path: root/5c/774124ff1f27a5fe01f998ff2e4ead91e6d066

Return-Path: <aj@erisian.com.au>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id EE7B3C002C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 05:04:01 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id C3DB4405E3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 05:04:01 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001,
 UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 6UvOAeW5f3Rg
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 05:04:00 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 5B843405BE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 21 Apr 2022 05:04:00 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
 by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
 id 1nhOyx-0000nW-1I; Thu, 21 Apr 2022 15:03:57 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
 Thu, 21 Apr 2022 15:03:51 +1000
Date: Thu, 21 Apr 2022 15:03:51 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Buck O Perley <buck.perley@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20220421050351.GA5616@erisian.com.au>
References: <cROVGM8-pKj4YzUX0QMipX3pYW6M5ps8HMrpHD9MJDey8cWBUBJSKc9tNeAJ6XOL2WVPWVwfNYI_LIAmJ4A0lLtolVIF-F1Zn2m27boTO-U=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <cROVGM8-pKj4YzUX0QMipX3pYW6M5ps8HMrpHD9MJDey8cWBUBJSKc9tNeAJ6XOL2WVPWVwfNYI_LIAmJ4A0lLtolVIF-F1Zn2m27boTO-U=@protonmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Spam-Score-int: -18
X-Spam-Bar: -
Subject: Re: [bitcoin-dev] CTV Signet Parameters
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2022 05:04:02 -0000

On Wed, Apr 20, 2022 at 05:13:19PM +0000, Buck O Perley via bitcoin-dev wro=
te:
> All merits (or lack thereof depending on your view) of CTV aside, I find =
this topic around decision making both interesting and important. While I t=
hink I sympathize with the high level concern about making sure there are u=
se cases, interest, and sufficient testing of a particular proposal before =
soft forking it into consensus code, it does feel like the attempt to attri=
bute hard numbers in this way is somewhat arbitrary.

Sure. I included the numbers for falsifiability mostly -- so people
could easily check if my analysis was way off the mark.

> For example, I think it could be reasonable to paint the list of examples=
 you provided where CTV has been used on signet in a positive light. 317 CT=
V spends =E2=80=9Cout in the wild=E2=80=9D before there=E2=80=99s a known a=
ctivation date is quite a lot

Not really? Once you can make one transaction, it's trivial to make
hundreds. It's more interesting to see if there's multiple wallets or
similar that support it; or if one wallet has a particularly compelling
use case.

> (more than taproot had afaik).

Yes; as I've said a few times now, I think we should have had more
real life demos before locking taproot's activation in. I think that
would have helped avoid bugs like Neutrino's [0] and made it easier for
hardware wallets etc to have support for taproot as soon as it was active,
without having to rush around adding library support at the last minute.

[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/0=
19589.html=20

Lightning's "two independent implementations" rule might be worth aspiring
too, eg.

> If we don=E2=80=99t think it is enough, then what number of unique spends=
 and use cases should we expect to see of a new proposal before it=E2=80=99=
s been sufficiently tested?

I don't really think that's the metric. I'd go for something more like:

 1a) can you make transactions using the new feature with bitcoin-cli,
     eg createrawtransaction etc?
 1b) can you make transactions using the new feature with some other
     library?
 1c) can you make transactions using the new feature with most common
     libraries?

 2) has anyone done a usable prototype of the major use cases of the new
    feature?

I think the answers for CTV are:

 1a) no
 1b) yes, core's python test suite, sapio
 1c) no
 2) no
=20
Though presumably jamesob's simple ctv vault is close to being an answer
for (2)?

For taproot, we had,

 1a) yes, with difficulty [1]
 1b) yes, core's python test suite; kalle's btcdeb sometimes worked too
 1c) no
 2) optech's python notebook [2] from it's taproot workshops had demos for
    musig and degrading multisig via multiple merkle paths, though I
    think they were out of date with the taproot spec for a while

