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, 1x10^-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) - A1, A2, ... 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.