public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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: Wed, 15 Sep 2021 08:24:43 -0700	[thread overview]
Message-ID: <90AD5816-4B44-4BBB-A2FC-39CD381D6395@mattcorallo.com> (raw)
In-Reply-To: <20210914045610.GA25475@erisian.com.au>



> On Sep 13, 2021, at 21:56, Anthony Towns <aj@erisian.com.au> wrote:
> I'm not sure that's really the question you want answered?

Of course it is? I’d like to understand the initial thinking and design analysis that went into this decision. That seems like an important question to ask when seeking changes in an existing system :).

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

Hmm, why would blocks coming quicker lead to a bug? I certainly hope no one has a bug if their block time is faster than per ten minutes. I presume here, you mean something like “if the node can’t keep up with the block rate”, but I certainly hope the benchmark for may isn’t 10 minutes, or really even one.

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

Why? One useful thing for testing is compressing real time. More broadly, the only issues that I’ve heard around block times in testnet3 are the inconsistency and, rarely software failing to keep up at all.

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

Hmm, I suppose? If you want to test that the upper bound doesn’t need to be 100 minutes, though, it could be 10.

> Best of luck to you then? Nobody's trying to sell you on a subscription
> plan to using signet.


lol, yes, I’m aware of that, nor did I mean to imply that anything has to be targeted at a specific person’s requirements. Rather, my point here is that I’m really confused as to who  the target user *is*, because we should be building products with target users in mind, even if those targets are often “me” for open source projects.

  reply	other threads:[~2021-09-15 15:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-07 16:07 [bitcoin-dev] Reorgs on SigNet - Looking for feedback on approach and parameters 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
2021-09-15 15:24         ` Matt Corallo [this message]
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=90AD5816-4B44-4BBB-A2FC-39CD381D6395@mattcorallo.com \
    --to=lf-lists@mattcorallo.com \
    --cc=aj@erisian.com.au \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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