[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/01=
9543.html
[2] https://github.com/bitcoinops/taproot-workshop/

To some extent those things are really proxies for:

 3) how well do people actually understand the feature?

 4) are we sure the tradeoffs being made in this implementation of the
    feature, vs other implementations or other features actually make
    sense?

 5) how useful is the feature?

I think we were pretty confident in the answers for those questions
for taproot. At least personally, I'm still not super confident in
the answers for CTV. In particular:

 - is there really any benefit to doing it as a NOP vs a taproot-only
   opcode like TXHASH? Theoretically, sure, that saves some bytes; but as
   was pointed out on #bitcoin-wizards the other day, you can't express
   those outputs as an address, which makes them not very interoperable,
   and if they're not interoperable between, say, an exchange and its
   users trying to do a withdraw, how useful is that really ever going
   to be?

 - the scriptSig commitments seems very kludgy; combining multiple
   inputs likewise seems kludgy

The continual push to rush activation of it certainly doesn't increase my
confidence either. Personally, I suspect it's counterproductive; better
to spend the time answering questions and improving the proposal, rather
than spending time going around in circles about activating something
people aren't (essentially) unanimously confident about.

> In absence of the above, the risk of a constantly moving bar=20

I'd argue the bar *should* be constantly moving, in the sense that we
should keep raising it.

> To use your meme, miners know precisely what they=E2=80=99re mining for a=
nd what a metric of success looks like which makes the risk/costs of attemp=
ting the PoW worth it=20

The difference between mining and R&D is variance: if you're competing for
50k blocks a year, you can get your actual returns to closely match your
expected return, especially if you pool with others so your probability
of success isn't miniscule -- for consensus dev, you can reasonably only
work on a couple of projects a year, so your median return is likely $0,
rather than a close match to your average/expected return.

> We also have new ideas that only started coming up after Taproot activati=
on (TLUV and Taro for example), so there=E2=80=99s also the unknown of what=
 we could have once it becomes clear that it=E2=80=99s worth devoting menta=
l energy and financial resources towards research.

TLUV was an offshoot of SCRIPTREPLACE which was public (though not
really published) since 2019.

> One last wrinkle with regards to using countable metrics to determine a f=
eature=E2=80=99s =E2=80=9Cworth=E2=80=9D is that not all features are the s=
ame. Many of the use cases that people are excited to use CTV for ([5], [6]=
) are very long term in nature and targeted for long term store of value in=
 contrast to medium of exchange.

I mean, if those use cases are so exciting, it really doesn't seem much
to ask to see them demoed live on the CTV signet that already exists?

> You can build a CTV vault in signet, but you=E2=80=99ll only really see a=
 lot of people using it when it=E2=80=99s to store real value on a time sca=
le measured in decades not minutes or days=20

On the other hand, if the value is really "very long term" and there's no
rush to implement these features and demo them ASAP, then it doesn't seem
like there should be a rush to adapt consensus to these use cases either.
Why not wait until someone does have time to finish sketching out the
use case so they can demo them in public?

> To put another way and leave CTV out of it completely, what should an out=
side, unbiased observer that doesn=E2=80=99t spend much time on Twitter exp=
ect to be able to see to evaluate the readiness or acceptability of ANYPREV=
OUT, TLUV,=20

For ANYPREVOUT, I would like to see a toy implementation of eltoo using
it, that can handle fees and layered transactions (or has a good argument
why layered transactions aren't necessary). It's going to take a while
even to update LN to taproot and PTLCs though, so eltoo doesn't seem like
it's on the immediate horizon. Besides eltoo, I don't think ANYPREVOUT
is an optimal design for covenants, so if that was the motivation and
not eltoo, maybe some other approach would be better.

TLUV's design parameters don't really seem optimal (the mess with x-only
pubkeys, alternatives like OP_EVICT), so I think it's still on the
whiteboard.

Cheers,
aj