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-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 <tier.nolan@gmail.com>) id 1Wdlwe-0004l5-BV
for bitcoin-development@lists.sourceforge.net;
Fri, 25 Apr 2014 19:38:00 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.192.48 as permitted sender)
client-ip=209.85.192.48; envelope-from=tier.nolan@gmail.com;
helo=mail-qg0-f48.google.com;
Received: from mail-qg0-f48.google.com ([209.85.192.48])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wdlwd-00089R-IG
for bitcoin-development@lists.sourceforge.net;
Fri, 25 Apr 2014 19:38:00 +0000
Received: by mail-qg0-f48.google.com with SMTP id q108so4509897qgd.35
for <bitcoin-development@lists.sourceforge.net>;
Fri, 25 Apr 2014 12:37:54 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.27.212 with SMTP id 78mr13556837qgx.18.1398454673910;
Fri, 25 Apr 2014 12:37:53 -0700 (PDT)
Received: by 10.140.25.86 with HTTP; Fri, 25 Apr 2014 12:37:53 -0700 (PDT)
In-Reply-To: <201404251918.44282.luke@dashjr.org>
References: <CAE-z3OVsQAya3RDzMTvKNK4hLGQVjFOp6Bseo=xK4ApOdPCh8g@mail.gmail.com>
<201404251918.44282.luke@dashjr.org>
Date: Fri, 25 Apr 2014 20:37:53 +0100
Message-ID: <CAE-z3OVo9wPbSwfHrpf8bSGWYBR510Q0np6VFfQUZdX3hWoQtA@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a11c14d6612af7704f7e31a1b
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [209.85.192.48 listed in list.dnswl.org]
-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
(tier.nolan[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: 1Wdlwd-00089R-IG
Subject: Re: [Bitcoin-development] BIP - Hash Locked Transaction
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: Fri, 25 Apr 2014 19:38:00 -0000
--001a11c14d6612af7704f7e31a1b
Content-Type: text/plain; charset=UTF-8
On Fri, Apr 25, 2014 at 8:18 PM, Luke-Jr <luke@dashjr.org> wrote:
> This one looks entirely useless (it cannot be made secure)
The hash locking isn't to prevent someone else stealing your coin. Once a
user broadcasts a transaction with x in it, then everyone has access to x.
It is to release the coin on the other chain. If you spend the output, you
automatically give the other participant the password to take your coin on
the other chain (completing the trade).
The BIP allows the hash to protect any of other standard transactions
(except P2SH, since that is a template match).
For example, it would allow a script of the form
OP_HASH160 [20-byte-password-hash] OP_EQUAL_VERIFY OP_DUP OP_HASH160
<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
To spend it, you would need to provide the password and also sign the
transaction using the private key.
> and the assertion
> that it is necessary for atomic cross-chain transfers seems unfounded and
> probably wrong...
>
>
I meant that it is required for the particular protocol.
> Luke
>
--001a11c14d6612af7704f7e31a1b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Apr 25, 2014 at 8:18 PM, Luke-Jr <span dir=3D"ltr"><<a href=3D"mailt=
o:luke@dashjr.org" target=3D"_blank">luke@dashjr.org</a>></span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">
This one looks entirely useless (it cannot be made secure)</blockquote><div=
><br></div>The hash locking isn't to prevent someone else stealing your=
coin.=C2=A0 Once a user broadcasts a transaction with x in it, then everyo=
ne has access to x.<br>
<br></div><div class=3D"gmail_quote">It is to release the coin on the other=
chain.=C2=A0 If you spend the output, you automatically give the other par=
ticipant the password to take your coin on the other chain (completing the =
trade).<br>
</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">The B=
IP allows the hash to protect any of other standard transactions (except P2=
SH, since that is a template match).<br><br></div><div class=3D"gmail_quote=
">
For example, it would allow a script of the form<br><br><pre>OP_HASH160 [20=
-byte-password-hash] OP_EQUAL_VERIFY OP_DUP OP_HASH160 <pubKeyHash> O=
P_EQUALVERIFY OP_CHECKSIG
</pre>To spend it, you would need to provide the password and also sign the=
transaction using the private key.<br></div><div class=3D"gmail_quote"></d=
iv><div class=3D"gmail_quote"><div><br>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">
and the assertion<br>
that it is necessary for atomic cross-chain transfers seems unfounded and<b=
r>
probably wrong...<br>
<br></blockquote><div><br></div><div>I meant that it is required for the pa=
rticular protocol.<br></div><div><br>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex">
Luke<br></blockquote></div></div></div>
--001a11c14d6612af7704f7e31a1b--
|
