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
|
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 <gmaxwell@gmail.com>) id 1YlkgQ-0007nl-7l
for bitcoin-development@lists.sourceforge.net;
Fri, 24 Apr 2015 20:58:46 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.170 as permitted sender)
client-ip=209.85.213.170; envelope-from=gmaxwell@gmail.com;
helo=mail-ig0-f170.google.com;
Received: from mail-ig0-f170.google.com ([209.85.213.170])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YlkgO-0002Pg-MY
for bitcoin-development@lists.sourceforge.net;
Fri, 24 Apr 2015 20:58:46 +0000
Received: by igbpi8 with SMTP id pi8so35693219igb.0
for <bitcoin-development@lists.sourceforge.net>;
Fri, 24 Apr 2015 13:58:39 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.107.7.87 with SMTP id 84mr420879ioh.76.1429909119387; Fri,
24 Apr 2015 13:58:39 -0700 (PDT)
Received: by 10.107.15.82 with HTTP; Fri, 24 Apr 2015 13:58:39 -0700 (PDT)
In-Reply-To: <CAHabJ+Mn0=vfLvTJ+z3tx8cFAAuLD1pLp4rOe3pM6MtCrCxjwg@mail.gmail.com>
References: <CAHabJ+Mn0=vfLvTJ+z3tx8cFAAuLD1pLp4rOe3pM6MtCrCxjwg@mail.gmail.com>
Date: Fri, 24 Apr 2015 20:58:39 +0000
Message-ID: <CAAS2fgRVcwNfYv8fnoS_uRtDoGqRiWAXcPgaK8if8FO_G6LQoQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Justus Ranvier <justus.ranvier@monetas.net>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.6 (-)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1YlkgO-0002Pg-MY
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Reusable payment codes
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 Apr 2015 20:58:46 -0000
On Fri, Apr 24, 2015 at 8:00 PM, Justus Ranvier
<justus.ranvier@monetas.net> wrote:
> https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki
>
> This link contains an RFC for a new type of Bitcoin address called a
> "payment code"
>
> Payment codes are SPV-friendly alternatives to DarkWallet-style stealth
> addresses which provide useful features such as positively identifying
> senders to recipients and automatically providing for transaction refunds.
So this requires making dust payments to a constantly reused address
in order to (ab)use the blockchain as a messaging layer.
Indeed, this is more SPV compatible; but it seems likely to me that
_in practice_ it would almost completely undermine the privacy the
idea hoped to provide; because you'd have an observable linkage to a
highly reused address.
It would also more than double the data sent for the application where
'stealth addresses' are most important: one-time anonymous donations
(in other contexts; you have two way communication between the
participants, and so you can just given them a one off address without
singling in the public network.)
> Alice selects the first exposed public key of the first input of the transaction
So this creates strong "binding" that we would really strongly like to
avoid in the network; basically what this says is that "You can only
pay to person X if you use scheme Y for your own Bitcoins"-- who says
any of your inputs have a ECDH pubkey at all? Of if they do, who says
its one that you have access to the private key for for use in this
scheme (e.g. it could be in a HSM that only signs according to a
policy). We should avoid creating txout features that restrict what
kind of scriptPubkey the sender can use, or otherwise we'll never be
able to deploy new signature features. (We can see how long P2SH took
to gain adoption because some wallets refused to implement sending to
it, even though doing so was trivial).
This kind of binding was intentionally designed out of the stealth
address proposal; I think this scheme can be made to work without any
increase in size by reusing the payment code as the ephemeral public
key (or actually being substantially smaller e.g. use the shared
secret as the chain code, but I should give it more thought)
Also, SPV wallets do not need to have access to the public keys being
spent by a particular transaction they learn about; providing that
access is fundamentally expensive and pushes things back towards
centralization.
> in uncompressed DER format
This is fundamentally more expensive to compute; please don't specify
"uncompressed".
This appears incompatible with multisignature; which is unfortunate.
I do very much like the fact that this scheme establishes a shared
chain once and then doesn't need to reestablish; this was one of the
improvements I wanted for the stealth address.
I'm disappointed that there isn't any thought given to solving the
scanning privacy without forcing non-private pure-overhead messaging
transactions on heavily reused addresses. Are you aware of the IBE
approach that allows someone to request a third party scan for them
with block by block control over their delegation of scanning?
|
