Topic: [Idea] The Bitcoin Banking Project (Read 3941 times)

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

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: [email protected]&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...

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.

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

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...

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.

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.

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.

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.

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.  

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.

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.

!!! 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 . It's like what electrum implement with their watch-only wallet.

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.

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'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.

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.

You obviously don't understand the proposal.

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.

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

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...