rich1.0Tomas [ARCHIVE] (npub1rs…9evk4)https://nostr.ae/npub1rsp4w56r24w3zv4xy8zfgesep45qmf9rq6aghxfw3wr7yemqnnwsf9evk4njumphttps://nostr.ae📅 Original date posted:2017-04-08 📝 Original message:On Sat, Apr 8, 2017, at 02:44, Gregory Maxwell wrote: > As you note that the output costs still bound the resource > requirements. Resource cost is not just a measure of storage requirement; data that needs to be accessed during peak load induce more cost then data only used during base load or only rarely used. > 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). In Core, when a block comes the inputs are checked against the UTXO set (which grows with outputs) even if pre-synced, to verify order. Am I wrong there? This is not in the case in bitcrust; it is instead checked against the spend-tree (which grows with inputs). How "significant" this is, I neither know nor claim, but it is an interesting difference. > 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* " I think you are being a bit harsh here . I am also clearly explaining the difference only applies to peak load, and just making a suggestion. I simply want to stress the importance of protocol / implementation separation as even though you are correct UTXO data is always a resource cost for script validation (as I also state), the ratio of different costs are not necessarily *identical* across implementation. Note that the converse also holds: In bitcrust, if the last few blocks contain many inputs, the peak load verification for this block is slower. This is not the case in Core. Tomas