path: root/d4/f3bae616332acc0dab6daf4cf29ff02f0cac93

Return-Path: <ctpacia@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 46EE149B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  4 May 2017 16:23:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f177.google.com (mail-wr0-f177.google.com
	[209.85.128.177])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5F545170
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  4 May 2017 16:23:29 +0000 (UTC)
Received: by mail-wr0-f177.google.com with SMTP id z52so10741384wrc.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 04 May 2017 09:23:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=/4+CVpTRMCfYsftTM+Mc+Gyk2KTwvgvaW7nXTdWKNmk=;
	b=sFtLGI3JW7YXldYRsptAepF0GOq2s+oGC+zdA9bdKG145nGmQ+YMhGu1igY6WiWUlO
	64Ha/cBeK/vfsMUAV0Na0Zo/aomyey5illaXTEfW4tZTAvURARPOB3i1p/D4J0IDcVqg
	CD4HW/BmrowS6ODHScEBKZ9QD+oV/+urc1/sewqZ69ERLvZSp+F0PwSgg1tBcG0zsSHa
	jaEq5ky9AWuiCB1TQ52iu1l7+HQmyuSsydLLgfm/0I0p+ITXxfDg4bFmtkPbpGPkqsBa
	gvcd84LejtErXGXXa+HnouGiRZRmVxeGpG+QqYM23LBTpqHzkxcmh1rHaieDp6tQad2b
	1F7A==
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:cc;
	bh=/4+CVpTRMCfYsftTM+Mc+Gyk2KTwvgvaW7nXTdWKNmk=;
	b=DXRQV5UW09eewK3J/bYZvMIOAcBfRGK8hilIsAe/9urPMlB04ICCVVpSbPywlNiP24
	oEEbZm/YsC2bFosf7tYTzpqSUswrHU4ReZk0uyb/suAHuRxgqX5Shn0R0FXNlpGYkigZ
	LlZD0oUI2p9G6t/uJOAd6XZQVUX+JyJmnKQgylrds8349345lUYal5GxVnM/omjmrcsQ
	bI1gg4SE0mhPbGsO48DZ4IJlqF4G83tZ4M5XroiCZESQaVH5lmDP2dncIXYHZTf/RVQB
	l6eFoLf5itRX6xQmQfKKfsZp+6hMk9iPiq5DfMpkhycrrtY2Fp+SbFPdt6E9VAlA61Dk
	zovQ==
X-Gm-Message-State: AN3rC/56ApJIULSnbLWhao1B6VX9nFbSsVHob+5m2tR9obl9zFpYdAHq
	Arj/SPfM/rkXo+8h9MyniPGyr33NoQ==
X-Received: by 10.223.164.9 with SMTP id d9mr25437501wra.91.1493915007951;
	Thu, 04 May 2017 09:23:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.173.102 with HTTP; Thu, 4 May 2017 09:23:27 -0700 (PDT)
Received: by 10.223.173.102 with HTTP; Thu, 4 May 2017 09:23:27 -0700 (PDT)
In-Reply-To: <20170504125138.GA2027@banane.informatik.uni-ulm.de>
References: <20170504125138.GA2027@banane.informatik.uni-ulm.de>
From: Chris Pacia <ctpacia@gmail.com>
Date: Thu, 4 May 2017 12:23:27 -0400
Message-ID: <CAB+qUq56a7-6B=-WVYUC2xoYADg+pnwje7ZSff3T4XBdAdUMkg@mail.gmail.com>
To: Henning Kopp <henning.kopp@uni-ulm.de>
Content-Type: multipart/alternative; boundary=f403045f14c25fc26d054eb5313b
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE, 
	RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Combining SPV and Stealth addresses
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: Thu, 04 May 2017 16:23:30 -0000

--f403045f14c25fc26d054eb5313b
Content-Type: text/plain; charset=UTF-8

Yes I've had it working using two pushes in op_return.

op_return op_pushdata <flag> op_pushdata <ephem_pubkey>

Flag goes in your filter. You anonymity set is all other transactions using
that same flag.

This is fairly decent privacy but the problem is you still need filter
matches on outgoing transactions to build a functioning wallet. So it might
not be an improvement over standard bloom filters but at least you can do
stealth if you want.

