What is Nostr?
George Balch [ARCHIVE] /
npub1pds…sw0k
2023-06-07 18:10:19

George Balch [ARCHIVE] on Nostr: đź“… Original date posted:2018-01-28 đź“ť Original message:If miners leave ...

đź“… Original date posted:2018-01-28
đź“ť Original message:If miners leave transactions out of a block they do pay a cost by not being
rewarded those fees. If they include their own spam transactions to get
back the fee they gain nothing. Since blocks can have fees resulting in
hundreds of thousands of dollars, it would seem unlikely that miners incur
a huge cost for not including transactions.

On Sun, Jan 28, 2018 at 8:54 AM, Lucas Clemente Vella via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> If the miner wants to force fees up, why would he fill up a block with
> placeholder high fee transactions, instead of simply cutting off
> transactions paying less fee than he is willing to take? Is there any
> evidence someone is doing such a thing for whatever reason?
>
> 2018-01-27 6:45 GMT-02:00 Nathan Parker via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org>:
>
>> 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
>>
>>
>
>
> --
> Lucas Clemente Vella
> lvella at gmail.com
>
> _______________________________________________
> 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/20180128/dc779353/attachment.html>;
Author Public Key
npub1pdskf6mnmxvpka4m5asm9dleucte2mn4c36nulf3j2flrs5a9xeqhtsw0k