What is a "double-spend"?

That question has come up lately, so I'm going to give it a go for answering it...

Spoilers, there are actually multiple possibilities under the classification of "double-spend" transactions...

First things first, let's look at how Bitcoin works.

A transaction takes inputs, and creates outputs.

Outputs contain locking scripts which must be "solved" in order to spend the coins.

Inputs contain references to outputs from previous transactions and include unlock scripts.

Those unlock scripts, if valid, "solve" the Output's locking scripts.

So, a valid Input spends an Output when it correctly "solves" the locking script of a valid Output.

A UTXO is an Unspent Transaction Output
U = Unspent
TX = Transaction
O = Output

So, the UTXO set is the current (as of X block,) set of valid transaction outputs that have not been spent in confirmed transactions (transactions included in a block.)

Now...

A double-spend can take a few forms.

First, when you spend the same inputs more than once in separate valid transactions, it is a double-spend of those inputs.

You can do this right now on your own system with something like TxForge.

Heck, you can do that with previously spent Outputs that are confirmed on that network as having been spent!

The thing is, nobody actually cares, because you're not broadcasting these spends to the network.

This is why it's so important for the ledger to be public, and for transactions to be confirmed.

This is also why it's important to check transactions with miners to confirm that a UTXO from inputs in a transaction you're accepting haven't been spent yet.

Now, let's say a UTXO has been spent in a transaction that is included in a block. That transaction is now confirmed.

There are only two ways for a double-spend to occur on the network now...
1) A miner creates an invalid block including that transaction
2) That block is orphaned, and a conflicting transaction is included in the new chain.

In the first case, it's an inflationary event because new coins are being created in an invalid manner due to the double-spend of coins on chain, confirmed in a block on chain.

This DID NOT happen with the recent BTC double-spend event.

The second case is NOT an inflationary event, but the UTXOs (the coins) from the now orphaned transaction would be invalid, as they're created out of inputs that have been spent in the now longest chain.

That second option is what happened on BTC.

Now here's the thing:

In that BTC event, the outputs of both transactions were almost identical. Presumably, the individual was sending to the same person (perhaps even themselves,) and paying a higher fee for it.

So, is that ok? Is that bad? Is it damaging to the system that it happened?

Well, that's kind of a squishy issue.

Let's say someone was paying a merchant with that transaction...

If they change the fee, then either the Inputs must change and the Outputs stay the same, or the Inputs must change and the Outputs must change at least in part...

If the Outputs remain exactly the same, then the change in Inputs ONLY changes the fee.

After all, the fee is the remainder from Input value - Output value. So, increase Input values and keep Outputs the same, you have a higher fee.

That, I think, is pretty hard to argue is a bad thing in the system, though it's a horrible user experience for a number of reasons.

But what if you change the Outputs?

Generally a transaction has 2 Outputs at a minimum:
1) The address you're sending coins to, out of your control
2) The address you're sending the extra coins back to, in your control - the "change" address.

The "change" address allows you to pick any of your UTXOs and set the fee you're paying to miners without having to "right size" the UTXOs for your transaction. This is really important!

Now, it seems alright to be able to change the "change" Output's value to let you set your fee appropriately, right? No damage to the system, or to anyone else, so long as the other Output stays the same.

Except... Which output is the "change" output, and which isn't?

Nobody can tell which Output is going into someone else's control, and which is going back into your own control, unless you're sending back to the same address you're spending from.

So on a system level, you can't enforce anything based on that idea.

As such, you can't enforce that people send to the same Outputs and call it an "acceptable double-spend"...

Because what if you use this method to short-change merchants by sending them less coins this way?

So, what happened on BTC *was* a successful double-spend, though it probably wasn't actually harming anyone (not that anyone can know but the folks directly involved in the transaction,) and it's a natural, expected part of Bitcoin's operation...

The thing is, BTC's particular self-inflicted problems (the block size limit, for example,) make double-spends like this far more problematic and far more likely to occur.

Add to that the "my node matters" degradation of network connectivity and folks can actively create double-spends, manufacturing consensus crises where miners must race to find the "accepted" chain given multiple conflicting transactions.

Essentially, someone can choose to broadcast conflicting transactions at different entry points in the network, allowing someone to predictably make two different conflicting versions of a transaction "first-seen" by different miners.

Without knowing who owns which UTXOs, you can't prevent someone from "testing" the network with this method.

And that I think is a pretty interesting problem that someone might be able to take advantage of in demonstrating the flaws in the BTC alterations to the Bitcoin design.