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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <natanael.l@gmail.com>) id 1YLtPY-0007vk-3c
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Feb 2015 13:02:28 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.49 as permitted sender)
client-ip=74.125.82.49; envelope-from=natanael.l@gmail.com;
helo=mail-wg0-f49.google.com;
Received: from mail-wg0-f49.google.com ([74.125.82.49])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YLtPX-0005Rd-4g
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Feb 2015 13:02:28 +0000
Received: by mail-wg0-f49.google.com with SMTP id l18so9931798wgh.8
for <bitcoin-development@lists.sourceforge.net>;
Thu, 12 Feb 2015 05:02:21 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.172.35 with SMTP id az3mr7561608wjc.43.1423746141026;
Thu, 12 Feb 2015 05:02:21 -0800 (PST)
Received: by 10.194.28.170 with HTTP; Thu, 12 Feb 2015 05:02:20 -0800 (PST)
Received: by 10.194.28.170 with HTTP; Thu, 12 Feb 2015 05:02:20 -0800 (PST)
In-Reply-To: <CANEZrP2YJxwVEocNXjc5cadcq6Wwed7vTLh_4zEX2ct7bTCz5g@mail.gmail.com>
References: <20150212064719.GA6563@savin.petertodd.org>
<CANEZrP2uVT_UqJbzyQcEbiS78T68Jj2cH7OGXv5QtYiCwArDdA@mail.gmail.com>
<CAAt2M1-eogn58zC_eAs4qD4-1GaY4wtuXLoSJ-UEZGKgdXGFyg@mail.gmail.com>
<CANEZrP2YJxwVEocNXjc5cadcq6Wwed7vTLh_4zEX2ct7bTCz5g@mail.gmail.com>
Date: Thu, 12 Feb 2015 14:02:20 +0100
Message-ID: <CAAt2M19UinurnQQVJWbR_UcSmCBsdFyksnhTfL4ESDMfny+UQQ@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=089e0122e8b6fc80de050ee3ba22
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(natanael.l[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YLtPX-0005Rd-4g
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, 12 Feb 2015 13:02:28 -0000
--089e0122e8b6fc80de050ee3ba22
Content-Type: text/plain; charset=UTF-8
Den 12 feb 2015 13:49 skrev "Mike Hearn" <mike@plan99.net>:
>>
>> Are you not counting collateralized multisignature notaries? Its an
extended version of the Greenaddress.it model.
>
> It makes unconfirmed transactions useless in the classical Bitcoin model.
Obviously if you introduce a trusted third party you can fix things, but
then you're back to having the disadvantages of centralised trust.
That trust you put in them is extremely limited, and temporary.
First of all, the standard multisignature notary model applies like how I
originally described it in my blog post over a year ago.
You can prove a doublespend instantly by showing two conflicting
transactions both signed by thar party. This pair can be distributed as a
proof of malice globally in seconds via a push messaging mechanism.
After confirmation in the blockchain, you have standard Bitcoin transaction
security.
To profit, the notary would have to be sure the payout from agreeing on
collusion (or to perform the doublespend themselves) would pay out better
than acting honestly for a given amount of time info the future. This means
transactions for small sums are secure.
To provide security for high value transactions, NRW adds a collateral
transaction that the notary stands for and signs in advance, and gives to
the seller. The key here is that it is constructed such that if the
original payment gets doublespent, then this collateral transaction to the
seller becomes spendable.
So there is two outcomes - either the customer or the notary pays the
seller. The customer can't force a doublespend. The notary can't steal or
freeze funds (due to nlocktime fund recovery option). The seller knows
he'll get the funds for sure before delivering the goods. Nobody is at
risk.
--089e0122e8b6fc80de050ee3ba22
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
Den 12 feb 2015 13:49 skrev "Mike Hearn" <<a href=3D"mailto:mi=
ke@plan99.net">mike@plan99.net</a>>:<br>
>><br>
>> Are you not counting collateralized multisignature notaries? Its a=
n extended version of the Greenaddress.it model.<br>
><br>
> It makes unconfirmed transactions useless in the classical Bitcoin mod=
el. Obviously if you introduce a trusted third party you can fix things, bu=
t then you're back to having the disadvantages of centralised trust.</p=
>
<p dir=3D"ltr">That trust you put in them is extremely limited, and tempora=
ry. </p>
<p dir=3D"ltr">First of all, the standard multisignature notary model appli=
es like how I originally described it in my blog post over a year ago.</p>
<p dir=3D"ltr">You can prove a doublespend instantly by showing two conflic=
ting transactions both signed by thar party. This pair can be distributed a=
s a proof of malice globally in seconds via a push messaging mechanism. </p=
>
<p dir=3D"ltr">After confirmation in the blockchain, you have standard Bitc=
oin transaction security. <br>
To profit, the notary would have to be sure the payout from agreeing on col=
lusion (or to perform the doublespend themselves) would pay out better than=
acting honestly for a given amount of time info the future. This means tra=
nsactions for small sums are secure. </p>
<p dir=3D"ltr">To provide security for high value transactions, NRW adds a =
collateral transaction that the notary stands for and signs in advance, and=
gives to the seller. The key here is that it is constructed such that if t=
he original payment gets doublespent, then this collateral transaction to t=
he seller becomes spendable. </p>
<p dir=3D"ltr">So there is two outcomes - either the customer or the notary=
pays the seller. The customer can't force a doublespend. The notary ca=
n't steal or freeze funds (due to nlocktime fund recovery option). The =
seller knows he'll get the funds for sure before delivering the goods. =
Nobody is at risk. </p>
--089e0122e8b6fc80de050ee3ba22--
|
