Billy Tetrud [ARCHIVE] on Nostr: 📅 Original date posted:2021-06-11 📝 Original message:> one can design a wallet ...
📅 Original date posted:2021-06-11
📝 Original message:> one can design a wallet to passively take advantage of reorgs
It does sound like this is the central issue. I can certainly see that it's
materially different than current double spending ability. Double spending
via reorgs today requires either active participation and above-average
connection to miners or luck.
The easiest method of double spending I can think of is the following.
Consider if a user broadcasts an RBF transaction as soon as the original
transaction is mined. I assume the transaction won't propagate through the
network because any node that has received the newest block will see it as
an invalid transaction, is that right? Is there no significant possibility
that enough of the network hasn't seen the block yet to transmit the RBF
transaction widely enough to get incorporated into a reorg? This would
certainly be something wallets could do automatically. It certainly does
seem like at very least this would have a much lower success rate than your
auto-double-spend wallet.
In any case, what if we apply the same logic to non-monotonic transactions?
What if we program nodes to reject such transactions that are too close to
the borderline? For example, if nodes rejected transactions that could
expire within 100 blocks, it would be much less likely for this kind of
thing to be done at point of sale, and there would be a much higher chance
that whatever recipient that's willing to wait 100 blocks would be willing
to wait 6 blocks more to be sure no reorg happens. It would also be a lot
more likely that the transaction is confirmed well before it might expire.
Not a perfect solution, to be sure. But it could substantially limit the
cases and likelihoods that passive double-spend attempts would succeed. But
miners could still get and include transactions in blocks regardless of
this, and they have an incentive to (to maximize the fees they collect). It
at least seems plausible that those incentives would undermine this
solution.
But it seems like all this is only a problem for people who are considering
1 confirmation to be effectively finalized. Users and programmatic systems
alike simply wait for some condition to be true to recognize payment as
having completed. Systems could simply be programmed so the condition is at
least 6 confirmations for any non-monotonic transaction, or all
transactions. 6 confirmations is the accepted standard of finalization,
isn't it? Users looking at their software should be able to see that a
confirmation has happened but that this isn't enough to be considered
finalized. As long as this is standard, no problem should really exist,
right? Except within incorrectly written software or people taking it upon
themselves to define finalization on their own. People who accept 0-conf
transactions are similarly using a non-standard definition of finalization
and are putting themselves at even greater risk for double spends. How
would this be any different?
> there is little point in addressing these lesser concerns if the main
concern is outstanding
I agree, it makes the most sense to discuss the above points rather than
getting into the weeds about more minor issues.
On Thu, Jun 10, 2021 at 4:20 PM Russell O'Connor <roconnor at blockstream.com>
wrote:
> As it stands today, in order to double spend a transaction during a reorg,
> one must take an active role of recognizing that a reorg has happened, hope
> that the new branch has completely omitted your spending transaction, and
> then quickly broadcast a replacement transaction with a higher fee to
> outbid your previous transaction.
>
> However with, pretty much any change to Bitcoin that leads to
> non-monotonic validity rules, that is any rule where transactions that are
> valid at one tip, can become invalid at a latter tip through some other
> means than their inputs being spent, such as OP_BBV, one can design a
> wallet to passively take advantage of reorgs by always spending through an
> OP_BBV that is on the verge of becoming invalid. Then you just have to sit
> back and wait for a suitable reorg to take back your UTXO for you without
> any work. I would probably attempt to build such a wallet for myself
> should any OP_BBV-like proposal be implemented. Think of it as an
> auto-double spend wallet.
>
> Some people hold the opinion that there is no meaningful distinction
> between the active and passive roles in these two scenarios. I'm not
> convinced. I see a material difference between needing to actively
> broadcast a replacement transaction and passively waiting for your
> transaction to fall out of validity. I also see a material difference
> between needing the transaction to be completely omitted from the reorging
> chain versus just having the transaction fail a height qualification in the
> reorging chain.
>
> (There are a few other lesser problems with an OP_BBV proposal, including
> the fact that Bitcoin software tends to cache script validity so you'd want
> to use the taproot annex instead of pure script; and a possible issue that
> the proposal defeats limits on transaction replacement because now instead
> of meeting minimum thresholds for fee bumping you can just let the previous
> transaction expire and bump the fee by a fraction (though you are
> effectively rate limited so maybe that is considered sufficiently
> mitigated?). But there is little point in addressing these lesser concerns
> if the main concern is outstanding.)
>
> On Thu, Jun 10, 2021 at 6:20 PM Billy Tetrud <billy.tetrud at gmail.com>
> wrote:
>
>> @Russell In that thread, you quoted Satoshi there, but neither he nor you
>> really deeply explained the concern. Would you mind elaborating on a
>> situation that calls for concern here? Some deeper explanation of the
>> "reorg safety" property would also be helpful. I'd very much like to know
>> what your thoughts are on the specific points I brought up in the BIP as
>> well.
>>
>> On Thu, Jun 10, 2021 at 11:35 AM Russell O'Connor <
>> roconnor at blockstream.com> wrote:
>>
>>> This is a continuation of the thread at
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018760.html
>>> on this topic.
>>>
>>> I still remain unconvinced that we ought to give up on the "reorg
>>> safety" property that is explicitly part of Bitcoin's design.
>>>
>>> On Thu, Jun 10, 2021 at 1:56 PM Billy Tetrud via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> Hi Everyone,
>>>>
>>>> I'd like to open a discussion of an opcode I call OP_BEFOREBLOCKVERIFY
>>>> (OP_BBV) which is similar to ones that have been discussed before (eg
>>>> OP_BLOCKNUMBER). The opcode is very simple: the it takes as a
>>>> parameter a number representing a block height, and marks the transaction
>>>> invalid if the current block the transaction is being evaluated for is
>>>> greater than or equal to that block height, the transaction is invalid. I
>>>> wrote up a bip for OP_BBV here
>>>> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md>;
>>>> .
>>>>
>>>> The motivation for this opcode is primarily to do switch-off kinds of
>>>> transactions. Eg, an output that contains both a spend path that uses
>>>> OP_BBV and a spend path that uses OP_CHECKSEQUENCEVERIFY so that before a
>>>> particular block one person can spend, and after that block a different
>>>> person can spend. This can allow doing things like expiring payments or
>>>> reversible payments in a cheaper way. Currently, things like that require a
>>>> sequence of multiple transactions, however OP_BBV can do it in a single
>>>> transaction, making these applications a lot more economically feasible.
>>>>
>>>> The particular application I'm most interested in is more efficient
>>>> wallet vaults. However, wallet vaults requires other new opcodes, and I've
>>>> been given the (good, I think) advice to start off this discussion with
>>>> something a bit more bite sized and manageable. So I want to keep this
>>>> discussion to OP_BBV and steer away from the specifics of the wallet vaults
>>>> I'm thinking of (which are more involved, requiring other new opcodes that
>>>> I think makes more sense to discuss in a different thread).
>>>>
>>>> The main thing I'd like to discuss is the historical avoidance of and
>>>> stigma toward opcodes that can cause a valid transaction to become invalid.
>>>>
>>>> It seems there are two concerns:
>>>>
>>>> 1. that an opcode like might create a DOS vector where a malicious
>>>> actor might be able to spam the mempool with transactions containing this
>>>> opcode.
>>>> 2. that an opcode like this could cause "bad" reorg behavior, where in
>>>> a reorg, transactions that were spent become not spend and not spendable
>>>> because they were mined too near their expiry point.
>>>>
>>>> While I don't want to claim anything about opcodes that can cause spend
>>>> paths to expire in general, I do want to claim that *some* opcodes like
>>>> that are safe - in particular OP_BBV. In the context of OP_BBV
>>>> specifically, it seems to me like item 1 (mempool handling) is a solvable
>>>> problem and that point 2 (reorg issues) is not really a problem since
>>>> people should generally be waiting for 6 confirmations and software can
>>>> warn the user to wait for 6 confirmations in relevant scenarios where a
>>>> 6-block reorg might reverse the transaction. I discuss this in detail in
>>>> the Design Tradeoffs and Risks
>>>> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md#transaction-expiry>; section
>>>> of the document I wrote for OP_BBV. I'd love to hear thoughts from others
>>>> on here about these things and especially the discussion of these issues in
>>>> the document I linked to.
>>>>
>>>> Thanks,
>>>> BT
>>>>
>>>> _______________________________________________
>>>> 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/20210610/46ce195a/attachment.html>;
📝 Original message:> one can design a wallet to passively take advantage of reorgs
It does sound like this is the central issue. I can certainly see that it's
materially different than current double spending ability. Double spending
via reorgs today requires either active participation and above-average
connection to miners or luck.
The easiest method of double spending I can think of is the following.
Consider if a user broadcasts an RBF transaction as soon as the original
transaction is mined. I assume the transaction won't propagate through the
network because any node that has received the newest block will see it as
an invalid transaction, is that right? Is there no significant possibility
that enough of the network hasn't seen the block yet to transmit the RBF
transaction widely enough to get incorporated into a reorg? This would
certainly be something wallets could do automatically. It certainly does
seem like at very least this would have a much lower success rate than your
auto-double-spend wallet.
In any case, what if we apply the same logic to non-monotonic transactions?
What if we program nodes to reject such transactions that are too close to
the borderline? For example, if nodes rejected transactions that could
expire within 100 blocks, it would be much less likely for this kind of
thing to be done at point of sale, and there would be a much higher chance
that whatever recipient that's willing to wait 100 blocks would be willing
to wait 6 blocks more to be sure no reorg happens. It would also be a lot
more likely that the transaction is confirmed well before it might expire.
Not a perfect solution, to be sure. But it could substantially limit the
cases and likelihoods that passive double-spend attempts would succeed. But
miners could still get and include transactions in blocks regardless of
this, and they have an incentive to (to maximize the fees they collect). It
at least seems plausible that those incentives would undermine this
solution.
But it seems like all this is only a problem for people who are considering
1 confirmation to be effectively finalized. Users and programmatic systems
alike simply wait for some condition to be true to recognize payment as
having completed. Systems could simply be programmed so the condition is at
least 6 confirmations for any non-monotonic transaction, or all
transactions. 6 confirmations is the accepted standard of finalization,
isn't it? Users looking at their software should be able to see that a
confirmation has happened but that this isn't enough to be considered
finalized. As long as this is standard, no problem should really exist,
right? Except within incorrectly written software or people taking it upon
themselves to define finalization on their own. People who accept 0-conf
transactions are similarly using a non-standard definition of finalization
and are putting themselves at even greater risk for double spends. How
would this be any different?
> there is little point in addressing these lesser concerns if the main
concern is outstanding
I agree, it makes the most sense to discuss the above points rather than
getting into the weeds about more minor issues.
On Thu, Jun 10, 2021 at 4:20 PM Russell O'Connor <roconnor at blockstream.com>
wrote:
> As it stands today, in order to double spend a transaction during a reorg,
> one must take an active role of recognizing that a reorg has happened, hope
> that the new branch has completely omitted your spending transaction, and
> then quickly broadcast a replacement transaction with a higher fee to
> outbid your previous transaction.
>
> However with, pretty much any change to Bitcoin that leads to
> non-monotonic validity rules, that is any rule where transactions that are
> valid at one tip, can become invalid at a latter tip through some other
> means than their inputs being spent, such as OP_BBV, one can design a
> wallet to passively take advantage of reorgs by always spending through an
> OP_BBV that is on the verge of becoming invalid. Then you just have to sit
> back and wait for a suitable reorg to take back your UTXO for you without
> any work. I would probably attempt to build such a wallet for myself
> should any OP_BBV-like proposal be implemented. Think of it as an
> auto-double spend wallet.
>
> Some people hold the opinion that there is no meaningful distinction
> between the active and passive roles in these two scenarios. I'm not
> convinced. I see a material difference between needing to actively
> broadcast a replacement transaction and passively waiting for your
> transaction to fall out of validity. I also see a material difference
> between needing the transaction to be completely omitted from the reorging
> chain versus just having the transaction fail a height qualification in the
> reorging chain.
>
> (There are a few other lesser problems with an OP_BBV proposal, including
> the fact that Bitcoin software tends to cache script validity so you'd want
> to use the taproot annex instead of pure script; and a possible issue that
> the proposal defeats limits on transaction replacement because now instead
> of meeting minimum thresholds for fee bumping you can just let the previous
> transaction expire and bump the fee by a fraction (though you are
> effectively rate limited so maybe that is considered sufficiently
> mitigated?). But there is little point in addressing these lesser concerns
> if the main concern is outstanding.)
>
> On Thu, Jun 10, 2021 at 6:20 PM Billy Tetrud <billy.tetrud at gmail.com>
> wrote:
>
>> @Russell In that thread, you quoted Satoshi there, but neither he nor you
>> really deeply explained the concern. Would you mind elaborating on a
>> situation that calls for concern here? Some deeper explanation of the
>> "reorg safety" property would also be helpful. I'd very much like to know
>> what your thoughts are on the specific points I brought up in the BIP as
>> well.
>>
>> On Thu, Jun 10, 2021 at 11:35 AM Russell O'Connor <
>> roconnor at blockstream.com> wrote:
>>
>>> This is a continuation of the thread at
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018760.html
>>> on this topic.
>>>
>>> I still remain unconvinced that we ought to give up on the "reorg
>>> safety" property that is explicitly part of Bitcoin's design.
>>>
>>> On Thu, Jun 10, 2021 at 1:56 PM Billy Tetrud via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> Hi Everyone,
>>>>
>>>> I'd like to open a discussion of an opcode I call OP_BEFOREBLOCKVERIFY
>>>> (OP_BBV) which is similar to ones that have been discussed before (eg
>>>> OP_BLOCKNUMBER). The opcode is very simple: the it takes as a
>>>> parameter a number representing a block height, and marks the transaction
>>>> invalid if the current block the transaction is being evaluated for is
>>>> greater than or equal to that block height, the transaction is invalid. I
>>>> wrote up a bip for OP_BBV here
>>>> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md>;
>>>> .
>>>>
>>>> The motivation for this opcode is primarily to do switch-off kinds of
>>>> transactions. Eg, an output that contains both a spend path that uses
>>>> OP_BBV and a spend path that uses OP_CHECKSEQUENCEVERIFY so that before a
>>>> particular block one person can spend, and after that block a different
>>>> person can spend. This can allow doing things like expiring payments or
>>>> reversible payments in a cheaper way. Currently, things like that require a
>>>> sequence of multiple transactions, however OP_BBV can do it in a single
>>>> transaction, making these applications a lot more economically feasible.
>>>>
>>>> The particular application I'm most interested in is more efficient
>>>> wallet vaults. However, wallet vaults requires other new opcodes, and I've
>>>> been given the (good, I think) advice to start off this discussion with
>>>> something a bit more bite sized and manageable. So I want to keep this
>>>> discussion to OP_BBV and steer away from the specifics of the wallet vaults
>>>> I'm thinking of (which are more involved, requiring other new opcodes that
>>>> I think makes more sense to discuss in a different thread).
>>>>
>>>> The main thing I'd like to discuss is the historical avoidance of and
>>>> stigma toward opcodes that can cause a valid transaction to become invalid.
>>>>
>>>> It seems there are two concerns:
>>>>
>>>> 1. that an opcode like might create a DOS vector where a malicious
>>>> actor might be able to spam the mempool with transactions containing this
>>>> opcode.
>>>> 2. that an opcode like this could cause "bad" reorg behavior, where in
>>>> a reorg, transactions that were spent become not spend and not spendable
>>>> because they were mined too near their expiry point.
>>>>
>>>> While I don't want to claim anything about opcodes that can cause spend
>>>> paths to expire in general, I do want to claim that *some* opcodes like
>>>> that are safe - in particular OP_BBV. In the context of OP_BBV
>>>> specifically, it seems to me like item 1 (mempool handling) is a solvable
>>>> problem and that point 2 (reorg issues) is not really a problem since
>>>> people should generally be waiting for 6 confirmations and software can
>>>> warn the user to wait for 6 confirmations in relevant scenarios where a
>>>> 6-block reorg might reverse the transaction. I discuss this in detail in
>>>> the Design Tradeoffs and Risks
>>>> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md#transaction-expiry>; section
>>>> of the document I wrote for OP_BBV. I'd love to hear thoughts from others
>>>> on here about these things and especially the discussion of these issues in
>>>> the document I linked to.
>>>>
>>>> Thanks,
>>>> BT
>>>>
>>>> _______________________________________________
>>>> 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/20210610/46ce195a/attachment.html>;