📅 Original date posted:2015-09-03
📝 Original message:Assuming that:
1. The current block size is 1MB
2. The block reward for a full block is 25.5BTC including tx fee
3. Miner is required to pay x% of reward penalty if he is trying to
increase the size of the next block by x%
If a miner wants to increase the block size by 1 byte, the block size
has to increase by 0.0001%, and the penalty will be 0.0000255BTC/byte.
For a typical 230byte tx that'd be 0.005865BTC, or 1.35USD at current
rate. This is the effective minimum tx fee.
Jeff Garzik 於 2015-09-03 10:18 寫到:
> Thanks for the link. I readily admit only having given
> pay-to-future-miner a little bit of thought. Not convinced it sets a
> minimal tx fee in all cases.
>
> On Thu, Sep 3, 2015 at 12:55 AM, <jl2012 at xbt.hk> wrote:
>
>> Jeff Garzik via bitcoin-dev 於 2015-09-03 00:05 寫到:
>>
>>> Schemes proposing to pay with difficulty / hashpower to change
>>> block
>>> size should be avoided. The miners incentive has always been
>>> fairly
>>> straightforward - it is rational to deploy new hashpower as soon
>>> as
>>> you can get it online. Introducing the concepts of (a) requiring
>>> out-of-band collusion to change block size and/or (b) requiring
>>> miners
>>> to have idle hashpower on hand to change block size are both
>>> unrealistic and potentially corrosive. That potentially makes
>>> the
>>> block size - and therefore fee market - too close, too sensitive
>>> to
>>> the wild vagaries of the mining chip market.
>>>
>>> Pay-to-future-miner has neutral, forward looking incentives worth
>>> researching.
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> [1]
>>
>> Ref:
>>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010723.html
>> [2]
>>
>> I explained here why pay with difficulty is bad for everyone:
>> miners and users, and described the use of OP_CLTV for
>> pay-to-future-miner
>>
>> However, a general problem of pay-to-increase-block-size scheme is
>> it indirectly sets a minimal tx fee, which could be difficult and
>> arbitrary, and is against competition
>
>
>
> Links:
> ------
> [1] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010723.html
jl2012 at xbt.hk [ARCHIVE] /
npub1kc…wjfw4
2023-06-07 19:39:25
in reply to nevent1q…mdly
Author Public Key
npub1kc0zulxt7j4a0ayhzhrz7jk84y7tm4026qcky7w97hlfkxxap24qnwjfw4Published at
2023-06-07 19:39:25Event JSON
{
"id": "60076022a4ee39eae80543227e19adb0b72b412f98aa98b0da5973a317a2565d",
"pubkey": "b61e2e7ccbf4abd7f49715c62f4ac7a93cbdd5ead0316279c5f5fe9b18dd0aaa",
"created_at": 1686159565,
"kind": 1,
"tags": [
[
"e",
"dbb4e6d7748308ee67a1d1ad1fb204aeb89db8ab4acccbd7812a3205f4f42fd9",
"",
"root"
],
[
"e",
"ab36b31f86766bf32abae080dd95d84dcc859c38d18272c0a0fcf8c65fc9b528",
"",
"reply"
],
[
"p",
"b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11"
]
],
"content": "📅 Original date posted:2015-09-03\n📝 Original message:Assuming that:\n1. The current block size is 1MB\n2. The block reward for a full block is 25.5BTC including tx fee\n3. Miner is required to pay x% of reward penalty if he is trying to \nincrease the size of the next block by x%\n\nIf a miner wants to increase the block size by 1 byte, the block size \nhas to increase by 0.0001%, and the penalty will be 0.0000255BTC/byte. \nFor a typical 230byte tx that'd be 0.005865BTC, or 1.35USD at current \nrate. This is the effective minimum tx fee.\n\n\n\nJeff Garzik 於 2015-09-03 10:18 寫到:\n\u003e Thanks for the link. I readily admit only having given\n\u003e pay-to-future-miner a little bit of thought. Not convinced it sets a\n\u003e minimal tx fee in all cases.\n\u003e \n\u003e On Thu, Sep 3, 2015 at 12:55 AM, \u003cjl2012 at xbt.hk\u003e wrote:\n\u003e \n\u003e\u003e Jeff Garzik via bitcoin-dev 於 2015-09-03 00:05 寫到:\n\u003e\u003e \n\u003e\u003e\u003e Schemes proposing to pay with difficulty / hashpower to change\n\u003e\u003e\u003e block\n\u003e\u003e\u003e size should be avoided. The miners incentive has always been\n\u003e\u003e\u003e fairly\n\u003e\u003e\u003e straightforward - it is rational to deploy new hashpower as soon\n\u003e\u003e\u003e as\n\u003e\u003e\u003e you can get it online. Introducing the concepts of (a) requiring\n\u003e\u003e\u003e out-of-band collusion to change block size and/or (b) requiring\n\u003e\u003e\u003e miners\n\u003e\u003e\u003e to have idle hashpower on hand to change block size are both\n\u003e\u003e\u003e unrealistic and potentially corrosive. That potentially makes\n\u003e\u003e\u003e the\n\u003e\u003e\u003e block size - and therefore fee market - too close, too sensitive\n\u003e\u003e\u003e to\n\u003e\u003e\u003e the wild vagaries of the mining chip market.\n\u003e\u003e\u003e \n\u003e\u003e\u003e Pay-to-future-miner has neutral, forward looking incentives worth\n\u003e\u003e\u003e researching.\n\u003e\u003e\u003e \n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e [1]\n\u003e\u003e \n\u003e\u003e Ref:\n\u003e\u003e \n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010723.html\n\u003e\u003e [2]\n\u003e\u003e \n\u003e\u003e I explained here why pay with difficulty is bad for everyone:\n\u003e\u003e miners and users, and described the use of OP_CLTV for\n\u003e\u003e pay-to-future-miner\n\u003e\u003e \n\u003e\u003e However, a general problem of pay-to-increase-block-size scheme is\n\u003e\u003e it indirectly sets a minimal tx fee, which could be difficult and\n\u003e\u003e arbitrary, and is against competition\n\u003e \n\u003e \n\u003e \n\u003e Links:\n\u003e ------\n\u003e [1] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e [2]\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010723.html",
"sig": "d454338f1e3246280fb23cbcc04d16da30831c33537981b5c2caa87b0aee2958c30c8afa977eadaeae46a0bd94c75e0c6a979d9a91d51270bc99dcdca071ec73"
}