Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Billy Tetrud via bitcoin-dev]

> look at how lightning ate up fees to keep bitcoin stable, we can't
"scale" too quickly either

I strongly disagree with this. We should be scaling Bitcoin as fast as we
can. There is no reason to delay scaling for the purposes of keeping fees
high. If we need fees to be higher, we can lower the block size or increase
the default minimum relay fee rate.

Also, the idea that use of the LN is there primary cause of recent low fees
is highly dubious.

> the various new uses for on-chain transactions mentioned as a use-case
arguably harms all existing users by competing for scarce blockchain space

Reminds me of that old saying, "nobody goes there anymore, it's too
crowded". ; )


On Mon, Feb 21, 2022, 03:54 Prayank via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Goog morning ZmnSCPxj,
>
> Context: https://bitcointalk.org/index.php?topic=48.msg329#msg329
>
> Maybe I should have rephrased it and quote Satoshi. I agree I should not
> speak for others and it was not my intention in the email.
>
> > If Satoshi refuses to participate in Bitcoin development today, who
> cares what his opinion is?
>
> I care about the opinions especially if consensus rules are not changed
> and remain same as far as subsidy is concerned.
>
> > Satoshi is dead, long live Bitcoin.
>
> I object to such assumptions about the founder of Bitcoin. Satoshi is more
> than a pseudonym and will stay alive forever.
>
> --
> Prayank
>
> A3B1 E430 2298 178F
>
>
>
> Feb 21, 2022, 14:32 by zmnsc...@protonmail.com:
>
> Good morning Prayank,
>
> (offlist)
>
> Satoshi
>
>
> I object to the invocation of Satoshi here, and in general.
> If Satoshi wants to participate in Bitcoin development today, he can speak
> for himself.
> If Satoshi refuses to participate in Bitcoin development today, who cares
> what his opinion is?
> Satoshi is dead, long live Bitcoin.
>
>
> Aside from that, I am otherwise thinking about the various arguments being
> presented.
>
>
> Regards,
> ZmnSCPxj
>
>
> ___
> 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] Stumbling into a contentious soft fork activation attempt

[Prayank via bitcoin-dev]

Goog morning ZmnSCPxj,

Context: https://bitcointalk.org/index.php?topic=48.msg329#msg329

Maybe I should have rephrased it and quote Satoshi. I agree I should not speak 
for others and it was not my intention in the email.

> If Satoshi refuses to participate in Bitcoin development today, who cares 
> what his opinion is?

I care about the opinions especially if consensus rules are not changed and 
remain same as far as subsidy is concerned.

> Satoshi is dead, long live Bitcoin.

I object to such assumptions about the founder of Bitcoin. Satoshi is more than 
a pseudonym and will stay alive forever.

-- 
Prayank

A3B1 E430 2298 178F



Feb 21, 2022, 14:32 by zmnsc...@protonmail.com:

> Good morning Prayank,
>
> (offlist)
>
>> Satoshi
>>
>
> I object to the invocation of Satoshi here, and in general.
> If Satoshi wants to participate in Bitcoin development today, he can speak 
> for himself.
> If Satoshi refuses to participate in Bitcoin development today, who cares 
> what his opinion is?
> Satoshi is dead, long live Bitcoin.
>
>
> Aside from that, I am otherwise thinking about the various arguments being 
> presented.
>
>
> Regards,
> ZmnSCPxj
>

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

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[ZmnSCPxj via bitcoin-dev]

> Good morning Prayank,
>
> (offlist)



My apologies.
I pushed the wrong button, I should have pressed "Reply" and not "Reply All".

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

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[ZmnSCPxj via bitcoin-dev]

Good morning,


> If this is the reason to stop/delay improvements in bitcoin, maybe it applies 
> for Taproot as well although I don't remember reading such things in your 
> posts or maybe missed it.

Perhaps a thing to note, is that if it allows us to move some activity 
off-chain, and reduce activity on the blockchain, then the increase in 
functionality does *not* translate to a requirement of block size increase.

So for example:

* Taproot, by allowing the below improvements, is good:
  * Schnorr multisignatures that allow multiple users to publish a single 
signature, reducing block size usage for large participant sets.
  * MAST, which allows eliding branches of complicated SCRIPTs that are not 
executed, reducing block size usage for complex contracts.
* `SIGHASH_ANYPREVOUT`, by enabling an offchain updateable multiparty (N > 2) 
cryptocurrency system (Decker-Russell-Osuntokun), is also good, as it allows us 
to make channel factories without having to suffer the bad tradeoffs of 
Decker-Wattenhofer.
* `OP_CTV`, by enabling commit-to-unpublished-promised-outputs, is also good, 
as it allows opportunities for transactional cut-through without having to 
publish promised outputs *right now*.

So I do not think the argument should really object to any of the above, either 
--- all these improvements increase the functionality of Bitcoin, but also 
allow opportunities to use the blockchain as judge+jury+executioner instead of 
noisy marketplace.

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

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[ZmnSCPxj via bitcoin-dev]

Good morning Prayank,

(offlist)

>  Satoshi

I object to the invocation of Satoshi here, and in general.
If Satoshi wants to participate in Bitcoin development today, he can speak for 
himself.
If Satoshi refuses to participate in Bitcoin development today, who cares what 
his opinion is?
Satoshi is dead, long live Bitcoin.


Aside from that, I am otherwise thinking about the various arguments being 
presented.


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

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Prayank via bitcoin-dev]

> note how ETH has quite high on chain fees for basic transactions,> because 
> there are so many use-cases where the per-tx value can afford much> higher 
> fees. That kind of expansion of use-case also arguably harms Bitcoin as> a 
> whole by providing more fuel for a future contentious blocksize debate.
>i second this argument

I disagree with this argument, Satoshi won't agree with it either if still 
active and it make no sense. Fees will be the incentives for miners as subsidy 
decreases after every 210,000 blocks and it will depend on demand for block 
space.

There is nothing harmful in it just because something similar is happening in 
an altcoin which has several other issues. Example: if a user has to pay fees 
with 100 sat/vbyte fee rate to open and close channels it will be good for 
Bitcoin in long term.

If this is the reason to stop/delay improvements in bitcoin, maybe it applies 
for Taproot as well although I don't remember reading such things in your posts 
or maybe missed it.

-- 
Prayank

A3B1 E430 2298 178F



Feb 21, 2022, 00:05 by e...@q32.com:

> > note how ETH has quite high on chain fees for basic transactions,
> > because there are so many use-cases where the per-tx value can afford much
> > higher fees. That kind of expansion of use-case also arguably harms Bitcoin 
> > as
> > a whole by providing more fuel for a future contentious blocksize debate.
>
> i second this argument
>
> ideally, all extensions should be explicit use cases, not generic/implicit 
> layers that can be exploited for unknown and possibly harmful use cases
>
> also timing is critical for all bitcoin innovation.   look at how lightning 
> ate up fees
>
> to keep bitcoin stable, we can't "scale" too quickly either
>
> i'm a fan of, eventually (timing is critical), a lightning-compatible 
> mimblewible+dandelion on-chain soft fork can reduce tx size, move us from l2 
> to l3, vastly improve privacy, and get more small transactions off-chain.
>
> but it probably shouldn't be released for another 2 years
>
>
> On Fri, Feb 18, 2022 at 6:41 PM Peter Todd via bitcoin-dev <> 
> bitcoin-dev@lists.linuxfoundation.org> > wrote:
>
>> On Tue, Jan 18, 2022 at 02:57:30AM +0100, Prayank wrote:
>>  > Hi Peter,
>>  > 
>>  > > that current lacks compelling use-cases clearly beneficial to all users
>>  > 
>>  > All the use cases shared in below links look compelling enough to me and 
>> we can do anything that a programmer could think of using such restrictions:
>>  > 
>>  >  >> https://utxos.org/uses/
>>  > 
>>  > >> https://rubin.io/archive/
>>  
>>  Again, what I said was "compelling use-cases _clearly_ beneficial to _all_
>>  users", not just a small subset. I neither think the use-cases in those 
>> links
>>  are clearly compelling in the current form, and they of course, don't 
>> benefit
>>  all users. Indeed, the Drivechains use-case arguably *harms* all users, as
>>  Drivechains is arguably harmful to the security of Bitcoin as a whole.
>>  Similarly, the various new uses for on-chain transactions mentioned as a
>>  use-case arguably harms all existing users by competing for scarce 
>> blockchain
>>  space - note how ETH has quite high on chain fees for basic transactions,
>>  because there are so many use-cases where the per-tx value can afford much
>>  higher fees. That kind of expansion of use-case also arguably harms Bitcoin 
>> as
>>  a whole by providing more fuel for a future contentious blocksize debate.
>>  
>>  Bitcoin is an almost $1 trillion dollar system. We have to very carefully 
>> weigh
>>  the benefits of making core consensus changes to that system against the 
>> risks.
>>  Both for each proposal in isolation, as well as the precedent making that
>>  change sets.
>>  
>>  -- 
>>  >> https://petertodd.org>>  'peter'[:-1]@>> petertodd.org 
>> 
>>  ___
>>  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] Stumbling into a contentious soft fork activation attempt

[Erik Aronesty via bitcoin-dev]

> note how ETH has quite high on chain fees for basic transactions,
> because there are so many use-cases where the per-tx value can afford much
> higher fees. That kind of expansion of use-case also arguably harms
Bitcoin as
> a whole by providing more fuel for a future contentious blocksize debate.

i second this argument

ideally, all extensions should be explicit use cases, not generic/implicit
layers that can be exploited for unknown and possibly harmful use cases

also timing is critical for all bitcoin innovation.   look at how lightning
ate up fees

to keep bitcoin stable, we can't "scale" too quickly either

i'm a fan of, eventually (timing is critical), a lightning-compatible
mimblewible+dandelion on-chain soft fork can reduce tx size, move us from
l2 to l3, vastly improve privacy, and get more small transactions off-chain.

but it probably shouldn't be released for another 2 years


On Fri, Feb 18, 2022 at 6:41 PM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Tue, Jan 18, 2022 at 02:57:30AM +0100, Prayank wrote:
> > Hi Peter,
> >
> > > that current lacks compelling use-cases clearly beneficial to all users
> >
> > All the use cases shared in below links look compelling enough to me and
> we can do anything that a programmer could think of using such restrictions:
> >
> >  https://utxos.org/uses/
> >
> > https://rubin.io/archive/
>
> Again, what I said was "compelling use-cases _clearly_ beneficial to _all_
> users", not just a small subset. I neither think the use-cases in those
> links
> are clearly compelling in the current form, and they of course, don't
> benefit
> all users. Indeed, the Drivechains use-case arguably *harms* all users, as
> Drivechains is arguably harmful to the security of Bitcoin as a whole.
> Similarly, the various new uses for on-chain transactions mentioned as a
> use-case arguably harms all existing users by competing for scarce
> blockchain
> space - note how ETH has quite high on chain fees for basic transactions,
> because there are so many use-cases where the per-tx value can afford much
> higher fees. That kind of expansion of use-case also arguably harms
> Bitcoin as
> a whole by providing more fuel for a future contentious blocksize debate.
>
> Bitcoin is an almost $1 trillion dollar system. We have to very carefully
> weigh
> the benefits of making core consensus changes to that system against the
> risks.
> Both for each proposal in isolation, as well as the precedent making that
> change sets.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> ___
> 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] Stumbling into a contentious soft fork activation attempt

[Peter Todd via bitcoin-dev]

On Tue, Jan 18, 2022 at 02:57:30AM +0100, Prayank wrote:
> Hi Peter,
> 
> > that current lacks compelling use-cases clearly beneficial to all users
> 
> All the use cases shared in below links look compelling enough to me and we 
> can do anything that a programmer could think of using such restrictions:
> 
>  https://utxos.org/uses/
> 
> https://rubin.io/archive/

Again, what I said was "compelling use-cases _clearly_ beneficial to _all_
users", not just a small subset. I neither think the use-cases in those links
are clearly compelling in the current form, and they of course, don't benefit
all users. Indeed, the Drivechains use-case arguably *harms* all users, as
Drivechains is arguably harmful to the security of Bitcoin as a whole.
Similarly, the various new uses for on-chain transactions mentioned as a
use-case arguably harms all existing users by competing for scarce blockchain
space - note how ETH has quite high on chain fees for basic transactions,
because there are so many use-cases where the per-tx value can afford much
higher fees. That kind of expansion of use-case also arguably harms Bitcoin as
a whole by providing more fuel for a future contentious blocksize debate.

Bitcoin is an almost $1 trillion dollar system. We have to very carefully weigh
the benefits of making core consensus changes to that system against the risks.
Both for each proposal in isolation, as well as the precedent making that
change sets.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


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

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Prayank via bitcoin-dev]

Hi Peter,

> that current lacks compelling use-cases clearly beneficial to all users

All the use cases shared in below links look compelling enough to me and we can 
do anything that a programmer could think of using such restrictions:

 https://utxos.org/uses/

https://rubin.io/archive/

