[bitcoin-dev] Swift Activation - CTV

[bitcoin-dev] Swift Activation - CTV

[alicexbt]

Hello World,

Note: This is not an attack on bitcoin. This is an email with some text and links. Users can decide what works best for themselves. There is also scope for discussion about changing method or params.

I want to keep it short and no energy left. I have explored different options for activation and this feels the safest at this point in 2023. I have not done any magic or innovation but updated activation params. If you agree with them, please run this client else build your own. Anyone who calls this attack and do not build alternative option is an attack in itself.

It activates CTV which is simple covenant proposal and achieves what we expect it to. It is upgradeable.  I like simple things, at least to start with.

Activation parameters: 

```
        consensus.vDeployments[Consensus::DEPLOYMENT_COVTOOLS].nStartTime = 1704067200;
        consensus.vDeployments[Consensus::DEPLOYMENT_COVTOOLS].nTimeout = 1727740800;
        consensus.vDeployments[Consensus::DEPLOYMENT_COVTOOLS].min_activation_height = 874874; 
```

I need payment pools and it does it for me. Apart from that it enables vaults, congestion control etc. We have more PoCs for CTV than we had for taproot and I understand it better.

If you agree with me, please build and run this client before 01 Jan 2024 else we can discuss ordinals for next 5 years and activate something in 2028.

Cheers

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

Re: [bitcoin-dev] Swift Activation - CTV

[Luke Dashjr]

This IS INDEED an attack on Bitcoin. It does not activate CTV - it would 
(if users are fooled into using it) give MINERS the OPTION to activate 
CTV. Nobody should run this, and if it gets any traction, it would 
behoove the community to develop and run a "URSF" making blocks 
signalling for it invalid.

Luke


On 12/19/23 20:44, alicexbt via bitcoin-dev wrote:
> Hello World,
>
> Note: This is not an attack on bitcoin. This is an email with some text and links. Users can decide what works best for themselves. There is also scope for discussion about changing method or params.
>
> I want to keep it short and no energy left. I have explored different options for activation and this feels the safest at this point in 2023. I have not done any magic or innovation but updated activation params. If you agree with them, please run this client else build your own. Anyone who calls this attack and do not build alternative option is an attack in itself.
>
> It activates CTV which is simple covenant proposal and achieves what we expect it to. It is upgradeable.  I like simple things, at least to start with.
>
> Activation parameters:
>
> ```
>          consensus.vDeployments[Consensus::DEPLOYMENT_COVTOOLS].nStartTime = 1704067200;
>          consensus.vDeployments[Consensus::DEPLOYMENT_COVTOOLS].nTimeout = 1727740800;
>          consensus.vDeployments[Consensus::DEPLOYMENT_COVTOOLS].min_activation_height = 874874;
> ```
>
> I need payment pools and it does it for me. Apart from that it enables vaults, congestion control etc. We have more PoCs for CTV than we had for taproot and I understand it better.
>
> If you agree with me, please build and run this client before 01 Jan 2024 else we can discuss ordinals for next 5 years and activate something in 2028.
>
> Cheers
>
> /dev/fd0
> floppy disk guy
>
> Sent with Proton Mail secure email.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

Re: [bitcoin-dev] Swift Activation - CTV

[alicexbt]

Hi Luke,

This is not the first time I am writing this but you keep ignoring it and threaten with URSF. Please build BIP 8 client with LOT=TRUE if you think its the best way to activate and share it so that users can run it.

I had created this branch specifically for it but needed help which I didn't get: https://github.com/xbtactivation/bitcoin/tree/bip8-ctv

Discussing trade-offs involved in different activation methods and providing options to users is not an attack.

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

On Friday, December 22nd, 2023 at 1:05 AM, Luke Dashjr <luke@dashjr.org> wrote:


