📅 Original date posted:2017-04-06
📝 Original message:On Fri, Apr 7, 2017, at 03:09, Gregory Maxwell wrote:
>
> How do you deal with validity rules changing based on block height?
I expected that one :). Just like the 100 blocks coinbase rule, changes
by softforks need to be added as metadata to the transaction-index, but
this is not yet in place.
As for the script validation itself using libbitcoinconsensus, this is a
bit hairy as this expects the rules to be known. Luckily, simply
gradually retrying using "lower" rules won't hurt performance, as
transaction that mismatch newer rules are rare.
Generally, bitcrust would appreciate a "is valid with X rules" instead
of a "validate with X rules" approach.
> So it sounds like to work the software still needs an analog of a
> (U)TXO database? I am confused by the earlier comments about thinking
> the the resource consumption of the (U)TXO database is not a
> consideration in your design.
No, but transactional access is. Bitcrust just uses a
*transaction-index*, where outputs can be looked up regardless of being
spent. As the concept of being "spent" depends on the branch, script
validation ignores this and simply looks up the outputs.
Transactions are split in two parts for better locality of reference
when accessing outputs.
The transaction index only looks similar to an "UTXO-index" after full
pruning.
> If you get a transaction claiming to spend 0xDEADBEEFDEADBEEF, an
> output that never existed how does your spent index reject this spend
The spend-tree is scanned until either DEADBEAF is found (=ERR double
spent), the transaction of DEADBEEF is found (=all ok!), or the start
of the chain is reached (=ERR spending unknown output!)
To prevent actually having to scan to genesis, the spent-index "catches"
the search after a few blocks and performs the same lookup (positive for
tx, negative for output) on a simple bit index.
Tomas [ARCHIVE] /
npub1rs…9evk4
2023-06-07 17:59:43
in reply to nevent1q…vpk2
Author Public Key
npub1rsp4w56r24w3zv4xy8zfgesep45qmf9rq6aghxfw3wr7yemqnnwsf9evk4Published at
2023-06-07 17:59:43Event JSON
{
"id": "d801c7c352d8b1aebf855711cd33eb906fcf9ce87ac05626c938200cb0b08300",
"pubkey": "1c03575343555d1132a621c49466190d680da4a306ba8b992e8b87e267609cdd",
"created_at": 1686160783,
"kind": 1,
"tags": [
[
"e",
"d4a682be1f6603f0ff8798c52b7225cac6554e21f3aedb0c80e7d41cf71983ad",
"",
"root"
],
[
"e",
"ee3ebb2f7f12052a1c44bc75e56a46c31b43ee2bed7b3af502ad6cdf1da8386b",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2017-04-06\n📝 Original message:On Fri, Apr 7, 2017, at 03:09, Gregory Maxwell wrote:\n\u003e \n\u003e How do you deal with validity rules changing based on block height?\n\nI expected that one :). Just like the 100 blocks coinbase rule, changes\nby softforks need to be added as metadata to the transaction-index, but\nthis is not yet in place.\n\nAs for the script validation itself using libbitcoinconsensus, this is a\nbit hairy as this expects the rules to be known. Luckily, simply\ngradually retrying using \"lower\" rules won't hurt performance, as\ntransaction that mismatch newer rules are rare.\n\nGenerally, bitcrust would appreciate a \"is valid with X rules\" instead \nof a \"validate with X rules\" approach.\n\n\n\u003e So it sounds like to work the software still needs an analog of a\n\u003e (U)TXO database? I am confused by the earlier comments about thinking\n\u003e the the resource consumption of the (U)TXO database is not a\n\u003e consideration in your design.\n\nNo, but transactional access is. Bitcrust just uses a\n*transaction-index*, where outputs can be looked up regardless of being\nspent. As the concept of being \"spent\" depends on the branch, script\nvalidation ignores this and simply looks up the outputs.\n\nTransactions are split in two parts for better locality of reference\nwhen accessing outputs.\n\nThe transaction index only looks similar to an \"UTXO-index\" after full\npruning.\n\n\u003e If you get a transaction claiming to spend 0xDEADBEEFDEADBEEF, an\n\u003e output that never existed how does your spent index reject this spend\n\nThe spend-tree is scanned until either DEADBEAF is found (=ERR double\nspent), the transaction of DEADBEEF is found (=all ok!), or the start\nof the chain is reached (=ERR spending unknown output!)\n\nTo prevent actually having to scan to genesis, the spent-index \"catches\"\nthe search after a few blocks and performs the same lookup (positive for\ntx, negative for output) on a simple bit index.",
"sig": "f9cb6aa4a6b7615b3749c4e5fce80677af97c3be668bb0c83649671c7413c8cac62713a9f1675fe4da1fbc8df66f1c79a91cc270ea9ccacaf4b524da1c37a3a3"
}