From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id ADCC7C000D for ; Mon, 13 Sep 2021 05:33:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 8940860821 for ; Mon, 13 Sep 2021 05:33:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.401 X-Spam-Level: X-Spam-Status: No, score=-4.401 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-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=mattcorallo.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 UdOfe9XNyKVg for ; Mon, 13 Sep 2021 05:33:31 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from mail.as397444.net (mail.as397444.net [69.59.18.99]) by smtp3.osuosl.org (Postfix) with ESMTPS id 9FA76607AB for ; Mon, 13 Sep 2021 05:33:31 +0000 (UTC) Received: by mail.as397444.net (Postfix) with ESMTPSA id 4H7FWW01Plz12B0k; Mon, 13 Sep 2021 05:33:26 +0000 (UTC) X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattcorallo.com; s=1631509264; t=1631511207; bh=hQ/ceGnwCG83YLtuvwBafj+kg8WZ+rWY6Y5Vm4P90ik=; h=From:Subject:References:Cc:In-Reply-To:To:From; b=Ma1afiRYf+kaVfHyC9KkIQbJY2xLq7N5Vbw5LCCXcqnXpQo3m0C/qhiwyx8QDnUnZ /gcyKO4yNw/a+tAlSaQFtyum1v65eJS9+4mDL9hArnuzwBiIKLPA+idojtk8dhWUIK 0UPIP4VJfuNVCTQBE3YbBhHEluZEecOF8C/YHMCXX+nnIf3lvd4sF1abqiLzvLZRH6 9zdoTkcJ9KvKHCohTl54Fc5rnzdfFZ22406IzezghDrvbdd+mMidD+riaPZv3JDkrX hUEH69pOoRBAfKtMhY/d+ZFO0UJHuCb8rPiaWJDcqyRTW3yjO7dbAZmdna4lc96jnJ aLUaAkFyWGX+w== Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Matt Corallo Mime-Version: 1.0 (1.0) Date: Sun, 12 Sep 2021 22:33:24 -0700 Message-Id: <571244AD-B8F4-4F2A-BF4B-31EED3AB7713@mattcorallo.com> References: <20210912075305.GA23673@erisian.com.au> In-Reply-To: <20210912075305.GA23673@erisian.com.au> To: Anthony Towns Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2021 05:33:32 -0000 > On Sep 12, 2021, at 00:53, Anthony Towns wrote: >=20 > =EF=BB=BFOn Thu, Sep 09, 2021 at 05:50:08PM -0700, Matt Corallo via bitcoi= n-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 launche= d >> to just have a different reorg signing key. >=20 > 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, But if that was the originally proposal, why is the challenge committed to i= n the block? :) > 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. Sure, you could set that for invalid block signatures as well though. It=E2=80= =99s not really a material DoS protection one way or the other. >>> 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 ofte= n >> as is practical. If users opt in to wanting to test with reorgs, they sho= uld >> be able to test with reorgs, not wait a day to test with reorgs. >=20 > 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. Can you explain the motivation for this? =46rom where I sit, as far as I kno= w, I should basically be a prime example of the target market for public sig= net - someone developing bitcoin applications with regular requirements to t= est those applications with other developers without jumping through hoops t= o configure software the same across the globe and set up miners. With block= s being slow and irregular, I=E2=80=99m basically not benefited at all by si= gnet and will stick with testnet3/mainnet testing, which both suck.=