From: Peter Todd <pete@petertodd•org>
To: Bryan Bishop <kanzure@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback mechanisms
Date: Mon, 12 Aug 2019 11:01:10 -0400 [thread overview]
Message-ID: <20190812150110.yf76pq47e5oszx62@petertodd.org> (raw)
In-Reply-To: <CABaSBawe_oF_zoso2RQBX+7OWDoCwC7T2MeKSX9fYRUQaY_xmg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5884 bytes --]
On Wed, Aug 07, 2019 at 08:48:06AM -0500, Bryan Bishop via bitcoin-dev 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
> ================
>
> Here, a vault is defined as a transaction setup scheme that binds both the 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 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 enforces a
> certain outcome.
It's important to note the reason this is possible is because any coin bound 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 way.
> * Nuclear abort key: Also unnecessary. This is a key for which only a single
> signed transaction will ever exist, and that single transaction will spend to a
> proof-of-burn key like 0x00. This key must be extremely secure, and if there
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)
> ============================================
>
> 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.
> 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?
> Deploying exceedingly large scripts
> ===================================
>
> A brief interlude to share a somewhat obvious construction. I haven't seen this
> written down yet.
>
> Suppose there is a bitcoin script that someone is interested in using, but 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 for
> 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 generating new
> scripts and keys (since the final hash isn't known until the whole tree is
> constructed, it's a dependency loop).
Clever!
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-08-12 15:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-07 13:48 Bryan Bishop
2019-08-07 20:32 ` Bryan Bishop
2019-08-07 21:19 ` Dustin Dettmer
2019-08-08 2:09 ` Sergio Demian Lerner
2019-08-08 3:03 ` ZmnSCPxj
2019-08-08 0:27 ` ZmnSCPxj
2019-08-08 1:16 ` Bryan Bishop
2019-08-12 14:40 ` [bitcoin-dev] Single-use-Seal Implementation Peter Todd
2019-08-12 15:01 ` Peter Todd [this message]
2019-08-13 2:09 ` [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback mechanisms Bryan Bishop
2019-08-13 14:15 ` Peter Todd
2019-08-13 2:44 ` Praveen Baratam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190812150110.yf76pq47e5oszx62@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=kanzure@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox