Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[pushd via bitcoin-dev]

Hi Luke,

> But none of this ST nonsense, please. That alone is a reason to oppose it.

Agree. Any soft fork that uses only speedy trial should be opposed. There are 
few other reasons to oppose it as well:

- Premature idea
- Use cases are not interesting for all users
- We are still in research phase of implementing covenants in bitcoin and 
looking for the best proposal
- Taproot soft fork was recently activated and its too soon
- Not enough documentation available
- Could not find any pull request in core for BIP 118 that can be reviewed
- Not enough tools available for testing

I am planning to maintain a page for all the NACKs against BIP 118 based on 
this thread. I am assuming you don't mind including your name in it.

pushd

---
parallel lines meet at infinity?

> --
>
> Message: 3
> Date: Fri, 22 Apr 2022 17:01:14 +
> From: Luke Dashjr l...@dashjr.org
>
> To: bitcoin-dev@lists.linuxfoundation.org, darosior
> daros...@protonmail.com
>
> Subject: Re: [bitcoin-dev] ANYPREVOUT in place of CTV
> Message-ID: 202204221701.15307.l...@dashjr.org
>
> Content-Type: Text/Plain; charset="iso-8859-1"
>
> There's no reason for before/after/in place. We have version bits specifically
> so we can have multiple deployments in parallel.
>
> But none of this ST nonsense, please. That alone is a reason to oppose it.
>
> Luke
>
> On Friday 22 April 2022 11:11:41 darosior via bitcoin-dev wrote:
>
>> I would like to know people's sentiment about doing (a very slightly
>> tweaked version of) BIP118 in place of (or before doing) BIP119.
>>
>> SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for
>> over 6 years. It presents proven and implemented usecases, that are
>> demanded and (please someone correct me if i'm wrong) more widely accepted
>> than CTV's.
>>
>> SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made
>> optional [0], can emulate CTV just fine. Sure then you can't have bare or
>> Segwit v0 CTV, and it's a bit more expensive to use. But we can consider
>> CTV an optimization of APO-AS covenants.
>>
>> CTV advocates have been presenting vaults as the flagship usecase. Although
>> as someone who've been trying to implement practical vaults for the past 2
>> years i doubt CTV is necessary nor sufficient for this (but still useful!),
>> using APO-AS covers it. And it's not a couple dozen more virtual bytes that
>> are going to matter for a potential vault user.
>>
>> If after some time all of us who are currently dubious about CTV's stated
>> usecases are proven wrong by onchain usage of a less efficient construction
>> to achieve the same goal, we could roll-out CTV as an optimization. In the
>> meantime others will have been able to deploy new applications leveraging
>> ANYPREVOUT (Eltoo, blind statechains, etc..[1]).
>>
>> Given the interest in, and demand for, both simple covenants and better
>> offchain protocols it seems to me that BIP118 is a soft fork candidate that
>> could benefit more (if not most of) Bitcoin users. Actually i'd also be
>> interested in knowing if people would oppose the APO-AS part of BIP118,
>> since it enables CTV's features, for the same reason they'd oppose BIP119.
>>
>> [0] That is, to not commit to the other inputs of the transaction (via
>> sha_sequences and maybe also sha_amounts). Cf
>> https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-me
>> ssage.
>>
>> [1] https://anyprevout.xyz/ "Use Cases" section
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> --
>
> Subject: Digest Footer
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> --
>
> End of bitcoin-dev Digest, Vol 83, Issue 42
> ***___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

[pushd via bitcoin-dev]

> I would like to know people's sentiment about doing (a very slightly tweaked 
> version of) BIP118 in place of (or before doing) BIP119.

NACK for the below reasons:

- Premature idea
- I do not find use cases interesting
- We are still in research phase of implementing covenants in bitcoin and 
looking for the best proposal
- Taproot soft fork was recently activated and its too soon
- Not enough documentation available
- Could not find any pull request in core for BIP 118 that can be reviewed
- Not enough tools available for testing

pushd
---

parallel lines meet at infinity?

--- Original Message ---
On Friday, April 22nd, 2022 at 5:30 PM, 
bitcoin-dev-requ...@lists.linuxfoundation.org wrote:

> Send bitcoin-dev mailing list submissions to
> bitcoin-dev@lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
> bitcoin-dev-requ...@lists.linuxfoundation.org
>
> You can reach the person managing the list at
> bitcoin-dev-ow...@lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
>
> Today's Topics:
>
> 1. ANYPREVOUT in place of CTV (darosior)
>
> --
>
> Message: 1
> Date: Fri, 22 Apr 2022 11:11:41 +
> From: darosior daros...@protonmail.com
>
> To: Bitcoin Protocol Discussion
> bitcoin-dev@lists.linuxfoundation.org
>
> Subject: [bitcoin-dev] ANYPREVOUT in place of CTV
> Message-ID:
> p3P0m2_aNXd-4oYhFjCKJyI8zQXahmZed6bv7lnj9M9HbP9gMqMtJr-pP7XRAPs-rn_fJuGu1cv9ero5i8f0cvyZrMXYPzPx17CxJ2ZSvRk=@protonmail.com
>
> Content-Type: text/plain; charset=utf-8
>
> I would like to know people's sentiment about doing (a very slightly tweaked 
> version of) BIP118 in place of
> (or before doing) BIP119.
>
> SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for over 
> 6 years. It presents proven and
> implemented usecases, that are demanded and (please someone correct me if i'm 
> wrong) more widely accepted than
> CTV's.
>
> SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made optional 
> [0], can emulate CTV just fine.
> Sure then you can't have bare or Segwit v0 CTV, and it's a bit more expensive 
> to use. But we can consider CTV
> an optimization of APO-AS covenants.
>
> CTV advocates have been presenting vaults as the flagship usecase. Although 
> as someone who've been trying to
> implement practical vaults for the past 2 years i doubt CTV is necessary nor 
> sufficient for this (but still
> useful!), using APO-AS covers it. And it's not a couple dozen more virtual 
> bytes that are going to matter for
> a potential vault user.
>
> If after some time all of us who are currently dubious about CTV's stated 
> usecases are proven wrong by onchain
> usage of a less efficient construction to achieve the same goal, we could 
> roll-out CTV as an optimization. In
> the meantime others will have been able to deploy new applications leveraging 
> ANYPREVOUT (Eltoo, blind
> statechains, etc..[1]).
>
> Given the interest in, and demand for, both simple covenants and better 
> offchain protocols it seems to me that
> BIP118 is a soft fork candidate that could benefit more (if not most of) 
> Bitcoin users.
> Actually i'd also be interested in knowing if people would oppose the APO-AS 
> part of BIP118, since it enables
> CTV's features, for the same reason they'd oppose BIP119.
>
> [0] That is, to not commit to the other inputs of the transaction (via 
> sha_sequences and maybe also
> sha_amounts). Cf 
> https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message.
>
> [1] https://anyprevout.xyz/ "Use Cases" section
>
> --
>
> Subject: Digest Footer
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> --
>
> End of bitcoin-dev Digest, Vol 83, Issue 40
> ***___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[pushd via bitcoin-dev]

E.
>>
>> pushd
>> ---
>> parallel lines meet at infinity?
>>
>> --- Original Message ---
>> On Thursday, March 31st, 2022 at 10:01 AM, Billy Tetrud 
>>  wrote:
>>
>>>> Many users, miners and exchanges still think its voting
>>>
>>> Why do you care what they think? Why does it matter if they misunderstand?
>>>
>>>> it is not an imaginary group of people
>>>
>>> If the people aren't imaginary, then its their importance that's imaginary.
>>>
>>>> One example of a mining pool
>>>
>>> This isn't even sufficient evidence that they don't understand. Its quite 
>>> possible they're using the word "voting" loosely or that they don't 
>>> understand english very well. And again, so what if they tweet things that 
>>> are not correctly worded? This is not a reason to change how we design 
>>> bitcoin soft forks.
>>>
>>> Its not even wrong to say that a particular signaling round is very much 
>>> like voting. What's wrong is saying that bitcoin upgrades are made if and 
>>> only if miners vote to approve those changes.
>>>
>>>> I see a problem that exists
>>>
>>> You haven't convinced me this is a significant problem. What are the 
>>> concrete downsides? Why do you think this can't be fixed by simple 
>>> persistent explaining? You can find groups of people who misunderstand 
>>> basically any aspect of bitcoin. The solution to people misunderstanding 
>>> the design is never to change how bitcoin is designed.
>>>
>>> On Wed, Mar 30, 2022 at 4:14 PM pushd  wrote:
>>>
>>>>> No it does not. This narrative is the worst. A bad explanation of speedy 
>>>>> trial can mislead people into thinking miner signalling is how Bitcoin 
>>>>> upgrades are voted in. But a bad explanation can explain anything badly.
>>>>
>>>> I agree it is worst but why do you think this narrative exists? People 
>>>> have tried explaining it. Many users, miners and exchanges still think its 
>>>> voting. I think the problem is with activation method so BIP 8/LOT=TRUE is 
>>>> a solution.
>>>>
>>>>> The solution is not to change how we engineer soft forks, it's to explain 
>>>>> speedy trial better to this imaginary group of important people that 
>>>>> think miner signaling is voting.
>>>>
>>>> We can suggest different solutions but the problem exists and it is not an 
>>>> imaginary group of people.
>>>>
>>>> One example of a mining pool: https://archive.ph/oyH04
>>>>
>>>>> We shouldn't change how we engineer Bitcoin because of optics. I 
>>>>> completely object to that point continuing to be used.
>>>>
>>>> Voting as described on wiki is quite similar to what happens during miners 
>>>> signaling followed by activation if a certain threshold is reached. If 
>>>> some participants in this process consider it voting instead of signaling 
>>>> for readiness then listing advantages of a better activation method should 
>>>> help everyone reading this thread/email.
>>>>
>>>> Sorry, I don't understand your objection. I see a problem that exists 
>>>> since years and a better activation method fixes it. There are other 
>>>> positives for using BIP 8/LOT=TRUE which I shared in 
>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020178.html
>>>>
>>>> I will continue to discuss this problem with solutions until we use better 
>>>> activation methods for future soft forks in any discussion about 
>>>> activation methods.
>>>>
>>>> pushd
>>>> ---
>>>> parallel lines meet at infinity?
>>>>
>>>> --- Original Message ---
>>>> On Thursday, March 31st, 2022 at 1:40 AM, Billy Tetrud 
>>>>  wrote:
>>>>
>>>>> @Pushd
>>>>>
>>>>>> Speedy trial makes it worse by misleading lot of bitcoin users including 
>>>>>> miners to consider signaling as voting and majority votes decide if a 
>>>>>> soft fork gets activated
>>>>>
>>>>> No it does not. This narrative is the worst. A bad explanation of speedy 
>>>>> trial can mislead people into thinking miner signalling is how Bitcoin 
>>>>> upgrades are voted in. But a b

Re: [bitcoin-dev] Speedy Trial

[pushd via bitcoin-dev]

; https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020178.html
>>
>> I will continue to discuss this problem with solutions until we use better 
>> activation methods for future soft forks in any discussion about activation 
>> methods.
>>
>> pushd
>> ---
>> parallel lines meet at infinity?
>>
>> --- Original Message ---
>> On Thursday, March 31st, 2022 at 1:40 AM, Billy Tetrud 
>>  wrote:
>>
>>> @Pushd
>>>
>>>> Speedy trial makes it worse by misleading lot of bitcoin users including 
>>>> miners to consider signaling as voting and majority votes decide if a soft 
>>>> fork gets activated
>>>
>>> No it does not. This narrative is the worst. A bad explanation of speedy 
>>> trial can mislead people into thinking miner signalling is how Bitcoin 
>>> upgrades are voted in. But a bad explanation can explain anything badly. 
>>> The solution is not to change how we engineer soft forks, it's to explain 
>>> speedy trial better to this imaginary group of important people that think 
>>> miner signaling is voting.
>>>
>>> We shouldn't change how we engineer Bitcoin because of optics. I completely 
>>> object to that point continuing to be used.
>>>
>>> On Wed, Mar 30, 2022, 05:36 pushd via bitcoin-dev 
>>>  wrote:
>>>
>>>>> Any case where a flawed proposal makes it through getting activation
>>>> parameters set and released, but doesn't achieve supermajority 
>>>> hashpowersupport is made worse by bip8/lot=true in comparison to speedy 
>>>> trial.
>>>>
>>>> - Flawed proposal making it through activation is a failure of review 
>>>> process
>>>>
>>>> - Supermajority hashpower percentage decided by bitcoin core developers 
>>>> can choose to not follow old or new consensus rules at any point
>>>>
>>>> - Speedy trial makes it worse by misleading lot of bitcoin users including 
>>>> miners to consider signaling as voting and majority votes decide if a soft 
>>>> fork gets activated
>>>>
>>>> - BIP 8/LOT=TRUE keeps things simple. Miners need to follow consensus 
>>>> rules as they do right now if they wish to mine blocks for subsidy and 
>>>> fees.
>>>>
>>>> Note: Mining pools or individual miners can participate in soft fork 
>>>> discussions regardless of activation method and share their concern which 
>>>> can be evaluated based on technical merits.
>>>>
>>>> pushd
>>>> ---
>>>> parallel lines meet at infinity?
>>>> ___
>>>> 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] Speedy Trial

