1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimon@monetize.io>) id 1WdI7U-0007MN-4H
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 11:47:12 +0000
Received: from mail-oa0-f49.google.com ([209.85.219.49])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WdI7S-0001sa-8X
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 11:47:12 +0000
Received: by mail-oa0-f49.google.com with SMTP id o6so2441034oag.8
for <bitcoin-development@lists.sourceforge.net>;
Thu, 24 Apr 2014 04:47:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:date:message-id:subject:from:to
:content-type:content-transfer-encoding;
bh=f56UfBoneh0X+wb40lfl4phH+3JEqq3iDti72sYwrFU=;
b=V8dMHpi9YEn/KYnw+UmaEnTUoSaGBZ8gqtwZodG4P/zQcyo/GhkJz3bMZJfOdTgqw+
zQBQZlWxRb8CafQlwGAT3R2G4gNlnJzRz6mx8LD2RR5nbMFAy9a8EKAm9VEFyDW8oKA1
Lrr6cuxT3YFS6oO1lCQsXeuCpoS0lhPSzN/evcR47GqOEbQXSMhqIBF/kqjLma2o82jD
ZgjLdMU2yXrfcqZGUdh6PQDI0KE52o9fY4svwKWCaXk7PdAOVvAzdlqxXApSjXwQ9GLX
oxg7ebB++8QpLlvo/75nXTiYbPja8GcujlCL5ILjkkhVuXSN8Fomv7de2GIdE3HQc5np
/fKw==
X-Gm-Message-State: ALoCoQm/yspiRhqPIHULGxo2OpjkSryzPww+Po7qLzjDZEETB8qcGQv5MFtotoVt9bMAyGXUp+HZ
MIME-Version: 1.0
X-Received: by 10.60.77.35 with SMTP id p3mr906228oew.46.1398336534373; Thu,
24 Apr 2014 03:48:54 -0700 (PDT)
Received: by 10.76.114.193 with HTTP; Thu, 24 Apr 2014 03:48:54 -0700 (PDT)
X-Originating-IP: [85.59.56.59]
Date: Thu, 24 Apr 2014 12:48:54 +0200
Message-ID: <CAC1+kJM3pSq8YfwbX167rQ0=0Y_hozRQ3pggDN524=LUfOdTqg@mail.gmail.com>
From: =?ISO-8859-1?Q?Jorge_Tim=F3n?= <jtimon@monetize.io>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1WdI7S-0001sa-8X
Subject: [Bitcoin-development] 0 confirmation txs using replace-by-fee and
game theory
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 24 Apr 2014 11:47:12 -0000
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-paren=
t.
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?
--=20
Jorge Tim=F3n
http://freico.in/
|
