Date: Mon, 19 Sep 2022 20:05:47 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Antoine Riard <antoine.riard@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Yyg++7tqBC9WGOzc@erisian.com.au>
References: <YyQioS3F942wu1HW@erisian.com.au>
 <CALZpt+HksJ8BFi-8jvKJQLskSiLnm5f-QR_zmFrsgLX19R630Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CALZpt+HksJ8BFi-8jvKJQLskSiLnm5f-QR_zmFrsgLX19R630Q@mail.gmail.com>
Subject: Re: [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on
	signet
Precedence: list

On Sun, Sep 18, 2022 at 02:47:38PM -0400, Antoine Riard via bitcoin-dev wrote:
> Said succinctly, in the genesis of creative ideas, evaluation doesn't
> happen at a single clear point but all along the idea lifetime, where this
> evaluation is as much done by the original author than its peers and a
> wider audience.

Sure. I definitely didn't mean to imply a waterfall development model,
or that the phases wouldn't overlap etc.

> I would still expose a concern to not downgrade in the pure empiricism in
> matter of consensus upgrades. I.e, slowly emerging the norm of a working
> prototype running on bitcoin-inquisition` as a determining factor of the
> soundness of a proposal. E.g with "upgrading lightning to support eltoo", a
> running e2e won't save us to think the thousands variants of pinnings, the
> game-theory soundness of a eltoo as mechanism in face of congestions, the
> evolvability of APO with more known upgrades proposals or the
> implementation complexity of a fully fleshed-out state machine and more
> questions.

I agree here; but I think not doing prototypes also hinders thinking
about all the thousands of details in a fork. It's easy to handwave
details away when describing things on a whiteboard; and only realise
they're trickier than you thought when you go to implement things.

> E,g if one implements the "weird" ideas
> about changes in the block reward issuance schedule discussed during the
> summer, another one might not want "noise" interferences with new
> fee-bumping primitives as the miner incentives are modified. 

(I don't think "miner incentives" are really something that can be
investigated on signet. You can assume how miners will respond to
incentives and program the mining software to act that way; but there's
no competitive pressure in signet mining so I don't think that really
demonstrates anything very much. Likewise, there's much less demand for
blockspace on signet than on mainnet, so it's probably hard to experiment
with "fee incentives" too)

> I hope the upcoming
> Contracting Primitives WG will be able to document and discuss some of the
> relevant experiments run on bitcoin-inquisition. 

Likewise.

(Lots trimmed due to either agreeing with it or having nothing to add)

Cheers,
aj