[bitcoin-dev] BIP CPRKV: Check private key verify

[Tier Nolan via bitcoin-dev]

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.
www.avast.com <https://www.avast.com/sig-email>
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

[Tier Nolan via bitcoin-dev]

I wonder if this is possible as a soft fork without using segwit?

Increasing the sigop count for a NOP would be a hard fork, but such a
change would be fine with a new segwit version. It might require specific
support in the altcoin, which might be troublesome..

It is a soft fork since it makes things that were previous allowed
disallowed. If it decreased the sigop count, then you could create a block
that had to many sigops due to the old rules.

With this rule, it increases the count. If the sigop count is valid under
the new rules, it is also valid under the old rules.

There is no need for specific support on the altcoin. It allows the
Bitcoin network act as trusted 3rd party so that you can do channels safely
on the altcoin, even though the altcoin still suffers from malleability and
doesn't have OP_CHECKLOCKTIMEVERIFY.

With regards to seg-witness, Ideally, the opcode would work in both old and
new scripts by re-purposing OP_NOP3.
<https://www.avast.com/sig-email> This email has been sent from a
virus-free computer protected by Avast.
www.avast.com <https://www.avast.com/sig-email>
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

[jl2012--- via bitcoin-dev]

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-***@lists.linuxfoundation.org [mailto:bitcoin-dev-***@lists.linuxfoundation.org] On Behalf Of Tier Nolan via bitcoin-dev
Sent: Friday, 12 February, 2016 04:05
To: Bitcoin Dev <bitcoin-***@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

[Tier Nolan via bitcoin-dev]

The assumption was that the altcoin would only accept standard output
scripts. Alice's payment in step 2 pays to a non-standard script.

This is an improvement over the cut and choose, but it will only work for
coins which allow non-standard scripts (type 2 in the BIP).

I guess I was to focused on maintaining standard scripts on the altcoin.

[Mats Jerratsch via bitcoin-dev]

This is actually very useful for LN too, see relevant discussion here

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011827.html

2016-02-12 11:05 GMT+01:00 Tier Nolan via bitcoin-dev

Post by Tier Nolan via bitcoin-dev
The assumption was that the altcoin would only accept standard output
scripts. Alice's payment in step 2 pays to a non-standard script.
This is an improvement over the cut and choose, but it will only work for
coins which allow non-standard scripts (type 2 in the BIP).
I guess I was to focused on maintaining standard scripts on the altcoin.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Tier Nolan via bitcoin-dev]

Post by Mats Jerratsch via bitcoin-dev
This is actually very useful for LN too, see relevant discussion here
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011827.html

Is there much demand for trying to code up a patch to the reference
client? I did a basic one, but it would need tests etc. added.

I think that segregated witness is going to be using up any potential
soft-fork slot for the time being anyway.

[jl2012--- via bitcoin-dev]

I just realize that if we have OP_CAT, OP_CHECKPRIVATEKEYVERIFY (aka OP_CHECKPRIVPUBPAIR) is not needed (and is probably better for privacy)



Bob has the prikey-x for pubkey-x. Alice and Bob will agree to a random secret nonce, k. They calculate r, in the same way as signing a transaction.



The script is:



SIZE <r-length + 1> ADD <0x30> SWAP CAT <0x02|r-length|r> CAT SWAP CAT <pubkey-x> CECHKSIGVERIFY <Bob pubkey hash> CHECKSIG



To redeem, Bob has to provide:



<Bob sig> <0x02|s-length|s|sighashtype>



With k, s and sighash, Alice (and only Alice) can recover the prikey-x with the well-known k-reuse exploit

( https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm )



The script will be much cleaner if we remove the DER encoding in the next generation of CHECKSIG



The benefit is prikey-x remains a secret among Alice and Bob. If they don’t mind exposing the prikey-x, they could use r = x coordinate of pubkey-x, which means k = prikey-x (https://bitcointalk.org/index.php?topic=291092.0) This would reduce the witness size a little bit as a DUP may be used



From: bitcoin-dev-***@lists.linuxfoundation.org [mailto:bitcoin-dev-***@lists.linuxfoundation.org] On Behalf Of Tier Nolan via bitcoin-dev
Sent: Monday, 29 February, 2016 19:53
Cc: Bitcoin Dev <bitcoin-***@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP CPRKV: Check private key verify



On Mon, Feb 29, 2016 at 10:58 AM, Mats Jerratsch <***@gmail.com <mailto:***@gmail.com> > wrote:

This is actually very useful for LN too, see relevant discussion here

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011827.html



Is there much demand for trying to code up a patch to the reference client? I did a basic one, but it would need tests etc. added.

I think that segregated witness is going to be using up any potential soft-fork slot for the time being anyway.