Re: [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that invalidates a spend path after a certain block
On Fri, Jun 11, 2021 at 7:12 AM James MacWhyte wrote: > @Billy I like the idea. It is very obvious how useful an opcode like this > would be! (My background is in wallet implementation) > > @Russell I do understand your concerns of monotonism, however I'm having a > hard time really coming up with an attack vector. You said "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." Unless I'm mistaken, > this means you would need to send yourself a fresh transaction using OP_BBV > set to, say, 2 blocks in the future, then immediately spend that output in > a new payment to someone else and hope a reorg happens. Does this mean the > theoretical double-spend wallet you are proposing would have to send two > transactions every time you make a single payment, doubling the transaction > fees and adding more uncertainty around when the second transaction would > get confirmed? > Assuming the proposal is rewritten to place the maxheight into the taproot annex in order to address the issue with caching of script validity, then this auto-double-spend wallet would send every payment with an annex value that limits the payment to being valid only up to the next block. If the payment doesn't make it into the next block, then resign it with the annex incremented to the next block, and repeat. > In a normal double spend scenario, there is no cost to a failed attempt, > but much to gain from a success. With your design, there is a real cost to > every single attempt (transaction fees) and no evidence that the rate of > success would be higher (you still have to bet on the reorg not including > your transaction in the first few blocks). It sounds like this new system > would actually be less attractive to double spenders than the current model! > > I also agree with Billy's idea for relay rules. We already have abusable > chain rules (e.g. a tx can be included in a block with 0 transaction fee > [spam?]) but we add protection with relay rules (e.g. minimum fee to > relay). I don't see how this would be any different, if the chain rules > only enforced the block height for confirmation and the relay rules forced > a minimum OP_BBV value in order to protect against reorg double spends. > The inclusion of a tx with 0 transaction fee in a block is not in of itself an abuse. There is nothing wrong with blocks containing such transactions. The *relay* of 0 transaction fee transactions is what is an abuse because it allows one to usurp Bitcoin's gossip network for their own arbitrary communications platform without cost. Most Bitcoin users aren't signing up for being a usenet provider. So, by policy, nodes require a cost to relay transactions so that broadcasting isn't free. Even when that price is paid to someone else, it still is an effective limitation on abuse. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that invalidates a spend path after a certain block
@Billy I like the idea. It is very obvious how useful an opcode like this would be! (My background is in wallet implementation) @Russell I do understand your concerns of monotonism, however I'm having a hard time really coming up with an attack vector. You said "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." Unless I'm mistaken, this means you would need to send yourself a fresh transaction using OP_BBV set to, say, 2 blocks in the future, then immediately spend that output in a new payment to someone else and hope a reorg happens. Does this mean the theoretical double-spend wallet you are proposing would have to send two transactions every time you make a single payment, doubling the transaction fees and adding more uncertainty around when the second transaction would get confirmed? In a normal double spend scenario, there is no cost to a failed attempt, but much to gain from a success. With your design, there is a real cost to every single attempt (transaction fees) and no evidence that the rate of success would be higher (you still have to bet on the reorg not including your transaction in the first few blocks). It sounds like this new system would actually be less attractive to double spenders than the current model! I also agree with Billy's idea for relay rules. We already have abusable chain rules (e.g. a tx can be included in a block with 0 transaction fee [spam?]) but we add protection with relay rules (e.g. minimum fee to relay). I don't see how this would be any different, if the chain rules only enforced the block height for confirmation and the relay rules forced a minimum OP_BBV value in order to protect against reorg double spends. James On Fri, Jun 11, 2021 at 11:00 AM Billy Tetrud via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > 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
Re: [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that invalidates a spend path after a certain block
> 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 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
Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent
> Note, I think that the tx mutation proposal relies on interactivity in the > worst-case scenario where a counterparty wants to increase its fee-bumping > output from the contract balance. This interactivity may lure a counterparty > to alway lock the worst-case fee-bumping reserve in the output. I believe > anchor output enables more "real-time" fee-bumping reserve adjustment ? Anchor outputs / malleability allow for real-time adjustment of long-lived contracts (for which the today worst case is much larger than the worst case estimated at the contract creation time). However it's a really interested for vaults, as you have multiple parties with the same goal (getting this Cancel transaction confirmed). Therefore you have this slight "tragedy of the commons" of whose fee-bumping wallet is going to pay for sponsoring the next Cancel (and it's exacerbated by / for external redundancy providers). With this approach, fees are taxed from the shared coins, so there is no pernicious incentive to delay the broadcast of your revocation transaction in the hope that another watchtower will pay the fee instead of you. I think this applies to multi-party channels too, by having some kind of a shared budget. You would also have a large UX improvement with regard to the fee-bumping wallet: no need to have one (fb wallet refills are really *really* poor UX) one and maintain a nice laid-out UTXO pool. In the end, both approaches seem desirable: the output for paying most of the fees from shared coins, therefore dwarfing the "tragedy of the common" concerns, and the malleability to still be able to dynamically allocate more funds to feebump in case of a black swan event (but essentially needs a single refill at startup as it's never spent from). As a side note, this can "just" be implemented by exchanging N (varying depending on the granularity) signatures with increasing feerates. Again, this might be reasonable in some usecases but not others (eg if you are already generating tons of sigs, or have longer chain of unconfirmed transactions). > Cheers, > Antoine > > [0] Incautious sighash alleability is unsafe. Be careful, otherwise kitties > will perish by the thousands : > https://github.com/revault/practical-revault/pull/83 > > Le dim. 6 juin 2021 à 22:28, Lloyd Fournier a écrit : > >> Hi Antione, >> >> Thanks for bringing up this important topic. I think there might be another >> class of solutions over input based, CPFP and sponsorship. I'll call them tx >> mutation schemes. The idea is that you can set a key that can increase the >> fee by lowering a particular output after the tx is signed without >> invalidating the signature. The premise is that anytime you need to bump the >> fee of a transaction you must necessarily have funds in an output that are >> going to you and therefore you can sacrifice some of them to increase the >> fee. This is obviously destructive to txids so child presigned transactions >> will have to use ANYPREVOUT as in your proposal. The advantage is that it >> does not require keeping extra inputs around to bump the fee. >> >> So imagine a new opcode OP_CHECKSIG_MUTATED >> . >> This would check that is valid against if the >> current transaction had the output at reduced by . To >> make this more efficient, if the public key is one byte: 0x02 it references >> the taproot *external key* (similar to how ANYPREVOUT uses 0x01 to refer to >> internal key[1]). >> Now for our protocol we want both parties (p1 and p2) to be able to fee bump >> a commitment transaction. They use MuSig to sign the commitment tx under the >> external key with a decent fee for the current conditions. But in case it >> proves insufficient they have added the following two leaves to their key in >> the funding output as a backup so that p1 and p2 can unilaterally bump the >> fee of anything they sign spending from the funding output: >> >> 1. OP_CHECKSIG_MUTATED(0, 0x02, , ) >> OP_CHECKSIGADD(p1-fee-bump-key, ) OP_2 >> OP_NUMEQUALVERIFY >> 2. OP_CHECKSIG_MUTATED(1, 0x02, , ) >> OP_CHECKSIGADD(p2-fee-bump-key, ) OP_2 >> OP_NUMEQUALVERIFY >> >> where <...> indicates the thing comes from the witness stack. >> So to bump the fee of the commit tx after it has been signed either party >> takes the and adds a signature under their fee-bump-key >> for the new tx and reveals their fee bump leaf. is >> checked against the old transaction while the fee bumped transaction is >> checked against the fee bump key. >> >> I know I have left out how to change mempool eviction rules to accommodate >> this kind of fee bumping without DoS or pinning attacks but hopefully I have >> demonstrated that this class of solutions also exists. >> >> [1] https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0118.mediawiki >> >> Cheers, >> >> LL >> >> On Fri, 28 May 2021 at 07:13, Antoine Riard via bitcoin-dev >> wrote: >> >>> Hi, >>> >>> This post is pursuing a wider discussion around better
