đź“… Original date posted:2018-01-27
đź“ť Original message:The OP premise is flawed:
https://github.com/libbitcoin/libbitcoin/wiki/Fee-Recovery-Fallacy
as is the idea that side fees are incentive incompatible:
https://github.com/libbitcoin/libbitcoin/wiki/Side-Fee-Fallacy
e
On 01/27/2018 11:06 AM, Gregory Maxwell via bitcoin-dev wrote:
> Not incentive compatible. Miners would prefer to include transactions
> paying fees via alternative mechanisms (anyone can spend outputs,
> direct pay to miner outputs, or completely out of band), if they even
> paid attention to internal fees at all they would give a lot more
> weight to direct payment fees. Users would accordingly pay much lower
> fees if they used these alternatives instead of directly, so the
> equlibrium state is almost everyone bypassing. Bypass fee mechenisms
> have been supported by miners since 2011 too, so it isn't just
> conjecture.
>
> On Sat, Jan 27, 2018 at 8:45 AM, Nathan Parker via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Miners can fill their blocks with transactions paying very high fees at no
>> cost because they get the fees back to themselves. They can do this for
>> different purposes, like trying to increase the recommended fee. Here I
>> propose a backwards-compatible solution to this problem.
>>
>> The solution would be to reward the fees of the current block to the miner
>> of the next block (or X blocks after the current one). That way, if a miner
>> floods its own block with very high fee transactions, those fees are no
>> longer given back to itself, but to the miner of future blocks which could
>> potentially be anyone. Flooding blocks with fake txs is now discouraged.
>> However, filling blocks with real transactions paying real fees is still
>> encouraged because you could be the one to mine the block that would claim
>> this reward.
>>
>> The way to implement this in a backwards-compatible fashion would be to
>> enforce miners to set an anyone-can-spend output in the coinbase transaction
>> of the block (by adding this as a rule for verifying new blocks). The miner
>> of 100 blocks after the current one can add a secondary transaction spending
>> this block's anyone-can-spend coinbase transaction (due to the coinbase
>> needing 100 blocks to mature) and thus claiming the funds. This way, the
>> block reward of a block X is always transferred to the miner of block X+100.
>>
>> Implementing this would require a soft-fork. Since that secondary
>> transaction needs no signature whatsoever, the overhead caused by that extra
>> transaction is negligible.
>>
>> Possible Downside: When the fork is activated, the miners won’t get any
>> reward for mining blocks for a period of 100 blocks. They could choose to
>> power off the mining equipment for maintenance or to save power over that
>> period, so the hashrate could drop temporarily. However, if the hashrate
>> drops too much, blocks would take much longer to mine, and miners wouldn’t
>> want that either since they want to go through those 100 reward-less blocks
>> as soon as possible so they can start getting rewards from mining again.
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180127/f4627e13/attachment.sig>;
Eric Voskuil [ARCHIVE] /
npub1sg…ppx3c
2023-06-07 18:10:18
in reply to nevent1q…8lcl
Author Public Key
npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3cPublished at
2023-06-07 18:10:18Event JSON
{
"id": "dbd93e1530856f218668223031588f310166a4e81c9da5cdc4400376dee64966",
"pubkey": "82205f272f995d9be742779a3c19a2ae08522ca14824c3a3b01525fb5459161e",
"created_at": 1686161418,
"kind": 1,
"tags": [
[
"e",
"8aa1a2e99bfee38bd0f906d936318c57f05a80fcd4e5ba689c4b18f16da0811f",
"",
"root"
],
[
"e",
"a1fb32103e1ae87dff07c6797cf62bc65a9cc1e528359d90ffeb0ab11c266371",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2018-01-27\n📝 Original message:The OP premise is flawed:\n\nhttps://github.com/libbitcoin/libbitcoin/wiki/Fee-Recovery-Fallacy\n\nas is the idea that side fees are incentive incompatible:\n\nhttps://github.com/libbitcoin/libbitcoin/wiki/Side-Fee-Fallacy\n\ne\n\nOn 01/27/2018 11:06 AM, Gregory Maxwell via bitcoin-dev wrote:\n\u003e Not incentive compatible. Miners would prefer to include transactions\n\u003e paying fees via alternative mechanisms (anyone can spend outputs,\n\u003e direct pay to miner outputs, or completely out of band), if they even\n\u003e paid attention to internal fees at all they would give a lot more\n\u003e weight to direct payment fees. Users would accordingly pay much lower\n\u003e fees if they used these alternatives instead of directly, so the\n\u003e equlibrium state is almost everyone bypassing. Bypass fee mechenisms\n\u003e have been supported by miners since 2011 too, so it isn't just\n\u003e conjecture.\n\u003e \n\u003e On Sat, Jan 27, 2018 at 8:45 AM, Nathan Parker via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e Miners can fill their blocks with transactions paying very high fees at no\n\u003e\u003e cost because they get the fees back to themselves. They can do this for\n\u003e\u003e different purposes, like trying to increase the recommended fee. Here I\n\u003e\u003e propose a backwards-compatible solution to this problem.\n\u003e\u003e\n\u003e\u003e The solution would be to reward the fees of the current block to the miner\n\u003e\u003e of the next block (or X blocks after the current one). That way, if a miner\n\u003e\u003e floods its own block with very high fee transactions, those fees are no\n\u003e\u003e longer given back to itself, but to the miner of future blocks which could\n\u003e\u003e potentially be anyone. Flooding blocks with fake txs is now discouraged.\n\u003e\u003e However, filling blocks with real transactions paying real fees is still\n\u003e\u003e encouraged because you could be the one to mine the block that would claim\n\u003e\u003e this reward.\n\u003e\u003e\n\u003e\u003e The way to implement this in a backwards-compatible fashion would be to\n\u003e\u003e enforce miners to set an anyone-can-spend output in the coinbase transaction\n\u003e\u003e of the block (by adding this as a rule for verifying new blocks). The miner\n\u003e\u003e of 100 blocks after the current one can add a secondary transaction spending\n\u003e\u003e this block's anyone-can-spend coinbase transaction (due to the coinbase\n\u003e\u003e needing 100 blocks to mature) and thus claiming the funds. This way, the\n\u003e\u003e block reward of a block X is always transferred to the miner of block X+100.\n\u003e\u003e\n\u003e\u003e Implementing this would require a soft-fork. Since that secondary\n\u003e\u003e transaction needs no signature whatsoever, the overhead caused by that extra\n\u003e\u003e transaction is negligible.\n\u003e\u003e\n\u003e\u003e Possible Downside: When the fork is activated, the miners won’t get any\n\u003e\u003e reward for mining blocks for a period of 100 blocks. They could choose to\n\u003e\u003e power off the mining equipment for maintenance or to save power over that\n\u003e\u003e period, so the hashrate could drop temporarily. However, if the hashrate\n\u003e\u003e drops too much, blocks would take much longer to mine, and miners wouldn’t\n\u003e\u003e want that either since they want to go through those 100 reward-less blocks\n\u003e\u003e as soon as possible so they can start getting rewards from mining again.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 490 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180127/f4627e13/attachment.sig\u003e",
"sig": "e12c82b8b1d44b6796d4ea6147981567f037ca7863fb1f8e87c5326c211e0e9064bae4d0995ba6c0bd44ef4870e16d10ac31dfcdf6ec20efc26da325215e66ac"
}