path: root/7c/af001fc7e8e7f4451b010c5bfb23c95794d2b4

Return-Path: <praveen.baratam@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id E6056D9C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 13 Aug 2019 02:44:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com
	[209.85.210.47])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 527BD87B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 13 Aug 2019 02:44:16 +0000 (UTC)
Received: by mail-ot1-f47.google.com with SMTP id b7so116692100otl.11
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 12 Aug 2019 19:44:16 -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; 
	bh=z33shgj/kUaXMwaaw83TVVm7X+NEhXeksKoBLpd5Bqg=;
	b=qq4nvIhvkP8CcEkLUAHVXWbhnhvKG8ANLF/+iG8YqOVTEtZCA1PBREdFkIUvw97Qd1
	wLXx4oYdYR0IA/2Y+wCTWjU84Ec57u0LeCpJZPWZuDP7lAI2Alzyhp/Fa915mJxn0QH+
	piMQtfCowJIO0l8eY1zzMW/v3NSMw26NIR/NbouXNORi+Kkz9HiuMYgcY4Fi6ZvIK0UW
	BlQdGj3IIrsLsweW3MrH+Id18veeE9Q1BjFxzZ7MXWt38BvhgNKNdw48hF5pNpezMVmS
	LD+smWx9yEmsVUvbjENS4g5NNjqFMstYs4wPx+042Q6NgeocamvTS11IufhqtXy7BM7d
	d3JQ==
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;
	bh=z33shgj/kUaXMwaaw83TVVm7X+NEhXeksKoBLpd5Bqg=;
	b=RE9kVWGNMkH7K2k/nnmO1pzYS1s37JS2orHXIwHwakOiZhGbhwzpLMy7QpZ6PfZuol
	Pr4VY6rLzixC5dbL2eVHktWSF2uz9VKUwhgrnQ0uHE7sklZGhXD7u9A55sc2yq7XCYP1
	zblyNRZnxMXpdofnShpKcjfsw4YqbBfk5P5DoTNernGWRaNT5LXYkSx1qMZmSYmzVVUH
	wvODPXWuycr4e/FpfAq8b/eRCihKQH92VPIdVv2xJ6lCrUMNotsTo4dyXLmCtUIWt2cE
	dXngwak3QI1BxOZ8BN1pm7M9gW8gnzvHHJxl4RoLgG9WRBHoByctWjsWwvbY1dh+F+5n
	NiKw==
X-Gm-Message-State: APjAAAVDPG6A8u/4uGrio/x6tvEsSPmDOglPcp7CGVHZQOmt+Zc908UY
	N1WxV4jOhv06J5i9Uq9h5AD6TEEmne61qZDz+4A=
X-Google-Smtp-Source: APXvYqzy9Pk/90G0Wic/KdAvpxu7LijsZlW1Y0fCXDFpUAWYPTSUHdCwz1bwNXH+yYvvkAryBAY3KOrNel28C+Y4xvg=
X-Received: by 2002:a54:4813:: with SMTP id j19mr83406oij.34.1565664255133;
	Mon, 12 Aug 2019 19:44:15 -0700 (PDT)
MIME-Version: 1.0
References: <CABaSBawe_oF_zoso2RQBX+7OWDoCwC7T2MeKSX9fYRUQaY_xmg@mail.gmail.com>
In-Reply-To: <CABaSBawe_oF_zoso2RQBX+7OWDoCwC7T2MeKSX9fYRUQaY_xmg@mail.gmail.com>
From: Praveen Baratam <praveen.baratam@gmail.com>
Date: Tue, 13 Aug 2019 08:14:03 +0530
Message-ID: <CAAQs3wvL_iG28ZDB10Y1ENjeNWhUOnFZ5pSWHudzYLB7D2HW6g@mail.gmail.com>
To: Bryan Bishop <kanzure@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c3ce00058ff69deb"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	HTTPS_HTTP_MISMATCH, 
	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
X-Mailman-Approved-At: Tue, 13 Aug 2019 03:25:49 +0000
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:44:20 -0000

--000000000000c3ce00058ff69deb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Bryan,

This is very similar to *CoinVault - Secure Depository and Secure Exchange*
technologies that I have shared with you all.
=E1=90=A7

On Wed, Aug 7, 2019 at 7:23 PM Bryan Bishop via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi,
>
> 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
> benefit
> from SIGHASH_NOINPUT which I'll describe later.
>
> I call them pre-signed vaults.
>
> Vault definition
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> 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
> before 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
> opportunity
> to initiate recovery/clawback which can either trigger deeper cold storag=
e
> parameters or at least reset the delay period to start over again for the
> same
> keys.
>
> One of the important components of this is the delete-the-key pre-signed
> transaction concept, where only a single transaction is (pre)signed befor=
e
> deleting the key. This is basically an emulation of a covenant and
> enforces a
> certain outcome.
>
> Background and motivation
> =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
>
> I was looking at Eyal and Sirer's 2016 vaults paper [1], and I saw this
> headscratcher:
>
> > Vault transactions use a delay mechanism. We note that vault transactio=
ns
> > cannot be implemented with existing timing mechanisms such as
> > CHECKLOCKTIMEVERIFY opcode or transaction locktime.
>
> This was probably written before the introduction of
> OP_CHECKSEQUENCEVERIFY.
> Still, a viable construction would have more steps than just using OP_CSV=
.
> They
> were probably not thinking about what those steps might be, because in th=
e
> context of the paper they were proposing a bitcoin vault implemented usin=
g
> recursive consensus-enforced covenants via a new opcode, which obviously
> cannot
> be deployed without an upgrade fork. Covenants have been discussed for
> years,
> but require new opcodes or other consensus-enforcement changes.
>
> Relative locktimes are useful here because there is no knowledge as to
> when the
> transactions might be broadcasted in the future. The delays need to be
> relative
> to after the transaction is included in the blockchain, not to setup
> initialization time.
>
> Also, from [2]:
>
> > We show that a [vault transaction] mechanism is currently not possible
> in all
> > cryptocurrencies [...] Bitcoin's scripting language requires support fo=
r
> > covenants.
>
> I haven't seen any previous proposal for how to implement recursive bitco=
in
> vaults without a fork and without a covenant. After asking around, I am
> pretty
> sure this is somewhat novel. The closest I guess is [3].
>
> Vaults are particularly interesting as a bitcoin cold storage security
> mechanism because they enable a publicly observable delay period during
> which
> time a user could be alerted by a watchtower that a thief might be in the
> process of stealing their coins, and then the user may take some actions =
to
> place the coins back into the vault before the relative timelock expires.
> There
> seems to be no way to get this notification or observation period without=
 a
> vault construction. It might have been assumed it required a covenant.
>
> Having a vault construction might go a long way to discourage would-be
> attackers, on principle that the attacker might be incapable of recoverin=
g
> their cost-of-attack because the recovery mechanism can lock up the coins
> indefinitely. Griefing or denial-of-service would still be possible, of
> course,
> but with multisig there might be some ways to put a halt to that as well.
> I am
> working under the assumption that the attacker knows that the user is a
> vault
> user.
>
> Vaults
> =3D=3D=3D=3D=3D=3D
>
> The idea is to have a sequence of pre-generated pre-signed transactions
> that
> are generated in a certain way. The basic components are a vaulting
> transaction
> that locks coins into a vault, a delayed-spend transaction which is the
> only
> way to spend from a vault, and a re-vaulting transaction which can
> recover/clawback coins from the delayed-spend transaction. The security o=
f
> this
> scheme is enforced by pre-signing transactions and deleting private keys,
> or
> with the help of SIGHASH_NOINPUT then there's another scheme where privat=
e
> keys
> are provably never known. This enforces that there's only a specific set =
of
> possible outcomes at every step of the vault.
>
> Some examples of what the set of broadcasted transactions might look like
> in
> regular usage:
>
>     coins -> VT -> DST -> exit via hot wallet key
>     coins -> VT -> DST -> RVT
>     coins -> VT -> DST -> RVT -> DST -> ...
>     coins -> VT -> ... -> RVT998 -> nuclear abort
>
> where:
>     VT =3D vault transaction
>     DST =3D delayed-spend transaction
>     RVT =3D re-vaulting transaction
>
> The delayed-spending transaction would have a single output with a script
> like:
> (
>     30 days AND hot wallet key
>  OR 10 days AND re-vaulting public key
>  OR 1 day AND 4-of-7 multisig
>  OR 0 days and super-secure nuclear abort ragequit key
> )
>
> Another diagram:
>
>     VT_100 -> DST -> (optionally) RVT -> coins are now in VT_99
>     VT_99 -> DST -> (optionally) RVT -> coins are now in VT_98
>     ...
>     VT_1 -> burn-all-coins nuclear abort ragequit (final)
>
> Definitions
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Transactions and components:
>
> * Commitment/funding vault setup transaction. Signed after setting up the
> transaction tree, and it is broadcasted whenever funds are to be placed
> into
> the vault.
>
> * Delayed-spend transaction. Signed during the vault transaction tree
> setup,
> and it is broadcasted when the user wants to withdraw coins from cold
> storage
> or otherwise manipulate the coins. The output script template used by the
> delayed-spend transaction was defined earlier.
>
> * Hot wallet key: Somewhat insecure key. This can also be multisig using
> multiple hot keys.
>
> * Re-vaulting key: It is important to note that the private key either
> never
> existed (SIGHASH_NOINPUT + P2WPK for the re-vaulting transaction) or the
> private key was deleted after pre-signing the re-vaulting transaction.
>
> * 4-of-7 multisig: This is a group of differently-motivated individuals
> who are
> responsible for signing transactions. This multisig group is not necessry
> to
> describe the technique, I just think it's a useful feature for a vault to
> include.
>
> * Nuclear abort key: Also unnecessary. This is a key for which only a
> single
> 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
> there
> is any doubt about the ability to keep such a key secured, then it is
> better to
> not include this in the protocol. Alternatively, maybe include it as an
> option
> 50 layers down in the revaulting sequence.
>
> * Nuclear-abort pre-signed transaction. This is signed during transaction
> tree
> setup, before constructing the delayed-spend transaction. It is broadcast=
ed
> only if the user wants to provably relinquish coins forever without givin=
g
> the
> attacker any coins.
>
> * Re-vaulting transaction. This is where the magic happens. The re-vaulti=
ng
> transaction is signed during transaction tree setup, before constructing
> the
> delayed-spend transaction for the parent vault. The re-vaulting
> transaction is
> broadcasted when someone wants to prevent a coin withdrawal during the
> public
> observation delay period. The re-vaulting transaction spends the
> delayed-spend
> transaction outputs. It has a single output with a script created by
> running
> the entire vault setup function again. Hence, when the re-vaulting
> transaction
> is confirmed, all of the coins go back into a new identically-configured
> vault
> instead of being relinquished through the delayed-spend transaction
> timeout for
> hot wallet key signing.
>
> * Special case: final transaction. This is the very first pre-signed
> transaction during setup, and the transaction spends the coins using any
> provable burn technique. This is broadcasted only at the end of the game,
> as an
> ultimate abort and forfeiture of coins without giving in to an adversary.
> It's
> similar to the nuclear-abort ragequit transaction but it sits at the same
> place
> that a delayed-spend transaction would, at the very end of the rainbow or
> yellow brick road.
>
> Example log during vault setup
> =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
>
> When running the recursive vault setup function, the created artifacts (i=
n
> order) will look like:
>
> 1) choose one of:
>    (first iteration) pre-signed burn-all-coins nuclear abort ragequit
> (final)
>    (all others) a new vault setup transaction spendable only by its
>                 delayed-spend transaction
>
> 2) pre-signed re-vaulting transaction sending to vault setup or final
> transaction, with a unique private key
>
> 3) pre-signed delayed-spend transaction, with a unique private key
>
> 4) vault transaction spendable only by the delayed-spend public key
>
> Pseudocode
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> In pseudocode (where PTX is a pre-signed transaction function with
> private key deletion):
>
>     VT(counter, *args, **kwargs) =3D
>         if counter =3D=3D 0:
>             DST =3D PTX("burn-all-coins")
>         else:
>             next_vault =3D VT(counter-1, *args, **kwargs)
>             revaulting =3D PTX("only spendable by next_vault public key")
>             DST =3D PTX("DST policy including revaulting and other
> conditions")
>         vault =3D PTX("spendable only by this DST")
>         return vault
>
> 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
>
> What has been known for a while is that a covenant can be somewhat emulat=
ed
> using a pre-signed transaction where the user then deletes the private ke=
y,
> enforcing that the user's chosen policy must be enforced since there is
> only
> one existing option and there will only ever be one option.
>
> Such a scheme has been previously described for simple one-time and chain=
ed
> vaults [3]. I have learned that the author has an implementation that is =
in
> preparation, for a non-recursive version.
>
> Note that a series of pre-signed transactions can be considered to be an
> emulation of a covenant. Imagine a linear chain of pre-signed transaction=
s
> where each hop has a relative locktime before being able to broadcast the
> next
> transaction. To recover the coins at the end of the rainbow, one would
> need to
> broadcast each sequential transaction in order and wait for the relative
> timelocks to expire each time. Here, covenants provide something like an
> undo
> for bitcoin, but only between pre-determined addresses and scripts.
>
> Fees 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
>
> There's a few different techniques to talk about:
>
> 1) SIGHASH_SINGLE|SIGHASH_ANYONECANPAY to let someone add inputs and
> outputs.
> This can get pretty complex though.
>
> 2) Add a zero-value OP_TRUE output and let anyone spend the zero-value
> output
> and attach a child-pays-for-parent (CPFP) transaction to pay for
> everything.
>
> 3) Pre-sign a variety of different possible fee rates. Unfortunately this
> involves an explosive blow-up in the amount of transaction data to
> generate. It
> might actually be a reasonable blow-up amount, only resulting in a few
> hundred
> megabytes of additional data. But given the other options, this is
> unnecessary.
>
> 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 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.
>
> 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 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
> transaction
> and they recover the public key from the signature using ECDSA pubkey
> recovery.
> A pre-signed transaction is created, which will trigger the start of the
> public
> observation period described earlier and also start the clock for the
> bip112
> relative timelock on its output. In the output script, an OR branch
> is added that enables the use of a re-vaulting key which could also be it=
s
> own
> separate multisig construction.
>
> This is incompatible with P2WPKH because the P2WPKH spending scriptSig
> needs to
> have the pubkey (to check the hash of the pubkey against the pubkeyhash i=
n
> the
> scriptPubKey), which in turn makes it incompatible with ECDSA pubkey
> recovery
> which requires a hash of the message. However, with P2WPK and
> SIGHASH_NOINPUT
> instead of P2WPKH it could conceivably work. SIGHASH_NOINPUT is required
> because
> otherwise the input includes a txid which references the public key. With
> P2WPK,
> the scriptSig only needs a signature and not a public key. Note that what
> would
> be required is a version of SIGHASH_NOINPUT that does not commit to the
> public
> key, and I think a few of the NOINPUT proposals are committing to the
> public
> key.
>
> Alternatively, there may be some constructions using the 2-party ECDSA
> techniques or m-n party ECDSA techniques.
>
> 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
>
> A brief interlude to share a somewhat obvious construction. I haven't see=
n
> this
> written down yet.
>
> 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
> split 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 fo=
r
> which only a single signature is known. That new pre-signed transaction
> would
> 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 i=
s
> constructed, it's a dependency loop).
>
> Recursively-enforced multi-party multisig bitcoin vaults
> =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
>
> Ideally, to enforce a covenant with impossible fairy dust magic, we would
> ask
> for a bitcoin transaction that could be self-referential because the
> only-one-signature-ever trick requires that the signed message be known
> before
> producing the signature, and the signature has to be known before the
> public
> key can be known, and the public key would have to be included in the
> self-referential message/transaction hash value. So, that's a dependency
> loop
> and it doesn't work. It would be interesting to explore a variation of th=
is
> idea with masking, such that a value X can be replaced by a hash over the
> whole
> script with the X value, even though the real script will have the hash.
> Someone else can figure that one out for me :-).
>
> Instead of the self-referential values attempting to reference the same
> script that is in the process of being constructed, an alternative is to
> use
> the same script template but populate it with different parameters. The
> script
> template gets reused over and over again, all the way down the tree, unti=
l
> the
> final transaction which could be >100 years into the future once done
> adding up
> all the relative locktimes. In fact, to create and populate this terrifyi=
ng
> recursive script tree, the final transaction needs to be created first, a=
nd
> then it is given as input to the script template function and that output
> is
> then given to the script template function itself-- and so on. At each
> stage,
> there are additional pre-signed transactions and values to remember.
>
> This can be written as:
>
>     final_transaction =3D TX(spend to 0x0000 to burn the coins)
>     initial_transaction =3D F(F(...F(final_transaction))
>
>     (This is missing parameters to indicate to the function what the
> spending
>     keys requirements are to be.)
>
> See earlier explanation for more details.
>
> Each call to the template populating function produces values that each
> must be
> preserved for a very long time. It is less safe to store all of the
> pre-signed
> transactions together at the same time, but more convenient. With less
> redundancy, there is an increased chance of losing data over time, which
> could
> render the coins completely frozen. This doesn't particularly worry me
> because
> forgetting a key has that property already, and this could be likened to
> hundreds of megabytes of extra key data or something. Unlike the much
> smaller
> covenant-based (opcode-based covenant) vault construction, the multiple
> layers
> here can be separately stored and protected, which might be able to prote=
ct
> against an adversary that has stolen some of the re-vaulting keys but not
> all
> of them.
>
> Optimizations can be made to store parameters for generating the remainde=
r
> of
> the tree, such as using deterministic key derivation, such that megabytes
> of
> data wouldn't need to be long-term stored. Only the initial parameters
> would
> need to be stored.
>
> Financial privacy for custody
> =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
>
> One of the concerns raised in [2] is that if all coins at an exchange are
> stored together in the same vault, then attackers would be able to learn
> about
> access control policies by observing scripts and keys. Some privacy can b=
e
> recovered by using segregated vaults, at the cost of additional setup
> complexity and keeping more data in long-term storage.
>
> However, note that I think vaults are also useful for personal cold stora=
ge
> solutions.
>
> Fail-deadly mechanism
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> An early nuclear abort option can be added to these scripts. This idea wa=
s
> explored in [2]. This would be a very cold very secret key that would
> abort the
> re-vaulting procedure and send all coins to a (provably) nonsense key. Th=
is
> allows a vault user to destroy the coins instead of continuously
> monitoring the
> bitcoin blockchain for the rest of his life. The attacker can't recover
> their
> cost of attack if they never get the coins, and this eliminates an entire
> class
> of potential attackers who are directly interested only in financial gain=
.
> The
> disadvantage is that if the attacker finds the secret key for the
> fail-deadly
> mechanism and uses it, then all of the coins are gone forever.
>
> Multisig variations
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> The re-vaulting key could be the same key at each layer, or only sometime=
s
> the
> same key, or always a unique key stored separately in another secure
> location.
>
> Additionally, these re-vaulting keys could be subjected to multisig
> schemes, as
> well as Shamir secret sharing schemes or other secret sharing schemes.
>
> The idea of adding the 4-of-7 multisig component is to avoid griefing
> situations, at the cost of the additional security requirements for the
> 4-of-7
> multisig group.
>
> Key rotation for vaults
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Keeping the same hot wallet key for 100 years is not advisable. Rotate th=
e
> keys
> by setting up a new vault construction and initiating a withdrawal
> transaction
> from the old vault to the new vault.
>
> Single-use seals
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> This proposal may have inadvertedly demonstrated a practical way to
> implement
> Peter Todd's single-use seals concept [4]. I am hesitant to say so, thoug=
h,
> because I think he would ask for a more sophisticated way to verify seal
> closure.
>
> Paid defection
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> It might be advisable to add small rewards for evidence of defection
> amongst
> multiparty multisig setups. Besides amounts spendable by individual keys
> from a
> multisig setup, it may be possible to use a zero-knowledge contingent
> payment
> for a zero-knowledge statement like: I have a signature s over some
> message m
> which validates for pubkey pk where pk is a member of the multisig group.
> Then
> the zkcp transaction would pay for knowledge of defectors. The zkcp
> procedure
> would require interaction with the defector, while the direct pubkey meth=
od
> would not. This is similar to companies paying employees to quit when the=
y
> value the payment over the value of continued employment.
>
> Handling change
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> It is important to note that this vault setup is one-time and once-only.
> There
> must only ever be one deposit into one vault. Also, spending some coins
> would
> require sending the change amount back into a new vault.  Alternatively,
> upfront work can be done to set a regular withdrawal stipend or assumptio=
n
> about how many coins are left, such that the transaction tree can be
> pre-generated for those possibilities, hence cutting down on future vault
> reinitializations. It would also be possible to commit upfront to only ev=
er
> working in some minimum increment number of bitcoin or something.
>
> It is very important to only fund the vault once, and only with the amoun=
t
> that
> was configured when setting up the vault.
>
> References
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> [1] https://fc16.ifca.ai/bitcoin/papers/MES16.pdf
>
> [2]
> http://www0.cs.ucl.ac.uk/staff/P.McCorry/preventing-cryptocurrency-exchan=
ge.pdf
>
> [3]
> http://web.archive.org/web/20180503151920/https://blog.sldx.com/re-imagin=
ing-cold-storage-with-timelocks-1f293bfe421f?gi=3Dda99a4a00f67
>
> [4]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-December/015=
350.html
> or
> https://diyhpl.us/wiki/transcripts/building-on-bitcoin/2018/single-use-se=
als/
> or https://petertodd.org/2016/closed-seal-sets-and-truth-lists-for-privac=
y
>
> Acknowledgements
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> * Jeremy Rubin for pointing out something embarrassingly broken in an
> earlier
> draft.
>
> * Bob McElrath for telling me to use SIGHASH_NOINPUT which I proceeded to
> promptly forget about.
>
> * Andrew Poelstra for the OP_TRUE trick.
>
> * Joe Rayhawk for paid defection.
>
> * Tadge Dryja for pointing out a few differences between SIGHASH_NOINPUT
> proposals.
>
>
>
> Thank you,
>
> - Bryan
> http://heybryan.org/
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


--=20
Dr. Praveen Baratam

about.me <http://about.me/praveen.baratam>

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

<div dir=3D"ltr">Bryan,<div><br></div><div>This is very similar to <b>CoinV=
ault - Secure Depository and Secure Exchange</b> technologies that I have s=
hared with you all.=C2=A0</div></div><div hspace=3D"streak-pt-mark" style=
=3D"max-height:1px"><img alt=3D"" style=3D"width:0px;max-height:0px;overflo=
w:hidden" src=3D"https://mailfoogae.appspot.com/t?sender=3DacHJhdmVlbi5iYXJ=
hdGFtQGdtYWlsLmNvbQ%3D%3D&amp;type=3Dzerocontent&amp;guid=3Dd4a8aa61-5160-4=
89a-82b0-3dfa116cff34"><font color=3D"#ffffff" size=3D"1">=E1=90=A7</font><=
/div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">O=
n Wed, Aug 7, 2019 at 7:23 PM Bryan Bishop via bitcoin-dev &lt;<a href=3D"m=
ailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundat=
ion.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex">Hi,<br>
<br>
I have a proposal for implementing bitcoin vaults in a way that does not<br=
>
require any soft-forks or other software upgrades, although it could benefi=
t<br>
from SIGHASH_NOINPUT which I&#39;ll describe later.<br>
<br>
I call them pre-signed vaults.<br>
<br>
Vault definition<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
Here, a vault is defined as a transaction setup scheme that binds both the =
user<br>
and the attacker to always using a public observation and delay period befo=
re a<br>
weakly-secured hot key is allowed to arbitrarily spend coins. This is the s=
ame<br>
definition previously used[1]. During the delay period, there is an opportu=
nity<br>
to initiate recovery/clawback which can either trigger deeper cold storage<=
br>
parameters or at least reset the delay period to start over again for the s=
ame<br>
keys.<br>
<br>
One of the important components of this is the delete-the-key pre-signed<br=
>
transaction concept, where only a single transaction is (pre)signed before<=
br>
deleting the key. This is basically an emulation of a covenant and enforces=
 a<br>
certain outcome.<br>
<br>
Background and motivation<br>
=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>
<br>
I was looking at Eyal and Sirer&#39;s 2016 vaults paper [1], and I saw this=
<br>
headscratcher:<br>
<br>
&gt; Vault transactions use a delay mechanism. We note that vault transacti=
ons<br>
&gt; cannot be implemented with existing timing mechanisms such as<br>
&gt; CHECKLOCKTIMEVERIFY opcode or transaction locktime.<br>
<br>
This was probably written before the introduction of OP_CHECKSEQUENCEVERIFY=
.<br>
Still, a viable construction would have more steps than just using OP_CSV. =
They<br>
were probably not thinking about what those steps might be, because in the<=
br>
context of the paper they were proposing a bitcoin vault implemented using<=
br>
recursive consensus-enforced covenants via a new opcode, which obviously ca=
nnot<br>
be deployed without an upgrade fork. Covenants have been discussed for year=
s,<br>
but require new opcodes or other consensus-enforcement changes.<br>
<br>
Relative locktimes are useful here because there is no knowledge as to when=
 the<br>
transactions might be broadcasted in the future. The delays need to be rela=
tive<br>
to after the transaction is included in the blockchain, not to setup<br>
initialization time.<br>
<br>
Also, from [2]:<br>
<br>
&gt; We show that a [vault transaction] mechanism is currently not possible=
 in all<br>
&gt; cryptocurrencies [...] Bitcoin&#39;s scripting language requires suppo=
rt for<br>
&gt; covenants.<br>
<br>
I haven&#39;t seen any previous proposal for how to implement recursive bit=
coin<br>
vaults without a fork and without a covenant. After asking around, I am pre=
tty<br>
sure this is somewhat novel. The closest I guess is [3].<br>
<br>
Vaults are particularly interesting as a bitcoin cold storage security<br>
mechanism because they enable a publicly observable delay period during whi=
ch<br>
time a user could be alerted by a watchtower that a thief might be in the<b=
r>
process of stealing their coins, and then the user may take some actions to=
<br>
place the coins back into the vault before the relative timelock expires. T=
here<br>
seems to be no way to get this notification or observation period without a=
<br>
vault construction. It might have been assumed it required a covenant.<br>
<br>
Having a vault construction might go a long way to discourage would-be<br>
attackers, on principle that the attacker might be incapable of recovering<=
br>
their cost-of-attack because the recovery mechanism can lock up the coins<b=
r>
indefinitely. Griefing or denial-of-service would still be possible, of cou=
rse,<br>
but with multisig there might be some ways to put a halt to that as well. I=
 am<br>
working under the assumption that the attacker knows that the user is a vau=
lt<br>
user.<br>
<br>
Vaults<br>
=3D=3D=3D=3D=3D=3D<br>
<br>
The idea is to have a sequence of pre-generated pre-signed transactions tha=
t<br>
are generated in a certain way. The basic components are a vaulting transac=
tion<br>
that locks coins into a vault, a delayed-spend transaction which is the onl=
y<br>
way to spend from a vault, and a re-vaulting transaction which can<br>
recover/clawback coins from the delayed-spend transaction. The security of =
this<br>
scheme is enforced by pre-signing transactions and deleting private keys, o=
r<br>
with the help of SIGHASH_NOINPUT then there&#39;s another scheme where priv=
ate keys<br>
are provably never known. This enforces that there&#39;s only a specific se=
t of<br>
possible outcomes at every step of the vault.<br>
<br>
Some examples of what the set of broadcasted transactions might look like i=
n<br>
regular usage:<br>
<br>
=C2=A0 =C2=A0 coins -&gt; VT -&gt; DST -&gt; exit via hot wallet key<br>
=C2=A0 =C2=A0 coins -&gt; VT -&gt; DST -&gt; RVT<br>
=C2=A0 =C2=A0 coins -&gt; VT -&gt; DST -&gt; RVT -&gt; DST -&gt; ...<br>
=C2=A0 =C2=A0 coins -&gt; VT -&gt; ... -&gt; RVT998 -&gt; nuclear abort<br>
<br>
where:<br>
=C2=A0 =C2=A0 VT =3D vault transaction<br>
=C2=A0 =C2=A0 DST =3D delayed-spend transaction<br>
=C2=A0 =C2=A0 RVT =3D re-vaulting transaction<br>
<br>
The delayed-spending transaction would have a single output with a script l=
ike:<br>
(<br>
=C2=A0 =C2=A0 30 days AND hot wallet key<br>
=C2=A0OR 10 days AND re-vaulting public key<br>
=C2=A0OR 1 day AND 4-of-7 multisig<br>
=C2=A0OR 0 days and super-secure nuclear abort ragequit key<br>
)<br>
<br>
Another diagram:<br>
<br>
=C2=A0 =C2=A0 VT_100 -&gt; DST -&gt; (optionally) RVT -&gt; coins are now i=
n VT_99<br>
=C2=A0 =C2=A0 VT_99 -&gt; DST -&gt; (optionally) RVT -&gt; coins are now in=
 VT_98<br>
=C2=A0 =C2=A0 ...<br>
=C2=A0 =C2=A0 VT_1 -&gt; burn-all-coins nuclear abort ragequit (final)<br>
<br>
Definitions<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
Transactions and components:<br>
<br>
* Commitment/funding vault setup transaction. Signed after setting up the<b=
r>
transaction tree, and it is broadcasted whenever funds are to be placed int=
o<br>
the vault.<br>
<br>
* Delayed-spend transaction. Signed during the vault transaction tree setup=
,<br>
and it is broadcasted when the user wants to withdraw coins from cold stora=
ge<br>
or otherwise manipulate the coins. The output script template used by the<b=
r>
delayed-spend transaction was defined earlier.<br>
<br>
* Hot wallet key: Somewhat insecure key. This can also be multisig using<br=
>
multiple hot keys.<br>
<br>
* Re-vaulting key: It is important to note that the private key either neve=
r<br>
existed (SIGHASH_NOINPUT + P2WPK for the re-vaulting transaction) or the<br=
>
private key was deleted after pre-signing the re-vaulting transaction.<br>
<br>
* 4-of-7 multisig: This is a group of differently-motivated individuals who=
 are<br>
responsible for signing transactions. This multisig group is not necessry t=
o<br>
describe the technique, I just think it&#39;s a useful feature for a vault =
to<br>
include.<br>
<br>
* Nuclear abort key: Also unnecessary. This is a key for which only a singl=
e<br>
signed transaction will ever exist, and that single transaction will spend =
to a<br>
proof-of-burn key like 0x00. This key must be extremely secure, and if ther=
e<br>
is any doubt about the ability to keep such a key secured, then it is bette=
r to<br>
not include this in the protocol. Alternatively, maybe include it as an opt=
ion<br>
50 layers down in the revaulting sequence.<br>
<br>
* Nuclear-abort pre-signed transaction. This is signed during transaction t=
ree<br>
setup, before constructing the delayed-spend transaction. It is broadcasted=
<br>
only if the user wants to provably relinquish coins forever without giving =
the<br>
attacker any coins.<br>
<br>
* Re-vaulting transaction. This is where the magic happens. The re-vaulting=
<br>
transaction is signed during transaction tree setup, before constructing th=
e<br>
delayed-spend transaction for the parent vault. The re-vaulting transaction=
 is<br>
broadcasted when someone wants to prevent a coin withdrawal during the publ=
ic<br>
observation delay period. The re-vaulting transaction spends the delayed-sp=
end<br>
transaction outputs. It has a single output with a script created by runnin=
g<br>
the entire vault setup function again. Hence, when the re-vaulting transact=
ion<br>
is confirmed, all of the coins go back into a new identically-configured va=
ult<br>
instead of being relinquished through the delayed-spend transaction timeout=
 for<br>
hot wallet key signing.<br>
<br>
* Special case: final transaction. This is the very first pre-signed<br>
transaction during setup, and the transaction spends the coins using any<br=
>
provable burn technique. This is broadcasted only at the end of the game, a=
s an<br>
ultimate abort and forfeiture of coins without giving in to an adversary. I=
t&#39;s<br>
similar to the nuclear-abort ragequit transaction but it sits at the same p=
lace<br>
that a delayed-spend transaction would, at the very end of the rainbow or<b=
r>
yellow brick road.<br>
<br>
Example log during vault setup<br>
=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>
<br>
When running the recursive vault setup function, the created artifacts (in<=
br>
order) will look like:<br>
<br>
1) choose one of:<br>
=C2=A0 =C2=A0(first iteration) pre-signed burn-all-coins nuclear abort rage=
quit (final)<br>
=C2=A0 =C2=A0(all others) a new vault setup transaction spendable only by i=
ts<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 delayed-spend trans=
action<br>
<br>
2) pre-signed re-vaulting transaction sending to vault setup or final<br>
transaction, with a unique private key<br>
<br>
3) pre-signed delayed-spend transaction, with a unique private key<br>
<br>
4) vault transaction spendable only by the delayed-spend public key<br>
<br>
Pseudocode<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
In pseudocode (where PTX is a pre-signed transaction function with<br>
private key deletion):<br>
<br>
=C2=A0 =C2=A0 VT(counter, *args, **kwargs) =3D<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if counter =3D=3D 0:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DST =3D PTX(&quot;burn-all-coins&=
quot;)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 else:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 next_vault =3D VT(counter-1, *arg=
s, **kwargs)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 revaulting =3D PTX(&quot;only spe=
ndable by next_vault public key&quot;)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DST =3D PTX(&quot;DST policy incl=
uding revaulting and other conditions&quot;)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vault =3D PTX(&quot;spendable only by this DST&=
quot;)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return vault<br>
<br>
Pre-signed transactions<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
What has been known for a while is that a covenant can be somewhat emulated=
<br>
using a pre-signed transaction where the user then deletes the private key,=
<br>
enforcing that the user&#39;s chosen policy must be enforced since there is=
 only<br>
