📅 Original date posted:2017-04-07
📝 Original message:Expanding on this question a bit, it's optimized for parallel access, but
hard drive access isn't parallel and memory accesses are very fast, so
shouldn't the target of optimization be about cramming as much as possible
in memory and minimizing disk accesses?
On Fri, Apr 7, 2017 at 11:18 AM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Thu, Apr 6, 2017 at 10:12 PM, Tomas via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >As this
> > solution, reversing the costs of outputs and inputs, seems to have
> > excellent performance characteristics (as shown in the test results),
> > updates to the protocol addressing the UTXO growth, might not be worth
> > considering *protocol improvements*
>
> I'm still lost on this-- AFAICT your proposals long term resource
> requirements are directly proportional to the amount of unspent output
> data, which grows over time at some fraction of the total transaction
> volume (plus the rate of spending which is more or less a constant).
>
> Can you help out my understanding here?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170407/6a7fb499/attachment-0001.html>;
Bram Cohen [ARCHIVE] /
npub1ld…t8ur6
2023-06-07 17:59:39
in reply to nevent1q…wj67
Author Public Key
npub1ldcq03p2qe58u0xnlwa35wchjuhz49y6ueu5ghmtjetez9xstnvsmt8ur6Published at
2023-06-07 17:59:39Event JSON
{
"id": "b01ea59f8732e4df1a2161b0acbbf9ac59450914fcf3db2a5ea26357cc359da5",
"pubkey": "fb7007c42a06687e3cd3fbbb1a3b17972e2a949ae679445f6b96579114d05cd9",
"created_at": 1686160779,
"kind": 1,
"tags": [
[
"e",
"d4a682be1f6603f0ff8798c52b7225cac6554e21f3aedb0c80e7d41cf71983ad",
"",
"root"
],
[
"e",
"40b8da526eac94da1ca26cbbd4eea0e0ba53a3124d65b4c466d4b4ba00120c66",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2017-04-07\n📝 Original message:Expanding on this question a bit, it's optimized for parallel access, but\nhard drive access isn't parallel and memory accesses are very fast, so\nshouldn't the target of optimization be about cramming as much as possible\nin memory and minimizing disk accesses?\n\nOn Fri, Apr 7, 2017 at 11:18 AM, Gregory Maxwell via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Thu, Apr 6, 2017 at 10:12 PM, Tomas via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003eAs this\n\u003e \u003e solution, reversing the costs of outputs and inputs, seems to have\n\u003e \u003e excellent performance characteristics (as shown in the test results),\n\u003e \u003e updates to the protocol addressing the UTXO growth, might not be worth\n\u003e \u003e considering *protocol improvements*\n\u003e\n\u003e I'm still lost on this-- AFAICT your proposals long term resource\n\u003e requirements are directly proportional to the amount of unspent output\n\u003e data, which grows over time at some fraction of the total transaction\n\u003e volume (plus the rate of spending which is more or less a constant).\n\u003e\n\u003e Can you help out my understanding here?\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170407/6a7fb499/attachment-0001.html\u003e",
"sig": "fc43abb586904e14395df8e43ca97e6e7a16991893adb171dbb940e9c60378c95c40af338f9b387a110ab175627e0eb2325c956a2a96dacde9483a223f3947a8"
}