public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Henning Kopp <henning.kopp@uni-ulm.de>
To: Chris Pacia <ctpacia@gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Combining SPV and Stealth addresses
Date: Sat, 6 May 2017 11:38:06 +0200	[thread overview]
Message-ID: <4f96caa7-5150-b7da-45a5-bf8502b60205@uni-ulm.de> (raw)
In-Reply-To: <CAB+qUq56a7-6B=-WVYUC2xoYADg+pnwje7ZSff3T4XBdAdUMkg@mail.gmail.com>

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



      reply	other threads:[~2017-05-06  9:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-04 12:51 [bitcoin-dev] Combining SPV and Stealth addresses Henning Kopp
2017-05-04 16:23 ` Chris Pacia
2017-05-06  9:38   ` Henning Kopp [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=4f96caa7-5150-b7da-45a5-bf8502b60205@uni-ulm.de \
    --to=henning.kopp@uni-ulm.de \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=ctpacia@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