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

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.. On 11 Feb 2016 20:05, "Tier Nolan via bitcoin-dev" < bitcoin-dev@lists•linuxfoundation•org> wrote:

> 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>
> <#-1229186329_DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

On Thu, Feb 11, 2016 at 10:20 PM, Thomas Kerin <thomas.kerin@gmail•com> wrote:

> 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>

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

On Fri, Feb 12, 2016 at 5:02 AM, <jl2012@xbt•hk> wrote:

> Seems it could be done without any new opcode:
>

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.

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 <bitcoin-dev@lists•linuxfoundation•org>:

> On Fri, Feb 12, 2016 at 5:02 AM, <jl2012@xbt•hk> wrote:
>>
>> Seems it could be done without any new opcode:
>
>
> 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
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

On Mon, Feb 29, 2016 at 10:58 AM, Mats Jerratsch <matsjj@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.

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

On Mon, Feb 29, 2016 at 10:58 AM, Mats Jerratsch <matsjj@gmail•com <mailto:matsjj@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.