> I don't think CTV in its current form makes that case sufficiently, and the 
> technical details are lacking.
CTV cannot be compared to segwit or taproot. We are expecting different things 
in that case. CTV is trying to do add basic covenants in Bitcoin that would 
help all Bitcoin users. Most important thing missing in lot of conversations is 
the low demand for block space which affects everyone who understands 
importance of fees in long term. Right now fee rates only spike during peak 
bull markets which indicate the only use case is speculation and this can be 
improved if developers could do better things with Bitcoin smart contracts.

This would also ensure that we don't end up with something really contentious 
in future that changes supply.

> DoS Attacks

I think this was already answered by Jeremy and pull request to add related 
information is also merged:

https://github.com/bitcoin/bips/pull/1272


-- 
Prayank

A3B1 E430 2298 178F
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Jeremy via bitcoin-dev]

Please see the following bips PRs which are follow ups to the concrete
actionables raised by Peter. Thanks for bringing these up, it certainly
improves the reviewability of the BIP.

https://github.com/bitcoin/bips/pull/1271
https://github.com/bitcoin/bips/pull/1272

--
@JeremyRubin 



On Mon, Jan 10, 2022 at 7:42 PM Jeremy  wrote:

> Hi Peter,
>
> Thank you for your review and feedback.
>
> Apologies for the difficulties in reviewing. The branch linked from the
> BIP is not the latest, the branch in the PR is what should be considered
> https://github.com/bitcoin/bitcoin/pull/21702 for review and has more
> thorough well documented tests and test vectors. The version you reviewed
> should still be compatible with the current branch as there have not been
> any spec changes, though.
>
> I'm not sure what best practice is w.r.t. linking to BIPs and
> implementations given need to rebase and respond to feedback with changes.
> Appreciate any pointers on how to better solve this. For the time being, I
> will suggest an edit to point it to the PR, although I recognize this is
> not ideal. I understand your preference for a commit hash and can do one
> if it helps. For what it's worth, the taproot BIPs do not link to a
> reference implementation of Taproot so I'm not sure what best practice is
> considered these days.
>
> One note that is unfortunate in your review is that there is a
> discrepancy between the BIP and the implementation (the original reference
> or the current PR either) in that caching and DoS is not addressed. This
> was an explicit design goal of CTV and for it not to be mentioned in the
> BIP (and just the reference) is an oversight on my part to not aid
> reviewers more explicitly. Compounding this, I accepted a third-party PR to
> make the BIP more clear as to what is required to implement it that does
> not have caching (functional correctness), that exposes the issue if
> implemented by the BIP directly and not by the reference implementation. I
> have explained this in a review last year to pyskell
>  on
> the PR that caching is required for non-DoS. I will add a note to the BIP
> about the importance of caching to avoid DoS as that should make third
> party implementers aware of the issue.
>
> That said, this is not a mis-considered part of CTV. The reference
> implementation is specifically designed to not have quadratic hashing and
> CTV is designed to be friendly to caching to avoid denial of service. It's
> just a part of the BIP that can be more clear. I will make a PR to more
> clearly describe how that should happen.
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Jeremy via bitcoin-dev]

Hi Peter,

Thank you for your review and feedback.

Apologies for the difficulties in reviewing. The branch linked from the BIP
is not the latest, the branch in the PR is what should be considered
https://github.com/bitcoin/bitcoin/pull/21702 for review and has more
thorough well documented tests and test vectors. The version you reviewed
should still be compatible with the current branch as there have not been
any spec changes, though.

I'm not sure what best practice is w.r.t. linking to BIPs and
implementations given need to rebase and respond to feedback with changes.
Appreciate any pointers on how to better solve this. For the time being, I
will suggest an edit to point it to the PR, although I recognize this is
not ideal. I understand your preference for a commit hash and can do one if
it helps. For what it's worth, the taproot BIPs do not link to a reference
implementation of Taproot so I'm not sure what best practice is considered
these days.

One note that is unfortunate in your review is that there is a
discrepancy between the BIP and the implementation (the original reference
or the current PR either) in that caching and DoS is not addressed. This
was an explicit design goal of CTV and for it not to be mentioned in the
BIP (and just the reference) is an oversight on my part to not aid
reviewers more explicitly. Compounding this, I accepted a third-party PR to
make the BIP more clear as to what is required to implement it that does
not have caching (functional correctness), that exposes the issue if
implemented by the BIP directly and not by the reference implementation. I
have explained this in a review last year to pyskell
 on
the PR that caching is required for non-DoS. I will add a note to the BIP
about the importance of caching to avoid DoS as that should make third
party implementers aware of the issue.

That said, this is not a mis-considered part of CTV. The reference
implementation is specifically designed to not have quadratic hashing and
CTV is designed to be friendly to caching to avoid denial of service. It's
just a part of the BIP that can be more clear. I will make a PR to more
clearly describe how that should happen.

--
use cases
--

One thing that's not clear to me is the amount of work a BIP needs to do
within itself to fully describe all applications and use cases. I don't
think it's appropriate for most BIPs to do so, but in some cases it is a
good idea. However, for CTV the applications actually are relatively
fleshed out, just outside the BIP. Further, the availability of generic
tooling through Sapio and it's examples has demonstrated how one might
build a variety of applications. See rubin.io/advent21 for numerous worked
examples.


## Congestion Controlled Transactions

Generally, the existence of these transactions can be tracked using
existing wallets if the transaction is seen in the mempool, it will be
marked as "mine" and can even be marked as "trusted". See
https://utxos.org/analysis/taxes/ which covers the legal obligations of
senders with respect to payees under congestion control. Generally, a
legally identifiable party such as an exchange sending a congestion control
payment must retain and serve it to the user to prove that they made
payment to the user. Users of said exchanges can either download a list of
their transactions at the time of withdrawal or they can wait to see it
e.g. in the mempool. This was also discussed at
https://diyhpl.us/wiki/transcripts/ctv-bip-review-workshop/ where you can
see notes/videos of what was discussed if the notes are hard to parse.

Lightning specific wallets such as Muun and LND particularly plan to use
CTV to batch-open a multitude of channels for users, using both congestion
control and non-interactive batching. Channels have to be opened on-chain
and if channels are to be the future so will on-chain opening of them.
These wallets can be built out to track and receive these opening proofs.

## Wallet Vaults

There exists at least 3 implementations of Vaults using CTV (one by me in
C++, one by me in Sapio, another by Bryan Bishop in python), and there
exist oracles as you mention for emulating it.

## Payment Channels

Actually taking advantage of them is quite simple and has been discussed
and reviewed with a number of independent lightning developers.

You can see here a rudimentary implementation and description of how it can
work https://rubin.io/bitcoin/2021/12/11/advent-14/.

