[Stratum] Overlay network protocol over Bitcoin

[kjj]

* Protocol must be bi-directional. In the opposite of standard client-server model, we sometimes need to allow server to initiate the communication. As an example, server can ask client to reconnect to another node (before switching to maintenance mode) or send some text message to user.

Use WebSocket as transport. It is bi-derectional and simple enough.
http://en.wikipedia.org/wiki/WebSocket

Eww.  Websockets are only useful when you have no other way to start a connection.  After that, it is just an obfuscated TCP socket.

[1714031557]

1714031557

[1714031557]

1714031557

[1714031557]

1714031557

[1714031557]

1714031557

[Grami]

Eww.  Websockets are only useful when you have no other way to start a connection.  After that, it is just an obfuscated TCP socket.

Websockets is much simpler in use. With TCP socket you have to aware of many useless things (buffer size, tcp error handling etc).

[2112]

Websockets is much simpler in use. With TCP socket you have to aware of many useless things (buffer size, tcp error handling etc).

All protocols are equal, but some protocols are more equal than others.

[ripper234]

Great project, I'm glad to see some commits already at Gitorious.

Just my two cents:
1. Like some others said, develop a prototype, launch early, and iterate.

2. Should not require sending private keys (haven't read the protocol in detail yet, but just in case this was not planned). Instead use some form of Offline Transactions.

3. Should consider DDOS protection. If this will be The Simple Network over Bitcoin, that will eventually handle huge traffic, you might want to consider charging a bit per API call ... just something minimal to deter DDOS. People can register their API keys, charge their account with X BTC, and get an allowance for Y API calls.

4. Should consider malicious servers. If someone evil runs an evil copy of this server, and clients connect to it ... how exactly can the evil server damage them?

Can EvilServer steal money? (Probablly not if you're just using Offline TX as the only mutator operation)
Does it have a strong incentive to lie about GET queries?
How about delaying transfers?
Would clients eventually talk to multiple overlay servers, and validate the results between them?
 - If only 2 out of 3 trusted servers tell me something, odds are the 3rd one is lying
 - I would be able to submit a mutator API call (e.g. processTX) to multiple servers ... and may the fastest one win.

These are just some things to think about ... you don't need all the answers in advance. I actually started developing a small Bitcoin webapp today, and got stuck when I realized I'd have to maintain the entire blockchain (or even just the headers). If a prototype of this project comes out early enough (~ 1 month), I'll wait for it instead of writing and debugging blockchain-maintaining code.

Oh, and a definite +1 to JSON. The protocol should appeal to the most common denominator ... which is JSON.

Good luck!

[ripper234]

BTW, what is the relation between this overlay network and BitcoinJS Exit Nodes?

Are they implementations of the same idea? Are there substantial differences between the projects?

[eldentyrell]

This is cool, but I couldn't find any mention of the trust model anywhere in this thread or the design docs.

If you keep a copy of the blockchain, trust is simple: you trust the longest chain.

If you aren't keeping a copy of the blockchain, you need to find another answer for this question.

I'm not saying it's impossible, though I am suggesting that it might be the most difficult part of this project (certainly more difficult than choosing wire protocol formats!).  I'm a bit worried that it isn't being addressed.  Or maybe I just missed something.

[Red Emerald]

This is cool, but I couldn't find any mention of the trust model anywhere in this thread or the design docs.

If you keep a copy of the blockchain, trust is simple: you trust the longest chain.

If you aren't keeping a copy of the blockchain, you need to find another answer for this question.

I'm not saying it's impossible, though I am suggesting that it might be the most difficult part of this project (certainly more difficult than choosing wire protocol formats!).  I'm a bit worried that it isn't being addressed.  Or maybe I just missed something.

There is a server that sits on top of a patched bitcoind which of course has the blockchain.

The thin client simply uses this protocol to ask the server the balance or to sign transactions relay signed transactions or w/e.  I don't see anything that needs to be addressed.

[eldentyrell]

The thin client simply uses this protocol to ask the server the balance or to sign transactions or w/e.

Why do you trust "the server" (and the person running it, who I assume is not always yourself)?

How do you know you're even talking to "the server" you think you're talking to (no man-in-the-middle)?

I don't see anything that needs to be addressed.

These are basic, fundamental security questions that have been widely known since before SSL came into use.  If the designers of this new protocol don't think they need to be addressed, that concerns me.

[ripper234]

The thin client simply uses this protocol to ask the server the balance or to sign transactions or w/e.

Why do you trust "the server" (and the person running it, who I assume is not always yourself)?

How do you know you're even talking to "the server" you think you're talking to (no man-in-the-middle)?

I don't see anything that needs to be addressed.

These are basic, fundamental security questions that have been widely known since before SSL came into use.  If the designers of this new protocol don't think they need to be addressed, that concerns me.

If the protocol is done right, zero trust is required, because a malicious server can't really do much.
Offline Transactions ftw.

[Red Emerald]

Why do you trust "the server" (and the person running it, who I assume is not always yourself)?

How do you know you're even talking to "the server" you think you're talking to (no man-in-the-middle)?

I am pretty sure that all client-server models require trust that the server is not lying. I can't think of any that don't.  However, there aren't too many things that a malicious server can do.

Why do you trust all of the nodes you connect to?  I'm pretty sure that most of the same protections to make sure peers aren't lying to you are available to a thin client.

For example: A transaction's input contains a signature that can't be faked (if they can, we are all f***ed, thin client or not).  If a malicious server gave you a fake input, a simple check would show you it is fake.

Since you generate and sign outgoing transactions yourself, there is no chance of the malicious server redirecting your coins to another address unless maybe that address is retrieved from a malicious firstbits resolve where they happen to have a collision.  This is a potential problem with firstbits in general and not specifically this protocol. http://firstbits.com/ could make addresses for the most commonly requested addresses and return those instead of the real ones (if they wanted to be thieves) or if the firstbits were short enough, they could generate a collision on the fly.  Not sure what we could do to prevent this problem besides letting people know that for utmost security they need the full address.

One thing I could see a server doing that would be harmful is not relaying it's clients transactions.  Right now, thin clients only talk to one server.  This wouldn't be too hard to detect as the person you are sending to would probably mention that it hasn't been received.  People are also talking about getting thin clients to communicate with multiple servers which would remove this problem.  I think transaction broadcast services will be important for anonymity given some of the IP tracing I've seen.

Another problem might be if the server does a double spend against one of it's clients as they could be kept unaware of the real transactions on the network.  This problem is also removed once the client can talk to multiple servers.

These are basic, fundamental security questions that have been widely known since before SSL came into use.  If the designers of this new protocol don't think they need to be addressed, that concerns me.

Run the protocol over SSL and you don't need to worry about MITM. Then, only a malicious server is the problem.

If we have a network of servers of running this protocol, some of the problems I mentioned above (like holding transactions) would require a 100% attack (which is likely much harder than a 51% attack ).  I'm not sure how we should handle what happens when a malicious server is detected.  That definitely needs to be figured out soon.

I imagine slush can give a better defense of this proposal as he seems to always write what I am thinking way better than I seem to be able.

[eldentyrell]

If the protocol is done right, zero trust is required

Just saying that does not make it true.

[ripper234]

If the protocol is done right, zero trust is required

Just saying that does not make it true.

Please describe a possible attack vector.

[MoonShadow]

Trust can be developed by a thin client the same way that trust in peer nodes is developed in the bitcoin protocol.  By polling randomly among a set of reachable nodes and comparing their responses.  If any response doesn't match, dump all those nodes and try again at random.  The odds that more than one random server on the Internet is trying to screw you, assuming that you are not caught into a honeypot local internet, is remote.  Moreso considering that it's largely impossible for those random servers to know if you are capable of verifying such data or not.

As a thin client, you are also not trusting the server with any critical data that cannot be corrected later.  You are not offering it access to your private keys, for example; just polling it for otherwise public data available on the blockchain, namely the balance of certain addresses and copies of certain confirmed transactions.

[eldentyrell]

However, there aren't too many things that a malicious server can do.

!!!Dangerous misconception!!!

Satoshi invented blockchains for a reason: they prevent double-spends.  If you don't have a copy of the block chain, anybody running the server you're talking to can "send" you coins and then take them back with total impunity, simply by making sure that a transaction sending those coins to themselves is "mined in" to the blockchain before they release the transaction that looks like it's sending them to you.

This problem is also removed once the client can talk to multiple servers.

This is dangerous "cargo cult security".  It does nothing to prevent man-in-the-middle attacks (my ISP attacks me) and merely shifts the problem elsewhere.  What prevents somebody from renting 100 cheap VPSes and running the server software on all of them?  Worse: botnet operators.  See also Sybil attacks.  Basing security on 51% hashpower is reasonable; basing it on 51%-of-IP-addresses-running-the-software is definitely not.  I can't think of anything more attractive to botnet operators!

I imagine slush can give a better defense of this proposal as he seems to always write what I am thinking way better than I seem to be able.

With all due respect to slush, he shouldn't provide a "defense"; he should address these issues in the design document by explicitly stating the trust model.

[Red Emerald]

If the protocol is done right, zero trust is required

Just saying that does not make it true.

Please describe a possible attack vector.

I provided a few

[eldentyrell]

Trust can be developed by a thin client the same way that trust in peer nodes is developed in the bitcoin protocol.

There is no trust in peer nodes in the bitcoin protocol.  There is only trust in the longest chain.

[eldentyrell]

Please describe a possible attack vector.

The attack vector depends on the trust model.  I'm waiting for the trust model to be specified.  This is the whole reason why security protocols state their trust model: so you can look for attack vectors!

[MoonShadow]

Trust can be developed by a thin client the same way that trust in peer nodes is developed in the bitcoin protocol.

There is no trust in peer nodes in the bitcoin protocol.  There is only trust in the longest chain.

Ultimately, this is true.  However, the client has to start somewhere with aquiring the blocks that build that longest chain, because a fresh install doesn't know anything about the longest chain.  So it attempts to develop direct connections with a number of peers that are all sending it blocks that agree with one another, reducing (not eliminating) the possibility of an isolation attack.  The thin client model isn't about the greatest form of trust or security, but a balance between trust, security and convience.  If you can't accept the risks of getting screwed out of a small amount of spending coins on a cell phone thin client, then stick with a full client.  No one is forcing you to accept a reduction in security, thin clients simply offer a choice.

[Red Emerald]

If you don't have a copy of the block chain, anybody running the server you're talking to can "send" you coins and then take them back with total impunity, simply by making sure that a transaction sending those coins to themselves is "mined in" to the blockchain before they release the transaction that looks like it's sending them to you.

Um. How is the server supposed to send those coins to themselves?

EDIT: They can only send you coins from them which severely limits the attack. They can't change someone else's payment to you because of the hashing done.  I also don't think "mined in" and simply can go together at the current difficulty.  Can you name a client-server model that DOES NOT require trust?

This problem is also removed once the client can talk to multiple servers.

This is dangerous "cargo cult security".  It does nothing to prevent man-in-the-middle attacks (my ISP attacks me) and merely shifts the problem elsewhere.  What prevents somebody from renting 100 cheap VPSes and running the server software on all of them?  Worse: botnet operators.

I don't get what "cargo cult security" has to do with this.

Stick the protocol and SSL and you can't MITM.  You are essentially saying we are vulnerable to an attack from a large number of servers.  You know what else is vulnerable to what is often called a 51% attack? Bitcoin...

I imagine slush can give a better defense of this proposal as he seems to always write what I am thinking way better than I seem to be able.

With all due respect to slush, he shouldn't provide a "defense"; he should address these issues in the design document by explicitly stating the trust model.

The "defense" would be that the protocol doesn't need modification as there is little need for trust in almost everything the server does.  Like I and others have said: This is a client-server model; not a decentralized model.  You are giving up 100% security for ease of use.

Once this is more developed, we could make it easy for everyone to run a server of their own on their home network.  Then people could run one server (they already run atleast one node) and use thin clients that only connect to their own trusted server if they want to be paranoid.

[2112]

assuming that you are not caught into a honeypot local internet

This is a piratebox...
http://wiki.daviddarts.com/PirateBox

Earlier I was simply "not impressed". But right now I switch my opinion to "starts to stink".

Oh, and a definite +1 to JSON. The protocol should appeal to the most common denominator ... which is JSON.

Good luck!

Yeah, good luck to whom?