> This IS INDEED an attack on Bitcoin. It does not activate CTV - it would
> (if users are fooled into using it) give MINERS the OPTION to activate
> CTV. Nobody should run this, and if it gets any traction, it would
> behoove the community to develop and run a "URSF" making blocks
> signalling for it invalid.
> 
> Luke
> 
> 
> On 12/19/23 20:44, alicexbt via bitcoin-dev wrote:
> 
> > Hello World,
> > 
> > Note: This is not an attack on bitcoin. This is an email with some text and links. Users can decide what works best for themselves. There is also scope for discussion about changing method or params.
> > 
> > I want to keep it short and no energy left. I have explored different options for activation and this feels the safest at this point in 2023. I have not done any magic or innovation but updated activation params. If you agree with them, please run this client else build your own. Anyone who calls this attack and do not build alternative option is an attack in itself.
> > 
> > It activates CTV which is simple covenant proposal and achieves what we expect it to. It is upgradeable. I like simple things, at least to start with.
> > 
> > Activation parameters:
> > 
> > `consensus.vDeployments[Consensus::DEPLOYMENT_COVTOOLS].nStartTime = 1704067200; consensus.vDeployments[Consensus::DEPLOYMENT_COVTOOLS].nTimeout = 1727740800; consensus.vDeployments[Consensus::DEPLOYMENT_COVTOOLS].min_activation_height = 874874;`
> > 
> > I need payment pools and it does it for me. Apart from that it enables vaults, congestion control etc. We have more PoCs for CTV than we had for taproot and I understand it better.
> > 
> > If you agree with me, please build and run this client before 01 Jan 2024 else we can discuss ordinals for next 5 years and activate something in 2028.
> > 
> > Cheers
> > 
> > /dev/fd0
> > floppy disk guy
> > 
> > Sent with Proton Mail secure email.
> > 
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Swift Activation - CTV

[alicexbt]

Hi Bitcoin Developers,

I think CTV is not ready for activation yet. Although I want it to be activated and use payment pools, we still have some work to do and AJ is correct that we need to build more apps that use CTV on signet.

Reasons:

- Apart from a few PoCs that do not achieve anything big on mainnet, nobody has tried to build PoC for a use case that solves real problems
- There is a bounty of 0.01 BTC to 1 BTC for creating such PoCs: https://bipbounty.org/bounties/1e101655-bad8-5147-82f7-f03145d567af/
- Some developers think TXHASH fixes all the issues although it doesn't so they need to be reviewed, tested and discussed
- There is no clarity on activation method for CTV
- Many users and developers believe timeline for activation is too aggressive, we should be patient and give more time for start and delay activation for 2 years

_reardencode_ is working on something which might improve things for CTV and covenants in general.

I have created an issue and if someone could close it with a PR that would be helpful: https://github.com/bitcoin-inquisition/bitcoin/issues/44

I apologize if my email caused any drama although most personal attacks were targeted towards people supporting CTV including me. Maybe one day we will have covenants on bitcoin to improve scaling and privacy.

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

On Friday, December 22nd, 2023 at 1:56 AM, alicexbt via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:


> Hi Luke,
> 
> This is not the first time I am writing this but you keep ignoring it and threaten with URSF. Please build BIP 8 client with LOT=TRUE if you think its the best way to activate and share it so that users can run it.
> 
> I had created this branch specifically for it but needed help which I didn't get: https://github.com/xbtactivation/bitcoin/tree/bip8-ctv
> 
> Discussing trade-offs involved in different activation methods and providing options to users is not an attack.
> 
> /dev/fd0
> floppy disk guy
> 
> Sent with Proton Mail secure email.
> 
> 
> On Friday, December 22nd, 2023 at 1:05 AM, Luke Dashjr luke@dashjr.org wrote:
> 
> 
> 
> > This IS INDEED an attack on Bitcoin. It does not activate CTV - it would
> > (if users are fooled into using it) give MINERS the OPTION to activate
> > CTV. Nobody should run this, and if it gets any traction, it would
> > behoove the community to develop and run a "URSF" making blocks
> > signalling for it invalid.
> > 
> > Luke
> > 
> > On 12/19/23 20:44, alicexbt via bitcoin-dev wrote:
> > 
> > > Hello World,
> > > 
> > > Note: This is not an attack on bitcoin. This is an email with some text and links. Users can decide what works best for themselves. There is also scope for discussion about changing method or params.
> > > 
> > > I want to keep it short and no energy left. I have explored different options for activation and this feels the safest at this point in 2023. I have not done any magic or innovation but updated activation params. If you agree with them, please run this client else build your own. Anyone who calls this attack and do not build alternative option is an attack in itself.
> > > 
> > > It activates CTV which is simple covenant proposal and achieves what we expect it to. It is upgradeable. I like simple things, at least to start with.
> > > 
> > > Activation parameters:
> > > 
> > > `consensus.vDeployments[Consensus::DEPLOYMENT_COVTOOLS].nStartTime = 1704067200; consensus.vDeployments[Consensus::DEPLOYMENT_COVTOOLS].nTimeout = 1727740800; consensus.vDeployments[Consensus::DEPLOYMENT_COVTOOLS].min_activation_height = 874874;`
> > > 
> > > I need payment pools and it does it for me. Apart from that it enables vaults, congestion control etc. We have more PoCs for CTV than we had for taproot and I understand it better.
> > > 
> > > If you agree with me, please build and run this client before 01 Jan 2024 else we can discuss ordinals for next 5 years and activate something in 2028.
> > > 
> > > Cheers
> > > 
> > > /dev/fd0
> > > floppy disk guy
> > > 
> > > Sent with Proton Mail secure email.
> > > 
> > > _______________________________________________
> > > 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] Swift Activation - CTV

[Anthony Towns]

Huh, this list is still active?

On Fri, Dec 22, 2023 at 10:34:52PM +0000, alicexbt via bitcoin-dev wrote:
> I think CTV is not ready for activation yet. Although I want it to be activated and use payment pools, we still have some work to do and AJ is correct that we need to build more apps that use CTV on signet.

I've said it before, and I'll say it again, but if you want to change
bitcoin consensus rules, IMO the sensible process is:

 * work out what you think the change should be
 * demonstrate the benefits so everyone can clearly see what they are,
   and that they're worth spending time on
 * review the risks, so that whatever risks there may be are well
   understood, and minimise them
 * iterate on all three of those steps to increase the benefits and
   reduce the risks
 * once "everyone" agrees the benefits are huge and the risks are low,
   work on activating it

If you're having trouble demonstrating that the benefits really are
worth spending time on, you probably need to go back to the first step
and reconsider the proposal. The "covtools" and "op_cat" approaches are
a modest way of doing that: adding additional opcodes that mesh well
with CTV, increasing the benefits from making a change.

But "target fixation" [0] is a thing too: maybe "CTV" (and/or "APO")
were just a bad approach from the start. Presumably "activate CTV"
is really intended as a step towards your actual goal, whether that be
"make it harder for totalitarians to censor payments", "replace credit
cards", "make lots of money", "take control over bitcoind evelopment",
or something else. Maybe there's a better step towards some/all of
whatever those goals may be than "activate CTV". Things like "txhash"
take that approach and go back to the first step.

To me, it seems like CTV has taken the odd approach of simultaneously
maximising (at least perceived) risk, while minimising the potential
benefits. As far as maximising risk goes, it's taken Greg Maxwell's
"amusingly bad idea" post from bitcointalk in 2013 [1] and made the bad
consequence described there (namely, "coin covenants", which left Greg
"screaming in horror") as the centrepiece of the functionality being
added, per its motivation section. It then minimises the potential
benefits that accompany that risk by restricting the functionality being
provided as far as you can without neutering it entirely. If you *wanted*
a recipe for how to propose a change to bitcoin and ensure that it's
doomed to fail while still gathering a lot of attention, I'm honestly
not sure how you could come up with a better approach?

[0] https://en.wikipedia.org/wiki/Target_fixation
[1] https://bitcointalk.org/index.php?topic=278122.0

> - Apart from a few PoCs that do not achieve anything big on mainnet, nobody has tried to build PoC for a use case that solves real problems

One aspect of "minimising the benefits" is that when you make something
too child safe, it can become hard to actually use the tool at all. Just
having ideas is easy -- you can just handwave over the complex parts
when you're whiteboarding or blogging -- the real way to test if a tool
is fit for purpose is to use it to build something worthwhile. Maybe a
great chef can create a great meal with an easy-bake oven, but there's
a reason it's not their tool of choice.

Cheers,
aj

Re: [bitcoin-dev] Swift Activation - CTV

[Erik Aronesty]

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

So what exactly are the risks of CTV over multi-sig?


>
>

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

Re: [bitcoin-dev] Swift Activation - CTV

[Michael Folkson]

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

Hi Erik

> So what exactly are the risks of CTV over multi-sig?

It is a strange comparison. Multisig is active onchain and is being used today for all sorts of things including Lightning and setups that address risk of single key loss or malicious signing. When discussing risks of CTV there are all sorts of risks that don't apply to multisig. These include that it is never used for any of its speculated use cases (multisig is being used today), other proposals end up being used instead of it (I'm not sure there were or are competing proposals so that multisig stops being used, MuSig2 maybe?), chain split risks with activation if there isn't consensus to activate it etc. Plus usage of complex (non covenant) scripts that fully utilize Taproot trees is still low today. Going straight to covenants (imposing restrictions on where​ funds can be sent) and not bothering with imposing all the restrictions you'd like on how​ funds can be spent in the first place seems to me to be putting the cart before the horse. Covenants don't ultimately solve the key management issue, they just move it from the pre spending phase to the post spending phase. So the benefits (although non-zero) aren't as obvious as some of the covenant advocates are suggesting. And although CTV is a limited covenant (some argue too limited) covenants taken to wild extremes could create all sorts of second order effects where funds can't be spent because of complex combinations of covenants. Even the strongest CTV proponent seems to suggest that the introduction of covenants wouldn't end with CTV.

The way to reduce implementation risk for a use case of a particular proposal is to build out that use case and see if CTV is the best tool for the job. Repeatedly trying to activate CTV when there isn't consensus for it to be activated does not reduce that implementation risk in any way, shape or form.

Thanks
Michael

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F

Learn about Bitcoin: https://www.youtube.com/@portofbitcoin

On Saturday, 30 December 2023 at 08:59, Erik Aronesty via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> So what exactly are the risks of CTV over multi-sig?
>
>>

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

Re: [bitcoin-dev] Swift Activation - CTV

[Erik Aronesty]

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

1. Claiming that something that isn't activated (unusable) isn't used as a
non-argument

2. Talking about activation methods is orthogonal.  Bip8 is fine.

3. Covenants allow trustless utxos sharing and also are needed for
vaulting.  The numerous use cases are documented, built out and on signet
to my knowledge.  Check out utxos.org for a good list

3. No need to discuss wild extremes that are unrelated to ctvs well
documented utility.  Plus multi-sig allows governments to encumber (or
accidentally ruin) destination addresses just like covenants.

4. "Best tool for the job" is not the bar. "Safe for all" and "useful for
some" is the bar. Like any opcodes or tech Bitcoin has deployed in the
past.  Changing the bar is not up for discussion.


CTV has already been demonstrated "useful for some".  The question that
needs to be answered is whether there are any specific objections to safety.









On Mon, Jan 1, 2024, 11:37 AM Michael Folkson <michaelfolkson@protonmail.com>
wrote:

> Hi Erik
>
> > So what exactly are the risks of CTV over multi-sig?
>
> It is a strange comparison. Multisig is active onchain and is being used
> today for all sorts of things including Lightning and setups that address
> risk of single key loss or malicious signing. When discussing risks of CTV
> there are all sorts of risks that don't apply to multisig. These include
> that it is never used for any of its speculated use cases (multisig is
> being used today), other proposals end up being used instead of it (I'm not
> sure there were or are competing proposals so that multisig stops being
> used, MuSig2 maybe?), chain split risks with activation if there isn't
> consensus to activate it etc. Plus usage of complex (non covenant) scripts
> that fully utilize Taproot trees is still low today. Going straight to
> covenants (imposing restrictions on *where*​ funds can be sent) and not
> bothering with imposing all the restrictions you'd like on *how*​ funds
> can be spent in the first place seems to me to be putting the cart before
> the horse. Covenants don't ultimately solve the key management issue, they
> just move it from the pre spending phase to the post spending phase. So the
> benefits (although non-zero) aren't as obvious as some of the covenant
> advocates are suggesting. And although CTV is a limited covenant (some
> argue too limited) covenants taken to wild extremes could create all sorts
> of second order effects where funds can't be spent because of complex
> combinations of covenants. Even the strongest CTV proponent seems to
> suggest that the introduction of covenants wouldn't end with CTV.
>
> The way to reduce implementation risk for a use case of a particular
> proposal is to build out that use case and see if CTV is the best tool for
> the job. Repeatedly trying to activate CTV when there isn't consensus for
> it to be activated does not reduce that implementation risk in any way,
> shape or form.
>
> Thanks
> Michael
>
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>
> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>
> On Saturday, 30 December 2023 at 08:59, Erik Aronesty via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> So what exactly are the risks of CTV over multi-sig?
>
>
>>
>>
>

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

Re: [bitcoin-dev] Swift Activation - CTV

[Michael Folkson]

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

In the interests of time I'll just pick two to respond to but I don't agree with any of your points.

> Covenants allow trustless utxos sharing and also are needed for vaulting. The numerous use cases are documented, built out and on signet to my knowledge. Check out[utxos.org](http://utxos.org/)for a good list

Your knowledge is incorrect. As far as I know in the getting on for 2 years since the first CTV activation talk/attempt literally no one has built out a CTV use case and demonstrated it on signet with the possible exception of James O'Beirne's OP_VAULT which requires other new opcodes in addition to CTV. I wish this wasn't the case. It is pitiful that we have these individuals (such as yourself) that are so convinced CTV should be activated but refuse to address any concerns raised by others and refuse to work on any of the speculated use cases, instead choosing to just beat the activation drum over and over again.

> 4. "Best tool for the job" is not the bar. "Safe for all" and "useful for some" is the bar. Like any opcodes or tech Bitcoin has deployed in the past. Changing the bar is not up for discussion.

If you want to avoid a chain split with an activation attempt (it is possible you don't care but if you do) you have to address concerns others have with a particular proposal. Just because Satoshi was able to make whatever changes he liked in the early days of Bitcoin's history and smaller groups of contributors then were able to activate changes without much scrutiny (Bitcoin was worth a fraction of what it is today and was only supporting a tiny ecosystem back then) doesn't mean we can do the same today. Appointing Erik as the new Satoshi who can make whatever changes he likes, who defines the bar with ultimate certainty and decides what is and what isn't up for discussion also isn't a viable option.

Thanks
Michael

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F

Learn about Bitcoin: https://www.youtube.com/@portofbitcoin

On Monday, 1 January 2024 at 17:11, Erik Aronesty <erik@q32.com> wrote:

> 1. Claiming that something that isn't activated (unusable) isn't used as a non-argument
>
> 2. Talking about activation methods is orthogonal. Bip8 is fine.
>
> 3. Covenants allow trustless utxos sharing and also are needed for vaulting. The numerous use cases are documented, built out and on signet to my knowledge. Check out utxos.org for a good list
>
> 3. No need to discuss wild extremes that are unrelated to ctvs well documented utility. Plus multi-sig allows governments to encumber (or accidentally ruin) destination addresses just like covenants.
>
> 4. "Best tool for the job" is not the bar. "Safe for all" and "useful for some" is the bar. Like any opcodes or tech Bitcoin has deployed in the past. Changing the bar is not up for discussion.
>
> CTV has already been demonstrated "useful for some". The question that needs to be answered is whether there are any specific objections to safety.
>
> On Mon, Jan 1, 2024, 11:37 AM Michael Folkson <michaelfolkson@protonmail.com> wrote:
>
>> Hi Erik
>>
>>> So what exactly are the risks of CTV over multi-sig?
>>
>> It is a strange comparison. Multisig is active onchain and is being used today for all sorts of things including Lightning and setups that address risk of single key loss or malicious signing. When discussing risks of CTV there are all sorts of risks that don't apply to multisig. These include that it is never used for any of its speculated use cases (multisig is being used today), other proposals end up being used instead of it (I'm not sure there were or are competing proposals so that multisig stops being used, MuSig2 maybe?), chain split risks with activation if there isn't consensus to activate it etc. Plus usage of complex (non covenant) scripts that fully utilize Taproot trees is still low today. Going straight to covenants (imposing restrictions on where​ funds can be sent) and not bothering with imposing all the restrictions you'd like on how​ funds can be spent in the first place seems to me to be putting the cart before the horse. Covenants don't ultimately solve the key management issue, they just move it from the pre spending phase to the post spending phase. So the benefits (although non-zero) aren't as obvious as some of the covenant advocates are suggesting. And although CTV is a limited covenant (some argue too limited) covenants taken to wild extremes could create all sorts of second order effects where funds can't be spent because of complex combinations of covenants. Even the strongest CTV proponent seems to suggest that the introduction of covenants wouldn't end with CTV.
>>
>> The way to reduce implementation risk for a use case of a particular proposal is to build out that use case and see if CTV is the best tool for the job. Repeatedly trying to activate CTV when there isn't consensus for it to be activated does not reduce that implementation risk in any way, shape or form.
>>
>> Thanks
>> Michael
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>>
>> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>>
>> On Saturday, 30 December 2023 at 08:59, Erik Aronesty via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> So what exactly are the risks of CTV over multi-sig?
>>>
>>>>

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

Re: [bitcoin-dev] Swift Activation - CTV

[Erik Aronesty]

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

On Tue, Jan 2, 2024, 8:52 AM Michael Folkson <michaelfolkson@protonmail.com>
wrote:

> In the interests of time I'll just pick two to respond to but I don't
> agree with any of your points.
>
> > Covenants allow trustless utxos sharing and also are needed for
> vaulting. The numerous use cases are documented, built out and on signet to
> my knowledge. Check out utxos.org for a good list
>
> Your knowledge is incorrect. As far as I know in the getting on for 2
> years since the first CTV activation talk/attempt literally no one has
> built out a CTV use case and demonstrated it on signet with the possible
> exception of James O'Beirne's OP_VAULT which requires other new opcodes in
> addition to CTV.
>

Nice example, thanks.

>
> > 4. "Best tool for the job" is not the bar. "Safe for all" and "useful
> for some" is the bar.
>

This is the bar, ant CTV has passed it with vaulting alone.

If you want to avoid a chain split with an activation attempt (it is
> possible you don't care but if you do) you have to address concerns others
> have with a particular proposal.
>

You haven't mentioned one safety concern.  It's hard to tell if you have
any.  There is, of course, the elephant in the room with CTV that is a true
concern that nobody talks about.

The real danger of CTV isn't whether it's the best, and we know it's
nonrecursive.  And we can use BIP8, so that isn't an issue either.

And we already have shitcoins on BTC, so sapio shouldn't be your issue (
https://github.com/sapio-lang/sapio)

Why exactly is your problem?  You yourself have admitted it's useful for
vaulting, and for reducing the cost of lightning onboarding, even though
you ignored the dozens of other use cases enumerated in detail on utxos.org
and elsewhere.

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

Re: [bitcoin-dev] Swift Activation - CTV

[Ryan Breen]

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



> On Jan 2, 2024, at 10:50 AM, Michael Folkson via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> Your knowledge is incorrect. As far as I know in the getting on for 2 years since the first CTV activation talk/attempt literally no one has built out a CTV use case and demonstrated it on signet with the possible exception of James O'Beirne's OP_VAULT which requires other new opcodes in addition to CTV. I wish this wasn't the case. It is pitiful that we have these individuals (such as yourself) that are so convinced CTV should be activated but refuse to address any concerns raised by others and refuse to work on any of the speculated use cases, instead choosing to just beat the activation drum over and over again.

James O’Beirne built a CTV-only vault prototype[1], actually. Jeremy Rubin also built vaults and many other prototypes with his Sapio smart contracting language.[2]

So this assertion that CTV has had no use cases or prototypes built out for it is just not true.

[1]: https://github.com/jamesob/simple-ctv-vault
[2]: https://github.com/sapio-lang/sapio

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

Re: [bitcoin-dev] Swift Activation - CTV

[alicexbt]

> Your knowledge is incorrect. As far as I know in the getting on for 2 years since the first CTV activation talk/attempt literally no one has built out a CTV use case and demonstrated it on signet with the possible exception of James O'Beirne's OP_VAULT which requires other new opcodes in addition to CTV. 

This is not true.

https://github.com/AdamISZ/pathcoin-poc

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

On Tuesday, January 2nd, 2024 at 1:52 PM, Michael Folkson via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:


> In the interests of time I'll just pick two to respond to but I don't agree with any of your points.
> 
> > Covenants allow trustless utxos sharing and also are needed for vaulting. The numerous use cases are documented, built out and on signet to my knowledge. Check out utxos.org for a good list
> 
> Your knowledge is incorrect. As far as I know in the getting on for 2 years since the first CTV activation talk/attempt literally no one has built out a CTV use case and demonstrated it on signet with the possible exception of James O'Beirne's OP_VAULT which requires other new opcodes in addition to CTV. I wish this wasn't the case. It is pitiful that we have these individuals (such as yourself) that are so convinced CTV should be activated but refuse to address any concerns raised by others and refuse to work on any of the speculated use cases, instead choosing to just beat the activation drum over and over again.
> 
> > 4. "Best tool for the job" is not the bar. "Safe for all" and "useful for some" is the bar. Like any opcodes or tech Bitcoin has deployed in the past. Changing the bar is not up for discussion.
> 
> If you want to avoid a chain split with an activation attempt (it is possible you don't care but if you do) you have to address concerns others have with a particular proposal. Just because Satoshi was able to make whatever changes he liked in the early days of Bitcoin's history and smaller groups of contributors then were able to activate changes without much scrutiny (Bitcoin was worth a fraction of what it is today and was only supporting a tiny ecosystem back then) doesn't mean we can do the same today. Appointing Erik as the new Satoshi who can make whatever changes he likes, who defines the bar with ultimate certainty and decides what is and what isn't up for discussion also isn't a viable option.
> 
> Thanks
> Michael
> 
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
> 
> 
> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
> 
> 
> On Monday, 1 January 2024 at 17:11, Erik Aronesty <erik@q32.com> wrote:
> 
> 
> > 1. Claiming that something that isn't activated (unusable) isn't used as a non-argument
> > 2. Talking about activation methods is orthogonal. Bip8 is fine.
> > 
> > 3. Covenants allow trustless utxos sharing and also are needed for vaulting. The numerous use cases are documented, built out and on signet to my knowledge. Check out utxos.org for a good list
> > 
> > 3. No need to discuss wild extremes that are unrelated to ctvs well documented utility. Plus multi-sig allows governments to encumber (or accidentally ruin) destination addresses just like covenants.
> > 
> > 4. "Best tool for the job" is not the bar. "Safe for all" and "useful for some" is the bar. Like any opcodes or tech Bitcoin has deployed in the past. Changing the bar is not up for discussion.
> > 
> > 
> > CTV has already been demonstrated "useful for some". The question that needs to be answered is whether there are any specific objections to safety.
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > On Mon, Jan 1, 2024, 11:37 AM Michael Folkson <michaelfolkson@protonmail.com> wrote:
> > 
> > > Hi Erik
> > > 
> > > 
> > > > So what exactly are the risks of CTV over multi-sig?
> > > 
> > > 
> > > It is a strange comparison. Multisig is active onchain and is being used today for all sorts of things including Lightning and setups that address risk of single key loss or malicious signing. When discussing risks of CTV there are all sorts of risks that don't apply to multisig. These include that it is never used for any of its speculated use cases (multisig is being used today), other proposals end up being used instead of it (I'm not sure there were or are competing proposals so that multisig stops being used, MuSig2 maybe?), chain split risks with activation if there isn't consensus to activate it etc. Plus usage of complex (non covenant) scripts that fully utilize Taproot trees is still low today. Going straight to covenants (imposing restrictions on where funds can be sent) and not bothering with imposing all the restrictions you'd like on how funds can be spent in the first place seems to me to be putting the cart before the horse. Covenants don't ultimately solve the key management issue, they just move it from the pre spending phase to the post spending phase. So the benefits (although non-zero) aren't as obvious as some of the covenant advocates are suggesting. And although CTV is a limited covenant (some argue too limited) covenants taken to wild extremes could create all sorts of second order effects where funds can't be spent because of complex combinations of covenants. Even the strongest CTV proponent seems to suggest that the introduction of covenants wouldn't end with CTV.
> > > 
> > > 
> > > The way to reduce implementation risk for a use case of a particular proposal is to build out that use case and see if CTV is the best tool for the job. Repeatedly trying to activate CTV when there isn't consensus for it to be activated does not reduce that implementation risk in any way, shape or form.
> > > 
> > > 
> > > Thanks
> > > Michael
> > > 
> > > 
> > > --
> > > Michael Folkson
> > > Email: michaelfolkson at protonmail.com
> > > GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
> > > 
> > > 
> > > Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
> > > 
> > > 
> > > On Saturday, 30 December 2023 at 08:59, Erik Aronesty via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > > 
> > > 
> > > > So what exactly are the risks of CTV over multi-sig?
> > > > 
> > > > 
> > > > > 
> > > > >

Re: [bitcoin-dev] Swift Activation - CTV

[Michael Folkson]

Hey AJ

Thanks for this, pretty much agree with all of it. It seems like a week doesn't go by now without a new individual popping out the woodwork proposing an upcoming activation of CTV with no new PoCs and no new insights. I'm not sure what it is about CTV (versus say other proposals) that it keeps attracting these people that refuse to work on PoCs or anything that drives the research area forward and yet want to try to attempt activation where the success scenario would be a chain split.

> > But "target fixation" [0] is a thing too: maybe "CTV" (and/or "APO") were just a bad approach from the start.

It is hard to discuss APO in a vacuum when this is going on the background but I'm interested in you grouping APO with CTV in this statement. At the time of writing there clearly isn't consensus or advanced PoCs on any of the use cases CTV claims to enable. (One rare exception on the use case front is James O'Beirne's OP_VAULT [0] that requires additional opcodes to OP_CTV). But APO does seem to be the optimal design and have broad consensus in the Lightning community for enabling eltoo/LN-Symmetry. Any other use cases APO enables would be an additional benefit.

I don't think one can seriously think about an *upcoming* activation for APO as there is still more work to do to convince the community that it would be worth the risks of embarking on another activation process. But assuming another year of concerted work on APO and the CTV woodwork of chaos (hopefully) being exhausted do you think an APO activation would be viable in say 2025/2026? Is your hesitancy on APO based on any particular technical concerns or just fatigue from the CTV chaos?

Thanks
Michael

[0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.html

--
Michael Folkson
Email: michaelfolkson at protonmail.com
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F

Learn about Bitcoin: https://www.youtube.com/@portofbitcoin


On Saturday, 30 December 2023 at 08:05, Anthony Towns via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:


> Huh, this list is still active?
> 
> On Fri, Dec 22, 2023 at 10:34:52PM +0000, alicexbt via bitcoin-dev wrote:
> 
> > I think CTV is not ready for activation yet. Although I want it to be activated and use payment pools, we still have some work to do and AJ is correct that we need to build more apps that use CTV on signet.
> 
> 
> I've said it before, and I'll say it again, but if you want to change
> bitcoin consensus rules, IMO the sensible process is:
> 
> * work out what you think the change should be
> * demonstrate the benefits so everyone can clearly see what they are,
> and that they're worth spending time on
> * review the risks, so that whatever risks there may be are well
> understood, and minimise them
> * iterate on all three of those steps to increase the benefits and
> reduce the risks
> * once "everyone" agrees the benefits are huge and the risks are low,
> work on activating it
> 
> If you're having trouble demonstrating that the benefits really are
> worth spending time on, you probably need to go back to the first step
> and reconsider the proposal. The "covtools" and "op_cat" approaches are
> a modest way of doing that: adding additional opcodes that mesh well
> with CTV, increasing the benefits from making a change.
> 
> But "target fixation" [0] is a thing too: maybe "CTV" (and/or "APO")
> were just a bad approach from the start. Presumably "activate CTV"
> is really intended as a step towards your actual goal, whether that be
> "make it harder for totalitarians to censor payments", "replace credit
> cards", "make lots of money", "take control over bitcoind evelopment",
> or something else. Maybe there's a better step towards some/all of
> whatever those goals may be than "activate CTV". Things like "txhash"
> take that approach and go back to the first step.
> 
> To me, it seems like CTV has taken the odd approach of simultaneously
> maximising (at least perceived) risk, while minimising the potential
> benefits. As far as maximising risk goes, it's taken Greg Maxwell's
> "amusingly bad idea" post from bitcointalk in 2013 [1] and made the bad
> consequence described there (namely, "coin covenants", which left Greg
> "screaming in horror") as the centrepiece of the functionality being
> added, per its motivation section. It then minimises the potential
> benefits that accompany that risk by restricting the functionality being
> provided as far as you can without neutering it entirely. If you wanted
> a recipe for how to propose a change to bitcoin and ensure that it's
> doomed to fail while still gathering a lot of attention, I'm honestly
> not sure how you could come up with a better approach?
> 
> [0] https://en.wikipedia.org/wiki/Target_fixation
> [1] https://bitcointalk.org/index.php?topic=278122.0
> 
> > - Apart from a few PoCs that do not achieve anything big on mainnet, nobody has tried to build PoC for a use case that solves real problems
> 
> 
> One aspect of "minimising the benefits" is that when you make something
> too child safe, it can become hard to actually use the tool at all. Just
> having ideas is easy -- you can just handwave over the complex parts
> when you're whiteboarding or blogging -- the real way to test if a tool
> is fit for purpose is to use it to build something worthwhile. Maybe a
> great chef can create a great meal with an easy-bake oven, but there's
> a reason it's not their tool of choice.
> 
> Cheers,
> aj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Swift Activation - CTV

[Anthony Towns]

On Sat, Dec 30, 2023 at 01:54:04PM +0000, Michael Folkson via bitcoin-dev wrote:
> > > But "target fixation" [0] is a thing too: maybe "CTV" (and/or "APO") were just a bad approach from the start.
> It is hard to discuss APO in a vacuum when this is going on the background but I'm interested in you grouping APO with CTV in this statement. ... But APO does seem to be the optimal design and have broad consensus in the Lightning community for enabling eltoo/LN-Symmetry. Any other use cases APO enables would be an additional benefit.

I guess I'm really just reiterating/expanding on Russell's thoughts from
two years ago:

  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html

CTV and APO both take the approach of delineating a small, precise piece
of functionality that is thought to be useful in known ways, and making
that available for use within Bitcoin. But doing incremental consensus
changes every time we discover new features that we'd like to add to
wallet/L2 software is kind of clumsy, and perhaps we should be looking
at more general approaches that allow more things at once.

Beyond that, APO also follows the design of satoshi's ANYONECANPAY,
which allows attaching other inputs. There's a decent argument to be
made that that's a bad design choice (and was perhaps a bad choice
for ANYONECANPAY as well as APO), and that committing to the number of
inputs would still be a valable thing to do (in that it minimises how
much third parties can manipulate your tx, and reduces the potential for
rbf pinning). A consequence of that is that once if you fix the number
of inputs to one and already know the input you're spending, you avoid
txid malleability. See https://github.com/bitcoin/bips/pull/1472 eg.

Cheers,
aj