From: Adam Back <adam@cypherspace•org>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Bait for reusable addresses
Date: Fri, 24 Jan 2014 16:42:35 +0100 [thread overview]
Message-ID: <20140124154235.GA3741@netbook.cypherspace.org> (raw)
In-Reply-To: <CANEZrP0MnXr4xjaMPg7v7vTiDQr-y7esvEBE=xk=Y0BUGXak9A@mail.gmail.com>
I think prefix has analysis side effects. There are (at least) 4 things
that link payments: the graph of payment flows, timing, precise amounts, IP
addresses, but with prefix a 5th: the prefix allows public elmination of
candidates connections, I think that may make network flow analysis even
more effective than it has been.
So SPV can be tuned as Mike just said, and as Greg pointed out somewhere
bloom is more private than prefix because its a wallet to node connection,
not a node broadcast, and Mike mentioned embedded Tor in another post to
boost node-capture issues with hostile network.
So reusable addresses are cool for full node recipients (0-bit prefix) or
trusted server offload (your own desktop, VPS, or trusted service provider
node, and solve real problems for the use case of static and donation
addresses particularly with this second delegatable key for no-funds at risk
search (which is even good as Jeremey said for your own node, in a offline
wallet use case).
Now while it would be clearly a very nice win if reusable addresses could be
made SPV-like in network characteristics and privacy, but we dont have a
plausible mechanism yet IMO. Close as we got was Greg's enhancement of
my/your "bloom bait"/"prefix" concept to make multiple candidate baits to
provide some ambiguity (still allows elimination, just slightly less of it).
If we can find some efficient crypto to solve that last one, we could even
adopt them generally if it was efficient enough without needing interactive
one-use address release.
Maybe we should ask some math/theoretical crypto people if there is anything
like public key watermarking or something that could solve this problem
efficiently.
For the related but different case of transaction level authenticity I like
Alan's server derived but communicated scalar & base to allow the client to
do at least TOFU.
Payment protocol may add another level of identity framework on top of TOFU
addresses (at a lower level than the payment messages defined now), and
without then needing a batch upload of offline signed secondary address
sigature that Mike described a while back, at least in person, maybe online
somewhere (an add on with similar purpose and effect to Alan's TOFU, but
then with revocation, identity and certification for merchants).
I have not talked about payment protocols main app level function I think we
all understand and agree on the purpose and use of the server and optional
client certs in that. People may wish to add other cert types later (eg
PGP, SSH etc) but this version covers the common merchant tech, and allows
client-side certs to be experimented with for identity also (eg imagine as a
way to enrol with regulated entities like exchanges.)
Tell me if I am misunderstanding anything :)
Adam
On Fri, Jan 24, 2014 at 12:26:19PM +0000, Mike Hearn wrote:
> brittleness. The real world experience is that users, or to be exact
> wallet authors, turn down SPV privacy parameters until bloom filters
> have almost no privacy in exchange for little bandwidth usage.
>
> That's not fundamental though, it just reflects that the only
> implementation of this is used on a wide range of devices and doesn't
> yet have any notion of bandwidth modes or monitoring. It can and will
> be resolved at some point.Â
next prev parent reply other threads:[~2014-01-24 15:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-16 1:23 Gregory Maxwell
2014-01-24 9:02 ` Peter Todd
2014-01-24 12:26 ` Mike Hearn
2014-01-24 15:26 ` Peter Todd
2014-01-24 21:58 ` Jeremy Spilman
2014-01-24 23:15 ` Mike Hearn
2014-01-24 15:42 ` Adam Back [this message]
2014-01-24 16:13 ` Peter Todd
2014-01-25 16:19 ` [Bitcoin-development] (space) efficient reusable addr via weil pairing IBE (Re: Bait for reusable addresses) Adam Back
2014-02-02 2:36 ` Peter Todd
2014-02-02 9:16 ` Jeremy Spilman
2014-02-02 12:26 ` Peter Todd
2014-02-02 15:26 ` Adam Back
2014-02-02 11:55 ` Peter Todd
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=20140124154235.GA3741@netbook.cypherspace.org \
--to=adam@cypherspace$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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