This is composable with any `impl Revokable` channel update specification
so generalizes to Lightning.

Of course, making it production grade requires a lot of work, but the
concept is sound.


## CoinJoin


CTV trees may mean more transactions, not less, but if feerates are not
monotonic and CTV allows you to defer the utilization of chainspace.

CTV CoinJoins also open the opportunity to cooperation through payment
pools (which can be opened via a coinjoin), which 

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Peter Todd via bitcoin-dev]

On Mon, Jan 03, 2022 at 02:05:20AM +, Michael Folkson via bitcoin-dev wrote:
> There have been a number of “soft signals”, many expressing enthusiasm for 
> the speculated use cases of OP_CTV. Personally I share that enthusiasm like I 
> do with the prospect of curing cancer. But these soft signals seem as if they 
> are going to be used to attempt to justify an imminent contentious soft fork 
> attempt. The devil is in the details both with regards to wording like 
> “reasonable parameters” and the utility and safety of a new opcode. Indeed if 
> you share my concerns that there has not been sufficient scrutiny and 
> research on the long implications of this proposal I encourage you to 
> register a soft signal of “No” on the site like I have. You can always change 
> it to “Yes” if and when you support an imminent soft fork activation attempt 
> containing exclusively OP_CTV. Enabling covenants on Bitcoin is a big step 
> change with barely any existing research on the topic and attempting to rush 
> it through by the back door so soon after Taproot activation should be 
> resisted. To look at the ~200 lines of code for the opcode exclusively (of 
> course this should be done too) in a vacuum without considering the broader 
> implications is also incredibly shortsighted. The only thing stopping a 
> descent into Ethereum style seat of our pants consensus changes is community 
> vigilance. If we ever lose that we lose the foundation of this industry.

I have to second your objections.

I spent a bit of time over the past week looking at the current state of
OP_CTV/BIP-0119, and I too think it's a premature idea with an insufficient BIP
and reference implementation, that current lacks compelling use-cases clearly
beneficial to all users.

Remember that Bitcoin is a nearly $1 trillion network with tens of millions of
users that has gotten to that point with careful, conservative engineering.
Every change to the protocol poses risks to those users. Previous feature
upgrades to the Bitcoin protocol have always been done with the intent of
improving the protocol for everyone: CSV/segwit benefit all users via
Lightning, because we can reasonably all users to directly take advantage of
those features. We expect _everyone_ to benefit from Taproot via improved
privacy. I don't think CTV in its current form makes that case sufficiently,
and the technical details are lacking.



As for some more detailed thoughts, for clarify, I'm referring to:

https://github.com/bitcoin/bips/blob/3693cdfd192dacdac89cd742f68cd1bb96bf7f7e/bip-0119.mediawiki
https://github.com/JeremyRubin/bitcoin/tree/8f313d292e426a74d9ce28e5130bbf0cd48f867e

By no means is this a complete list of issues:

# DoS Attacks

Note how above I cited the git hashes to make it clear what exactly I'm
referring too: the fact that the reference implementation is listed as
https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify in the BIP is
an immediate problem, as it's not clear what exactly is the specification.

This in turn matters quite a lot, because the BIP itself glosses over the quite
serious DoS attack issues involved in adding more ways that opcodes can hash
txs. Strong resistance to DoS attacks is a _mandatory_ aspect of all Bitcoin
script proposals, so leaving those details to a mostly uncommented reference
implementation without a clear discussion of those trade-offs is insufficient.


# Use Cases

As Folkson notes, these are barely fleshed out:

## Congestion Controlled Transactions

While this section appears somewhat fleshed out, with even a simulation, it
completely ignores the numerous practical issues like the need for
communication channels between wallets to inform them of the existence of these
batches. It also raises an important question: who needs this? On-chain
transactions are clearly not the future of Bitcoin and this use-case will
likely impact a small % of users.


## Wallet Vaults

This use-case can be easily tested, even in production, right now with
additional "oracle" signers that simply verify the CTV rules have been
followed.


## Payment Channels

These use-cases sound promising. But they all need to be clearly fleshed out as
actually taking advantage of them is quite complex.


## CoinJoin

> because participants agree on a single output which pays all participants,
> which will be lower fee than before

It is not clear how the fee will be lower, given that taking advantage of CTV
means there are more transactions, not less.


# Covenant Design Trade-Offs and Risks

> Covenants have historically been controversial given their potential for
> fungibility risks -- coins could be minted which have a permanent restriction
> on how they may or may not be spent or required to propagate metadata.

Indeed, this is a significant risk with the potential to harm all Bitcoin
users.

> In the CHECKTEMPLATEVERIFY approach, the covenants are severely restricted to
> simple templates. The structure of CHECKTEMPLATEVERIFY 

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Prayank via bitcoin-dev]

> You are working on a use case of OP_CTV now?

I think I mentioned clearly what I would be doing: 1. Review pull request 2. 
Create contracts with Sapio. This would help me review OP_CTV and learn new 
things.

> Cool, you only recently announced you were working on Bitcoin Knots (and I 
> think Wasabi before that) so I'm losing track of all the announcements.

You can read more about my involvement in Bitcoin Knots here: 
https://github.com/bitcoinknots/bitcoin/discussions/39

I started working for zkSNACKs Wasabi 2 months back which can be confirmed with 
the team.

There are no announcements and humans can work on multiple things. You might 
want to check my next project which involves discreet log contracts as I have 
learnt a few things in bitcoin-s slack as well: https://gok.one/

For my involvement in other projects you can email me privately and I can share 
my resume.

-- 
Prayank

A3B1 E430 2298 178F



Jan 4, 2022, 22:18 by michaelfolk...@protonmail.com:

> You are working on a use case of OP_CTV now? Cool, you only recently 
> announced you were working on Bitcoin Knots (and I think Wasabi before that) 
> so I'm losing track of all the announcements. Regardless stick with it and 
> build out more than a rudimentary proof of concept. That is one of the things 
> that is severely lacking at this point for OP_CTV.
>
> > TBH I am not against Miniscript and still waiting for its support in Core 
> >which might take another few years. I would love to have multiple 
> >programming languages so that application developers can decide what works 
> >best for them.
>
> I would hope you weren't against Miniscript because Sapio is built on top of 
> it :) But whatever have fun, I can't do this all day.
>
>
> --> Michael FolksonEmail: michaelfolkson at protonmail.comKeybase: 
> michaelfolksonPGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
>
> ‐‐‐ Original Message ‐‐‐
>  On Tuesday, January 4th, 2022 at 3:06 PM, Prayank  
> wrote:
>  
>
>> What I have done related to OP_CTV?
>>
>> https://twitter.com/prayankgahlot/status/1456643891885592579
>>
>> What am I currently working on that is not shared publicly and will do in 
>> next few weeks?
>>
>> Review pull request 21702 and write contracts using Sapio based on few ideas 
>> that I already have.
>>
>> What is this assessment based on?
>>
>> A few months are enough for the recent bounty to find bugs if possible and 
>> other things pending to be completed.
>>
>> > you haven't thought about alternative proposals for any particular use 
>> > case (vaults for example have multiple current alternative proposals and 
>> > most likely many future ones)
>>
>> I have read enough about alternative proposals and some of them don't even 
>> compete with OP_CTV, they can all be implemented and complement each other. 
>> Vaults is not the only thing that I care about and it would be better if we 
>> don't assume about research done by others.
>>
>> > A new programming language (Sapio) sounds great but do you you need it for 
>> > your use case rather than an alternative high level language like Minsc? 
>> > Sapio makes use of Miniscript which hasn't been finalized yet or updated 
>> > for Taproot. Surely that needs to be done first otherwise Sapio is built 
>> > on top of something that isn't ready? When you make the claims such as a 
>> > consensus change is ready to go the burden is on you to convince me and 
>> > other skeptics why. The status quo is the default. "I think it is ready or 
>> > will be ready" doesn't mean much unless you have done the work.
>>
>> TBH I am not against Miniscript and still waiting for its support in Core 
>> which might take another few years. I would love to have multiple 
>> programming languages so that application developers can decide what works 
>> best for them.
>>
>> I don't understand what work are you expecting me to do in this case to 
>> share my opinion about a soft fork.
>>
>> > It is not enough for one individual to say it is ready to be activated, 
>> > anyone who is expressing that view should understand why the opcode has 
>> > been designed in the way it has and why it is so important that we should 
>> > dedicate months of community time to getting a single opcode activated 
>> > this year.
>>
>> I have dedicated enough time reading everything related to OP_CTV and 
>> discuss things that were posted earlier here by Jeremy Rubin. Not sure how 
>> many skeptics did the same or even tried to discuss anything until recent 
>> bounty was announced.
>>
>> > You regularly NACK Core PRs yet you seem willing to wave a consensus 
>> > change through with no outstanding questions and zero skepticism.
>>
>> I would NACK and write the reasons in this pull request as well if I find 
>> any issues and PR author is not addressing them. I had lots of questions at 
>> conceptual level which have been answered on different platforms and I 
>> cannot document each conversation. Its a Concept ACK from me and none of the 

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Michael Folkson via bitcoin-dev]

You are working on a use case of OP_CTV now? Cool, you only recently announced 
you were working on Bitcoin Knots (and I think Wasabi before that) so I'm 
losing track of all the announcements. Regardless stick with it and build out 
more than a rudimentary proof of concept. That is one of the things that is 
severely lacking at this point for OP_CTV.

> TBH I am not against Miniscript and still waiting for its support in Core 
> which might take another few years. I would love to have multiple programming 
> languages so that application developers can decide what works best for them.

I would hope you weren't against Miniscript because Sapio is built on top of it 
:) But whatever have fun, I can't do this all day.

--

Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

‐‐‐ Original Message ‐‐‐
On Tuesday, January 4th, 2022 at 3:06 PM, Prayank  wrote:

> What I have done related to OP_CTV?
>
> https://twitter.com/prayankgahlot/status/1456643891885592579
>
> What am I currently working on that is not shared publicly and will do in 
> next few weeks?
>
> Review pull request 21702 and write contracts using Sapio based on few ideas 
> that I already have.
>
> What is this assessment based on?
>
> A few months are enough for the recent bounty to find bugs if possible and 
> other things pending to be completed.
>
>> you haven't thought about alternative proposals for any particular use case 
>> (vaults for example have multiple current alternative proposals and most 
>> likely many future ones)
>
> I have read enough about alternative proposals and some of them don't even 
> compete with OP_CTV, they can all be implemented and complement each other. 
> Vaults is not the only thing that I care about and it would be better if we 
> don't assume about research done by others.
>
>> A new programming language (Sapio) sounds great but do you you need it for 
>> your use case rather than an alternative high level language like Minsc? 
>> Sapio makes use of Miniscript which hasn't been finalized yet or updated for 
>> Taproot. Surely that needs to be done first otherwise Sapio is built on top 
>> of something that isn't ready? When you make the claims such as a consensus 
>> change is ready to go the burden is on you to convince me and other skeptics 
>> why. The status quo is the default. "I think it is ready or will be ready" 
>> doesn't mean much unless you have done the work.
>
> TBH I am not against Miniscript and still waiting for its support in Core 
> which might take another few years. I would love to have multiple programming 
> languages so that application developers can decide what works best for them.
>
> I don't understand what work are you expecting me to do in this case to share 
> my opinion about a soft fork.
>
>> It is not enough for one individual to say it is ready to be activated, 
>> anyone who is expressing that view should understand why the opcode has been 
>> designed in the way it has and why it is so important that we should 
>> dedicate months of community time to getting a single opcode activated this 
>> year.
>
> I have dedicated enough time reading everything related to OP_CTV and discuss 
> things that were posted earlier here by Jeremy Rubin. Not sure how many 
> skeptics did the same or even tried to discuss anything until recent bounty 
> was announced.
>
>> You regularly NACK Core PRs yet you seem willing to wave a consensus change 
>> through with no outstanding questions and zero skepticism.
>
> I would NACK and write the reasons in this pull request as well if I find any 
> issues and PR author is not addressing them. I had lots of questions at 
> conceptual level which have been answered on different platforms and I cannot 
> document each conversation. Its a Concept ACK from me and none of the 
> contributors could find any issues with PR right now so I don't want to stop 
> people from improving Bitcoin.
>
>> As I understand there are IRC workshops next week on BIP 119 [1] that I'd 
>> encourage you to join so you can start getting into a position where you can 
>> engage with the skeptics on technical concerns. Regrettably (as I said I 
>> find this work interesting) I don't feel like I can participate because 
>> deployment and activation is being included and I think it is irresponsible 
>> to be discussing those at this point. In my view activation should not even 
>> be speculated upon until it is clear there is overwhelming community support 
>> for a soft fork being activated.
>
> I would be attending the workshops and had even requested Jeremy to use 
> Twitch because it would help more people understand things with audio, screen 
> sharing etc. I would love to see skeptics participate and discuss technical 
> things.
>
>> I don't feel like I can participate because deployment and activation is 
>> being included and I think it is irresponsible to be discussing those at 

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Prayank via bitcoin-dev]

