From: Johnson Lau <jl2012@xbt•hk>
To: bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Forcenet: an experimental network with a new header format
Date: Sun, 15 Jan 2017 05:14:55 +0800 [thread overview]
Message-ID: <5CDE542F-204F-4988-838F-F438D30C7D99@xbt.hk> (raw)
In-Reply-To: <FB8593E6-3CD7-46D5-8FC8-A73A0EF1AE9A@xbt.hk>
[-- Attachment #1: Type: text/plain, Size: 5314 bytes --]
I created a second version of forcenet with more experimental features and stopped my forcenet1 node.
1. It has a new header format: Height (4), BIP9 signalling field (4), hardfork signalling field (2), Hash TMR (32), Hash WMR (32), Merkle sum root (32), number of tx (4), prev hash (32), timestamp (4), nBits (4), nonce1 (4), nonce2 (4), nonce3 (compactSize + variable), merkle branches leading to header C (compactSize + 32 bit hashes)
2. Anti-tx-replay. If, after masking the highest byte, the tx nVersion is >=3, the sighash for both segwit and non-segwit outputs is calculated with BIP143, except 0x2000000 is added to the nHashType. Such signatures are invalid for legacy nodes. But since they are non-std due the nVersion, they won’t be relayed nor validated by legacy nodes. This also removes the O(n^2) sighash problem when spending non-segwit outputs. (anti-replay is a long story and I will discuss in a separate post/BIP)
3. Block sighashlimit (https://github.com/jl2012/bips/blob/sighash/bip-sighash.mediawiki <https://github.com/jl2012/bips/blob/sighash/bip-sighash.mediawiki>). Due to point 2, SigHashSize is counted only for legacy non-segwit inputs (with masked tx nVersion < 3). We have to support legacy signature to make sure time-locked txs made before the hard fork are still valid.
4. A totally new way to define tx weight. Tx weight is the maximum of the following metrics:
a. SigHashSize (see the bip in point 3)
b. Witness serialised size * 2 * 90
c. Adjusted size * 90. Adjusted size = tx weight (BIP141) + (number of non-OP_RETURN outputs - number of inputs) * 41 * 4
d. nSigOps * 50 * 90. All SigOps are equal (no witness scaling). For non-segwit txs, the sigops in output scriptPubKey are not counted, while the sigops in input scriptPubKey are counted.
90 is the scaling factor for SigHashSize, to maintain the 1:90 ratio (see the BIP in point 3)
50 is the scaling factor for nSigOps, maintaining the 1:50 ratio in BIP141
Rationale for adjusted size: 4 is witness scaling factor. 41 is the minimum size for an input (32 hash + 4 index + 4 nSequence + 1 scriptSig). This requires people to pre-pay majority of the fee of spending an UTXO. It makes creation of UTXO more expensive, while spending of UTXO cheaper, creates a strong incentive to limit the growth of UTXO set.
Rationale for taking the maximum of different metrics: this indirectly set an upper block resources for _every_ metrics, while making the tx fee estimation a linear function. Currently, there are 2 block resources limits: block weight and nSigOp cost (BIP141). However, since users do not know what the other txs are included in the next block, it is difficult to determine whether tx weight of nSigOp cost is a more important factor in determining the tx fee. (This is not a real problem now, because weight is more important in most cases). With an unified definition of tx weight, the fee estimation becomes a linear problem.
Translating to new metric, the current BIP141 limit is 360,000,000. This is equivalent to 360MB of sighashing, 2MB of serialised size, 4MB of adjusted size, or 80000 nSigOp.
Any new block-level limit metrics could be added to tx weight using soft forks.
5. Smooth halving: the reward of the last 2016 blocks in a halving cycle will be reduced by 25%, which is contributed to the first 2016 blocks of the new halving cycle. (different parameters for forcenet) This makes a more graceful transition but we will lose some fun around halving.
6. A new coinbase tx format. BIP34 is removed. Coinbase tx may have more than 1 input. The prevout hash of first input must be the hash of previous block, and index must be 0xffffffff. The other inputs (if any) must come from UTXOs with valid signatures. Spending of previous coinbase outputs in a coinbase tx is exempted from the 100 block maturity requirement. Therefore, miners of an earlier block may pay other miners to convince them to confirm their blocks.
7. Merkle sum tree: it allows generating of fraud-proof for fee and weight. A special softfork (bit 15) is defined. When this softfork is activated, the full node will not validate the sum tree. This is needed because when the definition of tx weight is changed through a softfork (e.g. a new script version introducing new sigop), olds nodes won’t know the new rules and will find the sum tree invalid. Disabling the sum tree validation won’t degrade the security of a full node by more than an usual softfork, because the full node would still validate all other known rules.
However, it is still not possible to create fraud proof for spending of non-existing UTXO. This requires commitment of the block height of inputs, and the tx index in the block. I’m not quire sure how this could be implemented because a re-org may change such info (I think validation is easy but mining is more tricky)
How to join: codes at https://github.com/jl2012/bitcoin/tree/forcenet2 <https://github.com/jl2012/bitcoin/tree/forcenet2> , start with "bitcoind —forcenet" .
Connection: I’m running a node at 8333.info <http://8333.info/> with default port (39901)
Mining: there is only basic internal mining support. To use the internal miner, writeup a shell script to repeatedly call “bitcoin-cli —forcenet generate 1”
jl2012
[-- Attachment #2: Type: text/html, Size: 6479 bytes --]
next prev parent reply other threads:[~2017-01-14 21:15 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-04 19:34 Johnson Lau
2016-12-04 20:00 ` adiabat
2016-12-04 20:37 ` Hampus Sjöberg
2016-12-05 11:58 ` Tom Zander
2016-12-14 11:01 ` Johnson Lau
2016-12-14 11:07 ` Luke Dashjr
2016-12-14 11:12 ` Johnson Lau
2016-12-14 11:11 ` Johnson Lau
2016-12-10 21:29 ` Tier Nolan
2016-12-10 21:41 ` Luke Dashjr
2016-12-11 16:40 ` Tier Nolan
2016-12-14 10:55 ` Johnson Lau
2016-12-14 12:52 ` Tier Nolan
2016-12-14 15:45 ` Johnson Lau
2016-12-14 16:26 ` Tier Nolan
2017-01-14 21:14 ` Johnson Lau [this message]
2017-01-28 2:32 ` Matt Corallo
2017-01-28 3:02 ` Matt Corallo
2017-01-28 7:28 ` Johnson Lau
2017-01-28 17:14 ` Matt Corallo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5CDE542F-204F-4988-838F-F438D30C7D99@xbt.hk \
--to=jl2012@xbt$(echo .)hk \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox