Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[David A. Harding via bitcoin-dev]

On 21.04.2022 14:28, Anthony Towns wrote:

But, if [it's true that "many [...] use cases [...] to use CTV for
are very long term in nature"], that's presumably incompatible
with any sort of sunset that's less than many decades away, so doesn't
seem much better than just having it be available on a signet?


I fully acknowledge that a temporary test can't fully replicate a 
permanent condition.  That said, if people truly believe CTV vaults will 
significantly enhance their security, wouldn't it be worth using them 
for most of the deployment?  Users would receive both years of added 
security and the opportunity to convince other Bitcoiners to make CTV 
permanent by demonstrating real-world usage.



If sunsetting were a good idea, one way to think about implementing it
might be to code it as:

  if (DeploymentActiveAfter(pindexPrev, params, FOO) &&
  !DeploymentActiveAfter(pindexPrev, params, FOO_SUNSET))
  {
  EnforceFoo();
  }


Defining at the outset how we'll signal years later if we want to keep 
the rules seems intelligent to me.


Thanks!,

-Dave
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[David A. Harding via bitcoin-dev]

[Rearranging Matt's text in my reply so my nitpicks come last.]

On 21.04.2022 13:02, Matt Corallo wrote:

I agree, there is no universal best, probably. But is there a concrete
listing of a number of use-cases and the different weights of things,
plus flexibility especially around forward-looking designs?


I'm sure we could make a nice list of covenant usecases, but I don't 
know how we would assign reasonable objective weights to the different 
things purely through group foresight.  I know I'm skeptical about 
congestion control and enthusiastic about joinpools---but I've talked to 
developers I respect who've had the opposite opinions from me about 
those things.  The best way I know of to reconcile our differing 
opinions is to see what real Bitcoin users actually pay for.  But to do 
that, I think they must have a way to use covenants in something like 
the production environment.



You're also writing off [...] a community of
independent contributors who care about Bitcoin working together to
make decisions on what is or isn't the "right way to go" [...]. Why are 
you

suggesting its something that you "don't know how to do"?


You said we should use the best design.  I said the different designs 
optimize for different things, so it's unlikely that there's an 
objective best.  That implies to me that we either need to choose a 
winner (yuck) or we need to implement more than one of the designs.  In 
either of those cases, choosing what to implement would benefit from 
data about how much the thing will be used and how much users will pay 
for it in fees.



Again, my point *is not* "will people use CTV", I think they will. I
think they would also use TLUV if that were activated for the exact
same use-cases. I think they would also use CAT+CSFS if that were what
was activated, again for the exact same use-cases. Given that, I'm not
sure how your proposal teaches us anything at all, aside from "yes,
there was demand for *some* kind of covenant".


I'm sorry if my OP was ambiguous about this, but my goal there was to 
describe a general framework for activating temporary consensus changes 
for the purpose of demonstrating demand for proposed features.  I gave 
CTV as an example for how the framework could be used, but we could use 
the same framework to activate APO and TLUV (or IIDs and EVICT)---and 
then we would see which of them people actually used.  If there was 
significant ongoing use of all three after 5 years, great!  We keep them 
all.  If some of them went largely unused, we let the extra validation 
rules expire and move on.


Alternatively, if we only enabled one covenant design (e.g. CTV), we 
would still gain data about how it was used and we could see if some of 
the alternative designs would've been more optimal for those 
demonstrated uses.


My goal here is obtaining data from which we can make informed 
decisions.  A transitory soft fork is an extreme way to acquire that 
data and I fully acknowledge it has several significant problems 
(including those I listed in my OP).  I'm hoping, though, that it's a 
better solution than another activation battle, prolonged yelling on 
this mailing list and elsewhere, or everyone just giving up and letting 
Bitcoin ossify prematurely.  Alternatively, I'm hoping one of the many 
people on this list who is smarter than I am will think of another way 
to obtain decisive data with less fuss.



Again, you're writing off the real and nontrivial risk of doing a fork
to begin with.


I agree this risk exists and it isn't my intention to write it off---my 
OP did say "we [must be] absolutely convinced CTV will have no negative 
effects on the holders or receivers of non-CTV coins."  I haven't been 
focusing on this in my replies because I think the other issues we've 
been discussing are more significant.  If we were to get everyone to 
agree to do a transitory soft fork, I think the safety concerns related 
to a CTV soft fork could be mitigated the same way we've mitigated them 
for previous soft forks: heaps of code review/testing and making sure a 
large part of the active community supports the change.



You don't
mention the lack of recursion in CTV vs CAT+CSFS


I mentioned recursion, or the lack thereof, in various proposals like 
five times in this thread.  :-)


Thanks again for your replies,

-Dave
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CTV Signet Parameters

[Anthony Towns via bitcoin-dev]

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

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[Anthony Towns via bitcoin-dev]

On Wed, Apr 20, 2022 at 03:04:53PM -1000, David A. Harding via bitcoin-dev 
wrote:
> The main criticisms I'm aware of against CTV seem to be along the following
> lines: [...]

> Could those concerns be mitigated by making CTV an automatically reverting
> consensus change with an option to renew?  [...]

Buck O Perley suggested that "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."

But, if true, that's presumably incompatible with any sort of sunset
that's less than many decades away, so doesn't seem much better than
just having it be available on a signet?

[5] https://github.com/kanzure/python-vaults/blob/master/vaults/bip119_ctv.py
[6] https://github.com/jamesob/simple-ctv-vault

If sunsetting were a good idea, one way to think about implementing it
might be to code it as:

  if (DeploymentActiveAfter(pindexPrev, params, FOO) &&
  !DeploymentActiveAfter(pindexPrev, params, FOO_SUNSET))
  {
  EnforceFoo();
  }

That is to have sunsetting the feature be its own soft-fork with
pre-declared parameters that are included in the original activation
proposal. That way you don't have to have a second process debate about
how to go about (not) sunsetting the rules, just one on the merits of
whether sunsetting is worth doing or not.

Cheers,
aj

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

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[Matt Corallo via bitcoin-dev]

On 4/21/22 3:28 PM, David A. Harding wrote:

On 21.04.2022 08:39, Matt Corallo wrote:

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


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


To be clear - I was not suggesting that CTV fell flat here. I think there *is* demand for Bitcoin 
covenant designs, CTV included. I do *not* think there is demand for CTV *over* other covenant 
designs, that's okay, though, it doesn't need that, we just have to be confident its the right 
direction.


I believe you got the impression I was arguing CTV did not meet by criteria list (a)-(d), but in 
fact I only think it falls flat horribly on (c).



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


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


I tend to agree.


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


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


I agree, there is no universal best, probably. But is there a concrete listing of a number of 
use-cases and the different weights of things, plus flexibility especially around forward-looking 
designs? You don't mention the lack of recursion in CTV vs CAT+CSFS, which is a *huge* difference in 
the available design space for developers. This stuff is critical to get right and we're barely even 
talking about it, let alone at a position of deciding something?



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


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


Again, you're writing off the real and nontrivial risk of doing a fork to begin with. You're also 
writing off something organic that has happened without issue time and time again - a community of 
independent contributors who care about Bitcoin working together to make decisions on what is or 
isn't the "right way to go" is something we've all collaboratively done time and time again. Why are 
you suggesting its something that you "don't know how to do"?


Again, my point *is not* "will people use CTV", I think they will. I think they would also use TLUV 
if that were activated for the exact same use-cases. I think they would also use CAT+CSFS if that 
were what was activated, again for the exact same use-cases. Given that, I'm not sure how your 
proposal teaches us anything at all, aside from "yes, there was demand for *some* kind of covenant".


Matt
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[David A. Harding via bitcoin-dev]

On 21.04.2022 08:39, Matt Corallo wrote:

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


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



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


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



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


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


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


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



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


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



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


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



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


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


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


Thanks for your thoughtful response,

-Dave
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[Jeremy Rubin via bitcoin-dev]

I think I've discussed this type of concept previously somewhere but cannot
find a link to where.

Largely, I think the following:

1) This doesn't reduce burden of maintenance and risk of consensus split,
it raises it:
   A) as we now have a bunch of tricky code around reorgs and mempool
around the time of rule de-activation.
   B) we need to permanently maintain the rule to validate old blocks fully
2) Most of the value of a 'temporary soft fork' is more safely captured by
use of a CTV emulation server / servers, which has a more graceful
degradation property of the servers simply shutting down and not
authorizing new contracts, but funds not being vulnerable to theft. The
model here is trust, as opposed to a timeout.
   2A) The way I implemented the oracles in CTV was such that, if we wanted
to, we could actually soft-fork the rules for the oracle's keys such that
they would *have to* only sign CTV-valid transactions (e.g., the keys could
be made public). Pretty weird model, but cool that it would enable
after-the-fact trust model improvements. This could be generalized for any
opcode to be emulator -> emulator consensus guaranteed -> non signature
based opcode.

Although I will note that I like the spirit of this, and encourage thinking
more creatively about other ways to have temporary forks in Bitcoin like
this.

Best,

Jeremy

--
@JeremyRubin 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[Matt Corallo via bitcoin-dev]

On 4/21/22 11:06 AM, David A. Harding wrote:

On 21.04.2022 04:58, Matt Corallo wrote:

On 4/20/22 6:04 PM, David A. Harding via bitcoin-dev wrote:

The main criticisms I'm aware of against CTV seem to be along the following 
lines:

1. Usage, either:
   a. It won't receive significant real-world usage, or
   b. It will be used but we'll end up using something better later
2. An unused CTV will need to be supported forever, creating extra maintenance
    burden, increasing security surface, and making it harder to evaluate later
    consensus change proposals due to their interactions with CTV


Also "is this even the way we should be going about covenants?"


I consider this to be a version of point 1b above.  If we find a better way for going about 
covenants, then we'll activate that and let CTV automatically be retired at the end of its five years.


If you still think your point is separate from point 1b, I would appreciate you 
helping me understand.


No, its unrelated to whether CTV or any other system gets usage. If we were just concerned with 
whether CTV would get usage over or under some other alternative proposal then I could see an 
argument for your proposal (though the nontrivial cost of any fork to Bitcoin would make me still 
strongly disagree with such a way forward in principle).


Rather, I'm instead concerned with us designing something that is going to be the most flexible and 
useful and hopefully private covenents design we can, because that doesn't just get users to use the 
change to Bitcoin we paid some nontrivial change-cost to incorporate into the Bitcoin's consensus 
rules, but gets the most bang-for-our-buck. There are at least three or four separate covenants 
designs that have been posted to this list, and I don't see why we're even remotely talking about a 
specific one as something to move forward with at this point.


We don't add things to Bitcoin just to find out whether we can. full stop.

We add things to Bitcoin because (a) there's some demonstrated use-cases and intent to use the 
change (which I think we definitely have for covenants, but which only barely, if at all, suggests 
favoring one covenant design over any other), (b) because its generally considered aligned with 
Bitcoin's design and goals, based on developer and more broad community response and (c) because the 
technical folks who have/are wiling to spend time working on the specific design space think the 
concrete proposal is the best design we have, and finally (d) because the implementation is 
well-reviewed and complete.


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



the Bitcoin technical community (or at least those interested in
working on covenants) doesn't even remotely show any signs of
consensus around any concrete proposal,


This is also my assessment: neither CTV nor any other proposal currently has enough support to 
warrant a permanent change to the consensus rules.  My question to the list was whether we could use 
a transitory soft fork as a method for collecting real-world usage data about proposals.  E.g., a 
consensus change proposal could proceed along the following idealized path:


