public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Luke Dashjr <luke@dashjr•org>
To: Chris Priest <cp368202@ohiou•edu>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP draft: Memo server
Date: Thu, 2 Jun 2016 00:41:27 +0000	[thread overview]
Message-ID: <201606020041.30139.luke@dashjr.org> (raw)
In-Reply-To: <CAAcC9ysPMmTiEX3TS+=2t6FtNSYMXdz+h+qi=KQyTjS7CsbsxQ@mail.gmail.com>

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


      reply	other threads:[~2016-06-02  0:42 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-02  0:21 Chris Priest
2016-06-02  0:41 ` Luke Dashjr [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201606020041.30139.luke@dashjr.org \
    --to=luke@dashjr$(echo .)org \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=cp368202@ohiou$(echo .)edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox