Practical Blockchain Telegraphy.

Mircea Popescu writes:

‘Now making an irc channel is quite the pleasant experience : you create something out of nothing, get to name it and are now the boss of it. For a generation devoid of proper “empire building” avenues, this is about as cool as it gets. So you can do anything you wish, right ? Your channel, your rules, that’s the deal! … But all is perhaps not quite right in this world. Driven by a deep seated intuition that perhaps no, perhaps this isn’t the deal, perhaps the whole charade’s an illusion, the kids in question move compulsively to test it. So they dump child porn or stolen bank credentials or whatever it is that’s taboo in the larger society they fear they might have failed to individuate from. … So how did the story end ? Why, with the Freenode admin pointing out that no, you can’t ban Freenode admins from your Freenode channel. Because while it is “yours”, it is nevertheless… a Freenode channel. And so the adventure came to an end, the kids weren’t interested in wasting time with the rotten foundation of pretend-ownership, and pretend-control and pretend-alodial, and Freenode wasn’t interested in wasting time with some users that were inclined to verify the limits of “your” and “yours”.’

At this point, the tale is familiar – in one form or another – to nearly everyone with an Internet connection. But, as Mr. P points out, we are now reasonably well-equipped to change the story’s ending:

‘So yes, because Bitcoin now I can have, if I feel like it, an irc network that works exactly the way those kids’ didn’t, a decade ago. They had no choice but to go home and cry about it, about their failure, about their dashed dreams and hopes, yet guess what : I do.’

The exact mechanics of this hypothetical network were left as ‘an exercise for the alert reader.’ Let’s explore one possible solution to the exercise!

What follows is perhaps the most obvious conceivable recipe using the ingredients at hand. The ’server’ and each ‘client’ need only a standard copy of ‘bitcoind.’ The clients – at least initially – will each need a certain amount of Bitcoin.

First, the engineering envelope – the smallest and largest useful transaction for this blockchain abuse.

Let’s start with the lower bound. Bitcoin transactions containing outputs of less than 0.01 are discouraged by the network (miners demand extra ‘fee’ to incorporate such a transaction into a block.) Hence all outputs must exceed the ‘dust constant.’

As for the upper bound: the Bitcoin protocol gives us 8 bytes for a transaction amount (in units of satoshi, 1×10^-8 BTC.) However, we cannot use all eight bytes for payload – unless the channel is to be inhabited solely by royalty.

So let’s pick an ‘amplitude’ range: an amount of 0.01001 to 0.01256 BTC for each individual byte of the payload.

But now we are faced with the fact that a Bitcoin transaction will only be incorporated into the blockchain in a timely manner if a ‘miner’s fee’ (traditionally, 0.01 or so) is included. So we do not want one transaction per byte of payload. Hence, an engineering compromise is suggested:

The ’server’ creates a ‘channel’ by generating a certain number (let’s say 32, but this is not a critical constant) of Bitcoin addresses (public/private key pairs) - A1A2, … AN.

Server and client alike decode messages by examining the Bitcoin blockchain and parsing out amounts sent to these addresses. No use is made of ‘exotica’ – i.e. human-readable fields of the Bitcoin transaction, and other ‘garbage’ that might conceivably end up pruned from the blockchain in the future.

The only distinction between the server and the clients is that the server is the fellow who has the private keys to the address array. The one and only responsibility of the server is to re-send the coins back to the originators (selectively! see below.)

What ideal value of N to pick for AN? This is left as an exercise for the alert reader. Consider that miner’s fees increase with ‘mass’.

A client may speak on the channel by emitting a transaction of the following form:

bitcoind sendmany “” ‘{”A1″:0.01256,”A2″:0.01256,”A3″:0.01256}’

This transmits the string 0xFFFFFF. If a string longer than N is to be transmitted, the address index must simply loop around. So, if we wish to ’speak’ the ascii string ‘foobar’:

bitcoind sendmany “” ‘{”A1″:0.01103,”A2″:0.01112,”A3″:0.01112}’

bitcoind sendmany “” ‘{”A1″:0.01099,”A2″:0.01098,”A3″:0.01115}’

Two transactions. If we assume a miner’s fee of 0.01 BTC included with each, the total cost of transmission is 0.08639 BTC (about $50 USD in today’s exchange rate.) Yes, 19th century ‘Western Union’ telegraph looks like a bargain by comparison. But see below.

We can easily anticipate the objection: “No one would speak on this telegraph – they would soon go broke.”

