Bitcoin Forum
May 24, 2024, 03:06:37 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Instant clearing solution/double spend defense.  (Read 3680 times)
Cryddit (OP)
Legendary
*
Offline Offline

Activity: 924
Merit: 1129


View Profile
September 01, 2013, 03:23:28 AM
 #1


I have been thinking hard about instant clearing. The problem is the possibility of a double spend.  In a double spend, a transaction is lost in a block chain reorganization.  The reason the transaction is lost is because it refers to an input which has already been spent by another transaction.  Therefore it is invalid because of insufficient inputs.  Therefore it is necessary to wait several blocks to be sure that a block chain reorganization will not happen.  Otherwise the spender may be able to double spend.

I think I may have a solution to this problem.  The spender must post a surety bond.  It is not necessary that the recipient get this bond. If the spender loses it, then  it means that the spender has no motive to commit a double spend.  This can be done by making the spender demonstrate ownership of an account containing enough for the surety bond.  It can be done without requiring the spender to reveal the private key of that account.

The spender has the account he is spending money from.  He also has a surety account.  The surety account must be at least a week old.  This makes it very unlikely to disappear in a block chain reorganization.  The surety account must contain enough money to make sure a double spend is unprofitable.  That means at least the amount being spent.  To account for exotic triple-spend attempts, maybe double the amount being spent.  The recipient of funds presents nonce, which does not hash to the script that spends the account.  The spender must encrypt nonce using the private key of the surety account.  The recipient can check by decrypting nonce using the public key of the surety account. This demonstrates that the spender owns the surety account.  It does not spend the surety account. The public key of the surety account is then recorded in the transaction. 

If a transaction citing a surety account fails due to insufficient inputs, the surety account cannot be subsequently spent.

In practice the failure of a transaction due to insufficient funds occurs in case of a double spend.  It may also occur if a wallet is badly mismanaged.  The spender states  with a surety bond that neither thing has happened.  The recipient knows that the spender has no motive to commit a double spend.  The recipient knows that the spender has a strong motive to avoid mismanaging his wallet.  The recipient may therefore accept funds instantly without waiting for block chain confirmation, knowing that if the recipient loses anything the spender will lose more.

This requires a hard fork update to the protocol rules.  The new rule must enforce this constraint.  This requires extension of existing clients.  The extension must enable clients to handle instant-clearing transactions with surety bonds. 

I have been very careful to construct English.  I hope I have done it well enough.  If I have not, I apologize.  It is difficult.  I am using a grammar checking program.  It doesn't know all the words I must use to describe this. 

Edward.
dragonfruit
Newbie
*
Offline Offline

Activity: 27
Merit: 0



View Profile
September 01, 2013, 04:22:51 AM
 #2

Sorry man but a hard fork isn't going to happen, and someone can double spend the same inputs 10 times for example.
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4186
Merit: 8424



View Profile WWW
September 01, 2013, 06:14:14 AM
 #3

Search for "bitcoin fidelity bonds".  I believe it is basically the idea you propose here.

There are other ways to provide for instant clearing but they require either knowing who you want to pay in advance and setting up an escrow with timed refund, or using a semi-trusted third party (an anti-replay signing oracle).
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!