path: root/e4/c85ac1007582ce0a00998b5a1275f9b7c24cbe

Return-Path: <matthew@roberts.pm>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 7312F2C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 23 Dec 2016 18:21:44 +0000 (UTC)
Received: by mail-ua0-f177.google.com with SMTP id i68so14215928uad.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CAL8tG=n6NnTaeV71-sWi3Bvk_8E8F20_69f90k-Shrc4XXUQog@mail.gmail.com>
References: <CAL8tG=n6NnTaeV71-sWi3Bvk_8E8F20_69f90k-Shrc4XXUQog@mail.gmail.com>
From: Matthew Roberts <matthew@roberts.pm>
Date: Sat, 24 Dec 2016 04:21:43 +1000
Message-ID: <CAAEDBiHJf544gpEsuzE5vO8Kdr3_yUU2pf-2Danei4VqjEo3hQ@mail.gmail.com>
To: Andrew <onelineproof@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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 <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
>

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

<div dir=3D"ltr">The following won&#39;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.<d=
iv><br></div><div>If you&#39;re interested look up the definition for &quot=
;Lamport Signatures.&quot; It&#39;s an algorithm for masking the bits of a =
message by exchanging a table of hashes prior to signing and then revealing=
 the &quot;secrets&quot; behind said hashes in such a way that you can sele=
ctively mask the bits of the message hash that you&#39;re wishing to sign.<=
/div><div><br></div><div>It&#39;s actually a really cool algorithm and prob=
ably the most elegant thing I&#39;ve ever seen in the way of digital signat=
ures - and besides just being something that&#39;s really cool: Lamport Sig=
natures have the advantage of being quantum safe too (if you care about tha=
t kind of thing.)</div><div><br></div><div>To actually answer your question=
 indirectly: you would use a consensus system that understands Lamport sign=
ature operations in the &quot;scriptPubKey&quot; (Ethereum could probably d=
o this now.) And note that as Nick ODell has already said: using the hashes=
 alone in this scheme won&#39;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&#39;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.)</div><div><br></div><div=
>Regarding hash protected M of N multi-sig: there is already a similar smar=
t contract algorithm called &quot;atomic cross-chain contracts&quot; 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.</div><div><br></div><div>(I hop=
e this helps. You didn&#39;t say much about the intended use-case for this.=
)</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On F=
ri, Dec 23, 2016 at 4:29 AM, Andrew via bitcoin-dev <span dir=3D"ltr">&lt;<=
a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b=
itcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">Hi<br>
<br>
Is there a worked out scriptPubKey for doing multisig with just hashes<br>
of the participants? I think it is doable and it is more secure to a<br>
compromised ECDSA. I&#39;m thinking something like this for the<br>
scriptPubKey:<br>
=C2=A02 OP_SWAP OP_SWAP OP_SWAP OP_DUP OP_HASH160 &lt;pubKeyHash1&gt;<br>
OP_EQUALVERIFY OP_DUP OP_HASH160 &lt;pubKeyHash2&gt; OP_EQUALVERIFY OP_DUP<=
br>
OP_HASH160 &lt;pubKeyHash3&gt; OP_EQUALVERIFY 3 OP_CHECKMULTISIG<br>
<br>
and &lt;sigs&gt;&lt;pubkeys&gt; for the scriptSig<br>
<br>
Can anyone confirm or send me a link to the worked out script?<br>
<br>
Thanks<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
PGP: B6AC 822C 451D 6304 6A28=C2=A0 49E9 7DB7 011C D53B 5647<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</font></span></blockquote></div><br></div>

--f403045f8f6c4505220544577541--
From dev@jonasschnelli.ch  Sun Jan  1 21:08:31 2017
Return-Path: <dev@jonasschnelli.ch>
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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  1 Jan 2017 22:01:24 +0100 (CET)
To: bitcoin-dev@lists.linuxfoundation.org
References: <71d822e413ac457a530e1c367811cc24@cock.lu>
From: Jonas Schnelli <dev@jonasschnelli.ch>
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 <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: 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 <dev@jonasschnelli.ch>
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.

</jonas>


--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--