pushd [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2022-03-11 to 2022-04-22
💬 Posted a total of 12 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 13:05:42

- reply

📅 Original date posted:2022-04-05
📝 Original message:
Good morning ZmnSCPxj,

> No amount of onchain confidential transactions can hide this fact.
On-chain confidential transaction that I mentioned in my email was in this context:
If someone holds a large sum of BTC or any amount associated with an incident or an old UTXO from 2010, any transaction that spends these UTXOs will be observed by lot of chain analysts.
If this transaction was confidential, nobody can track amounts. Example: https://liquid.network/testnet/tx/4c8b1615109a29ad0fc9e4b40cdab1da3fe83447547806ee3c60e6dc337d9325
> This reduction in liquidity translates to a reduction in anonymity set, meaning it is probably more likely that Alice will be running most of the nodes that *do* support your OmniBOLT-based asset and even if you try to route your funds elsewhere, if you use OmniBOLT, it is likely that Alice will be able to track where you moved your funds.
I agree, liquidity and anonymity set will be less in this case. Second part can be fixed if the project was decentralized and Alice allows anyone to run nodes for providing liquidity.
> You are better off with this scheme if you want to "clean" 1000 BTC:
Tried the steps on testnet and swap transaction was https://mempool.space/testnet/tx/2505145b76c978860ee8061f5cf8a59f38d2a25ecacdd2b17f706a67e6a65287
> Source routing means that Boltz Exchange can report your onchain address, but cannot correlate it with your published node.
I used boltz onion link: http://tboltzzrsoc3npe6sydcrh37mtnfhnbrilqi45nao6cgc6dr7n2eo3id.onion however I still need to trust boltz that no logs are saved for swaps. Maybe running own boltz backend can be helpful.
Thanks for responding to the email and sharing steps that could be used to break links between UTXOs using lightning. I plan to make this process easier with better UI/UX in a mobile app if this works better than coinjoin.
pushd
---
parallel lines meet at infinity?
------- Original Message -------
On Monday, April 4th, 2022 at 1:53 PM, ZmnSCPxj ZmnSCPxj at protonmail.com wrote:
> Good morning pushd,
>
>> Good morning,
>>
>> Things that affect privacy particularly when large sums of money are involved in bitcoin:
>>
>> Liquidity, Anonymity set, Amounts, Type of addresses/scripts, Block, Locktime and Version
>>
>> I have left out things that aren't part of bitcoin protocol or blockchain like KYC. It is difficult for users to move large sums of BTC without being observed because bitcoin does not have confidential transactions to hide amounts. Coinjoin implementations have their own issues, trade-offs, some might even censor transactions and big amounts will still be a problem. Coinswap might be an alternative in future however I wanted to share one solution that could be helpful in improving privacy.
>>
>> Synonym did first stablecoin transaction in a lightning channel using Omni BOLT. Consider Alice starts a bitcoin project in which a lightning channel is used for assets like stablecoin. Bob wants to use 1000 BTC linked with an incident. He opens channels with Alice, gets stablecoin which can be used in any project that supports Omni BOLT assets.
>>
>> Questions:
>>
>> What is the lightning channel capacity when using Omni BOLT?
>>
>> What else can be improved in this setup? Anything else that I maybe missing?
>>
>> I added 'fifty shades of privacy' in subject because it was the first thing that came to my mind when I look at privacy in bitcoin and lightning.
>
> I am not quite sure that using OmniBOLT and a stablecoin (I ssume you mean an asset ostensibly pegged to traditional currency) improves the privacy here.
>
> Even if you have onchain confidentiality, your counterparty has to know how much of the funds are theirs, and by elimination, since there are only the two of you on that channel, the remainder of the funds is yours.
> No amount of onchain confidential transactions can hide this fact.
> And if the channel is unpublished, then the counterparty knows that any send from you is your own payment, and any receive to you is your own received funds.
>
> Using a non-Bitcoin assett(whether pegged to a traditional currency or not) simply reduces the likelihood that you will be able to use the rest of the network, since most of the network only works with Bitcoin.
> This reduction in liquidity translates to a reduction in anonymity set, meaning it is probably more likely that Alice will be running most of the nodes that do support your OmniBOLT-based asset and even if you try to route your funds elsewhere, if you use OmniBOLT, it is likely that Alice will be able to track where you moved your funds.
>
> You are better off with this scheme if you want to "clean" 1000 BTC:
>
> * Set up a published LN node with already-clean funds (or just clean a small amount of BTC using existing CoinJoin methods).
> * Leave it running for a while, or use your existing one.
> * Make all or at least most of its channels published!
> * Make sure it has at least some incoming capacity, use the swap-to-onchain trick or buy incoming liquidity.
> * Set up a throwaway LN node using your dirty 1000 BTC.
> * On your throwaway, create channel(s) to randomly-selected LN nodes.
> * Send amounts from the throwaway to your published LN node.
> * At a later time, send from your published LN node to e.g. Boltz Exchange offchain-to-onchain swap to get funds back onchain and get more incoming capacity to your published LN node.
> * Repeat until you have drained all the funds from your throwaway node.
> * Close the channels of your throwaway node and destroy all evidence of it having ever existed.
>
> This provides privacy:
>
> * By using an intermediate published node to temporarily hold your funds:
> * You disrupt timing correlation from the outgoing payments of your dubious throwaway node to the Boltz Exchange payment: first you pay to your published node, let the funds stew a bit, then send to the Boltz Exchange.
> * Published node has deniability: payments to that node could conceivably be destined elsewhere i.e. the published node can claim it was just forwarding to someone else.
> * Source routing means that Boltz Exchange can report your onchain address, but cannot correlate it with your published node.
>
> Regards,
> ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220405/9506edbb/attachment.html>

2023-06-09 13:05:41

- reply

📅 Original date posted:2022-03-25
📝 Original message:
Good morning,
Things that affect privacy particularly when large sums of money are involved in bitcoin:
Liquidity, Anonymity set, Amounts, Type of addresses/scripts, Block, Locktime and Version
I have left out things that aren't part of bitcoin protocol or blockchain like KYC. It is difficult for users to move large sums of BTC without being observed because bitcoin does not have confidential transactions to hide amounts. Coinjoin implementations have their own issues, trade-offs, some might even censor transactions and big amounts will still be a problem. Coinswap might be an alternative in future however I wanted to share one solution that could be helpful in improving privacy.
Synonym did first [stablecoin transaction][1] in a lightning channel using Omni BOLT. Consider Alice starts a bitcoin project in which a lightning channel is used for assets like stablecoin. Bob wants to use 1000 BTC linked with an incident. He opens channels with Alice, gets stablecoin which can be used in any project that supports Omni BOLT assets.
Questions:
What is the lightning channel capacity when using Omni BOLT?
What else can be improved in this setup? Anything else that I maybe missing?
I added 'fifty shades of privacy' in subject because it was the first thing that came to my mind when I look at privacy in bitcoin and lightning.
[1]: https://youtu.be/MfaqYeyake8
pushd
---
parallel lines meet at infinity?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220326/7def2c9b/attachment.html>

2023-06-07 23:07:59

- reply

📅 Original date posted:2022-04-22
📝 Original message: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 +0000
> From: Luke Dashjr luke at dashjr.org
>
> To: bitcoin-dev at lists.linuxfoundation.org, darosior
> darosior at protonmail.com
>
> Subject: Re: [bitcoin-dev] ANYPREVOUT in place of CTV
> Message-ID: 202204221701.15307.luke at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> ------------------------------
>
> 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 42
> *******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220422/608937c7/attachment.html>

2023-06-07 23:07:58

- reply

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

2023-06-07 23:06:24

- reply

📅 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: https://i.postimg.cc/zv4M6MSp/2KM5tcE.png
>>
>> 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>

2023-06-07 23:06:22

- reply

📅 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: https://i.postimg.cc/zv4M6MSp/2KM5tcE.png
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>

2023-06-07 23:06:21

- reply

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

2023-06-07 23:06:20

- reply

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

2023-06-07 23:06:20

- reply

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

2023-06-07 23:06:20

- reply

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

2023-06-07 23:06:19

- reply

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

2023-06-07 23:06:01

- reply

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