Message-ID: <966de823-557a-ad71-68b3-c9c8938e60e5@mattcorallo.com>
Date: Fri, 10 Sep 2021 12:22:00 -0700
MIME-Version: 1.0
Content-Language: en-US
To: Michael Folkson <michaelfolkson@gmail.com>
References: <CAFvNmHR+SkAcd_Pr50bMhpWQwCULEo3rC1cwDSRAnu6kmGYAiQ@mail.gmail.com>
 <50970c07-b447-0b49-3f2b-b8a4961761f1@mattcorallo.com>
 <CAFvNmHRKBt-KndgEtuT6da8qJAJgHSoime40J3x6Q=8tnnYpOw@mail.gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <CAFvNmHRKBt-KndgEtuT6da8qJAJgHSoime40J3x6Q=8tnnYpOw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Reorgs on SigNet - Looking for feedback on
 approach and parameters
Precedence: list

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