Date: Tue, 14 Sep 2021 14:56:10 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Matt Corallo <lf-lists@mattcorallo.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20210914045610.GA25475@erisian.com.au>
References: <20210912075305.GA23673@erisian.com.au>
 <571244AD-B8F4-4F2A-BF4B-31EED3AB7713@mattcorallo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <571244AD-B8F4-4F2A-BF4B-31EED3AB7713@mattcorallo.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Subject: Re: [bitcoin-dev] Reorgs on SigNet - Looking for feedback on
 approach and parameters
Precedence: list

On Sun, Sep 12, 2021 at 10:33:24PM -0700, Matt Corallo via bitcoin-dev wrote:
> > On Sep 12, 2021, at 00:53, Anthony Towns <aj@erisian.com.au> wrote:
> >> Why bother with a version bit? This seems substantially more complicated
> >> than the original proposal that surfaced many times before signet launched
> >> to just have a different reorg signing key.
> > 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 in the block? :)

The answer to your question was in the text after the comma, that you
deleted...

> > 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? 

I'm not sure that's really the question you want answered? Mostly
it's just "this is how mainnet works" plus "these are the smallest
changes to have blocks be chosen by a signature, rather than entirely
by PoW competition".

For integration testing across many services, I think a ten-minute-average
between blocks still makes sense -- protocols relying on CSV/CLTV to
ensure there's a delay they can use to recover funds, if they specify
that in blocks (as lightning's to_self_delay does), then significant
surges of blocks will cause uninteresting bugs. 

It would be easy enough to change things to target an average of 2 or
5 minutes, I suppose, but then you'd probably need to propogate that
logic back into your apps that would otherwise think 144 blocks is around
about a day.

We could switch back to doing blocks exactly every 10 minutes, rather
than a poisson-ish distribution in the range of 1min to 60min, but that
doesn't seem like that huge a win, and makes it hard to test that things
behave properly when blocks arrive in bursts.

> From where I sit, as far as I know, I should basically be a prime
> example of the target market for public signet - someone developing
> bitcoin applications with regular requirements to test those applications
> with other developers without jumping through hoops to configure software
> the same across the globe and set up miners. With blocks being slow and
> irregular, I’m basically not benefited at all by signet and will stick
> with testnet3/mainnet testing, which both suck.

Best of luck to you then? Nobody's trying to sell you on a subscription
plan to using signet. Signet's less expensive in fees (or risk) than
mainnet, and takes far less time for IBD than testnet, but if those
aren't blockers for you, that's great.

Cheers,
aj