|
| 1 | +<pre> |
| 2 | + BIP: 325 |
| 3 | + Layer: Applications |
| 4 | + Title: Signet |
| 5 | + Author: Karl-Johan Alm < [email protected]> |
| 6 | + Comments-Summary: No comments yet. |
| 7 | + Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0325 |
| 8 | + Status: Draft |
| 9 | + Type: Standards Track |
| 10 | + Created: 2019-03-20 |
| 11 | + License: CC0-1.0 |
| 12 | +</pre> |
| 13 | + |
| 14 | +== Abstract == |
| 15 | + |
| 16 | +A new type of test network where signatures are used in addition to proof of work for block progress, enabling much better coordination and robustness (be reliably unreliable), for persistent, longer-term testing scenarios involving multiple independent parties. |
| 17 | + |
| 18 | +== Motivation == |
| 19 | + |
| 20 | +Testnet is a great place to try out new things without risking real money, but it is notoriously unreliable. Huge block reorgs, long gaps in between blocks being mined or sudden bursts of blocks in rapid succession mean that realistic testing of software, especially involving multiple independent parties running software over an extended period of time, becomes infeasible in practice. |
| 21 | + |
| 22 | +A new type of test network would be more suitable for integration testing by organizations such as exchanges, or testing of next generation Layer-2 protocols like Eltoo or sidechain pegs. The goal is not to be perfectly reliable but rather to have a predictable amount of unreliability. You want a test network to behave like mainnet (i.e. no thousands of block reorgs) while also making it easier to trigger expected but rare events like a 6-block reorg. Regtest is not suitable for longer-term scenarios involving multiple independent parties because creating blocks costs nothing, so any party can completely control the test network. |
| 23 | + |
| 24 | + |
| 25 | +== Specification == |
| 26 | + |
| 27 | +A new type of network ("signet"), which takes an additional consensus parameter called the challenge (scriptPubKey). The challenge can be a simple pubkey (P2PKH style), or a k-of-n multisig, or any other script you would want. |
| 28 | + |
| 29 | +The witness commitment of the coinbase transaction is extended to include a secondary commitment (the signature/solution): |
| 30 | + |
| 31 | + 1-4 bytes - Push the following (x + 4) bytes |
| 32 | + 4 bytes - Signet header (0xecc7daa2) |
| 33 | + x bytes - Solution (sigScript) |
| 34 | +
|
| 35 | +Any push operations that do not start with the 4 byte signet header are ignored. Multiple push operations with the 4 byte signet header are ignored except for the first entry. |
| 36 | + |
| 37 | +Any signature operations contained within the challenge use SHA256d(modifiedBlockHash), i.e. the double-SHA256 digest of the following data as the sighash: |
| 38 | + |
| 39 | +{|class="wikitable" style="text-align: center;" |
| 40 | +|- |
| 41 | +!Type |
| 42 | +!Size |
| 43 | +!Name |
| 44 | +|- |
| 45 | +|Int32||4||nVersion |
| 46 | +|- |
| 47 | +|Uint256||32||hashPrevBlock |
| 48 | +|- |
| 49 | +|Uint256||32||modifiedMerkleRoot |
| 50 | +|- |
| 51 | +|Uint32||4||nTime |
| 52 | +|- |
| 53 | +|Uint32||4||nBits |
| 54 | +|} |
| 55 | + |
| 56 | +The <code>modifiedMerkleRoot</code> hash is obtained by generating the merkle root of the block transactions, with the coinbase witness commitment as is, without the signet extension. This means the merkle root of the block is different from the merkle root in the signet commitment. This is needed, because the signature can never be included in the very message (in this case, a block) that is being signed. Apart from the signature, to facilitate block generation (mining), the block nonce value is the only other component of the block that the signet signature does not commit to. When grinding proof of work, the extended nonce cannot be used as it would invalidate the signature. Instead, simply resigning the same (or an updated) block will give a new search space. |
| 57 | + |
| 58 | +A block is considered fully validated if the above commitment is found, and its solution is valid. It is recommended that this verification is done directly before or after the witness commitment verification, as the data required to do both is approximately the same. |
| 59 | + |
| 60 | +== Compatibility == |
| 61 | + |
| 62 | +This specification is backwards compatible in the sense that existing software can use Signet out of the box. |
| 63 | + |
| 64 | +Simply by adding the network parameters for signet (magic number, etc), a client can connect to and use any signet network without further modifications. The block headers have valid proof of work, so clients can trivially check that blocks are "probably" valid. |
| 65 | + |
| 66 | +However, anyone can mine blocks that are accepted by the client for any given signet network. These blocks do not contain the required signatures, however, so any fully validating node will promptly reject them. As such, clients need to either validate the block signature inside the coinbase transaction, or connect to trusted peers. |
| 67 | + |
| 68 | +Other software need not add block signature validation code that they will not use in production. This is adequate for non-production test purposes where the goal is to have a network behave as much like mainnet as possible. |
| 69 | + |
| 70 | +== Reference implementation == |
| 71 | + |
| 72 | +Pull request at https://github.com/bitcoin/bitcoin/pull/16411 |
| 73 | + |
| 74 | +== Acknowledgements == |
| 75 | + |
| 76 | +TODO |
| 77 | + |
| 78 | +== References == |
| 79 | + |
| 80 | +# Original mailing list thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016734.html |
| 81 | +# Bitcoin Wiki entry: https://en.bitcoin.it/wiki/Signet |
| 82 | +
|
| 83 | +== Copyright == |
| 84 | + |
| 85 | +This document is licensed under the Creative Commons CC0 1.0 Universal license. |
0 commit comments