1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1VzBXA-0007MJ-Ug
for bitcoin-development@lists.sourceforge.net;
Fri, 03 Jan 2014 20:39:56 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.55 as permitted sender)
client-ip=62.13.149.55; envelope-from=pete@petertodd.org;
helo=outmail149055.authsmtp.co.uk;
Received: from outmail149055.authsmtp.co.uk ([62.13.149.55])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VzBX9-0001Ha-GO for bitcoin-development@lists.sourceforge.net;
Fri, 03 Jan 2014 20:39:56 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s03KdjxR051444;
Fri, 3 Jan 2014 20:39:45 GMT
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s03KdeoF056382
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Fri, 3 Jan 2014 20:39:42 GMT
Date: Fri, 3 Jan 2014 15:39:39 -0500
From: Peter Todd <pete@petertodd.org>
To: Adam Back <adam@cypherspace.org>
Message-ID: <20140103203939.GA30273@savin>
References: <CAGXD5f2_E82kEqsGGrhiywGogVCbR8vzs7q51=Luaq2ZEzGBtA@mail.gmail.com>
<CAAS2fgQ8M6=Utj7SBpN4Fiv6rgBKvZfm5jpmwkFRuFsZYZLqHQ@mail.gmail.com>
<20140103202320.GA16515@netbook.cypherspace.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="5vNYLRcllDrimb99"
Content-Disposition: inline
In-Reply-To: <20140103202320.GA16515@netbook.cypherspace.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 2cff2b8d-74b7-11e3-94fa-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdgEUElQaAgsB AmIbWVReU1R7XWA7 bAxPbAVDY01GQQRq
WVdMSlVNFUsrAR96 UktBJBl3cQZOejBx Y0FlXD5ZDxIsdxR1
FlNTET8BeGZhPWMC WUQOJh5UcAFPdx8U a1N6AHBDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4iGHY9 Sx0LVTsoBwUMQzk+
NRovNl8CEQ4JO1Q3 PF09EUkTMxIXB2UA
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/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: 1VzBX9-0001Ha-GO
Cc: bitcoin-development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] An idea for alternative payment scheme
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, 03 Jan 2014 20:39:57 -0000
--5vNYLRcllDrimb99
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Jan 03, 2014 at 09:23:20PM +0100, Adam Back wrote:
> Seems like you (Nadav) are the third person to reinvent this idea so far =
:)
Lol, fourth if you include me, although my case is rather embarassing as
I had re-read Bytecoin's original post recently and completely missed
the main point of it!
> I wrote up some of the post-Bytecoin variants here:
>=20
> https://bitcointalk.org/index.php?topic=3D317835.msg4103530#msg4103530
>=20
> The general limitation so far is its not SPV compatible, so the recipient
> has to test each payment to see if its one he can compute the private key
> for. Or the sender has to send the recipient out of band the derivation
> key.
Actually I think it has the potential to be *more* SPV compatible than
the alternative, as in conjunction with prefix filters it lets you
receive unlimited unrelated payments that you can find in the blockchain
with a single prefix query with a fixed bandwidth/anonymity set size
tradeoff. (obviously in conjunction with one of the many ways of tagging
transactions for more efficient search)
The BIP38 approach with UI's that make it easy to create a new address
for every payment on the other hand force you to either accept higher
bandwidth consumption, or decrease your anonymity set size, or lose
payments. (inclusive)
I've got a post talking about this in more detail as well as an overview
of bloom filters vs. prefix filters that I'll publish tomorrow. (tl;dr:
bloom filters have very poor O(n^2) scalability and should be
depreciated)
> However at present most of the bitcoin infrastructure is using the bitcoin
> broadcast channel as the communication channel, which also supports payer
> and payee not being simultaneously online. You have to be careful also n=
ot
> to lose the key. You dont want a subsequent payer data loss event to lose
> money for the recipient. You want the message to be sent atomically.
>=20
> It does seem like a very attractive proposition to be able to fix the
> address reuse issue. Admonishment to not reuse addresses doesnt seem to
> have been successful so far, and there are multiple widely used wallets t=
hat
> reuse addresses (probably in part because they didnt implement HD wallets
> and so are scared of losing addresses due to backup failure risks of non =
HD
> wallets and fresh addresses).
--=20
'peter'[:-1]@petertodd.org
0000000000000001a96469654430aa06e4ae7c7328a7eb848c6fc63443f24e4a
--5vNYLRcllDrimb99
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQGrBAEBCACVBQJSxyALXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDMwNjVmMzJkYTI2ZGUxZGVkYTkzZWI3MjJiZjFkYzRhMWI3
ODdlN2Q2OGQyODJkYmMvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfvbAwgAshgdy9cKqvFyUybeJ9uG2ILX
IFnCWPTHsgj0wpD9Za7MHqCYTZQTqLGS+9If0OGtDPnk3pkBI+fUndK70zZbKNRn
ILjUwFa1klofRs/mfcAaUqTDo6O31AbknoQt8dTBxoEZHqVrIwgbPMH/uIie6Vmc
ueYNLclH0jKsp2z9ihirpfvgX9zEqYR9Tu2fWogq7MocgXvN93zSXiodt0n7jzrd
Zmm4ZMrX+fwQ1mCYlPrrIe3m+g1sGOOt5Vkg73ZmICDKAU2RwlDuwH6eoWVTYOI0
w7GhRQZ6zuEDXeIiVm5bF9I8RrFDgg9fLqE9WyzE+AGSHEK1zQ6fGWb1XT/YkA==
=85xT
-----END PGP SIGNATURE-----
--5vNYLRcllDrimb99--
|
