public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

From: "Jorge Timón" <jtimon@monetize•io>
To: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: [Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory
Date: Thu, 24 Apr 2014 12:48:54 +0200	[thread overview]
Message-ID: <CAC1+kJM3pSq8YfwbX167rQ0=0Y_hozRQ3pggDN524=LUfOdTqg@mail.gmail.com> (raw)

Here is a solution to the problem of having 0 confirmation
transactions that relies on game
theory and most miners implementing replace-by-fee and child-pays-for-parent.

This has been proposed before
http://sourceforge.net/p/bitcoin/mailman/message/30876033/
I'm just going to describe the general idea in more detail.

Here's a small draft on how this could work:

Alice goes to Bob's store and wants to buy something cheaper than a
car, say a smartphone.
So Bob says, "it's 200 usd in btc, please pay me 400 usd in btc"
So Alice signs a tx with 400 and no fee with her old phone and she
just sends it to Bob rather than the network.
Bob creates a child transaction keeping 200 and giving 199.9 (0.1 usd
fee) back to Alice.

But you know, Alice wants to double spend.
She double spends 399.8 to herself (0.2 fee)
Bob thinks "last chance", he double-spends the child: 200 to Bob, back
199 to Alice (1 usd fee).
Alice is stubborn: 398 to Alice (2 usd fee).
Bob is really pissed off, double spends the child: 400 in fees.

So, ok, Bob lost the phone and got nothing but Alice has paid twice as
she needed for the phone.
Nobody's happy thus everybody's happy.

This is similar to the general game theory "stag hunt" case.
The payoff matrix could be something like this:

                        Bob returns change   Bob burns in fees
 ---------------------+--------------------+-------------------
  Alice behaves         + 1 , + 1            - 1, + 1
 ---------------------+--------------------+-------------------
  Alice double-spends   + 3, - 1             - 1, - 1

The game has two Nash equilibria, but cooperation is Pareto efficient.

Replace-by-fee and child-pays-for parent cannot be prohibited by a
protocol rule.
I believe all miners will eventually implement these policies because
it is the more rational way for them to prioritize transactions.
Finally I hope they do because it would make 0-confirmation
transactions possible as described in this post.
So I can't find any reasoning against replace-by-fee unless my example
is terribly flawed.
Am I missing something?

-- 
Jorge Timón

http://freico.in/

next             reply	other threads:[~2014-04-24 11:47 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-24 10:48 Jorge Timón [this message]
2014-04-24 11:54 ` Mike Hearn
2014-04-24 12:07   ` Chris Pacia
2014-04-24 12:15     ` Mike Hearn
2014-04-24 14:49       ` Jorge Timón
2014-04-24 15:45         ` Mike Hearn
2014-04-24 17:13       ` Jannis Froese
2014-06-19  3:47       ` Isidor Zeuner
2014-04-25  4:51     ` Gareth Williams
2014-04-25 10:19       ` Mike Hearn
2014-04-25 13:38         ` Gareth Williams
2014-04-24 12:59 ` Peter Todd
2014-04-24 14:20   ` Jorge Timón

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAC1+kJM3pSq8YfwbX167rQ0=0Y_hozRQ3pggDN524=LUfOdTqg@mail.gmail.com' \
    --to=jtimon@monetize$(echo .)io \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox