Return-Path: <aj@erisian.com.au>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4A82DC000D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 12 Sep 2021 07:53:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 3134F827FB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 12 Sep 2021 07:53:17 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level: 
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001,
 SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001]
 autolearn=no autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id n3t-xZAUG2wU
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 12 Sep 2021 07:53:16 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 73769827F0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 12 Sep 2021 07:53:16 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
 by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
 id 1mPKIY-0005we-3I; Sun, 12 Sep 2021 17:53:12 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
 Sun, 12 Sep 2021 17:53:05 +1000
Date: Sun, 12 Sep 2021 17:53:05 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Matt Corallo <lf-lists@mattcorallo.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20210912075305.GA23673@erisian.com.au>
References: <83272afb-ed87-15b6-e02c-16bb1102beb4@gmail.com>
 <e11d718f-2bb7-335a-80dc-7d44244a0e98@mattcorallo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <e11d718f-2bb7-335a-80dc-7d44244a0e98@mattcorallo.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Spam-Score-int: -18
X-Spam-Bar: -
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: Sun, 12 Sep 2021 07:53:17 -0000

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, so if you have two different challenges, eg

  "<normal> CHECKSIG"
  "0 SWAP 1 <normal> <reorg> 2 CHECKMULTISIG"

then while both challenges will accept a signature by normal as the
block solution, the signature by "normal" will be different between the
two. This is a fairly natural result of reusing the tx-signing code for
the block signatures and not having a noinput/anyprevout tx-signing mode.

More generally, though, this would mean that a node that's opting out
of reorgs will see the to-be-reorged blocks as simply invalid due to a
bad signature, and will follow the "this node sent me an invalid block"
path in the p2p code, and start marking peers that are following reorgs
as discouraged and worth disconnecting. I think that would make it pretty
hard to avoid partitioning the network between peers that do and don't
accept reorgs, and generally be a pain.

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.

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

I guess it would be super easy to say something like:

 - miner 1 ignores blocks marked for reorg
 - miner 2 marks its blocks for reorg, mines on top of the most work
   block
 - miner 2 never mines a block which would have (height % 10 == 1)
 - miner 1 and miner 2 have the same hashrate, but mine at randomly
   different times

which would mean there's almost always a reorg being mined, people that
follow reorgs will see fewer than 1.9x as many blocks as non-reorg nodes,
and reorgs won't go on for more than 10 blocks.

Cheers,
aj