Re: [bitcoin-dev] CTV Signet Parameters

[Jeremy Rubin <jeremy.l.rubin@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 12852 bytes --]

Missed one for part 2:

Shesek's social recovery wallet using CTV to enforce timelocks without
expiry, using his Minsc toolchain:

https://twitter.com/shesek/status/1511619296367153153
https://docs.google.com/presentation/d/1B59CdMIXW-wSW6CaLSgo7y4kvgrEwVgfY14IW2XV_MA/edit#slide=id.g1235f9ffb79_0_81
https://github.com/shesek/plebfi2022-social-recovery
--
@JeremyRubin <https://twitter.com/JeremyRubin>


On Thu, Apr 21, 2022 at 1:16 AM Jeremy Rubin <jeremy.l.rubin@gmail.com>
wrote:

> Probably merits a more thorough response, but, I wanted to respond on the
> framework above:
>
>
>  1a) can you make transactions using the new feature with bitcoin-cli,
>      eg createrawtransaction etc? (*YES)*
>
> since ~Feb 2020, this has existed:
> https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify-feb1-workshop
>
> CTV hasn't changed so this code should work un-rebased. The transaction
> outputs may need to be manually submitted to the network, but the covenant
> is enforced. This covers congestion control and vaults.
>
>
>  1b) can you make transactions using the new feature with some other
>      library? *(YES)*
> Sapio, Test Framework, also https://min.sc/nextc/ produced independently
> by Shesek
>
>  1c) can you make transactions using the new feature with most common
>      libraries? *(YES, kinda)*
>
> Yes, https://crates.io/crates/sapio-miniscript and
> https://crates.io/crates/sapio-bitcoin have been maintained for about 1
> year, and are now taproot compatible.
>
> Sapio's use of these libraries has even helped find bugs in the release
> process of Taproot for rust-bitcoin.
>
> kinda: It's not _most_ common libraries, it's _a_ common library. it's
> also not upstreamed, because the patches would not be accepted were it to
> be.
>
>  2) has anyone done a usable prototype of the major use cases of the new
>     feature?* (YES)*
>
> In addition to https://github.com/jamesob/simple-ctv-vault, there is also
> https://github.com/kanzure/python-vaults, although it has an interesting
> bug.
>
> There's also a myriad of uses shown in
> https://github.com/sapio-lang/sapio/tree/master/sapio-contrib/src/contracts
> and in https://github.com/sapio-lang/sapio/tree/master/plugin-example.
> While these aren't quite "usable" as an end-to-end application, e.g.,
> something you'd want to put real money on, they are a part of a *massive*
> infrastructure investment in general purpose smart contract tooling for
> covenant design with CTV. That CTV can be targeted with a compiler to
> generate a wide variety of composable use cases *is* one of the use cases
> for CTV, since it enables people to design many different types of thing
> relatively easily. That is a feature of CTV! It's not just for one use case.
>
> The suite of Sapio apps are less "production ready" than they could be for
> a few reasons:
>
> 1) I've been working hard at pushing the limits of what is possible & the
> theory of it v.s. making it production ready
> 2) I prioritized supporting Taproot v.s. legacy script, and much of the
> taproot tooling isn't production ready
> 3) Sapio is really ambitious undertaking, and it will take time to make it
> production
>
> That said, https://rubin.io/bitcoin/2022/03/22/sapio-studio-btc-dev-mtg-6/
> tutorial was completed by people who weren't me, and at the
> pleb.fi/miami2022 one of the projects was able to use sapio congestion
> control transactions as well, so it does "work". As it matures, we'll get a
> number of implemented use cases people have been excited about like DLCs,
> which are implemented here
> https://github.com/sapio-lang/sapio/blob/master/sapio-contrib/src/contracts/derivatives/dlc.rs.
> You can see the test case shows how to construct one.
>
> Why did I not focus on production grade? Well, production grade can always
> happen later, and I don't think it takes as much imagination. But the main
> critique I'd heard of CTV was that no one could see it being used for
> anything but one or two use cases. So I built Sapio, in part, to show how
> CTV could be used for an incredibly wide and diverse set of applications,
> as opposed to the polish on them.
>
> If I knew the bar to surpass was to be polish, I probably could have taken
> a less ambitious approach with Sapio and shown like 1-2 applications
> working end-to-end. But because the main feedback I got was that CTV wasn't
> powerful enough, I opted to build a very general framework for covenants
> and demonstrate how CTV fits that.
>
>
>
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
>
> On Thu, Apr 21, 2022 at 12:05 AM Anthony Towns via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Wed, Apr 20, 2022 at 05:13:19PM +0000, Buck O Perley via bitcoin-dev
>> wrote:
>> > 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 think I sympathize with the high level concern about making sure
>> there are use cases, interest, and sufficient testing of a particular
>> proposal before soft forking it into consensus code, it does feel like the
>> attempt to attribute 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 CTV spends “out in the wild” before there’s a known activation
>> 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/019589.html
>>
>> Lightning's "two independent implementations" rule might be worth aspiring
>> too, eg.
>>
>> > If we don’t think it is enough, then what number of unique spends and
>> use cases should we expect to see of a new proposal before it’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
>>
>> 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/019543.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
>>
>> 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’re mining for and
>> what a metric of success looks like which makes the risk/costs of
>> attempting the PoW worth it
>>
>> 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
>> activation (TLUV and Taro for example), so there’s also the unknown of what
>> we could have once it becomes clear that it’s worth devoting mental 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
>> feature’s “worth” is that not all features are the same. 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’ll only really see a lot
>> of people using it when it’s to store real value on a time scale measured
>> in decades not minutes or days
>>
>> 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
>> outside, unbiased observer that doesn’t spend much time on Twitter expect
>> to be able to see to evaluate the readiness or acceptability of ANYPREVOUT,
>> TLUV,
>>
>> 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
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

[-- Attachment #2: Type: text/html, Size: 20998 bytes --]