public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "David A. Harding" <dave@dtrt.org>
To: Matt Corallo <lf-lists@mattcorallo.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV
Date: Thu, 21 Apr 2022 12:28:17 -1000	[thread overview]
Message-ID: <4056eca7e1ff018bff03918b8c266d76@dtrt.org> (raw)
In-Reply-To: <c779648c-891d-b920-f85f-c617a0448997@mattcorallo.com>

On 21.04.2022 08:39, Matt Corallo wrote:
> We add things to Bitcoin because (a) there's some demonstrated
> use-cases and intent to use the change (which I think we definitely
> have for covenants, but which only barely, if at all, suggests
> favoring one covenant design over any other)

I'm unconvinced about CTV's use cases but others have made reasonable 
claims that it will be used.  We could argue about this indefinitely, 
but I would love to give CTV proponents an opportunity to prove that a 
significant number of people would use it.

> (b) because its
> generally considered aligned with Bitcoin's design and goals, based on
> developer and more broad community response

I think CTV fulfills this criteria.  At least, I can't think of any way 
BIP119 itself (notwithstanding activation concerns) violates Bitcoin's 
designs and goals.

> (c) because the
> technical folks who have/are wiling to spend time working on the
> specific design space think the concrete proposal is the best design
> we have

This is the criteria that most concerns me.  What if there is no 
universal best?  For example, I mentioned in my previous email that I'm 
a partisan of OP_CAT+OP_CSFS due to their min-max of implementation 
simplicity versus production flexibility.  But one problem is that 
spends using them would need to contain a lot of witness data.  In my 
mind, they're the best for experimentation and for proving the existence 
of demand for more optimized constructions.

OP_TX or OP_TXHASH would likely offer almost as much simplicity and 
flexibility but be more efficient onchain.  Does that make them better 
than OP_CAT+OP_CSFS?  I don't know how to objectively answer that 
question, and I don't feel comfortable with my subjective opinion of 
CAT+CSFS being better than OP_TX.

APO/IIDs, CTV, and TLUV/EVICT all seem to me to be very specific to 
certain usecases (respectively: Eltoo, congestion control, and 
joinpools), providing maximum onchain efficiency for those cases but 
requiring contortions or larger witnesses to accomplish other covenant 
usecases.  Is their increased efficiency better than more general 
constructions like CSFS or TX?  Again, I don't know how to answer that 
question objectively, although subjectively I'm ok with optimized 
constructions for cases of proven demand.

> , and finally (d) because the implementation is well-reviewed
> and complete.

No comment here; I haven't followed CTV's review progress to know 
whether I'd consider it well enough reviewed or not.

> I do not see how we can make an argument for any specific covenant
> under (c) here. We could just as well be talking about
> TLUV/CAT+CHECKSIGFROMSTACK/etc, and nearly anyone who is going to use
> CTV can probably just as easily use those instead - ie this has
> nothing to do with "will people use it".

I'm curious how we as a technical community will be able to determine 
which is the best approach.  Again, I like starting simple and general, 
gathering real usage data, and then optimizing for demonstrated needs.  
But the simplest and most general approaches seem to be too general for 
some people (because they enable recursive covenants), seemingly forcing 
us into looking only at application-optimized designs.  In that case, I 
think the main thing we want to know about these narrow proposals for 
new applications is whether the applications and the proposed consensus 
changes will actually receive significant use.  For that, I think we 
need some sort of test bed with real paying users, and ideally one that 
is as similar to Bitcoin mainnet as possible.

> we
> cannot remove the validation code for something ever, really - you
> still want to be able to validate the historical chain

You and Jeremy both brought up this point.  I understand it and I 
should've addressed it better in my OP, but I'm of the opinion that 
reverting to earlier consensus rules gives future developers the 
*option* of dropping no-longer-used consensus code as a practical 
simplification of the same type we've used on several occasions before, 
and which is an optional default in newly started Bitcoin Core nodes for 
over a decade now (i.e. skipping verification of old signatures).  If 
future devs *want* to maintain code from a set of temporary rules used 
millions of blocks ago, that's great, but giving them the option to 
forget about those rules eliminates one of my concerns about making 
consensus changes without fully proven demand for that change.

I just wanted to mention the above in case this discussion comes back to 
serious consideration of a transitory soft fork.  For now, I think we 
can table a debate over validating reverted rules and focus on how we'll 
come to agreement that a particular covenant-related consensus change is 
warranted.

Thanks for your thoughtful response,

-Dave


  reply	other threads:[~2022-04-21 22:28 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-21  1:04 [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV David A. Harding
2022-04-21  2:05 ` Luke Dashjr
2022-04-21  3:10   ` alicexbt
2022-04-21  5:56     ` Luke Dashjr
2022-04-21  6:20       ` Jeremy Rubin
2022-04-21  6:37         ` Luke Dashjr
2022-04-21 13:10           ` Jeremy Rubin
2022-04-24 15:22     ` Peter Todd
2022-04-21 14:58 ` Matt Corallo
2022-04-21 18:06   ` David A. Harding
2022-04-21 18:39     ` Matt Corallo
2022-04-21 22:28       ` David A. Harding [this message]
2022-04-21 23:02         ` Matt Corallo
2022-04-22  1:20           ` David A. Harding
2022-04-22 18:40             ` Matt Corallo
2022-04-22 18:49               ` Corey Haddad
2022-04-22 16:48         ` James O'Beirne
2022-04-22 17:06           ` James O'Beirne
2022-04-22 16:28       ` James O'Beirne
2022-04-22 17:25         ` [bitcoin-dev] Vaulting (Was: Automatically reverting ("transitory") soft forks) Russell O'Connor
2022-04-23  4:56           ` Billy Tetrud
2022-04-23 14:02             ` Russell O'Connor
2022-04-23 18:24           ` Matt Corallo
2022-04-23 19:30             ` Russell O'Connor
2022-04-24 23:03               ` Billy Tetrud
2022-04-25 17:27                 ` Nadav Ivgi
2022-04-25 22:27                 ` Russell O'Connor
2022-04-27  1:52                   ` Billy Tetrud
2022-04-28 23:14                     ` Nadav Ivgi
2022-04-28 23:51                       ` Billy Tetrud
2022-04-22 18:35         ` [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV Matt Corallo
2022-04-21 19:08 ` Jeremy Rubin
2022-04-22  0:28 ` Anthony Towns
2022-04-22  1:44   ` David A. Harding
2022-04-22 19:57 ` Antoine Riard
2022-04-25  5:12 ` ZmnSCPxj
2022-04-22 19:05 alicexbt

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=4056eca7e1ff018bff03918b8c266d76@dtrt.org \
    --to=dave@dtrt.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=lf-lists@mattcorallo.com \
    /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