Chris Priest [ARCHIVE] on Nostr: ๐
Original date posted:2016-08-06 ๐ Original message:Because the blocksize ...
๐
Original date posted:2016-08-06
๐ Original message:Because the blocksize limit is denominated in bytes, miners choose
transactions to add to a block based on fee/byte ratio. This mean that
if you make a transaction with a lot of inputs, your transaction will
be very big, an you'll have a to pay a lot in fees to get that
transaction included in a block.
For a long time I have been of the belief that it is a flaw in bitcoin
that you have to pay more to move coins that are sent to you via small
value UTXOs, compared to coins sent to you through a single high
values UTXO. There are many legitimate uses of bitcoin where you get
the money is very small increments (such as microtransactions). This
is the basis for my "Wildcard inputs" proposal now known as BIP131.
This BIP was rejected because it requires a database index, which
people thought would make bitcoin not scale, which I think is complete
malarkey, but it is what it is. It has recently occurred to me a way
to achieve the same effect without needing the database index.
If the blocksize limit was denominated in outputs, miners would choose
transactions based on maximum fee per output. This would essentially
make it free to include an input to a transaction.
If the blocksize limit were removed and replaced with a "block output
limit", it would have multiple positive effects. First off, like I
said earlier, it would incentivize microtransactions. Secondly it
would serve to decrease the UTXO set. As I described in the text of
BIP131, as blocks fill up and fees rise, there is a "minimum
profitability to include an input to a transaction" which increases.
At the time I wrote BIP131, it was something like 2 cents: Any UTXO
worth less than 2 cents was not economical to add to a transaction,
and therefore likely to never be spent (unless blocks get bigger and
fee's drop). This contributes to the "UTXO bloat problem" which a lot
of people talk about being a big problem.
If the blocksize limit is to be changed to a block output limit, the
number the limit is set to should be roughly the amount of outputs
that are found in 1MB blocks today. This way, the change should be
considered non-controversial. I think its silly that some people think
its a good thing to keep usage restricted, but again, it is what it
is.
Blocks can be bigger than 1MB, but the extra data in the block will
not result in more people using bitcoin, but rather existing users
spending inputs to decrease the UTXO set.
It would also bring about data that can be used to determine how to
scale bitcoin in the future. For instance, we have *no idea* how the
network will handle blocks bigger than 1MB, simply because the network
has never seen blocks bigger than 1MB. People have set up private
networks for testing bigger blocks, but thats not quite the same as
1MB+ blocks on the actual live network. This change will allow us to
see what actually happens when bigger blocks gets published.
Why is this change a bad idea?
Published at
2023-06-07 17:52:18Event JSON
{
"id": "608bae2788dcacf0213a48b64207eb77edc8e786ab2fca98f17c2d229169f444",
"pubkey": "3b5311200328974edeaa105b1a8f60d243e653cc63b6bb29f61dc696e04189ed",
"created_at": 1686160338,
"kind": 1,
"tags": [
[
"e",
"227c7e61f339b988c564332237e38e2ff169098ab5f3bd26b06334d4b1a8e368",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "๐
Original date posted:2016-08-06\n๐ Original message:Because the blocksize limit is denominated in bytes, miners choose\ntransactions to add to a block based on fee/byte ratio. This mean that\nif you make a transaction with a lot of inputs, your transaction will\nbe very big, an you'll have a to pay a lot in fees to get that\ntransaction included in a block.\n\nFor a long time I have been of the belief that it is a flaw in bitcoin\nthat you have to pay more to move coins that are sent to you via small\nvalue UTXOs, compared to coins sent to you through a single high\nvalues UTXO. There are many legitimate uses of bitcoin where you get\nthe money is very small increments (such as microtransactions). This\nis the basis for my \"Wildcard inputs\" proposal now known as BIP131.\nThis BIP was rejected because it requires a database index, which\npeople thought would make bitcoin not scale, which I think is complete\nmalarkey, but it is what it is. It has recently occurred to me a way\nto achieve the same effect without needing the database index.\n\nIf the blocksize limit was denominated in outputs, miners would choose\ntransactions based on maximum fee per output. This would essentially\nmake it free to include an input to a transaction.\n\nIf the blocksize limit were removed and replaced with a \"block output\nlimit\", it would have multiple positive effects. First off, like I\nsaid earlier, it would incentivize microtransactions. Secondly it\nwould serve to decrease the UTXO set. As I described in the text of\nBIP131, as blocks fill up and fees rise, there is a \"minimum\nprofitability to include an input to a transaction\" which increases.\nAt the time I wrote BIP131, it was something like 2 cents: Any UTXO\nworth less than 2 cents was not economical to add to a transaction,\nand therefore likely to never be spent (unless blocks get bigger and\nfee's drop). This contributes to the \"UTXO bloat problem\" which a lot\nof people talk about being a big problem.\n\nIf the blocksize limit is to be changed to a block output limit, the\nnumber the limit is set to should be roughly the amount of outputs\nthat are found in 1MB blocks today. This way, the change should be\nconsidered non-controversial. I think its silly that some people think\nits a good thing to keep usage restricted, but again, it is what it\nis.\n\nBlocks can be bigger than 1MB, but the extra data in the block will\nnot result in more people using bitcoin, but rather existing users\nspending inputs to decrease the UTXO set.\n\nIt would also bring about data that can be used to determine how to\nscale bitcoin in the future. For instance, we have *no idea* how the\nnetwork will handle blocks bigger than 1MB, simply because the network\nhas never seen blocks bigger than 1MB. People have set up private\nnetworks for testing bigger blocks, but thats not quite the same as\n1MB+ blocks on the actual live network. This change will allow us to\nsee what actually happens when bigger blocks gets published.\n\nWhy is this change a bad idea?",
"sig": "3334a2d1df2db83742194a86690f6ccceba209e54e4f0536ba16034dc98ddf03728425b6d36fb9df3ffadd8d9be7f7657eaf7d8353b6766dc60d072c04cd81ec"
}