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
114
115
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimon@monetize.io>) id 1WdKy3-0004Nl-NQ
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 14:49:39 +0000
Received: from mail-lb0-f173.google.com ([209.85.217.173])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WdKy2-00035q-LA
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 14:49:39 +0000
Received: by mail-lb0-f173.google.com with SMTP id l4so2093600lbv.18
for <bitcoin-development@lists.sourceforge.net>;
Thu, 24 Apr 2014 07:49:32 -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:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=hh6wIp/fGZtQ2M85BPwy8bElaNVben+EFaQVvA20kj8=;
b=ODSTcSjCgsAkJhU0LWuZ+C02XLmyMw/ni1akGX+hBkAtKvyYqbufMFasj1uk1Q5InR
Mheu4Y38SCf/8cBJQyU3OKju0ZOHzxXFKO223TNTOBkVM971LhEXg3Rk3B+pJRI8F1QZ
a6KKe+Ts5v/nuYk0p8Azefl6RzHLv3hRfRMQeKM9N9qYAMpBecRvgjzmx8RGCVheWght
vbQpGrQ2W5ccAldqabQ4DbfPz3/2EaUHKNL+qq7sY3asZApHPM9zpgxUinzSEpbsdBDr
TLj3ddh4JSV5mGVgl/e/0PaZM37U3Raj9Aw3YP6sndCzVIiqsmqg+uLeTQbG2Z9Gm53u
VBHw==
X-Gm-Message-State: ALoCoQmaMR/kM/2mIm5XXulj9bEoJG0RV7QGpQHKANOabkwpyoOL7CERDKMXnp/9jLjrU2Yh/hXo
MIME-Version: 1.0
X-Received: by 10.112.157.67 with SMTP id wk3mr799522lbb.63.1398350972071;
Thu, 24 Apr 2014 07:49:32 -0700 (PDT)
Received: by 10.112.185.4 with HTTP; Thu, 24 Apr 2014 07:49:31 -0700 (PDT)
X-Originating-IP: [85.59.56.59]
In-Reply-To: <CANEZrP0fjzuUKh0Jmk9c99ne81hdxZdTnhw6sq47Na7AC4n04A@mail.gmail.com>
References: <CAC1+kJM3pSq8YfwbX167rQ0=0Y_hozRQ3pggDN524=LUfOdTqg@mail.gmail.com>
<CANEZrP1f9WV-Mp9SGm4q88h82xxBnwqg8M7JJhnqGOHCWf65xg@mail.gmail.com>
<CAB+qUq7=o05GgCNdTtH=cuW56qbjg5v0ZpxvCYmCPj1AvFui+g@mail.gmail.com>
<CANEZrP0fjzuUKh0Jmk9c99ne81hdxZdTnhw6sq47Na7AC4n04A@mail.gmail.com>
Date: Thu, 24 Apr 2014 16:49:31 +0200
Message-ID: <CAC1+kJNTpHpG5EpRKj21PEy3z2iAouuH6Yiix8m20uji3b6Lgg@mail.gmail.com>
From: =?ISO-8859-1?Q?Jorge_Tim=F3n?= <jtimon@monetize.io>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=ISO-8859-1
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: 1WdKy2-00035q-LA
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [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 14:49:39 -0000
On 4/24/14, Mike Hearn <mike@plan99.net> wrote:
>>
>> This scheme would discourage people from attempting a Finney attack
>> because they would end up worse off if they did.
>>
> Phrased another way, it simply makes every block a Finney attack that
> charges the maximum double spending fee possible. This doesn't solve the
> problem.
This solves regular double-spends, not Finney attacks, but finney
attacks (which are not really the easiest attacks in the world) don't
get any worse.
On 4/24/14, Chris Pacia <ctpacia@gmail.com> wrote:
> It would work but it's an ugly hack IMO. What do people do if they don't
> have extra to pay when making a purchase? I have 200 mbtc and want to buy a
> 200 mbtc phone but I can't because I need 400 mbtc. Sucks for me.
>
> I would much prefer the hassle of a green address notary than always having
> to make sure I have double what I need to make a purchase.
This scheme wouldn't be mandatory. You can still wait for
confirmations or rely somehow on existing trust instead if that's
better for you on that situation.
> Beyond needing to double balances, what if the shop is selling me a phone
> on contract? So the actual cost of the phone is lower than the real price
> on the assumption of future revenue. Alice double spends (aka steals) the
> phone, paying double the artifically lower cost but still making a good
> saving. Bob does not end up with "nothing", he ends up in the red.
Sybil attacks aside, Alice can't save anything, period. If she tries
she will end up losing it all.
I don't see how signing a longer term contract protects her in any way.
> But there's a much simpler way to dispose with this idea. Jorge, go down to
> your local bars and cafes, and ask them if they'd be willing to accept a
> form of payment that allows anyone to steal from them by simply paying
> double the purchase price to some other random guy. They *will* look at you
> as if you're crazy. Why would they ever do that?
They would do that to avoid having to wait for a confirmation or two
(I think one is good enough for most small purchases) when being paid
by people they don't trust just before they leave.
Maybe they prefer to just make people wait if they think that will
make them pay up-front.
This is completely optional and only an improvement on the current situation.
Of course if we're not comparing this with Bitcoin today and we're
comparing it to some theoretical mechanism for instant p2p
serialization without requiring proof of work then, yes, this concept
is not very interesting.
|