What I have done related to OP_CTV?

https://twitter.com/prayankgahlot/status/1456643891885592579

What am I currently working on that is not shared publicly and will do in next 
few weeks?

Review pull request 21702 and write contracts using Sapio based on few ideas 
that I already have.

What is this assessment based on?

A few months are enough for the recent bounty to find bugs if possible and 
other things pending to be completed.

> you haven't thought about alternative proposals for any particular use case 
> (vaults for example have multiple current alternative proposals and most 
> likely many future ones)

I have read enough about alternative proposals and some of them don't even 
compete with OP_CTV, they can all be implemented and complement each other. 
Vaults is not the only thing that I care about and it would be better if we 
don't assume about research done by others.

> A new programming language (Sapio) sounds great but do you you need it for 
> your use case rather than an alternative high level language like Minsc? 
> Sapio makes use of Miniscript which hasn't been finalized yet or updated for 
> Taproot. Surely that needs to be done first otherwise Sapio is built on top 
> of something that isn't ready? When you make the claims such as a consensus 
> change is ready to go the burden is on you to convince me and other skeptics 
> why. The status quo is the default. "I think it is ready or will be ready" 
> doesn't mean much unless you have done the work.

TBH I am not against Miniscript and still waiting for its support in Core which 
might take another few years. I would love to have multiple programming 
languages so that application developers can decide what works best for them.

I don't understand what work are you expecting me to do in this case to share 
my opinion about a soft fork.

> It is not enough for one individual to say it is ready to be activated, 
> anyone who is expressing that view should understand why the opcode has been 
> designed in the way it has and why it is so important that we should dedicate 
> months of community time to getting a single opcode activated this year.

I have dedicated enough time reading everything related to OP_CTV and discuss 
things that were posted earlier here by Jeremy Rubin. Not sure how many 
skeptics did the same or even tried to discuss anything until recent bounty was 
announced.

> You regularly NACK Core PRs yet you seem willing to wave a consensus change 
> through with no outstanding questions and zero skepticism.

I would NACK and write the reasons in this pull request as well if I find any 
issues and PR author is not addressing them. I had lots of questions at 
conceptual level which have been answered on different platforms and I cannot 
document each conversation. Its a Concept ACK from me and none of the 
contributors could find any issues with PR right now so I don't want to stop 
people from improving Bitcoin.

> As I understand there are IRC workshops next week on BIP 119 [1] that I'd 
> encourage you to join so you can start getting into a position where you can 
> engage with the skeptics on technical concerns. Regrettably (as I said I find 
> this work interesting) I don't feel like I can participate because deployment 
> and activation is being included and I think it is irresponsible to be 
> discussing those at this point. In my view activation should not even be 
> speculated upon until it is clear there is overwhelming community support for 
> a soft fork being activated.

I would be attending the workshops and had even requested Jeremy to use Twitch 
because it would help more people understand things with audio, screen sharing 
etc. I would love to see skeptics participate and discuss technical things.

> I don't feel like I can participate because deployment and activation is 
> being included and I think it is irresponsible to be discussing those at this 
> point.

If you don't participate in the workshops you might miss few things. However, 
either Jeremy or one of the participants will ensure they share the summary 
here or even logs would be available.

-- 
Prayank

A3B1 E430 2298 178F



Jan 4, 2022, 19:45 by michaelfolk...@protonmail.com:

> > > It should be ready to go in a few months IMO
>
> What is this assessment based on? I am assuming you haven't done a code 
> review of the opcode, you haven't coded up a real world use case of OP_CTV 
> (or even a primitive proof of concept), you haven't thought about alternative 
> proposals for any particular use case (vaults for example have multiple 
> current alternative proposals and most likely many future ones). A new 
> programming language (Sapio) sounds great but do you you need it for your use 
> case rather than an alternative high level language like Minsc? Sapio makes 
> use of Miniscript which hasn't been finalized yet or updated for Taproot. 
> Surely that needs to be done first otherwise Sapio is built on top of 
> something that isn't 

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Prayank via bitcoin-dev]

Hi Christian,

A few things are mentioned in these threads including unsolved research issues 
in which you were tagged and Richard Myers had even replied so I am assuming 
this is known:

https://twitter.com/JeremyRubin/status/1460349481518465025

https://twitter.com/ajtowns/status/1477586002252238850

> I also see people comparing OP_CTV with APO, which may or may not work
out in the end.

Michael Folkson did in the first email for this thread: 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html

> I therefore consider the two proposals complementary

Agree

> I'm also happy to go wih OP_CTV if only one gets activated (But then why 
> would we? We've done much more obscure things to save bytes in a TX).

Maybe we can activate one that does more than just eltoo and see how things 
work. If APO is still required for eltoo, there would be clear consensus for 
APO.


-- 
Prayank

A3B1 E430 2298 178F



Jan 4, 2022, 20:12 by decker.christ...@gmail.com:

> Prayank via bitcoin-dev  writes:
>
>>> To contrast with his approach, the authors and contributors of
>>> another future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT)
>>> aren’t promoting an imminent soft fork activation attempt and instead
>>> are building out and testing one of the speculated use cases, eltoo
>>> payment channels [4].
>>>
>>
>> Because its not ready?
>>
>
> Could you elaborate on this point? I keep seeing people mentioning this,
> but I, as BIP co-author, have not seen any real pushback. For context
> BIP118 was initially called `sighash_noinput` and it was mentioned at
> least as far back as 2015 when Joseph and Tadje wrote about its
> applications in the LN protocol. While writing eltoo we stumbled over an
> alternative use, and decided to draft the formal proposal.
>
> Once we saw that Taproot is likely to activate next, AJ started adapting
> it to integrate nicely with Taproot, and renamed it to anyprevout.
>
> I'd like to point out that the original noinput could be implemented
> with as little as 3-5 lines of code in Bitcoin Core, and there are
> experimental branches implementing APO, which isn't significantly more
> complex than the original proposal.
>
> In addition Richard Myers has implemented a PoC of eltoo on top of one
> of these experimental branches. So with all this I don't see how APO
> could be considered "not ready".
>
> The reason that neither noinput nor APO have a section on activation is
> that we want to allow bundling with other soft-forks, and we want to
> minimize the surface for potential conflicts. Also as the Taproot
> activation has shown activation is a whole another discussion, that is
> mostly unrelated to the soft-fork being activated.
>
> Why aren't we yelling about the advantages of APO over other soft-forks
> or asking for immediate activation? Because we want to be respectful of
> everyone's time. We know review capacity is very limited, and developer
> time expensive. By now most devs will be aware of the many improvements
> (on LN, eltoo, MPC, channel factories, statechains, spacechains, etc)
> anyprevout would enable, so there is little point in annoying everyone
> by constantly talking about it. The people interested in exploring this
> venue are already working on it, and we just need to wait for an
> opportune moment to start the activation discussion with other
> soft-forks.
>
> I also see people comparing OP_CTV with APO, which may or may not work
> out in the end. It seems possible to emulate APO using OP_CTV, but at
> what cost? APO does not have any overhead in the transaction size, which
> is not the case for OP_CTV, and I therefore consider the two proposals
> complementary, and not competing (APO does best what APO does best,
> while OP_CTV enables use-cases beyond APO's scope). While I'd prefer APO
> for eltoo, due to its lack of overhead, I'm also happy to go wih OP_CTV
> if only one gets activated (But then why would we? We've done much more
> obscure things to save bytes in a TX).
>
> Finally I see people mentioning that APO is insufficient to get
> eltoo. That's also not true, since in fact we can implement a poor-man's
> version of eltoo right now:
>
>  - When updating:
>  - Iterate through all prior update TXs
>  - Bind the new update TX to each of the prior ones
>  - Sign using `sighash_all`
>  - Collect all sinatures and send to peer (message size O(n), but
>  semantics are preserved, while APO enable O(1) making it actually
>  reasonable to implement).
>
> There may be some extensions, such as layered commitments that may be
> added at a later stage, but they are not required to get the first
> versions off the ground. Pretending that they're required would be like
> saying that the protocol in the LN paper hasn't changed since it was
> first written (definitely not the case).
>
> Overall I agree with Michael's sentiment that soft-fork activations have
> to be carefully planned, and kept at a reasonable pace. This is in order
> to ensure 

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Michael Folkson via bitcoin-dev]

