Tomas [ARCHIVE] on Nostr: 📅 Original date posted:2017-04-08 📝 Original message:On Sun, Apr 9, 2017, at ...
📅 Original date posted:2017-04-08
📝 Original message:On Sun, Apr 9, 2017, at 00:12, Gregory Maxwell wrote:
> In Bitcoin Core the software _explicitly_ and intentionally does not
> exploit mempool pre-validation because doing that very easily leads to
> hard to detect consensus faults and makes all mempool code consensus
> critical when it otherwise is not. There have been bugs in the past
> which would have split the network if this optimization had been used.
>
> (in particular, I believe I recall one related to correctly removing
> coinbase spends from the mempool during reorganization that made them
> immature; and with the optimization and without the CNB post-test
> would have resulted in nodes that saw the reorg creating and accepting
> an invalid block, while nodes that didn't rejecting it; but because of
> prudent design it was largely harmless).
Although I don't quite follow the details (CNB post-test? Connect block
I assume?), the risks you are describing seem to be rather specific to
Core's implementation. For one, bitcrust does not or use need reorgs at
all.
Do you argue (or can you further explain) that the idea of splitting
script validation (or what you call mempool pre-validation), and order
validation is introducing risks inherent to the protocol?
Thanks,
Tomas
Published at
2023-06-07 17:59:42Event JSON
{
"id": "2056b90b6ffe94956fceacbea703c5eccb671fb1700b6d528337fdda649dfd31",
"pubkey": "1c03575343555d1132a621c49466190d680da4a306ba8b992e8b87e267609cdd",
"created_at": 1686160782,
"kind": 1,
"tags": [
[
"e",
"d4a682be1f6603f0ff8798c52b7225cac6554e21f3aedb0c80e7d41cf71983ad",
"",
"root"
],
[
"e",
"856a861f7ef65aebd7f1b2f35ae1d803619c50e7389cd9ecad15dbcd550cf1af",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2017-04-08\n📝 Original message:On Sun, Apr 9, 2017, at 00:12, Gregory Maxwell wrote:\n\u003e In Bitcoin Core the software _explicitly_ and intentionally does not\n\u003e exploit mempool pre-validation because doing that very easily leads to\n\u003e hard to detect consensus faults and makes all mempool code consensus\n\u003e critical when it otherwise is not. There have been bugs in the past\n\u003e which would have split the network if this optimization had been used.\n\u003e \n\u003e (in particular, I believe I recall one related to correctly removing\n\u003e coinbase spends from the mempool during reorganization that made them\n\u003e immature; and with the optimization and without the CNB post-test\n\u003e would have resulted in nodes that saw the reorg creating and accepting\n\u003e an invalid block, while nodes that didn't rejecting it; but because of\n\u003e prudent design it was largely harmless).\n\nAlthough I don't quite follow the details (CNB post-test? Connect block\nI assume?), the risks you are describing seem to be rather specific to\nCore's implementation. For one, bitcrust does not or use need reorgs at\nall.\n\nDo you argue (or can you further explain) that the idea of splitting\nscript validation (or what you call mempool pre-validation), and order\nvalidation is introducing risks inherent to the protocol? \n\nThanks,\nTomas",
"sig": "19ee4fe276cca80b86168e6c77e25834c76c310eac201ec04c41e7d8f1435b7452a1e87af4edff7f90c60d0318529556891eb6d7f738a7b4d8b1229ff353056a"
}