@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


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