> It should be ready to go in a few months IMO

What is this assessment based on? I am assuming you haven't done a code review 
of the opcode, you haven't coded up a real world use case of OP_CTV (or even a 
primitive proof of concept), you haven't thought about alternative proposals 
for any particular use case (vaults for example have multiple current 
alternative proposals and most likely many future ones). A new programming 
language (Sapio) sounds great but do you you need it for your use case rather 
than an alternative high level language like Minsc? Sapio makes use of 
Miniscript which hasn't been finalized yet or updated for Taproot. Surely that 
needs to be done first otherwise Sapio is built on top of something that isn't 
ready? When you make the claims such as a consensus change is ready to go the 
burden is on you to convince me and other skeptics why. The status quo is the 
default. "I think it is ready or will be ready" doesn't mean much unless you 
have done the work.

You are well aware of the review process in Core for non-consensus changes. For 
consensus changes you really should be digging even deeper, the bar should be 
higher and all questions you and others have should be explored in depth. It is 
not enough for one individual to say it is ready to be activated, anyone who is 
expressing that view should understand why the opcode has been designed in the 
way it has and why it is so important that we should dedicate months of 
community time to getting a single opcode activated this year.

I have more sympathy for those who don't follow Bitcoin Core development and 
Bitcoin Core review on an ongoing basis (note as I said that the bar for 
consensus changes should be significantly higher than a non-consensus PR). The 
use cases sound cool and the work is genuinely interesting. But honestly for 
someone who has followed Bitcoin Core development, review for a while now you 
really should know better than bandy around statements like "it should be ready 
to go in a few months" when you currently haven't scratched the surface on the 
utility and safety of this opcode. You regularly NACK Core PRs yet you seem 
willing to wave a consensus change through with no outstanding questions and 
zero skepticism.

> If I had to select between a soft fork without any use cases and one with use 
> cases, I would go with the one that has some use cases with code, 
> documentation etc. You should propose a new opcode but OP_CTV is not claiming 
> to cure cancer.

Multiple proven built out use cases, sure. Multiple is better than single when 
you have done the work to ensure they are actually the right tool for those 
multiple use cases. This work hasn't been done on any of these use cases. The 
curing cancer analogy was used to elucidate the point that claims should be 
deeply explored rather than just accepted as true.

>> To contrast with his approach, the authors and contributors of another 
>> future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren’t promoting 
>> an imminent soft fork activation attempt and instead are building out and 
>> testing one of the speculated use cases, eltoo payment channels [4].

> Because its not ready?

As I said it is not ready because the ANYPREVOUT contributors are building out 
and testing a use case. The high bar on readiness should be applied to all 
proposals not merely the ones where the authors/contributors decide to impose a 
high bar themselves.

I don't really want to spend my year imploring people to dig deeper on this 
before indicating they support an imminent activation attempt. Some people 
don't have the understanding to dig deeper, some people don't have the time and 
some don't have either. However, if an activation of OP_CTV is attempted this 
year I am sure it will be contentious [0]. Anyone who cares about Bitcoin 
development and the ongoing technical work in a multitude of areas should be 
strongly against a contentious soft fork activation attempt wasting the time of 
developers and the entire ecosystem even if they don't have the understanding 
or time to appreciate the reasons why it is contentious.

As I understand there are IRC workshops next week on BIP 119 [1] that I'd 
encourage you to join so you can start getting into a position where you can 
engage with the skeptics on technical concerns. Regrettably (as I said I find 
this work interesting) I don't feel like I can participate because deployment 
and activation is being included and I think it is irresponsible to be 
discussing those at this point. In my view activation should not even be 
speculated upon until it is clear there is overwhelming community support for a 
soft fork being activated.

[0]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
[1]: 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019719.html

--

Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Christian Decker via bitcoin-dev]

Prayank via bitcoin-dev  writes:
>> To contrast with his approach, the authors and contributors of
>> another future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT)
>> aren’t promoting an imminent soft fork activation attempt and instead
>> are building out and testing one of the speculated use cases, eltoo
>> payment channels [4].
>
> Because its not ready?

Could you elaborate on this point? I keep seeing people mentioning this,
but I, as BIP co-author, have not seen any real pushback. For context
BIP118 was initially called `sighash_noinput` and it was mentioned at
least as far back as 2015 when Joseph and Tadje wrote about its
applications in the LN protocol. While writing eltoo we stumbled over an
alternative use, and decided to draft the formal proposal.

Once we saw that Taproot is likely to activate next, AJ started adapting
it to integrate nicely with Taproot, and renamed it to anyprevout.

I'd like to point out that the original noinput could be implemented
with as little as 3-5 lines of code in Bitcoin Core, and there are
experimental branches implementing APO, which isn't significantly more
complex than the original proposal.

In addition Richard Myers has implemented a PoC of eltoo on top of one
of these experimental branches. So with all this I don't see how APO
could be considered "not ready".

The reason that neither noinput nor APO have a section on activation is
that we want to allow bundling with other soft-forks, and we want to
minimize the surface for potential conflicts. Also as the Taproot
activation has shown activation is a whole another discussion, that is
mostly unrelated to the soft-fork being activated.

Why aren't we yelling about the advantages of APO over other soft-forks
or asking for immediate activation? Because we want to be respectful of
everyone's time. We know review capacity is very limited, and developer
time expensive. By now most devs will be aware of the many improvements
(on LN, eltoo, MPC, channel factories, statechains, spacechains, etc)
anyprevout would enable, so there is little point in annoying everyone
by constantly talking about it. The people interested in exploring this
venue are already working on it, and we just need to wait for an
opportune moment to start the activation discussion with other
soft-forks.

I also see people comparing OP_CTV with APO, which may or may not work
out in the end. It seems possible to emulate APO using OP_CTV, but at
what cost? APO does not have any overhead in the transaction size, which
is not the case for OP_CTV, and I therefore consider the two proposals
complementary, and not competing (APO does best what APO does best,
while OP_CTV enables use-cases beyond APO's scope). While I'd prefer APO
for eltoo, due to its lack of overhead, I'm also happy to go wih OP_CTV
if only one gets activated (But then why would we? We've done much more
obscure things to save bytes in a TX).

Finally I see people mentioning that APO is insufficient to get
eltoo. That's also not true, since in fact we can implement a poor-man's
version of eltoo right now:

 - When updating:
   - Iterate through all prior update TXs
   - Bind the new update TX to each of the prior ones
   - Sign using `sighash_all`
   - Collect all sinatures and send to peer (message size O(n), but
 semantics are preserved, while APO enable O(1) making it actually
 reasonable to implement).

There may be some extensions, such as layered commitments that may be
added at a later stage, but they are not required to get the first
versions off the ground. Pretending that they're required would be like
saying that the protocol in the LN paper hasn't changed since it was
first written (definitely not the case).

Overall I agree with Michael's sentiment that soft-fork activations have
to be carefully planned, and kept at a reasonable pace. This is in order
to ensure that the activated features will work as expected (building
PoCs is important here) and that review time is kept efficient (bundling
may help here). For these reasons we omitted the activation discussion
in BIP118 and have trimmed the proposal to the bare minimum.

Sorry for the longish rant, but I felt I needed to clarify this
situation a bit.

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

[bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Michael Folkson via bitcoin-dev]

I have already expressed my arguments on the regularity of soft forks [0]. 
Having spent months of my time on Taproot activation last year attempting to 
get at least rough community consensus on the activation method it seems crazy 
to me that some want to do that again so soon after Taproot activation and 
somehow this time it will be plain sailing. (Spoiler: it won’t. Although 
Taproot safely activated there remain outstanding views ranging on whether BIP 
8 or 9 variants of Speedy Trial should be used in future to Speedy Trial only 
being a short term stopgap that should not be repeated.) If OP_CTV is ready to 
go now and has overwhelming community support (I don’t think either is true) it 
should surely have been included in the Taproot soft fork (perhaps delayed) 
rather than going through the months of activation wrangling and community 
outreach twice.

I stated in that post:

“A contentious or disputed soft fork can be merged into a Bitcoin 
implementation at any time but doing this is opening the door to the schism, 
disruption and waste of developer hours that we saw in 2017. Personally I think 
we’ll see an attempt to activate a contentious soft fork at some point in the 
long term future (Murphy’s Law) but any attempt to do so should be strongly 
discouraged. It should be made clear to any individual(s) that attempt this of 
the knock on impacts and potential short term damage they are inflicting on the 
entire ecosystem. Longer term I have confidence in Bitcoin’s ability to survive 
whatever happens but allocating significant community resources to resist an 
unnecessary contentious soft fork (or even regular contentious soft forks) is 
not an optimal use of those resources.”

I am getting increasingly concerned that we are stumbling into this scenario 
three months after I wrote that post. One of many future soft fork proposals 
(as many will know) is BIP 119 [1] which is the enabling of a new opcode 
OP_CHECKTEMPLATEVERIFY (OP_CTV). It seems to me like the author and primary 
promoter of this proposal (Jeremy Rubin) is pushing for an imminent attempted 
activation of a soft fork containing exclusively OP_CTV [2]. To contrast with 
his approach, the authors and contributors of another future soft fork proposal 
(BIP 118 [3], SIGHASH_ANYPREVOUT) aren’t promoting an imminent soft fork 
activation attempt and instead are building out and testing one of the 
speculated use cases, eltoo payment channels [4]. Similar work has not been 
done for any of the speculated use cases of OP_CTV. Instead Jeremy is 
encouraging people to “soft signal” for soft fork activation of OP_CTV 
presumably in the hope that the building out and testing of use cases can be 
completed post activation.

This is totally irresponsible in my view. A long list of speculated use cases 
means nothing on its own. I can propose a new opcode OP_MAGIC and claim it will 
cure cancer with no potential downsides and hence we should have a soft fork 
activating it as soon as possible. I would hope there would be sufficient 
skepticism that this proposal wouldn’t see the light of day. It is true that 
Jeremy has some rudimentary proofs of concept built but as any software 
engineer will tell you the vast majority of the challenges are encountered once 
you attempt to build out that proof of concept. Once you do you may realize 
that the tool (or opcode) you are using isn’t the right one for the job. Unlike 
adjusting a feature on a social media app adjusting a consensus change once it 
has been activated is trickier to put it mildly.

There are a number of other more interesting technical discussions to be had 
later (what kind of covenants we want and are able to enable safely on Bitcoin 
etc, how CTV compares to other covenant enabling proposals, to what extent 
activating CTV would impact future proposals) but I feel the top priority is to 
bring some attention to the danger of us stumbling into an attempted 
contentious soft fork activation attempt.

Jeremy has put up this site (https://utxos.org/signals/) which is collecting 
so-called “soft signals”. I very much doubt anyone has a problem with Jeremy 
engaging with the community on his proposal and receiving feedback. However, 
the site currently states:

“The following organizations, individuals, or pools have communicated 
preference for and intent to support a BIP-119 activation attempt using 
reasonable parameters. These “soft signals” are non-binding until an actual 
concrete proposal has been formed, but are useful for measuring community 
consensus.”

There have been a number of “soft signals”, many expressing enthusiasm for the 
speculated use cases of OP_CTV. Personally I share that enthusiasm like I do 
with the prospect of curing cancer. But these soft signals seem as if they are 
going to be used to attempt to justify an imminent contentious soft fork 
attempt. The devil is in the details both with regards to wording like 
“reasonable parameters” and the utility and