one existing option and there will only ever be one option.<br>
<br>
Such a scheme has been previously described for simple one-time and chained=
<br>
vaults [3]. I have learned that the author has an implementation that is in=
<br>
preparation, for a non-recursive version.<br>
<br>
Note that a series of pre-signed transactions can be considered to be an<br=
>
emulation of a covenant. Imagine a linear chain of pre-signed transactions<=
br>
where each hop has a relative locktime before being able to broadcast the n=
ext<br>
transaction. To recover the coins at the end of the rainbow, one would need=
 to<br>
broadcast each sequential transaction in order and wait for the relative<br=
>
timelocks to expire each time. Here, covenants provide something like an un=
do<br>
for bitcoin, but only between pre-determined addresses and scripts.<br>
<br>
Fees for pre-signed transactions<br>
=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>
<br>
There&#39;s a few different techniques to talk about:<br>
<br>
1) SIGHASH_SINGLE|SIGHASH_ANYONECANPAY to let someone add inputs and output=
s.<br>
This can get pretty complex though.<br>
<br>
2) Add a zero-value OP_TRUE output and let anyone spend the zero-value outp=
ut<br>
and attach a child-pays-for-parent (CPFP) transaction to pay for everything=
.<br>
<br>
3) Pre-sign a variety of different possible fee rates. Unfortunately this<b=
r>
involves an explosive blow-up in the amount of transaction data to generate=
. It<br>
might actually be a reasonable blow-up amount, only resulting in a few hund=
red<br>
megabytes of additional data. But given the other options, this is unnecess=
ary.<br>
<br>
Delete the key (for pre-signed transactions)<br>
=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>
<br>
The delete-the-key trick is simple. The idea is to pre-sign at least one<br=
>
transaction and then delete the private key, thus locking in that course of=
<br>
action.<br>
<br>
Unfortunately, delete-the-key doesn&#39;t really work for multisig scenario=
s<br>
because nobody would trust that anyone else in the scheme has actually dele=
ted<br>
the secret. If they haven&#39;t deleted the secret, then they have full uni=
lateral<br>
control to sign anything in that branch of the transaction tree. The only t=
ime<br>
that delete-the-key might be appropriate would be where the user who delete=
s<br>
the key and controls the key during the setup process is also the sole<br>
beneficiary of the entire setup with the multisig participants.<br>
<br>
Alternative fee rates are easier to deal with using delete-the-key, compare=
d to<br>
a technique where the private key never existed which can only be used to s=
ign<br>
one fee rate per public key, requiring an entirely new vault subtree for ea=
ch<br>
alternative fee rate. With delete-the-key, the alternative fee rates are si=
gned<br>
with the private key before the private key is deleted.<br>
<br>
Multisig gated by ECDSA pubkey recovery for provably-unknown keys<br>
=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>
<br>
A group can participate in a multisig scheme with provably-unknown ECDSA ke=
ys.<br>
Instead of deleting the key, the idea is to agree on a blockheight and then=
<br>
select the blockhash (or some function of the chosen blockhash like<br>
H(H(H(blockhash)))) as the signature. Next, the group agrees on a transacti=
on<br>
and they recover the public key from the signature using ECDSA pubkey recov=
ery.<br>
A pre-signed transaction is created, which will trigger the start of the pu=
blic<br>
observation period described earlier and also start the clock for the bip11=
2<br>
relative timelock on its output. In the output script, an OR branch<br>
is added that enables the use of a re-vaulting key which could also be its =
own<br>
separate multisig construction.<br>
<br>
This is incompatible with P2WPKH because the P2WPKH spending scriptSig need=
s to<br>
have the pubkey (to check the hash of the pubkey against the pubkeyhash in =
the<br>
scriptPubKey), which in turn makes it incompatible with ECDSA pubkey recove=
ry<br>
which requires a hash of the message. However, with P2WPK and SIGHASH_NOINP=
UT<br>
instead of P2WPKH it could conceivably work. SIGHASH_NOINPUT is required be=
cause<br>
otherwise the input includes a txid which references the public key. With P=
2WPK,<br>
the scriptSig only needs a signature and not a public key. Note that what w=
ould<br>
be required is a version of SIGHASH_NOINPUT that does not commit to the pub=
lic<br>
key, and I think a few of the NOINPUT proposals are committing to the publi=
c<br>
key.<br>
<br>
Alternatively, there may be some constructions using the 2-party ECDSA<br>
techniques or m-n party ECDSA techniques.<br>
<br>
Deploying exceedingly large scripts<br>
=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>
<br>
A brief interlude to share a somewhat obvious construction. I haven&#39;t s=
een this<br>
written down yet.<br>
<br>
Suppose there is a bitcoin script that someone is interested in using, but =
it<br>
far exceeds the size limits and sigop limits. To fix this, they would split=
 up<br>
the script into usable chunks, and then use the delete-the-key mechanism (o=
r<br>
the other one) to create an OR branch that is signable by a single key for<=
br>
which only a single signature is known. That new pre-signed transaction wou=
ld<br>
spend to a script that has the output with the remainder of the script of<b=
r>
interest. Re-vaulting or clawback clauses can be added to that output as we=
ll,<br>
but spending back to the original root script will only work by generating =
new<br>
scripts and keys (since the final hash isn&#39;t known until the whole tree=
 is<br>
constructed, it&#39;s a dependency loop).<br>
<br>
Recursively-enforced multi-party multisig bitcoin vaults<br>
=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>
<br>
Ideally, to enforce a covenant with impossible fairy dust magic, we would a=
sk<br>
for a bitcoin transaction that could be self-referential because the<br>
only-one-signature-ever trick requires that the signed message be known bef=
ore<br>
producing the signature, and the signature has to be known before the publi=
c<br>
key can be known, and the public key would have to be included in the<br>
self-referential message/transaction hash value. So, that&#39;s a dependenc=
y loop<br>
and it doesn&#39;t work. It would be interesting to explore a variation of =
this<br>
idea with masking, such that a value X can be replaced by a hash over the w=
hole<br>
script with the X value, even though the real script will have the hash.<br=
>
Someone else can figure that one out for me :-).<br>
<br>
Instead of the self-referential values attempting to reference the same<br>
script that is in the process of being constructed, an alternative is to us=
e<br>
the same script template but populate it with different parameters. The scr=
ipt<br>
template gets reused over and over again, all the way down the tree, until =
the<br>
final transaction which could be &gt;100 years into the future once done ad=
ding up<br>
all the relative locktimes. In fact, to create and populate this terrifying=
<br>
recursive script tree, the final transaction needs to be created first, and=
<br>
then it is given as input to the script template function and that output i=
s<br>
then given to the script template function itself-- and so on. At each stag=
e,<br>
there are additional pre-signed transactions and values to remember.<br>
<br>
This can be written as:<br>
<br>
=C2=A0 =C2=A0 final_transaction =3D TX(spend to 0x0000 to burn the coins)<b=
r>
=C2=A0 =C2=A0 initial_transaction =3D F(F(...F(final_transaction))<br>
<br>
=C2=A0 =C2=A0 (This is missing parameters to indicate to the function what =
the spending<br>
=C2=A0 =C2=A0 keys requirements are to be.)<br>
<br>
See earlier explanation for more details.<br>
<br>
Each call to the template populating function produces values that each mus=
t be<br>
preserved for a very long time. It is less safe to store all of the pre-sig=
ned<br>
transactions together at the same time, but more convenient. With less<br>
redundancy, there is an increased chance of losing data over time, which co=
uld<br>
render the coins completely frozen. This doesn&#39;t particularly worry me =
because<br>
forgetting a key has that property already, and this could be likened to<br=
>
hundreds of megabytes of extra key data or something. Unlike the much small=
er<br>
covenant-based (opcode-based covenant) vault construction, the multiple lay=
ers<br>
here can be separately stored and protected, which might be able to protect=
<br>
against an adversary that has stolen some of the re-vaulting keys but not a=
ll<br>
of them.<br>
<br>
Optimizations can be made to store parameters for generating the remainder =
of<br>
the tree, such as using deterministic key derivation, such that megabytes o=
f<br>
data wouldn&#39;t need to be long-term stored. Only the initial parameters =
would<br>
need to be stored.<br>
<br>
Financial privacy for custody<br>
=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>
<br>
One of the concerns raised in [2] is that if all coins at an exchange are<b=
r>
stored together in the same vault, then attackers would be able to learn ab=
out<br>
access control policies by observing scripts and keys. Some privacy can be<=
br>
recovered by using segregated vaults, at the cost of additional setup<br>
complexity and keeping more data in long-term storage.<br>
<br>
However, note that I think vaults are also useful for personal cold storage=
<br>
solutions.<br>
<br>
Fail-deadly mechanism<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
An early nuclear abort option can be added to these scripts. This idea was<=
br>
explored in [2]. This would be a very cold very secret key that would abort=
 the<br>
re-vaulting procedure and send all coins to a (provably) nonsense key. This=
<br>
allows a vault user to destroy the coins instead of continuously monitoring=
 the<br>
bitcoin blockchain for the rest of his life. The attacker can&#39;t recover=
 their<br>
cost of attack if they never get the coins, and this eliminates an entire c=
lass<br>
of potential attackers who are directly interested only in financial gain. =
The<br>
disadvantage is that if the attacker finds the secret key for the fail-dead=
ly<br>
mechanism and uses it, then all of the coins are gone forever.<br>
<br>
Multisig variations<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
The re-vaulting key could be the same key at each layer, or only sometimes =
the<br>
same key, or always a unique key stored separately in another secure locati=
on.<br>
<br>
Additionally, these re-vaulting keys could be subjected to multisig schemes=
, as<br>
well as Shamir secret sharing schemes or other secret sharing schemes.<br>
<br>
The idea of adding the 4-of-7 multisig component is to avoid griefing<br>
situations, at the cost of the additional security requirements for the 4-o=
f-7<br>
multisig group.<br>
<br>
Key rotation for vaults<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
Keeping the same hot wallet key for 100 years is not advisable. Rotate the =
keys<br>
by setting up a new vault construction and initiating a withdrawal transact=
ion<br>
from the old vault to the new vault.<br>
<br>
Single-use seals<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
This proposal may have inadvertedly demonstrated a practical way to impleme=
nt<br>
Peter Todd&#39;s single-use seals concept [4]. I am hesitant to say so, tho=
ugh,<br>
because I think he would ask for a more sophisticated way to verify seal<br=
>
closure.<br>
<br>
Paid defection<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
It might be advisable to add small rewards for evidence of defection amongs=
t<br>
multiparty multisig setups. Besides amounts spendable by individual keys fr=
om a<br>
multisig setup, it may be possible to use a zero-knowledge contingent payme=
nt<br>
for a zero-knowledge statement like: I have a signature s over some message=
 m<br>
which validates for pubkey pk where pk is a member of the multisig group. T=
hen<br>
the zkcp transaction would pay for knowledge of defectors. The zkcp procedu=
re<br>
would require interaction with the defector, while the direct pubkey method=
<br>
would not. This is similar to companies paying employees to quit when they<=
br>
value the payment over the value of continued employment.<br>
<br>
Handling change<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
It is important to note that this vault setup is one-time and once-only. Th=
ere<br>
must only ever be one deposit into one vault. Also, spending some coins wou=
ld<br>
require sending the change amount back into a new vault.=C2=A0 Alternativel=
y,<br>
upfront work can be done to set a regular withdrawal stipend or assumption<=
br>
about how many coins are left, such that the transaction tree can be<br>
pre-generated for those possibilities, hence cutting down on future vault<b=
r>
reinitializations. It would also be possible to commit upfront to only ever=
<br>
working in some minimum increment number of bitcoin or something.<br>
<br>
It is very important to only fund the vault once, and only with the amount =
that<br>
was configured when setting up the vault.<br>
<br>
References<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
[1] <a href=3D"https://fc16.ifca.ai/bitcoin/papers/MES16.pdf" rel=3D"norefe=
rrer" target=3D"_blank">https://fc16.ifca.ai/bitcoin/papers/MES16.pdf</a><b=
r>
<br>
[2] <a href=3D"http://www0.cs.ucl.ac.uk/staff/P.McCorry/preventing-cryptocu=
rrency-exchange.pdf" rel=3D"noreferrer" target=3D"_blank">http://www0.cs.uc=
l.ac.uk/staff/P.McCorry/preventing-cryptocurrency-exchange.pdf</a><br>
<br>
[3] <a href=3D"http://web.archive.org/web/20180503151920/https://blog.sldx.=
com/re-imagining-cold-storage-with-timelocks-1f293bfe421f?gi=3Dda99a4a00f67=
" rel=3D"noreferrer" target=3D"_blank">http://web.archive.org/web/201805031=
51920/https://blog.sldx.com/re-imagining-cold-storage-with-timelocks-1f293b=
fe421f?gi=3Dda99a4a00f67</a><br>
<br>
[4] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017=
-December/015350.html" rel=3D"noreferrer" target=3D"_blank">https://lists.l=
inuxfoundation.org/pipermail/bitcoin-dev/2017-December/015350.html</a><br>
or <a href=3D"https://diyhpl.us/wiki/transcripts/building-on-bitcoin/2018/s=
ingle-use-seals/" rel=3D"noreferrer" target=3D"_blank">https://diyhpl.us/wi=
ki/transcripts/building-on-bitcoin/2018/single-use-seals/</a><br>
or <a href=3D"https://petertodd.org/2016/closed-seal-sets-and-truth-lists-f=
or-privacy" rel=3D"noreferrer" target=3D"_blank">https://petertodd.org/2016=
/closed-seal-sets-and-truth-lists-for-privacy</a><br>
<br>
Acknowledgements<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
* Jeremy Rubin for pointing out something embarrassingly broken in an earli=
er<br>
draft.<br>
<br>
* Bob McElrath for telling me to use SIGHASH_NOINPUT which I proceeded to<b=
r>
promptly forget about.<br>
<br>
* Andrew Poelstra for the OP_TRUE trick.<br>
<br>
* Joe Rayhawk for paid defection.<br>
<br>
* Tadge Dryja for pointing out a few differences between SIGHASH_NOINPUT<br=
>
proposals.<br>
<br>
<br>
<br>
Thank you,<br>
<br>
- Bryan<br>
<a href=3D"http://heybryan.org/" rel=3D"noreferrer" target=3D"_blank">http:=
//heybryan.org/</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature"><div style=3D"color:rgb(34,34,34);font-family:ar=
ial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">Dr. Pravee=
n Baratam</div><div style=3D"color:rgb(34,34,34);font-family:arial,sans-ser=
if;font-size:13px;background-color:rgb(255,255,255)"><br></div><div style=
=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;backgro=
und-color:rgb(255,255,255)"><a href=3D"http://about.me/praveen.baratam" sty=
le=3D"color:rgb(17,85,204)" target=3D"_blank">about.me</a></div></div>

--000000000000c3ce00058ff69deb--