* [Bitcoin-development] BIP Draft: Atomic Cross Chain Transfer Protocol
@ 2014-04-30 18:03 Tier Nolan
2014-04-30 18:59 ` Luke Dashjr
0 siblings, 1 reply; 4+ messages in thread
From: Tier Nolan @ 2014-04-30 18:03 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 448 bytes --]
Due to "popular" demand, I have created a BIP for cross chain atomic
transfers.
Unlike the previous version, this version only requires hash locking. The
previous version required a "selector" transaction based on if statements.
OP_HASH160 OP_EQUAL_VERIFY [public key] OP_CHECKSIG
OP_HASH160 OP_EQUAL_VERIFY OP_N [public key 1] ... [public key m]
OP_M OP_CHECK_MULTISIG
https://github.com/TierNolan/bips/blob/bip4x/bip-atom.mediawiki
[-- Attachment #2: Type: text/html, Size: 696 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bitcoin-development] BIP Draft: Atomic Cross Chain Transfer Protocol
2014-04-30 18:03 [Bitcoin-development] BIP Draft: Atomic Cross Chain Transfer Protocol Tier Nolan
@ 2014-04-30 18:59 ` Luke Dashjr
2014-04-30 20:48 ` Tier Nolan
0 siblings, 1 reply; 4+ messages in thread
From: Luke Dashjr @ 2014-04-30 18:59 UTC (permalink / raw)
To: bitcoin-development
On Wednesday, April 30, 2014 6:03:59 PM Tier Nolan wrote:
> Due to "popular" demand, I have created a BIP for cross chain atomic
> transfers.
>
> https://github.com/TierNolan/bips/blob/bip4x/bip-atom.mediawiki
Instead of TX0, TX1, etc, can you put some kind of meaningful identifier for
these transactions?
TX1 and TX2 *cannot* be signed until after TX0 is completely signed by both
parties. 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*. How did you implement and
test this? :/
What is the purpose of the OP_EQUAL_VERIFY in TX4? I don't see a use...
IMO, there should be separate BIPs for the exchange itself, and the protocol
to negotiate the exchange. I would recommend changing the latter from JSON-RPC
to some extension of the Payment Protocol, if possible.
Perhaps it would be good to only support compressed keys, to discourage use of
uncompressed ones..
Luke
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bitcoin-development] BIP Draft: Atomic Cross Chain Transfer Protocol
2014-04-30 18:59 ` Luke Dashjr
@ 2014-04-30 20:48 ` Tier Nolan
2014-04-30 23:02 ` Tier Nolan
0 siblings, 1 reply; 4+ messages in thread
From: Tier Nolan @ 2014-04-30 20:48 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1789 bytes --]
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
> 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
>
[-- Attachment #2: Type: text/html, Size: 3479 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bitcoin-development] BIP Draft: Atomic Cross Chain Transfer Protocol
2014-04-30 20:48 ` Tier Nolan
@ 2014-04-30 23:02 ` Tier Nolan
0 siblings, 0 replies; 4+ messages in thread
From: Tier Nolan @ 2014-04-30 23:02 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2239 bytes --]
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 <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
>> 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
>>
>
>
[-- Attachment #2: Type: text/html, Size: 4323 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-04-30 23:02 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-30 18:03 [Bitcoin-development] BIP Draft: Atomic Cross Chain Transfer Protocol Tier Nolan
2014-04-30 18:59 ` Luke Dashjr
2014-04-30 20:48 ` Tier Nolan
2014-04-30 23:02 ` Tier Nolan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox