The difference between sponsors and this issue is more subtle. The issue Suhas raised was with a variant of sponsors trying to address a second criticism, not sponsors itself, which is secure against this.
I think I can make this clear by defining a few different properties: Strong Reorgability: The transaction graph can be arbitrarily reorged into any series of blocks as long as dependency order/timelocks are respected. Simple Existential Reorgability: The transaction graph can be reorged into a different series of blocks, and it is not computationally difficult to find such an ordering. Epsilon-Strong Reorgability: The transaction graph can be arbitrarily reorged into any series of blocks as long as dependency order/timelocks are respected, up to Epsilon blocks. Epsilon: Simple Existential Reorgability: The transaction graph can be reorged into a different series of blocks, and it is not computationally difficult to find such an ordering, up to epsilon blocks. Perfect Reorgability: The transaction graph can be reorged into a different series of blocks, but the transactions themselves are already locked in. Perfect Reorgability doesn't exist in Bitcoin because unconfirmed transactions can be double spent which invalidates descendants. Notably, for a subset of the graph which is CTV Congestion control tree expansions, perfect reorg ability would exist, so it's not just a bullshit concept to think about :) The sponsors proposal is a change from Epsilon-Strong Reorgability to Epsilon-Weak Reorgability. It's not clear to me that there is any functional reason to rely on Strongness when Bitcoin's reorgability is already not Perfect, so a reorg generator with malicious intent can already disturb the tx graph. Epsion-Weak Reorgability seems to be a sufficient property. Do you disagree with that? Best, Jeremy -- @JeremyRubin <https://twitter.com/JeremyRubin> On Tue, Feb 15, 2022 at 12:25 PM Russell O'Connor via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > >> >> 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. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
