BIP 325: Signet

kallewoof commented at 7:40 am on July 17, 2019: member

This BIP describes Signet, a proposed new network for testing purposes.

in bip-signet.mediawiki:16 in 0b13dad546 outdated

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.

jtimon commented at 7:33 pm on July 17, 2019:

This reads weird. It seems like you’re saying robustness = being reliably unreliable

Perhaps change to “(including being reliably unreliable)”? Or perhaps just remove it, since you talk about that more clearly on the motivation.

kallewoof commented at 3:03 am on July 18, 2019:

I actually am saying robustness = reliably unreliable! The network should be unreliable in the sense that it should behave like Bitcoin (sometimes one block orphans, very seldom but sometimes multi-block reorgs) and reliable in the same vein (never 10k block reorgs, and no 1 week blank periods).

jtimon commented at 8:22 pm on July 18, 2019:

Ok then.

in bip-signet.mediawiki:56 in 0b13dad546 outdated

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, but in return, the block nonce value is the only component 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.

jtimon commented at 7:45 pm on July 17, 2019:

How is that “in return”? It is a good idea not to hash the nonce, but even if you did, you still can’t hash the signature before you sign. I propose the following alternative phrasing:

0This 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.

kallewoof commented at 3:08 am on July 18, 2019:

Looks good. A bit over-explanatory on the signature part but I am keeping as is. Thanks.

jtimon commented at 8:23 pm on July 18, 2019:

Cool, yeah, I guess the signature part should probably be obvious to most people reading this, but I guess it doesn’t hurt.

in bip-signet.mediawiki:58 in 0b13dad546 outdated

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, but in return, the block nonce value is the only component 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. This verification should be done directly before or after the witness commitment verification.

jtimon commented at 7:49 pm on July 17, 2019:

why? what would be wrong with doing this verification directly before or after verifying the proof of work, for example?

In case it’s really necessary, is there any advantage on doing it right after over doing it right before? what about viceversa. If it’s better to do it before, perhaps only recommending doing it before is better, and viceversa.

kallewoof commented at 3:10 am on July 18, 2019:

You cannot do this verification at the same place that you do proof of work verification, because the data necessary in the two cases is different. For POW validation you only need the block header, whereas the block signature requires the block in its entirety, including all of the transactions.

There is no real advantage to doing it before vs after witness validation, but it should be considered an integral part of witness validation; it resides in the witness commitment, and it requires approximately the same data to operate.

jtimon commented at 8:26 pm on July 18, 2019:

well, by “the same place” I guess I meant one after the other, not necessarily the same function. I get that both segwit and signet validation require the coinbase transaction whereas pow validation doesn’t. But, sorry, I still don’t get why signet validation should be done near segwit validation.

kallewoof commented at 8:37 pm on July 18, 2019:

Where would you prefer it be done? It seems natural to do it around witness commitment check, since the data is there already.

kallewoof commented at 5:29 am on July 19, 2019:

I removed “should” and turned this into a recommendation.

jtimon changes_requested

jtimon commented at 8:00 pm on July 17, 2019: contributor

I’m eager for this.

kallewoof force-pushed on Jul 18, 2019

kallewoof cross-referenced this on Jul 18, 2019 from issue BIP-325: Signet support by kallewoof

in bip-signet.mediawiki:22 in 0b4e3d71b9 outdated

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.

luke-jr commented at 12:09 pm on July 18, 2019:

“Regtest” isn’t a network at all, just a testing mode for specific software.

kallewoof commented at 1:09 pm on July 18, 2019:

You can in practice start up a regtest and addnode people all over the world to create a network, though it would be completely vulnerable.

kallewoof force-pushed on Jul 19, 2019

kallewoof commented at 4:33 pm on July 23, 2019: member

These seem to be the editor criteria for BIPs, as seen in BIP-2:

Read the BIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don’t seem likely to be accepted.
- I am biased, but I believe it is sound and complete. If not, please let me know. Lack of negative feedback here and on mailing list, including concept ACKs on the implementation itself (3 concept ACKs on https://github.com/bitcoin/bitcoin/pull/16411), indicate this is the case.
The title should accurately describe the content.
- Title is fine, I believe, but I can expand if required.
The BIP draft must have been sent to the Bitcoin development mailing list for discussion.
- https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017123.html
Motivation and backward compatibility (when applicable) must be addressed.
- There is a backwards compatibility section; if it needs complementing, let me know.
The defined Layer header must be correctly assigned for the given specification.
- Application seems like the correct layer.
Licensing terms must be acceptable for BIPs.
- License is based on other, already-approved BIPs.

If there’s anything not in this list, lemme know.

MaxHillebrand cross-referenced this on Jul 25, 2019 from issue Implement Signet Support by MaxHillebrand

kallewoof force-pushed on Aug 11, 2019

luke-jr commented at 10:07 pm on September 19, 2019: member

I think the only question is whether it is actually Bitcoin…

luke-jr added the label New BIP on Sep 19, 2019

kallewoof commented at 5:32 am on September 24, 2019: member

Since it affects (in the “lets test our software thoroughly” sense) all Bitcoin software, I would say it is Bitcoin. I guess it depends on your definition of “Bitcoin” though?

clarkmoody commented at 3:18 am on October 15, 2019: contributor

Testnet is mentioned plenty of times in the BIPs. Is Testnet Bitcoin?

harding commented at 3:21 am on October 15, 2019: contributor

Documenting a standardized way to create test networks for Bitcoin applications seems like a wholly appropriate use of the BIPs repository. If that justification is not satisfactory to convince the BIPs editor that this proposed BIP should be merged, I’d suggest changing this document’s type to “Informational”. I’ve just skimmed BIP2 and it seems to me that pretty much anything can be published in that category.

junderw commented at 5:52 am on October 15, 2019: contributor

I agree with @harding

Worst case scenario: Change type to informational and merge

But tbh I think this is fine as is.

laanwj commented at 7:18 am on October 15, 2019: member

Agree with @harding too. I think the “is this bitcoin” discussion is a valid point but also I think there’s wide enough agreement that this deserves a BIP [as a testnet, not as a future course for bitcoin mainnet, ofc]. There’s much more controversial ideas (for mainnet!) that got a BIP number.

junderw commented at 7:27 am on October 15, 2019: contributor

Agree with @harding too. I think the “is this bitcoin” discussion is a valid point but also I think there’s wide enough agreement that this deserves a BIP [as a testnet, not as a future course for bitcoin mainnet, ofc]. There’s much more controversial ideas (for mainnet!) that got a BIP number.

looks at BIP100 onward

Yup. We’ve had many more “is this Bitcoin?” BIPs merged with the intent of hardforking mainnet… so a BIP with the intent of creating a new testnet is definitely BIP-worthy imo.

luke-jr renamed this:
~~BIP-XXXX: Signet~~
BIP 325: Signet
on Nov 4, 2019

luke-jr commented at 3:20 pm on November 4, 2019: member

Assigned BIP 325.

BIP 325: Signet 2a270d9419

kallewoof force-pushed on Nov 6, 2019

luke-jr merged this on Nov 6, 2019

luke-jr closed this on Nov 6, 2019

BIP 325: Signet #803