{"type":"rich","version":"1.0","author_name":"npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3c","author_url":"https://nostr.ae/npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3c","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-04-11\n📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA256\n\nOn 04/11/2017 01:43 AM, Tomas wrote:\n\u003e Splitting transactions only happens *on storage* and is just a\n\u003e minor optimization compared to storing them in full.\n\nOk\n\n\u003e Sure, we can still call switching tips a \"reorg\". And it is indeed\n\u003e a trade off as orphan blocks are stored, but a block in the spend\n\u003e tree takes only ~12kb and contains the required state information.\n\u003e \nIt's not the headers/tx-hashes of the blocks that I'm referring to, it\nis the confirmation and spend information relative to all txs and all\noutputs for each branch. This reverse navigation (i.e. utxo\ninformation) is essential, must be persistent and is branch-relative.\n\n\u003e The blockchain is - by design - only eventually consistent across\n\u003e nodes. Even if nodes would use the same \"tip-selection\" rules, you\n\u003e cannot rely on all blocks being propagated and hence each\n\u003e transaction having the same number of confirmations across all\n\u003e nodes.\n\u003e \n\u003e As a simpler example, if two miners both mine a block at\n\u003e approximately the same time and send it to each other, then surely\n\u003e they would want to continue mining on their own block. Otherwise\n\u003e they would be throwing away their own reward.\n\nThat's not your concurrent validation scenario. In the scenario you\ndescribed, the person chooses the weaker block of two that require\nvalidation because it's better somehow, not because it's his own\n(which does not require validation).\n\n\u003e And yes, this can also happen over multiple blocks, but the chances\n\u003e of consistency are vastly increased with each confirmation.\n\nConsistency is reached, despite seeing things at different times,\nbecause people use the same rules. If the economy ran on arbitrary\nblock preference consistency would be elusive.\n\n\u003e I am not talking about rejecting blocks, I am only talking choosing\n\u003e on which tip to mine.\n\nThis line of reasoning has me a bit baffled. Yet as I said, it's not\nimportant to the question at hand. It is not likely to be optimal to\nvalidate concurrently even if you consider selection of a weaker block\nadvantageous.\n\n\u003e\u003e If you intend this to be useful it has to help build the chain,\n\u003e\u003e not just rely on hardwiring checkpoints once rule changes are\n\u003e\u003e presumed to be buried deeply enough to do so (as the result of\n\u003e\u003e other implementations ).\n\u003e\u003e \n\u003e\u003e I understand this approach, it was ours at one time. There is a \n\u003e\u003e significant difference, and your design is to some degree based\n\u003e\u003e on a failure to fully consider this. I encourage you to not\n\u003e\u003e assume any consensus-related detail is too small.\n\u003e \n\u003e I am not failing to consider this, and I don't consider this too\n\u003e small . But ensuring contextual transaction validity by \"validate\n\u003e =\u003e  valid with rules X,Y,Z\" and then checking the active rules\n\u003e (softfork activation) on order validation, will give logically the\n\u003e same results as \"validate with X,Y,Z =\u003e valid\". This is not\n\u003e \"hardwiring checkpoints\" at all.\n\nStoring the validation flags with each tx is exactly what libbitcoin\ndoes (otherwise pre-validation would be infeasible). But that was not\nthe full point. You said on this in response previously:\n\n\u003e\u003e\u003e ...height-based compliance as meta data of validation seems to\n\u003e\u003e\u003e be\nadequate and safe.\n\nI read this as encoding the height at which a fork historically\nactivated. If you intend to track activation for each branch that will\nnot be \"height-based\" it will be history based.\n\ne\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v2.0.22 (GNU/Linux)\n\niQEcBAEBCAAGBQJY7KTHAAoJEDzYwH8LXOFOI+QH/RzX++1TNLC9DEMWioE7SmMj\nyKOrP8WEkOnnrZdFKxVmwV9oZBekEvDABMnJmFiW5TMjsmPz7XwKAYzV0Y5L5oGU\nfZYo3IOPyr0dA9TcpP15gNziR6pFUBq/QTYB6BcbUvvlkJv6xjgIdedgDMEyREWU\nHm/JU5g7gQUQd6MIDWbQ9FbYjtPuNSRQi851YfIn5mDivT4HuidaqQYMd9t5yS2Z\nFuoQBI6L5GTJIqml1bTwJ0wsA7+ZseBEgMn1TT1ehy2v1FFJTojTpzIwG+m3eiXg\nTxN3U/+fNAj+sKBb8Hq+nb7DvgjvKHyHuyRryBju7yq5d5rsb6meXcoiOtAznP8=\n=fRXf\n-----END PGP SIGNATURE-----"}