<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 30, 2014 at 7:59 PM, Luke Dashjr <span dir="ltr"><<a href="mailto:luke@dashjr.org" target="_blank">luke@dashjr.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Instead of TX0, TX1, etc, can you put some kind of meaningful identifier for<br>
these transactions?<br></blockquote><div><br></div><div>Sorry, that is the names come from the original thread, where I was outlining the idea. I updated the names.<br></div><div> <br></div><blockquote class="gmail_quote" style="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<br>
parties.</blockquote><div><br></div><div>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.<br><br></div><div>There is a malleability risk though, hence the need for the 3rd party.<br>
<br></div><div>It works on the same refund principle as payment channels.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> After TX0 is signed, but before TX2 is signed, either party could<br>
walk away or otherwise hold the funds hostage. The sequence of signing<br>
proposed in this BIP is *not possible to perform*. </blockquote><div><br></div><div>TX0 is not broadcast until the refund transactions are complete.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
How did you implement and test this? :/<br></blockquote><div><br></div><div>This is a draft at the moment. <br><br>There is an implementation of (almost) this system but not by me. This proposal reduces the number of non-standard transaction types required.<br>
<br></div><div>A full implement is the next step.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What is the purpose of the OP_EQUAL_VERIFY in TX4? I don't see a use...<br></blockquote><div><br></div><div>That is a typo, I have updated it.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
IMO, there should be separate BIPs for the exchange itself, and the protocol<br>
to negotiate the exchange. </blockquote><div><br></div><div>I can do that.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I would recommend changing the latter from JSON-RPC<br>
to some extension of the Payment Protocol, if possible.<br></blockquote><div><br></div><div>I wanted it to be as simple as possible, but I guess MIME is just a different way of doing things.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Perhaps it would be good to only support compressed keys, to discourage use of<br>
uncompressed ones..<br></blockquote><div><br></div><div>I would have no objection.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Luke<br>
</font></span></blockquote></div><br></div></div>