Thanks for this AJ, especially the history on prior soft forks, the vast majority of which I was unclear on.
> The point of doing it via signet and outside of core is there doesn't need to be any community consensus on soft forks. Unlike mainnet, signet sBTC isn't money, and it isn't permissionless; and unlike merging it into core, there isn't a risk of a mege having unintended side effects impacting mainnet operation. Agreed. I'm obviously much happier with proposed consensus changes being activated prematurely on a signet (default or custom) than on mainnet. > Because signet mining is a closed set (determined by the first block after genesis when the signetchallenge is locked in), signet soft forks always have gatekeepers. I'm also perfectly happy with the status quo of the default signet having block signers and gatekeepers for soft forks activated on the default signet. I'm more concerned with those gatekeepers being under pressure to merge unfinished, buggy soft fork proposals on the default signet which need to be reversed or changed disrupting all default signet users. The bar for mainnet activations is obviously much higher than for the default signet but the default signet does still need a bar. > If you don't want to risk any disruption, then regtest or a private signet is a better option. A global p2p network *always* has risk of disruption at some level or another. Right but disruption isn't boolean, it is a spectrum. It isn't disruption or zero disruption. The more soft fork proposals that are enabled on the default signet (and the more changes to those soft fork proposals pushed to the default signet) the higher the risk of a stalling blockchain (your signet node rejects a block the rest of the signet network accepts). The small number of block signers (currently 2) should prevent you being forked off entirely onto a different default signet chain with new mined blocks being added to your blockchain tip but your blockchain could stall. What should happen in this scenario? Say I'm a default signet full node runner and I don't want to run any code outside of say the Bitcoin Core repo. I don't care about the proposed soft forks being tested on the default signet, I just care about testing my application with the existing consensus rules on mainnet. However, my default signet blockchain has stalled because of some consensus rule adjustment (an effective hard fork) made by the signet miners and the block signers. I have to run a patch from bitcoin-inquisition to get my node adding blocks again? I'm essentially being forced to run code from bitcoin-inquisition or wait many months for a default signet checkpoint in a Core release. I looked into linux-next[0] which you mentioned as an interesting parallel in the Linux ecosystem on last week's Bitcoin Optech Twitter Spaces [1]. In that link linux-next is described as: "The linux-next tree is the holding area for patches aimed at the next kernel merge window." I guess I'd also want expectations to be tempered a little for consensus changes on bitcoin-inquisition versus say this description of linux-next. I don't know where the bar will be set for default signet soft fork activations by the block signers and the miners but wherever it is set it will be lower than mainnet. And to be considered for activation on mainnet these proposals do require community consensus if we want to minimize the risk of mainnet chain splits. There are no block signers or regularly updated checkpoints on mainnet. It is certainly possible that soft fork proposals that get activated on the default signet never get activated on mainnet and that being activated on the default signet offers no guarantees or even intentions/aims for the next Bitcoin Core (or any alternative implementation) release. I'd like to avoid the "my soft fork proposal has been activated on the default signet so you should expect it to be activated on mainnet within x months or y years" type thi ng. Thanks Michael [0]: https://www.kernel.org/doc/man-pages/linux-next.html [1]: https://twitter.com/bitcoinoptech/status/1574697495325974528?s=20&t=XWkpA459C9qxOOrBuP2fYA -- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ------- Original Message ------- On Sunday, October 2nd, 2022 at 07:12, Anthony Towns via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > On Fri, Sep 16, 2022 at 05:15:45PM +1000, Anthony Towns via bitcoin-dev wrote: > > > So that's the concept. For practical purposes, I haven't yet merged > > either CTV or APO support into the bitcoin-inquisition 23.0 branch yet > > > I've now merged CTV and updated my signet miner to enforce both CTV and > APO (though you'd need to be either lucky or put some effort into it to > figure out how to get a CTV/APO transaction relayed to my miner). > > Updating APO to be compatible with CTV actually seems to have found a > previously unknown bug in the CTV PR against core [0], so that seems > productive at the very least. > > [0] https://github.com/bitcoin-inquisition/bitcoin/pull/8 > https://github.com/bitcoin/bitcoin/pull/21702#pullrequestreview-1118047730 > > I've also mined a couple of test APO transactions [1]; both reusing an > APOAS signature [2], including demonstrating the case where a third party > can replay APO signatures to send funds from duplicate UTXOs to fees, > by spending those UTXOs in a single tx [3] [4]. > > [1] > https://mempool.space/signet/address/tb1pesae595q3cpzp8j3gy07gussw9t9hh580xj027sfz6g8e530u3nqscn0yn > > [2] > "ec764a8ed632916868ca6dbfdc5bed95f74b83be62d01397aba7ec916982c6721c923fa22d29b5e0c4fddde0148233f0cf401758df23d8cc89c88f04beffc3c3c1" > -- sighash of 0xc1 = ANYPREVOUTANYSCRIPT|ALL > > https://mempool.space/signet/tx/ee6f6eda93a3d80f4f65f2e1000334132c9a014b3ed3dec888fdcc1f3441f52c > https://mempool.space/signet/tx/2cbcc4857e6ee8510d9479c01fbf133a9a2cde3f5c61ccf9439c69b7b83334ba > > [3] > https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#Signature_replay > > [4] > https://mempool.space/signet/tx/53a9747546e378956072795351e8436cf704da72d235c8ac7560787b554a4d3f > > Cheers, > aj > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
