public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Matthew Roberts <matthew@roberts.pm>
To: Andrew <onelineproof@gmail.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Multisig with hashes instead of pubkeys
Date: Sat, 24 Dec 2016 04:21:43 +1000	[thread overview]
Message-ID: <CAAEDBiHJf544gpEsuzE5vO8Kdr3_yUU2pf-2Danei4VqjEo3hQ@mail.gmail.com> (raw)
In-Reply-To: <CAL8tG=n6NnTaeV71-sWi3Bvk_8E8F20_69f90k-Shrc4XXUQog@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2938 bytes --]

The following won't be directly applicable to your question without some
kind of tremendous hacking on your part: but in cryptography there is
actually a way to sign a message using only hash functions.

If you're interested look up the definition for "Lamport Signatures." It's
an algorithm for masking the bits of a message by exchanging a table of
hashes prior to signing and then revealing the "secrets" behind said hashes
in such a way that you can selectively mask the bits of the message hash
that you're wishing to sign.

It's actually a really cool algorithm and probably the most elegant thing
I've ever seen in the way of digital signatures - and besides just being
something that's really cool: Lamport Signatures have the advantage of
being quantum safe too (if you care about that kind of thing.)

To actually answer your question indirectly: you would use a consensus
system that understands Lamport signature operations in the "scriptPubKey"
(Ethereum could probably do this now.) And note that as Nick ODell has
already said: using the hashes alone in this scheme won't work since the
moment you publish the transactions with said hash secrets anyone is then
free to pluck out those values and double spend the original transaction to
a new destination (and this is actually the reason why Peter Todd's
proof-of-hash collision scheme in Bitcoin is insecure but still allows us
to incentivize whether or not there may be a flaw with the recent SHA
algorithms.)

Regarding hash protected M of N multi-sig: there is already a similar smart
contract algorithm called "atomic cross-chain contracts" that relies on
hash values to be released as part of the protocol to swap coins across
blockchains but said algorithm also uses ECDSA public keys to prevent the
transactions from being double-spent. So in Bitcoin Multi-sig using hash
values will work - though you still need to include an ECDSA pub key to
protect them from attackers on the network.

(I hope this helps. You didn't say much about the intended use-case for
this.)

On Fri, Dec 23, 2016 at 4:29 AM, Andrew via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi
>
> Is there a worked out scriptPubKey for doing multisig with just hashes
> of the participants? I think it is doable and it is more secure to a
> compromised ECDSA. I'm thinking something like this for the
> scriptPubKey:
>  2 OP_SWAP OP_SWAP OP_SWAP OP_DUP OP_HASH160 <pubKeyHash1>
> OP_EQUALVERIFY OP_DUP OP_HASH160 <pubKeyHash2> OP_EQUALVERIFY OP_DUP
> OP_HASH160 <pubKeyHash3> OP_EQUALVERIFY 3 OP_CHECKMULTISIG
>
> and <sigs><pubkeys> for the scriptSig
>
> Can anyone confirm or send me a link to the worked out script?
>
> Thanks
>
> --
> PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 3800 bytes --]

      parent reply	other threads:[~2016-12-23 18:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-22 18:29 [bitcoin-dev] Multisig with hashes instead of pubkeys Andrew
2016-12-23 17:35 ` Nick ODell
2016-12-23 18:21 ` Matthew Roberts [this message]

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=CAAEDBiHJf544gpEsuzE5vO8Kdr3_yUU2pf-2Danei4VqjEo3hQ@mail.gmail.com \
    --to=matthew@roberts.pm \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=onelineproof@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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