path: root/6f/6e7fa5960368e0a10283eabb36a144d11901b1

Return-Path: <kanzure@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id CF9F4B7D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 13 Aug 2019 02:11:38 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua1-f46.google.com (mail-ua1-f46.google.com
	[209.85.222.46])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8925A8B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 13 Aug 2019 02:11:37 +0000 (UTC)
Received: by mail-ua1-f46.google.com with SMTP id c4so14162716uad.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 12 Aug 2019 19:11:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to
	:cc; bh=mLmCvnDB7XCchr1xHDJRiDAVkiqhD5/Nm2eOL5aKY3I=;
	b=B/d5EYQX3nwQWFC67+2lWSVkU+xJA9y88CZUlDNBv1h5pLqFctmWdYJSj/OOjZi6Oy
	nwhMi3rt8xct4zhPEvxhBBNt3MYsSkg6/NfLa3B0DEb1gNeUZ1dFrVsiwI4xW11Hcpdl
	XLF6xHhPVhJC97okvwZkngIJpKm0olr2wgunr63PQA82UURowEFi4bYZeP0VSWpY6DCC
	eoBuolcZmcNrZgeqIkvk1qoobfKVS0QIgNlvKDtZVELAchFQ+YrUrZ73GrGTYg5ors1I
	S0cTW2d0lLuoirbiOWUXUQaBCpPyUv9tDfnFCP0bnB/qytlRbwztufblKATFAzIvoUCO
	+FRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to:cc;
	bh=mLmCvnDB7XCchr1xHDJRiDAVkiqhD5/Nm2eOL5aKY3I=;
	b=ZDwbf5LaHk3nvrZxCMjQvz7xv4/ZBPusH3jTVx+whVxSSedNL6K5zXSOv6A0i8PFtT
	eZX/+NX4Ap4A6zHVdTyURSl+mFeuJyxkY/x2I3abTiEPFth0347itTkxzQ700BuWlv3J
	9pBh3xMcyaKuKCFQlkuKzHZ6K7X0FMTD+rPu/impNwMOg1y7poXNJfgBfDzZilNtES/D
	6+bRMDMxqg3fKzcmQQPOiSDvQ8zLDNa0sXaDejeWP5lOj624KLJOgnPqxktlf4umJI3q
	d/21HwSifZ55O7WA+1kx5W/iyKPT+cUuG8gKYFoNqYrwpED+sFGI44pT6etzx9zcnHA1
	4wXg==
X-Gm-Message-State: APjAAAV2NEuLq2pArzxFGXDNCezP5tEFtwAoQW2RvXNPDCKmz7nuLDrw
	EMw3NHci67D7AkDjUlj66LbwKcVKa3/sWELZBDo=
X-Google-Smtp-Source: APXvYqxSxsvqeiac4crrAPoYyqIAr5m8/29X0shZEEE/7WiySyTjzdSRwdeyDo48OYpFd2H3DqRcfZVAFKVPmgr9eLQ=
X-Received: by 2002:ab0:6911:: with SMTP id b17mr24274213uas.18.1565662296447; 
	Mon, 12 Aug 2019 19:11:36 -0700 (PDT)
MIME-Version: 1.0
References: <CABaSBawe_oF_zoso2RQBX+7OWDoCwC7T2MeKSX9fYRUQaY_xmg@mail.gmail.com>
	<20190812150110.yf76pq47e5oszx62@petertodd.org>
In-Reply-To: <20190812150110.yf76pq47e5oszx62@petertodd.org>
From: Bryan Bishop <kanzure@gmail.com>
Date: Mon, 12 Aug 2019 21:09:43 -0500
Message-ID: <CABaSBawwSEa_dDLEXhWncsqKmsM+rdT2Npo334LEZPvcMzrzFQ@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>, Bryan Bishop <kanzure@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000004a21a058ff62920"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback
	mechanisms
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: Tue, 13 Aug 2019 02:11:38 -0000

--00000000000004a21a058ff62920
Content-Type: text/plain; charset="UTF-8"

On Mon, Aug 12, 2019 at 10:01 AM Peter Todd <pete@petertodd.org> wrote:

> The key difference being it's not important that this be a *public*
> notification: that the public can see just happens to be an (unfortunate)
> implementation detail. For example, you could imagine a system where the
> "prepare to spend" tx is indistinguishable from any other transaction.
>

True, I did not intend for everyone to know the meaning of the observed
transaction. It turns out to not be too useful to the scheme anyway, unless
you're interested in protecting against an adversary dumb enough to tell
you he has stolen your key before spending your coins. To reiterate my
other follow-up email, the best you can do (... or the best I can do right
now) is limit losses to k% where k is selected by the user, e.g. 1 input
100 outputs each with succesively increasing timeouts allowing the rotten
non-rotated(pre-inserted) key to spend, and instant spending by a recovery
flow. Once the attacker steals any one of the k% outputs, you know to not
let the outputs timeout to that key in the future. Unfortunately, without
an opcode-style covenant, the only way to know if a stale hot key is stolen
is to observe an unexpected spend or, if you're lucky, observe an
unexpected signature otherwise unassociated with a transaction.


> > * Nuclear abort key: Also unnecessary. This is a key for which only a
> single


>
Obviously normally to provably destroy coins you'd spend to an OP_RETURN
> output, or if miner censorship was an issue, a pay-to-script-hash of an
> OP_RETURN <nonce> script.
>

Oh, right. Well, that works.


> > Delete the key (for pre-signed transactions)
> > ============================================
> >
> > The delete-the-key trick is simple. The idea is to pre-sign at least one
> > transaction and then delete the private key, thus locking in that course
> of
> > action.
> >
> > Unfortunately, delete-the-key doesn't really work for multisig scenarios
> > because nobody would trust that anyone else in the scheme has actually
> deleted
> > the secret. If they haven't deleted the secret, then they have full
> unilateral
> > control to sign anything in that branch of the transaction tree. The
> only time
> > that delete-the-key might be appropriate would be where the user who
> deletes
> > the key and controls the key during the setup process is also the sole
> > beneficiary of the entire setup with the multisig participants.
> >
> > Alternative fee rates are easier to deal with using delete-the-key,
> compared to
> > a technique where the private key never existed which can only be used
> to sign
> > one fee rate per public key, requiring an entirely new vault subtree for
> each
> > alternative fee rate. With delete-the-key, the alternative fee rates are
> signed
> > with the private key before the private key is deleted.
>
> I think this could use a bit more analysis here: why can't delete the
> *keys*
> work, with each party deleting a separate private key that's used in an
> m-of-n
> fashion? So long as at least n-m+1 parties actually deleted their keys
> IIUC it
> should be secure.
>

I was thinking about another construction where you pick a key as a group
(separate from the multisig setup) and sign with that. But in practice, as
you have pointed out, you would do the delete-the-key trick on the multisig
construction itself with each party contributing their own pubkey,
requiring 1/n honest deletes.


> > Multisig gated by ECDSA pubkey recovery for provably-unknown keys
> > =================================================================
> >
> > A group can participate in a multisig scheme with provably-unknown ECDSA
> keys.
> > Instead of deleting the key, the idea is to agree on a blockheight and
> then
> > select the blockhash (or some function of the chosen blockhash like
> > H(H(H(blockhash)))) as the signature. Next, the group agrees on a
> transaction
> > and they recover the public key from the signature using ECDSA pubkey
> recovery.
>
> Could you explain in more detail why you're deriving this from a blockhash?
>

Well you need to pick an entropy source, and I wouldn't want to tell people
to just trust the first party to tell you a good sequence of bytes.

- Bryan
http://heybryan.org/
1 512 203 0507

--00000000000004a21a058ff62920
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Mon, Aug 12, 2019 at 10:01 AM Peter To=
dd &lt;<a href=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>&gt; wro=
te:</div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">
The key difference being it&#39;s not important that this be a *public*<br>
notification: that the public can see just happens to be an (unfortunate)<b=
r>
implementation detail. For example, you could imagine a system where the<br=
>
&quot;prepare to spend&quot; tx is indistinguishable from any other transac=
tion.<br></blockquote><div><br>True, I did not intend for everyone to know =
the meaning of the observed transaction. It turns out to not be too useful =
to the scheme anyway, unless you&#39;re interested in protecting against an=
 adversary dumb enough to tell you he has stolen your key before spending y=
our coins. To reiterate my other follow-up email, the best you can do (... =
or the best I can do right now) is limit losses to k% where k is selected b=
y the user, e.g. 1 input 100 outputs each with succesively increasing timeo=
uts allowing the rotten non-rotated(pre-inserted) key to spend, and instant=
 spending by a recovery flow. Once the attacker steals any one of the k% ou=
tputs, you know to not let the outputs timeout to that key in the future. U=
nfortunately, without an opcode-style covenant, the only way to know if a s=
tale hot key is stolen is to observe an unexpected spend or, if you&#39;re =
lucky, observe an unexpected signature otherwise unassociated with a transa=
ction.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; * Nuclear abort key: Also unnecessary. This is a key for which only a =
single=C2=A0</blockquote><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
=C2=A0<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Obviously normally to provably destroy coins you&#39;d spend to an OP_RETUR=
N<br>
output, or if miner censorship was an issue, a pay-to-script-hash of an<br>
OP_RETURN &lt;nonce&gt; script.<br></blockquote><div><br>Oh, right. Well, t=
hat works.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
>&gt; Delete the key (for pre-signed transactions)<br>
&gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
&gt; <br>
&gt; The delete-the-key trick is simple. The idea is to pre-sign at least o=
ne<br>
&gt; transaction and then delete the private key, thus locking in that cour=
se of<br>
&gt; action.<br>
&gt; <br>
&gt; Unfortunately, delete-the-key doesn&#39;t really work for multisig sce=
narios<br>
&gt; because nobody would trust that anyone else in the scheme has actually=
 deleted<br>
&gt; the secret. If they haven&#39;t deleted the secret, then they have ful=
l unilateral<br>
&gt; control to sign anything in that branch of the transaction tree. The o=
nly time<br>
&gt; that delete-the-key might be appropriate would be where the user who d=
eletes<br>
&gt; the key and controls the key during the setup process is also the sole=
<br>
&gt; beneficiary of the entire setup with the multisig participants.<br>
&gt; <br>
&gt; Alternative fee rates are easier to deal with using delete-the-key, co=
mpared to<br>
&gt; a technique where the private key never existed which can only be used=
 to sign<br>
&gt; one fee rate per public key, requiring an entirely new vault subtree f=
or each<br>
&gt; alternative fee rate. With delete-the-key, the alternative fee rates a=
re signed<br>
&gt; with the private key before the private key is deleted.<br>
<br>
I think this could use a bit more analysis here: why can&#39;t delete the *=
keys*<br>
work, with each party deleting a separate private key that&#39;s used in an=
 m-of-n<br>
fashion? So long as at least n-m+1 parties actually deleted their keys IIUC=
 it<br>
should be secure.<br></blockquote><div><br>I was thinking about another con=
struction where you pick a key as a group (separate from the multisig setup=
) and sign with that. But in practice, as you have pointed out, you would d=
o the delete-the-key trick on the multisig construction itself with each pa=
rty contributing their own pubkey, requiring 1/n honest deletes.<br>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; Multisig gated by ECDSA pubkey recovery for provably-unknown keys<br>
&gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
&gt; <br>
&gt; A group can participate in a multisig scheme with provably-unknown ECD=
SA keys.<br>
&gt; Instead of deleting the key, the idea is to agree on a blockheight and=
 then<br>
&gt; select the blockhash (or some function of the chosen blockhash like<br=
>
&gt; H(H(H(blockhash)))) as the signature. Next, the group agrees on a tran=
saction<br>
&gt; and they recover the public key from the signature using ECDSA pubkey =
recovery.<br>
<br>
Could you explain in more detail why you&#39;re deriving this from a blockh=
ash?<br></blockquote><div><br>Well you need to pick an entropy source, and =
I wouldn&#39;t want to tell people to just trust the first party to tell yo=
u a good sequence of bytes.=C2=A0</div></div><div><br></div><div dir=3D"ltr=
" class=3D"gmail_signature">- Bryan<br><a href=3D"http://heybryan.org/" tar=
get=3D"_blank">http://heybryan.org/</a><br>1 512 203 0507</div></div>

--00000000000004a21a058ff62920--