📅 Original date posted:2017-04-07
📝 Original message:On Fri, Apr 7, 2017 at 9:14 PM, Tomas <tomas at tomasvdw.nl> wrote:
> The long term *minimal disk storage* requirement, can obviously not be less
> then all the unspent outputs.
Then I think you may want to retract the claim that "As this solution,
reversing the costs of outputs and inputs, [...] updates to the
protocol addressing the UTXO growth, might not be worth considering
*protocol improvements* "
As you note that the output costs still bound the resource
requirements. Short of radical protocol changes like TXO-proofs the
UTXO data remains a driving unavoidable long term resource cost, not
an implementation detail. Implementation optimizations like improving
locality further or keeping spentness in memory do not change this
fact.
> The storage that is accessed during peak load (block validation with
> pre-synced transactions), is minimized as this only needs the transaction
> index (to lookup ptrs from hashes), the tip of the spend-tree and the tip of
Latency related costs in Bitcoin Core also do not depend on the number
of outputs in transactions in a block. When a transaction is handled
it goes into an in-memory buffer and only gets flushed later if isn't
spent before the buffer fills. A block will take more time to
validate with more inputs, same as you observer, but the aggregate
resource usage for users depends significantly on outputs (so, in fact
there is even further misaligned incentives than just the fact that
small outputs have a outsized long term cost).
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 17:59:40
in reply to nevent1q…0g47
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetPublished at
2023-06-07 17:59:40Event JSON
{
"id": "2abd8ce4b5b093cd64fdf328bf3638148ac06d97834fa31533fd72e03f67bd41",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686160780,
"kind": 1,
"tags": [
[
"e",
"d4a682be1f6603f0ff8798c52b7225cac6554e21f3aedb0c80e7d41cf71983ad",
"",
"root"
],
[
"e",
"f334bf920f7feea3c9e4a427ef5408ed9593494dacad85015697ff0d39292855",
"",
"reply"
],
[
"p",
"1c03575343555d1132a621c49466190d680da4a306ba8b992e8b87e267609cdd"
]
],
"content": "📅 Original date posted:2017-04-07\n📝 Original message:On Fri, Apr 7, 2017 at 9:14 PM, Tomas \u003ctomas at tomasvdw.nl\u003e wrote:\n\u003e The long term *minimal disk storage* requirement, can obviously not be less\n\u003e then all the unspent outputs.\n\nThen I think you may want to retract the claim that \"As this solution,\nreversing the costs of outputs and inputs, [...] updates to the\nprotocol addressing the UTXO growth, might not be worth considering\n*protocol improvements* \"\n\nAs you note that the output costs still bound the resource\nrequirements. Short of radical protocol changes like TXO-proofs the\nUTXO data remains a driving unavoidable long term resource cost, not\nan implementation detail. Implementation optimizations like improving\nlocality further or keeping spentness in memory do not change this\nfact.\n\n\u003e The storage that is accessed during peak load (block validation with\n\u003e pre-synced transactions), is minimized as this only needs the transaction\n\u003e index (to lookup ptrs from hashes), the tip of the spend-tree and the tip of\n\nLatency related costs in Bitcoin Core also do not depend on the number\nof outputs in transactions in a block. When a transaction is handled\nit goes into an in-memory buffer and only gets flushed later if isn't\nspent before the buffer fills. A block will take more time to\nvalidate with more inputs, same as you observer, but the aggregate\nresource usage for users depends significantly on outputs (so, in fact\nthere is even further misaligned incentives than just the fact that\nsmall outputs have a outsized long term cost).",
"sig": "f2839fd936c55a114444b4a3c23b63de641dadfb0fd0775b7fbf08c168110c8b726be4570f16cb5dea4b212c8f2e77d52e536c2f69aaae759f93dc6d6ddf35b9"
}