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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <hozer@grid.coop>) id 1YOMu5-00089f-4E
for bitcoin-development@lists.sourceforge.net;
Thu, 19 Feb 2015 08:56:13 +0000
X-ACL-Warn:
Received: from nl.grid.coop ([50.7.166.116])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1YOMu3-0001Dp-Ql for bitcoin-development@lists.sourceforge.net;
Thu, 19 Feb 2015 08:56:13 +0000
Received: from localhost (localhost [127.0.0.1]) (uid 1000)
by nl.grid.coop with local; Thu, 19 Feb 2015 02:56:04 -0600
id 00000000000613C7.0000000054E5A524.00006CC8
Date: Thu, 19 Feb 2015 02:56:04 -0600
From: Troy Benjegerdes <hozer@hozed.org>
To: Adam Gibson <ekaggata@gmail.com>
Message-ID: <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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <54E11248.6090401@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Score: -0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1YOMu3-0001Dp-Ql
Cc: 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: Thu, 19 Feb 2015 08:56:13 -0000
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
|
