From: Peter Todd <pete@petertodd•org>
To: Bryan Bishop <kanzure@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback mechanisms
Date: Tue, 13 Aug 2019 10:15:32 -0400 [thread overview]
Message-ID: <20190813141532.zv5n5ghii5e44qsf@petertodd.org> (raw)
In-Reply-To: <CABaSBawwSEa_dDLEXhWncsqKmsM+rdT2Npo334LEZPvcMzrzFQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1461 bytes --]
On Mon, Aug 12, 2019 at 09:09:43PM -0500, Bryan Bishop wrote:
> > > 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.
But why does this specifically need to be entropy?
If I understand the scheme correctly, the important thing is for the ECDSA
private key to be unknown. Under the standard assumption that hash functions
are random oracles, hashing anything should be sufficient to create a pubkey
whose private key is unknown.
Secondly, there's probably better slightly privacy if a random nonce is chosen
(perhaps by concatenating a nonce from each party) rather than picking pubkeys
unique to this use-case.
--
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-13 14:15 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 ` [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback mechanisms Peter Todd
2019-08-13 2:09 ` Bryan Bishop
2019-08-13 14:15 ` Peter Todd [this message]
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=20190813141532.zv5n5ghii5e44qsf@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