📅 Original date posted:2019-04-07 📝 Original message:Related ideas previously ...

Natanael [ARCHIVE] /

npub1798…pmjt

2023-06-07 18:17:37

in reply to nevent1q…deqk

📅 Original date posted:2019-04-07
📝 Original message:Related ideas previously submitted by me;

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013885.html

Title: Block size adjustment idea - expedience fees + difficulty scaling
proportional to block size (+ fee pool)

Den sön 7 apr. 2019 17:45simondev1 via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> skrev:

> 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
>
> _______________________________________________
> 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/20190407/0f09ef59/attachment.html>;

Author Public Key

npub1798ncudyucap9jzzujjsgufx8tdykm8auzfledjcs6f6wf4ekqvq8lpmjt

Seen on

wss://relay.nostr.band

Show more details

Published at

2023-06-07 18:17:37

Kind type

1 Short Text Note

Event JSON

{ "id": "36b6370d04309557b949d0cffac0670766bb1a04cab0ae3ea0a0b9c2247f3048", "pubkey": "f14f3c71a4e63a12c842e4a50471263ada4b6cfde093fcb6588693a726b9b018", "created_at": 1686161857, "kind": 1, "tags": [ [ "e", "722e1de047fd5a9c7312a5a0d56a4911c0ecb42ffc880d286aa7bdcc39193466", "", "root" ], [ "e", "a01d7b4f16d74d8c8a71ddc7ca60af8a9520187a0666e792ff73ad9ee2acd90e", "", "reply" ], [ "p", "4ae81aafdc23f738a441a761012e766c3ad6dc53c9a288d7b5d51934c861c291" ] ], "content": "📅 Original date posted:2019-04-07\n📝 Original message:Related ideas previously submitted by me;\n\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013885.html\n\nTitle: Block size adjustment idea - expedience fees + difficulty scaling\nproportional to block size (+ fee pool)\n\nDen sön 7 apr. 2019 17:45simondev1 via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e skrev:\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\n\u003e is for each fee price.\n\u003e Allow senders to have more control about how the fee/priority of their\n\u003e transaction will behave, especially in the case of increased adoption in\n\u003e 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\n\u003e bytes of space used so far. Check if summed up bytes of space used so far\n\u003e 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\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-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190407/0f09ef59/attachment.html\u003e", "sig": "2a27118ac868e03d6302e5b26e044dd733fc3c2dd9d6dd00125f7251b57af74f83147909a50fa1be7b5e40af4f646445c76ac0a34fe5fd577199a6211f7ea850" }