📅 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
Tomas [ARCHIVE] /
npub1rs…9evk4
2023-06-07 17:59:41
in reply to nevent1q…hjv5
Author Public Key
npub1rsp4w56r24w3zv4xy8zfgesep45qmf9rq6aghxfw3wr7yemqnnwsf9evk4Published at
2023-06-07 17:59:41Event JSON
{
"id": "9f85620ef61093a1eed25cf9944c153ffe278e4f1191859d3f4ded28638d338e",
"pubkey": "1c03575343555d1132a621c49466190d680da4a306ba8b992e8b87e267609cdd",
"created_at": 1686160781,
"kind": 1,
"tags": [
[
"e",
"d4a682be1f6603f0ff8798c52b7225cac6554e21f3aedb0c80e7d41cf71983ad",
"",
"root"
],
[
"e",
"2abd8ce4b5b093cd64fdf328bf3638148ac06d97834fa31533fd72e03f67bd41",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 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",
"sig": "f86aa761059a133bdc7499d49ffb18effe76d06b11b8e42af5db5105d34f8373d7ba48ed876792cbcda1bf99eb308a74125ea26c403a07873fb7fe85f18c93ec"
}