📅 Original date posted:2017-04-07
📝 Original message:Answering both,
On Fri, Apr 7, 2017 at 11:18 AM, Gregory Maxwell via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> 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?
>>
On Fri, Apr 7, 2017, at 20:39, Bram Cohen wrote:
> 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?
The long term *minimal disk storage* requirement, can obviously not be
less then all the unspent outputs. Minimal disk requirements is not
something bitcrust attempts to address.
The storage that is accessed during peak load (block validation with
pre-synced transactions), is minimized as this only needs the
transaction index (to lookup ptrs from hashes), the tip of the spend-
tree and the tip of the spend-index (together to check double
spents/spending non-existing outputs). These not only easily fit in
RAM, but are accessed in a cache efficient way. *These* only grow with
inputs as the spend tree contains one record per input referencing the
output being spent.
Script validation is also not something bitcrust *directly* addresses;
it uses libbitcoinconsensus for the actual validation and lookups to
outputs are mostly similar. They are kept fast by trusting the OS on MRU
caching of transaction-outputs; I don't think that for this part the
UTXO index has much drawbacks,. Bitcrust seems to have a small advantage
due to the awesomeness of Rayon's parallelization and the lock-free data
structures, but a disadvantage in that keeping all spent outputs
decreases spatial locality of reference. Script validation is not the
innovative part.
Tomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170407/f7db76c7/attachment.html>;
Tomas [ARCHIVE] /
npub1rs…9evk4
2023-06-07 17:59:40
in reply to nevent1q…76jg
Author Public Key
npub1rsp4w56r24w3zv4xy8zfgesep45qmf9rq6aghxfw3wr7yemqnnwsf9evk4Published at
2023-06-07 17:59:40Event JSON
{
"id": "f334bf920f7feea3c9e4a427ef5408ed9593494dacad85015697ff0d39292855",
"pubkey": "1c03575343555d1132a621c49466190d680da4a306ba8b992e8b87e267609cdd",
"created_at": 1686160780,
"kind": 1,
"tags": [
[
"e",
"d4a682be1f6603f0ff8798c52b7225cac6554e21f3aedb0c80e7d41cf71983ad",
"",
"root"
],
[
"e",
"465f2261b70e2a6aef2354fa0680b58ff5cccaf64fc088b4452d48e306d5bb8b",
"",
"reply"
],
[
"p",
"82205f272f995d9be742779a3c19a2ae08522ca14824c3a3b01525fb5459161e"
]
],
"content": "📅 Original date posted:2017-04-07\n📝 Original message:Answering both,\n\n\n\nOn Fri, Apr 7, 2017 at 11:18 AM, Gregory Maxwell via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e \n\n\u003e\u003e I'm still lost on this-- AFAICT your proposals long term resource\n\n\u003e\u003e requirements are directly proportional to the amount of\n\u003e\u003e unspent output\n\u003e\u003e data, which grows over time at some fraction of the total transaction\n\u003e\u003e volume (plus the rate of spending which is more or less a constant).\n\u003e\u003e \n\n\u003e\u003e Can you help out my understanding here?\n\n\u003e\u003e \n\n\n\nOn Fri, Apr 7, 2017, at 20:39, Bram Cohen wrote:\n\n\u003e Expanding on this question a bit, it's optimized for parallel access,\n\u003e but hard drive access isn't parallel and memory accesses are very\n\u003e fast, so shouldn't the target of optimization be about cramming as\n\u003e much as possible in memory and minimizing disk accesses?\n\n\nThe long term *minimal disk storage* requirement, can obviously not be\nless then all the unspent outputs. Minimal disk requirements is not\nsomething bitcrust attempts to address.\n\n\n The storage that is accessed during peak load (block validation with\n pre-synced transactions), is minimized as this only needs the\n transaction index (to lookup ptrs from hashes), the tip of the spend-\n tree and the tip of the spend-index (together to check double\n spents/spending non-existing outputs). These not only easily fit in\n RAM, but are accessed in a cache efficient way. *These* only grow with\n inputs as the spend tree contains one record per input referencing the\n output being spent.\n\n\nScript validation is also not something bitcrust *directly* addresses;\nit uses libbitcoinconsensus for the actual validation and lookups to\noutputs are mostly similar. They are kept fast by trusting the OS on MRU\ncaching of transaction-outputs; I don't think that for this part the\nUTXO index has much drawbacks,. Bitcrust seems to have a small advantage\ndue to the awesomeness of Rayon's parallelization and the lock-free data\nstructures, but a disadvantage in that keeping all spent outputs\ndecreases spatial locality of reference. Script validation is not the\ninnovative part.\n\n\nTomas\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170407/f7db76c7/attachment.html\u003e",
"sig": "3a2ca8f5bde4cc9e933de3886887c04e607a82b22270285e3a9c5f44a79cc882822aa7167cc6f56bb4317a91f43f1232eba790d286dd876b67876b1349ca3c69"
}