- Idea (individual or small group)
- Publication (probably to this list)
- Draft specification and implementation
- Riskless testing (integration tests, signet(s), testnet, etc)
- Money-at-stake testing (availability on a pegged sidechain, an altcoin similar to Bitcoin, or in 
Bitcoin via a transitory soft fork)

- Permanent consensus change


That all seems fine, except that doing a fork on Bitcoin has very nontrivial cost, both in terms of 
ecosystem disruption and possibility that anything goes wrong, not to mention code maintenance 
(which we cannot remove the validation code for something ever, really - you still want to be able 
to validate the historical chain). Plus, really, I'd love to see "technical community consensus" 
somewhere in there - at least its been something that has very roughly appeared for most previous 
soft forks, at least among those who have time/willingness to work on the specific design being 
proposed.


[other comments snipped because my responses would mostly have been rehashing 
the first response above].

Matt
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] User Resisted Soft Fork for CTV

[Michael Folkson via bitcoin-dev]

Ok so we've had to scramble a bit as I don't think anyone except perhaps Jeremy 
thought that there would be a Speedy Trial signaling period for a CTV soft fork 
planned to start on May 5th [1]. That is two weeks away.

(I have to take what he says at face value. I can understand why one would be 
skeptical.)

Understandably this has angered and surprised a few people including some of 
those who have voiced opposition to a CTV soft fork activation being attempted 
in the first place [2].

As I've said in a previous post [3] the Bitcoin Core 23.0 release candidate 
(and older versions) does not include any CTV code or CTV activation code. If a 
miner runs Bitcoin Core 23.0 out the box it will not signal for CTV. If by some 
chance CTV was to activate through some other software release Bitcoin Core 
releases would not apply CTV rules but they also wouldn't reject blocks that 
apply CTV rules. Hence it is prudent to prepare for an eventuality where the 
miner signaling threshold might be reached but the community wants to prevent 
the attempted soft fork from activating. (I personally don't think a 90 percent 
miner signaling threshold will be reached but I wouldn't want to bet Bitcoin's 
future on it.)

I've tentatively labelled this effort a User Resisted Soft Fork (URSF) but I'm 
open to better names. I certainly don't want to discourage those who dislike or 
oppose UASFs from contributing to this effort and potentially ultimately 
running a URSF release. If you don't want this rushed CTV soft fork to activate 
we are all on the same side whatever we call it.

For now I've set up a ##ursf channel on Libera IRC to monitor developments and 
discuss working on an additional release that if run may ultimately reject 
blocks that signal for CTV.

The intention of this would be to provide additional direction and incentive to 
miners that the community does not want this soft fork to be activated. To 
repeat running a Bitcoin Core release will not signal for a CTV soft fork out 
the box. If a miner runs a Bitcoin Core release it will not signal for CTV.

Apologies that this is rushed. But as always with Jeremy caution and 
conservatism seems to be thrown out the window and we have to react to that. It 
goes without saying that this is not how Bitcoin consensus changes should be 
attempted.

[1]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
[2]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
[3]: 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[David A. Harding via bitcoin-dev]

On 21.04.2022 04:58, Matt Corallo wrote:

On 4/20/22 6:04 PM, David A. Harding via bitcoin-dev wrote:
The main criticisms I'm aware of against CTV seem to be along the 
following lines:


1. Usage, either:
   a. It won't receive significant real-world usage, or
   b. It will be used but we'll end up using something better later
2. An unused CTV will need to be supported forever, creating extra 
maintenance
    burden, increasing security surface, and making it harder to 
evaluate later

    consensus change proposals due to their interactions with CTV


Also "is this even the way we should be going about covenants?"


I consider this to be a version of point 1b above.  If we find a better 
way for going about covenants, then we'll activate that and let CTV 
automatically be retired at the end of its five years.


If you still think your point is separate from point 1b, I would 
appreciate you helping me understand.



the Bitcoin technical community (or at least those interested in
working on covenants) doesn't even remotely show any signs of
consensus around any concrete proposal,


This is also my assessment: neither CTV nor any other proposal currently 
has enough support to warrant a permanent change to the consensus rules. 
 My question to the list was whether we could use a transitory soft fork 
as a method for collecting real-world usage data about proposals.  E.g., 
a consensus change proposal could proceed along the following idealized 
path:


- Idea (individual or small group)
- Publication (probably to this list)
- Draft specification and implementation
- Riskless testing (integration tests, signet(s), testnet, etc)
- Money-at-stake testing (availability on a pegged sidechain, an altcoin 
similar to Bitcoin, or in Bitcoin via a transitory soft fork)

- Permanent consensus change


talking about a "way forward for CTV" or activating CTV or coming up
with some way of shoving it into Bitcoin at this stage [...] sets 
incredibly poor precedent for

how we think about changes to Bitcoin and maintaining Bitcoin's
culture of security and careful design.


How should we think about changes to Bitcoin and maintaining its culture 
of security and careful design?  My post suggested a generalized way we 
could evaluate proposed consensus changes for real-world demand, 
allowing us to settle what I see as the most contended part of the CTV 
proposal.  That feels to me like legitimate engineering and social 
consensus building.  What would be your preferred alternatives?


(For the record, my preferred alternative for years has been to add the 
technically trivial opcodes OP_CAT and OP_CHECKSIGFROMSTACK, see what 
covenant-y things people build with them, and then consider proposals to 
optimize the onchain usage of those covenant-y things.  Alas, this seems 
to fall afoul of the concerns held by some people about recursive 
covenants.)



I'm gobsmacked that the conversation has reached this point, and am
even more surprised that the response from the Bitcoin (technical)
community hasn't been a more resounding and complete rejection of this
narrative.


If the only choices are to support activation of BIP119 CTV at this time 
or to reject it, I would currently side with rejection.  But I would 
prefer over both of those options to find a third way that doesn't 
compromise safety or long-term maintainability and which gives us the 
data about CTV (or other covenant-related constructions) to see whether 
the concerns described above in 1a and 1b are actually non-issues.


I see one of those third ways as the testing on the CTV signet described 
in a contemporaneous thread on this list.[1]  Other third ways would be 
trying CTV on sidechains or altcoins, or perhaps allowing CTV to be 
temporarily used on Bitcoin as proposed in this thread.  Is there 
interest in working on those alternatives, or is the only path forward 
an argument over attempting activation of CTV?


Thanks,

-Dave

[1] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020234.html

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

Re: [bitcoin-dev] CTV Signet Parameters

[Jeremy Rubin via bitcoin-dev]

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 

Re: [bitcoin-dev] 7 Theses on a next step for BIP-119

[Greg Sanders via bitcoin-dev]

Ironically assumptions of bad faith are going to kill any proposal,
resulting in the status quo.

Let's keep the assumption of good faith, unless you are actually accusing
people of being a NSA-adjacent asset.

On Thu, Apr 21, 2022 at 10:08 AM alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> There are a number of individuals who have stated opposition to attempting
> to activate a CTV soft fork in the near term:
>
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>
>
> sheshek found some issues with the list and some of them are not really an
> opposition for CTV. Others do not have any technical details to consider.
>
> The saddest thing is that if Jeremy's soft fork activation attempt causes
> the uncertainty, confusion and disruption I fear it could it will make
> future soft forks that do have community consensus orders of magnitude
> harder to pull off.
>
>
>
> Calling CTV an attack on bitcoin or doing personal attacks on Jeremy and
> other developers on social media that support CTV won't help. Developers
> should be free to propose improvements and write code. Users can decide if
> they want to run this code. Just because someone is opposing a change and
> prefers status quo does not mean it is better for Bitcoin. Attackers have
> used such things in past for many open source projects.
>
> Example: Someone signed up on the Tor Project mailing list and then
> participated in discussions to advocate against the removal of malicious
> servers
>
> https://nitter.net/campuscodi/status/1466748897003544579
>
>
> dev/fd0
>
> Sent with ProtonMail  secure email.
>
> --- Original Message ---
> On Wednesday, April 20th, 2022 at 6:54 PM, Michael Folkson via bitcoin-dev
>  wrote:
>
> > The client has a Speedy trial release similar to Taproots with
> parameters proposed to be
>
> As I've said before I was hoping we'd avoid this exercise. Best case, it
> wastes the time of people who could be working on all sorts of valuable
> projects for the ecosystem. Worst case, we take a Russian roulette style
> gamble with a chain split.
>
> But here's a summary of the basic facts:
>
> The latest Bitcoin Core release candidate (23.0) does not contain any new
> soft fork code, either CTV code or any new activation code. Running Bitcoin
> Core 23.0 out the box will not signal for any new soft fork and will not
> enforce any new soft fork rules (CTV or otherwise). Of course it will
> continue to enforce Taproot rules as Taproot activated last year.
>
> There are a number of individuals who have stated opposition to attempting
> to activate a CTV soft fork in the near term:
>
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>
> Most of those individuals haven't logged their opposition on Jeremy's site:
> https://utxos.org/signals/
>
> Hence their views haven't been included or discussed in Jeremy's latest
> blog post.
>
> Chain split risk
>
> I can't predict how many full nodes and miners will run Jeremy's client
> attempting to activate CTV. One would expect that many will continue to run
> versions of Bitcoin Core that will not enforce CTV rules and will not
> activate it. But whether Jeremy's client will be a majority, significant
> minority, insignificant minority of full nodes and miners would be
> speculation on my part. (Personally I highly doubt those running Jeremy's
> client will be a majority which leaves a significant minority and
> insignificant minority as the most likely options).
>
> Jeremy's client is intending to use Speedy Trial presumably with similar
> parameters to that used for Taproot. That would mean seeking 90 percent of
> miners to signal for this CTV soft fork activation attempt.
>
> Assuming 90 percent of miners don't signal for it in one of the Speedy
> Trial windows then the activation attempt will have failed and it will be
> back in Jeremy's court whether he tries again with a different activation
> attempt.
>
> Assuming 90 percent of miners do signal for it (unlikely in my opinion but
> presumably still a possibility) then the CTV soft fork could activate
> unless full nodes resist it. This resistance would most likely be in the
> form of a UASF style client which rejects blocks that apply the CTV rules
> and/or includes transactions that don't meet the CTV rules post activation.
> We would now be in chain split territory with two different assets and
> blockchains like we had with BTC and BCH.
>
> If I oppose this activation attempt and the associated chain split risk
> what should I do?
>
> Firstly, you can register your opposition to this soft fork activation
> attempt on Jeremy's site: https://utxos.org/signals/
>
> It seems Jeremy will continue this activation attempt regardless but it
> will be useful for others to see clearly that this a contentious soft fork
> activation attempt and act accordingly. So far only 3 individuals'
> opposition is registered on his site.
>
> 

Re: [bitcoin-dev] 7 Theses on a next step for BIP-119

[alicexbt via bitcoin-dev]

> There are a number of individuals who have stated opposition to attempting to 
> activate a CTV soft fork in the near term:
>
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718

sheshek found some issues with the list and some of them are not really an 
opposition for CTV. Others do not have any technical details to consider.

> The saddest thing is that if Jeremy's soft fork activation attempt causes the 
> uncertainty, confusion and disruption I fear it could it will make future 
> soft forks that do have community consensus orders of magnitude harder to 
> pull off.

Calling CTV an attack on bitcoin or doing personal attacks on Jeremy and other 
developers on social media that support CTV won't help. Developers should be 
free to propose improvements and write code. Users can decide if they want to 
run this code. Just because someone is opposing a change and prefers status quo 
does not mean it is better for Bitcoin. Attackers have used such things in past 
for many open source projects.

Example: Someone signed up on the Tor Project mailing list and then 
participated in discussions to advocate against the removal of malicious servers

https://nitter.net/campuscodi/status/1466748897003544579

dev/fd0

Sent with [ProtonMail](https://protonmail.com/) secure email.

--- Original Message ---
On Wednesday, April 20th, 2022 at 6:54 PM, Michael Folkson via bitcoin-dev 
 wrote:

>> The client has a Speedy trial release similar to Taproots with parameters 
>> proposed to be
>
> As I've said before I was hoping we'd avoid this exercise. Best case, it 
> wastes the time of people who could be working on all sorts of valuable 
> projects for the ecosystem. Worst case, we take a Russian roulette style 
> gamble with a chain split.
>
> But here's a summary of the basic facts:
>
> The latest Bitcoin Core release candidate (23.0) does not contain any new 
> soft fork code, either CTV code or any new activation code. Running Bitcoin 
> Core 23.0 out the box will not signal for any new soft fork and will not 
> enforce any new soft fork rules (CTV or otherwise). Of course it will 
> continue to enforce Taproot rules as Taproot activated last year.
>
> There are a number of individuals who have stated opposition to attempting to 
> activate a CTV soft fork in the near term:
>
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>
> Most of those individuals haven't logged their opposition on Jeremy's site:
> https://utxos.org/signals/
>
> Hence their views haven't been included or discussed in Jeremy's latest blog 
> post.
>
> Chain split risk
>
> I can't predict how many full nodes and miners will run Jeremy's client 
> attempting to activate CTV. One would expect that many will continue to run 
> versions of Bitcoin Core that will not enforce CTV rules and will not 
> activate it. But whether Jeremy's client will be a majority, significant 
> minority, insignificant minority of full nodes and miners would be 
> speculation on my part. (Personally I highly doubt those running Jeremy's 
> client will be a majority which leaves a significant minority and 
> insignificant minority as the most likely options).
>
> Jeremy's client is intending to use Speedy Trial presumably with similar 
> parameters to that used for Taproot. That would mean seeking 90 percent of 
> miners to signal for this CTV soft fork activation attempt.
>
> Assuming 90 percent of miners don't signal for it in one of the Speedy Trial 
> windows then the activation attempt will have failed and it will be back in 
> Jeremy's court whether he tries again with a different activation attempt.
>
> Assuming 90 percent of miners do signal for it (unlikely in my opinion but 
> presumably still a possibility) then the CTV soft fork could activate unless 
> full nodes resist it. This resistance would most likely be in the form of a 
> UASF style client which rejects blocks that apply the CTV rules and/or 
> includes transactions that don't meet the CTV rules post activation. We would 
> now be in chain split territory with two different assets and blockchains 
> like we had with BTC and BCH.
>
> If I oppose this activation attempt and the associated chain split risk what 
> should I do?
>
> Firstly, you can register your opposition to this soft fork activation 
> attempt on Jeremy's site: https://utxos.org/signals/
>
> It seems Jeremy will continue this activation attempt regardless but it will 
> be useful for others to see clearly that this a contentious soft fork 
> activation attempt and act accordingly. So far only 3 individuals' opposition 
> is registered on his site.
>
> Secondly, if it is looking like 90 percent (or whatever percentage Jeremy 
> uses) of miners are going to signal for a CTV soft fork then you can consider 
> joining a UASF style effort to resist the soft fork activation attempt. I 
> will certainly seek to participate and will continue to inform this list of 
> efforts in this 

Re: [bitcoin-dev] CTV Signet Parameters

[Russell O'Connor via bitcoin-dev]

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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[Jeremy Rubin via bitcoin-dev]

> You'd be confiscating your own funds by making an absurd spending
condition.
> By this argument, ALL softforks would have to be ruled out.

The argument is that transactions which can be relayed and in the mempool
and then confirmed should not ever be restricted.

This is so that old node's mempools don't produce invalid blocks after an
upgrade.

This is what a good chunk of policy is for, and we (being core) do bounce
these txns to make clear what might be upgraded.

Changing the detail you mentioned represents a tweak that could make old
nodes mine invalid blocks. That's all I'm ruling out.



> > In preparing it I just used what was available in Core now, surely the
> last
> > year you could have gotten the appropriate patches done?
>
> They were done, reviewed, and deployed in time for Taproot. You personally
>
> played a part in sabotaging efforts to get it merged into Core, and
> violating
> the community's trust in it by instead merging your BIP9 ST without
> consensus. Don't play dumb. You have nobody to blame but yourself.
>


Even if I accept full responsibility for BIP9 ST without consensus, you
still had the last year to convince the rest of the maintainers to review
and merge your activation code, which you did not do.

Don't confuse consensus-seeking with preference. My preference was to leave
versionbits entirely.

Nor am I blame seeking. I'm simply asking why, if this is _the_ most
important thing for Bitcoin (as I've heard some BIP8 LOT=true people
remark), did you not spend the last year improving your advocacy. And I'm
suggesting that you redouble those efforts by, e.g., opening a new PR for
Core with logic you find acceptable and continuing to drive the debate
forward. None of these things happen without advocacy.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] 7 Theses on a next step for BIP-119

[Zac Greenwood via bitcoin-dev]

On Wed, 20 Apr 2022 at 15:49, Michael Folkson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

Assuming 90 percent of miners don't signal for it in one of the Speedy
> Trial windows then the activation attempt will have failed and it will be
> back in Jeremy's court whether he tries again with a different activation
> attempt.
>
> Assuming 90 percent of miners do signal for it (unlikely in my opinion but
> presumably still a possibility) then the CTV soft fork could activate
> unless full nodes resist it.
>

This is wrong. Miners do not have the mandate to decide the faith of
softforks. The MO of softforks is that once a softfork has been merged, it
already has consensus and must be activated by miners eventually. The
various activation methods exist to ensure miners cannot sabotage a
softfork that has consensus.

The way you phrase it, makes it sound like miners have any say over
softforks. This is not the case.

Zac

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

Re: [bitcoin-dev] 7 Theses on a next step for BIP-119

[Robin Linus via bitcoin-dev]

Hi Michael,

Sorry, if my critique of your opinions feels too personal to you. This is 
nothing personal. As you probably know, one of the most effective attack 
vectors on Bitcoin is to target the social layer by sabotaging the protocol 
development[1]. Bike shedding is an easy way to cause a lot of harm.
This is why it is hard to distinguish your radical opinions from an 
(unintended) attack. So, we cannot simply trust you. In particular because you 
contribute so much time criticising the activation of CTV, while you also 
refuse to spend any time working on activating covenants. You just want to 
stall the activation of covenants indefinitely. An attacker would act the same.
Another red flag is that you are trying to downplay how many reputable 
community members have already signalled their support for CTV 
https://utxos.org/signals/ . You keep framing it as if there was only that one 
crazy guy trying to push an immature and risky consensus change. In fact, it is 
well reviewed and many people support CTV because it is the most conservative 
step forwards and it is ready for activation now.
You are alarmed by what you call a "contentious" soft fork while actually you 
are yourself by far the most vocal opponent of this fork. You are even 
threatening to cause a chain split while you're also warning others that your 
chain split would become a big issue. Since we're talking about a soft fork 
here you're basically saying that you want to make your node reject valid 
blocks. I doubt that anyone opposes CTV as extremely as you do. In particular 
because your strongest argument is that CTV might not be ideal for all use 
cases, which is trivially true for every protocol upgrade. An attacker would 
act the same.

All in all, it is very hard to distinguish your strong desire to stall the 
development from an attack. This is why we have to question your motives 
thoroughly. Again, this is nothing personal. It's just that you are very 
critical of people who support activation of CTV and thus, you should expect 
others to be just as critical of your opinions. Isn't that fair?

Regards,
Robin

[1] https://twitter.com/peterktodd/status/1495796670440919056

--- Original Message ---
On Thursday, April 21st, 2022 at 12:04 AM, Michael Folkson 
 wrote:

> Ok last one. Whatever you say and whatever personal attacks you come up with 
> I'm not responding after this one :)
>
>> Where can I see the use cases you have built out in recent years? Do you 
>> have a writeup in which you compare CTV to existing covenant enabling 
>> proposals? Do you have a strong reason to favour a different proposal? Have 
>> you written any code?
>
> You don't seem to quite understand the asymmetry here. I (and the rest of the 
> community excluding Jeremy) am not a full time CTV developer or full time CTV 
> advocate. There are a number of soft fork proposals I am interested in and 
> attempting to follow in addition to all the work that is going around Taproot 
> etc. But if you/Jeremy want to make a change to the consensus rules the onus 
> is on you to get community review and community consensus. I am not demanding 
> the consensus rules be changed. I am quite happy to wait until there is 
> community consensus over a particular soft fork like there was with Taproot.
>
> I have looked into CTV a considerable number of times now. I have asked 5 of 
> the 6 CTV related questions on Bitcoin StackExchange at the time of writing 
> [1], 2 of which I have attempted to answer. Does this mean I understand as 
> much about Jeremy about CTV? Of course not. But if you believe that soft 
> forks should have community consensus it is up to you/Jeremy to address 
> concerns from curious, relatively informed, skeptical people like me. I am 
> not convinced at the time of writing that CTV is the best tool for the job on 
> any of its intended use cases. On this I don't think even Jeremy is convinced 
> as when asked to compare CTV to alternatives he often just says it is ready 
> and other proposals aren't.
>
>> In contrast, Jeremy has been doing exactly what you are proposing. He wrote 
>> the BIP, implemented it, explained use cases in detail, spoke at 
>> conferences, organised workshops, and built the Sapio framework for the 
>> community to experiment with covenants. He even puts his money where his 
>> mouth is and offers a bug bounty for any security flaw in the code.
>
> I'm not entirely sure where you are going with this. That because Jeremy has 
> worked really hard on it for a long time we should activate it without 
> community consensus? I'm sorry that's not how consensus changes work or how 
> they should work. Personally I very much doubt I will ever attempt to change 
> the consensus rules with one of my proposals. I struggle to follow all of the 
> work and the proposals others work on and at least for now believe others are 
> much more qualified than me to design and code up consensus code changes. So 
> again there is an 

