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
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimon@jtimon.cc>) id 1YPFR8-0003l0-IJ
for bitcoin-development@lists.sourceforge.net;
Sat, 21 Feb 2015 19:09:58 +0000
Received: from mail-wi0-f177.google.com ([209.85.212.177])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YPFR6-0007jZ-TK
for bitcoin-development@lists.sourceforge.net;
Sat, 21 Feb 2015 19:09:58 +0000
Received: by mail-wi0-f177.google.com with SMTP id bs8so9140346wib.4
for <bitcoin-development@lists.sourceforge.net>;
Sat, 21 Feb 2015 11:09:50 -0800 (PST)
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=px5sVtA2vVTJXaxT9LB1RtnejrDWBs7XxT5eIjxtuJU=;
b=Z6WzR9EwavHLn2Lij3gA7C+tEJd2ahMjr5W+N/IoXKqUrwCYw9yvUSjI6mfksaiIYA
bmeSv+tpF55c3g64Xpl/LiRx2xBWIK+r5jyol7PQCMPwM7F/vBSPrZ9RCYPDEuBgboIq
lE5stOCogTnG4cnvyg0MgUvS2f97B2IafcyvS+W8quJ2ZNyHpbehNxk1hc8kaC/H9qYz
Bait4/buieq7DrdRFbh6eSvzzkTfUzp4F0QS9S4g5FGCNKrqRNv2Uvt2wHdQvmXS1ke7
n/dySGPm115ieeZvUYY/hq8/KyyJMBimJyJ53734KbH+brVQglxFiUjOKZl0/Mzj8NNe
zRVQ==
X-Gm-Message-State: ALoCoQnDy1JT7p+N7SPFOorptp1JlxDIMI31UwCyCEcFXLXF1t6sdNquoNmjNbIl+hYOar4Fdz8C
MIME-Version: 1.0
X-Received: by 10.194.19.197 with SMTP id h5mr6787300wje.109.1424545790515;
Sat, 21 Feb 2015 11:09:50 -0800 (PST)
Received: by 10.194.133.74 with HTTP; Sat, 21 Feb 2015 11:09:50 -0800 (PST)
X-Originating-IP: [173.228.107.141]
In-Reply-To: <20150219085604.GT14804@nl.grid.coop>
References: <20150212064719.GA6563@savin.petertodd.org>
<CANEZrP2uVT_UqJbzyQcEbiS78T68Jj2cH7OGXv5QtYiCwArDdA@mail.gmail.com>
<CAJHLa0PkzG44JpuQoHVLUU8SR55LaJf5AwG=a7AjK2u7TAveOQ@mail.gmail.com>
<20150215212512.GR14804@nl.grid.coop> <54E11248.6090401@gmail.com>
<20150219085604.GT14804@nl.grid.coop>
Date: Sat, 21 Feb 2015 20:09:50 +0100
Message-ID: <CABm2gDorEFNzzHH2bxpo6miv1H0RUhL9uAYX6gg2aW0wB1QDbw@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Troy Benjegerdes <hozer@hozed.org>
Content-Type: text/plain; charset=UTF-8
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: 1YPFR6-0007jZ-TK
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
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: Sat, 21 Feb 2015 19:09:58 -0000
I agree "scorched hearth" is a really bad name for the 0 conf protocol
based on game theory. I would have preferred "stag hunt" since that's
basically what it's using (see http://en.wikipedia.org/wiki/Stag_hunt)
but I like the protocol and I think it would be interesting to
integrate it in the payment protocol.
Even if that protocol didn't existed or didn't worked, replace-by-fee
is purely part of a node's policy, not part of consensus.
From the whitepaper, 0 conf transactions being secure by the good will
of miners was never an assumption, and it is clear to me that the
system cannot provide those guaranties based on such a weak scheme. I
believe thinking otherwise is naive.
As to consider non-standard policies "an attack to bitcoin" because
"that's not how bitcoin used to work", then I guess minimum relay fee
policies can also be considered "an attack to bitcoin" on the same
grounds.
Lastly, "first-seen-wins" was just a simple policy to bootstrap the
system, but I expect that most nodes will eventually move to policies
that are economically rational for miners such as replace-by-fee.
Not only I disagree this will be "the end of bitcoin" or "will push
the price of the btc miners are mining down", I believe it will be
something good for bitcoin.
Since this is apparently controversial I don't want to push for
replace-by-fee to become the new standard policy (something that would
make sense to me). But once the policy code is sufficiently modular as
to support several policies I would like bitcoin core to have a
CReplaceByFeePolicy alongside CStandardPolicy and a CNullPolicy (no
policy checks at all).
One step at a time I guess...
On Thu, Feb 19, 2015 at 9:56 AM, Troy Benjegerdes <hozer@hozed.org> wrote:
> On Sun, Feb 15, 2015 at 11:40:24PM +0200, Adam Gibson wrote:
>>
>>
>> On 02/15/2015 11:25 PM, Troy Benjegerdes wrote:
>> >
>> > Most money/payment systems include some method to reverse or undo
>> > payments made in error. In these systems, the longer settlement
>> > times you mention below are a feature, not a bug, and give more
>> > time for a human to react to errors and system failures.
>> >
>>
>> Settlement has to be final somewhere. That is the whole point of it.
>> Transfer costs in current electronic payment systems are a direct
>> consequence of their non-finality. That's the point Satoshi was making
>> in the introduction to the whitepaper: "With the possibility of
>> reversal, the need for trust spreads".
>
> The problem with that statement is I trust a merchant that I went into
> a store and made a payment with personally more than I trust the firmware
> on my hard drive [1].
>
> The attack surface of devices in your computer is huge. A motivated attacker
> just needs to get an intern into a company that makes some kind of component
> or system that's in your computer, cloud server, hardware wallet, or what
> have you that has firmware capable of reading your private keys.
>
> With the possibility of mass trojaned hardware, if we are going to trust
> the system, it must somehow allow reversal through a human-in-the-loop.
>
>> There is nothing wrong with having reversible mechanisms built on top
>> of Bitcoin, and indeed it makes sense for most activity to happen at
>> those higher layers. It's easy to build things that way, but
>> impossible to build them the other way: you can't build a
>> non-reversible layer on top of a reversible layer.
>
> We built 'reliable' TCP on top of unreliable ethernet networks. My experience
> with networking was if you tried to guarantee message delivery at the lowest
> level, the system got exceedingly complicated, expensive, and brittle.
>
> Most applications, in particular paying someone you already trust, are quite
> happy running on reversible systems, and in some cases more reliable and
> lower risk. (carrying non-reversible cash is generally considered risky)
>
> The problem is that if the base currency is assumed to be non-reversible,
> then it's brittle and becomes 'too big to fail'.
>
> Where the blockchain improves on everything else is in transparency. If you
> reverse transactions a lot, it will be obvious from an analysis. I would much
> rather deal with a known, predictable, and relatively continous transaction
> reversal rate (percentage) than have to deal with sudden failures where
> some anonymous bad actor makes off with a fortune.
>
> We already have zero-conf double-spend transaction reversal, why not explicitly
> extend that a little in a way that senders and receivers have a choice to
> use it, or not?
>
>
> [1] http://www.reuters.com/article/2015/02/16/us-usa-cyberspying-idUSKBN0LK1QV20150216
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
|
