[bitcoin-dev] BIP draft: Memo server

[Luke Dashjr]

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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev