Topic: [Stratum] Overlay network protocol over Bitcoin - page 10. (Read 37909 times)

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.

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!

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

I provided a few

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


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.

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.

Please describe a possible attack vector.

Just saying that does not make it true.

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.


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.

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

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)?



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.

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.

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.

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?

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!

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

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

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

+1