To: Chris Pacia <ctpacia@gmail.com>
References: <20170504125138.GA2027@banane.informatik.uni-ulm.de>
	<CAB+qUq56a7-6B=-WVYUC2xoYADg+pnwje7ZSff3T4XBdAdUMkg@mail.gmail.com>
From: Henning Kopp <henning.kopp@uni-ulm.de>
Message-ID: <4f96caa7-5150-b7da-45a5-bf8502b60205@uni-ulm.de>
Date: Sat, 6 May 2017 11:38:06 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
	Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAB+qUq56a7-6B=-WVYUC2xoYADg+pnwje7ZSff3T4XBdAdUMkg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-DCC-sonic.net-Metrics: poseidon 1156; Body=2 Fuz1=2 Fuz2=2
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE, 
	RP_MATCHES_RCVD autolearn=ham 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: Sat, 06 May 2017 09:38:22 -0000

Sorry, I cannot quite follow you. What do you mean with flag?

Best,
Henning


Am 04.05.2017 um 18:23 schrieb Chris Pacia:
> 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
>>
>