Use ANYONECANPAY if -spendzeroconfchange=0 #8543

Signing transactions with ANYONECANPAY has a number of advantages:

1. Anyone can bump fees by adding a (small-valued) input: This can get struck transactions unstuck more effectively than CPFP, which may not work if the parent transaction hasn't gotten to a miner's mempool due to low fees.

2. Privacy/Fungibility: If inputs aren't signing each other, they're not making any explicit statement about the relationship of one input to another. In particular, any input that's less than the transaction fee is possibly from another wallet, confusing taint analysis with plausible deniability.

3. Discouraging Re-Orgs: By allowing anyone to add inputs to any transaction, we make malicious re-orgs targetting particular coins more disruptive, as the set of non-targetted transactions unrelated to the target coins can grow faster, increasing the colateral damage of a malicious re-org attack.

The downside of ANYONECANPAY is mutability, but if we're not spending zeroconf change that's irrelevant; enabling ANYONECANPAY if zeroconf change is disabled is an easy and low-risk first step towards using ANYONECANPAY more widely.

I've also opened an issue for joinmarket to implement this: https://github.com/JoinMarket-Org/joinmarket/issues/599

CC: @gmaxwell

Although you may argue that is discouraging re-orgs, this also makes a malicious re-org much more damaging. Children transaction of ANYONECANPAY would be considered to be less reliable, and more confirmations are required.

Since no new outputs might be added, the only use case is fee bumping, assuming an UTXO with an exactly appropriate value is available. The risks is too high and the benefit is too small.

Malicious reorgs are already very damaging if the attackers want to make them damaging in that way: just exploit mutability, fee bumping, etc.

ANYONECANPAY isn't significantly worse than what a malicious miner already can do.

On 19 August 2016 01:25:35 GMT-04:00, Johnson Lau notifications@github.com wrote:

Although you may argue that is discouraging re-orgs, this also makes a malicious re-org much more damaging. Children transaction of ANYONECANPAY would be considered to be less reliable, and more confirmations are required.

You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #8543 (comment)

Like I explained above, fee bumping is just one use-case: in addition we benefit the entire ecosystem with fungibility and privacy improvements.

On 19 August 2016 01:39:39 GMT-04:00, Johnson Lau notifications@github.com wrote:

Since no new outputs might be added, the only use case is fee bumping, assuming an UTXO with an exactly appropriate value is available. The risks is too high and the benefit is too small.

You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #8543 (comment)

Keep in mind, that the malicious reorg scenario where the attacker tried to disrupt the entire ecosystem assumes someone with sufficient hashing power to kill Bitcoin is trying to kill Bitcoin... While the targeted reorg is something a court could order miners to do: better to make such targeted attacks structurally infeasible.

Note the very similar goals of signature aggregation.

On 19 August 2016 01:39:39 GMT-04:00, Johnson Lau notifications@github.com wrote:

Since no new outputs might be added, the only use case is fee bumping, assuming an UTXO with an exactly appropriate value is available. The risks is too high and the benefit is too small.

You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #8543 (comment)

Segwit + BIP66 + BIP146 eliminate third party malleability for 99% of transactions. ANYONECANPAY reopens the vulnerability.

Consider an attack like this: To make sure my transactions is mined in the very next block, I pay a very high fee. With ANYONECANPAY everyone want to mix their coins will freeride my transaction by adding dust inputs.

To make sure my transactions is mined in the very next block, I pay a very high fee. With ANYONECANPAY everyone want to mix their coins will freeride my transaction by adding dust inputs.

Is that so bad? The miner will either choose the newly updated transaction, or it won't? It's only an issue if the miner isn't considering all previously known versions of the transaction, not just replacing the old with the new.

Interesting idea!

I think more work is needed before we could consider making this as default:

1. Miners need to select transaction in a more intelligent way. They should have the ability to drop dust inputs in order to maximize the fee with limited block space.
2. A bigger problem is it will make the txid malleable and confuse users. We have to define a new immutable id. The 36 bytes outpoint (prevhash+index) may be used since it is guaranteed to be unique.

Yes I think aiming to make this the default is too high for now, this should at least be an option though.

is -spendzeroconfchange true by default?

I think we should introduce another command argument for this (which implies spendzeroconfchange), instead of using spendzeroconfchange. A user who do not want to spend zero conf changes may not want his txids get randomly mutated.

@laanwj Yeah, I picked -spendzeroconfchange=0 in part because the default is -spendzeroconfchange=1 @jl2012 Starting with this as another command-line-option is fine by me. Maybe -setanyonecanpay, with default false?

With regard to malicious addition of low-value inputs, with RBF the higher-fee version will overwrite the lower-fee version the attacker is distributing, modulo a minor bit of friction around the anti-network-spam limit. So for full-RBF miners, it's a non-issue, and for most other miners it's a non-issue if opt-in-RBF is set.

Additionally, for transactions where all inputs are ANYONECANPAY you can sort the inputs by value and drop any input that doesn't make the overall fee-per-kb higher. This is a deterministic process, and would eliminate the issue.

Re: txid malleability and UI, remember that in general we have this issue in other contexts like coinjoin, fee bumping, malleability, etc.

The right thing to do has always been to not re-use addresses; we shouldn't bend over backwards for broken implementations.

Seems like someone can abuse this by adding garbage inputs (perhaps spending those 0-value anyone-can-spend generations p2pool [used to?] make) such that they reduce the fee of a high-fee transaction, but not below the minimum threshold that gets relayed. (RBF won't help, because the delta fee is zero.)

Any plans to make this otpional? Should this be closed and made into an issue for someone else to pick up later?

Closing, needs a bunch of other work to make more feasible, and I've got higher priorities.