path: root/52/56fd2845199dc55ae1939dcf559226c6d3ded6

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pete@petertodd.org>) id 1W6jO8-0006ou-6v
	for bitcoin-development@lists.sourceforge.net;
	Fri, 24 Jan 2014 16:13:48 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.149.77 as permitted sender)
	client-ip=62.13.149.77; envelope-from=pete@petertodd.org;
	helo=outmail149077.authsmtp.com; 
Received: from outmail149077.authsmtp.com ([62.13.149.77])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1W6jO6-0002u1-QC for bitcoin-development@lists.sourceforge.net;
	Fri, 24 Jan 2014 16:13:48 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
	by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s0OGDam1042012;
	Fri, 24 Jan 2014 16:13:36 GMT
Received: from petertodd.org (petertodd.org [174.129.28.249])
	(authenticated bits=128)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s0OGDVx2026244
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Fri, 24 Jan 2014 16:13:33 GMT
Date: Fri, 24 Jan 2014 11:13:30 -0500
From: Peter Todd <pete@petertodd.org>
To: Adam Back <adam@cypherspace.org>
Message-ID: <20140124161330.GA31233@petertodd.org>
References: <CAAS2fgQmsxjkQFSiCdeMoVMaqq5720KpUpdkKZOE+XytHsWw0w@mail.gmail.com>
	<20140124090218.GA15398@savin>
	<CANEZrP0MnXr4xjaMPg7v7vTiDQr-y7esvEBE=xk=Y0BUGXak9A@mail.gmail.com>
	<20140124154235.GA3741@netbook.cypherspace.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP"
Content-Disposition: inline
In-Reply-To: <20140124154235.GA3741@netbook.cypherspace.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 79206bff-8512-11e3-94fa-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aQdMdAYUElQaAgsB AmIbWlJeUV57WmA7 ag1VcwRfa1RMVxto
	VEFWR1pVCwQmQhx+ cWp4GhtydQNEfHo+ Z05iVngVW014dUAv
	FBhJHWgHZ3phaTUc TUlcIVJJcANIexZF O1F8UScOLwdSbGoL
	NQ4vNDcwO3BTJTpY RgYVKF8UXXNDNDc9 W1gMGi9nB0AYXCw5
	KxFuI1IQBksKKUgp WQAA
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 174.129.28.249/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	-0.0 SPF_PASS               SPF: sender matches SPF record
X-Headers-End: 1W6jO6-0002u1-QC
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bait for reusable addresses
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 24 Jan 2014 16:13:48 -0000


--jRHKVT23PllUwdXP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 24, 2014 at 04:42:35PM +0100, Adam Back wrote:
> 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.

You know, we've made this discussion rather confusing because we're
using the term "prefix" for both prefix filters - which are equivalent
to bloom filters but with better scalability - and the act of forcing a
scriptPubKey to match some given prefix. I suggest we call the latter
concept 'wallet clustering' as it can just as easily be applied to bloom
filters, as well as Gregory Maxwell's candidate bait scheme, and for
that matter, prefix filters with a tweak option, e.g. H(scriptPubKey |
nTweak)

So yeah, clustering schemes make network flow analysis easier if the
attacker only has blockchain data to work from. But they can also make
network flow analysis significantly harder for attackers that have query
logs from attackers running nodes, and as we know sybiling the network
to get query logs is very easy. I'd rather develop systems that don't
fail catastrophically against sybil attack.

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

The hostile network is likely to have a significant percentage of
hostile, query-logging nodes. For one thing, running nodes is expensive
and would be even more so in a blocksize limit raising scenario, and a
easy way to pay those costs is by selling query data.

> 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 r=
isk
> search (which is even good as Jeremey said for your own node, in a offline
> wallet use case).

Sure, in some cases you can use zero-length prefixes with trusted nodes;
not many users have access to such nodes.

> 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 i=
t).
>=20
> 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 interacti=
ve
> one-use address release.

Conversely, it'd be interesting if someone can dig up a proof showing
that doing much better than Gregory's ambiguity tradeoff is impossible.
My gut feeling is that it is, especially if you take into account the
desire for scalability - if we're to make the blocksize bigger assuming
all nodes have all data for every block just isn't going to happen.

> Maybe we should ask some math/theoretical crypto people if there is anyth=
ing
> like public key watermarking or something that could solve this problem
> efficiently.

Yes, and I think such schemes should be pursued. But in the near-term
what can we offer users?

Remember that making stealth addresses and similar clustering-using
schemes capable of backward compatible upgrades isn't hard; if the
crypto is found later it can be adopted.

What is harder is that people want miners to commit to various types of
indexes - changing those indexes would require a soft-fork and there's
much pressure for those indexes to have very good performance
properties.

> For the related but different case of transaction level authenticity I li=
ke
> Alan's server derived but communicated scalar & base to allow the client =
to
> do at least TOFU.
>=20
> Payment protocol may add another level of identity framework on top of TO=
FU
> 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 onli=
ne
> somewhere (an add on with similar purpose and effect to Alan's TOFU, but
> then with revocation, identity and certification for merchants).

Note how well the OpenPGP + bitcoin address UID ideas I and others have
been talking about meshes with TOFU: the logic for "Do I trust this
address to send money?" and "Do I trust this PGP key to send more
encrypted mail/verify signatures?" is just different questions about the
same human identity, so combining the two is synergistic. For instance I
might want to communicate securely with a friend via email and also send
funds to them securely.

An interesting nuance is ideally that UID can be used for more than just
a single address type, e.g. BIP32 derivation chains can the same root
pubkeys as stealth addresses. Though I don't know if the added
complexity is worthwhile vs. just adding another UID for the BIP32
derivation case.

--=20
'peter'[:-1]@petertodd.org
0000000000000001a2aeb2101283cb4e35d4a038b38a72a21af5092d8d8c9d2e

--jRHKVT23PllUwdXP
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJS4pEqAAoJEBmcgzuo5/CFipcIAKyQKoyYI+TgUf6ahioDo3fO
iNrJlbxoA1CC6RZbB8U966ND1L+vyWO9KJo4yFmFtSX53/RznBmiZ7fl7NVx1eD4
J0owST7aFxApx1fjPJfOg5qVXhxMbMQls2YYfYfbtZ3aNbaYJSUIcL6UYaCRfEiN
p6cAMDAAA37ZZTWtZajQJ/ijiu8sg+42UNL+EV+utnMuXp9Ilfy/MrQ+US/Cx3i8
X5DOV5gLcbigXQxkmoXkgnRW1GfQBeioH8AkaN3f2qCNCSe89ewn+XlNBWERptdZ
V24GqK3vpAi67eTnn1yqkAOienM8PGxAgG2LPKJR8BK9oTKKlJ+W4wu/wJXNIsc=
=qeRu
-----END PGP SIGNATURE-----

--jRHKVT23PllUwdXP--