Bitcoin Forum
December 09, 2016, 09:58:44 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2] 3 4 5 6 7 8 9 10 11 »  All
  Print  
Author Topic: [Stratum] Overlay network protocol over Bitcoin  (Read 33273 times)
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
December 28, 2011, 03:34:52 PM
 #21

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

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
1481277524
Hero Member
*
Offline Offline

Posts: 1481277524

View Profile Personal Message (Offline)

Ignore
1481277524
Reply with quote  #2

1481277524
Report to moderator
Satoshi is no god. He did not come down from the mountain with 10 golden rules engraved in stone for no one to question.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481277524
Hero Member
*
Offline Offline

Posts: 1481277524

View Profile Personal Message (Offline)

Ignore
1481277524
Reply with quote  #2

1481277524
Report to moderator
1481277524
Hero Member
*
Offline Offline

Posts: 1481277524

View Profile Personal Message (Offline)

Ignore
1481277524
Reply with quote  #2

1481277524
Report to moderator
1481277524
Hero Member
*
Offline Offline

Posts: 1481277524

View Profile Personal Message (Offline)

Ignore
1481277524
Reply with quote  #2

1481277524
Report to moderator
Grami
Jr. Member
*
Offline Offline

Activity: 38


View Profile
December 28, 2011, 05:50:19 PM
 #22


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
Legendary
*
Offline Offline

Activity: 1708



View Profile
December 28, 2011, 06:21:13 PM
 #23

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.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
ripper234
Legendary
*
Offline Offline

Activity: 1260


Ron Gross


View Profile WWW
December 28, 2011, 11:12:59 PM
 #24

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!

Please do not pm me, use ron@bitcoin.org.il instead
Mastercoin Executive Director
Co-founder of the Israeli Bitcoin Association
ripper234
Legendary
*
Offline Offline

Activity: 1260


Ron Gross


View Profile WWW
December 28, 2011, 11:38:50 PM
 #25

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?

Please do not pm me, use ron@bitcoin.org.il instead
Mastercoin Executive Director
Co-founder of the Israeli Bitcoin Association
eldentyrell
Donator
Legendary
*
Offline Offline

Activity: 966


felonious vagrancy, personified


View Profile WWW
December 29, 2011, 01:04:48 AM
 #26

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.

The printing press heralded the end of the Dark Ages and made the Enlightenment possible, but it took another three centuries before any country managed to put freedom of the press beyond the reach of legislators.  So it may take a while before cryptocurrencies are free of the AML-NSA-KYC surveillance plague.
Red Emerald
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
December 29, 2011, 02:28:41 AM
 #27

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
Donator
Legendary
*
Offline Offline

Activity: 966


felonious vagrancy, personified


View Profile WWW
December 29, 2011, 03:14:23 AM
 #28

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.

The printing press heralded the end of the Dark Ages and made the Enlightenment possible, but it took another three centuries before any country managed to put freedom of the press beyond the reach of legislators.  So it may take a while before cryptocurrencies are free of the AML-NSA-KYC surveillance plague.
ripper234
Legendary
*
Offline Offline

Activity: 1260


Ron Gross


View Profile WWW
December 29, 2011, 07:11:04 AM
 #29

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.

Please do not pm me, use ron@bitcoin.org.il instead
Mastercoin Executive Director
Co-founder of the Israeli Bitcoin Association
Red Emerald
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
December 29, 2011, 07:25:49 AM
 #30

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.

Quote
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 Smiley ).  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
Donator
Legendary
*
Offline Offline

Activity: 966


felonious vagrancy, personified


View Profile WWW
December 29, 2011, 07:50:06 AM
 #31

If the protocol is done right, zero trust is required

Just saying that does not make it true.

The printing press heralded the end of the Dark Ages and made the Enlightenment possible, but it took another three centuries before any country managed to put freedom of the press beyond the reach of legislators.  So it may take a while before cryptocurrencies are free of the AML-NSA-KYC surveillance plague.
ripper234
Legendary
*
Offline Offline

Activity: 1260


Ron Gross


View Profile WWW
December 29, 2011, 07:52:58 AM
 #32

If the protocol is done right, zero trust is required

Just saying that does not make it true.

Please describe a possible attack vector.

Please do not pm me, use ron@bitcoin.org.il instead
Mastercoin Executive Director
Co-founder of the Israeli Bitcoin Association
MoonShadow
Legendary
*
Offline Offline

Activity: 1666



View Profile
December 29, 2011, 07:57:15 AM
 #33

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.

"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."

- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
eldentyrell
Donator
Legendary
*
Offline Offline

Activity: 966


felonious vagrancy, personified


View Profile WWW
December 29, 2011, 07:59:18 AM
 #34

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.

The printing press heralded the end of the Dark Ages and made the Enlightenment possible, but it took another three centuries before any country managed to put freedom of the press beyond the reach of legislators.  So it may take a while before cryptocurrencies are free of the AML-NSA-KYC surveillance plague.
Red Emerald
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
December 29, 2011, 07:59:51 AM
 #35

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
Donator
Legendary
*
Offline Offline

Activity: 966


felonious vagrancy, personified


View Profile WWW
December 29, 2011, 08:00:13 AM
 #36

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.

The printing press heralded the end of the Dark Ages and made the Enlightenment possible, but it took another three centuries before any country managed to put freedom of the press beyond the reach of legislators.  So it may take a while before cryptocurrencies are free of the AML-NSA-KYC surveillance plague.
eldentyrell
Donator
Legendary
*
Offline Offline

Activity: 966


felonious vagrancy, personified


View Profile WWW
December 29, 2011, 08:01:33 AM
 #37

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!

The printing press heralded the end of the Dark Ages and made the Enlightenment possible, but it took another three centuries before any country managed to put freedom of the press beyond the reach of legislators.  So it may take a while before cryptocurrencies are free of the AML-NSA-KYC surveillance plague.
MoonShadow
Legendary
*
Offline Offline

Activity: 1666



View Profile
December 29, 2011, 08:06:28 AM
 #38

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.

"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."

- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
Red Emerald
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
December 29, 2011, 08:12:11 AM
 #39

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?

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

Quote
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
Legendary
*
Offline Offline

Activity: 1708



View Profile
December 29, 2011, 08:12:33 AM
 #40

assuming that you are not caught into a honeypot local internet


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?

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
Pages: « 1 [2] 3 4 5 6 7 8 9 10 11 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!