public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Anthony Towns <aj@erisian.com.au>
To: Antoine Riard <antoine.riard@gmail.com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on signet
Date: Mon, 19 Sep 2022 20:05:47 +1000	[thread overview]
Message-ID: <Yyg++7tqBC9WGOzc@erisian.com.au> (raw)
In-Reply-To: <CALZpt+HksJ8BFi-8jvKJQLskSiLnm5f-QR_zmFrsgLX19R630Q@mail.gmail.com>

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



  reply	other threads:[~2022-09-19 10:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-16  7:15 [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on signet Anthony Towns
2022-09-16 16:46 ` Matt Corallo
2022-09-17  6:14   ` Anthony Towns
2022-09-17  8:39     ` Matt Corallo
2022-09-17 15:53       ` Michael Folkson
2022-09-18 12:27         ` alicexbt
2022-09-18 18:44           ` Michael Folkson
2022-09-18 18:47 ` Antoine Riard
2022-09-19 10:05   ` Anthony Towns [this message]
2022-09-28 11:48     ` Michael Folkson
2022-09-28 20:01       ` alicexbt
2022-10-02  4:06       ` Anthony Towns
2022-10-02  6:12 ` Anthony Towns
2022-10-02 15:25   ` Michael Folkson
2022-10-03 22:54     ` Anthony Towns

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yyg++7tqBC9WGOzc@erisian.com.au \
    --to=aj@erisian.com.au \
    --cc=antoine.riard@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox