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 ` [Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory 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.io \
--cc=bitcoin-development@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox