Billy Tetrud [ARCHIVE] on Nostr: 📅 Original date posted:2022-02-16 📝 Original message:@Jeremy > there are ...
📅 Original date posted:2022-02-16
📝 Original message:@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 at 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 at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220215/a6789db0/attachment.html>;
📝 Original message:@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 at 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 at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220215/a6789db0/attachment.html>;