š
Original date posted:2019-04-07
š Original message:Good morning simondev1,
It seems the algorithm would greatly increase validation time.
In particular, if the current limit is removed (as in hardforked proposal) then a 1Tb block can be used to attack the network, since sorting would require looking through the entire block.
Thus, validation time would still limit the practical block sizes that can be deployed with this.
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
āāāāāāā Original Message āāāāāāā
On Sunday, April 7, 2019 4:50 PM, simondev1 via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Dear bitcoin developers,
> Ā
> New BIP: https://github.com/bitcoin/bips/pull/774
> Ā
> ==Abstract==
> Logarithm of transaction fee limits block size.
> Ā
> ==Motivation==
> Keep block space small.
> Waste less with spam transactions.
> Auto balance Fees: Increase very low fees, Descrease very high fees.
> Allow larger size when sender pays a lot.
> Allow wallets to calculate/display how much average free block space there is for each fee price.
> Allow senders to have more control about how the fee/priority of their transaction will behave, especially in the case of increased adoption in the future.
> Ā
> ==Specification==
> Every transaction has to fit into the following block space:
> Input variable 'FeeInSatoshiPerByte': Must be positive or 0
> type: double
> unit: Satishi per byte
> Output:
> type: uint
> unit: bytes
> Formula:
> floor( log10( 1.1 + FeeInSatoshiPerByte ) * 1024 * 1024 )
> Ā
> ==Implementation==
> Sort transactions by FeeInSatoshiPerByte (lowest first)
> For each transaction starting from lowest FeeInSatoshiPerByte: Sum up the bytes of space used so far. Check if summed up bytes of space used so far is smaller or equal than the formula result.
> If this is valid for each transaction then the blocksize is valid.
> Ā
> ==Backward compatibility==
> Soft fork: If applied AND old hardcoded block size limit is kept.
> Hard fork: If applied AND old hardcoded block size limit is removed.
>
> Regards, simondev1
>
ZmnSCPxj [ARCHIVE] /
npub1g5ā¦3ms3l
2023-06-07 18:17:37
in reply to nevent1qā¦wq4l
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-07 18:17:37Event JSON
{
"id": "12d5718d06606381a7604f421d875b4fda4595da2ae27f514a3bf08bf623208d",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686161857,
"kind": 1,
"tags": [
[
"e",
"722e1de047fd5a9c7312a5a0d56a4911c0ecb42ffc880d286aa7bdcc39193466",
"",
"root"
],
[
"e",
"4fc3526643c2a2f4f150e91cc14e4c9f1431a3ac78a2dfd47b69d20b47b23413",
"",
"reply"
],
[
"p",
"4ae81aafdc23f738a441a761012e766c3ad6dc53c9a288d7b5d51934c861c291"
]
],
"content": "š
Original date posted:2019-04-07\nš Original message:Good morning simondev1,\n\nIt seems the algorithm would greatly increase validation time.\nIn particular, if the current limit is removed (as in hardforked proposal) then a 1Tb block can be used to attack the network, since sorting would require looking through the entire block.\nThus, validation time would still limit the practical block sizes that can be deployed with this.\n\nRegards,\nZmnSCPxj\n\nSent with ProtonMail Secure Email.\n\nāāāāāāā Original Message āāāāāāā\nOn Sunday, April 7, 2019 4:50 PM, simondev1 via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Dear bitcoin developers,\n\u003e Ā \n\u003e New BIP: https://github.com/bitcoin/bips/pull/774\n\u003e Ā \n\u003e ==Abstract==\n\u003e Logarithm of transaction fee limits block size.\n\u003e Ā \n\u003e ==Motivation==\n\u003e Keep block space small.\n\u003e Waste less with spam transactions.\n\u003e Auto balance Fees: Increase very low fees, Descrease very high fees.\n\u003e Allow larger size when sender pays a lot.\n\u003e Allow wallets to calculate/display how much average free block space there is for each fee price.\n\u003e Allow senders to have more control about how the fee/priority of their transaction will behave, especially in the case of increased adoption in the future.\n\u003e Ā \n\u003e ==Specification==\n\u003e Every transaction has to fit into the following block space:\n\u003e Input variable 'FeeInSatoshiPerByte': Must be positive or 0\n\u003e type: double\n\u003e unit: Satishi per byte\n\u003e Output:\n\u003e type: uint\n\u003e unit: bytes\n\u003e Formula:\n\u003e floor( log10( 1.1 + FeeInSatoshiPerByte ) * 1024 * 1024 )\n\u003e Ā \n\u003e ==Implementation==\n\u003e Sort transactions by FeeInSatoshiPerByte (lowest first)\n\u003e For each transaction starting from lowest FeeInSatoshiPerByte: Sum up the bytes of space used so far. Check if summed up bytes of space used so far is smaller or equal than the formula result.\n\u003e If this is valid for each transaction then the blocksize is valid.\n\u003e Ā \n\u003e ==Backward compatibility==\n\u003e Soft fork: If applied AND old hardcoded block size limit is kept.\n\u003e Hard fork: If applied AND old hardcoded block size limit is removed.\n\u003e\n\u003e Regards, simondev1\n\u003e",
"sig": "1794860cef158e437db767b7ec7a2cf70ebe9dfe08a12a8ffba79606efa1e26b9a46352b833cac5056da3a5a0fd1c318d7bc1c5b5df078548c2df92de4b0abf0"
}