path: root/07/e67c50d62c570cbb066ad8f45d5c6f6381122b

Return-Path: <user@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 5040BCCC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 12 Aug 2019 15:01:17 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail148102.authsmtp.net (outmail148102.authsmtp.net
	[62.13.148.102])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 531168B6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 12 Aug 2019 15:01:16 +0000 (UTC)
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
	by punt17.authsmtp.com. (8.15.2/8.15.2) with ESMTP id x7CF1D7g031448;
	Mon, 12 Aug 2019 16:01:13 +0100 (BST)
	(envelope-from user@petertodd.org)
Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com
	[52.5.185.120]) (authenticated bits=0)
	by mail.authsmtp.com (8.15.2/8.15.2) with ESMTPSA id x7CF1BQs051759
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
	Mon, 12 Aug 2019 16:01:12 +0100 (BST)
	(envelope-from user@petertodd.org)
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by petertodd.org (Postfix) with ESMTPSA id 4A72E40148;
	Mon, 12 Aug 2019 15:01:11 +0000 (UTC)
Received: by localhost (Postfix, from userid 1000)
	id 3BD1C21A53; Mon, 12 Aug 2019 11:01:10 -0400 (EDT)
Date: Mon, 12 Aug 2019 11:01:10 -0400
From: Peter Todd <pete@petertodd.org>
To: Bryan Bishop <kanzure@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20190812150110.yf76pq47e5oszx62@petertodd.org>
References: <CABaSBawe_oF_zoso2RQBX+7OWDoCwC7T2MeKSX9fYRUQaY_xmg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="kiqt4ydtqylza5nz"
Content-Disposition: inline
In-Reply-To: <CABaSBawe_oF_zoso2RQBX+7OWDoCwC7T2MeKSX9fYRUQaY_xmg@mail.gmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
X-Server-Quench: 0696ad2f-bd12-11e9-b106-8434971169dc
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZIVwkA IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aAdMdwAUGUATAgsB Am8bWlJeUFx7WGE7 bghPaBtcak9QXgdq
	T0pMXVMcXAIbdx1z Z10eVxh1cgwIeXt3 YUIsXnZSWhUudxBg
	EBpVF3AHZDJpdTIe UEZFfwdXdApNfx5D YwQsGhFYa3VsNCMk
	FAgyOXU9MCtqYA5U XgoKLFRaX08WGiIn Dw8DATVnFEsZRmAv
	LxEoNhYGEU0WLEgo IBwqXVsHORYZCW8W GkxGACZfJkIEXEL/ 
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 52.5.185.120/25
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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
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: Mon, 12 Aug 2019 15:01:17 -0000


--kiqt4ydtqylza5nz
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 07, 2019 at 08:48:06AM -0500, Bryan Bishop via bitcoin-dev wrot=
e:
> Hi,
>=20
> I have a proposal for implementing bitcoin vaults in a way that does not
> require any soft-forks or other software upgrades, although it could bene=
fit
> from SIGHASH_NOINPUT which I'll describe later.
>=20
> I call them pre-signed vaults.
>=20
> Vault definition
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> Here, a vault is defined as a transaction setup scheme that binds both th=
e user
> and the attacker to always using a public observation and delay period be=
fore a
> weakly-secured hot key is allowed to arbitrarily spend coins. This is the=
 same
> definition previously used[1]. During the delay period, there is an oppor=
tunity
> to initiate recovery/clawback which can either trigger deeper cold storage
> parameters or at least reset the delay period to start over again for the=
 same
> keys.

So, I'll point out that I'd describe this a little bit differently:

    The vault is a tx setup scheme that binds coins in such a way that they=
 can
    only be spent via a proof-of-publication *notification*, followed by a =
delay
    period, during which coins can be recovered/clawed back.

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.

> One of the important components of this is the delete-the-key pre-signed
> transaction concept, where only a single transaction is (pre)signed before
> deleting the key. This is basically an emulation of a covenant and enforc=
es a
> certain outcome.

It's important to note the reason this is possible is because any coin boun=
d by
a convenant simply isn't a coin in the normal sense of the word, and is only
acceptable as payment directly if the receiver chooses to accept it.

To use an analogy many others have used, if you owe me $100, it's not
acceptable for you to pay me that $100 by dumping a time-locked safe on my
front lawn containing that $100 unless I've agreed to accept payment that w=
ay.

> * Nuclear abort key: Also unnecessary. This is a key for which only a sin=
gle
> signed transaction will ever exist, and that single transaction will spen=
d to a
> proof-of-burn key like 0x00. This key must be extremely secure, and if th=
ere

So to be clear, you're spending to a proof-of-burn _key_ because of the use=
 of
adapter signatures for multisig? I'm not sure where the 0x00 is coming from
here.

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.

> 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
>=20
> 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.
>=20
> Unfortunately, delete-the-key doesn't really work for multisig scenarios
> because nobody would trust that anyone else in the scheme has actually de=
leted
> the secret. If they haven't deleted the secret, then they have full unila=
teral
> 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 dele=
tes
> the key and controls the key during the setup process is also the sole
> beneficiary of the entire setup with the multisig participants.
>=20
> Alternative fee rates are easier to deal with using delete-the-key, compa=
red 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-o=
f-n
fashion? So long as at least n-m+1 parties actually deleted their keys IIUC=
 it
should be secure.

> 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
>=20
> 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 th=
en
> select the blockhash (or some function of the chosen blockhash like
> H(H(H(blockhash)))) as the signature. Next, the group agrees on a transac=
tion
> and they recover the public key from the signature using ECDSA pubkey rec=
overy.

Could you explain in more detail why you're deriving this from a blockhash?

> Deploying exceedingly large scripts
> =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
>=20
> A brief interlude to share a somewhat obvious construction. I haven't see=
n this
> written down yet.
>=20
> Suppose there is a bitcoin script that someone is interested in using, bu=
t it
> far exceeds the size limits and sigop limits. To fix this, they would spl=
it up
> the script into usable chunks, and then use the delete-the-key mechanism =
(or
> the other one) to create an OR branch that is signable by a single key for
> which only a single signature is known. That new pre-signed transaction w=
ould
> spend to a script that has the output with the remainder of the script of
> interest. Re-vaulting or clawback clauses can be added to that output as =
well,
> but spending back to the original root script will only work by generatin=
g new
> scripts and keys (since the final hash isn't known until the whole tree is
> constructed, it's a dependency loop).

Clever!

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--kiqt4ydtqylza5nz
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEFcyURjhyM68BBPYTJIFAPaXwkfsFAl1RfzEACgkQJIFAPaXw
kfvFhQgAq3ch2c3AyTaGgO9ceCFLv5TUpbEGKFz4nzSmgwYt6SFg1vbSTDHWWYG7
JSgSpDf9px1ryH7CJ92qmD2X1WQdPYjRSaSynj/TR3kKIfkNmOOLKLLumnwWr7C8
H97igOwzz3opSFalZTVjthxJWN019yrKh/iDj0S9lZHblYpfZKETZQcKjuf+9flu
GNUvpZFk6oxqEWIGlFDW+vFN9kbpsTI+PTSPZx8GxyS7wx7Cgy3a/271LJUKyEcm
L7aZuKGrUtjsL+DPIvMYOeylBKGtDY67LQP3JMMlVpw/T35IwDOsaOhvDipsMrVP
x3cNdSbrnNhZk/6C6b+s90kqqMtefA==
=QATw
-----END PGP SIGNATURE-----

--kiqt4ydtqylza5nz--