Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7312F2C for ; Fri, 23 Dec 2016 18:21:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f177.google.com (mail-ua0-f177.google.com [209.85.217.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B2F7CD5 for ; Fri, 23 Dec 2016 18:21:44 +0000 (UTC) Received: by mail-ua0-f177.google.com with SMTP id i68so14215928uad.0 for ; Fri, 23 Dec 2016 10:21:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=roberts-pm.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=2F5niO+qfReKatLDB65QaGyJChRUCDgCPyxbrQ4Czdo=; b=K40IfJdh9bAwbn0l7GCMV2i9YKwNYsIrf/JeQlgFuPv6Y/oTsLb9IDqzb4moT1LKZD ff9MdGcCopkkITO6yoClInt7eeYSVjoZpmdk1+oRFSkdVGEK3EsQA8ivEKbKG9+SS19d bFVRy84KwORrzqw/I95AXVEoo0EGYKpCycbazLB4NfqREm3ke2o95K6S7z3bDW+KvN8Y lSOgOhR5JYh3v5rBbTe45lhDY+1SObkzOuvw9tixPSHLxnD4QS+Ewl9TTURXNC6GvERd pAYq4doitZTvRnkKfVqNkI+RjtlVV3fE73yH+XawOzrYB8KGdLB/S3Fk7vNpFYGvDckH WAeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=2F5niO+qfReKatLDB65QaGyJChRUCDgCPyxbrQ4Czdo=; b=DsZ8d1d+TmO5TMZZjKSGTz6usWreYrdjWeXI1S/wXtkz2VRJjHLnvfZHwFYLuXPFKH bMOM1Ir/AeO2ROrWB65yVkor1qJ5qMYWwwfDyLLChU6S/bNDuonKVf9DhhcWe0ud6gEN Eas2EqUVCYof/w3wqkr7AMHQaLM8kl3cWJaBoTYrnkfMLg2UlY5rAuMpN1jLfRzDqNSO xgnadOQdnl36ZH8HKWBUAKbLtUR58+Wwy5i8nrFgOyEXf1eZoicDeW8XZHE1Q/PTk0hT WYXA7s0OFUkw/u1YasRDHFcNzl+SE/OdewXDCnhEfADRtc+U848vr2JC6tuxjBkd4RgB a+sg== X-Gm-Message-State: AIkVDXKKSTFi/xx+xUv1/HUQiDm/FsK3Kxl0YFm1ygnBQAIigwVxuSuMU3TasB6D9iurKGJiBtVmI6hV16gQeQ== X-Received: by 10.176.91.14 with SMTP id u14mr12387929uae.133.1482517303833; Fri, 23 Dec 2016 10:21:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.54.145 with HTTP; Fri, 23 Dec 2016 10:21:43 -0800 (PST) X-Originating-IP: [49.199.195.141] In-Reply-To: References: From: Matthew Roberts Date: Sat, 24 Dec 2016 04:21:43 +1000 Message-ID: To: Andrew , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=f403045f8f6c4505220544577541 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, 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: Fri, 23 Dec 2016 18:41:20 +0000 Subject: Re: [bitcoin-dev] Multisig with hashes instead of pubkeys X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 18:21:45 -0000 --f403045f8f6c4505220544577541 Content-Type: text/plain; charset=UTF-8 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 > OP_EQUALVERIFY OP_DUP OP_HASH160 OP_EQUALVERIFY OP_DUP > OP_HASH160 OP_EQUALVERIFY 3 OP_CHECKMULTISIG > > and 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 > --f403045f8f6c4505220544577541 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The following won't be directly applicable to your que= stion without some kind of tremendous hacking on your part: but in cryptogr= aphy 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 sele= ctively mask the bits of the message hash that you're wishing to sign.<= /div>

It's actually a really cool algorithm and prob= ably the most elegant thing I've ever seen in the way of digital signat= ures - and besides just being something that's really cool: Lamport Sig= natures have the advantage of being quantum safe too (if you care about tha= t kind of thing.)

To actually answer your question= indirectly: you would use a consensus system that understands Lamport sign= ature operations in the "scriptPubKey" (Ethereum could probably d= o 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 trans= actions with said hash secrets anyone is then free to pluck out those value= s 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 th= ere may be a flaw with the recent SHA algorithms.)

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

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

On F= ri, Dec 23, 2016 at 4:29 AM, Andrew via bitcoin-dev <<= a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b= itcoin-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:
=C2=A02 OP_SWAP OP_SWAP OP_SWAP OP_DUP OP_HASH160 <pubKeyHash1>
OP_EQUALVERIFY OP_DUP OP_HASH160 <pubKeyHash2> OP_EQUALVERIFY OP_DUP<= br> 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=C2=A0 49E9 7DB7 011C D53B 5647
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev

--f403045f8f6c4505220544577541-- From dev@jonasschnelli.ch Sun Jan 1 21:08:31 2017 Return-Path: X-Original-To: bitcoin-dev@lists.linuxfoundation.org Delivered-To: bitcoin-dev@mail.linuxfoundation.org Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 532956C for ; Sun, 1 Jan 2017 21:08:31 +0000 (UTC) X-Greylist: delayed 00:07:03 by SQLgrey-1.7.6 Received: from server3 (server3.include7.ch [144.76.194.38]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id F2F9A148 for ; Sun, 1 Jan 2017 21:08:29 +0000 (UTC) Received: by server3 (Postfix, from userid 115) id 464622D00D00; Sun, 1 Jan 2017 22:01:25 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, FSL_HELO_NON_FQDN_1 autolearn=ham version=3.3.1 Received: from Jonass-MacBook-Pro.local (cable-static-140-182.teleport.ch [87.102.140.182]) by server3 (Postfix) with ESMTPSA id A351A2D002F5 for ; Sun, 1 Jan 2017 22:01:24 +0100 (CET) To: bitcoin-dev@lists.linuxfoundation.org References: <71d822e413ac457a530e1c367811cc24@cock.lu> From: Jonas Schnelli Message-ID: <77b6dd25-0603-a0bd-6a9e-38098e5cb19d@jonasschnelli.ch> Date: Sun, 1 Jan 2017 22:01:23 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <71d822e413ac457a530e1c367811cc24@cock.lu> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6IHk7D0dOTE5EhJ5BgtwkBmr9rvpOuGd1" Subject: Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2017 21:08:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6IHk7D0dOTE5EhJ5BgtwkBmr9rvpOuGd1 Content-Type: multipart/mixed; boundary="um4tXD5WgrPW5SVWmd3sfKgkMEIh6JiEa"; protected-headers="v1" From: Jonas Schnelli To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <77b6dd25-0603-a0bd-6a9e-38098e5cb19d@jonasschnelli.ch> Subject: Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security References: <71d822e413ac457a530e1c367811cc24@cock.lu> In-Reply-To: <71d822e413ac457a530e1c367811cc24@cock.lu> --um4tXD5WgrPW5SVWmd3sfKgkMEIh6JiEa Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi > We introduce several concepts that rework the lightweight Bitcoin > client model in a manner which is secure, efficient and privacy > compatible. > > The BFD can be used verbatim in replacement of BIP37, where the filter > can be cached between clients without needing to be recomputed. It can > also be used by normal pruned nodes to do re-scans locally of their > wallet without needing to have the block data available to scan, or > without reading the entire block chain from disk. I started exploring the potential of BFD after this specification. What would be the preferred/recommended way to handle 0-conf/mempool filtering =96 if & once BDF would have been deployed (any type, semi-trusted oracles or protocol-level/softfork)? =46rom the user-experience perspective, this is probably pretty important= (otherwise the experience will be that incoming funds can take serval minutes to hours until they appear). Using BIP37 bloom filters just for mempool filtering would obviously result in the same unwanted privacy-setup. --um4tXD5WgrPW5SVWmd3sfKgkMEIh6JiEa-- --6IHk7D0dOTE5EhJ5BgtwkBmr9rvpOuGd1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEMu5cTD+hXMrbRqvlKdS8tkFvU+wFAlhpbiQACgkQKdS8tkFv U+xNHRAAhbvVk8AP5212AOXibxEUQ1byhZOz2TgJUze3W2tBiFLZvOYbqxvVlnfh CDWKKxPUOqEhGfQxxJaBJoPh3dUOeysf5wEPfD7plwbZUOuOt6HM72MqcJCBpjoc Q1sxGjSza3/BJpyVMYDcbcGmA020j3taI1JzSTm13BenAzwsjxOo6wqJNCBH193Y IQvxUDV1byedkjXMIR8FALlneDlhtXVxmpX/woD94EnCyVSlDplTD/df/1a48hte difPmYk1OghzZKrI+e4ciPajrt3RFmQT4EdHyJzFs+YYPMIycn5SbR02NPa5TcyY THEiBWbiGQIYqYwQtWamgRBhVwt8bnIo+5rLljxyPQ5ftrNfDUP1n+Xv+ZziTvWc 4/Xt0qwtTSgFN/03IoPXm15+CjL0httjVMkQrdQBI4YsaW03UZ+h1/8fjrSwhYkg yjjvpldoZAVRLTscFTWEVX3AKXAymX+gxneFv+Ovn4hohZF7IZZi1mR2H+M4yzuh Tik/Ns0/lW2JtuDEh+t2nRbLLQIy4SiTb+1ELZGHs8FjPc7FX8FwgHagybSzmdQG 3jJHVn8VciQwYUqsyqjjLvfD7zlnXctQSsb9DtKn+tmP0CJZpvdKulXMJ7lE/rGV 1Z9Dnrcnz/tmm8pkLtUr4RJ355W7vbjaQZO0QgNnZ4PBGFl2lIc= =uVw8 -----END PGP SIGNATURE----- --6IHk7D0dOTE5EhJ5BgtwkBmr9rvpOuGd1--