📅 Original date posted:2022-02-15
📝 Original message:> >> 2. (from Suhas) "once a valid transaction is created, it should not
> become invalid later on unless the inputs are double-spent."
> > This doesn't seem like a huge concern to me
>
> I agree that this shouldn't be a concern. In fact, I've asked numerous
> people in numerous places what practical downside there is to transactions
> that become invalid, and I've heard basically radio silence other than one
> off hand remark by satoshi at the dawn of time which didn't seem to me to
> have good reasoning. I haven't seen any downside whatsoever of transactions
> that can become invalid for anyone waiting the standard 6 confirmations -
> the reorg risks only exists for people not waiting for standard
> finalization. So I don't think we should consider that aspect of a
> sponsorship transaction that can only be mined with the transaction it
> sponsors to be a problem unless a specific practical problem case can be
> identified. Even if a significant such case was identified, an easy
> solution would be to simply allow sponsorship transactions to be mined on
> or after the sponsored transaction is mined.
>
The downside is that in a 6 block reorg any transaction that is moved past
its expiration date becomes invalid and all its descendants become invalid
too.
The current consensus threshold for transactions to become invalid is a 100
block reorg, and I see no reason to change this threshold. I promise to
personally build a wallet that always creates transactions on the verge of
becoming invalid should anyone ever implement a feature that violates this
tx validity principle.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220215/12596d01/attachment.html>;
Russell O'Connor [ARCHIVE] /
npub1dw…8plrw
2023-06-07 23:04:19
in reply to nevent1q…460v
Author Public Key
npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrwPublished at
2023-06-07 23:04:19Event JSON
{
"id": "50c87327138c2e93f40463bb10583dc1db5d7715a4135ed8812ed4dfab6a8028",
"pubkey": "6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d",
"created_at": 1686179059,
"kind": 1,
"tags": [
[
"e",
"c703681c72b4e4669ca1bb5b15d757a9761db34f49baa03e75c29c4c1b65c0d1",
"",
"root"
],
[
"e",
"e03a9742059ae28decc982745905d9b5dd267b39f53f65ca0fa3d675bdcdc55c",
"",
"reply"
],
[
"p",
"3030ec2d70259fdd55ba8e063740c139c3daaa618f86e3fae34cebcb73c742ba"
]
],
"content": "📅 Original date posted:2022-02-15\n📝 Original message:\u003e \u003e\u003e 2. (from Suhas) \"once a valid transaction is created, it should not\n\u003e become invalid later on unless the inputs are double-spent.\"\n\u003e \u003e This doesn't seem like a huge concern to me\n\u003e\n\u003e I agree that this shouldn't be a concern. In fact, I've asked numerous\n\u003e people in numerous places what practical downside there is to transactions\n\u003e that become invalid, and I've heard basically radio silence other than one\n\u003e off hand remark by satoshi at the dawn of time which didn't seem to me to\n\u003e have good reasoning. I haven't seen any downside whatsoever of transactions\n\u003e that can become invalid for anyone waiting the standard 6 confirmations -\n\u003e the reorg risks only exists for people not waiting for standard\n\u003e finalization. So I don't think we should consider that aspect of a\n\u003e sponsorship transaction that can only be mined with the transaction it\n\u003e sponsors to be a problem unless a specific practical problem case can be\n\u003e identified. Even if a significant such case was identified, an easy\n\u003e solution would be to simply allow sponsorship transactions to be mined on\n\u003e or after the sponsored transaction is mined.\n\u003e\n\nThe downside is that in a 6 block reorg any transaction that is moved past\nits expiration date becomes invalid and all its descendants become invalid\ntoo.\n\nThe current consensus threshold for transactions to become invalid is a 100\nblock reorg, and I see no reason to change this threshold. I promise to\npersonally build a wallet that always creates transactions on the verge of\nbecoming invalid should anyone ever implement a feature that violates this\ntx validity principle.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220215/12596d01/attachment.html\u003e",
"sig": "6f03a59d1e039b40f1f4520ccff11e1f009e9b48d4d3593253242f3234870d23c88417bcf9ecd5965fdab1b1a7173e8f242283c28fd2a224d1c4d65706150a92"
}