The answer: the channel operator would return the coin to the originating address. Not immediately, of course (minimizing transaction fees.) And, naturally, not to everyone – merely those who are welcome guests in the channel. Unwelcome guests (spammers, and bozos of any and all other species) will find that they have stumbled into a ruinously expensive waste of time – because they will never see their coin again. (What to do with the ‘bozo coin’ is for the operator to decide. He can buy beer with it, pay for his bandwidth, or parcel it out to the welcome guests – whatever pleases him.)

Thus, we have an automatic moderation mechanism. Likewise, we get cryptographically-strong identity ‘for free’ – originating addresses of the transactions become user identities (they can be matched with human-readable names in some agreed-upon fashion, e.g. using a magic ‘hello’ packet.) We likewise get a ‘free’ perpetual log of the channel conversations.

If the system is run as a closed loop, the only ultimate cost to the operator and clients is the accumulated miner’s fees – which can be minimized by choosing a large N for the address array, and by returning the coins to their originators in infrequent (e.g. weekly) parcels.

The mechanics of this ‘chat’ apparatus will encourage brevity – and perhaps, clarity of thought. Or, alternatively, it could easily degenerate into a kind of mournful ‘twitter.’ Only one way to find out…

One obvious criticism – ’slow.’ Sure, we can wait eight minutes for a confirmed transaction. Or we can parse immediately. Depends on one’s taste.

This entry was written by Stanislav , posted on Friday June 27 2014 , filed under Bitcoin, Computation, Cryptography, Distractions, Idea, Mathematics, ModestProposal, NonLoper, ShouldersGiants . Bookmark the permalink . Post a comment below or leave a trackback: Trackback URL.

4 Responses to “Practical Blockchain Telegraphy.”

  • jpt4 says:

    In-line with, but not identical to:

    • Stanislav says:

      Dear jpt4,

      Unlike Bitmessage – with this thought experiment, you don’t need to send any network packets other than ordinary Bitcoin traffic, nor does one end up creating any unusual blockchain transactions. The proposed scheme could be implemented using only a standard ‘bitcoind’ and two dozen or so lines of your favourite scripting language.


  • dexX says:

    Hehe, this is an interesting approach. In general abusing the blockchain as data storage is not a new idea and also not suitable for real time communication or anything alike in the first place in my opinion.

    First of all, this is a worth to read piece: “Hidden surprises in the Bitcoin blockchain and how they are stored” (

    But that aside a few numbers which might be good to know in this context:

    For Bitcoin Core clients of version 0.9 or higher (as used by a majority of nodes according to the dust limit is as low as 0.00000546-0.00000882, depending on the actual type. This number defines a minimum amount that an output must spent and otherwise the whole transaction will be dropped. Earlier clients use a similar numbers, but by a factor of 10x higher. You already mentioned those amounts are refundable.

    Transaction fees are basically paid on a basis of (whole, rounded up) 1000 byte transaction size packets and a widely accepted number is 0.0001 BTC/1000 byte. A “standard send” with one input, one output should roughly have a size of 180-200 byte. You’d probably want to combine several outputs in one transaction to reduce the cost overhead. Here is a chart that related after how many blocks a transaction confirms to what people pay:

    One OP_RETURN output per transaction is possible which can be filled with 40 byte of data. While there are several other options (e.g. using m-of-n multisig where some of the recipients are no recipients, but data), this is by far the most preferable choice. is a neat website that lists ASCII encoded data that was ever broadcasted and is one that lists OP_RETURN transactions and it’s content.

    Though undocumented, blockpop ( is probably the most advanced library for data storing in the chain, but you might as well take a look on other approaches and in particular worth to mention is probably Twister which is basically distributed Twitter via DHT (,


    • Stanislav says:

      Dear dexX,

      The proposed scheme deliberately avoids making use of anything but the kind of data likely to be preserved ‘forever’ – transaction amounts, for transactions deliberately not easily distinguishable from ‘genuine’ ones – coins moving back & forth to trade U.S. Dollars, alpaca socks, cocaine, cement, etc.

      Try to understand why.

      What is needed, in this thought experiment, is a means of storing data which cannot be obsoleted, mutilated, censored, or otherwise screwed with without destroying Bitcoin as a whole. Only encoded transaction amounts qualify – and certainly not ‘magic’ plaintext fields, any and all of which could probably be ‘vanished’ from the protocol tomorrow – to virtually no one’s complaint.


Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" highlight="">