📅 Original date posted:2017-09-30 📝 Original message:Gmaxwell I think what's ...

Jorge Timón [ARCHIVE] /

npub1fx9…l2d8

2023-06-07 18:06:38

in reply to nevent1q…k8mq

📅 Original date posted:2017-09-30
📝 Original message:Gmaxwell I think what's new is that in this case, with a single tx you
would take out all txs with fee below 1 btc. With current rules, you would
only remove enoguh txs for that one to fit, not empty the whole block and
mine only a block with that single tx.

On 30 Sep 2017 5:53 am, "Jorge Timón" <jtimon at jtimon.cc> wrote:

> I really don't see how this "outlier behaviour" can be prevented. I think
> it would be the norm even with your proposed "fix". Perhaps I'm missing
> something too.
>
> On 29 Sep 2017 5:24 pm, "Mark Friedenbach via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> This is correct. Under assumptions of a continuous mempool model however
>> this should be considered the outlier behavior, other than a little bit of
>> empty space at the end, now and then. A maximum fee rate calculated as a
>> filter over past block rates could constrain this outlier behavior from
>> ever happening too.
>>
>> > On Sep 29, 2017, at 3:43 AM, Daniele Pinna <daniele.pinna at gmail.com>
>> wrote:
>> >
>> > Maybe I'm getting this wrong but wouldn't this scheme imply that a
>> miner is incentivized to limit the amount of transactions in a block to
>> capture the maximum fee of the ones included?
>> >
>> > As an example, mined blocks currently carry ~0.8 btc in fees right now.
>> If I were to submit a transaction paying 1 btc in maximal money fees, then
>> the miner would be incentivized to include my transaction alone to avoid
>> that lower fee paying transactions reduce the amount of fees he can earn
>> from my transaction alone. This would mean that I could literally clog the
>> network by paying 1btc every ten minutes.
>> >
>> > Am I missing something?
>> >
>> > Daniele
>> _______________________________________________
>> 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/20170930/23101914/attachment-0001.html>;

Author Public Key

npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8

Show more details

Published at

2023-06-07 18:06:38

Kind type

1 Short Text Note

Event JSON

{ "id": "0080a7c401598191bc874b0f108f9479e45be04c149b8c75caad1a736f348553", "pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84", "created_at": 1686161198, "kind": 1, "tags": [ [ "e", "ae5bb64562efc3a1339440e5c70f6b3b8b12997d5b034703d0bb377a6fd6447b", "", "root" ], [ "e", "0302c38708de5be09141a472144e8f1dfea8d169c61b7df7bca27ca8f8a50a81", "", "reply" ], [ "p", "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84" ] ], "content": "📅 Original date posted:2017-09-30\n📝 Original message:Gmaxwell I think what's new is that in this case, with a single tx you\nwould take out all txs with fee below 1 btc. With current rules, you would\nonly remove enoguh txs for that one to fit, not empty the whole block and\nmine only a block with that single tx.\n\nOn 30 Sep 2017 5:53 am, \"Jorge Timón\" \u003cjtimon at jtimon.cc\u003e wrote:\n\n\u003e I really don't see how this \"outlier behaviour\" can be prevented. I think\n\u003e it would be the norm even with your proposed \"fix\". Perhaps I'm missing\n\u003e something too.\n\u003e\n\u003e On 29 Sep 2017 5:24 pm, \"Mark Friedenbach via bitcoin-dev\" \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e This is correct. Under assumptions of a continuous mempool model however\n\u003e\u003e this should be considered the outlier behavior, other than a little bit of\n\u003e\u003e empty space at the end, now and then. A maximum fee rate calculated as a\n\u003e\u003e filter over past block rates could constrain this outlier behavior from\n\u003e\u003e ever happening too.\n\u003e\u003e\n\u003e\u003e \u003e On Sep 29, 2017, at 3:43 AM, Daniele Pinna \u003cdaniele.pinna at gmail.com\u003e\n\u003e\u003e wrote:\n\u003e\u003e \u003e\n\u003e\u003e \u003e Maybe I'm getting this wrong but wouldn't this scheme imply that a\n\u003e\u003e miner is incentivized to limit the amount of transactions in a block to\n\u003e\u003e capture the maximum fee of the ones included?\n\u003e\u003e \u003e\n\u003e\u003e \u003e As an example, mined blocks currently carry ~0.8 btc in fees right now.\n\u003e\u003e If I were to submit a transaction paying 1 btc in maximal money fees, then\n\u003e\u003e the miner would be incentivized to include my transaction alone to avoid\n\u003e\u003e that lower fee paying transactions reduce the amount of fees he can earn\n\u003e\u003e from my transaction alone. This would mean that I could literally clog the\n\u003e\u003e network by paying 1btc every ten minutes.\n\u003e\u003e \u003e\n\u003e\u003e \u003e Am I missing something?\n\u003e\u003e \u003e\n\u003e\u003e \u003e Daniele\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-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170930/23101914/attachment-0001.html\u003e", "sig": "98708db2aa0f463ef3673638428fa9b0a5d5490ee5530692cabd63b9ead87ec9767290c742cbb0f13361d2d3fab09cfa5b5a0689d4a4790830682d62cac671f3" }