From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WfbQO-0007bn-W5 for bitcoin-development@lists.sourceforge.net; Wed, 30 Apr 2014 20:48:17 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.172 as permitted sender) client-ip=209.85.216.172; envelope-from=tier.nolan@gmail.com; helo=mail-qc0-f172.google.com; Received: from mail-qc0-f172.google.com ([209.85.216.172]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WfbQO-0000om-29 for bitcoin-development@lists.sourceforge.net; Wed, 30 Apr 2014 20:48:16 +0000 Received: by mail-qc0-f172.google.com with SMTP id i8so2506596qcq.17 for ; Wed, 30 Apr 2014 13:48:10 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.224.67.195 with SMTP id s3mr8807452qai.96.1398890890579; Wed, 30 Apr 2014 13:48:10 -0700 (PDT) Received: by 10.140.25.86 with HTTP; Wed, 30 Apr 2014 13:48:10 -0700 (PDT) In-Reply-To: <201404301859.07833.luke@dashjr.org> References: <201404301859.07833.luke@dashjr.org> Date: Wed, 30 Apr 2014 21:48:10 +0100 Message-ID: From: Tier Nolan To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a11c322769cda2d04f848aa47 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 (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: 1WfbQO-0000om-29 Subject: Re: [Bitcoin-development] BIP Draft: Atomic Cross Chain Transfer Protocol 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: Wed, 30 Apr 2014 20:48:17 -0000 --001a11c322769cda2d04f848aa47 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 30, 2014 at 7:59 PM, Luke Dashjr wrote: > Instead of TX0, TX1, etc, can you put some kind of meaningful identifier > for > these transactions? > Sorry, that is the names come from the original thread, where I was outlining the idea. I updated the names. > TX1 and TX2 *cannot* be signed until after TX0 is completely signed by both > parties. The bail in transactions are only signed by one of the parties. They are kept secret until the refund/payout transactions are all properly signed. There is a malleability risk though, hence the need for the 3rd party. It works on the same refund principle as payment channels. After TX0 is signed, but before TX2 is signed, either party could > walk away or otherwise hold the funds hostage. The sequence of signing > proposed in this BIP is *not possible to perform*. TX0 is not broadcast until the refund transactions are complete. > How did you implement and test this? :/ > This is a draft at the moment. There is an implementation of (almost) this system but not by me. This proposal reduces the number of non-standard transaction types required. A full implement is the next step. > What is the purpose of the OP_EQUAL_VERIFY in TX4? I don't see a use... > That is a typo, I have updated it. > IMO, there should be separate BIPs for the exchange itself, and the > protocol > to negotiate the exchange. I can do that. > I would recommend changing the latter from JSON-RPC > to some extension of the Payment Protocol, if possible. > I wanted it to be as simple as possible, but I guess MIME is just a different way of doing things. > > Perhaps it would be good to only support compressed keys, to discourage > use of > uncompressed ones.. > I would have no objection. > > Luke > --001a11c322769cda2d04f848aa47 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 30, 2014 at 7:59 PM, Luke Dashjr <luke@dashjr.org> wro= te:
Instead of TX0, TX1, etc, can you put some kind of meaningful identifier fo= r
these transactions?

Sorry, that is the = names come from the original thread, where I was outlining the idea.=C2=A0 = I updated the names.
=C2=A0
TX1 and TX2 *cannot* be signed until after TX0 is completely signed by both=
parties.

The bail in transactions are only = signed by one of the parties.=C2=A0 They are kept secret until the refund/p= ayout transactions are all properly signed.

There is a ma= lleability risk though, hence the need for the 3rd party.

It works on the same refund principle as payment channels.

After TX0 is signed= , but before TX2 is signed, either party could
walk away or otherwise hold the funds hostage. The sequence of signing
proposed in this BIP is *not possible to perform*.

TX0 is not broadcast until the refund transactions are complete.
=C2=A0
How did you implement and test this? :/

This is a draft at the moment.=C2=A0

There is an implementation of= (almost) this system but not by me.=C2=A0 This proposal reduces the number= of non-standard transaction types required.

A full implement is the next step.
=C2=A0
<= /div>
What is the purpose of the OP_EQUAL_VERIFY in TX4? I don't see a use...=

That is a typo, I have updated it.
=
=C2=A0
IMO, there should be separate BIPs for the exchange itself, and the protoco= l
to negotiate the exchange.

I can do that.<= br>
=C2=A0
I would recommend = changing the latter from JSON-RPC
to some extension of the Payment Protocol, if possible.

I wanted it to be as simple as possible, but I guess MIME = is just a different way of doing things.

Perhaps it would be good to only support compressed keys, to discourage use= of
uncompressed ones..

I would have no obj= ection.
=C2=A0

Luke

--001a11c322769cda2d04f848aa47--