path: root/f3/82048a95e5e9778e5dc10102b2f29c97bc31e7

Return-Path: <michaelfolkson@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 56171C000D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 10 Sep 2021 19:00:53 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 3C4A36074F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 10 Sep 2021 19:00:53 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 3z-TfSvUO0ef
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 10 Sep 2021 19:00:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com
 [IPv6:2607:f8b0:4864:20::b2e])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 03EB960718
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 10 Sep 2021 19:00:51 +0000 (UTC)
Received: by mail-yb1-xb2e.google.com with SMTP id r4so5870501ybp.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 10 Sep 2021 12:00:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=Nw2N4kzOevyuluRyD313N6Fq9WVKQvSyxoURRBJc5ek=;
 b=Cnv3lGF+CXaPJW8KkKn/3+iJAeb9aMtFIE7/zILo5sxtizRLmZrxl6yfH8DFiJ8KYY
 KcJLkBzocUROQn1CqMRad+lKmYa33DSD55cZsZOgR3sZsxzM/ZHRIAYDEw8lxEiYgoSB
 EL3SCB9JIjKcZalnuIw92AeZC2R1LwS/8Sih2RMwlGcSIAeQgdVetjcGwmMfslA+Tpk+
 DvauuUY2BAMJhP0+JqtUhFNX6SME6SFt6vj+txqOQ6WaXVaN4+wNAncGkn2nFmZy2UTv
 5KBNGBJGexskrLAVq55BsAwF/IkJ72DAi6lhPj3sYtlW7jmJF+BNvW7/AX7GcPnCHthG
 w+Fw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=Nw2N4kzOevyuluRyD313N6Fq9WVKQvSyxoURRBJc5ek=;
 b=OjWzFmVALl5UpkbtdbzIfZG/w8y3ZRE1nFUKSkzvEFq4zAHVw8PiulCJPPuXq9sDAq
 mrdorxpmKzfhRx0XUH7VnRn2WmXcUJN8rFvSzimTUrQvGOX/Ua/ZneN9g4cUq1mwiyF3
 3W/vBsEtTVvafeRMomkXFUZezg1vrF3ahTLkseILnu3sb7OxCqjUVFbvxpmOtVc619SE
 cy59mIplaNzchrjdERO35Musmt5CEFLeQMwkT8UNaDd95E2zJuTSaHiRXaO2UAdgWB6P
 ZWsW+jYj17BtQCJdCSeppEC1kdEw9f4BK8Abln7HgtWm/CvRqBgzk3O3lLpv2Dgh28lX
 2Fbw==
X-Gm-Message-State: AOAM532J3azZznrBvmE7QWS0YuRaxJJEc6fTGJXggQ2Dds8wpSwoa9As
 lfNzpvSPSiUFOqn7t+Fe58k10ccVckY4fwOSEfZGXo0OMRI=
X-Google-Smtp-Source: ABdhPJzH7KALJaslrq/Kg5gWQ9/YBmPfvFlYEGqTyxwqnckAod+l0jH+s9bDaPY3/yuTD/5EEleWKBeMlHTIV9R3OqY=
X-Received: by 2002:a25:ca54:: with SMTP id a81mr12675181ybg.349.1631300450736; 
 Fri, 10 Sep 2021 12:00:50 -0700 (PDT)
MIME-Version: 1.0
References: <CAFvNmHR+SkAcd_Pr50bMhpWQwCULEo3rC1cwDSRAnu6kmGYAiQ@mail.gmail.com>
 <50970c07-b447-0b49-3f2b-b8a4961761f1@mattcorallo.com>
In-Reply-To: <50970c07-b447-0b49-3f2b-b8a4961761f1@mattcorallo.com>
From: Michael Folkson <michaelfolkson@gmail.com>
Date: Fri, 10 Sep 2021 20:00:39 +0100
Message-ID: <CAFvNmHRKBt-KndgEtuT6da8qJAJgHSoime40J3x6Q=8tnnYpOw@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Fri, 10 Sep 2021 23:00:24 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Reorgs on SigNet - Looking for feedback on
 approach and parameters
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Sep 2021 19:00:53 -0000

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

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.

But if this feature of extremely regular re-orgs is an in demand
feature for testers I think the question then becomes what the default
be (I would suggest re-orgs every 8 hours rather than no re-orgs at
all) and then the alternative which you can switch to, re-orgs every
block or every 6 blocks or whatever.

> I believe my suggestion was not correctly understood. I'm not suggesting =
*users* sign blocks or
otherwise do anything manually here, only that the existing block
producers each generate a new key,
and we then only sign reorgs with *those* keys. Users will be able to
set a flag to indicate "I want
to accept sigs from either sets of keys, and see reorgs" or "I only
want sigs from the non-reorg
keys, and will consider the reorg keys-signed blocks invalid"

Ah I did misunderstand, yes this makes more sense. Thanks for the correctio=
n.

[0] https://bitcoin.stackexchange.com/questions/98642/can-we-experiment-on-=
signet-with-multiple-proposed-soft-forks-whilst-maintaining

On Fri, Sep 10, 2021 at 7:24 PM Matt Corallo <lf-lists@mattcorallo.com> wro=
te:
>
>
>
> On 9/10/21 06:05, Michael Folkson wrote:
> >> I see zero reason whatsoever to not simply reorg ~every block, or as o=
ften 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.
> >
> > One of the goals of the default Signet was to make the default Signet
> > resemble mainnet as much as possible. (You can do whatever you want on
> > a custom signet you set up yourself including manufacturing a re-org
> > every block if you wish.) Hence I'm a bit wary of making the behavior
> > on the default Signet deviate significantly from what you might
> > experience on mainnet. Given re-orgs don't occur that often on mainnet
> > I can see the argument for making them more regular (every 8 hours
> > seems reasonable to me) on the default Signet but every block seems
> > excessive. It makes the default Signet into an environment for purely
> > testing whether your application can withstand various flavors of edge
> > case re-orgs. You may want to test whether your application can
> > withstand normal mainnet behavior (no re-orgs for long periods of
> > time) first before you concern yourself with re-orgs.
>
> 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 head=
er format the same to let
> SPV clients function without (significant) modification, etc. The point o=
f the whole thing is to
> make testing as easy as possible, why would we do otherwise.
>
> Further, because one goal here is to enable clients to opt in or out of t=
he reorg chain at will
> (presumably by just changing one config flag in bitcoin.conf), why would =
we worry about making it
> "similar to mainnet". If users want an experience "similar to mainnet", t=
hey can simply turn off
> reorgs and they'll see a consistent chain moving forward which never reor=
gs, similar to the
> practical experience of mainnet.
>
> Once you've opted into reorgs, you almost certainly are looking to *test*=
 reorgs - you just
> restarted Bitcoin Core with the reorg flag set, waiting around for a reor=
g after doing that seems
> like the experience of testnet3 today, and the whole reason why we wanted=
 signet to begin with -
> things happen sporadically and inconsistently, making developers wait aro=
und forever. Please lets
> not replicate the "gotta wait for blocks before I can go to lunch" experi=
ence of testnet today on
> signet, I'm tired of eating lunch late.
>
> >> Why bother with a version bit? This seems substantially more complicat=
ed than the original proposal that surfaced many times before signet launch=
ed to just have a different reorg signing key. Thus, users who wish to foll=
ow reorgs can use a 1-of-2 (or higher multisig) and users who wish to not f=
ollow reorgs would use a 1-of-1 (or higher multisig), simply marking the re=
org blocks as invalid without touching any header bits that non-full client=
s will ever see.
> >
> > If I understand this correctly this is introducing a need for users to
> > sign blocks when currently with the default Signet the user does not
> > need to concern themselves with signing blocks. That is entirely left
> > to the network block signers of the default Signet (who were AJ and
> > Kalle last time I checked). Again I don't think this additional
> > complexity is needed on the default Signet when you can set up your
> > own custom Signet if you want to test edge case scenarios that deviate
> > significantly from what you are likely to experience on mainnet. A
> > flag set via a configuration argument (the AJ, 0xB10C proposal) with
> > no-reorgs (or 8 hour re-orgs) as the default seems to me like it would
> > introduce no additional complexity to the casual (or alpha stage)
> > tester experience though of course it introduces implementation
> > complexity.
> >
> > To move the default Signet in the direction of resembling mainnet even
> > closer would be to randomly generate batches of transactions to fill
> > up blocks and create a fee market. It would be great to be able to
> > test features like RBF and Lightning unhappy paths (justice
> > transactions, perhaps even pinning attacks etc) on the default Signet
> > in future.
>
> I believe my suggestion was not correctly understood. I'm not suggesting =
*users* sign blocks or
> otherwise do anything manually here, only that the existing block produce=
rs each generate a new key,
> and we then only sign reorgs with *those* keys. Users will be able to set=
 a flag to indicate "I want
> to accept sigs from either sets of keys, and see reorgs" or "I only want =
sigs from the non-reorg
> keys, and will consider the reorg keys-signed blocks invalid"
>
> Matt



--=20
Michael Folkson
Email: michaelfolkson@gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3