From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WfdWc-0006sV-JM for bitcoin-development@lists.sourceforge.net; Wed, 30 Apr 2014 23:02:50 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.192.53 as permitted sender) client-ip=209.85.192.53; envelope-from=tier.nolan@gmail.com; helo=mail-qg0-f53.google.com; Received: from mail-qg0-f53.google.com ([209.85.192.53]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WfdWZ-00067y-54 for bitcoin-development@lists.sourceforge.net; Wed, 30 Apr 2014 23:02:50 +0000 Received: by mail-qg0-f53.google.com with SMTP id f51so1945461qge.12 for ; Wed, 30 Apr 2014 16:02:41 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.48.13 with SMTP id n13mr8989730qga.90.1398898961679; Wed, 30 Apr 2014 16:02:41 -0700 (PDT) Received: by 10.140.25.86 with HTTP; Wed, 30 Apr 2014 16:02:41 -0700 (PDT) In-Reply-To: References: <201404301859.07833.luke@dashjr.org> Date: Thu, 1 May 2014 00:02:41 +0100 Message-ID: From: Tier Nolan To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a11351cceb00a2404f84a8b25 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: 1WfdWZ-00067y-54 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 23:02:50 -0000 --001a11351cceb00a2404f84a8b25 Content-Type: text/plain; charset=UTF-8 I updated again. The new version only requires non-standard transactions on one of the two networks. Next step is a simple TCP / RPC server that will implement the protocol to trade between testnet and mainnet. Timeouts of much less than 24 hours should be possible now. On Wed, Apr 30, 2014 at 9:48 PM, Tier Nolan wrote: > 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 >> > > --001a11351cceb00a2404f84a8b25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I updated again.

The new version only requires= non-standard transactions on one of the two networks.

Next st= ep is a simple TCP / RPC server that will implement the protocol to trade b= etween testnet and mainnet.=C2=A0 Timeouts of much less than 24 hours shoul= d be possible now.


On Wed,= Apr 30, 2014 at 9:48 PM, Tier Nolan <tier.nolan@gmail.com> wrote:
=
On Wed, Apr 30, 2014 at 7:59 PM,= Luke Dashjr <luke@dashjr.org> wrote:
Instead of TX0, TX1, etc, can you put some kind of meaningful identifier fo= r
these transactions?

Sorry, that i= s the names come from the original thread, where I was outlining the idea.= =C2=A0 I updated the names.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> 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 re= fund/payout transactions are all properly signed.

There i= s a malleability risk though, hence the need for the 3rd party.

It works on the same refund principle as payment channels.

Aft= er 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 compl= ete.
=C2=A0
How did you implement and test this? :/

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

There is an implementat= ion 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
What is the purpose of the OP_EQUAL_VERIFY in TX4? I don't see a use...=

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

I can do = that.
=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 objection.
=C2=A0

Luke


--001a11351cceb00a2404f84a8b25--