Nostr notes by

📅 Original date posted:2022-04-22 📝 Original message:> I ...

2023-06-08T01:07:58+02:00

In reply to nevent1q…2u0y
_________________________

📅 Original date posted:2022-04-22
📝 Original message:> 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-request at lists.linuxfoundation.org wrote:

> Send bitcoin-dev mailing list submissions to
> bitcoin-dev at 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-request at lists.linuxfoundation.org
>
> You can reach the person managing the list at
> bitcoin-dev-owner at 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 +0000
> From: darosior darosior at protonmail.com
>
> To: Bitcoin Protocol Discussion
> bitcoin-dev at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> ------------------------------
>
> End of bitcoin-dev Digest, Vol 83, Issue 40
> *******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220422/303a4052/attachment-0001.html>;

📅 Original date posted:2022-03-31 📝 Original message:> ...

2023-06-08T01:06:24+02:00

In reply to nevent1q…q6lc
_________________________

📅 Original date posted:2022-03-31
📝 Original message:> If that's really true then you're wasting my and everyone's time here.

It isn't waste of time but important for everyone to understand different opinions about soft fork activations before moving to next soft fork.

The reason I am not trying to convince you or others but sharing my opinion: https://www.vox.com/science-and-health/2016/12/28/14088992/brain-study-change-minds

> This is completely false. I have to assume you don't include yourself in the list of users who think a passing vote of miners is required to upgrade Bitcoin. Am I wrong? If not, then you should know that this misunderstanding gives no one an edge.

It is not false because it has been misused by mining pools in past so provides an edge to delay things and create contentious environment.

> You will be able to find 3 people who misunderstand BIP8, or literally any other thing you come up with.
Sorry, I cannot ignore things or live in denial at least when we have better alternatives for activation available.

pushd
---
parallel lines meet at infinity?

------- Original Message -------
On Thursday, March 31st, 2022 at 9:04 PM, Billy Tetrud <billy.tetrud at gmail.com> wrote:

>> I am not trying to convince you
>
> If that's really true then you're wasting my and everyone's time here.
>
>> Signaling period is a waste of time if mining pools that agreed on a soft fork earlier do politics
>
> They can and will do politics regardless of why misunderstandings about signaling. This is not a relevant point.
>
>> It is considered as voting not just by people outside Bitcoin but the participants itself
>
> This is not a concrete downside. You are simply restating the premise.
>
>> It gives miners an edge over economic nodes that enforce consensus rules
>
> This is completely false. I have to assume you don't include yourself in the list of users who think a passing vote of miners is required to upgrade Bitcoin. Am I wrong? If not, then you should know that this misunderstanding gives no one an edge.
>
> So I'm counting 0 concrete downsides of this misunderstanding of how signaling works that are both relevant and true. I'm going to stick with my conclusion that this is a pointless dead end argument to make about soft fork deployment in particular, and literally any technical design in general.
>
> You will be able to find 3 people who misunderstand BIP8, or literally any other thing you come up with. You could probably find thousands. Or millions if you ask people who've never heard of it. The argument that changing the design will somehow improve that situation is perplexing, but the argument that changing the idea might be a good idea on that basis is completely unconscionable.
>
> On Thu, Mar 31, 2022, 09:19 pushd <pushd at protonmail.com> wrote:
>
>>> Why do you care what they think? Why does it matter if they misunderstand?
>>
>> I care about improving soft fork activation mechanism and shared one of the advantages that helps avoid misleading things. It matters because they are participants in this process.
>>
>>> If the people aren't imaginary, then its their importance that's imaginary.
>>
>> Neither the people nor their importance is imaginary. They are a part of Bitcoin and as important as our opinion about soft forks on this mailing list.
>>
>>> This isn't even sufficient evidence that they don't understand.
>>
>> One example of an exchange:
>>
>> One example of a user: https://bitcoin.stackexchange.com/questions/97043/is-there-an-active-list-of-bips-currently-open-for-voting/
>>
>> 3 examples for each (user, mining pool and exchange) are enough to discuss a problem or list advantages of BIP 8/LOT=TRUE. I can create an archive with more if it helps during next soft fork.
>>
>>> 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?
>>
>> I am not trying to convince you and we can have different opinions.
>>
>> Downsides:
>>
>> - Signaling period is a waste of time if mining pools that agreed on a soft fork earlier do politics or influenced by councils such as BMC or governments during signaling
>>
>> - It is considered as voting not just by people outside Bitcoin but the participants itself
>>
>> - It gives miners an edge over economic nodes that enforce consensus rules
>> Simple persistent explaining has not helped in last few years. I don't see anything wrong in listing this as one of the advantages for BIP8/LOT=TRUE.
>>
>> pushd
>> ---
>> parallel lines meet at infinity?
>>
>> ------- Original Message -------
>> On Thursday, March 31st, 2022 at 10:01 AM, Billy Tetrud <billy.tetrud at gmail.com> 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 <pushd at protonmail.com> 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 <billy.tetrud at gmail.com> 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 <bitcoin-dev at lists.linuxfoundation.org> 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 at lists.linuxfoundation.org
>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220331/807435d4/attachment-0001.html>;

📅 Original date posted:2022-03-31 📝 Original message:> ...

2023-06-08T01:06:22+02:00

In reply to nevent1q…m7gg
_________________________

📅 Original date posted:2022-03-31
📝 Original message:> Why do you care what they think? Why does it matter if they misunderstand?

I care about improving soft fork activation mechanism and shared one of the advantages that helps avoid misleading things. It matters because they are participants in this process.

> If the people aren't imaginary, then its their importance that's imaginary.

Neither the people nor their importance is imaginary. They are a part of Bitcoin and as important as our opinion about soft forks on this mailing list.

> This isn't even sufficient evidence that they don't understand.

One example of an exchange:

One example of a user: https://bitcoin.stackexchange.com/questions/97043/is-there-an-active-list-of-bips-currently-open-for-voting/

3 examples for each (user, mining pool and exchange) are enough to discuss a problem or list advantages of BIP 8/LOT=TRUE. I can create an archive with more if it helps during next soft fork.

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

I am not trying to convince you and we can have different opinions.

Downsides:

- Signaling period is a waste of time if mining pools that agreed on a soft fork earlier do politics or influenced by councils such as BMC or governments during signaling

- It is considered as voting not just by people outside Bitcoin but the participants itself

- It gives miners an edge over economic nodes that enforce consensus rules
Simple persistent explaining has not helped in last few years. I don't see anything wrong in listing this as one of the advantages for BIP8/LOT=TRUE.

pushd
---
parallel lines meet at infinity?

------- Original Message -------
On Thursday, March 31st, 2022 at 10:01 AM, Billy Tetrud <billy.tetrud at gmail.com> 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 <pushd at protonmail.com> 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 <billy.tetrud at gmail.com> 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 <bitcoin-dev at lists.linuxfoundation.org> 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 at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220331/c868eee4/attachment-0001.html>;

📅 Original date posted:2022-03-30 📝 Original message:> ...

2023-06-08T01:06:21+02:00

In reply to nevent1q…pzhc
_________________________

📅 Original date posted:2022-03-30
📝 Original message:> 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 <billy.tetrud at gmail.com> 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 <bitcoin-dev at lists.linuxfoundation.org> 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220330/0272365e/attachment-0001.html>;

📅 Original date posted:2022-03-17 📝 Original message:> ...

2023-06-08T01:06:20+02:00

In reply to nevent1q…su0p
_________________________

📅 Original date posted:2022-03-17
📝 Original message:> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220317/0de96e24/attachment.html>;

📅 Original date posted:2022-03-30 📝 Original message:> ...

2023-06-08T01:06:20+02:00

In reply to nevent1q…ndtm
_________________________

📅 Original date posted:2022-03-30
📝 Original message:> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220330/959159a9/attachment.html>;

📅 Original date posted:2022-03-26 📝 Original message:> ...

2023-06-08T01:06:20+02:00

In reply to nevent1q…3enc
_________________________

📅 Original date posted:2022-03-26
📝 Original message:> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220326/418e8cd9/attachment.html>;

📅 Original date posted:2022-03-12 📝 Original message:> A ...

2023-06-08T01:06:19+02:00

In reply to nevent1q…ser3
_________________________

📅 Original date posted:2022-03-12
📝 Original message:> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220312/63dc5fc7/attachment-0001.html>;

📅 Original date posted:2022-03-11 📝 Original message:> ...

2023-06-08T01:06:01+02:00

In reply to nevent1q…awhf
_________________________

📅 Original date posted:2022-03-11
📝 Original message:> Do you think BIP8 still has broad consensus? If that's the case, maybe all
that's needed is to gather some evidence<https://www.youtube.com/watch?v=U7rXOgL4oFQ>;; and present it.

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

pushd
---parallel lines meet at infinity?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220311/1206460f/attachment.html>;