[pushd via bitcoin-dev]

> No it does not. This narrative is the worst. A bad explanation of speedy 
> trial can mislead people into thinking miner signalling is how Bitcoin 
> upgrades are voted in. But a bad explanation can explain anything badly.

I agree it is worst but why do you think this narrative exists? People have 
tried explaining it. Many users, miners and exchanges still think its voting. I 
think the problem is with activation method so BIP 8/LOT=TRUE is a solution.

> The solution is not to change how we engineer soft forks, it's to explain 
> speedy trial better to this imaginary group of important people that think 
> miner signaling is voting.

We can suggest different solutions but the problem exists and it is not an 
imaginary group of people.

One example of a mining pool: https://archive.ph/oyH04

> We shouldn't change how we engineer Bitcoin because of optics. I completely 
> object to that point continuing to be used.

Voting as described on wiki is quite similar to what happens during miners 
signaling followed by activation if a certain threshold is reached. If some 
participants in this process consider it voting instead of signaling for 
readiness then listing advantages of a better activation method should help 
everyone reading this thread/email.

Sorry, I don't understand your objection. I see a problem that exists since 
years and a better activation method fixes it. There are other positives for 
using BIP 8/LOT=TRUE which I shared in 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020178.html

I will continue to discuss this problem with solutions until we use better 
activation methods for future soft forks in any discussion about activation 
methods.

pushd
---
parallel lines meet at infinity?

--- Original Message ---
On Thursday, March 31st, 2022 at 1:40 AM, Billy Tetrud  
wrote:

> @Pushd
>
>> Speedy trial makes it worse by misleading lot of bitcoin users including 
>> miners to consider signaling as voting and majority votes decide if a soft 
>> fork gets activated
>
> No it does not. This narrative is the worst. A bad explanation of speedy 
> trial can mislead people into thinking miner signalling is how Bitcoin 
> upgrades are voted in. But a bad explanation can explain anything badly. The 
> solution is not to change how we engineer soft forks, it's to explain speedy 
> trial better to this imaginary group of important people that think miner 
> signaling is voting.
>
> We shouldn't change how we engineer Bitcoin because of optics. I completely 
> object to that point continuing to be used.
>
> On Wed, Mar 30, 2022, 05:36 pushd via bitcoin-dev 
>  wrote:
>
>>> Any case where a flawed proposal makes it through getting activation
>> parameters set and released, but doesn't achieve supermajority 
>> hashpowersupport is made worse by bip8/lot=true in comparison to speedy 
>> trial.
>>
>> - Flawed proposal making it through activation is a failure of review process
>>
>> - Supermajority hashpower percentage decided by bitcoin core developers can 
>> choose to not follow old or new consensus rules at any point
>>
>> - Speedy trial makes it worse by misleading lot of bitcoin users including 
>> miners to consider signaling as voting and majority votes decide if a soft 
>> fork gets activated
>>
>> - BIP 8/LOT=TRUE keeps things simple. Miners need to follow consensus rules 
>> as they do right now if they wish to mine blocks for subsidy and fees.
>>
>> Note: Mining pools or individual miners can participate in soft fork 
>> discussions regardless of activation method and share their concern which 
>> can be evaluated based on technical merits.
>>
>> pushd
>> ---
>> parallel lines meet at infinity?
>> ___
>> 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] Speedy Trial

[pushd via bitcoin-dev]

> Any case where a flawed proposal makes it through getting activation
parameters set and released, but doesn't achieve supermajority hashpowersupport 
is made worse by bip8/lot=true in comparison to speedy trial.

- Flawed proposal making it through activation is a failure of review process

- Supermajority hashpower percentage decided by bitcoin core developers can 
choose to not follow old or new consensus rules at any point

- Speedy trial makes it worse by misleading lot of bitcoin users including 
miners to consider signaling as voting and majority votes decide if a soft fork 
gets activated

- BIP 8/LOT=TRUE keeps things simple. Miners need to follow consensus rules as 
they do right now if they wish to mine blocks for subsidy and fees.

Note: Mining pools or individual miners can participate in soft fork 
discussions regardless of activation method and share their concern which can 
be evaluated based on technical merits.

pushd
---
parallel lines meet at infinity?___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[pushd via bitcoin-dev]

> 0') someone has come up with a good idea (yay!)
> 1') most of bitcoin is enthusiastically behind the idea
> 2') an enemy of bitcoin is essentially alone in trying to stop it
> 3') almost everyone remains enthusiastic, despite that guy's incoherent raving
> 4') nevertheless, the enemies of bitcoin should have the power to stop
the good idea

How do we know if someone is enemy or not in step 2 and step 4?

why bip 8:

- gives more power to users
- miners signaling is not considered voting
- less politics and controversies

During the taproot activation parameters meeting on 2021-02-16,
participants expressed their preferences with regards to BIP 8's 
lockinontimeout (LOT) parameter:
https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c

pushd
---
parallel lines meet at infinity?___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[pushd via bitcoin-dev]

> I've done it in about 40 lines of python:
https://github.com/jeremyrubin/forkd

This python script using `invalidateblock` RPC is an attack on Bitcoin. Just 
kidding although I won't be surprised if someone writes about it on reddit.

Thanks for writing the script, it will be helpful.

pushd
---
parallel lines meet at infinity?___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[pushd via bitcoin-dev]

> A mechanism of soft-forking against activation exists. What more do you
want? Are we supposed to write the code on behalf of this hypothetical
group of users who may or may not exist for them just so that they can have
a node that remains stalled on Speedy Trial lockin? That simply isn't
reasonable, but if you think it is, I invite you to create such a fork.
I want BIP 8. And less invitations to fork or provoke people.

> If I believe I'm in the economic majority then I'll just refuse to upgrade
my node, which was option 2. I don't know why you dismissed it.

> Not much can prevent a miner cartel from enforcing rules that users don't
want other than hard forking a replacement POW. There is no effective
difference between some developers releasing a malicious soft-fork of
Bitcoin and the miners releasing a malicious version themselves. And when
the miner cartel forms, they aren't necessarily going to be polite enough
to give a transparent signal of their new rules.

Miners get paid irrespective of rules as long as subsidy doesn't change. You 
can affect their fees, bitcoin and that should be termed as an attack on 
bitcoin.

> However, without the
economic majority enforcing their set of rules, the cartel continuously
risks falling apart from the temptation of transaction fees of the censored
transactions.

Transaction fee isn't as expected even if we leave censored transactions in a 
censorship resistant network. If cartel of developers affect it in long term, 
there will be a time when nobody wants to mine for loss or less profit.

> Look, you cannot have the perfect system of money all by your
lonesome self.

I agree with this and I can't do the same thing with my local government.

pushd
---
parallel lines meet at infinity?___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[pushd via bitcoin-dev]

> Do you think BIP8 still has broad consensus? If that's the case, maybe all
that's needed is to gather some 
evidence; and present it.

This pull request had some support and a few disagreements: 
https://archive.fo/uw1cO

pushd
---parallel lines meet at infinity?___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev