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
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3F51E360
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Jun 2016 00:42:43 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id C753BF5
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Jun 2016 00:42:41 +0000 (UTC)
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:61b6:56a6:b03d:28d6])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 52ECB38A17CB;
Thu, 2 Jun 2016 00:41:32 +0000 (UTC)
X-Hashcash: 1:25:160602:cp368202@ohiou.edu::e1GqcQWGY2NCotFZ:iuTnu
X-Hashcash: 1:25:160602:bitcoin-dev@lists.linuxfoundation.org::WJdDMsu=UutCJi7Y:BZQT
From: Luke Dashjr <luke@dashjr.org>
To: Chris Priest <cp368202@ohiou.edu>
Date: Thu, 2 Jun 2016 00:41:27 +0000
User-Agent: KMail/1.13.7 (Linux/4.1.18-gentoo; KDE/4.14.16; x86_64; ; )
References: <CAAcC9ysPMmTiEX3TS+=2t6FtNSYMXdz+h+qi=KQyTjS7CsbsxQ@mail.gmail.com>
In-Reply-To: <CAAcC9ysPMmTiEX3TS+=2t6FtNSYMXdz+h+qi=KQyTjS7CsbsxQ@mail.gmail.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201606020041.30139.luke@dashjr.org>
X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP draft: Memo server
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jun 2016 00:42:43 -0000
First of all, and most importantly, I like the idea/concept.
The first issue I see is that this scheme exposes private information in the
form of which inputs/outputs are related to the user. But IMO this information
should also be private and kept encrypted, so memo servers don't have anything
at all to leak.
Note this necessarily means you can't reuse the keys for the blockchain UTXOs
for memos. But such key reuse is also a risk that should be avoided anyway.
Instead, I suggest encrypting all the memos to an arbitrary key which is
derived from the HD seed and shouldn't ever be used for UTXOs.
Ideally, the memo server shouldn't be tied to a specific wallet schema. So the
next step is to not tell the memo server anything except your memo-specific
identifier (which can be a hash of a pubkey, or really anything at all -
there's no reason the memo server needs to know ANYTHING about the user's
wallet). Using an arbitrary identifier of sufficient length allows for future
wallet schemas to continue to use the same memo servers. (The specifics on how
to derive the identifier can be specified in a separate BIP to ensure wallets
can be compatible with each other.)
I don't think there is a real need for memo servers to sync data. It should be
sufficient for users to decide on two or more memo servers they wish to
entrust their memos with, or possibly trust only their own memo server(s).
There should probably also be a way for memos of different types. Some wallets
might only support simple memos, but others might associate more data for (eg)
proof-of-existence schemas. What types are used *might* be desirable to
encrypt as well, so this should probably be in the second "how wallets use it"
BIP.
IIRC, Electrum already has some kind of "memo server" interface in a plugin.
Have you looked at how it works, and considered its features (and/or flaws)
for your proposal?
Finally, using "?data&data&data" doesn't follow the standard
"?key=value&key=value" scheme; simple to fix.
Luke
On Thursday, June 02, 2016 12:21:54 AM Chris Priest via bitcoin-dev wrote:
> I'm currently working on a wallet called multiexplorer. You can check
> it at https://multiexplorer.com/wallet
>
> It supports all the BIPs, including the ones that lets you export and
> import based on a 12 word mnemonic. This lets you easily import
> addresses from one wallet to the next. For instance, you can
> copy+paste your 12 word mnemonic from Coinbase CoPay into
> Multiexplorer wallet and all of your address and transaction history
> is imported (except CoPay doesn't support altcoins, so it will just be
> your BTC balance that shows up). Its actually pretty cool, but not
> everything is transferred over.
>
> For instance, some people like to add little notes such as "paid sally
> for lunch at Taco Bell", or "Paid rent" to each transaction they make
> through their wallet's UI. When you export and import into another
> wallet these memos are lost, as there is no way for this data to be
> encoded into the mnemonic.
>
> For my next project, I want to make a stand alone system for archiving
> and serving these memos. After it's been built and every wallet
> supports the system, you should be able to move from one wallet by
> just copy+pasting the mnemonic into the next wallet without losing
> your memos. This will make it easier for people to move off of old
> wallets that may not be safe anymore, to more modern wallets with
> better security features. Some people may want to switch wallets, but
> since its much harder to backup memos, people may feel stuck using a
> certain wallet. This is bad because it creates lock in.
>
> I wrote up some details of how the system will work:
>
> https://github.com/priestc/bips/blob/master/memo-server.mediawiki
>
> Basically the memos are encrypted and then sent to a server where the
> memo is stored. An API exists that allows wallets to get the memos
> through an HTTPS interface. There isn't one single memo server, but
> multiple memo servers all ran by different people. These memo servers
> share data amongst each other through a sync process.
>
> The specifics of how the memos will be encrypted have not been set in
> stone yet. The memos will be publicly propagated, so it is important
> that they are encrypted strongly. I'm not a cryptography expert, so
> someone else has to decide on the scheme that is appropriate.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
