From: Ethan Heilman <eth3rs@gmail•com>
To: Michael Cassano <mcassano@gmail•com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Mandatory Inclusion of Old Transactions in Blocks
Date: Sat, 28 Dec 2024 13:48:52 -0500 [thread overview]
Message-ID: <CAEM=y+V5RTz2g8JvbLuZ3zs2RAmNPrN3WvKVfU7X69pD2j-8nw@mail.gmail.com> (raw)
In-Reply-To: <CAAg3Je3k4RrQzUQ-x-D81NeMPsFuZTVYFKem9uN9MYP-CnmdRg@mail.gmail.com>
You say:
> Bitcoin network nodes will validate blocks only if they contain the required percentage of old transactions. If a block fails to meet this criterion, it will be deemed invalid and rejected by the network.
This requires that network nodes reach consensus on what the oldest
transactions are. This is the technical problem you need to solve to
make your proposal practical, but I don't see that as a bad thing as
it is a very interesting problem. If you can solve this problem, you
can probably also solve the problem of how to enforce that Bitcoin
miners only include the transactions with the highest fee rate.
Enforcing the highest fee rate at the consensus level may be an
effective tool against MEVil.
This does seem like a hard problem to solve, because reaching
consensus on transactions in mempool is very similar to what bitcoin
blocks are already trying to achieve. Perhaps there is a more creative
solution. It is worth looking at but it doesn't seem ready for a BIP.
On Sat, Dec 28, 2024 at 11:26 AM Michael Cassano <mcassano@gmail•com> wrote:
>
> I reject the premise of this proposed BIP. Mandating miners to include a specific percentage of transactions based on age fundamentally undermines the core principles of Bitcoin: decentralization, voluntary participation, and free market dynamics.
>
> Bitcoin thrives because of its permissionless, free-market system. Miners are incentivized to prioritize transactions based on fees and network conditions, not arbitrary mandates. Imposing a rule like this introduces central planning into what is a decentralized system.
>
> The proposal claims to fight centralization, but will likely backfire. Mandates like this add operational complexity and reduce efficiency for miners. Smaller miners, who are already operating on thin margins, will be disproportionately impacted, driving them out of the market and further centralizing mining power. If censorship-resistant mining is valuable, let the free market reward those who provide it. If there’s demand for miners to include old or low-fee transactions, let someone build tools and pools that prioritize this voluntarily. Solutions shall arise from innovation, not coercion.
>
> Best regards,
> Mike
>
> On Sat, Dec 28, 2024 at 8:58 AM developer <estensioni.app@gmail•com> wrote:
>>
>> Status: Draft
>> Type: Standards Track
>> Created: December 27, 2024
>> Abstract
>>
>> This proposal mandates miners to include at least 0.1% of transactions in their blocks from the oldest transactions by date, even if they have low fees. This mechanism helps prevent mining centralization and censorship, encouraging miners not to exclude certain transactions.
>> Motivation
>>
>> The increasing centralization of Bitcoin mining and potential regulations that may require miners to censor or exclude certain transactions pose a threat to the Bitcoin network. Mandating the inclusion of a small percentage of old transactions, even with low fees, ensures that no single miner can censor block contents without sacrificing their own rewards.
>> Specification
>>
>> Mandatory Inclusion of Old even if with Low-Fee Transactions
>> Each miner is required to include at least 0.1% of the total transactions in a block from the oldest transactions in the mempool, even if their fees are below the current market average.
>> These transactions must be added to blocks regardless of their fees, prioritizing their age.
>>
>> Block Validation
>> Bitcoin network nodes will validate blocks only if they contain the required percentage of old transactions.
>> If a block fails to meet this criterion, it will be deemed invalid and rejected by the network.
>>
>> Incentives
>> Miners are incentivized to include these transactions to ensure their blocks are valid and to avoid losing block rewards.
>>
>> Advantages
>>
>> Censorship Resistance: Miners cannot censor transactions without forfeiting their rewards.
>> Greater Inclusivity: Old and low-fee transactions are assured of being confirmed.
>> Decentralization Prevention: Reducing the potential for centralized censorship keeps the Bitcoin network decentralized.
>>
>> Considerations
>>
>> Impact on the Mempool: The mempool may become more dynamic and up-to-date with fewer old, stagnant transactions.
>> Resource Management: Miners will need to adjust their systems to automatically identify and include relevant transactions.
>>
>> Conclusion
>>
>> Implementing this BIP will help maintain the integrity and decentralization of the Bitcoin network, preventing censorship and ensuring all transactions have a fair chance of confirmation.
>>
>> --
>> You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
>> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/fa4a8cd3-778c-4793-8dd4-5662475b6601n%40googlegroups.com.
>
> --
> You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAg3Je3k4RrQzUQ-x-D81NeMPsFuZTVYFKem9uN9MYP-CnmdRg%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BV5RTz2g8JvbLuZ3zs2RAmNPrN3WvKVfU7X69pD2j-8nw%40mail.gmail.com.
next prev parent reply other threads:[~2024-12-28 18:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-28 15:54 developer
2024-12-28 16:15 ` Michael Cassano
2024-12-28 18:48 ` Ethan Heilman [this message]
2024-12-29 16:35 ` developer
2024-12-28 16:22 ` Luke Dashjr
2024-12-28 16:23 ` [bitcoindev] " Owen Kemeys
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAEM=y+V5RTz2g8JvbLuZ3zs2RAmNPrN3WvKVfU7X69pD2j-8nw@mail.gmail.com' \
--to=eth3rs@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
--cc=mcassano@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox