Bitcoin Forum

-----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://bitcointalk.org/index.php?topic=279249.0) 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-----

Very interesting concepts. However, this is really moving far away from Bitcoin protocol, which is based on P2P nodes. If you have nodes and servers like electrum, you introduce the problem of server trust. And to solve that you need something else than what is traditionally thought of as a server. The whole beauty of the system lies in the fact that trust is not needed, or rather is forced by the protocol. Security/trust are not just features, they are the fundamental primitive of the network. Bitcoin is based on the fact that one doesn't really have to trust any other node. Even if I own a server and control that server I have introduced several new problems. You are talking about a BBP network. How are these different from cloud wallets? Why introduce a second class network? I think that makes no sense. Bitcoin protocol runs on TCP/IP which everyone has access to. One might imagine a sort of institution which gives approval to cloud wallets, which is what government regulators already partly do.

Having said that, it is clear that a) something else than cloud wallets are needed, because they completely undermine the algorithm b) mining centralization/ASIC/botnets are a major problem.

Perhaps there's some misunderstanding here.  This idea for a bank is absolute trustless: if you are curious, inspect the code.  It's an absolute requirement that all code be open so that you *can* trust your own server.



Huh?  TCP/IP is just a transport layer for data.  The "second class" network is no different than Bitcoin's network except in the data it exchanges. The whole point of joining a network of peers is to facilitate CoinJoin, mixing, and other potential improvements in the future.


Pretty sure this is off-topic..

This is a great idea! I have developed something like this just days ago as a Bitcoin payment protocol. Same concepts but based entirely on XMPP for the federated servers system. One client create an account on the server they choose and get an email address (Jabber IDs). Each clients communicate with the server through the standardized "mainhandler@server" entry-point to ask for the recipient Bitcoin address, send txs, get payment notifications with optional additional data... and servers to servers communications all derived from the Jabber ID domain part of the sender/recipient addresses. Each servers can have there own fees policy and ask for inclusion of an txout to themselves, pool and match txs for CoinJoin between servers and allow direct user to user communication scheme for complex contracts. All of this made possible with the XMPP protocol which allow storage of messages and online presence detection of when the client software are on/off-line. Not to mention the direct xmpp-http bind capability for websites interactions... All your schemes can be implemented with this and an optional anonymity layer per transaction basis with the added benefit of human readable addresses. This is basically the equivalent of a Bitcoin address DNS. The possibilities are endless...     

Well, you have to be much more precise in what you are talking about. Bitcoin works, because there is the proof of work and blockchain. This scheme removes those features, which makes little sense. One server compromise is enough for an attacker to compromise the network. Anyway.

XMPP is a pretty cool idea.  It definitely makes sense to not have to reimplement a messaging network, as these things already exist.  I didn't really explicitly mention this, but building upon other open source software is the right thing to do.  sx and the unSYSTEM project are making great strides doing similar things (though not really focused on the ease of use functionality).

The BBP network doesn't need a blockchain and proof of work systems because there are no BBP-specific transactions.  All transactions are legitimate Bitcoin transactions.  A server compromise by itself is of generally no consequence because the server isn't authoritative over anything: it requires your permission to do anything.

A large class of attacks are spoofing / MITM attacks. If a server is compromised the attacker can trick users into sending money to him. What would make sense for me is to run bitcoind on servers through a secured connection, like electrum. But Electrum lists some servers run by people I don't know. Instead I would like to easily run my own server. Integrating server control (SSH) into a HD wallet is a very good idea. You only need one master key on the client IMO.

In the case of a properly implemented nym->address system, a MITM attack couldn't spoof an address because he can't forge a signature.  This would work especially well if a nym's pubkeys were registered in a system like Namecoin.

Exactly all the communications can be signed with a Bitcoin address publicly know to be associated with the intended user. This can involve a directory look-up service but just move the MITM problem... So the most simple solution is to add the public signing address that the user directly grab from the website of the merchant to his own trust list on the client software.  Or by extension an self identifying address scheme that i am currently working on...  ;)

this just defeats the entire purpose of bitcoin.  u might as well walk down to your bank and deposit cash

I have a simpler solution for you. It's called paper wallet and backup or blockchain wallet in this case of "personal online banking".
What you are proposing is a good concept but I feel that it somehow complicates the idea of Bitcoin.

You obviously don't understand the proposal.

I would suggest you look at BIP33 which already introduced a similar scheme https://github.com/bitcoin/bips/blob/master/bip-0033.mediawiki

If you have that kind of detail and precision people will be much more inclined to look at it. I would propose to call these servers not banks, but something else, as this has very negative connotations these days.

I'm already working on an early implementation in python with Qt and xmpp. A public derivation of the masterkey for generating addresses is much better than P2SH enforced. The server only need to store the public master key for each account and generate incrementally new Bitcoin addresses at each request. It work together with bitcoind and can easily be implemented as a plugin for electrum or any Bitcoin back-end... I see it as a great merchant tool for payment processing as a main target but even an auction market scheme can "easily" be implemented with this protocol and client software...


I fully agree with that.

With this each server can even act as "buffer" for micro-payment. When a client want to send a micro-payment at first he send 0.001 BTC to the server account and his micro-payment is credited on the recipient account on his server. When a micro-payment account reach the 0.001 threshold his server make the Bitcoin transaction...  Each server owner can have their own policy and services to monetize it.

I respectfully disagree.   If the server you use has the only copy necessary to spend your money then you are in an entirely different realm of banking.  My solution proposes that you are in full control of your money and the "bank" is only there to provide some convenience.

???!!! Public derivation mean that the public masterkey can only serve to generate bitcoin addresses NOT private key! Each client software on the other hand keep the Private master key encrypted for Private derivation to spend their coins... Read this carefully:  https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki (https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) . It's like what electrum implement with their watch-only wallet.

D'oh.  You're right!  You're doing Bip32 public key derivation using a single key.  For what it's worth, I'm the author of the javascript bip32 implementation at https://github.com/sarchar/brainwallet.github.com/blob/bip32gen/js/bip32.js

The point of multisignature (whether it's p2sh or not) was to provide some backup in case of lost keys.

What is the different between running your own bitcoin server? There I have full control, and this can be set up very easily. I then use SSH to secure my connection. Running servers can be automated much better than it is done today. One could run one's own electrum server with the click of a mouse.

And what is the point of running your own electrum server? Why not just running the full Bitcoin-Qt then? Think of this project more like a DNS for bitcoin addresses. The server doesn't directly handle any bitcoins at all, it's just a communication/routing layer between clients for building higher level sevices on top of it. That's the whole point of this, convenience through the use of memorizable "email" (xmpp) addresses and to transparently enabling all the complex contract scheme that exist with Bitcoin. It's primarily a payment protocol and in fact can be implemented on every Bitcoin client including electrum.

Edit:
What is especially great with the "email" thing is that one can print it on a magazine or a Ads and each user can send payment with an invoice number attached or even join a complete order form with his payment. The server generate a unique Bitcoin address automatically at each client's request and reroute the payment information on the merchant's client software.  

I think you should have a look at Amir's work, with libbitcoin and the more recent stuff, as well as the mentioned BIP. He has been working on this for a couple of years now. Its nice to have ideas, but implementing them is that hard part.

I like the idea, of what I would call a "service hub", but the problem you don't see is that attackers can attack the traffic. It's not a secure channel we are speaking about, because the source is untrusted. What SSL does, is to provide trust via the CA's. There is no way I would let a third party handle my transactions over an unsecured channel. how do I know that when I go to paypal.com this is the website of paypal Inc? That's what HTTPS/SSL does. And for that you need Verisign / Trusted third party, although we now know that Verisign is happy to introduce backdoors when it feels like it. ICANN has similar problems, sucking up to corporations.

One of many weaknesses of Bitcoin-Qt is that it eats up resources on the client. So electrum pushes this to a server. It would be much better to have client owned server. Basically like a dropbox, but running programs. This hasn't been really done before, but its quite easy these days, although security of these VPS is not easy to access. I would argue that a server set up in this way, is probably more secure than most clients.

A service hub is a good definitions of this project. The xmpp protocol handle the SSL communications and prevent address spoofing already, of course each server would have their certificate, we are not trying to reinvent the wheel.

I think a lot about security of the whole system and for the BIP32 part although it's an elegant solution it must not belong to the server to take it because I think the strongest for security is that each client can sign every bit of information they transmit with a unique, publicly identified Bitcoin address that any willing client can verify to correspond with the intended entity. And for this the client software must generate a list of 100 addresses in advance, sign each of it and send it to the server for storing it and repeating this when addresses are used. Of course we can sign only a public masterkey and clients can verify it... but then anyone can tell all the future addresses resulting in a loss of privacy.

A good compromise is that regularly the client publish and sign a new public masterkey this way we have a strong scheme where even a corrupted server cannot forge addresses because of the signature and by repeatedly generating new masterkey we maintain a good level of privacy. I have already framed the majority of this protocol and a very early pre-alpha (proof of concept) implementation in python will be published on github very soon...

Yeah Bitcoin-Qt is very hungry on resources, electrum is what I intend for the majority of users and running his own electrum server on a VPS would be great and can already be made. For this thing I will publish the client and the server part so you can have your own server on your own domain if you want... It's a pretty light protocol on resources and every merchant sites can have their own server installed, so maximum security for customers and a nice business payment address with their own domain.

Good. Would be interesting to try some of this out. I'm working on some similar things, to facility the use of servers (VPS with machine images). There are some major security concerns however, as the hardware is run by a third party. Linode is said to have stolen large amounts of BTC, and there were some recent issues with DO.

I think a third category of keys is not needed. See BIP32, https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki

With namecoin one can bootstrap DNS/domain ownership. so one can run a server by using foreign, trusted build scripts on a VPS platform (AWS, Rackspace, etc.). SSH agents are also kind of like this. in the end one can use one master key for everything. One could imagine to subscribe to a scheme, like the following. Say I want to restrict all payments of my address to 10% of balance of an account. I register at a trusted server (gateway). The gateway will only allow payments of 10% of the current balance per day. The gateway might only know the balance and no further info. This is what BIP32 is about. But how one would set up a gateway is not known as far as I know.

I think that's the possible awkward part.

It's not possible (or not that I understand) for the client to know what adapted version of the server-side source code is being used. If you have a bad actor running the server, they know how much their HNW clients have in their accounts. This could motivate them to expend alternative (real world) resources to ensure that the paper backup or the wallet seed aren't available to the client (somehow). If the bad actor server can do this in a way that does not implicate their complicity, could they extort money from the client by pre-implementing server side code that refuses to derive a new address chain, or that refuses to sign transactions to access his lost funds?

And, (server bad actors aside) what if the client loses the paper wallet and his seed? With current clients, you've still got your 1 of 1 wallet file, and you may still remember the encryption password for that. When you introduce a third party backup private key and enforce 2 of 3 signatures, even if the wallet file still exists and the encrypting password are known, you can't sign tx's from the wallet. It would be interesting if the multisig keys scheme could be modified so that not all signing keys are equal, although I get the feeling this depends on the way it's implemented upstream at the bitcoin protocol level. The seed could perhaps have 1 of 3 a signing quorum, and the paper wallet and server key could have 2 of 3.

All of this let me think that I must separate the communication part and the more higher level services for the server. So in fact we will have each merchant installing their own server on their domain that handle the basic level of communication and generating addresses for the client software, and for all the higher services that require some form of centralization like CoinJoin operations etc, there will be independent services providers that each client software can subscribe to from a public list.  For the general user they must still pass through a trusted server if they don't want to/cannot maintain their own server.

We can also imagine a much more "decentralized" model where we have light clients that can just connect to a merchant's server when sending payments and without email(xmpp) address for themselves, but can still benefit of all the ecosystem of high level service providers on the whole network, thus making this project really a "communication layer" / "service hub" for "Bitcoin service providers" / "software agents". So basically we don't need a third party to mess with our BIP32 addresses...

Better in my wallet, bitcoin was actually made to eliminate banking and lots more.. IMO

LOL... I agree with you ;) As has already been said, it has nothing to do with BANKS.


It's a mean to send bitcoins to email addresses! Nothing more nothing less. And on top of that an ecosystem of services can be built. It's a major simplification for all Bitcoin users and open a lot of opportunity for businesses, conceptually it's like what PayPal propose but on your own computer and as decentralized as the email system is. I have advanced a lot on the alpha version of this software and expect to see it in a few days... There is not a server specific part you can use an existing xmpp server on the internet to create your account, even your own server, the clients communicate and send payments between them directly. Actually the software is based on electrum and so is a self contained wallet and also a mean to easily handle incoming payments on your website with a simple RPC API soon.

BPP - The ULTIMATE Bitcoin Payment Protocol:

I finally made the first (quick and dirty) implementation of this software.

HERE IT IS: https://github.com/jsbitcoin/bpp-client (https://github.com/jsbitcoin/bpp-client)

What is it? :
* A mean to receive and send bitcoins on a unique address that resemble a email address.
* A mean to attach some datas with each payments like an invoice number, a reference, a comment or even an order form... whatever you want!
* A payment manager with the history of payments and all its data and return address available with an API. (Later...)
* Very light and fast! Based on electrum.
* Secure without having to rely on an PKI, a security code is embedded directly on the address to verify the signature of all communications.
 
To test it create your own account on a xmpp server (just click create new account and enter a new address), add some funds on your receipt address, send payments, and have fun... :)
For testing purposes you can create two copies of it in different folders and launch them to send money between the two clients. The Tx fee is set to 0.0001 by default. Currently the ONLY?! public xmpp server I have found on the internet with vcards enabled is sibergad.ru , So dedicated servers must be made available to support this service later. 
To receive money all you have to do is to publish your secure BPP address like mine: bppmaster@sibergad.ru&bf8FrAWCgFtJuVfbrC5wUiEKVW . The security part (after the &) is optional, you can send payment to an address without it but the signature of information will not be verified (in case of compromised server)!  For each payments you will receive bitcoins in a brand new Bitcoin address, so you can print your BPP address in a QR code on a static support safely.

I will create a new thread for this with more details...