Seems it could be done without any new opcode:

 

Bob is trading b Bitcoins for a altcoins.

 

1. Bob Pays D Bitcoins to

 

IF

<now+2days> CLTV DROP <Alice PK> CHECKSIG

ELSE

HASH160 <hash secret B> EQUALVERIFY <Bob PK> CHECKSIG

ENDIF

 

2. Alice pays a altcoins to

 

IF

HASH160 <hash secret B> EQUALVERIFY <Alice PK> CHECKSIG

ELSE

HASH160 <hash secret A> EQUALVERIFY <Bob PK> CHECKSIG

ENDIF

 

3. Bob pays b Bitcoins to

 

IF

<now+1days> CLTV DROP <Bob PK> CHECKSIG

ELSE

HASH160 <hash secret A> EQUALVERIFY <Alice PK> CHECKSIG

ENDIF

 

4. Alice claims output from step 3 and reveals secret A

 

5. Bob claims output from step 2

 

6. Bob claims output from step 1 and reveals secret B

 

From: bitcoin-dev-bounces@lists.linuxfoundation.org [mailto:bitcoin-dev-bounces@lists.linuxfoundation.org] On Behalf Of Tier Nolan via bitcoin-dev
Sent: Friday, 12 February, 2016 04:05
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] BIP CPRKV: Check private key verify

 

There was some discussion on the bitcointalk forums about using CLTV for cross chain transfers.

Many altcoins don't support CLTV, so transfers to those coins cannot be made secure.  

I created a protocol.  It uses on cut and choose to allow commitments to publish private keys, but it is clunky and not entirely secure.

I created a BIP draft for an opcode which would allow outputs to be locked unless a private key was published that matches a given public key.


https://github.com/TierNolan/bips/blob/cpkv/bip-cprkv.mediawiki


 <https://www.avast.com/sig-email> 

This email has been sent from a virus-free computer protected by Avast. 
 <https://www.avast.com/sig-email> www.avast.com