Date: Wed, 08 May 2019 04:37:37 +0000
To: Sjors Provoost <sjors@sprovoost.nl>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <2OTGF_pw4RyRk4r84XkFrxdU-wz8m0iRr469ZvlBitshF7K8arSwXkaxdmL-GjTatYbU8DcgWO2zzM2u3EZ3hhjsCUeKHWu0prFoSUmeRUs=@protonmail.com>
In-Reply-To: <34827F16-9061-4317-B91F-250734850EE6@sprovoost.nl>
References: <CAPg+sBg6Gg8b7hPogC==fehY3ZTHHpQReqym2fb4XXWFpMM-pQ@mail.gmail.com>
	<201905062017.11396.luke@dashjr.org>
	<34827F16-9061-4317-B91F-250734850EE6@sprovoost.nl>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Pieter Wuille <pieter.wuille@gmail.com>
Subject: Re: [bitcoin-dev] Taproot proposal
Precedence: list

Good morning Sjors,


Sent with ProtonMail Secure Email.

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Wednesday, May 8, 2019 4:42 AM, Sjors Provoost via bitcoin-dev <bitcoin-=
dev@lists.linuxfoundation.org> wrote:

> Hey Pieter,
>
> I think this is a reasonable collection of changes that make sense in com=
bination. Some initial feedback and questions.
>
> From the BIP:
>
> > If one or more of the spending conditions consist of just a single key =
(after aggregation),
> > he most likely one should be made the internal key. If no such conditio=
n exists, it may
> > be worthwhile adding one that consists of an aggregation of all keys pa=
rticipating in all
> > scripts combined; effectively adding an "everyone agrees" branch. If th=
at is inacceptable,
> > pick as internal key a point with unknown discrete logarithm (TODO).
>
> I assume Luke Dashjr referred to the above when saying:
>
> > Is there any way to use the Taproot construct here while retaining exte=
rnal
> > script limitations that the involved party(ies) cannot agree to overrid=
e?
> > For example, it is conceivable that one might wish to have an unconditi=
onal
> > CLTV enforced in all circumstances.
>
> One reason why someone would want to avoid a "everone agrees" branch, is =
duress (or self-discipline, or limiting powers of a trustee). In particular=
 with respect to time-locks.
>
> Can this "unknown discrete logarithm" be made provably unknown, so all si=
gners are assured of this property? Bonus points if the outside world can't=
 tell. The exact mechanism could be outside the scope of the BIP, but knowi=
ng that it's possible is useful.

As I understand it, it is possible to take some random data, hash it with S=
HA256 and acquire a 256-bit number.
Then treat that number as an X coordinate (or is it Y...), and see if there=
 exists a point on the secp256k1 curve at that coordinate.
If not, try another random data, or just hash the same number again.
As I understand it, about half the possible X coordinates will have a point=
 on the curve.

I believe this is the "hash to a point" technique.

The scalar behind the above point cannot be known, unless either the hash f=
unction is broken, or ECDLP is broken.
(perhaps a better cryptographer can give the proper qualifications, any cor=
rections, and etc etc)

As the point is just an arbitrary point on the curve, it is unknown to the =
rest of the world whether somebody knows the scalar, or nobody knows.

>
> Perhaps Lightning devs have an opinion on "everyone agrees" with respect =
to hash pre-images. I suspect there is no benefit in guaranteeing that a pr=
e-image must be revealed or a timeout must be waited for and there's no way=
 around that condition.

The "everyone agrees" branch in Lightning is basically the "cooperative clo=
se" of the channel.
So it is not likely we will need an "everyone agrees" branch in the actual =
HTLCs we transfer *within* the channel.
So if we need to use hashes still, we will likely use the "hash to a point"=
 technique above.

Or just use pubkeys given by both participants, that should be enough to en=
sure the "everyone agrees" branch is never taken if we write our software s=
uch that we never agree to sign with it (i.e. just get points from both sid=
es and MuSig them; then each side can just erase the scalar generating it f=
rom memory and whatever caches exist on the system; a node might even just =
generate a single random point from a scalar it subsequently erases, and ju=
st use some non-hardened derivation path from that for every HTLC it has to=
 make).
This technique is "sufficiently provably unknown" since each participant kn=
ows that it deliberately erased the only means of knowing the complete disc=
rete log by erasing its share.
In short, "everyone agrees" is trivially easy to make "nobody can agree" by=
 a single participant never agreeing to let itself be ripped off.

Do note that it is likely Lightning will eventually switch to using payment=
 points/scalars instead of hashes/preimages.
This will allow us to have path decorrelation, both within a route, and in =
multiple routes of the same payment.
This is enabled by Schnorr, as this requires Scriptless Script.
(granted 2p-ECDSA also enables Scriptless Script, but we decided to wait fo=
r Schnorr to hit base layer instead)
This means we would be using the "everyone agrees" path only, with everyone=
 agreeing to first create a `nLockTime` backout tx, then everyone agreeing =
to create a transaction where one side has knowledge of a secret scalar tha=
t is learned by the other side upon completion of the signature.

Regards,
ZmnSCPxj