đź“… Original date posted:2017-04-08
đź“ť Original message:> On 8 Apr 2017, at 15:28, Tomas via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>
> 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
>
I don’t fully understand your storage engine. So the following deduction is just based on common sense.
a) It is possible to make unlimited number of 1-in-100-out txs
b) The maximum number of 100-in-1-out txs is limited by the number of previous 1-in-100-out txs
c) Since bitcrust performs not good with 100-in-1-out txs, for anti-DoS purpose you should limit the number of previous 1-in-100-out txs.
d) Limit 1-in-100-out txs == Limit UTXO growth
I’m not surprised that you find an model more efficient than Core. But I don’t believe one could find a model that doesn’t become more efficient with UTXO growth limitation.
Maybe you could try an experiment with regtest? Make a lot 1-in-100-out txs with many blocks, then spend all the UTXOs with 100-in-1-out txs. Compare the performance of bitcrust with core. Then repeat with 1-in-1-out chained txs (so the UTXO set is always almost empty)
One more question: what is the absolute minimum disk and memory usage in bitcrust, compared with the pruning mode in Core?
Johnson Lau [ARCHIVE] /
npub1fy…p2mv9
2023-06-07 17:59:41
in reply to nevent1q…xtrr
Author Public Key
npub1fyh6gqhg8zgyhhywkty047s64z2a7fjr307enrr3kqwtnk64plmsup2mv9Published at
2023-06-07 17:59:41Event JSON
{
"id": "7db4283f0efc6b868c5a604460ae1d23e64d943d5f3ef6c3b0a45af05a252749",
"pubkey": "492fa402e838904bdc8eb2c8fafa1aa895df26438bfd998c71b01cb9db550ff7",
"created_at": 1686160781,
"kind": 1,
"tags": [
[
"e",
"d4a682be1f6603f0ff8798c52b7225cac6554e21f3aedb0c80e7d41cf71983ad",
"",
"root"
],
[
"e",
"9f85620ef61093a1eed25cf9944c153ffe278e4f1191859d3f4ded28638d338e",
"",
"reply"
],
[
"p",
"1c03575343555d1132a621c49466190d680da4a306ba8b992e8b87e267609cdd"
]
],
"content": "📅 Original date posted:2017-04-08\n📝 Original message:\u003e On 8 Apr 2017, at 15:28, Tomas via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e \n\u003e \n\u003e I think you are being a bit harsh here . I am also clearly explaining\n\u003e the difference only applies to peak load, and just making a suggestion.\n\u003e I simply want to stress the importance of protocol / implementation\n\u003e separation as even though you are correct UTXO data is always a resource\n\u003e cost for script validation (as I also state), the ratio of different\n\u003e costs are not necessarily *identical* across implementation. \n\u003e \n\u003e Note that the converse also holds: In bitcrust, if the last few blocks\n\u003e contain many inputs, the peak load verification for this block is\n\u003e slower. This is not the case in Core.\n\u003e \n\u003e Tomas\n\u003e \n\nI don’t fully understand your storage engine. So the following deduction is just based on common sense.\n\na) It is possible to make unlimited number of 1-in-100-out txs\n\nb) The maximum number of 100-in-1-out txs is limited by the number of previous 1-in-100-out txs\n\nc) Since bitcrust performs not good with 100-in-1-out txs, for anti-DoS purpose you should limit the number of previous 1-in-100-out txs. \n\nd) Limit 1-in-100-out txs == Limit UTXO growth\n\nI’m not surprised that you find an model more efficient than Core. But I don’t believe one could find a model that doesn’t become more efficient with UTXO growth limitation.\n\nMaybe you could try an experiment with regtest? Make a lot 1-in-100-out txs with many blocks, then spend all the UTXOs with 100-in-1-out txs. Compare the performance of bitcrust with core. Then repeat with 1-in-1-out chained txs (so the UTXO set is always almost empty)\n\nOne more question: what is the absolute minimum disk and memory usage in bitcrust, compared with the pruning mode in Core?",
"sig": "c1db4529947e9f6bbb3482beb47618590d3458eb21443e4efe9da1c2c8bae42825cfb8ea6e133f853f1a0d7849956b54d94015f6856eb1981d4cb1e9fdc6c174"
}