From: Matt Corallo <lf-lists@mattcorallo•com>
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
Date: Sun, 12 Sep 2021 22:33:24 -0700 [thread overview]
Message-ID: <571244AD-B8F4-4F2A-BF4B-31EED3AB7713@mattcorallo.com> (raw)
In-Reply-To: <20210912075305.GA23673@erisian.com.au>
> On Sep 12, 2021, at 00:53, Anthony Towns <aj@erisian•com.au> wrote:
>
> On Thu, Sep 09, 2021 at 05:50:08PM -0700, Matt Corallo via bitcoin-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 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? :)
> 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’s 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 often
>> as is practical. If users opt in to wanting to test with reorgs, they should
>> be able to test with reorgs, not wait a day to test with reorgs.
>
> 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? 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.
next prev parent reply other threads:[~2021-09-13 5:33 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 [this message]
2021-09-14 4:56 ` Anthony Towns
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=571244AD-B8F4-4F2A-BF4B-31EED3AB7713@mattcorallo.com \
--to=lf-lists@mattcorallo$(echo .)com \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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