Re: [bitcoin-dev] CTV Signet Parameters

Re: [bitcoin-dev] CTV Signet Parameters

[Buck O Perley]

[-- Attachment #1.1.1: Type: text/plain, Size: 10396 bytes --]

Hi AJ,
Long time listener first time caller here.
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.
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 (more than taproot had afaik). 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?
Perhaps this is simply a case of the Justice Stewart view on pornography where “you know it when you see it”[1], but then if that’s the case than it really doesn’t seem productive to use these numbers to evaluate the readiness and eagerness to use CTV since they are effectively arbitrary and could be used to make the argument in either direction.
So perhaps it just *felt* like there was more need and ready-to-use applications of taproot, and perhaps this feeling is broadly shared and that’s fine, and it doesn’t *feel* that way for CTV, but by the measures you laid out were there as many uses in the wild of taproot spends before it was brought to Speedy Trial? As far as I’m aware there seemed to be more broken [2], premature Taproot spends then actual practical uses of it on a test network before it was fully activated (I might be wrong about this though). Meanwhile the primary tooling necessary to really make it useful (PTLCs, Musig2, FROST) weren’t even fully specced out yet let alone actively being used on a test network and the list of proposed applications on the bitcoin wiki [3] (last updated April 2021) is similarly sparse and not quite up to the standards you’ve set for CTV to be the next soft fork (this is to say nothing of the fact that many prefer to develop, build, and test on regtest than signet at this stage).
Maybe this is similarly an argument for Taproot being activated too early and that may be a fair argument (not one I share to be clear). If that’s the case, I think it’s reasonable to put all cards on the table and we should be explicit that Taproot activation was premature for [X] reasons, here’s the new standard we want to have new proposals hit (a signet, expected level of activity, etc.). Then whether it’s CTV or TLUV or ANYPREVOUT, that’s what we as a community, the developers maintaining the proposals, and the developers/companies that plan to build on top of the new proposal should strive to achieve.
In absence of the above, the risk of a constantly moving bar means the possibility of either insufficiently reviewed proposals getting activated because we’re complacent and just placing trust in a small cadre of experts (nothing malicious in this, just seems worth avoiding) or personal and subjective reasoning allowing for premature ossification and blocking of upgrades that could otherwise be considered safe, useful, and perhaps even necessary on a long enough time horizon.
There’s also the other risk which you point out:

> One challenge with building a soft fork is that people don't want tocommit to spending time building something that relies on consensusfeatures and run the risk that they might never get deployed. But thereverse of that is also a concern: you don't want to deploy consensuschanges and run the risk that they won't actually turn out to be useful.


Perhaps if we had clear metrics of what would make the work worth it, if we knew what we were working towards, we’d be more likely to get that proof of work. 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 (or conversely sometimes resulting the decision for miners to be decommissioned). In addition to the examples listed above, even Taproot which most agree had relatively broad consensus didn’t have much work happening on top of it until it was activated. Suredbits as far as I’m aware didn’t want to build DLCs on top of lightning until taproot AND PTLCs were in use (in contrast we already have a DLC implementation that uses CTV[4]). 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.
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. Metrics for measuring value of a store of value upgrade are fundamentally different than those measuring value of MoE. It’s like people pointing to transaction volume on other cryptocurrency systems to show that their chain is more valuable. 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 like you might find for lightning testing and experimentation. This doesn’t make one more or less desirable or valuable imo, just that the evaluation metrics should be treated totally differently.
Anyway, I guess that’s a (very) long way of saying, are these constructive ways to evaluate an upgrade and if they are can we maybe have an idea of what a success vs. a failure metric looks like (and in the interest of retrospection and iterative improvement, it would be useful to know if in retrospect Taproot didn’t reach these metrics and maybe was activated prematurely as a result). 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, or any other possible future soft forks? If nothing else, nailing this down would seem to help make the lives of key bitcoin core maintainers much easier by removing politics from decisions that should otherwise be as technical in nature as possible.
[1](http://cbldf.org/about-us/case-files/obscenity-case-files/obscenity-case-files-jacobellis-v-ohio-i-know-it-when-i-see-it/)
[2](https://suredbits.com/taproot-funds-burned-on-the-bitcoin-blockchain/)
[3](https://en.bitcoin.it/wiki/Taproot_Uses)
[4](https://github.com/sapio-lang/sapio/blob/master/sapio-contrib/src/contracts/derivatives/dlc.rs)
[5](https://github.com/kanzure/python-vaults/blob/master/vaults/bip119_ctv.py)
[6](https://github.com/jamesob/simple-ctv-vault)


> On Thu, Feb 17, 2022 at 01:58:38PM -0800, Jeremy Rubin via bitcoin-dev wrote:AJ Wrote (in another thread): I'd much rather see some real third-party experimentation *somewhere* public first, and Jeremy's CTV signet being completely empty seems like a bad sign to me.
> There's now been some 2,200 txs on CTV signet, of which (if I haven'tmissed anything) 317 have been CTV spends:
> - none have been bare CTV (ie, CTV in scriptPubKey directly, not via  p2sh/p2wsh/taproot)
> - none have been via p2sh
> - 3 have been via taproot:  https://explorer.ctvsignet.com/tx/f73f4671c6ee2bdc8da597f843b2291ca539722a168e8f6b68143b8c157bee20  https://explorer.ctvsignet.com/tx/7e4ade977db94117f2d7a71541d87724ccdad91fa710264206bb87ae1314c796  https://explorer.ctvsignet.com/tx/e05d828bf716effc65b00ae8b826213706c216b930aff194f1fb2fca045f7f11
>   The first two of these had alternative merkle paths, the last didn't.
> - 314 have been via p2wsh  https://explorer.ctvsignet.com/tx/62292138c2f55713c3c161bd7ab36c7212362b648cf3f054315853a081f5808e  (don't think there's any meaningfully different examples?)
> As far as I can see, all the scripts take the form:
>  [PUSH 32 bytes] [OP_NOP4] [OP_DROP] [OP_1]
> (I didn't think DROP/1 is necessary here? Doesn't leaving the 32 bytehash on the stack evaluate as true? I guess that means everyone's usingsapio to construct the txs?)
> I don't think there's any demos of jamesob's simple-ctv-vault [0], whichI think uses a p2wsh of "IF n CSV DROP hotkey CHECKSIG ELSE lockcoldtx CTVENDIF", rather than taproot branches.
> [0] https://github.com/jamesob/simple-ctv-vault
> Likewise I don't think there's any examples of "this CTV immediately;or if fees are too high, this other CTV that pays more fees after Xdays", though potentially they could be hidden in the untaken taprootmerkle branches.
> I don't think there's any examples of two CTV outputs being combinedand spent in a single transaction.
> I don't see any txs with nSequence set meaningfully; though most (all?)of the CTV spends seem to set nSequence to 0x00400000 which I thinkdoesn't have a different effect from 0xfffffffe?
> That looks to me like there's still not much practical (vs theoretical)exploration of CTV going on; but perhaps it's an indication that CTVcould be substantially simplified and still get all the benefits thatpeople are particularly eager for.
> I am unsure that "learning in public" is required --
> For a consensus system, part of the learning is "this doesn't seem thatinteresting to me; is it actually valuable enough to others that thechange is worth the risk it imposes on me?" and that's not somethingyou can do purely in private.
> One challenge with building a soft fork is that people don't want tocommit to spending time building something that relies on consensusfeatures and run the risk that they might never get deployed. But thereverse of that is also a concern: you don't want to deploy consensuschanges and run the risk that they won't actually turn out to be useful.
> Or, perhaps, to "meme-ify" it -- part of the "proof of work" for deployinga consensus change is actually proving that it's going to be useful.Like sha256 hashing, that does require real work, and it might turn outto be wasteful.
> Cheers,

[-- Attachment #1.1.2.1: Type: text/html, Size: 22450 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

Re: [bitcoin-dev] CTV Signet Parameters

[Anthony Towns]

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

Re: [bitcoin-dev] CTV Signet Parameters

[Jeremy Rubin]

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

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: 18994 bytes --]

Re: [bitcoin-dev] CTV Signet Parameters

[Jeremy Rubin]

[-- 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 --]

Re: [bitcoin-dev] CTV Signet Parameters

[Russell O'Connor]

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

On Thu, Apr 21, 2022 at 1:04 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>  - 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?
>

FWIW, this is also approximately where my sticking point lies with BIP-119.

Overall I've come around to the idea of something like CTV.  The ability to
construct "smart contracts" that commit to *multiple* possible payout
schemes based on some conditions seems like a very useful construct, and
there have been several examples of  schemes proposed that use this feature.

However, I'm still skeptical of the bare-CTV part of BIP-119 (and I'm told
that bare-CTV hasn't even appeared on the CTV signet).  Unlike the general
smart-contracting case, bare-CTV does not have any branches.  All it can do
is commit to a subsequent transaction's outputs.  At first glance this
appears to be a waste because, for less bandwidth, that transaction could
just realize those outputs immediately, so why would anyone want to delay
the inevitable?

One reason might be that you want to commit to the output early during a
high-fee time, and then complete the transaction later during a low-fee
time.  While there are fee-rate situations where this could result in lower
fees than committing to the outputs all at once, it would be even cheaper
still to just wait to do the payout at the low-fee time.  I'm struggling to
understand the advantages of the advanced commitment, along with all the
overhead that entails.  Doesn't it just cause more blockspace to be used
overall?

There are some other proposed use cases for bare-CTV.  A bare-CTV can be
used to delay a "trigger"-transaction.  Some contracts, such as vaults, use
a relative-locktime as part of their construction and it could make sense
to make an output commitment but not realize those outputs yet until you
are ready to start your relative-time lock clock.  But bare-CTV doesn't
support any co-signing ability here, so you are relying entirely on keeping
the transaction data secret to prevent a third-party from triggering your
relative-lock clock.  More specifically for a vault scheme, since
bare-CTV's are currently unaddressable, and AFAIK, there is no address
format proposal yet, it is impossible to receive funds directly into a
vault.  You must shuffle received funds into your vault yourself, which
seems very likely to negate the cost savings of using bare-CTV in the first
place (please correct me if I'm wrong).  Better to receive funds directly
into a taproot-CTV vault, which has an address, and while you are at it,
you could place the cold-key as the taproot key to save even more when
using the cold-key to move vault funds.

There might be even more exotic use cases of bare-CTV.  For example you
could commit to a transaction that has a second input that doesn't yet
exist in the UTXO set in an attempt to coax it into existence. I don't know
if there have been any proposals to take advantage of this.

With that said, everything that bare-CTV can do, can also be done by
tapscript-CTV; so it is just a matter of cost.  I'm struggling to
understand where this cost savings is and how much those savings are going
to be given that bare-CTV is unaddressable and seems to ultimately occupy
more-blockspace than if the outputs were directly committed to.

I also believe the bare-CTV question is material, because if bare-CTV were
not part of the spec, then I'd be advocating for using an OP_SUCCESS code
from tapscript instead, and either use push-style semantics for CTV, which
would be composed with EQUAL_VERIFY to mimic the currently proposed
verification style-semantics, or a hybrid push-or-verify semantics that
would either push or verify depending on the size of the input.  (And I
still think a more general TXHASH would be even better, though if I cannot
convince aj then perhaps I'm wrong.)

I'm not saying bare-CTV is necessarily a bad idea.  I'm just struggling
with its justification.

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

Re: [bitcoin-dev] CTV Signet Parameters

[Jeremy Rubin]

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

Hi Russell,

Thank you for your feedback here.



> However, I'm still skeptical of the bare-CTV part of BIP-119 (and I'm told
> that bare-CTV hasn't even appeared on the CTV signet).  Unlike the general
> smart-contracting case, bare-CTV does not have any branches.  All it can do
> is commit to a subsequent transaction's outputs.  At first glance this
> appears to be a waste because, for less bandwidth, that transaction could
> just realize those outputs immediately, so why would anyone want to delay
> the inevitable?
>

I can probably make some show up sometime soon. Note that James' vault uses
one at the top-level https://github.com/jamesob/simple-ctv-vault, but I
think the second use of it (since it's not segwit wrapped) wouldn't be
broadcastable since it's nonstandard.




>
> One reason might be that you want to commit to the output early during a
> high-fee time, and then complete the transaction later during a low-fee
> time.  While there are fee-rate situations where this could result in lower
> fees than committing to the outputs all at once, it would be even cheaper
> still to just wait to do the payout at the low-fee time.  I'm struggling to
> understand the advantages of the advanced commitment, along with all the
> overhead that entails.  Doesn't it just cause more blockspace to be used
> overall?
>

One case where you actually use less space is if you have a few different
sets of customers at N different fee priority level. Then, you might need
to have N independent batches, or risk overpaying against the customer's
priority level. Imagine I have 100 tier 1 customers and 1000 tier 2
customers. If I batcher tier 1 with tier 2, to provide tier 1 guarantees
I'd need to pay tier 1 rate for 10x the customers. With CTV, I can combine
my batch into a root and N batch outputs. This eliminates the need for
inputs, signatures, change outputs, etc per batch, and can be slightly
smaller. Since the marginal benefit on that is still pretty small, having
bare CTV improves the margin of byte wise saving.

I give this as an example where CTV uses less space, it is detailed more
here: https://utxos.org/analysis/batching_sim/. This benefit might be
marginal and absurd, given these are already big transactions, but it may
_also_ be absurd that feerates only ever go up and congestion control is
not valuable.

Another example where this arises is where you have a transaction set you
need to pay top-of-mempool rate for the soonest confirmation you can get.
CTV has a decongesting effect, because your top-of-mempool transaction is
small, which doesn't trigger as much rivalrous behavior with other
transactors. Concretely, the current policy max txn size is 100kb, or 10%
of a block. If you bump out of next block window 10% of the mempool, then
if those transactors care to maintain their positioning, they will need to
put themselves into a higher percentile with e.g. RBF or CPFP. Whereas if
you put in a transaction that is just 100 bytes, you only bump out 100
bytes of rivals (0.01%), not 10%.

Lastly, perhaps a more realistic scenario, is where I am batching to 100
customers who all wish to do something else after I pay them. E.g., open a
lightning channel. Being able to use CTV noninteractive channels cuts
through the extra hop transaction (unless dual funded channels, unless the
channels are opened between two customers, then they can be dual funded
again). So using CTV here also saves in net blockspace (although, note,
this is sort of orthogonal to using CTV over the batch itself, just a good
example for the related question of 'doesn't ctv generally use more
blockspace').


> There are some other proposed use cases for bare-CTV.  A bare-CTV can be
> used to delay a "trigger"-transaction.  Some contracts, such as vaults, use
> a relative-locktime as part of their construction and it could make sense
> to make an output commitment but not realize those outputs yet until you
> are ready to start your relative-time lock clock.  But bare-CTV doesn't
> support any co-signing ability here, so you are relying entirely on keeping
> the transaction data secret to prevent a third-party from triggering your
> relative-lock clock.  More specifically for a vault scheme, since
> bare-CTV's are currently unaddressable, and AFAIK, there is no address
> format proposal yet, it is impossible to receive funds directly into a
> vault.  You must shuffle received funds into your vault yourself, which
> seems very likely to negate the cost savings of using bare-CTV in the first
> place (please correct me if I'm wrong).  Better to receive funds directly
> into a taproot-CTV vault, which has an address, and while you are at it,
> you could place the cold-key as the taproot key to save even more when
> using the cold-key to move vault funds.
>
>
This is not quite true, you can receive funds into a bare-CTV from your
vault software, and you can send into one from your vault software. What
doesn't work is exporting or creating an address for that. As a reminder
for those following along at home, not all standard output types have
addresses, even today. For example, OP_RETURN.

However, this is a standarness question. If the market _wanted_ such an
address, one could be adopted without requiring consensus processes.

Generally, the vault designs I work on use Sapio and therefore also use
Taproot since I have not added support for non-taproot scripts / removed
support for witness v0. I will eventually add these back, but it's a
marginal fee savings optimization and I'm focused primarily on feature
completeness.


> There might be even more exotic use cases of bare-CTV.  For example you
> could commit to a transaction that has a second input that doesn't yet
> exist in the UTXO set in an attempt to coax it into existence. I don't know
> if there have been any proposals to take advantage of this.
>

There are, but it's not specific to how bare ctv works, it should work from
any CTV context.

>
> With that said, everything that bare-CTV can do, can also be done by
> tapscript-CTV; so it is just a matter of cost.  I'm struggling to
> understand where this cost savings is and how much those savings are going
> to be given that bare-CTV is unaddressable and seems to ultimately occupy
> more-blockspace than if the outputs were directly committed to.
>
> I also believe the bare-CTV question is material, because if bare-CTV were
> not part of the spec, then I'd be advocating for using an OP_SUCCESS code
> from tapscript instead, and either use push-style semantics for CTV, which
> would be composed with EQUAL_VERIFY to mimic the currently proposed
> verification style-semantics, or a hybrid push-or-verify semantics that
> would either push or verify depending on the size of the input.  (And I
> still think a more general TXHASH would be even better, though if I cannot
> convince aj then perhaps I'm wrong.)
>

Even if we got rid of bare ctv, segwit v0 CTV would still exist, so we
couldn't use OP_SUCCESSx there either. segwitv0 might be desired if someone
has e.g. hardware modules or MPC Threshold Crypto that only support ECDSA
signatures, but still want CTV.

>
> I'm not saying bare-CTV is necessarily a bad idea.  I'm just struggling
> with its justification.
>


Fair. I wouldn't have a big problem removing it, if it were clear that were
it to become desired, we could add it back. I think the case for CTV in
Segwitv0 is stronger, which has the same implication for a PUSH variant of
CTV.


Thanks again,

Jeremy



> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] CTV Signet Parameters

[Anthony Towns]

On Thu, Apr 21, 2022 at 10:05:20AM -0500, Jeremy Rubin via bitcoin-dev wrote:
> I can probably make some show up sometime soon. Note that James' vault uses
> one at the top-level https://github.com/jamesob/simple-ctv-vault, but I
> think the second use of it (since it's not segwit wrapped) wouldn't be
> broadcastable since it's nonstandard.

The whole point of testing is so that bugs like "wouldn't be broadcastable
since it's nonstandard" get fixed. If these things are still in the
"interesting thought experiment" stage, but nobody but Jeremy is
interested enough to start making them consistent with the proposed
consensus and policy rules, it seems very premature to be changing
consensus or policy rules.

> One case where you actually use less space is if you have a few different
> sets of customers at N different fee priority level. Then, you might need
> to have N independent batches, or risk overpaying against the customer's
> priority level. Imagine I have 100 tier 1 customers and 1000 tier 2
> customers. If I batcher tier 1 with tier 2, to provide tier 1 guarantees
> I'd need to pay tier 1 rate for 10x the customers. With CTV, I can combine
> my batch into a root and N batch outputs. This eliminates the need for
> inputs, signatures, change outputs, etc per batch, and can be slightly
> smaller. Since the marginal benefit on that is still pretty small, having
> bare CTV improves the margin of byte wise saving.

Bare CTV only saves bytes when *spending* -- but this is when you're
creating the 1100 outputs, so an extra 34 or 67 bytes of witness data
seems fairly immaterial (0.05% extra vbytes?). It doesn't make the small
commitment tx any smaller.

ie, scriptPubKey looks like:
 - bare ctv: [push][32 bytes][op_nop4]
 - p2wsh: [op_0][push][32 bytes]
 - p2tr: [op_1][push][32 bytes]

while witness data looks like:
 - bare ctv: empty scriptSig, no witness
 - pw2sh: empty scriptSig, witness = "[push][32 bytes][op_nop4]"
 - p2tr: empty scriptSig, witness = 33B control block,
         "[push][32 bytes][op_nop4]"

You might get more a benefit from bare ctv if you don't pay all 1100
outputs in a single tx when fees go lower; but if so, you're also wasting
quite a bit more block space in that case due to the intermediate
transactions you're introducing, which makes it seem unlikely that
you care about the extra 9 or 17 vbytes bare CTV would save you per
intermediate tx...

I admit that I am inclined towards micro-optimising things to save
those bytes if it's easy, which does incline me towards bare CTV; but
the closest thing we have to real user data suggests that nobody's going
to benefit from that possibility anyway.

> Even if we got rid of bare ctv, segwit v0 CTV would still exist, so we
> couldn't use OP_SUCCESSx there either. segwitv0 might be desired if someone
> has e.g. hardware modules or MPC Threshold Crypto that only support ECDSA
> signatures, but still want CTV.

If you desire new features, then you might have to upgrade old hardware
that can't support them.

Otherwise that would be an argument to never use OP_SUCCESSx: someone
might want to use whatever new feature we might imagine on hardware that
only supports ECDSA signatures.

Cheers,
aj

Re: [bitcoin-dev] CTV Signet Parameters

[Nadav Ivgi]

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

> nobody's going to benefit from that possibility anyway.

 James O'Beirne's simple-ctv-vault appears to be using bare CTV outputs:

https://github.com/jamesob/simple-ctv-vault/blob/7dd6c4ca25debb2140cdefb79b302c65d1b24937/main.py#L217-L218
https://github.com/jamesob/simple-ctv-vault/blob/7dd6c4ca25debb2140cdefb79b302c65d1b24937/main.py#L324-L325

I guess this suggests that it was not tested on signet?

On Fri, Apr 22, 2022 at 3:58 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Apr 21, 2022 at 10:05:20AM -0500, Jeremy Rubin via bitcoin-dev
> wrote:
> > I can probably make some show up sometime soon. Note that James' vault
> uses
> > one at the top-level https://github.com/jamesob/simple-ctv-vault, but I
> > think the second use of it (since it's not segwit wrapped) wouldn't be
> > broadcastable since it's nonstandard.
>
> The whole point of testing is so that bugs like "wouldn't be broadcastable
> since it's nonstandard" get fixed. If these things are still in the
> "interesting thought experiment" stage, but nobody but Jeremy is
> interested enough to start making them consistent with the proposed
> consensus and policy rules, it seems very premature to be changing
> consensus or policy rules.
>
> > One case where you actually use less space is if you have a few different
> > sets of customers at N different fee priority level. Then, you might need
> > to have N independent batches, or risk overpaying against the customer's
> > priority level. Imagine I have 100 tier 1 customers and 1000 tier 2
> > customers. If I batcher tier 1 with tier 2, to provide tier 1 guarantees
> > I'd need to pay tier 1 rate for 10x the customers. With CTV, I can
> combine
> > my batch into a root and N batch outputs. This eliminates the need for
> > inputs, signatures, change outputs, etc per batch, and can be slightly
> > smaller. Since the marginal benefit on that is still pretty small, having
> > bare CTV improves the margin of byte wise saving.
>
> Bare CTV only saves bytes when *spending* -- but this is when you're
> creating the 1100 outputs, so an extra 34 or 67 bytes of witness data
> seems fairly immaterial (0.05% extra vbytes?). It doesn't make the small
> commitment tx any smaller.
>
> ie, scriptPubKey looks like:
>  - bare ctv: [push][32 bytes][op_nop4]
>  - p2wsh: [op_0][push][32 bytes]
>  - p2tr: [op_1][push][32 bytes]
>
> while witness data looks like:
>  - bare ctv: empty scriptSig, no witness
>  - pw2sh: empty scriptSig, witness = "[push][32 bytes][op_nop4]"
>  - p2tr: empty scriptSig, witness = 33B control block,
>          "[push][32 bytes][op_nop4]"
>
> You might get more a benefit from bare ctv if you don't pay all 1100
> outputs in a single tx when fees go lower; but if so, you're also wasting
> quite a bit more block space in that case due to the intermediate
> transactions you're introducing, which makes it seem unlikely that
> you care about the extra 9 or 17 vbytes bare CTV would save you per
> intermediate tx...
>
> I admit that I am inclined towards micro-optimising things to save
> those bytes if it's easy, which does incline me towards bare CTV; but
> the closest thing we have to real user data suggests that nobody's going
> to benefit from that possibility anyway.
>
> > Even if we got rid of bare ctv, segwit v0 CTV would still exist, so we
> > couldn't use OP_SUCCESSx there either. segwitv0 might be desired if
> someone
> > has e.g. hardware modules or MPC Threshold Crypto that only support ECDSA
> > signatures, but still want CTV.
>
> If you desire new features, then you might have to upgrade old hardware
> that can't support them.
>
> Otherwise that would be an argument to never use OP_SUCCESSx: someone
> might want to use whatever new feature we might imagine on hardware that
> only supports ECDSA signatures.
>
> 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: 5541 bytes --]

Re: [bitcoin-dev] CTV Signet Parameters

[Jeremy Rubin]

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

small note, it's a savings of 34 or 67 bytes *per histogram bucket* to have
bare CTV v.s. v0/v1, so the interesting thing is that by making it cheaper
bytes wise it might enable one to have, for the same byte budget, more
buckets, which would make the feerate savings for the user even greater.
E.g., assume user priorities are exponential, like:

[10, 12, 14, 17, 20, 24, 29, 35, 42, 51]

suppose binning into 4 groups yields:

[10, 12, 14], [17, 20, 24], [29, 35, 42], [51]
then the feerate of each group summarized by the max times bin count is
[14 x 3], [24 x 3], [42 x 3], [51 x 1] =

291

suppose binning into 5 groups yields:

[10, 12], [14, 17], [20, 24], [29, 35], [42, 51]
[12 x 2] [17 x 2] [24 x 2] [35 x 2] [51x2] =

278

so it's clear that bins of 5 yields a discount, and the marginal cost
difference of 5 bins vs 4 can be more than "paid for" by switching to bare
instead of segwit v0.

E.g., 4 segwits = 4*34 additional
5 bares = 1 extra output (34 bytes) + 1 extra input (41 bytes) + extra tx
body (~10 bytes?) = ~2.5 x 34 additional weight

so while in this particular case, the savings mean that 4 would likely be a
better binning than 5 even if bare were available, if you imagine the
groups scaled to more elements under the same distribution would have
eventually the cost (291-278)*S > 2.5*34  make it worth switching the
binning to 5 bins earlier than with would if the bins were more expensive.

Kinda hard to perfectly characterize this type of knock-on effect, but it's
also cool to think about how cheapness of the nodes in the graph changes
the optimal graph, which means you can't just do a simple comparison of how
much is a bigger than b.





On Thu, Apr 21, 2022 at 7:58 PM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Apr 21, 2022 at 10:05:20AM -0500, Jeremy Rubin via bitcoin-dev
> wrote:
> > I can probably make some show up sometime soon. Note that James' vault
> uses
> > one at the top-level https://github.com/jamesob/simple-ctv-vault, but I
> > think the second use of it (since it's not segwit wrapped) wouldn't be
> > broadcastable since it's nonstandard.
>
> The whole point of testing is so that bugs like "wouldn't be broadcastable
> since it's nonstandard" get fixed. If these things are still in the
> "interesting thought experiment" stage, but nobody but Jeremy is
> interested enough to start making them consistent with the proposed
> consensus and policy rules, it seems very premature to be changing
> consensus or policy rules.
>
> > One case where you actually use less space is if you have a few different
> > sets of customers at N different fee priority level. Then, you might need
> > to have N independent batches, or risk overpaying against the customer's
> > priority level. Imagine I have 100 tier 1 customers and 1000 tier 2
> > customers. If I batcher tier 1 with tier 2, to provide tier 1 guarantees
> > I'd need to pay tier 1 rate for 10x the customers. With CTV, I can
> combine
> > my batch into a root and N batch outputs. This eliminates the need for
> > inputs, signatures, change outputs, etc per batch, and can be slightly
> > smaller. Since the marginal benefit on that is still pretty small, having
> > bare CTV improves the margin of byte wise saving.
>
> Bare CTV only saves bytes when *spending* -- but this is when you're
> creating the 1100 outputs, so an extra 34 or 67 bytes of witness data
> seems fairly immaterial (0.05% extra vbytes?). It doesn't make the small
> commitment tx any smaller.
>
> ie, scriptPubKey looks like:
>  - bare ctv: [push][32 bytes][op_nop4]
>  - p2wsh: [op_0][push][32 bytes]
>  - p2tr: [op_1][push][32 bytes]
>
> while witness data looks like:
>  - bare ctv: empty scriptSig, no witness
>  - pw2sh: empty scriptSig, witness = "[push][32 bytes][op_nop4]"
>  - p2tr: empty scriptSig, witness = 33B control block,
>          "[push][32 bytes][op_nop4]"
>
> You might get more a benefit from bare ctv if you don't pay all 1100
> outputs in a single tx when fees go lower; but if so, you're also wasting
> quite a bit more block space in that case due to the intermediate
> transactions you're introducing, which makes it seem unlikely that
> you care about the extra 9 or 17 vbytes bare CTV would save you per
> intermediate tx...
>
> I admit that I am inclined towards micro-optimising things to save
> those bytes if it's easy, which does incline me towards bare CTV; but
> the closest thing we have to real user data suggests that nobody's going
> to benefit from that possibility anyway.
>
> > Even if we got rid of bare ctv, segwit v0 CTV would still exist, so we
> > couldn't use OP_SUCCESSx there either. segwitv0 might be desired if
> someone
> > has e.g. hardware modules or MPC Threshold Crypto that only support ECDSA
> > signatures, but still want CTV.
>
> If you desire new features, then you might have to upgrade old hardware
> that can't support them.
>
> Otherwise that would be an argument to never use OP_SUCCESSx: someone
> might want to use whatever new feature we might imagine on hardware that
> only supports ECDSA signatures.
>
> 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: 9781 bytes --]

[bitcoin-dev] CTV Signet Parameters

[Jeremy Rubin]

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

Hi devs,

I have been running a CTV signet for around a year and it's seen little
use. Early on I had some issues syncing new nodes, but I have verified
syncability to this signet using
https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify-signet-23.0-alpha.
Please use this signet!

```
[signet]
signetchallenge=512102946e8ba8eca597194e7ed90377d9bbebc5d17a9609ab3e35e706612ee882759351ae
addnode=50.18.75.225
```

This should be operational. Let me know if there are any issues you
experience (likely with signet itself, but CTV too).

Feel free to also email me an address and I can send you some signet coins
-- if anyone is interested in running an automatic faucet I would love help
with that and will send you a lot of coins.

AJ Wrote (in another thread):

>  I'd much rather see some real
>   third-party experimentation *somewhere* public first, and Jeremy's CTV
>   signet being completely empty seems like a bad sign to me. Maybe that
>   means we should tentatively merge the feature and deploy it on the
>   default global signet though?  Not really sure how best to get more
>   real world testing; but "deploy first, test later" doesn't sit right.

I agree that real experimentation would be great, and think that merging
the code (w/o activation) for signet would likely help users v.s. custom
builds/parameters.

I am unsure that "learning in public" is required -- personally I do
experiments on regtest regularly and on mainnet (using emulators) more
occasionally. I think some of the difficulty is that for setting up signet
stuff you need to wait e.g. 10 minutes for blocks and stuff, source faucet
coins, etc. V.s. regtest you can make tests that run automatically. Maybe
seeing more regtest RPC test samples for regtests would be a sufficient
in-between?


Best,

Jeremy

--
@JeremyRubin <https://twitter.com/JeremyRubin>

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

Re: [bitcoin-dev] CTV Signet Parameters

[0x0ff]

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

Good day,

I've setup the explorer for CTV Signet which is now up and running at [https://explorer.ctvsignet.com](https://explorer.ctvsignet.com/)

Best,
[@0x0ff](https://twitter.com/0x0ff_)

------- Original Message -------
On Thursday, February 17th, 2022 at 9:58 PM, Jeremy Rubin via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi devs,
>
> I have been running a CTV signet for around a year and it's seen little use. Early on I had some issues syncing new nodes, but I have verified syncability to this signet using https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify-signet-23.0-alpha. Please use this signet!
>
> ```
> [signet]
> signetchallenge=512102946e8ba8eca597194e7ed90377d9bbebc5d17a9609ab3e35e706612ee882759351ae
> addnode=50.18.75.225
> ```
>
> This should be operational. Let me know if there are any issues you experience (likely with signet itself, but CTV too).
>
> Feel free to also email me an address and I can send you some signet coins -- if anyone is interested in running an automatic faucet I would love help with that and will send you a lot of coins.
>
> AJ Wrote (in another thread):
>
>> I'd much rather see some real> third-party experimentation *somewhere* public first, and Jeremy's CTV
>> signet being completely empty seems like a bad sign to me. Maybe that
>> means we should tentatively merge the feature and deploy it on the
>> default global signet though? Not really sure how best to get more
>> real world testing; but "deploy first, test later" doesn't sit right.
>
> I agree that real experimentation would be great, and think that merging the code (w/o activation) for signet would likely help users v.s. custom builds/parameters.
>
> I am unsure that "learning in public" is required -- personally I do experiments on regtest regularly and on mainnet (using emulators) more occasionally. I think some of the difficulty is that for setting up signet stuff you need to wait e.g. 10 minutes for blocks and stuff, source faucet coins, etc. V.s. regtest you can make tests that run automatically. Maybe seeing more regtest RPC test samples for regtests would be a sufficient in-between?
>
> Best,
>
> Jeremy
>
> --
> [@JeremyRubin](https://twitter.com/JeremyRubin)

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

Re: [bitcoin-dev] CTV Signet Parameters

[Jeremy Rubin]

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

There's also now a faucet:

https://faucet.ctvsignet.com

thanks 0x0ff!
--
@JeremyRubin <https://twitter.com/JeremyRubin>


On Fri, Feb 18, 2022 at 3:13 AM 0x0ff <0x0ff@onsats.org> wrote:

> Good day,
>
> I've setup the explorer for CTV Signet which is now up and running at
> https://explorer.ctvsignet.com
>
> Best,
> @0x0ff <https://twitter.com/0x0ff_>
>
> ------- Original Message -------
> On Thursday, February 17th, 2022 at 9:58 PM, Jeremy Rubin via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Hi devs,
>
> I have been running a CTV signet for around a year and it's seen little
> use. Early on I had some issues syncing new nodes, but I have verified
> syncability to this signet using
> https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify-signet-23.0-alpha.
> Please use this signet!
>
> ```
> [signet]
>
> signetchallenge=512102946e8ba8eca597194e7ed90377d9bbebc5d17a9609ab3e35e706612ee882759351ae
> addnode=50.18.75.225
> ```
>
> This should be operational. Let me know if there are any issues you
> experience (likely with signet itself, but CTV too).
>
> Feel free to also email me an address and I can send you some signet coins
> -- if anyone is interested in running an automatic faucet I would love help
> with that and will send you a lot of coins.
>
> AJ Wrote (in another thread):
>
> > I'd much rather see some real
> > third-party experimentation *somewhere* public first, and Jeremy's CTV
> > signet being completely empty seems like a bad sign to me. Maybe that
> > means we should tentatively merge the feature and deploy it on the
> > default global signet though? Not really sure how best to get more
> > real world testing; but "deploy first, test later" doesn't sit right.
>
> I agree that real experimentation would be great, and think that merging
> the code (w/o activation) for signet would likely help users v.s. custom
> builds/parameters.
>
> I am unsure that "learning in public" is required -- personally I do
> experiments on regtest regularly and on mainnet (using emulators) more
> occasionally. I think some of the difficulty is that for setting up signet
> stuff you need to wait e.g. 10 minutes for blocks and stuff, source faucet
> coins, etc. V.s. regtest you can make tests that run automatically. Maybe
> seeing more regtest RPC test samples for regtests would be a sufficient
> in-between?
>
>
> Best,
>
> Jeremy
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
>
>
>

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

Re: [bitcoin-dev] CTV Signet Parameters

[Anthony Towns]

On Thu, Feb 17, 2022 at 01:58:38PM -0800, Jeremy Rubin via bitcoin-dev wrote:
> AJ Wrote (in another thread):
> >   I'd much rather see some real
> >   third-party experimentation *somewhere* public first, and Jeremy's CTV
> >   signet being completely empty seems like a bad sign to me. 

There's now been some 2,200 txs on CTV signet, of which (if I haven't
missed anything) 317 have been CTV spends:

 - none have been bare CTV (ie, CTV in scriptPubKey directly, not via
   p2sh/p2wsh/taproot)

 - none have been via p2sh

 - 3 have been via taproot:
    https://explorer.ctvsignet.com/tx/f73f4671c6ee2bdc8da597f843b2291ca539722a168e8f6b68143b8c157bee20
    https://explorer.ctvsignet.com/tx/7e4ade977db94117f2d7a71541d87724ccdad91fa710264206bb87ae1314c796
    https://explorer.ctvsignet.com/tx/e05d828bf716effc65b00ae8b826213706c216b930aff194f1fb2fca045f7f11

   The first two of these had alternative merkle paths, the last didn't.

 - 314 have been via p2wsh
    https://explorer.ctvsignet.com/tx/62292138c2f55713c3c161bd7ab36c7212362b648cf3f054315853a081f5808e
   (don't think there's any meaningfully different examples?)

As far as I can see, all the scripts take the form:

  [PUSH 32 bytes] [OP_NOP4] [OP_DROP] [OP_1]

(I didn't think DROP/1 is necessary here? Doesn't leaving the 32 byte
hash on the stack evaluate as true? I guess that means everyone's using
sapio to construct the txs?)

I don't think there's any demos of jamesob's simple-ctv-vault [0], which
I think uses a p2wsh of "IF n CSV DROP hotkey CHECKSIG ELSE lockcoldtx CTV
ENDIF", rather than taproot branches.

[0] https://github.com/jamesob/simple-ctv-vault

Likewise I don't think there's any examples of "this CTV immediately;
or if fees are too high, this other CTV that pays more fees after X
days", though potentially they could be hidden in the untaken taproot
merkle branches.

I don't think there's any examples of two CTV outputs being combined
and spent in a single transaction.

I don't see any txs with nSequence set meaningfully; though most (all?)
of the CTV spends seem to set nSequence to 0x00400000 which I think
doesn't have a different effect from 0xfffffffe?

That looks to me like there's still not much practical (vs theoretical)
exploration of CTV going on; but perhaps it's an indication that CTV
could be substantially simplified and still get all the benefits that
people are particularly eager for.

> I am unsure that "learning in public" is required --

For a consensus system, part of the learning is "this doesn't seem that
interesting to me; is it actually valuable enough to others that the
change is worth the risk it imposes on me?" and that's not something
you can do purely in private.

One challenge with building a soft fork is that people don't want to
commit to spending time building something that relies on consensus
features and run the risk that they might never get deployed. But the
reverse of that is also a concern: you don't want to deploy consensus
changes and run the risk that they won't actually turn out to be useful.

Or, perhaps, to "meme-ify" it -- part of the "proof of work" for deploying
a consensus change is actually proving that it's going to be useful.
Like sha256 hashing, that does require real work, and it might turn out
to be wasteful.

Cheers,
aj

Re: [bitcoin-dev] CTV Signet Parameters

[Nadav Ivgi]

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

> I didn't think DROP/1 is necessary here? Doesn't leaving the 32 byte hash
on the stack evaluate as true?

Not with Taproot's CLEANSTACK rule. It can make sense to always use `DROP
OP_1` even outside of Taproot, just to keep things consistent and to avoid
potential errors when switching from non-Taproot to Taproot. FWIW that's
what I found myself doing when playing with CTV in P2WSH

On Wed, Apr 20, 2022 at 5:31 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Feb 17, 2022 at 01:58:38PM -0800, Jeremy Rubin via bitcoin-dev
> wrote:
> > AJ Wrote (in another thread):
> > >   I'd much rather see some real
> > >   third-party experimentation *somewhere* public first, and Jeremy's
> CTV
> > >   signet being completely empty seems like a bad sign to me.
>
> There's now been some 2,200 txs on CTV signet, of which (if I haven't
> missed anything) 317 have been CTV spends:
>
>  - none have been bare CTV (ie, CTV in scriptPubKey directly, not via
>    p2sh/p2wsh/taproot)
>
>  - none have been via p2sh
>
>  - 3 have been via taproot:
>
> https://explorer.ctvsignet.com/tx/f73f4671c6ee2bdc8da597f843b2291ca539722a168e8f6b68143b8c157bee20
>
> https://explorer.ctvsignet.com/tx/7e4ade977db94117f2d7a71541d87724ccdad91fa710264206bb87ae1314c796
>
> https://explorer.ctvsignet.com/tx/e05d828bf716effc65b00ae8b826213706c216b930aff194f1fb2fca045f7f11
>
>    The first two of these had alternative merkle paths, the last didn't.
>
>  - 314 have been via p2wsh
>
> https://explorer.ctvsignet.com/tx/62292138c2f55713c3c161bd7ab36c7212362b648cf3f054315853a081f5808e
>    (don't think there's any meaningfully different examples?)
>
> As far as I can see, all the scripts take the form:
>
>   [PUSH 32 bytes] [OP_NOP4] [OP_DROP] [OP_1]
>
> (I didn't think DROP/1 is necessary here? Doesn't leaving the 32 byte
> hash on the stack evaluate as true? I guess that means everyone's using
> sapio to construct the txs?)
>
> I don't think there's any demos of jamesob's simple-ctv-vault [0], which
> I think uses a p2wsh of "IF n CSV DROP hotkey CHECKSIG ELSE lockcoldtx CTV
> ENDIF", rather than taproot branches.
>
> [0] https://github.com/jamesob/simple-ctv-vault
>
> Likewise I don't think there's any examples of "this CTV immediately;
> or if fees are too high, this other CTV that pays more fees after X
> days", though potentially they could be hidden in the untaken taproot
> merkle branches.
>
> I don't think there's any examples of two CTV outputs being combined
> and spent in a single transaction.
>
> I don't see any txs with nSequence set meaningfully; though most (all?)
> of the CTV spends seem to set nSequence to 0x00400000 which I think
> doesn't have a different effect from 0xfffffffe?
>
> That looks to me like there's still not much practical (vs theoretical)
> exploration of CTV going on; but perhaps it's an indication that CTV
> could be substantially simplified and still get all the benefits that
> people are particularly eager for.
>
> > I am unsure that "learning in public" is required --
>
> For a consensus system, part of the learning is "this doesn't seem that
> interesting to me; is it actually valuable enough to others that the
> change is worth the risk it imposes on me?" and that's not something
> you can do purely in private.
>
> One challenge with building a soft fork is that people don't want to
> commit to spending time building something that relies on consensus
> features and run the risk that they might never get deployed. But the
> reverse of that is also a concern: you don't want to deploy consensus
> changes and run the risk that they won't actually turn out to be useful.
>
> Or, perhaps, to "meme-ify" it -- part of the "proof of work" for deploying
> a consensus change is actually proving that it's going to be useful.
> Like sha256 hashing, that does require real work, and it might turn out
> to be wasteful.
>
> 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: 5805 bytes --]

Re: [bitcoin-dev] CTV Signet Parameters

[Anthony Towns]

On Wed, Apr 20, 2022 at 08:05:36PM +0300, Nadav Ivgi via bitcoin-dev wrote:
> > I didn't think DROP/1 is necessary here? Doesn't leaving the 32 byte hash
> on the stack evaluate as true?
> Not with Taproot's CLEANSTACK rule. 

The CLEANSTACK rule is the same for segwit and tapscript though? 

For p2wsh/BIP 141 it's "The script must not fail, and result in exactly
a single TRUE on the stack." and for tapscript/BIP 342, it's "If the
execution results in anything but exactly one element on the stack which
evaluates to true with CastToBool(), fail."

CastToBool/TRUE is anything that's not false, false is zero (ie, any
string of 0x00 bytes) or negative zero (a string of 0x00 bytes but with
the high byte being 0x80).

Taproot has the MINIMALIF rule that means you have to use exactly 1 or 0
as the input to IF, but I don't think that's relevant for CTV.

Cheers,
aj

Re: [bitcoin-dev] CTV Signet Parameters

[Jeremy Rubin]

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

Sorry I didn't see this snippet fully earlier, but I caught it in Optech
(cc harding)


> *(I didn't think DROP/1 is necessary here? Doesn't leaving the 32 byte*
> *hash on the stack evaluate as true? I guess that means everyone's using**sapio to
> construct the txs?)*


Not quite: it would mean that everyone is using *sapio-miniscript**, *which
may or may not be in Sapio, or they are using a different miniscript
implementation that is compatible with sapio-miniscript's CTV fragment
(which is sort of the most obvious way to implement it), or they are hand
writing the script and are still using that fragment.

E.g., you can see
https://min.sc/nextc/#gist=001cf1fcb0e24ca9f3614c4db9bfe57d:2 or
https://min.sc/nextc/#gist=001cf1fcb0e24ca9f3614c4db9bfe57d:0 both of these
might "look" like sapio, but are built using minsc.

The underlying point might still stand, but using miniscript seems
different than using Sapio.

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