From uSEkaCIO at protonmail.com  Tue Nov 12 07:32:11 2019
From: uSEkaCIO at protonmail.com (uSEkaCIO)
Date: Tue, 12 Nov 2019 07:32:11 +0000
Subject: [Lightning-dev] Payment points without 2p-ECDSA or Schnorr
In-Reply-To: <a0sWidgzzUWn31HiGecGjRZHpToJzmtWz7d1G1sGd4RaDNFm91UoIo2OiuM509_apdKaseHZwazGPYZnPVloE7_UNIytAX8tKRGhXQvpZIA=@protonmail.com>
References: <_KbzEbn5pk8opY2EV9H0EVRK-sYbj4npR3pWg6CpTHGP98YvAPU1xVm-Q71ZAolkESDvEXNppRtU4jrpordkUy6jQQAzzn-xltFxS3cSx2A=@protonmail.com>
	<a0sWidgzzUWn31HiGecGjRZHpToJzmtWz7d1G1sGd4RaDNFm91UoIo2OiuM509_apdKaseHZwazGPYZnPVloE7_UNIytAX8tKRGhXQvpZIA=@protonmail.com>
Message-ID: <_EbeLaKjYh8JaJD4U8qZMUcjcBE5qFIVUmH4Abjmqhdg0Ms2_Z4r96Ti9gnERaIS6rPuyuEzbgnwRI1_mMoxRBsRRdEuAEgcV2TXDrt0R8E=@protonmail.com>

Hi Lisa and ZmnSCPxj,

Lisa,

>?Does the ?additive blinding? scheme andrew lays out here[1] work for this scheme, or is that only a property of Schnorr sigs? (i.e. are disparate Y?s additive across sigs?)?

Yep I think that anything that works with a single joint Schnorr public key can be transformed into the single-signer-ECDSA+OP_CMS form I laid out. Everything works exactly the same except that you have OP_CMS and do single signer adaptor signature rather than a joint adaptor signature.

ZmnSCPxj,

>?I believe ajtowns has a SCRIPT useable today that enables payment points as well, using 3 `OP_CODESEPARATOR`s. This was rejected in the Adelaide meeting in 2018, I believe partly because `OP_CODESEPARATOR` is difficult enough to understand by itself, and having a SCRIPT that used 3 of them was an even bigger difficulty. Another is that it required three different signatures in the witness as well, if my memory serves correctly.

Ahh so that's what was meant by "script magic" in those threads. I thought it meant adding a new opcode. I found references?[1,2]?which discuss the idea. This is very clever. I had never seen OP_CODESEPARATOR usefully before. It looks like it actually requires six signatures in total (3 OP_CMS). The other downside is it would let you identify the payment point from the transaction.

Aside from not revealing the payment point on-chain, my proposal also has the advantage of taking less witness data than the current spec without adding much complexity. Though how much will depend on how you do revocation. One simple thing that could work would be for Alice to simply reveal the private key for her public key in the OP_CMS to Bob (and for Bob to reveal B on his side). In other words on Alice's state she has a OP_CMS(A,B) output and on Bob's state he has OP_CMS(A',B') output. To revoke her state Alice reveals the private key for A to Bob and to revoke on Bob's side Bob reveals the private key for B'.

Cheers,

USEkaCIO

[1] https://bitcoin.stackexchange.com/questions/85936/bitcoin-scripts-that-force-disclosure-of-the-private-key
[2] https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000344.html


Sent with ProtonMail Secure Email.

??????? Original Message ???????
On Tuesday, 12 November 2019 01:01, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Good morning uSEkaCIO,
>
> This is certainly interesting, though I lack the mathematical background to double-check this.
>
> I believe ajtowns has a SCRIPT useable today that enables payment points as well, using 3 `OP_CODESEPARATOR`s.
> This was rejected in the Adelaide meeting in 2018, I believe partly because `OP_CODESEPARATOR` is difficult enough to understand by itself, and having a SCRIPT that used 3 of them was an even bigger difficulty.
> Another is that it required three different signatures in the witness as well, if my memory serves correctly.
>
> Regards,
> ZmnSCPXj
>
> > Hi list,
> > It is generally believed that in order to do "payment points" we need either the two party multisignature scheme 2p-ECDSA or 2p-Schnorr.
> > I think we can do it without them.
> > TL;DR Just use 2-of-2 OP_CHECKMULTISIG and do a single signer ECDSA adaptor signature on one of the keys.
> > Background
> >
> > There are many nice features that could be enabled by using "payment points" instead of hashes as the core lock mechanism for lightning as discussed in the threads below. The consensus from these threads seems to be that it is best to wait for BIP-Schnorr/Taporoot to hit (which could be years away) than to try and implement and specify a 2p-ECDSA protocol (which I think is very wise).
> > March'17:? Andrew demonstrates scripltess lightning:??https://lists.launchpad.net/mimblewimble/msg00086.html
> > Apr'18:? Pedro shows you can do it for ECDSA:?https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001221.html?
> > Nov'18: Long discussion on the impact of scriptless scripts:?https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001489.html
> > Oct'19: ZmnSCPxj shares thoughts on the choice between 2p-ECDSA and waiting for Schnorr:?https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002211.html
> > The core idea I will present is that the 2pECDSA adaptor signature Pedro and Aniket introduced can be applied to?single signer ECDSA and OP_CHECKMULTISIG can fill the gap.
> > Payment points today, without 2p-ECDSA, Hip hip Hoorayy!
> >
> > Here's how to create the core discrete log based lock required to do payment points without a proper multisignature scheme. Let's say Alice wants to give Bob 1 BTC if he can reveal y, the discrete log of Y to her.
> >
> > 1.  Alice tells Bob about her public key A, her 1 BTC input and her refund address
> >
> > 2.  Bob tells Alice about his public key B and his redeem address
> >
> > 3.  They both can calculate the txid of the fund transaction which spends Alice's inputs to an OP_CHECKMULTISIG 2-of-2 with A B as the keys
> >
> > 4.  Bob also sends to Alice a signature under B on a refund transaction spending the OP_CMS output to her refund address
> >
> > 5.  Alice sends an adaptor signature under A with "auxiliary point" Y on the redeem transaction which spends the OP_CMS output to Bob's redeem address
> >
> > 6.  Bob completes the adaptor signature under A with y and makes his own signature on the redeem tx under B and broadcasts it.
> >
> > 7.  Alice sees the redeem tx and her completed signature and extracts y from it.
> >     Note that Y or y never go on-chain, all anyone sees is a plain 2-of-2 OP_CMS.
> >     Single Signer ECDSA adaptor signatures
> >
> >
> > For the completeness of this post I'll show my version of the single signer ECDSA adaptor algorithms (please verify). This is just a single signer protocol translated from Pedro and Aniket's original work. The only semi-exotic thing is the DLEQ proof. A description of the interactive protocol can be found inhttps://cs.nyu.edu/courses/spring07/G22.3220-001/lec3.pdf (and can be made non-interactive by Fiat-Shamir transform).
> > // Sign such that y = DLOG(Y) is needed to complete signature
> > AdaptorSign((x,X),Y,m):
> >
> > 1.  Choose k randomly, R' = k*G
> >
> > 2.  R = k*Y;
> >
> > 3.  proof = DLEQ_prove((G,R'),(Y, R))
> >
> > 4.  s' = k??(H(m) + x_coord(R)x)
> >
> > 5.  return (R, R', s', proof)
> >     // Verify Adaptor signature is correct for the given message and keys
> >     AdaptorVerify(X, Y, m , (R, R', s', proof))
> >
> > 6.  DLEQ_verify((G,R'),(Y, R))
> >
> > 7.  return x_coord(R') == x_coord(s'??(H(m) * G + x_coord(R) * X))
> >     // Complete the adaptor with the secret
> >     AdaptorComplete(y, (R, R', s', proof))
> >     s = s'y??
> >     return (x_coord(R),s)
> >     // Extract y from the completed adaptor
> >     AdaptorExtract(s',s, Y)
> >     y' = s??s'
> >     return y' * G == -Y ? -y : y; // Deal with ECDSA malleability
> >     Security
> >
> >
> > I am doing a security analysis on this scheme in a paper that will be in review soon (which is why I am posting this anonymously). Unlike in 2pECDSA case, the DLEQ NIZK proof is the only proof required. However, there is one flaw in scheme that I should warn about: from the ECDSA adaptor signature you can calculate the Diffie-Hellman key between the signer's key X and the auxiliary point Y e.g xY = yX (to see this start with s'*R and go from there). Therefore care should be taken when composing this with any scheme that relies on the Computational Diffie-Hellman assumption. In practice, I don't know of any proposal that would be affected by this. Keep in mind that X and Y are usually both transient keys and so learning a DDH keys doesn't help an attacker at all.
> > Discussion
> >
> > Using this scheme I think it's possible to do anything you can do with 2p-ECSA/Schnorr scriptless scripts except that instead of a normal p2pkh/public key output you have a 2-of-2 OP_CMS P2WSH output. Aside from this the scheme has some nice advantages:
> >
> > 1.  The key exchange protocol is far simpler than 2pECDSA and simpler even than 2pSchnorr. This makes it a natural step up in complexity from the current HTLCs towards Schnorr (2pECDSA is like 5 steps up in complexity and then 3 down towards Schnorr).
> >
> > 2.  Because of its simplicity it is much easier to specify -- A single BOLT spec could cover the key generation, transaction structure and signing without too much pain (actually trying to write and review the spec for 2pECDSA would take far longer)
> >
> > 3.  The actual transaction structure can be moved towards the ideal Schnorr based endpoint (i.e. almost completely scriptless except for OP_CMS) or you could even keep the transaction structure the same as it is today and just replace the pre-image spending path in script with OP_CMS
> >     I think this is practical but there are still a number of ways you could go about it so I'd be interested to hear your thoughts. Any feedback on this would be greatly appreciated :)
> >     Cheers,
> >     uSEkaCIO
> >
> >
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev