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

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

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.

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.  

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.

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

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

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

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.



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.

funny 

molecular, you probably wanted to post it there: https://bitcointalksearch.org/topic/closed-2-btc-for-suggesting-a-name-of-an-overlay-network-on-top-of-bitcoin-55822 :-)

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

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.

I fully agree with you. I think building services on top of bitcoin is much smarter than changing the bitcoin protocol.

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.

Following.

I am very interested in Electrum/thin clients and have the bandwidth/hardware to run a supernode so am willing to test.

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.

I think that it was just a matter of time before a parrallel/sidechannel network was developed.

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.


Requirements to protocol: