📅 Original date posted:2015-05-09
📝 Original message:On Sat, May 9, 2015 at 12:58 PM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
> RE: fixing sigop counting, and building in UTXO cost: great idea! One of
> the problems with this debate is it is easy for great ideas get lost in all
> the noise.
>
If the UTXO set cost is built in, UTXO database entries suddenly are worth
something, in addition to the bitcoin held in that entry.
A user's client might display how many they own. When sending money to a
merchant, the user might demand the merchant indicate a slot to pay to.
The user could send an ANYONE_CAN_PAY partial transaction. The transaction
would guarantee that the user has at least as many UTXOs as before.
Discussing the possibility of doing this creates an incentive to bloat the
UTXO set right now, since UTXOs would be valuable in the future.
The objective would be to make them valuable enough to encourage
conservation, but not so valuable that the UTXO contains more value than
the bitcoins in the output.
Gmaxwell's suggested "tx_size = MAX( real_size >> 1, real_size +
4*utxo_created_size - 3*utxo_consumed_size)" for a 250 byte transaction
with 1 input and 2 outputs has very little effect.
real_size + 4 * (2) - 3 * 1 = 255
That gives a 2% size penalty for adding an extra UTXO. I doubt that is
enough to change behavior.
The UTXO set growth could be limited directly. A block would be invalid if
it increases the number of UTXO entries above the charted path.
RE: a hard upper limit, with a dynamic limit under it:
>
If the block is greater than 32MB, then it means an update to how blocks
are broadcast, so that could be a reasonable hard upper limit (or maybe
31MB, or just the 20MB already suggested).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150509/ffd834c1/attachment.html>;
Tier Nolan [ARCHIVE] /
npub1g6…sl5wd
2023-06-07 15:34:00
in reply to nevent1q…hk8u
Author Public Key
npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wdSeen on
wss://relay.noswhere.comPublished at
2023-06-07 15:34:00Event JSON
{
"id": "d6489032cd8a740c8ac222a997eebb3b06d11168bae1a2ce2c296756359c1a82",
"pubkey": "46986f86b97cc97829a031b03209644d134b939d0163375467f0b1363e0d875e",
"created_at": 1686152040,
"kind": 1,
"tags": [
[
"e",
"aec396df7693e37c124fbd2891fe6c4a3b28f46e7fbc3f304a7b1d78d2f5ffbe",
"",
"root"
],
[
"e",
"287c76892158337d3874466a628e73cba749f847c2acffd9a7e57ea1bd1bc7f9",
"",
"reply"
],
[
"p",
"857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4"
]
],
"content": "📅 Original date posted:2015-05-09\n📝 Original message:On Sat, May 9, 2015 at 12:58 PM, Gavin Andresen \u003cgavinandresen at gmail.com\u003e\nwrote:\n\n\u003e RE: fixing sigop counting, and building in UTXO cost: great idea! One of\n\u003e the problems with this debate is it is easy for great ideas get lost in all\n\u003e the noise.\n\u003e\n\nIf the UTXO set cost is built in, UTXO database entries suddenly are worth\nsomething, in addition to the bitcoin held in that entry.\n\nA user's client might display how many they own. When sending money to a\nmerchant, the user might demand the merchant indicate a slot to pay to.\n\nThe user could send an ANYONE_CAN_PAY partial transaction. The transaction\nwould guarantee that the user has at least as many UTXOs as before.\n\nDiscussing the possibility of doing this creates an incentive to bloat the\nUTXO set right now, since UTXOs would be valuable in the future.\n\nThe objective would be to make them valuable enough to encourage\nconservation, but not so valuable that the UTXO contains more value than\nthe bitcoins in the output.\n\nGmaxwell's suggested \"tx_size = MAX( real_size \u003e\u003e 1, real_size +\n4*utxo_created_size - 3*utxo_consumed_size)\" for a 250 byte transaction\nwith 1 input and 2 outputs has very little effect.\n\nreal_size + 4 * (2) - 3 * 1 = 255\n\nThat gives a 2% size penalty for adding an extra UTXO. I doubt that is\nenough to change behavior.\n\nThe UTXO set growth could be limited directly. A block would be invalid if\nit increases the number of UTXO entries above the charted path.\n\nRE: a hard upper limit, with a dynamic limit under it:\n\u003e\n\nIf the block is greater than 32MB, then it means an update to how blocks\nare broadcast, so that could be a reasonable hard upper limit (or maybe\n31MB, or just the 20MB already suggested).\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150509/ffd834c1/attachment.html\u003e",
"sig": "84f2adfc18deb709f41237ec8271e8c86553e172bbad85aa067757ee92939edaf3b0c48c20bd05bc58bd8bca42c5e68d0edfd1bc1c71d8284249beb09a653f54"
}