Topic: Defence against double spending, even 0-confirmation - page 2. (Read 3058 times)

I edited the first post. Now it only needs 51% of miner support, and old clients don't need to upgrade. Blocks are fully backward compatible.

Let me help you ...

"a POTENTIAL solution would be a kill or fill value".

Nobody except you claimed "x" exists.

There is no x, and its absence is neither an accident nor an oversight.

I think you fail to understand how old some nodes are.  Even if programmed to start some years in the future a good chunk of the network would be incompatible.

It would have to be programmed to start at some block number several months in the future.

I support this.  It's a good idea even outside double-spend-confiscation.



The node is not guaranteed to be on the same LAN after being restored.  for instance, a laptop may be carried over to the IT department for a restore.

Also: are unconfirmed txes actually stored and sent to new nodes after the initial flooding?  I seem to recall that if you're not on the net at the time of the initial broadcast you won't hear about it until you see it in a block.

Instead, the recipient should spend the stuck transaction to himself with a higher fee to push it through. Miners have to include the first transaction to get the higher fee in the second one.

The sender can also do it by spending the change.

A potential solution for "limbo" tx in general is a kill or fill value.  If not included by block x, the tx is void.  Client default behavior could be to set kill value for 30 blocks into future for a tx (can be overriden by users).  Still the risk is minimal.  Tx only go into "limbo" if the user violates spam rules.  To do that requires using a custom client and willfully breaking protocol rules.


The restored node should see the tx from the other LAN node. 

So neither issues are killers but it does make the protocol more "fragile".  Things need to be done right or there is a risk of invalidating funds.

The larger issue is implementation.  A change like this would require not just miners upgrading but 100% of nodes to avoid a permenent fork.  Likely an impossible goal.  There are less drastic solutions to non 51% attack double spends (like tx contracts).  This change wouldn't affect 51% attacks or Finney attacks which are the more likely double spends.

It is possible for people create non-fraudulent double-spends.  A common case: if they forgot to include a sufficient fee and the transaction goes into limbo, they can resend it with a fee.  Under this proposal there's a small chance they could lose the entire balance if a miner who considers the no-fee transaction to be valid and then mines them both.  Evil miners could even hoard such transactions hoping for the opportunity to confiscate a large fee.

Or another: they send a transaction while their LAN is disconnected from the network (another machine on their LAN sees it); they restore from backups; their restored client doesn't show the transaction so they resend it; when the LAN reconnects to the internet both transactions are transmitted and then confiscated.

Interesting but likely impossible to implement.  Old node (not just miners) would be incompatible.   So it would require a 100% upgrade of every single node on the network to avoid disruptions.

Here's an idea to take away the incentive to double spend. If a miner finds a double spend, it can put BOTH into the same block and the entire double spent amount goes to fee. Instead of up to ~50% chance of getting the money back, double spending would almost always fail and lose the money.

This would allow instant acceptance of 0-confirmation transactions for most uses that need it, like point-of-sale.

It's pretty easy to scan for conflicting inputs in a block. I'm not sure it would be necessary to flag or list them in a separate list.

Both transactions must go in the same block. If a double spend comes along after the first transaction is already in a block, it's too late.

This would only apply with a lockTime=0 spend. If you need to create multiple spends on purpose for some reason, use lockTime=1 or higher.

EDIT
New backward compatible version 2:

If a miner finds a double spend, it puts both spends into an extension data area in the block. The double spent inputs are marked as paying to this miner's scriptPubKey, but can't be spent until some future time when we decide enough old clients have upgraded. There's bound to eventually be a security issue that makes all old clients insecure and forced to upgrade.

So the entire double spent amount goes to the miner, eventually. In the future, it'll go to the miner immediately.

For transition, we only need to get above 51% of mining power following the new rule.

This is fully compatible with old clients. They continue to see double spends stay stuck at 0-confirmation.

Both old and new clients will benefit from the fact that double spending is as futile as sending your money to 1BitcoinEaterAddressDontSendf59kuE.

The extension data could be shoehorned in anywhere, like an extra 0BTC output on the coinbase to a deadend scriptPubKey that contains the extension data in a push-drop.