From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Sjors Provoost <sjors@sprovoost•nl>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Cc: Pieter Wuille <pieter.wuille@gmail•com>
Subject: Re: [bitcoin-dev] Taproot proposal
Date: Wed, 08 May 2019 04:37:37 +0000 [thread overview]
Message-ID: <2OTGF_pw4RyRk4r84XkFrxdU-wz8m0iRr469ZvlBitshF7K8arSwXkaxdmL-GjTatYbU8DcgWO2zzM2u3EZ3hhjsCUeKHWu0prFoSUmeRUs=@protonmail.com> (raw)
In-Reply-To: <34827F16-9061-4317-B91F-250734850EE6@sprovoost.nl>
Good morning Sjors,
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
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 combination. 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 condition exists, it may
> > be worthwhile adding one that consists of an aggregation of all keys participating in all
> > scripts combined; effectively adding an "everyone agrees" branch. If that 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 external
> > script limitations that the involved party(ies) cannot agree to override?
> > For example, it is conceivable that one might wish to have an unconditional
> > 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 signers 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 knowing that it's possible is useful.
As I understand it, it is possible to take some random data, hash it with SHA256 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 function is broken, or ECDLP is broken.
(perhaps a better cryptographer can give the proper qualifications, any corrections, 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 pre-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 close" 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 ensure the "everyone agrees" branch is never taken if we write our software such that we never agree to sign with it (i.e. just get points from both sides and MuSig them; then each side can just erase the scalar generating it from 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 just use some non-hardened derivation path from that for every HTLC it has to make).
This technique is "sufficiently provably unknown" since each participant knows that it deliberately erased the only means of knowing the complete discrete 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 for 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 that is learned by the other side upon completion of the signature.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2019-05-08 4:37 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-06 17:57 Pieter Wuille
2019-05-06 20:17 ` Luke Dashjr
2019-05-07 20:42 ` Sjors Provoost
2019-05-08 4:37 ` ZmnSCPxj [this message]
2019-05-08 5:16 ` ZmnSCPxj
2019-05-08 23:06 ` Pieter Wuille
2019-05-18 17:51 ` ZmnSCPxj
2019-05-08 3:44 ` ZmnSCPxj
2019-05-09 16:56 ` Johnson Lau
2019-05-10 5:38 ` ZmnSCPxj
2019-05-08 4:49 ` Anthony Towns
2019-05-08 13:10 ` Luke Dashjr
2019-05-21 17:20 ` Russell O'Connor
2019-05-23 2:06 ` Pieter Wuille
2019-05-23 2:32 ` Russell O'Connor
2019-05-22 14:14 ` John Newbery
2019-09-16 16:18 ` Greg Sanders
2019-09-17 4:09 ` ZmnSCPxj
2019-09-18 21:21 ` Pieter Wuille
2019-06-27 0:08 ` Russell O'Connor
2019-06-28 9:49 ` Anthony Towns
2019-06-28 11:16 ` Russell O'Connor
2019-08-09 14:58 Elichai Turkel
2019-08-09 18:29 ` Pieter Wuille
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='2OTGF_pw4RyRk4r84XkFrxdU-wz8m0iRr469ZvlBitshF7K8arSwXkaxdmL-GjTatYbU8DcgWO2zzM2u3EZ3hhjsCUeKHWu0prFoSUmeRUs=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pieter.wuille@gmail$(echo .)com \
--cc=sjors@sprovoost$(echo .)nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox