Pages:
Author

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

newbie
Activity: 39
Merit: 0
* 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
legendary
Activity: 1896
Merit: 1353
The thing is not to get too caught up writing long proposals and documents. Think a little bit, code up an implementation, get rolling and refine your requirements as they become obvious. It's easier to ask for forgiveness than to ask for permission.

I agree with you. These things are a bit obvious, but it is sometimes worthwile to remind obvious things. :-)
A protocol should result from an iterative process, back and forth between specifications and the needs that we discover during implementation. It should not be set in stone too early, especially when the number of people involved is tiny.

Things I would like to see in the protocol:

* use JSON RPC
* the set of functions that are currently used by the Electrum client and server (address based functions): the server does not know the set of addresses in a client's wallet, it just sends address histories and broadcasts transactions. This means that a client should be able to use several servers simultaneously for improved anonymity.
* wallet-based functions (similar to BCCAPI) for ultra-thin clients:  The server knows the public key used to generate the sequence of addresses in a type 2 wallet. It sends the balance and history of the wallet. It also sends the number of addresses detected in the wallet (gap based detection; note that this differs from BCCAPI, because the BCCAPI server needs to store your number of keys in its database). The server also sends unsigned transactions to the client, and the client signs them.
* also, I would like to see something similar to Transaction Radar: http://www.transactionradar.com/ : when a transaction is unconfirmed, the client should display its rate of propagation. Electrum servers could be part of the existing transaction radar service.
hero member
Activity: 742
Merit: 500
The thing is not to get too caught up writing long proposals and documents. Think a little bit, code up an implementation, get rolling and refine your requirements as they become obvious. It's easier to ask for forgiveness than to ask for permission.
I disagree.  I think planning ahead always leads to better software even if the software development may be slower to start.  Better to find a problem in your proposal and rewrite that than to discover a problem in your code and redo a ton of work there IMO

Proposals are especially important when multiple people are working on a project as it makes it easier to work on different parts of the project at once.

You're advocating the ancient waterfall method which is basically out of fashion since the last decade.

Quote
genjix:~$ python
Python 2.7.2+ (default, Oct  4 2011, 20:03:08)
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.

If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

You are emphasizing the first bolded point while I am emphasizing the second.  I'm not trying to say, "don't start ANY code until you have the proposal 100% complete and vetted by every major dev." I'm saying that we should have a basic roadmap worked out about what we are coding so that we actually know where are going.

And I most definitely stand behind my second point.  

Quote
Proposals are especially important when multiple people are working on a project as it makes it easier to work on different parts of the project at once.
How are multiple people supposed to work on something when no one knows were we are trying to go?

EDIT: reread your post.  I had missed the "code up an implementation" and thought you wanted to code with no roadmap.
legendary
Activity: 1232
Merit: 1076
The thing is not to get too caught up writing long proposals and documents. Think a little bit, code up an implementation, get rolling and refine your requirements as they become obvious. It's easier to ask for forgiveness than to ask for permission.
I disagree.  I think planning ahead always leads to better software even if the software development may be slower to start.  Better to find a problem in your proposal and rewrite that than to discover a problem in your code and redo a ton of work there IMO

Proposals are especially important when multiple people are working on a project as it makes it easier to work on different parts of the project at once.

You're advocating the ancient waterfall method which is basically out of fashion since the last decade.

Quote
genjix:~$ python
Python 2.7.2+ (default, Oct  4 2011, 20:03:08)
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.

If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
legendary
Activity: 1232
Merit: 1076
The thing is not to get too caught up writing long proposals and documents. Think a little bit, code up an implementation, get rolling and refine your requirements as they become obvious. It's easier to ask for forgiveness than to ask for permission.
You have a fair point. But I'm extremely skeptical as to overall software architectural skills in the broad Bitcoin community. My absolute favorite is the inversion of control issue in Satoshi client exhibited by ThreadSafeAskFee(). Such a textbook case of an anti-pattern.

https://bitcointalksearch.org/topic/m.538044

The rationalization I heard why this "isn't a problem" or the workarounds proposed are quite enlightening and entertaining. Too bad that moderators deleted several flaming comments in that thread.



The bitcoin codebase is terrible architecturally.

You may be interested to review my codebase which is an asynchronous bitcoin toolkit library using proactors. Completion handlers using std::bind and std::function are passed to operations.

https://bitcointalksearch.org/topic/libbitcoin-30646

Also a video on the design principles behind the API:

