📅 Original date posted:2017-04-11
📝 Original message:On Tue, Apr 11, 2017, at 11:41, Eric Voskuil wrote:
> It's not the headers/tx-hashes of the blocks that I'm referring to, it
> is the confirmation and spend information relative to all txs and all
> outputs for each branch. This reverse navigation (i.e. utxo
> information) is essential, must be persistent and is branch-relative.
That is exactly what is stored in the spend-tree.
>> As a simpler example, if two miners both mine a block at
>> approximately the same time and send it to each other, then surely
>> they would want to continue mining on their own block. Otherwise
>> they would be throwing away their own reward.
> That's not your concurrent validation scenario. In the scenario you
> described, the person chooses the weaker block of two that require
> validation because it's better somehow, not because it's his own
> (which does not require validation).
> Consistency is reached, despite seeing things at different times,
> because people use the same rules. If the economy ran on arbitrary
> block preference consistency would be elusive.
No but my example shows that it is up to the miner to choose which tip
to work on. This is not using different rules, it is just optimizing its
income. This means that the economy *does* run on arbitrary "block
preference", even if it is not running on arbitrary rules.
If two blocks are competing, a miner could optimize its decision which
to mine on, not just on whether one of the blocks is his own, but also
on fees, or on excessive validation costs.
> I read this as encoding the height at which a fork historically
> activated. If you intend to track activation for each branch that will
> not be "height-based" it will be history based.
I understand "height-based" was not the right wording, as it is of
course branch-specific. Per tip ruleset metadata, must be matched with
per-transaction ruleset metadata.
Tomas
Tomas [ARCHIVE] /
npub1rs…9evk4
2023-06-07 17:59:37
in reply to nevent1q…9ypp
Author Public Key
npub1rsp4w56r24w3zv4xy8zfgesep45qmf9rq6aghxfw3wr7yemqnnwsf9evk4Published at
2023-06-07 17:59:37Event JSON
{
"id": "c7dc11a16b51fb66f25902432ea9c72f95d1cd23ca3a1b1484fbf0ce643c7077",
"pubkey": "1c03575343555d1132a621c49466190d680da4a306ba8b992e8b87e267609cdd",
"created_at": 1686160777,
"kind": 1,
"tags": [
[
"e",
"d4a682be1f6603f0ff8798c52b7225cac6554e21f3aedb0c80e7d41cf71983ad",
"",
"root"
],
[
"e",
"df9416f1ef4c86ff6daf5e2d529d92a7a02a6ebdadd6b2c7baf5093b857645e1",
"",
"reply"
],
[
"p",
"82205f272f995d9be742779a3c19a2ae08522ca14824c3a3b01525fb5459161e"
]
],
"content": "📅 Original date posted:2017-04-11\n📝 Original message:On Tue, Apr 11, 2017, at 11:41, Eric Voskuil wrote:\n\u003e It's not the headers/tx-hashes of the blocks that I'm referring to, it\n\u003e is the confirmation and spend information relative to all txs and all\n\u003e outputs for each branch. This reverse navigation (i.e. utxo\n\u003e information) is essential, must be persistent and is branch-relative.\n\nThat is exactly what is stored in the spend-tree. \n\n\u003e\u003e As a simpler example, if two miners both mine a block at\n\u003e\u003e approximately the same time and send it to each other, then surely\n\u003e\u003e they would want to continue mining on their own block. Otherwise\n\u003e\u003e they would be throwing away their own reward.\n\n\u003e That's not your concurrent validation scenario. In the scenario you\n\u003e described, the person chooses the weaker block of two that require\n\u003e validation because it's better somehow, not because it's his own\n\u003e (which does not require validation).\n\n\u003e Consistency is reached, despite seeing things at different times,\n\u003e because people use the same rules. If the economy ran on arbitrary\n\u003e block preference consistency would be elusive.\n\nNo but my example shows that it is up to the miner to choose which tip\nto work on. This is not using different rules, it is just optimizing its\nincome. This means that the economy *does* run on arbitrary \"block\npreference\", even if it is not running on arbitrary rules.\n\nIf two blocks are competing, a miner could optimize its decision which\nto mine on, not just on whether one of the blocks is his own, but also\non fees, or on excessive validation costs.\n\n\u003e I read this as encoding the height at which a fork historically\n\u003e activated. If you intend to track activation for each branch that will\n\u003e not be \"height-based\" it will be history based.\n\nI understand \"height-based\" was not the right wording, as it is of\ncourse branch-specific. Per tip ruleset metadata, must be matched with\nper-transaction ruleset metadata.\n\nTomas",
"sig": "af95295995cf2145c39b98704226390ee313b97c8e4a36d1f83893fcbf0ef3f19087639e607d2f43119d71c56592e52fd5ff95cce09a02961b15147c4c0506d3"
}