Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B3E77A55
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 18 May 2019 17:51:23 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch
	[185.70.40.136])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0488A5E4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 18 May 2019 17:51:22 +0000 (UTC)
Date: Sat, 18 May 2019 17:51:16 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
	s=default; t=1558201880;
	bh=QiNy0v9pJNuKB0JobC5/qHISXZoEMMYo5aBgweqw7wA=;
	h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
	Feedback-ID:From;
	b=XsphDDPCFYFlzJsW/6tOIkPxkYZv0XNpHuIcxsyYS5E/fUmOno1M4mvyyXjDimT5l
	56nJvZC3W8r7QWedR582r7K0wePz5Exj7+VVVpDNC9/n7z9qdLfPJXEDon5n15Kdgc
	93bq8xCej4nLoxhJncWL7N0pM7q1zlXTy73baLTI=
To: Pieter Wuille <pieter.wuille@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Gregory Maxwell <greg@xiph.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <wsHT3V-IhjJLoWYTdS1MHucmq64qr_uUnYruU-mANVEMackqpTdulxCRV_w92zaXlfRvBrL8Dll3wu4g4H-GDp3Rqjv9RhM3yaEk_xXFs4g=@protonmail.com>
In-Reply-To: <CAPg+sBjqgyu=Do-8P=7Q1S3tehr30K58=o_SokAE7H_SP-pf8g@mail.gmail.com>
References: <CAPg+sBg6Gg8b7hPogC==fehY3ZTHHpQReqym2fb4XXWFpMM-pQ@mail.gmail.com>
	<201905062017.11396.luke@dashjr.org>
	<34827F16-9061-4317-B91F-250734850EE6@sprovoost.nl>
	<CAPg+sBjqgyu=Do-8P=7Q1S3tehr30K58=o_SokAE7H_SP-pf8g@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
	RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 18 May 2019 18:00:32 +0000
Subject: Re: [bitcoin-dev] Taproot proposal
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 18 May 2019 17:51:23 -0000

Good morning list,


> > 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 kno=
wing that it's possible is useful.
>
> Yes, that's a TODO that's left in the draft, but this is absolutely
> possible (using a hash-to-curve operation). As ZmnSCPxj already
> suggested, there can even be a fixed known constant you can use for
> this. However, you get better privacy by taking this fixed known
> constant (call it C) and using as internal key a blinded version of it
> (C+rG, for some random value r, and G the normal secp256k1 generator);
> as long as the DL between G and C is unknown, this is safe (and does
> not reveal to the world that in fact no key-path was permitted when
> spending).

Gregory Maxwell commented some days ago:

> 2019-05-11T23:35:02  <gmaxwell> sipa: also someone might want to point ou=
t to ZmnSCPxj  that his scheme for getting a NUMS point is insecure (it mus=
t also commit to G because we don't know how G was generated)

I am assuming that gmax is referring to my description of the "hash-to-poin=
t" or "hash-to-curve" operation.

A little more research shows this: https://crypto.stackexchange.com/a/25603

From the above, it seems the method that real cryptographers use is:

1.  Generate some random data d.
2.  Get x =3D h(G | d) where G is the existing generator for secp256k1.
3.  Find a point on secp256k1 with X coordinate x.
4.  If not found, go to 1.

In any case, I am almost sure that for every case where the "everyone agree=
s" path is unwanted in a taproot address, the simple "put your own pubkey l=
ock on the door and throw away the privkey" technique would work without re=
quiring a NUMS point: the same taproot assumption should also work here.
But generation of a NUMS point might be of independent interest in any case=
 (e.g. setting up Pedersen commitments).

Regards,
ZmnSCPxj