From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id B2878C000D for ; Wed, 15 Sep 2021 15:24:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 94D5881A3B for ; Wed, 15 Sep 2021 15:24:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -3.002 X-Spam-Level: X-Spam-Status: No, score=-3.002 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=mattcorallo.com 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 y8i650zoZEss for ; Wed, 15 Sep 2021 15:24:49 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from mail.as397444.net (mail.as397444.net [IPv6:2620:6e:a000:1::99]) by smtp1.osuosl.org (Postfix) with ESMTPS id 6CE8C819CC for ; Wed, 15 Sep 2021 15:24:49 +0000 (UTC) Received: by mail.as397444.net (Postfix) with ESMTPSA id 4H8kXt2p0gz12LlV; Wed, 15 Sep 2021 15:24:46 +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=1631718065; t=1631719486; bh=gNizbQt8kANTxcLGOI4BpKDVr966Cz5EqEkJstO4Xm0=; h=Subject:From:In-Reply-To:Cc:References:To:From; b=p58rS/gIjXYgLP2WyG3f2WJH+8hT67Bmlj16ypB2fbwsNN6kHcyRMZVGMg0aocPqy z7P8jYxbevGBAL0Gnp+TPwe0aRDlKMAqlUzWjaFe1EKxZ7e8ZRRyeMyHPtn6fVeU2q 5Glz3Yu7uhg0XdRSXGcm6zffovJSzXrxcn60lI3Gg9ETccNU+xyljNIPnJXWo5PKg6 gXUGntcqX1d3+jCQJwKDGLqb0EpMbd966BHBDGVUXbs8N60PfKdSvLfw1UyMvWmNdh A3QJO9cz3gNBniDucsT3KDClcCOdZIbrWbpB/q8hZ9+F9vtMwYriKkIVfxI0D3Y0uP +3maR6jgWmsdg== Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) From: Matt Corallo In-Reply-To: <20210914045610.GA25475@erisian.com.au> Date: Wed, 15 Sep 2021 08:24:43 -0700 Message-Id: <90AD5816-4B44-4BBB-A2FC-39CD381D6395@mattcorallo.com> References: <20210914045610.GA25475@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: Wed, 15 Sep 2021 15:24:50 -0000 > On Sep 13, 2021, at 21:56, Anthony Towns wrote: > I'm not sure that's really the question you want answered? Of course it is? I=E2=80=99d like to understand the initial thinking and des= ign analysis that went into this decision. That seems like an important ques= tion to ask when seeking changes in an existing system :). > Mostly > it's just "this is how mainnet works" plus "these are the smallest > changes to have blocks be chosen by a signature, rather than entirely > by PoW competition". >=20 > For integration testing across many services, I think a ten-minute-average= > between blocks still makes sense -- protocols relying on CSV/CLTV to > ensure there's a delay they can use to recover funds, if they specify > that in blocks (as lightning's to_self_delay does), then significant > surges of blocks will cause uninteresting bugs.=20 Hmm, why would blocks coming quicker lead to a bug? I certainly hope no one h= as a bug if their block time is faster than per ten minutes. I presume here,= you mean something like =E2=80=9Cif the node can=E2=80=99t keep up with the= block rate=E2=80=9D, but I certainly hope the benchmark for may isn=E2=80=99= t 10 minutes, or really even one. > It would be easy enough to change things to target an average of 2 or > 5 minutes, I suppose, but then you'd probably need to propogate that > logic back into your apps that would otherwise think 144 blocks is around > about a day. Why? One useful thing for testing is compressing real time. More broadly, th= e only issues that I=E2=80=99ve heard around block times in testnet3 are the= inconsistency and, rarely software failing to keep up at all. > We could switch back to doing blocks exactly every 10 minutes, rather > than a poisson-ish distribution in the range of 1min to 60min, but that > doesn't seem like that huge a win, and makes it hard to test that things > behave properly when blocks arrive in bursts. Hmm, I suppose? If you want to test that the upper bound doesn=E2=80=99t nee= d to be 100 minutes, though, it could be 10. > Best of luck to you then? Nobody's trying to sell you on a subscription > plan to using signet. lol, yes, I=E2=80=99m aware of that, nor did I mean to imply that anything h= as to be targeted at a specific person=E2=80=99s requirements. Rather, my po= int here is that I=E2=80=99m really confused as to who the target user *is*= , because we should be building products with target users in mind, even if t= hose targets are often =E2=80=9Cme=E2=80=9D for open source projects.=