Punishing empty blocks?



Summary:

In a thread on Bitcoin.org, the idea of miners publishing their own transaction rules was discussed. However, it was pointed out that it may be difficult to determine these rules from data alone. One suggestion was to create an open service where miners could publish a short string tying to the service and the service would have different metadata, including the miner's transaction guarantees. This service was offered to be hosted before and still willing to do so. Another issue that came up was slower confirmations giving people a reason to set higher fees. Even if it takes four blocks to get a transaction included instead of one, once it is included, you still benefit from every new block in terms of security. There are also techniques for instant transactions which continue to be refined and improved. Punishing 1-tx blocks was deemed as complete and utter nonsense by some as it is trivial to include a bogus second transaction. Additionally, any additional challenges towards miners like hashes of the previous block were seen as at best useless. There was also the question of the ethical aspect of a miner's choice not to include someone's transaction. It was argued that if a miner wishes not to include a transaction, that is their choice and they have no obligation to sell their service to anyone. Therefore, if someone really wants a miner to include their transaction, they will have to offer to pay more. The right measures to address slow confirmations or more blocks including transactions were seen as educating users about the relationship between confirmation speed and fees and raising the default transaction fee. All markets must have a certain tension, meaning there must be miners who don't include transactions for there to be users who want their transactions included more quickly. If this balance is interfered with, it could keep transaction fees below market level, making the transition from inflation-financed hashing to transaction-financed hashing more painful and disruptive.


Updated on: 2023-06-06T04:40:06.059980+00:00