{"type":"rich","version":"1.0","author_name":"Tomas [ARCHIVE] (npub1rs…9evk4)","author_url":"https://nostr.ae/npub1rsp4w56r24w3zv4xy8zfgesep45qmf9rq6aghxfw3wr7yemqnnwsf9evk4","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-04-08\n📝 Original message:On Sat, Apr 8, 2017, at 02:44, Gregory Maxwell wrote:\n\u003e As you note that the output costs still bound the resource\n\u003e requirements. \n\nResource cost is not just a measure of storage requirement; data that\nneeds to be accessed during peak load induce more cost then data only\nused during base load or only rarely used.\n\n\u003e Latency related costs in Bitcoin Core also do not depend on the number\n\u003e of outputs in transactions in a block. When a transaction is handled\n\u003e it goes into an in-memory buffer and only gets flushed later if isn't\n\u003e spent before the buffer fills.  A block will take more time to\n\u003e validate with more inputs, same as you observer, but the aggregate\n\u003e resource usage for users depends significantly on outputs (so, in fact\n\u003e there is even further misaligned incentives than just the fact that\n\u003e small outputs have a outsized long term cost).\n\nIn Core, when a block comes the inputs are checked against the UTXO set\n(which grows with outputs)  even if pre-synced, to verify order. Am I\nwrong there? This is not in the case in bitcrust; it is instead checked\nagainst the spend-tree (which grows with inputs).\n\nHow \"significant\" this is, I neither know nor claim,  but it is an\ninteresting difference. \n\n\u003e Then I think you may want to retract the claim that \"As this solution,\n\u003e reversing the costs of outputs and inputs, [...] updates to the\n\u003e protocol addressing the UTXO growth, might not be worth considering\n\u003e *protocol improvements* \"\n\nI think you are being a bit harsh here . I am also clearly explaining\nthe difference only applies to peak load, and just making a suggestion.\nI simply want to stress the importance of protocol / implementation\nseparation as even though you are correct UTXO data is always a resource\ncost for script validation (as I also state), the ratio of different\ncosts are  not necessarily *identical* across implementation. \n\nNote that the converse also holds: In bitcrust, if the last few blocks\ncontain many inputs, the peak load verification for this block is\nslower. This is not the case in Core.\n\nTomas"}