On May 4, 2017 9:00 AM, "Henning Kopp via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> Recently I think a lot about combining Stealth addresses with SPV but
> I did not come to a satisfying conclusion, so I post this as a
> challenge to the wider community. Maybe you have an idea.
>
> ## Explanation of SPV
> In SPV a thin client puts his public keys in a bloom filter
> and asks a full node to give him Merkle proofs of all transactions
> whose pubkey are in the bloom filter. Since a bloom filter has a lot
> of false positives depending on the parameters, this gives privacy to
> the thin client, since the full node cannot detect if a specific
> transaction belongs to the thin client. This is cool if you want to
> use Bitcoin on your smartphone.
>
> ## Explanation of Stealth Addresses
> Stealth addresses on the other hand enable receiver privacy. The
> sender of a transaction derives a one-time pubkey to which he sends the
> money. The receiver can check if the money was sent to him and recover
> the one-time private key. This is cool, since an observer cannot
> decide if two payments belong to the same recipient. Further the
> recipient needs only to have one pubkey.
> For a more formal explanation see https://github.com/genjix/
> bips/blob/master/bip-stealth.mediawiki#Reuse_ScanPubkey
> I will use their notation in the following.
>
> ## The Problem
> My line of thought was to combine stealth addresses with spv, so that
> I can use stealth addresses on my smart phone without losing privacy.
>
> Basically to check if a payment belongs to a pubkey (Q,R), the full
> node needs to check if R' = R + H(dP)*G for each transaction. For this
> it needs the private scanning key d.
> This sucks, since when I give my d to a full node, he can link all my
> transactions. For an online-wallet this may be okay, but not for thin
> client synchronisation.
>
> ## Ideas
> In the following I detail some ideas of me which did not work.
>
> It does not suffice to have a Bloom filter and check if d is
> contained since there is no way to recompute d from the equation. If
> there were a way to recompute d, the scheme would offer no privacy,
> since anyone could compute the private scanning key d and scan for
> payments.
> So, if we modify the scheme we need to be sure that d is kept private.
>
> Multiparty computation may be possible in theory. The full node and
> the thin client could collaboratively check R' = R + H(dP)*G, where d
> is the private input of the thin client and R, R',P is provided by the
> full node. But this is costly and they need to do it for each
> transaction. It may be more costly than simply setting up a full node.
>
> I do not think that some kind of search functionality without leaking
> the search pattern (PIR?) would work, since the full node needs to compute
> on the
> data it has found. And further it needs to retrieve the whole Merkle
> proofs.
>
> Any better ideas?
>
> Best,
> Henning
>
> --
> Henning Kopp
> Institute of Distributed Systems
> Ulm University, Germany
>
> Office: O27 - 3402
> Phone: +49 731 50-24138
> Web: http://www.uni-ulm.de/in/vs/~kopp
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"auto">Yes I&#39;ve had it working using two pushes in op_return=
.<div dir=3D"auto"><br></div><div dir=3D"auto">op_return op_pushdata &lt;fl=
ag&gt; op_pushdata &lt;ephem_pubkey&gt;</div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">Flag goes in your filter. You anonymity set is all other tr=
ansactions using that same flag.=C2=A0</div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">This is fairly decent privacy but the problem is you still n=
eed filter matches on outgoing transactions to build a functioning wallet. =
So it might not be an improvement over standard bloom filters but at least =
you can do stealth if you want.</div></div><div class=3D"gmail_extra"><br><=
div class=3D"gmail_quote">On May 4, 2017 9:00 AM, &quot;Henning Kopp via bi=
tcoin-dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br type=3D"attributi=
on"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
Recently I think a lot about combining Stealth addresses with SPV but<br>
I did not come to a satisfying conclusion, so I post this as a<br>
challenge to the wider community. Maybe you have an idea.<br>
<br>
## Explanation of SPV<br>
In SPV a thin client puts his public keys in a bloom filter<br>
and asks a full node to give him Merkle proofs of all transactions<br>
whose pubkey are in the bloom filter. Since a bloom filter has a lot<br>
of false positives depending on the parameters, this gives privacy to<br>
the thin client, since the full node cannot detect if a specific<br>
transaction belongs to the thin client. This is cool if you want to<br>
use Bitcoin on your smartphone.<br>
<br>
## Explanation of Stealth Addresses<br>
Stealth addresses on the other hand enable receiver privacy. The<br>
sender of a transaction derives a one-time pubkey to which he sends the<br>
money. The receiver can check if the money was sent to him and recover<br>
the one-time private key. This is cool, since an observer cannot<br>
decide if two payments belong to the same recipient. Further the<br>
recipient needs only to have one pubkey.<br>
For a more formal explanation see <a href=3D"https://github.com/genjix/bips=
/blob/master/bip-stealth.mediawiki#Reuse_ScanPubkey" rel=3D"noreferrer" tar=
get=3D"_blank">https://github.com/genjix/<wbr>bips/blob/master/bip-stealth.=
<wbr>mediawiki#Reuse_ScanPubkey</a><br>
I will use their notation in the following.<br>
<br>
## The Problem<br>
My line of thought was to combine stealth addresses with spv, so that<br>
I can use stealth addresses on my smart phone without losing privacy.<br>
<br>
Basically to check if a payment belongs to a pubkey (Q,R), the full<br>
node needs to check if R&#39; =3D R + H(dP)*G for each transaction. For thi=
s<br>
it needs the private scanning key d.<br>
This sucks, since when I give my d to a full node, he can link all my<br>
transactions. For an online-wallet this may be okay, but not for thin<br>
client synchronisation.<br>
<br>
## Ideas<br>
In the following I detail some ideas of me which did not work.<br>
<br>
It does not suffice to have a Bloom filter and check if d is<br>
contained since there is no way to recompute d from the equation. If<br>
there were a way to recompute d, the scheme would offer no privacy,<br>
since anyone could compute the private scanning key d and scan for<br>
payments.<br>
So, if we modify the scheme we need to be sure that d is kept private.<br>
<br>
Multiparty computation may be possible in theory. The full node and<br>
the thin client could collaboratively check R&#39; =3D R + H(dP)*G, where d=
<br>
is the private input of the thin client and R, R&#39;,P is provided by the<=
br>
full node. But this is costly and they need to do it for each<br>
transaction. It may be more costly than simply setting up a full node.<br>
<br>
I do not think that some kind of search functionality without leaking<br>
the search pattern (PIR?) would work, since the full node needs to compute =
on the<br>
data it has found. And further it needs to retrieve the whole Merkle<br>
proofs.<br>
<br>
Any better ideas?<br>
<br>
Best,<br>
Henning<br>
<br>
--<br>
Henning Kopp<br>
Institute of Distributed Systems<br>
Ulm University, Germany<br>
<br>
Office: O27 - 3402<br>
Phone: <a href=3D"tel:%2B49%20731%2050-24138" value=3D"+497315024138">+49 7=
31 50-24138</a><br>
Web: <a href=3D"http://www.uni-ulm.de/in/vs/~kopp" rel=3D"noreferrer" targe=
t=3D"_blank">http://www.uni-ulm.de/in/vs/~<wbr>kopp</a><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>
</blockquote></div></div>

--f403045f14c25fc26d054eb5313b--