ECDSA signatures: why not force the reuse for r for spends from the same address

[monsterer2]

If we want to discourage double spends, why aren't we just enforcing the rule that spends from the same address must use the same r value in the ECDSA signatures?

This would mean that any attempted double spend would reveal the private key*, therefore making the double spend attempt futile, while still allowing standard transactions to function, because change is always sent back to a new address anyway.

It ought to be possible to verify and disallow unique r values for spends from the same address.

Obviously I'm overlooking something horribly obvious here, anyone care to enlighten me?

Cheers, Paul.


*) https://bitcointalk.org/index.php?topic=271486.0

[1714939856]

1714939856

[1714939856]

1714939856

[1714939856]

1714939856

[1714939856]

1714939856

[achow101]

It ought to be possible to verify and disallow unique r values for spends from the same address.

No, it isn't. Bitcoin does not use an accounts model where an address is an account. It uses a UTXO model where each UTXO is independent of every other UTXO. Furthermore, addresses do not exist on the protocol level, so to do this, we would have to maintain a script index, but not all scripts map to an address anyways. Additionally, there are more than just the single pubkey addresses, you can have complex scripts for an address (P2SH) which greatly complicates things because those scripts can have pubkeys that are reused in other scripts. And then all nodes need to maintain a script index which requires significantly more computational power and a lot more disk space.

[odolvlobo]

My issues are:

1. There are legitimate reasons for 0-conf double spends, e.g RBF.
2. I consider punishing someone for making a mistake to be a problem and not a feature.
3. Address reuse cannot be prevented by the owner of an address.

[monsterer2]

It ought to be possible to verify and disallow unique r values for spends from the same address.

No, it isn't. Bitcoin does not use an accounts model where an address is an account. It uses a UTXO model where each UTXO is independent of every other UTXO.

Ah, yes, I'd forgotten about that. In order for this to work you'd need to generate a new address every time you wanted to receive some BTC which is beyond the scope of what is logical for bitcoin.

edit: you could do this with the UTXO model but you'd need a signature per UTXO.

[monsterer2]

My issues are:

1. There are legitimate reasons for 0-conf double spends, e.g RBF.
2. I consider punishing someone for making a mistake to be a problem and not a feature.
3. Address reuse cannot be prevented by the owner of an address.

I agree. But in theory, if you had something like what I've suggested, you don't need a blockchain anymore, or miners or anything except the UTXO DAG.

[HeRetiK]

[...]

This would mean that any attempted double spend would reveal the private key*, therefore making the double spend attempt futile, while still allowing standard transactions to function, because change is always sent back to a new address anyway.

[...]

I'm not sure if such an approach would really make double spend attempts futile though. It discourages double spending, yes, but gives no solution on how to resolve conflicting transactions, should they occur. Also the discouragement only works insofar as that the network tries to punish the double spender by enabling other network participants to attempt double spends of their own.

The problem being as follows: In essence revealing the private key on attempting a double spend only means that other network participants can now double spend your coins as well. Which means it now boils down to who spams the network the hardest to force the double spent. Tough luck for someone double spending by accident; a field day for an adversary that attempts a double spend on purpose and has a botnet at their disposal. And that's ignoring the question of resolving conflicting transactions as mentioned above.

[monsterer2]

Tough luck for someone double spending by accident; a field day for an adversary that attempts a double spend on purpose and has a botnet at their disposal. And that's ignoring the question of resolving conflicting transactions as mentioned above.

I'm not quite sure what you mean by the botnet comment? In bitcoin, the winner of the race to claim the funds would be the person who paid the highest fee; on average this means the funds will get burnt as transaction fees.

As for resolving conflicting transactions, I can't think of an example of a conflicting transaction that isn't a double spend?

[HeRetiK]

Tough luck for someone double spending by accident; a field day for an adversary that attempts a double spend on purpose and has a botnet at their disposal. And that's ignoring the question of resolving conflicting transactions as mentioned above.

I'm not quite sure what you mean by the botnet comment? In bitcoin, the winner of the race to claim the funds would be the person who paid the highest fee; on average this means the funds will get burnt as transaction fees

I mean that in the scenario as described above -- no miners, the only collateral being the amount that is being spent -- an adversary would use botnets, virtual machines or whatever other resources they have at their disposal to get the transaction they are trying to force to get seen by as many nodes as possible. A user creating a double spend by accident, would likely take no such measures.

Note that with Bitcoin in its current state a high transaction fee does not guarantee precedence over other transactions. If both transactions that are part of a double spend attack have a reasonable high fee attached it doesn't make much of a difference whether you paid 100 sats per byte or 1000 sats.

Ignoring how Bitcoin works today, let's assume we have a system where highest fee always takes precedence.

How does a node know that it sees the transaction with the highest fee? Different nodes see a different subset of transactions. In Bitcoin that's their respective mempools. The blockchain exists to normalize these transactions across all nodes. In the system as described above each node would have their own version of history.

But let's go further. Let's say a node knows that the transaction it sees has to be the one with the highest fees because it burns all its outputs. What happens to the transactions that spend those inputs? Say someone makes a double spend using an address from 2-3 years ago. Those coins have been in circulation for quite a while now and fractions of this transaction have found their way into many people's wallets. Now suddenly these coins are burned and all these uninvolved parties lose their coins. Effectively the whole transaction history needs to be rewritten at the snap of a finger. And you'll never know when it hits you.

Immutability is one of the core value propositions of blockchains. A system as described above, would completely rid a cryptocurrency of this property.

As for resolving conflicting transactions, I can't think of an example of a conflicting transaction that isn't a double spend?

I was indeed referring to double spends as conflicting transactions. What I was missing was the strategy how they are handled besides exposing the private key -- exposing the private key being only the first step. Now I see that the implicit assumption was that exposing the private key would automatically burn the coins in question by means of transaction fees. For a more detailed comment on this approach, see above.


That being said, keep in mind that miners fulfill another function besides securing the network against double spend attacks -- currency issuance. If you reduce the transaction history to a DAG without PoW, all you're left with is a central entity issuing all currency.

[monsterer2]

Say someone makes a double spend using an address from 2-3 years ago. Those coins have been in circulation for quite a while now and fractions of this transaction have found their way into many people's wallets. Now suddenly these coins are burned and all these uninvolved parties lose their coins. Effectively the whole transaction history needs to be rewritten at the snap of a finger. And you'll never know when it hits you.

That's what I was missing. As you pointed out, there's no objective way to solve this with just the transaction DAG. Thanks for the feedback.

[HeRetiK]

Say someone makes a double spend using an address from 2-3 years ago. Those coins have been in circulation for quite a while now and fractions of this transaction have found their way into many people's wallets. Now suddenly these coins are burned and all these uninvolved parties lose their coins. Effectively the whole transaction history needs to be rewritten at the snap of a finger. And you'll never know when it hits you.

That's what I was missing. As you pointed out, there's no objective way to solve this with just the transaction DAG. Thanks for the feedback.

Thanks for the thought experiment.

I had the feeling that something was off about your approach, but wasn't quite able to put my finger on it until I put a bit more thought into it.

[monsterer2]

Thanks for the thought experiment.

I had the feeling that something was off about your approach, but wasn't quite able to put my finger on it until I put a bit more thought into it.

This idea might still have some legs because arguably it would still work if weak subjectivity was an acceptable compromise since no online node would accept a historical double spend as being valid given the latest UTXO DAG. I don't think weak subjectivity should ever be acceptable, however, so I'm going to keep thinking

[HeRetiK]

Thanks for the thought experiment.

I had the feeling that something was off about your approach, but wasn't quite able to put my finger on it until I put a bit more thought into it.

This idea might still have some legs because arguably it would still work if weak subjectivity was an acceptable compromise since no online node would accept a historical double spend as being valid given the latest UTXO DAG. I don't think weak subjectivity should ever be acceptable, however, so I'm going to keep thinking

Look into DAG based cryptocurrencies such as IOTA and ByteBall, if you haven't already. Unfortunately they are both centrally issued and rely on centralized trusted entities (IOTA's coordinator and ByteBall's witnesses, respectively) but there might be something worth learning from them nonetheless.

[Traxo]

3. Address reuse cannot be prevented by the owner of an address.

This is because addresses don't expire, not because of the intractability of another user being able to generate the same address. However, presuming each transaction designates inputs tied to specific UTXO outputs (so that other payments to the same public key address do not conflict) and not applying it to (or finding an analogous construction for) scripts, then a plausible design is to declare that any conflicting spend (seen by any witness and posted to the chain) from a specific output would always be a double-spend that burns all the outputs of all such conflicting transactions, but that incurs numerous issues some of which have been mentioned in this thread and other issues were mentioned recently in other thread. Most notably that the double-spend rule has to expire else the payee is forever held hostage.