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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1XFAi3-0002hT-DP
for bitcoin-development@lists.sourceforge.net;
Wed, 06 Aug 2014 23:33:31 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.101 as permitted sender)
client-ip=62.13.148.101; envelope-from=pete@petertodd.org;
helo=outmail148101.authsmtp.com;
Received: from outmail148101.authsmtp.com ([62.13.148.101])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1XFAi1-0004WP-Ln for bitcoin-development@lists.sourceforge.net;
Wed, 06 Aug 2014 23:33:31 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s76NXNwv059067;
Thu, 7 Aug 2014 00:33:23 +0100 (BST)
Received: from localhost.localdomain (tor-exit-01.thehappy3.com [178.63.97.34])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s76NXCgQ067038
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Thu, 7 Aug 2014 00:33:19 +0100 (BST)
Date: Wed, 6 Aug 2014 23:33:09 +0000
From: Peter Todd <pete@petertodd.org>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Message-ID: <20140806233309.GB9272@localhost.localdomain>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="f2QGlHpHGjS2mn6Y"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 0dcc07cc-1dc2-11e4-9f74-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdgUUGUATAgsB AmIbW1ReU157W2E7 ag1ZcwNefENJQQZu
T01BRU1TWkZvB2Jp dUl/Uh91dwZONn9w YERmEHAPDxd6chUu
X08ARm8bZGY1bH0W BkdcagNUcgZDfk5E aVUrVz1tMCxaMyQk
Vy4fd3t+Jn1RLz4d eR0AJFYOQQ4iEjIm SgsZEC5H
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 178.63.97.34/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: 1XFAi1-0004WP-Ln
Subject: [Bitcoin-development] Payment ID #'s for Stealth 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: Wed, 06 Aug 2014 23:33:31 -0000
--f2QGlHpHGjS2mn6Y
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Real-world experience with stealth address implementations used by
Cryptonote/Monero/etc. have shown that being able to attach a number of
some kind to each stealth-sent txout is valuable. For instance an
exchange with many customers can use such #'s to disambiguate payments
and credit the correct customer's account. Similarly an informal
person-to-person transaction can attach a number short enough to be
communicated verbally or on paper. Finally multiple payments with the
same ID # can be merged together in wallet UI's, allowing
merge-avoidance to be conveniently used with stealth addresses.
To avoid accidental collision such payment #'s should be at least
64-bits; to avoid privacy loss the encoded size should be the same for
all users. Thus we pick 64-bits or 8-bytes. In addition for the purposes
of CoinJoin and multiple outputs it would be desirable for all
stealth-using outputs the option of sharing a single 33-byte ephemeral
pubkey. Thus our OP_RETURN output becomes:
OP_RETURN <ephemeral pubkey> <payment ID 1> {<ID 2> ... <ID n>}
Of course, this can't be accomodated within the existing 40-byte, one
OP_RETURN per tx, IsStandard() rules, something which is already causing
issues w/ Dark Wallet when users try to send to multiple stealth
addresses at once, and when multiple stealth sends are CoinJoin'd
together.
1) "Merge avoidance", Dec 11th 2013, Mike Hearn,
https://medium.com/@octskyward/merge-avoidance-7f95a386692f
--f2QGlHpHGjS2mn6Y
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCgAGBQJT4rsrAAoJEH+rEUJn5PoEABQH/37VgBgyjzeEcOlIw58R+NlM
S7xm2/Z6twLylVByINopLoGJu5nQMUO8MARg/4jmFXCsPNcznMNHlsA/EdwU+tce
sBdHA5q++dmzhFy2XpyLt7S3zeLqH7j9lzrvCq7JLth+iawVqmH0clT8NZLgppuJ
3Az3RMunLZPAA4BeQpeQHhm6cDCFFuL4CNdNFpCIqbglyOsBLlx0+cuQDT24XNnG
0UIs+Ewttw5QQ28e6uy7p9J7mzo5lViRi6TYbA2FQSmUfDVltr7S5wJtjN6LIBgO
neBVk57wHSejUyknCYPv/3PjD5rcc/tlU7nC/6EBd+DyF8836JKdzP51A0iUJo0=
=Jk/r
-----END PGP SIGNATURE-----
--f2QGlHpHGjS2mn6Y--
|
