Tomas [ARCHIVE] on Nostr: 📅 Original date posted:2017-04-06 📝 Original message:On Fri, Apr 7, 2017, at ...
📅 Original date posted:2017-04-06
📝 Original message:On Fri, Apr 7, 2017, at 02:32, Gregory Maxwell wrote:
> Perhaps a simple question would help:
>
> What is the minimal amount of space your system requires to take a new
> block received from the P2P network and verifying that all its spends
> were valid spends of existing coins unspent coins today?
>
> For Bitcoin Core the answer is ~2GB (plus the configuration handling
> currently forces you to keep another 550MB of blocks for reorgs).
Bitcrust separates script validation (base load, when transaction come
in) from order validation (peak load, when blocks come in).
For script validation it would obviously need the ~2GB (or I think
~1.5GB) of outputs needed to validate these. For order validation it
needs ~200mb or the spent-index (for bit-lookups) and I would guess
roughly ~500mb of the spent-tree (for scanning), though I don't think
the 5.7GB full spend tree isn't worth pruning anytime soon.
Then it is currently using a ~1.5GB index for transaction hash to
fileptr lookups, though this could be made more space efficient.
📝 Original message:On Fri, Apr 7, 2017, at 02:32, Gregory Maxwell wrote:
> Perhaps a simple question would help:
>
> What is the minimal amount of space your system requires to take a new
> block received from the P2P network and verifying that all its spends
> were valid spends of existing coins unspent coins today?
>
> For Bitcoin Core the answer is ~2GB (plus the configuration handling
> currently forces you to keep another 550MB of blocks for reorgs).
Bitcrust separates script validation (base load, when transaction come
in) from order validation (peak load, when blocks come in).
For script validation it would obviously need the ~2GB (or I think
~1.5GB) of outputs needed to validate these. For order validation it
needs ~200mb or the spent-index (for bit-lookups) and I would guess
roughly ~500mb of the spent-tree (for scanning), though I don't think
the 5.7GB full spend tree isn't worth pruning anytime soon.
Then it is currently using a ~1.5GB index for transaction hash to
fileptr lookups, though this could be made more space efficient.