Re: [bitcoin-dev] 7 Theses on a next step for BIP-119

[Billy Tetrud via bitcoin-dev]

Hi Michael,

I'm sympathetic to the idea of allowing time for the community to absorb,
review, analyze, discuss, etc any new substantial change to bitcoin,
especially consensus changes. I certainly think that over time the
frequency of soft forks should generally go down on average, with
ossification at some point being the ideal endpoint (perhaps in the next
10-20 years).

However, many of the messages of opposition/caution seem to imply that
analysis of a consensus change can't begin until the last change has been
completed. This is quite clearly not the case. And as far as I can tell the
CTV spec was functionally completed *before* the taproot spec was (sometime
in early 2020).

Jeremy included a nice list of "ticked boxes" that are all indicators of
maturity of not only the spec but implementations and testing. I would
expect any considered opposition to CTV to at least address that checklist,
but you did not.

I think it would be interesting to compare the state of CTV now with the
state of taproot when activation. One example is that Taproot had been on
Signet for about 1 month

before
consensus developed 
in support of pulling the trigger on a softfork for taproot. CTV has had a
signet running for almost twice that long already if not longer. So
Michael, what do you think is missing from Jeremy's checklist? Where do you
think the checklist fails to meet your ideal bar of acceptance?

Not only that but CTV is a simpler change than taproot. I assume you'd
agree that a simpler change should require correspondingly less
review/analysis/etc, right? If not, I'd appreciate it if you could comment
as to why.

> There are a number of individuals who have stated opposition to
attempting to activate a CTV soft fork in the near term

As Jeremy has noted, none of these indicate or suspect any technical issues
in CTV. Basically all of them are basically saying "too soon" without much
concrete reasons. I believe in consensus weighted by quality-of-logic, and
most of the ones in your list do not contain any supported logic at all.
Many are borderline ad hominems at Jeremy. So to me, most hold little
weight. The ones with some logic included seem to basically be "I'm not
involved enough to know or knowledgeable enough to review, and therefore
I'm hesitant". Now to be fair, many of the acks listed in Jeremy's also
hold little weight to me for the same reasons, with a few exceptions like Bram
Cohen's discussion
 and a Corenell
paper . But there's clearly been quite a
bit of review on the PR  as
well. By contrast I've seen literally no opposition to CTV based on the
proposal at all.

With regards to the idea that more time is needed to review/discuss. I
wonder if any of those opposed to near term speedy trial of CTV plan on
doing a deeper review/exploration of it in the next year? If not, then what
will delaying do? Are these people simply waiting to see more people in
their social bubble becomes familiar and comfortable with CTV?

> I have a better (and safer) way forward which is to continue to build out
use cases of CTV, convince the community it is the best tool for the job
(whatever use case(s) that is), compare it to other existing covenant
enabling proposals

While I think this is a more valid position to take than your other points,
I disagree with it. I am also sympathetic to the idea that alternatives
should be evaluated and the best one at hand should be chosen. However, it
is a simple fact that the "best" solution possible is almost never going to
be found or created, even after absurd amounts of time (eg millenia). We
live in a time bound world, with time bound human lives. I assume you've
heard of the phrase "don't let the perfect become the enemy of the good". I
assert that your argument is to do just that: to make the perfect become
the enemy of the good.

There is some trade off between time to usage (think time to market) and
the quality of the solution. We didn't choose taproot because it was the
best possible solution, we chose it because it was a pretty good solution
and the solution we had. Yes alternatives have been discussed (at least
since 2013), but alternatives to CTV have also been discussed (eg OP_CAT)
for probably just as long. There have been a number of random
back-of-the-napkin alternative proposals to CTV. None have gained anything
resembling support. I proposed one of them

myself. And I certainly agree that CTV isn't perfect and doesn't do
everything I want it to do. But despite this, I think having CTV is better
than not having it. Even if its eventually mostly replaced by some more
complex 

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[alicexbt via bitcoin-dev]

@DavidHarding

Interesting proposal to revert consensus changes. Is it possible to do this for 
soft forks that are already activated?

Example: Some users are not okay with witness discount in segwit transactions

https://nitter.net/giacomozucco/status/1513614380121927682

@LukeDashjr

> The bigger issue with CTV is the miner-decision route. Either CTV has
> community support, or it doesn't. If it does, miners shouldn't have the
> ability to veto it. If it doesn't, miners shouldn't have the ability to
> activate it (making it a 51% attack more than a softfork).

Agree. UASF client compatible with this speedy trial release for BIP 119 could 
be a better way to activate CTV. Users can decide if they prefer mining pools 
to make the decision for them or they want to enforce it irrespective of how 
many mining pools signal for it. I haven't seen any arguments against CTV from 
mining pools yet.

Sent with [ProtonMail](https://protonmail.com/) secure email.
--- Original Message ---
On Thursday, April 21st, 2022 at 7:35 AM, Luke Dashjr via bitcoin-dev 
bitcoin-dev@lists.linuxfoundation.org wrote:

> 1-2 can be mitigated to some extent by encoding an expiry height in the
> address (and pubkey?), and honouring CTV for UTXOs during the active period.
> It might take longer to remove CTV code post-deactivation, but that's simply
> a tradeoff to consider.
>
> The bigger issue with CTV is the miner-decision route. Either CTV has
> community support, or it doesn't. If it does, miners shouldn't have the
> ability to veto it. If it doesn't, miners shouldn't have the ability to
> activate it (making it a 51% attack more than a softfork).
>
> On Thursday 21 April 2022 01:04:53 David A. Harding via bitcoin-dev wrote:
>
>> Hi all,
>>
>> The main criticisms I'm aware of against CTV seem to be along the
>> following lines:
>>
>> 1. Usage, either:
>> a. It won't receive significant real-world usage, or
>> b. It will be used but we'll end up using something better later
>> 2. An unused CTV will need to be supported forever, creating extra
>> maintenance
>> burden, increasing security surface, and making it harder to evaluate
>> later
>> consensus change proposals due to their interactions with CTV
>>
>> Could those concerns be mitigated by making CTV an automatically
>> reverting
>> consensus change with an option to renew? E.g., redefining OP_NOP4 as
>> OP_CTV
>> for five years from BIP119's activation date and then reverting to
>> OP_NOP4.
>> If, prior to the end of those five years, a second soft fork was
>> activated, it
>> could continue enforcing the CTV rules either for another five years or
>> permanently.
>>
>> This would be similar in nature to the soft fork described in BIP50
>> where the
>> maximum block size was temporarily reduced to address the BDB locks
>> issue and
>> then allowed to return to its original value. In Script terms, any use
>> of
>> OP_CTV would effectively be:
>>
>> OP_IF
>>  OP_CTV
>> OP_ELSE
>> <5 years after activation> OP_CLTV
>> OP_ENDIF
>>
>> As long as we are absolutely convinced CTV will have no negative effects
>> on the
>> holders or receivers of non-CTV coins, I think an automatically
>> reverting soft
>> fork gives us some ability to experiment with new features without
>> committing
>> ourselves to live with them forever.
>>
>> The main downsides I can see are:
>>
>> 1. It creates a big footgun. Anyone who uses CTV without adequately
>> preparing for
>> the reversion could easily lose their money.
>>
>> 2. Miners would be incentivized to censor spends of the reverting
>> opcode near its reversion date. E.g., if Alice receives 100 bitcoins
>> to a
>> script secured only by OP_CTV and attempts to spend them the day
>> before it
>> becomes OP_NOP4, miners might prefer to skip confirming that
>> transaction even
>> if it pays a high feerate in favor of spending her 100 bitcoins to
>> themselves
>> the next day after reversion.
>>
>> The degree to which this is an issue will depend on the diversity of
>> hashrate and the willingness of any large percentage of hashrate to
>> deliberately reorg the chain to remove confirmed transactions. This
>> could be
>> mitigated by having OP_CTV change to OP_RETURN, destroying any
>> unspent CTV-only
>> coins so that any censoring miners only benefited from the (hopefully
>> slight)
>> decrease in bitcoin currency supply.
>>
>> 3. A bias towards keeping the change. Even if it turned out very few
>> people
>> really used CTV, I think there would be a bias at the end of five
>> years towards
>> "why not just keep it".
>>
>> 4. The drama doesn't end. Activating CTV now, or decisively not
>> activating it,
>> may bring to an end our frequent discussions about it (though I
>> wouldn't
>> count on that). An automatically reverting soft fork would probably
>> guarantee we'll have further consensus-level discussions about CTV in
>> the
>> future.
>>
>> Thanks for reading. I'm curious to hear y'alls thoughts,
>>
>> -Dave
>> 

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[Luke Dashjr via bitcoin-dev]

On Thursday 21 April 2022 06:20:15 Jeremy Rubin wrote:
> > While reverting Segwit wouldn't be possible, it IS entirely possible to
> > do an additional softfork to either weigh witness data at the full 4
> > WU/Byte rate (same as other data), or to reduce the total weight limit so
> > as to extend the witness discount to non-segwit transactions (so scriptSig
> > is similarly discounted).
>
> What if I pre signed a transaction which was valid under the discounted
> weighting, but the increase in weight would make it invalid? This would
> serve to confiscate funds. Let's not do that.

You'd be confiscating your own funds by making an absurd spending condition.
By this argument, ALL softforks would have to be ruled out.

> > Furthermore, the variant of Speedy Trial being used (AFAIK) is the BIP9
> > variant which has no purpose other than to try to sabotage parallel UASF
> > efforts.
>
> Why didn't you upstream the code that was used for the actual activation
> into Bitcoin Core in the last year?
>
> In preparing it I just used what was available in Core now, surely the last
> year you could have gotten the appropriate patches done?

They were done, reviewed, and deployed in time for Taproot. You personally 
played a part in sabotaging efforts to get it merged into Core, and violating 
the community's trust in it by instead merging your BIP9 ST without 
consensus. Don't play dumb. You have nobody to blame but yourself.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CTV Signet Parameters

[Jeremy Rubin via bitcoin-dev]

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 


On Thu, Apr 21, 2022 at 1:16 AM Jeremy Rubin 
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 
>
> 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 +, 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 

Re: [bitcoin-dev] Automatically reverting ("transitory") soft forks, e.g. for CTV

[Jeremy Rubin via bitcoin-dev]

> While reverting Segwit wouldn't be possible, it IS entirely possible to
do an
> additional softfork to either weigh witness data at the full 4 WU/Byte
rate
> (same as other data), or to reduce the total weight limit so as to extend
the
> witness discount to non-segwit transactions (so scriptSig is similarly
> discounted).

What if I pre signed a transaction which was valid under the discounted
weighting, but the increase in weight would make it invalid? This would
serve to confiscate funds. Let's not do that.



> Furthermore, the variant of Speedy Trial being used (AFAIK) is the BIP9
> variant which has no purpose other than to try to sabotage parallel UASF
> efforts.

Why didn't you upstream the code that was used for the actual activation
into Bitcoin Core in the last year?

In preparing it I just used what was available in Core now, surely the last
year you could have gotten the appropriate patches done?


--
@JeremyRubin 

On Thu, Apr 21, 2022 at 12:57 AM Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thursday 21 April 2022 03:10:02 alicexbt wrote:
> > @DavidHarding
> >
> > Interesting proposal to revert consensus changes. Is it possible to do
> this
> > for soft forks that are already activated?
>
> Generally, no. Reverting a softfork without a built-in expiry would be a
> hardfork.
>
> > Example: Some users are not okay with witness discount in segwit
> > transactions
> >
> > https://nitter.net/giacomozucco/status/1513614380121927682
>
> While reverting Segwit wouldn't be possible, it IS entirely possible to do
> an
> additional softfork to either weigh witness data at the full 4 WU/Byte
> rate
> (same as other data), or to reduce the total weight limit so as to extend
> the
> witness discount to non-segwit transactions (so scriptSig is similarly
> discounted).
>
> > @LukeDashjr
> >
> > > The bigger issue with CTV is the miner-decision route. Either CTV has
> > > community support, or it doesn't. If it does, miners shouldn't have the
> > > ability to veto it. If it doesn't, miners shouldn't have the ability to
> > > activate it (making it a 51% attack more than a softfork).
> >
> > Agree. UASF client compatible with this speedy trial release for BIP 119
> > could be a better way to activate CTV. Users can decide if they prefer
> > mining pools to make the decision for them or they want to enforce it
> > irrespective of how many mining pools signal for it. I haven't seen any
> > arguments against CTV from mining pools yet.
>
> We had that for Taproot, and now certain people are trying to say Speedy
> Trial
> activated Taproot rather than the BIP8 client, and otherwise creating
> confusion and ambiguity.
>
> Furthermore, the variant of Speedy Trial being used (AFAIK) is the BIP9
> variant which has no purpose other than to try to sabotage parallel UASF
> efforts.
>
> At this point, it is probably better for any Speedy Trial attempts to be
> rejected by the community and fail outright. Perhaps even preparing a real
> counter-softfork to invalidate blocks signalling for it.
>
> Luke
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CTV Signet Parameters

[Jeremy Rubin via bitcoin-dev]

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 

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 +, 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