Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CF9F4B7D for ; 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 ; Tue, 13 Aug 2019 02:11:37 +0000 (UTC) Received: by mail-ua1-f46.google.com with SMTP id c4so14162716uad.1 for ; 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: <20190812150110.yf76pq47e5oszx62@petertodd.org> In-Reply-To: <20190812150110.yf76pq47e5oszx62@petertodd.org> From: Bryan Bishop Date: Mon, 12 Aug 2019 21:09:43 -0500 Message-ID: To: Peter Todd , Bryan Bishop 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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
On Mon, Aug 12, 2019 at 10:01 AM Peter To= dd <pete@petertodd.org> wro= te:
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 transac= tion.

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 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're = lucky, observe an unexpected signature otherwise unassociated with a transa= ction.
=C2=A0
> * Nuclear abort key: Also unnecessary. This is a key for which only a = single=C2=A0
= =C2=A0
Obviously normally to provably destroy coins you'd spend to an OP_RETUR= N
output, or if miner censorship was an issue, a pay-to-script-hash of an
OP_RETURN <nonce> script.

Oh, right. Well, t= hat works.
=C2=A0
> Delete the key (for pre-signed transactions)
> =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
>
> The delete-the-key trick is simple. The idea is to pre-sign at least o= ne
> transaction and then delete the private key, thus locking in that cour= se of
> action.
>
> Unfortunately, delete-the-key doesn't really work for multisig sce= narios
> 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 ful= l unilateral
> control to sign anything in that branch of the transaction tree. The o= nly time
> that delete-the-key might be appropriate would be where the user who d= eletes
> 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, co= mpared 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 f= or each
> alternative fee rate. With delete-the-key, the alternative fee rates a= re 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 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.
=C2=A0<= /div>
> Multisig gated by ECDSA pubkey recovery for provably-unknown keys
> =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
>
> A group can participate in a multisig scheme with provably-unknown ECD= SA 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 tran= saction
> 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 blockh= ash?

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

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