Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Matt Corallo <lf-lists@mattcorallo.com>
Mime-Version: 1.0 (1.0)
Date: Sun, 12 Sep 2021 22:33:24 -0700
Message-Id: <571244AD-B8F4-4F2A-BF4B-31EED3AB7713@mattcorallo.com>
References: <20210912075305.GA23673@erisian.com.au>
In-Reply-To: <20210912075305.GA23673@erisian.com.au>
To: Anthony Towns <aj@erisian.com.au>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Reorgs on SigNet - Looking for feedback on
	approach and parameters
Precedence: list


> On Sep 12, 2021, at 00:53, Anthony Towns <aj@erisian.com.au> wrote:
>=20
> =EF=BB=BFOn Thu, Sep 09, 2021 at 05:50:08PM -0700, Matt Corallo via bitcoi=
n-dev wrote:
>>> AJ proposed to allow SigNet users to opt-out of reorgs in case they
>>> explicitly want to remain unaffected. This can be done by setting a
>>> to-be-reorged version bit [...]
>> Why bother with a version bit? This seems substantially more complicated
>> than the original proposal that surfaced many times before signet launche=
d
>> to just have a different reorg signing key.
>=20
> Yeah, that was the original idea, but there ended up being two problems
> with that approach. The simplest is that the signet block signature
> encodes the signet challenge,

But if that was the originally proposal, why is the challenge committed to i=
n the block? :)

> So using the RECENT_CONSENSUS_CHANGE behaviour that avoids the
> discourage/disconnect logic seems the way to avoid that problem, and that
> means making it so that nodes that that opt-out of reorgs can distinguish
> valid-but-will-become-stale blocks from invalid blocks. Using a versionbit=

> seems like the easiest way of doing that.

Sure, you could set that for invalid block signatures as well though. It=E2=80=
=99s not really a material DoS protection one way or the other.

>>> The reorg-interval X very much depends on the user's needs. One could
>>> argue that there should be, for example, three reorgs per day, each 48
>>> blocks apart. Such a short reorg interval allows developers in all time
>>> zones to be awake during one or two reorgs per day. Developers don't
>>> need to wait for, for example, a week until they can test their reorgs
>>> next. However, too frequent reorgs could hinder other SigNet users.
>> I see zero reason whatsoever to not simply reorg ~every block, or as ofte=
n
>> as is practical. If users opt in to wanting to test with reorgs, they sho=
uld
>> be able to test with reorgs, not wait a day to test with reorgs.
>=20
> Blocks on signet get mined at a similar rate to mainnet, so you'll always
> have to wait a little bit (up to an hour) -- if you don't want to wait
> at all, that's what regtest (or perhaps a custom signet) is for.

Can you explain the motivation for this? =46rom where I sit, as far as I kno=
w, I should basically be a prime example of the target market for public sig=
net - someone developing bitcoin applications with regular requirements to t=
est those applications with other developers without jumping through hoops t=
o configure software the same across the globe and set up miners. With block=
s being slow and irregular, I=E2=80=99m basically not benefited at all by si=
gnet and will stick with testnet3/mainnet testing, which both suck.=