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 ) 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 ; 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: <201404251918.44282.luke@dashjr.org> Date: Fri, 25 Apr 2014 20:37:53 +0100 Message-ID: From: Tier Nolan To: Bitcoin Dev 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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
On F= ri, Apr 25, 2014 at 8:18 PM, Luke-Jr <luke@dashjr.org> wrote:<= br>
This one looks entirely useless (it cannot be made secure)

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.

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).

The B= IP allows the hash to protect any of other standard transactions (except P2= SH, 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> O=
P_EQUALVERIFY OP_CHECKSIG
To spend it, you would need to provide the password and also sign the= transaction using the private key.

=C2=A0
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 pa= rticular protocol.

=C2=A0
Luke
--001a11c14d6612af7704f7e31a1b--