path: root/a7/46f8d5abeb89e278ef3901018bf06535b1983b

Return-Path: <michaelfolkson@protonmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C1CA6C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  2 Oct 2022 15:25:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 9660E6060A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  2 Oct 2022 15:25:25 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 9660E6060A
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
 header.a=rsa-sha256 header.s=protonmail3 header.b=xOi21aBq
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.103
X-Spam-Level: 
X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 PDS_OTHER_BAD_TLD=1.999, RCVD_IN_MSPIKE_H2=-0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id KXTSIooGZiCm
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  2 Oct 2022 15:25:24 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 3895F605F6
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 3895F605F6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  2 Oct 2022 15:25:24 +0000 (UTC)
Date: Sun, 02 Oct 2022 15:25:19 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1664724321; x=1664983521;
 bh=G5dsffpKpnGo1drhmL+zOM5AtmGtsTfPaDdP2b7Lm+U=;
 h=Date:To:From:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID;
 b=xOi21aBqoKoR99bAh6j345qS6+UmHPOtfXjRZ5LAacTNlHIv8mUyaCappstW3kpFh
 RvjX023hyCPQsJkGxhnW7OQVpkONSNXfNdxwINfJj8KB9vVTAygQ4xu0Nr/XZXvOdh
 Nhk9AD/wcDPaQCRyOTFcMO0g5rW089ea4EUGXwfBeF6RWPitoMqUwl4RPA351bsjmh
 O+IBDEXyiREpA4K+RZyJuS5my412pbz2axFq0xzsiQW/GIqsJIcHf0rBsBzaMekJxR
 8OzTcj7wsnxUFDQVesFYNyQ5Euadgn87pD09uexrkdTOd8maPAqOIMQZrUz096XXHZ
 gK8KCLJ+5LfeA==
To: Anthony Towns <aj@erisian.com.au>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: Michael Folkson <michaelfolkson@protonmail.com>
Message-ID: <QCgAXgQnala8tj6931-FkV7y_E3_PccGjvWziGoY6QG7hF1RZfiM2Zh3luKTtnnpn_DgjjxzDlMESO1DO06zyr1Ykl_eUrQKLqe4g8wmRqQ=@protonmail.com>
In-Reply-To: <YzkruoZZ5sP4IvKl@erisian.com.au>
References: <YyQioS3F942wu1HW@erisian.com.au> <YzkruoZZ5sP4IvKl@erisian.com.au>
Feedback-ID: 27732268:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Sun, 02 Oct 2022 15:48:32 +0000
Subject: Re: [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on
	signet
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 02 Oct 2022 15:25:25 -0000

Thanks for this AJ, especially the history on prior soft forks, the vast ma=
jority 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 ac=
tivated 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 b=
lock signers and gatekeepers for soft forks activated on the default signet=
. I'm more concerned with those gatekeepers being under pressure to merge u=
nfinished, buggy soft fork proposals on the default signet which need to be=
 reversed or changed disrupting all default signet users. The bar for mainn=
et 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 o=
r zero disruption. The more soft fork proposals that are enabled on the def=
ault signet (and the more changes to those soft fork proposals pushed to th=
e 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 nu=
mber of block signers (currently 2) should prevent you being forked off ent=
irely onto a different default signet chain with new mined blocks being add=
ed to your blockchain tip but your blockchain could stall.

What should happen in this scenario? Say I'm a default signet full node run=
ner 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 sign=
et, I just care about testing my application with the existing consensus ru=
les on mainnet. However, my default signet blockchain has stalled because o=
f some consensus rule adjustment (an effective hard fork) made by the signe=
t miners and the block signers. I have to run a patch from bitcoin-inquisit=
ion 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 che=
ckpoint 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 kern=
el merge window."

I guess I'd also want expectations to be tempered a little for consensus ch=
anges on bitcoin-inquisition versus say this description of linux-next. I d=
on't know where the bar will be set for default signet soft fork activation=
s by the block signers and the miners but wherever it is set it will be low=
er than mainnet. And to be considered for activation on mainnet these propo=
sals do require community consensus if we want to minimize the risk of main=
net chain splits. There are no block signers or regularly updated checkpoin=
ts on mainnet. It is certainly possible that soft fork proposals that get a=
ctivated on the default signet never get activated on mainnet and that bein=
g activated on the default signet offers no guarantees or even intentions/a=
ims 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 defa=
ult signet so you should expect it to be activated on mainnet within x mont=
hs or y years" type thing.

Thanks
Michael

[0]: https://www.kernel.org/doc/man-pages/linux-next.html
[1]: https://twitter.com/bitcoinoptech/status/1574697495325974528?s=3D20&t=
=3DXWkpA459C9qxOOrBuP2fYA

--
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 <bitco=
in-dev@lists.linuxfoundation.org> wrote:


> On Fri, Sep 16, 2022 at 05:15:45PM +1000, Anthony Towns via bitcoin-dev w=
rote:
>=20
> > 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
>=20
>=20
> 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).
>=20
> 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.
>=20
> [0] https://github.com/bitcoin-inquisition/bitcoin/pull/8
> https://github.com/bitcoin/bitcoin/pull/21702#pullrequestreview-111804773=
0
>=20
> 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].
>=20
> [1] https://mempool.space/signet/address/tb1pesae595q3cpzp8j3gy07gussw9t9=
hh580xj027sfz6g8e530u3nqscn0yn
>=20
> [2] "ec764a8ed632916868ca6dbfdc5bed95f74b83be62d01397aba7ec916982c6721c92=
3fa22d29b5e0c4fddde0148233f0cf401758df23d8cc89c88f04beffc3c3c1" -- sighash =
of 0xc1 =3D ANYPREVOUTANYSCRIPT|ALL
>=20
> https://mempool.space/signet/tx/ee6f6eda93a3d80f4f65f2e1000334132c9a014b3=
ed3dec888fdcc1f3441f52c
> https://mempool.space/signet/tx/2cbcc4857e6ee8510d9479c01fbf133a9a2cde3f5=
c61ccf9439c69b7b83334ba
>=20
> [3] https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#Signat=
ure_replay
>=20
> [4] https://mempool.space/signet/tx/53a9747546e378956072795351e8436cf704d=
a72d235c8ac7560787b554a4d3f
>=20
> Cheers,
> aj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev