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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jeremy@taplink.co>) id 1W5Scm-0006gH-6u
for bitcoin-development@lists.sourceforge.net;
Tue, 21 Jan 2014 04:07:40 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of taplink.co
designates 50.117.27.232 as permitted sender)
client-ip=50.117.27.232; envelope-from=jeremy@taplink.co;
helo=mail.taplink.co;
Received: from mail.taplink.co ([50.117.27.232])
by sog-mx-4.v43.ch3.sourceforge.com with smtp (Exim 4.76)
id 1W5Scl-0007Vo-9z for bitcoin-development@lists.sourceforge.net;
Tue, 21 Jan 2014 04:07:40 +0000
Received: from laptop-air ([192.168.168.135]) by mail.taplink.co ;
Mon, 20 Jan 2014 20:12:06 -0800
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: "Gregory Maxwell" <gmaxwell@gmail.com>
References: <CABsx9T2G=yqSUGr0+Ju5-z9P++uS20AwLC+c3DnFMHtcQjQK6w@mail.gmail.com>
<CAAS2fgTz0TaGhym_35V3N2-vHVzU9BeuV8q+QJjwh5bg77FEZg@mail.gmail.com>
<CANEZrP0huBWqgvQik9Yc26Tu4CwR0VSXcfC+qfzsZqvoU4VJGA@mail.gmail.com>
<20140113133746.GI38964@giles.gnomon.org.uk>
<CANEZrP1KAVhi_-cxCYe0rR9LUSYJ8MyW8=6eSJZ65FeY5ZJNuQ@mail.gmail.com>
<20140114225321.GT38964@giles.gnomon.org.uk>
<CANAnSg0tH_bK_19rsRRHOeZgrGYeWMhW89fXPyS4DQGmS4r_7A@mail.gmail.com>
<CALimQCXgc0eXeOcqFGUaCpSF7gKEe87KzvLqHZwUysV3WyjjGw@mail.gmail.com>
<CAAS2fgShChAQryfUOBp60jB-zxn2tH986fu1HfT+LsNdBYnoYg@mail.gmail.com>
<CAJHLa0P5r2+kxy7w8G=h=TAhdk1jUoW5UOiv-euo47uQY0u9ZA@mail.gmail.com>
<20140115230901.GA25135@netbook.cypherspace.org>
<op.w9q85wkhyldrnw@laptop-air.hsd1.ca.comcast.net>
<CAAS2fgTRKgkO15VUvVgttP-iEBNF4=G+++Xo-XsaRBmOxyXXKA@mail.gmail.com>
Date: Mon, 20 Jan 2014 20:00:05 -0800
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Jeremy Spilman" <jeremy@taplink.co>
Organization: TapLink
Message-ID: <op.w90qqfh4yldrnw@laptop-air>
In-Reply-To: <CAAS2fgTRKgkO15VUvVgttP-iEBNF4=G+++Xo-XsaRBmOxyXXKA@mail.gmail.com>
User-Agent: Opera Mail/1.0 (Win32)
oclient: 192.168.168.135#jeremy@taplink.co#465
X-Spam-Score: -2.2 (--)
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
-0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1W5Scl-0007Vo-9z
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] unlinakble static address? & spv-privacy
(Re: 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: Tue, 21 Jan 2014 04:07:40 -0000
On Wed, 15 Jan 2014 17:32:31 -0800, Gregory Maxwell <gmaxwell@gmail.com>
wrote:
> I'd point out that regardless of how long the desired prefix is, the
> encoded prefix should probably always be constant length in all
> reusable addresses.
I might be misunderstanding, but I think prefix length must be specified
in the reusable address, however I agree the prefix actually published to
the blockchain should be constant length.
> If you don't want a particular prefix then the
> sender should just pick random data for the rest of the space. There
> is no need to publish any additional distinguishing data in the form
> of how long the prefix is.
Let's say the payee's reusable address is '<version> <prefix> <Q1> <Q2>
...', where <prefix> is 2 bytes. Without any length indicator. What's the
payer going to put on the blockchain? How would they know what the 'rest
of the space' is? They would have to put the whole <prefix> verbatim into
the OP_RETURN without knowing how many bits of <prefix> the payee actually
wants to see there.
If instead, the address is '<version> <prefix> <prefixLen> <Q1> <Q2> ...'
where <prefix> is 2 bytes, and <prefixLen> is 1 byte, representing number
of bits of prefix that should be fixed.
Then payer will know how much of <prefix> from the address should be taken
verbatim, and the rest of the two bytes would be replaced with random
data, and exactly two bytes would be put in the OP_RETURN.
If <prefixLen> was zero, the 2 byte prefix in the reusable address must be
ignored, and an entirely random 2 byte prefix would be put into the
OP_RETURN.
I'm a bit worried about broken implementations copying the <prefix> from
the reusable address into OP_RETURN when <prefixLen> is 0, and ending up
basically identifying the payee. That's the only reason I can think of to
make '<prefix> <prefixLen>' optional in the reusable address, to prevent
the opportunity to screw it up. You would *still* put a 2-byte random
prefix in the OP_RETURN, even if the fields weren't in the address at all.
It's just a minor concern though.
|
