Sarchar



Offline



Activity: 88

Merit: 10







MemberActivity: 88Merit: 10 [Idea] The Bitcoin Banking Project December 28, 2013, 04:32:39 AM #1

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

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

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



* 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----- -----BEGIN PGP SIGNED MESSAGE-----Hash: SHA1Idea: The Bitcoin Banking ProjectAbstract: The Bitcoin Banking Project (BBP) is an open source bank softwarepackage (client and server) that aims to implement a form of "federated"banking for Bitcoin. The primary goal is to eliminate as many sources oferrors that cause lost or stolen Bitcoins as possible.Foundation: BBP is separated into three pieces, the client source code that executesin a typical web browser, the server that responds to client requests, and thedistributed network application that connects to other banking peers, processeslong-standing requests, etc.Setup: User logs into a publicly available BBP server -- or downloads andconfigures his own -- and is greeted with an easy to use several-step processthat walks the user through creating an account. The process would resemblesomething like this:1. The user is required to enter a password. The password must besufficently secure. Typical measures are provided to help the user recoverthe password in case of loss. 2-Factor Authentication could be provided ifit were something of interest, though may not be useful due to the natureof the design of this project.The users password is hashed in accordance with BIP32 (see my BIP32 stuffat https://github.com/sarchar/brainwallet.github.com/tree/bip32gen ) to producemaster extended private key MASTER_KEY_USER_PW. Perhaps different hashingmechanisms would be useful to help alleviate brute-force attacks on a user'spassword.Next, the client code then uses secure random number generation to producea second key, which forms another master extended private keyMASTER_KEY_CLIENT.2. The MASTER_KEY_CLIENT is turned into a set of words (like Multibit's 12-wordpaper wallet backup) and the user is prompted to print or write the wordsonto 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 isthat the user is walked through creating an offline backup ofMASTER_KEY_CLIENT. It must be stressed that this MUST be done. Noexceptions. If the user decides not to create this paper backup, he isputting his money at risk of accidental loss.While #2 is happening, the server also uses secure random number generationto generate a third master extended private key, MASTER_KEY_SERVER. Thiskey is unique to each user of the system, and it is never shared with theclient frontend.It's important to note here that neither MASTER_KEY_CLIENT norMASTER_KEY_USER_PW are ever seen by the server, and the client never seesMASTER_KEY_SERVER.At this point we have three keys. The client will turn the two keys it knowsinto master public keys: MASTER_PUB_USER_PW and MASTER_PUB_CLIENT and sendsthese 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 theuse of BIP32 (using the same derivation channel on each master public key),we can now produce a chain of multisignature addresses. BBP will *only* use2 of 3 multisignature addresses, for every user, for every transaction.The master public key package is built only of public information, so thepublic 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 masterpublic key package in several places: one copy is sent to his email, anothercopy is printed out and stored with MASTER_KEY_CLIENT, another copy is storedon the server's database, and other locations as wanted.4. The user is brought into his "wallet" home page, where he can make thetypical pay/receive actions related to standard wallet functionality.Features:* The server can create new deposit addresses for the user, without the user everneeding to disclose private keys. If the user is offline or away, yet someonewishes to send him money, the payer requests from the server, "give me anaddress for user XYZ", and the server happy responds with a new address basedon BIP32 key derivation.* Every transaction occurs in 2 of 3 Multisignature P2SH space and because there areonly 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 paperkey 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 andhis 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 accessiblefrom the paper key backup and his password.* The server cannot steal the users Bitcoins because the server only has one keyand two are required to spend.* Transactions are created by the client and partially signed with the correct derived keybefore 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 andconfigure his own server.The distributed part:Along with the above advanced Bitcoin features, the BBP should also implementCoinJoin (see https://bitcointalk.org/index.php?topic=279249.0 ) by default onevery transaction.This means it makes sense to have a daemon process running alongside the serverthat connects to other nodes in the BBP network. This network is where CoinJointransactions can be discovered and built. A paranoid user would configure Torand 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 thenetwork are building a collection of who wants to pay what. When a server isready to broadcast a transaction, he searches his list of 'who wants to paywhat' and starts directly talking to those machines, building a CoinJointransaction and signing along the way. This means that a user's transactionwill take longer to be sent, but with the benefit that it helps anonymizehis activity in the network. Chaum-blind signatures could be used to furtheranonymize behavior.Perhaps obviously, because the BBP server can be used by multiple users, aCoinJoin transaction can be built using only the transactions being executedwithin the same server.The daemon should also connect to the Bitcoin network to monitor transactionsand new blocks. A new server doesn't need to download the entire blockchainbecause there's no need to have the current UTXO set. The server could startwith downloading headers-only up until "today" and then download full blocksafter that point, storing only the relevant transactions to users within theserver's database and discarding the rest of the block.Other thoughts:* Monetizaiton wouldn't be too hard: be the first player in the game witha notable domain name and the average user will use your site. Ad revenueseems like the most common sense source.* Using a public-key signature scheme, two separate servers could arrangeaddresses for users through the distributed network and you could theoreticallyimplement a system that allows you to send money using an E-mail addressas the recipient:User A on server S wants to send User B on server T some money. User Abuilds a BBP-specific transaction that sends money to "B@T". The daemonon server S queries the network with "I need an address for B@T." IfT sees the message, T responds with an address for B and a signatureproving the address really belongs to B.Care would have to be taken in determining the right signature scheme forthis to work.* The daemon + server + client could be packaged into a single executable. Userdownloads the program, runs it, and connects to http://localhost:1234/ * Someone could pre-package server + client + daemon onto an embedded system orRaspberry 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 giveAccountingAccount an account of their own using company funds. You couldderive a set of private keys from the master public key package and create anew user account based on these derived private keys. BigBusinessAccount cansee 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 allin the Bitcoin or Namecoin blockchain, thus making the server completelyneutral. A user could log into *any* BBP server so that if a server evergoes 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+cs70klBqEv2awyBgPMoRvrvj5ddk2FqDyFgMQlYXe8T36JqeI5SwP5GyHq8WG77uLkof0+Fp1UjrlQRqeYUNnhLuzgKbUh2a54BV6M040zAjUNKPSlRUvvvty13VtZmmI6mYMxwTJ1XLcsS0Ecfh3TUlHB/IkR2+y2Wtjck1jGOpfFO/aSktkUCTQeS6N7uoaMr58gph2QZk8D9gOSywlXDDSq79MhIrii/gs==LCdh-----END PGP SIGNATURE-----