-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Idea: The Bitcoin Banking Project
Abstract: The Bitcoin Banking Project (BBP) is an open source bank software
package (client and server) that aims to implement a form of "federated"
banking for Bitcoin. The primary goal is to eliminate as many sources of
errors that cause lost or stolen Bitcoins as possible.
Foundation: BBP is separated into three pieces, the client source code that executes
in a typical web browser, the server that responds to client requests, and the
distributed network application that connects to other banking peers, processes
long-standing requests, etc.
Setup: User logs into a publicly available BBP server -- or downloads and
configures his own -- and is greeted with an easy to use several-step process
that walks the user through creating an account. The process would resemble
something like this:
1. The user is required to enter a password. The password must be
sufficently secure. Typical measures are provided to help the user recover
the password in case of loss. 2-Factor Authentication could be provided if
it were something of interest, though may not be useful due to the nature
of the design of this project.
The users password is hashed in accordance with BIP32 (see my BIP32 stuff
at
https://github.com/sarchar/brainwallet.github.com/tree/bip32gen) to produce
master extended private key MASTER_KEY_USER_PW. Perhaps different hashing
mechanisms would be useful to help alleviate brute-force attacks on a user's
password.
Next, the client code then uses secure random number generation to produce
a second key, which forms another master extended private key
MASTER_KEY_CLIENT.
2. The MASTER_KEY_CLIENT is turned into a set of words (like Multibit's 12-word
paper wallet backup) and the user is prompted to print or write the words
onto paper and store them in a safe location.
Other options: BIP38 encrypted private key + QR code can be printed.
Whatever option is used here isn't important, but what's important is
that the user is walked through creating an offline backup of
MASTER_KEY_CLIENT. It must be stressed that this MUST be done. No
exceptions. If the user decides not to create this paper backup, he is
putting his money at risk of accidental loss.
While #2 is happening, the server also uses secure random number generation
to generate a third master extended private key, MASTER_KEY_SERVER. This
key is unique to each user of the system, and it is never shared with the
client frontend.
It's important to note here that neither MASTER_KEY_CLIENT nor
MASTER_KEY_USER_PW are ever seen by the server, and the client never sees
MASTER_KEY_SERVER.
At this point we have three keys. The client will turn the two keys it knows
into master public keys: MASTER_PUB_USER_PW and MASTER_PUB_CLIENT and sends
these keys to the server. The server responds by returning MASTER_PUB_SERVER.
These three public keys form what I call a Master Public Key Package:
Master Public Key Package =
(MASTER_PUB_USER_PW, MASTER_PUB_CLIENT, MASTER_PUB_SERVER)
The client code now completely forgets MASTER_KEY_CLIENT and through the
use of BIP32 (using the same derivation channel on each master public key),
we can now produce a chain of multisignature addresses. BBP will *only* use
2 of 3 multisignature addresses, for every user, for every transaction.
The master public key package is built only of public information, so the
public key package ought to be stored in as many places as possible.
3. The user is walked through the process of creating a backup of the master
public key package in several places: one copy is sent to his email, another
copy is printed out and stored with MASTER_KEY_CLIENT, another copy is stored
on the server's database, and other locations as wanted.
4. The user is brought into his "wallet" home page, where he can make the
typical pay/receive actions related to standard wallet functionality.
Features:
* The server can create new deposit addresses for the user, without the user ever
needing to disclose private keys. If the user is offline or away, yet someone
wishes to send him money, the payer requests from the server, "give me an
address for user XYZ", and the server happy responds with a new address based
on BIP32 key derivation.
* Every transaction occurs in 2 of 3 Multisignature P2SH space and because there are
only two keys required to spend (out of three), we have the following safety net:
1. If the user forgets his password and is unable to recover it, his paper
key backup plus the server key will allow him access to his funds.
2. If the paper key backup is lost or stolen, a new one can be produced and
his funds transfer to a new chain of addresses.
3. If the server goes out of commission for any reason whatsoever (hacked,
taken down, etc.), then the users funds are safe and still accessible
from the paper key backup and his password.
* The server cannot steal the users Bitcoins because the server only has one key
and two are required to spend.
* Transactions are created by the client and partially signed with the correct derived key
before being sent to the server, which then signs and broadcasts the transaction.
* If the advanced user is concerned about trust or privacy, he can download and
configure his own server.
The distributed part:
Along with the above advanced Bitcoin features, the BBP should also implement
CoinJoin (see
https://bitcointalksearch.org/topic/coinjoin-bitcoin-privacy-for-the-real-world-279249) by default on
every transaction.
This means it makes sense to have a daemon process running alongside the server
that connects to other nodes in the BBP network. This network is where CoinJoin
transactions can be discovered and built. A paranoid user would configure Tor
and the BBP will happily proxy through that.
A message is broadcast to the network declaring "I want to pay XYZ to ABC.
Contact me." whenever a user wishes to spend. Meanwhile, all the nodes in the
network are building a collection of who wants to pay what. When a server is
ready to broadcast a transaction, he searches his list of 'who wants to pay
what' and starts directly talking to those machines, building a CoinJoin
transaction and signing along the way. This means that a user's transaction
will take longer to be sent, but with the benefit that it helps anonymize
his activity in the network. Chaum-blind signatures could be used to further
anonymize behavior.
Perhaps obviously, because the BBP server can be used by multiple users, a
CoinJoin transaction can be built using only the transactions being executed
within the same server.
The daemon should also connect to the Bitcoin network to monitor transactions
and new blocks. A new server doesn't need to download the entire blockchain
because there's no need to have the current UTXO set. The server could start
with downloading headers-only up until "today" and then download full blocks
after that point, storing only the relevant transactions to users within the
server's database and discarding the rest of the block.
Other thoughts:
* Monetizaiton wouldn't be too hard: be the first player in the game with
a notable domain name and the average user will use your site. Ad revenue
seems like the most common sense source.
* Using a public-key signature scheme, two separate servers could arrange
addresses for users through the distributed network and you could theoretically
implement a system that allows you to send money using an E-mail address
as the recipient:
User A on server S wants to send User B on server T some money. User A
builds a BBP-specific transaction that sends money to "B@T". The daemon
on server S queries the network with "I need an address for B@T." If
T sees the message, T responds with an address for B and a signature
proving the address really belongs to B.
Care would have to be taken in determining the right signature scheme for
this to work.
* The daemon + server + client could be packaged into a single executable. User
downloads the program, runs it, and connects to
http://localhost:1234/.
* Someone could pre-package server + client + daemon onto an embedded system or
Raspberry Pi-like device, and sell it as an all-in-one wallet solution.
* Derived accounts:
Support you're BigBussinessAccount on a server, and you want to give
AccountingAccount an account of their own using company funds. You could
derive a set of private keys from the master public key package and create a
new user account based on these derived private keys. BigBusinessAccount can
see and spend AccountingAccount's funds, but not the other way around.
* Account info in the cloud:
A scheme could be devised so that user account information is stored all
in the Bitcoin or Namecoin blockchain, thus making the server completely
neutral. A user could log into *any* BBP server so that if a server ever
goes offline, a user can access his account on any other server trivially.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJSvlD6AAoJEBSq1Xfbtr1cJ70H/R9jvBU6W4jnbey9I7mvord+
UCdsV7igPIl7pYMNdntnh+cogdrOWNCedm1RUrCAC0Pw7lW6URRhvj4A28S9mS0+
kOv0fNrceXiz1dgHNieRSVqzs+cs70klBqEv2awyBgPMoRvrvj5ddk2FqDyFgMQl
YXe8T36JqeI5SwP5GyHq8WG77uLkof0+Fp1UjrlQRqeYUNnhLuzgKbUh2a54BV6M
040zAjUNKPSlRUvvvty13VtZmmI6mYMxwTJ1XLcsS0Ecfh3TUlHB/IkR2+y2Wtjc
k1jGOpfFO/aSktkUCTQeS6N7uoaMr58gph2QZk8D9gOSywlXDDSq79MhIrii/gs=
=LCdh
-----END PGP SIGNATURE-----
