Topic: [PROBLEM & SOLUTION] Blocks fees to be rewarded to the next block's miner? (Read 700 times)
August 22, 2017, 09:07:59 AM
Bump
August 12, 2017, 11:02:39 AM
Neither they know if they will be the ones finding the current block.
Hi TryNinja, thanks for your reply!
As I explained in the first post, miners just have to not relay those spammy transactions into the bitcoin network until they mine the block, so that they don't get included in the blockchain by other miner.
When they finally mine a block and broadcast it, that's the first time the network gets to know about those spammy txs, and the miner gets back all the fees that they spent.
August 12, 2017, 10:30:14 AM
This spam wouldn't be so profitable anyway.
In the actual situation, how can you be sure the block will be mined by you? Miners would be paying thousands in fees but without any guarantee that they will mine the block and receive everything back to them.
If most of the blocks are mined by one or two individuals, and they are sure that they will receive everything spent in fees back, they would also be sure that the next block will be found by them, which means that we wouldn't be safe from malicious miners anyway.
In the actual situation, how can you be sure the block will be mined by you? Miners would be paying thousands in fees but without any guarantee that they will mine the block and receive everything back to them.
If most of the blocks are mined by one or two individuals, and they are sure that they will receive everything spent in fees back, they would also be sure that the next block will be found by them, which means that we wouldn't be safe from malicious miners anyway.
Quote
That way, malicious miners would be no longer interested in including lots of txs paying lots of fees on a block to raise the "recommended fee", because they can't be sure they will be lucky and mine the next block to get the fees they paid back. It would no longer be profitable for them.
Neither they know if they will be the ones finding the current block. August 12, 2017, 09:33:16 AM
Hi!
I was thinking yesterday about an idea that I think could help to solve one specific problem of bitcoin. Let me know what you think!
Users decide what fee they want to spend on a tx depending on how fast they want it to be confirmed. Blocks can hold a limited amount of txs, so, miners always try to include those that paid the most satoshis/byte first. When there is network congestion (more txs being sent that can fit in a block), either you pay higher fees or your txs could take longer than expected to confirm.
The client (software, website wallets, etc) suggests the user a "recommended fee" for their txs, which is calculated, among other things, depending on the fees paid by txs included in the previous blocks.
The problem: Malicious miners could use this to increase the fee users have to pay to send txs. They could create lots of spammy txs with high fees, include them in their own block, and then the network would think you must spend higher fees to get your txs confirmed. Since miners are including those txs in their own blocks (without actually relaying them to the network so that they won't get mined by other miners), they would be receiving the fees of such txs, and it would be cost-less for them.
Due to this, miners could potentially make the fees go higher with no cost for them. They probably do it or they probably don't, we don't know. But I would sleep better at night if I knew they don't do it because they CAN'T, rather than because they are good people and they wouldn't do such thing.
The solution: One easy way to solve this could be if, when a block gets mined, the fees obtained by the block, instead of being claimed by the miner that mined THAT block, they are claimed by the miner that mines the NEXT block.
That way, malicious miners would be no longer interested in including lots of txs paying lots of fees on a block to raise the "recommended fee", because they can't be sure they will be lucky and mine the next block to get the fees they paid back. It would no longer be profitable for them.
Miners would however still be interested in filling in the blocks and including as many transactions as possible, since they could actually be the ones to mine the next block, and if that's the case, they would still want to get the biggest reward possible.
How to implement: I haven't thought this part carefully yet, but I think this could be done in a way that is completely backwards-compatible. All we would need to do is to add a new rule on future versions of the bitcoin client in which they will only validate new blocks if the coinbase tx pays the reward to an specific "anyone-can-spend" output, such as an script that doesn't require any signature to be validated, or just a bitcoin address derived from a private key which is public and hardcoded in the client. That way, miners could add a secondary transaction spending the coins gathered by the previous block (or actually, 100 blocks before, since the coinbase txs needs to mature for some blocks before it is spent).
Thanks for reading! Thoughts?
I was thinking yesterday about an idea that I think could help to solve one specific problem of bitcoin. Let me know what you think!
Users decide what fee they want to spend on a tx depending on how fast they want it to be confirmed. Blocks can hold a limited amount of txs, so, miners always try to include those that paid the most satoshis/byte first. When there is network congestion (more txs being sent that can fit in a block), either you pay higher fees or your txs could take longer than expected to confirm.
The client (software, website wallets, etc) suggests the user a "recommended fee" for their txs, which is calculated, among other things, depending on the fees paid by txs included in the previous blocks.
The problem: Malicious miners could use this to increase the fee users have to pay to send txs. They could create lots of spammy txs with high fees, include them in their own block, and then the network would think you must spend higher fees to get your txs confirmed. Since miners are including those txs in their own blocks (without actually relaying them to the network so that they won't get mined by other miners), they would be receiving the fees of such txs, and it would be cost-less for them.
Due to this, miners could potentially make the fees go higher with no cost for them. They probably do it or they probably don't, we don't know. But I would sleep better at night if I knew they don't do it because they CAN'T, rather than because they are good people and they wouldn't do such thing.
The solution: One easy way to solve this could be if, when a block gets mined, the fees obtained by the block, instead of being claimed by the miner that mined THAT block, they are claimed by the miner that mines the NEXT block.
That way, malicious miners would be no longer interested in including lots of txs paying lots of fees on a block to raise the "recommended fee", because they can't be sure they will be lucky and mine the next block to get the fees they paid back. It would no longer be profitable for them.
Miners would however still be interested in filling in the blocks and including as many transactions as possible, since they could actually be the ones to mine the next block, and if that's the case, they would still want to get the biggest reward possible.
How to implement: I haven't thought this part carefully yet, but I think this could be done in a way that is completely backwards-compatible. All we would need to do is to add a new rule on future versions of the bitcoin client in which they will only validate new blocks if the coinbase tx pays the reward to an specific "anyone-can-spend" output, such as an script that doesn't require any signature to be validated, or just a bitcoin address derived from a private key which is public and hardcoded in the client. That way, miners could add a secondary transaction spending the coins gathered by the previous block (or actually, 100 blocks before, since the coinbase txs needs to mature for some blocks before it is spent).
Thanks for reading! Thoughts?
Jump to: