Author

Topic: [PAPER] Bitcoin Gateway - A Peer-to-peer Bitcoin Vault and Payment Network (Read 4239 times)

sr. member
Activity: 269
Merit: 250
I don't think addresses are as big a deal as you think. People already have to deal with long complicated strings of numbers whenever they make a payment, whether it be via credit cards or wire transfers. The mental model is easy enough - "somebody wants to make me a payment, so I'll grab a new labelled address and send it to them: done". For the merchant case it's more useful to hide the address behind a URI.

People seem to find useful to use single address to receive payments, e.g. signatures on this forum, bank card from bitbills etc. I think that's really bad for everyone's privacy because it creates loops and makes it easier to map transactions to users

Quote
Prior to performing the analyses above, we expected the user network to be largely composed of disjoint trees representing Bitcoin flows between one-time public-keys that were not linked with other public-keys. However, our analyses reveal that the user network has considerable cyclic structure. We now consider the implications of this structure, coupled with other aspects of the Bitcoin system, for anonymity.
An Analysis of Anonymity in the Bitcoin System
sr. member
Activity: 322
Merit: 251
FirstBits: 168Bc
We could use IP addresses instead of domain names, but most people prefer domain names. Likewise, millions of people have been trained to accept sending money using an email address thanks to PayPal. When these people give bitcoin a try and find they have to use cryptic addresses to send money, they think this stuff is not ready for prime time yet and move on. Features which enhance the end user experience can make or break a product even though they may seem insignificant from a technical perspective.

Hi Omar. Interesting ideas.

Satoshi envisioned sending bitcoins to IP addresses, but this has since been rarely used. In fact, I think it has been disabled by default in later clients over security concerns. PayPal uses an email so that they can initiate the payment process, whether that means telling you the amount, sending you a link to login, or to create an initial account. A bitcoin address IS the destination and cuts out numerous steps even for seasoned PayPal users.

As for memorability of the address, perhaps you should look into the first bits 'notation' which presents the shortest unambiguous case insensitive prefix compared to all previous addresses present in the block chain. Satoshi's first address is '1' while one of mine is '168Bc' first seen in block 128188. Maybe the first dozen addresses in the chain can help clarify the idea:

Code:
1    = 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
12   = 12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX
1H   = 1HLoD9E4SDFFPDiYfNYnkBLQ85Y51J3Zb1
1F   = 1FvzCLoTPGANNjWoUo6jUGuAG3wg1w4YjR
15   = 15ubicBBWFnvoZLT7GiU2qxjRaKJPdkDMG
1J   = 1JfbZRwdDHKZmuiZgYArJZhcuuzuw2HuMu
1G   = 1GkQmKAmHtNfnD3LHhTkewJxKHVSta4m2a
16   = 16LoW7y83wtawMg5XmT4M3Q7EdjjUmenjM
1J6  = 1J6PYEzr4CUoGbnXrELyHszoTSz3wCsCaj
12cb = 12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S
15y  = 15yN7NPEpu82sHhB6TzCW5z5aXoamiKeGy
1d   = 1dyoBoF5vDmPCxwSsUZbbYhA5qjAfBTx9
legendary
Activity: 1526
Merit: 1134
I didn't really understand your key scheme, sorry, but khals patch/system solves the issue of domain/email address  to key mappings quite elegantly, IMHO. It does have the disadvantage of requiring provider support, but for merchants who want to accept Bitcoin that's not an issue and for people, as I said, you usually email them back and forth anyway.

I don't think addresses are as big a deal as you think. People already have to deal with long complicated strings of numbers whenever they make a payment, whether it be via credit cards or wire transfers. The mental model is easy enough - "somebody wants to make me a payment, so I'll grab a new labelled address and send it to them: done". For the merchant case it's more useful to hide the address behind a URI.

You can't reliably do finance from a compromised host, period, even with wallet passwords. I'm not sure why you think otherwise. Wallet encryption is useful but just means viruses have to wait around until you enter the passphrase so they can grab it then. This is what's done (and more) by existing banking viruses. The only way to do it is secure hardware.
jr. member
Activity: 37
Merit: 1
Mike, thanks for the pointers.

Stefan Thomas' WebCoin project provides the sort of thing you imagine as being a "gateway". WebCoin servers are full Bitcoin nodes that expose an API to WebCoin clients allowing them to find transactions relevant to them, download them, and upload signed spends. WebCoin is implemented in JavaScript and allows web browsers to store and manage keys/transactions. WebCoin servers are not a P2P network, but you can use them interchangeably as they are (as I understand) stateless.
Yes, I had seen this project back in May shortly after Stefan released it. I wasn't able to get it working at the time, but I'll try it out again. I just looked over it again and I am quite amazed. The approach Stefan is taking is exactly the same as proposed in the paper. The send bitcoin transactions are created and signed by the browser based client and passed on to the Webcoin server; thus only the client has access to the private keys stored in the wallet. That's perfect. The wallet is encrypted and stored locally as well as on the Webcoin server. This is headed in the right direction. The next step would be to have the Webcoin servers connect with each other to form a structured P2P network to provide a distributed hash table (DHT) for true cloud storage. Once the DHT is in place it can hold all kinds of mappings to facilitate additional features like sending bitcoins using email addresses or sending a bill.

Quote
Startup time on todays software has been known to be an issue for over a year. The fix is complex and the people who have the skills to do it are largely on vacation at the moment. It'll come.
I think the Webcoin client should already have a fast startup time. As long as the client does not have to download and process the block chain and can make a request to the server (that processes the block chain) to get transactions for just the addresses it cares about, the client should be fast. The Webcoin client and server seems to be operating this way.

Quote
A 1-1 mapping of email addresses to public keys has poor privacy: it means anyone can see the payments you've received without access to your wallet. There is a patch floating around that provides an email-to-key mapping scheme that (if I recall correctly) doesn't have that problem. But I haven't found the current scheme to be so problematic, because before sending money to somebody you almost always communicate with them beforehand and they can then simply include an address in one of their replies. That's better for them because they can label it, so they can easily keep track of where payments are coming from.
The privacy is not degraded, because the email address does not map to a public key that represents a bitcoin address. The mapping is more like this:

email -> public_key
public_key -> [list of bitcoin addresses supplied by the client]
getAddress(public_key) - gateway returns only one unused bitcoin address from the list for someone that wants to send coins to email
getMyAddresses(public_key) - gateway returns the complete list of bitcoin addresses and payments received to them, but only if you can prove that you own the public_key

So this actually enhances privacy since a different address is used for each payment and no one knows who is associated with the receiving addresses.

Quote
In my opinion the use case for sending money to an email address without any prior contact turns out to not be that important, given practical experience.

We could use IP addresses instead of domain names, but most people prefer domain names. Likewise, millions of people have been trained to accept sending money using an email address thanks to PayPal. When these people give bitcoin a try and find they have to use cryptic addresses to send money, they think this stuff is not ready for prime time yet and move on. Features which enhance the end user experience can make or break a product even though they may seem insignificant from a technical perspective.

Aside from the ease of use issue there are practical cases where sending money to an email address without prior contact is necessary. For example if WikiLeaks wants to receive donations they have no choice but to post their bitcoin address. It would be great if they could give each person that wants to send a donation a unique bitcoin address. If instead they asked people to send bitcoins to their email address the gateway would take care of dishing out a unique bitcoin address for each donor.

Quote
Wallet security in the face of compromised hosts is a problem you can't solve without some kind of secure path to trusted hardware. That, in turn, is infrastructure that would have to be provided by a kind of "bitcoin bank". Yes, it means a bit more centralization, but it's optional if you're confident you can keep your computer virus free (eg because you only ever use it for Bitcoin and not general web browsing). And there's no other way to do it. You can't do finance from only a compromised host, period. The constant stream of massive thefts reported by Krebs is strong evidence of this.

Since the wallet file is encrypted using a long computer generated password rather than a human generated password then even if the host is compromised and the encrypted wallet file stolen the attacker will not be able to crack it using brute force. So the wallet file encrypted this way is about as safe as you can get. The issue then is how do you store and keep the computer generated password safe. The solution is to encrypt the computer generated password so that you need the user's private key to decrypt it and store it on a different host. Even if this host is compromised the attacker will not be able crack it using brute force. Then it's a matter of how you store and keep the user's private key safe. This is encrypted using the user selected password and stored on yet a different host. If this host is compromised and the user did not select a strong password then you've got problems. It would be ideal to store the user's private key on secure trusted hardware. In the end the weakest link is the human generated password, but keeping this safe should not require centralizing bitcoin.

[/list]
legendary
Activity: 1526
Merit: 1134
Thanks for an interesting document. I scan read it, so apologies if I make a point you already addressed.

There are already efforts underway to address many of the concerns your paper discusses. Here's a brief overview:

Stefan Thomas' WebCoin project provides the sort of thing you imagine as being a "gateway". WebCoin servers are full Bitcoin nodes that expose an API to WebCoin clients allowing them to find transactions relevant to them, download them, and upload signed spends. WebCoin is implemented in JavaScript and allows web browsers to store and manage keys/transactions. WebCoin servers are not a P2P network, but you can use them interchangeably as they are (as I understand) stateless.

Startup time on todays software has been known to be an issue for over a year. The fix is complex and the people who have the skills to do it are largely on vacation at the moment. It'll come.

Mobile wallets are now appearing, like Andreas Schildbachs' Android Wallet app. These connect directly to the P2P network. The approach is a bit different to the standard softwares, allowing for much faster startup times and lower resource usage (but still higher than WebCoins). Whether the final solution ends up being a move away from Satoshis code for end users, or improvements to it, is unclear.

A 1-1 mapping of email addresses to public keys has poor privacy: it means anyone can see the payments you've received without access to your wallet. There is a patch floating around that provides an email-to-key mapping scheme that (if I recall correctly) doesn't have that problem. But I haven't found the current scheme to be so problematic, because before sending money to somebody you almost always communicate with them beforehand and they can then simply include an address in one of their replies. That's better for them because they can label it, so they can easily keep track of where payments are coming from.

In my opinion the use case for sending money to an email address without any prior contact turns out to not be that important, given practical experience.

Wallet security in the face of compromised hosts is a problem you can't solve without some kind of secure path to trusted hardware. That, in turn, is infrastructure that would have to be provided by a kind of "bitcoin bank". Yes, it means a bit more centralization, but it's optional if you're confident you can keep your computer virus free (eg because you only ever use it for Bitcoin and not general web browsing). And there's no other way to do it. You can't do finance from only a compromised host, period. The constant stream of massive thefts reported by Krebs is strong evidence of this.

jr. member
Activity: 37
Merit: 1
I learned about bitcoin in May 2011. I was working on a paper titled "Sound Money Without Commodities" and wanted to check on the current state of digital currencies. I stumbled upon bitcoin and thought it was a really neat project. I posted about it in the forum on my Arimaa game web site:
http://arimaa.com/arimaa/forum/cgi/YaBB.cgi?board=other;action=display;num=1305495730

I am very enthuiastic about the future of bitcoin and have started accepting bitcoins for Arimaa game sets on my arimaa.com site. However, there are some thing about bitcoin which I believe can be improved to make it more appealing to a larger user base. I know there has been much discussion around future improvements to bitcoin on this forum. I'm sorry that I have not caught up on everything that has been said in the forum. But from what I have read, it seems that most of the proposals are based on modifications to the current bitcoin client/node software. I actually think that the current bitcoin software does not need to be changed and that separate software components need to be developed to provide additional features. After thinking through some ideas over the last few months I have tried to write up some specs for a bitcoin gateway that can provide these features while maintaining the decentralized goal of bitcoin. I hope this paper will motivate the bitcoin community to consider implementing the bitcoin gateway.

If I had thousands of bitcoins I would surely spend some of it to motivate development of the bitcoin gateway. As it is, I was a bit late to the mining party Grin I do have some bitcoins now thanks to a few bitcoin enthusiasts who have bought Arimaa game sets. But bitcoin has come along so far due to the contributions of time and effort made by many different people. So I view this paper as my contribution towards the continued success of bitcoin.

Hope you enjoy reading the paper:
http://arimaa.com/bitcoin/

Jump to: