rich1.0npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwethttps://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetnjumphttps://nostr.ae📅 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).