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

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

[Tier Nolan]

[-- Attachment #1: Type: text/plain, Size: 723 bytes --]

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>

[-- Attachment #2: Type: text/html, Size: 1492 bytes --]

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

[Thomas Kerin]

[-- Attachment #1: Type: text/plain, Size: 1316 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2474 bytes --]

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

[Tier Nolan]

[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]

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>

[-- Attachment #2: Type: text/html, Size: 1952 bytes --]

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

[jl2012]

[-- Attachment #1: Type: text/plain, Size: 1808 bytes --]

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 

 


[-- Attachment #2: Type: text/html, Size: 9493 bytes --]

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

[Tier Nolan]

[-- Attachment #1: Type: text/plain, Size: 455 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 974 bytes --]

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

[Mats Jerratsch]

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
>

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

[Tier Nolan]

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 946 bytes --]

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

[jl2012]

[-- Attachment #1: Type: text/plain, Size: 1984 bytes --]

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.


[-- Attachment #2: Type: text/html, Size: 7071 bytes --]