@Jeremy > there are technical reasons for sponsors to not be monotone. Mostly that it requires the maintenance of an additional permanent TX-Index, making Bitcoin's state grow at a much worse rate
What do you mean by monotone in the context of sponsor transactions? And when you say tx-index, do you mean an index for looking up a transaction by its ID? Is that not already something nodes do? > The sponsors proposal is a change from Epsilon-Strong Reorgability to Epsilon-Weak Reorgability It doesn't look like you defined that term in your list. Did you mean what you listed as "Epsilon: Simple Existential Reorgability"? If so, I would say that should be sufficient. I'm not sure I would even distinguish between the "strong" and "simple" versions of these things, tho you could talk about things that make reorgs more or less computationally difficult on a spectrum. As long as the computational difficulty isn't significant for miners vs their other computational costs, the computation isn't really a problem. @Russell > The current consensus threshold for transactions to become invalid is a 100 block reorg What do you mean by this? The only 100 block period I'm aware of is the coinbase cooldown period. > 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. Could you explain how you would build a wallet like that with a sponsor transaction as described by Jeremy? What damage do you think such a wallet could do? As far as I can tell, such a wallet is very unlikely to do more damage to the network than it does to the user of that wallet. On Tue, Feb 15, 2022 at 3:39 PM Jeremy Rubin via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