http://www.youtube.com/watch?v=zyKcSpx5xDg
hero member
Activity: 742
Merit: 500
The thing is not to get too caught up writing long proposals and documents. Think a little bit, code up an implementation, get rolling and refine your requirements as they become obvious. It's easier to ask for forgiveness than to ask for permission.
I disagree.  I think planning ahead always leads to better software even if the software development may be slower to start.  Better to find a problem in your proposal and rewrite that than to discover a problem in your code and redo a ton of work there IMO

Proposals are especially important when multiple people are working on a project as it makes it easier to work on different parts of the project at once.
legendary
Activity: 2128
Merit: 1073
The thing is not to get too caught up writing long proposals and documents. Think a little bit, code up an implementation, get rolling and refine your requirements as they become obvious. It's easier to ask for forgiveness than to ask for permission.
You have a fair point. But I'm extremely skeptical as to overall software architectural skills in the broad Bitcoin community. My absolute favorite is the inversion of control issue in Satoshi client exhibited by ThreadSafeAskFee(). Such a textbook case of an anti-pattern.

https://bitcointalksearch.org/topic/m.538044

The rationalization I heard why this "isn't a problem" or the workarounds proposed are quite enlightening and entertaining. Too bad that moderators deleted several flaming comments in that thread.

legendary
Activity: 1232
Merit: 1076
The thing is not to get too caught up writing long proposals and documents. Think a little bit, code up an implementation, get rolling and refine your requirements as they become obvious. It's easier to ask for forgiveness than to ask for permission.
legendary
Activity: 2128
Merit: 1073
Hi slush (and other readers)!

I reread your proposal (both here and in Google docs). In my opinion you are proposing either (1) internally inconsistent protocol or (2) family of incompatible protocols supported by a hope of sharing some implementation details.

Second issue is that I'm NOT proposing RPC over HTTP(S).

I'll need to add some custom way how to support HTTP poll or HTTP push, because I *want* to provide services for this type of clients.

because json encoder/decoder or curl/ajax is available everywhere in standard libraries

The resultant Frankenstein monster (or family of monsters) is going to try to strangle its creator.

It is hard to argue with what you proposing point by point because of the contradictory nature of the requirements. I'm going to group my response into the following points.

1) Protocol can be either RPC or bidirectional, but not both. The RPC paradigm (request-response, master-slave) is mutually contradictory with a pair of peers exchanging asynchronous messages. Bitcoin protocol itself is from its origin asynchronous and cannot be squeezed into the master-slave architecture. It demands the bi-directional asynchronous protocol with finite state machines (FSMs) on both ends communicating with a two flows of sequenced frames. The successful design will look very much like TCP on top of IP frames.

2) Your target market (low-end consumer-level devices) demands that there's checksuming and framing at the application layer. Precisely because cheap NAT gateways and cheap DSL/Cable/WLAN modems are known to mangle the transport-level frames due to bugs (in the implementation of NAT) and excessive buffering (to improve one-way file transfer benchmarks).
If you think you can add CRC later you are going to loose by not detecting corruptions early.

3) In my experience JSON is probably the close to being the least resilient encoding possible. I can't disclose proprietary data, but I have over a decade's worth of reliability statistics for various  remote services (RPC-like) that are sold by organizations I consulted. But the rough ranking is
as follows: (from the least errors to the most)

3.1) ultra-lean character-based protocol similar to FIX, designed originally for MNP5 and V.42bis modems, currently used through a simple TCP/IP socket
3.2) SOAP (RPC over XML) with Content-Length, Content-MD5 and DTD verification enabled
3.3) SOAP and plain XML-RPC without the above strenghtening options
3.4) JSON-RPC
3.5) RPC over e-mail with various human-readable encodings

All the above are primarily sold to small businesses and individual traveling salespeople, which seems to be the target market you are planning to serve. We also have enterprise-oriented services using various MQ and *-remoting technologies, but the services offered aren't directly comparable. I thing that JSON could be an acceptable choice if you from the start demand the strengthening by some form of Content-Length and Content-Checksum. JSON is also infamous for letting people easily make byte-endianness mistakes, very much like current "getwork" which is neither big-endian not little-endian. Yes, JSON saves a lot of bandwidth when compared to XML. But I know of no presently available implementation that isn't producing cryptic and hard to troubleshoot failure modes. It is a classic example of a "lean but very mean" design.

4) You somehow read the my earlier suggestions about IPsec imply high-end large-volume target market. The reality is quite opposite: Windows support IPsec since 2000, Linux for a long time, Netgear ProSafe family has several models in $100-$200 range, L2TP and PPTP are available for free on all iPhones,Blackberries,Androids; many Nokias and other smartphones. The real hindrance is the HTTP(S)-uber-alles mindset, not the actual difficulty and cost of the implementation.

In summary I'd like to say that you wrote a very interesting and thought provoking proposal. I just think that the range of the targets you are hoping to cover is way too broad ($3 AVR processors, shared hosting plans, home computers, etc.).

I have my personal litmus test for the technological implementation in the Bitcoin domain: it has to support (and be tested for) chain reorganization. Preferably it should correctly retry the transactions upon the reorg. Absolute minimal implementation should correctly shut down with a clear error message and a defined way to restart the operations. Any implementation that will behave like Tom Williams' Mybitcoin.org blame-it-on-the-chain-reorg is a failure. Thus far your proposals don't seem to encompass this essential feature of Bitcoin. If Electrum (and associated protocols) aren't going to behave properly in the presence of chain reorganization events then I withdraw my earlier opinion that Electrum has more potential than the Satoshi client.

Thank you again for your time and attention.
hero member
Activity: 714
Merit: 500
suggestion for network name:

electricity
funny  Grin
legendary
Activity: 1386
Merit: 1097
vip
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
I fully agree with you. I think building services on top of bitcoin is much smarter than changing the bitcoin protocol.

I don't think the core bitcoin protocol would need to be changed.  It would be replaced entirely, for clients designed to use another protocol.

Reasons for a new protocol might include:
  • supporting clients which act as full nodes, but which have never seen the full blockchain (working with a pruned version)... the current protocol assumes all nodes have the full block chain... there's no language for saying "I have a pruned block", or for reconciling what on a block should and should not be pruned
  • passing around metadata that doesn't belong in the block chain, but nevertheless is useful against 51% attacks (e.g. signed messages acknowledging who has seen what blocks)
  • supporting queries against nodes with the full block chain, for the benefit of light nodes
  • some sort of mutual authentication where necessary (for example, if I'm a light node, I'd prefer to query a node I trust, rather than a random one, and would prefer that its response to my query be digitally signed... likewise, that node might charge for this service, and might want to know who I am as well)
  • possibly, a service that could handle multiple cryptocurrencies or alt chains (not that I'd be a fan of this, but it's a legitimate feature that may prompt someone to do a new protocol)
  • a mechanism for clients to only ask about messages that pertain to them, to cut resource costs (e.g. client asks, "only tell me about transactions involving " and/or "only tell me about new blocks".

Presumably, any such protocol would be created without the support of the main developers, and probably would appear out of the results of efforts to make a new client where the current protocol was seen as constraining, -or- where there would be some advantage to having this new client talk to other nodes of that same client (presumably because satoshi client won't relay its custom messages).
legendary
Activity: 1386
Merit: 1097
Yeah, I thought this would be a good idea as well.

My independent imagination of this concept was that of a "supernode"

Grid servers of such overlay network will need full blockchain, so yes, they turn into some kind of "supernodes". Using lightweight clients for normal people is very rational choice, because those end users don't need to care about bandwidth, CPU usage and they don't need to wait for blockchain sync if they're using Bitcoin once per week.

Although I'm proposing "some kind of supernodes", I don't like centralizing of blockchain, I think it' real threat for Bitcoin. That's the reason why I keep running full bitcoin node on all computers where I can.
hero member
Activity: 742
Merit: 500
Some people are asking me why I don't just extend Bitcoin protocol. I think both things are solving another problems. Bitcoin P2P network is distributed database, it's storing blockchain and handling transactions. My proposal is more about services on top of this database and I don't think they can be provided purely thru p2p network. Also, I don't think that bitcoin p2p network should care about such "services" like distributing USD/BTC price or similar.

I fully agree with you. I think building services on top of bitcoin is much smarter than changing the bitcoin protocol.
legendary
Activity: 1386
Merit: 1097
I think that it was just a matter of time before a parrallel/sidechannel network was developed.

Well, the purpose is only provide bitcoin-related services for any possible device or application, where keeping blockchain locally is overkill. I definitely don't want to develop anything which is replacing bitcoin. I just see the concept of various transports (TCP socket, HTTP poll, HTTP push, even email interface!) very flexible.

Some people are asking me why I don't just extend Bitcoin protocol. I think both things are solving another problems. Bitcoin P2P network is distributed database, it's storing blockchain and handling transactions. My proposal is more about services on top of this database and I don't think they can be provided purely thru p2p network. Also, I don't think that bitcoin p2p network should care about such "services" like distributing USD/BTC price or similar.

hero member
Activity: 742
Merit: 500
Following.

I am very interested in Electrum/thin clients and have the bandwidth/hardware to run a supernode so am willing to test.
vip
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
Yeah, I thought this would be a good idea as well.

My independent imagination of this concept was that of a "supernode" - one that could be depended upon to seed the block chain, replace IRC as the peer-finding mechanism, provide exchange rates, and (in combination with an idea that I had recently published on another thread) sign blocks and provide hint information as to how to resolve major forks in the chain if they ever came up.  Such a service could either be free, or could be a paid model (where whoever's running it has an incentive to do a good honest job because they're able to make a business out of it).

Supernodes could also provide constant confirmation that all supernodes are in contact with one another (e.g. by each of them signing the blocks they receive, exchanging the signatures, and sharing them with their clients).  They would be a valuable resource in the event of a 51% attack.  In the event of a real attack on the main chain, the operators of supernodes can manually checkpoint the honest chain.  Then, they would invite everyone else to connect directly to them (using the -connect command line argument) and effectively censor out the attacker's chain, keeping the bitcoin network functional while the developers rushed to come up with a technical solution that allowed automatic rejection of the attacker's chain.
legendary
Activity: 1708
Merit: 1010
I think that it was just a matter of time before a parrallel/sidechannel network was developed.
legendary
Activity: 1386
Merit: 1097
Few days ago I started the discussion in Electrum client thread about new protocol and server implementation of overlay network over Bitcoin p2p network. I think that discussion is not anymore relevant to Electrum client itself, so I started this new thread dedicated to my proposal. Please comment my proposal, ask to anything or suggest any improvement if you want.

Network protocol proposal (in progress): https://docs.google.com/document/d/17zHy1SUlhgtCMbypO8cHgpWH73V5iUQKk_0rWvMqSNs/edit?hl=en_US

Server implementation (in progress): https://gitorious.org/stratum/

Running nodes:
  • london.stratum.bitcoin.cz (TCP - 3333, HTTP - 8001), provider: Linode.com
  • chicago.stratum.bitcoin.cz (TCP - 3333, HTTP - 8000), provider: BitVps.com (thanks!)

Short quote from google document, describing main purpose of such overlay network. (current codename is "Electrum platform", but I'm searching better name ATM: edit: "Stratum" won the contest for network name.

Quote
Electrum platform is a framework for creating lightweight Bitcoin clients (= clients without a blockchain, keeping only private keys). Absence of blockchain on the client side provide very good user experience, client has very small footprint and still provide high level of security and privacy.

Basically Electrum is overlay network on the top of Bitcoin P2P protocol, creating simplified facade for lightweight clients and hiding unnecessary complexity of decentralized protocol. However there’s much bigger potential in this overlay network than just providing simplified API for accessing blockchain stored on Electrum servers. For utilization of such potential, we definitely need some robust protocol providing enough flexibility for various type of Electrum clients and their purposes.

Some advanced ideas for Electrum network, which will need flexible network protocol:
* Integration of BTC/fiat exchanges into clients
* Wallet storages for diskless or extremely low-resource clients (AVR-based hardware wallets)
* Server-side escrows (sending bitcoins to email)
* Integration of bitcoin laundry
* Exchange calculators (for providing “fiat” equivalents of BTC in clients)
* Firstbits support
* Mining support for clients
* Various transport protocols (especially HTTP Push, which allows PHP websites to integrate with Bitcoin easily)

Requirements to protocol:

Quote
* Protocol should be as simple as possible. Some clients aren’t capable to handle high-level message systems like Google’s Protocol buffers or Apache Thrift.
* Protocol should be text-based. Some languages cannot handle binary data (javascript) or it’s pretty difficult to implement it correctly (PHP).
* Protocol must support standard RPC mechanism (request-response). Request should contains method identifier and parameters, response should be able to transfer error states/exceptions.
* Mapping between request and response must be clear. Don’t allow vague relation between request and response. Some message-based systems use only textual conventions to map requests and responses together, like ‘firstbits_resolve ’ expects ‘firstbits_response
’ or ‘firstbits_error ’. It creates ambiguous data flow, avoid it.
* Protocol should support publish-subscribe mechanism. Client can subscribe on server for receiving some kind of information. After this request, server will proactively broadcast messages to subscribed clients until client disconnects or cancel it’s subscription.
* 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.
Pages:
Jump to: