From: Anthony Towns <aj@erisian•com.au>
To: Matt Corallo <lf-lists@mattcorallo•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Reorgs on SigNet - Looking for feedback on approach and parameters
Date: Tue, 14 Sep 2021 14:56:10 +1000 [thread overview]
Message-ID: <20210914045610.GA25475@erisian.com.au> (raw)
In-Reply-To: <571244AD-B8F4-4F2A-BF4B-31EED3AB7713@mattcorallo.com>
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
next prev parent reply other threads:[~2021-09-14 4:56 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-07 16:07 0xB10C
2021-09-07 16:44 ` Jeremy
2021-09-08 7:59 ` Anthony Towns
2021-09-12 14:29 ` vjudeu
2021-09-12 14:54 ` Greg Sanders
2021-09-10 0:50 ` Matt Corallo
2021-09-12 7:53 ` Anthony Towns
2021-09-13 5:33 ` Matt Corallo
2021-09-14 4:56 ` Anthony Towns [this message]
2021-09-15 15:24 ` Matt Corallo
2021-10-15 4:41 ` Anthony Towns
2021-09-10 13:05 Michael Folkson
2021-09-10 18:24 ` Matt Corallo
2021-09-10 19:00 ` Michael Folkson
2021-09-10 19:22 ` Matt Corallo
2021-09-10 20:00 ` David A. Harding
2021-09-13 12:30 Michael Folkson
2021-09-13 16:24 ` Matt Corallo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210914045610.GA25475@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lf-lists@mattcorallo$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox