From: Matt Corallo <lf-lists@mattcorallo•com>
To: Michael Folkson <michaelfolkson@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Reorgs on SigNet - Looking for feedback on approach and parameters
Date: Fri, 10 Sep 2021 12:22:00 -0700 [thread overview]
Message-ID: <966de823-557a-ad71-68b3-c9c8938e60e5@mattcorallo.com> (raw)
In-Reply-To: <CAFvNmHRKBt-KndgEtuT6da8qJAJgHSoime40J3x6Q=8tnnYpOw@mail.gmail.com>
Fwiw, your email client is broken and does not properly quote in the plaintext copy. I believe this
is a known gmail bug, but I'd recommend avoiding gmail's web interface for list posting :).
On 9/10/21 12:00, Michael Folkson wrote:
>> Huh? Why would the goal be to match mainnet? The goal, as I understand it, is to allow software to
> use SigNet without modification *to make testing simpler* - keep the
> header format the same to let
> SPV clients function without (significant) modification, etc. The
> point of the whole thing is to
> make testing as easy as possible, why would we do otherwise.
>
> I guess Kalle (and AJ) can answer this question better than me but my
> understanding is that the motivation for Signet was that testnet
> deviated erratically from mainnet behavior (e.g. long delays before
> any blocks were mined followed by a multitude of blocks mined in a
> short period of time) which meant it wasn't conducive to normal
> testing of applications. Why would you want a mainnet like chain? To
> check if your application works on a mainnet like chain without
> risking any actual value before moving to mainnet. The same purpose as
> testnet but more reliably resembling mainnet behavior. You are well
> within your rights to demand more than that but my preference would be
> to push some of those demands to custom signets rather than the
> default Signet.
Huh? You haven't made an argument here as to why such a chain is easier to test with, only that we
should "match mainnet". Testing on mainnet sucks, 99% of the time testing on mainnet involves no
reorgs, which *doesn't* match in-the-field reality of mainnet, with occasional reorgs. Matching
mainnet's behavior is, in fact, a terrible way to test if your application will run fine on mainnet.
My point is that the goal should be making it easier to test. I'm not entirely sure why there's
debate here. I *regularly* have lunch late because I'm waiting for blocks either on mainnet or
testnet3, and would quite like to avoid that in the future. It takes *forever* to test things on
mainnet and testnet3, matching their behavior would mean its equally impossible to test things on
mainnet and testnet3, why is that something we should stirve for?
> Testing out proposed soft forks in advance of them being considered
> for activation would already be introducing a dimension of complexity
> that is going to be hard to manage [0]. I'm generally of the view that
> if you are going to introduce a complexity dimension, keep the other
> dimensions as vanilla as possible. Otherwise you are battling
> complexity in multiple different dimensions and it becomes hard or
> impossible to maintain it and meet your initial objectives.
Yep! Great reason to not have any probabilistic nonsense or try to match mainnet or something on
signet, just make it deterministic, reorg once a block or twice an our or whatever and call it a day!
Matt
next prev parent reply other threads:[~2021-09-10 19:22 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2021-09-10 20:00 ` David A. Harding
-- strict thread matches above, loose matches on Subject: below --
2021-09-13 12:30 Michael Folkson
2021-09-13 16:24 ` Matt Corallo
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
2021-09-15 15:24 ` Matt Corallo
2021-10-15 4:41 ` Anthony Towns
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=966de823-557a-ad71-68b3-c9c8938e60e5@mattcorallo.com \
--to=lf-lists@mattcorallo$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=michaelfolkson@gmail$(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