📅 Original date posted:2014-08-01
📝 Original message:On Thursday, 31 July 2014, at 7:28 pm, Gregory Maxwell wrote:
> On Thu, Jul 31, 2014 at 6:38 PM, Matt Whitlock <bip at mattwhitlock.name> wrote:
> > It would make more sense to introduce a new script opcode that pushes the current block height onto the operand stack. Then you could implement arbitrary logic about which blocks the transaction can be valid in. This would require that the client revalidate all transactions in its mempool (really, only those making use of this opcode) whenever the chain tip changes.
>
> Transactions that become invalid later are have pretty severe
> consequences because they might mean that completely in an absence of
> fraud transactions are forever precluded due to a otherwise harmless
> reorg.
I understand what you're saying, but I don't understand why it's a problem. Transactions shouldn't be considered "final" until a reasonable number of confirmations anyway, so the possibility that an "accepted" transaction could become invalid due to a chain reorganization is not a new danger. Ordinary transactions can similarly become invalid due to chain reorganizations, due to inputs already having been spent in the new branch.
Matt Whitlock [ARCHIVE] /
npub17q…upwet
2023-06-07 15:24:40
in reply to nevent1q…vrd6
Author Public Key
npub17qxssk9sj2r7jswvh3y32e7vwz7mcckhz33gk9nurdmw0lhsfkgswupwetSeen on
wss://relay.nostr.bandPublished at
2023-06-07 15:24:40Event JSON
{
"id": "109de5f3c709001124afd690ec5cca85a2087cf2d0998bb071d31ca6d33b26ab",
"pubkey": "f00d0858b09287e941ccbc491567cc70bdbc62d714628b167c1b76e7fef04d91",
"created_at": 1686151480,
"kind": 1,
"tags": [
[
"e",
"862ea3dc96b72bff70fc377e79d0d6efd56d14bf0babb9aa995ab55fc1b92d18",
"",
"root"
],
[
"e",
"0fddb0c3f086415ec6c505a8b67d36be57bf9853f29d80e58534264a8c1fcd18",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2014-08-01\n📝 Original message:On Thursday, 31 July 2014, at 7:28 pm, Gregory Maxwell wrote:\n\u003e On Thu, Jul 31, 2014 at 6:38 PM, Matt Whitlock \u003cbip at mattwhitlock.name\u003e wrote:\n\u003e \u003e It would make more sense to introduce a new script opcode that pushes the current block height onto the operand stack. Then you could implement arbitrary logic about which blocks the transaction can be valid in. This would require that the client revalidate all transactions in its mempool (really, only those making use of this opcode) whenever the chain tip changes.\n\u003e \n\u003e Transactions that become invalid later are have pretty severe\n\u003e consequences because they might mean that completely in an absence of\n\u003e fraud transactions are forever precluded due to a otherwise harmless\n\u003e reorg.\n\nI understand what you're saying, but I don't understand why it's a problem. Transactions shouldn't be considered \"final\" until a reasonable number of confirmations anyway, so the possibility that an \"accepted\" transaction could become invalid due to a chain reorganization is not a new danger. Ordinary transactions can similarly become invalid due to chain reorganizations, due to inputs already having been spent in the new branch.",
"sig": "78e9f3f990d870d0ddaac9ecf1813e5a1c77c83eef68287456394462189259bcebd2c3143a480b041aceef0f8c2250f4c9d4688e96e43055f2be9db40485a840"
}