Lords of a new economy

Pondering Bitcoin, I recently opined:

Who sets the difficulty of the puzzle and all that? The computers in the network do - when the system was created, rules were agreed, and written into the software. As everyone runs software following those rules, anybody solving easier puzzles or trying to award themselves more bounty for doing so will have their bounty-claiming transaction rejected as invalid. To loosen the rules, a majority of the computers in the system will all need to accept the new rules - so it will require consensus from the community.

I've been thinking more about this.

What does it really mean to say a transaction is "accepted" in Bitcoin? I want to pay somebody 10BTC for a piece of computer hardware. So my bitcoin client software looks over my bitcoin addresses, and assembles a transaction stating that I take money from a bunch of previous transactions that send money to my addresses and send 10BTC to one addresses, and the change to a newly-minted address of my own. That's signed by my private keys, to prove I own the addresses the money is coming from, and fired off into the Bitcoin network. Which, in practice, means it's broadcast so the whole world sees it.

Now, anybody seeing that can check it's valid, by looking at the global transaction history to see if the source transactions were valid, and that the transaction is signed to prove that I was the owner of the addresses those transactions paid into, and so on. So the recipient knows I'm sending them the money within a few seconds. However, there's a number of frauds I could be committing, including taking advantage of network delays to spend the same money twice - which won't be detected until the second transaction also arrives at the recipient and they realise they've been duped. So there's more to it than just that.

You can consider money to have "cleared" into your address if, and only if, other recipients will accept you transferring that money to them as valid. So if some of your balance is from a dodgy transaction, and you decide to try and spend it anyway, then the new recipient should reject that.

So to build a global standard of "accepted transaction", we have the bitcoin miners. They all run software that checks the validity of transactions, and assembles groups of accepted transactions, and then invests significant effort into demonstrating that they agree with it. This means that an onlooker can tell that the majority of the miners agree on the validity of a transaction if lots of proof of it accumulates. Currently, the standard is that this involves about an hour's total computation from the majority of the miners in the system. If your transaction has withstood that much scrutiny, then it's considered "baked in", and transactions spending the money you received in that transaction will now be considered valid in turn - in other words, you can now spend the money. The miner's reward for providing this service is that they are allowed, subject to certain constraints, to sneak in their own transactions that let them create money from nothing and give it to themselves; and they also get any transaction fees that were provided with the transactions they accept.

So "validity" all boils down to what transactions more than 50% of the miners will accept. If there was a bug in the software that let a transaction which created money from nothing count as valid, then the miners would accept it as valid and it would be baked into global history. And therefore the senders of those transactions could magic money into existence. Not cool.

But if that bug was found, and a new release of the software rushed out, then that loophole would be closed as soon as more than 50% of the miners ran that software. Indeed, if such a bug were found, many miners would probably stop mining - as contributing to devaluing the economy would reduce the value of the bitcoins they can award themselves for doing the mining - until the patch was in place; bitcoin transactions would just hang in limbo until it was ready.

Nonetheless, it seems that a lot of scrutiny needs to be applied to new versions of the rules miners use to validate transactions in case they have loopholes. As they are the rules of the Bitcoin economy. And a LOT of scrutiny needs to be given to the implementation of those rules, which is where it's really easy to let bugs in.

Changing the Rules

For instance, as there's a cap of about 21 million bitcoin in existence, and each bitcoin can be divided into at most a hundred billion little pieces, there's a constraint that you can never spend an amount smaller than a 21*10^17th of the total value of the economy. When we're a universe-spanning colony of post-singularity time-bending superbeings, that might be an issue.

But it could be fixed. Just create a new currency, within the same bitcoin infrastructure (but with its own transaction types for transacting it). And then create a new kind of transaction which splits N bitcoins into N*2^128 "minicoins", and another which does the reverse. You'd extend the "is this transaction valid?" routine to now accept four kinds of transactions: Traditional bitcoin ones, new minicoin ones, and the two directions of exchange transactions. If everyone agreed that was a good idea, and all the implementations implemented it, and everyone installed the new implementations, then after a while, people would start to find their test transactions attempting to split a bitcoin up would be accepted by the global mining community. At which point, the new change would be "in". The changeover to the new implementation should be done at the same time across all the miners if possible (perhaps at an agreed block number), as otherwise, miners running the new rules before a majority of the mining capacity is would sometimes win blocks that don't get accepted by the majority, losing their bounty (and, therefore, having wasted their time).

A similar process could be followed to change the rules for generation transactions; perhaps the bounty rules might be changed so that the system will no longer cap at 21 million BTC, but grow with the size of the economy or something.

Which is very interesting.

Making the change would require consensus amongst the implementation teams (currently, there's only really one, with Freecoin hopefully soon being another) followed by consensus amongst the miners to install the new implementation.

Compare that to the analogous process for national currencies: governments can choose to print more or less money as they see fit, while a tangled combination of laws and banks generally define the rules for transferring funds. The Bitcoin economy is, largely, defined by the miners and what transactions they choose to accept. They know that if they change their rules to unfairly benefit themselves over non-miners, then they can't stop more people joining up and becoming miners too, dissolving their advantage with more competition; and if they ruin the Bitcoin economy, everyone will start a new one with saner miners, and their mined bitcoins wil become worthless. There's little incentive for an individual miner to accept transactions that other miners wouldn't; because if they win a block with such a transaction in and try to claim the bounty, the others would reject their block due to the bad transaction, and they wouldn't get their bounty accepted. It's in nobody's best interests to vary the rules without gaining a consensus between the implementers first, so any change to the rules will necessarily be rather conservative and careful.

But, the bitcoin economy needs to be careful. Don't let any one miner (or mining pool) get too close to 50% of the hashing capacity. And get more competing implementations of the rules in place. Bugs in the system would hit confidence in the economy hard, even if they were fixed rapidly. (Also, rolling out en emergency bug fix would probably be the easiest way for an attacker to try and slip a new bug in with insufficient review).

And... back to politics

It's not often that you get to see anarcho-capitalism and enlightened self interest having such free reign of expression; and it will be interesting to see how it pans out.

Currently, powerful vested interests (largely, big business) have found ways to lobby governments to do things in ways that benefit them. What will happen if bitcoin becomes a significant proportion of the world economy? There will be cries that we can't let the world be run by a bunch of nerds. Perhaps countries will enact rules that bitcoin miners on their soil have to run approved software, and those countries will form an international committee to decide what rules that approved software should run. Or perhaps private bitcoin mining will be made illegal, and nations will set up their own supercomputers to dominate the mining capacity, with their own rules controlling the money supply. I can see that happening; and then anti-money-laundering rules (transactions above a certain amount need to be signed with an X.509 identity or similar?) will be introduced. But that will, at worst, just cause a fork of the chain, as people who want an unregulated economy will just go off on their own separate way with the old rules.

Garden design (for geeks)

When I was about 11, I designed a garden. I remember drawing a plan of it on a page of my spiralbound notepad. Sadly, that means the original design is now long gone, but that's irrelevant - the original design assumed a plot of land the exact same shape as a page of my notepad, which is unlikely.

The important thing is that I can remember the concept.

The idea was simple - I think of a garden as a fun place to relax. Be that a pleasant spot to read a book, or a venue for a party. Where, to me, "party" involves a buffet and background music and people mingling and chatting.

Therefore, I wanted to pack in a pleasing variety of spots to read/sit/chat into a limited space. Also, being a geek, I wanted it to be intellectually interesting.

So the answer was obvious - it had to involve a maze. But more than that. Two mazes. Why not have a stream and little ponds that forms a water-maze, and then overlay that with a maze you can walk, with little bridges and stepping stones and the like where it crosses the stream, to add interest? And use a variety of materials for the maze; hedges, walls, balustrades, the stream itself - all can form barriers of varying solidity. I love strings of lights in trees and bushes, so let's run lights around it. And have lights in the stream and its ponds. Lights are pretty at night.

One idea that appealed to me was that, for parties and the like, you could have little boats with candles in circulating around the stream. Of course, if it's an actual natural stream, then all the boats would end up stuck at the grating you'd need to put up to stop them all going downstream - but if it's an artificial one (in effect, a long thin pond that wriggles around the place) you could encourage a continuous current around it by putting pumps around the place, sucking in water then emitting it in a jet, with the jets and inlets all aligned around the circuit to push the water in the same way. Extra points for style: Computer control of the pumps so, at the end of the day, you can cause all the boats to congregate in one place for easy collection...

There would need to be a more open patio / lawn area joining the maze to the house, for when you need to gather everyone together to eat and so on. And it would be nice if the other end of the maze led into some more wild and natural terrain such as woodland, after all that order. But the maze would pack a lot of different little nooks into a relatively small space, creating a garden that seems a lot larger than it really is...

I'd draw up a plan, but of course, the actual implementation totally depends on what the land you have is like, and what bits of random architectural salvage turn up to build the maze out of!

AURUM

My recent thoughts about bitcoin reminded me of earlier thoughts I'd had about digital currency.

Cryptographic digital currency is a way of transferring value without trusted third parties being involved in every transaction, but within a closed domain, it's easier to go for a trusted party and cut out all the crypto maths. Which is why we have printer credits managed in a central database when we use a shared printer. We may use a digital currency to buy a credit, but once we have credits, we're happy for the owner of the printer to just store our balance in a database and decrement it whenever we print.

And within a company, complex processes are used to transfer money in and out of the company's actual bank account, but budgets within departments are usually allocated by just asking somebody to update a spreadsheet. Money moves within the company using easier, faster, simple methods than bank transfers, writing cheques and letting them clear, or exchanging cryptographic keys.

It's the same story for "ulimit" mechanisms in computer operating systems, and language-level sandboxes, that allocate budgets of things like CPU time and memory space to software running in a computer.

So, when I set out to design AURUM, the resource limit system for ARGON, I decided to make a unified abstraction across all of the above. A process has a budget, which contains arbitrary amounts of arbitrary resources; and it can subdivided that budget into sub-budgets.

That's just an accounting system, though. It needs to integrate with actual resource managers. For something like CPU time, for efficiency, the scheduler probably wants a nice simple machine word reserved for "jiffies in the budget" attached to a process context in a hardcoded way. So the AURUM system probably needs a handler for "run out of jiffies" that takes more from the actual AURUM budget and "prepays" them into the process context - and when the process' balance is requested, knows to ask what's been prepaid and not yet used, so it can report honestly. If the process is stopped, any remaining balance needs to be put back in to be re-allocated to the parent process' budget. And so on.

Similarly, interfaces to actual electronic banking (spend money in a budget by causing an actual bank transfer, or bitcoin transaction, or whatever to happen), and interfaces for incoming budgets from external sources (a bank account interface that fires off a handler when an incoming payment is detected - with that payment as the handler's budget so it can then allocate it appropriately), and so on, can be built.

And a power-constrained mobile device might have joule budgets - and operations such as driving motors, transmitters, and lights might use them up. That would be neat for handheld computers and deep space probes, which can then run less-trusted code in a sandbox with controlled access to expensive resources.

That's all well and good as a way to manage finite resources in a system, but the next level is to take a step back, look at the system as a whole, and see how this facility can be used to do other cool stuff.

This leads naturally to the semi-forgotten discipline of Agoric computing which seeks to make marketplaces and auctions a core tool to solve resource allocation problems. This has scope within an ARGON cluster, if it's shared between multiple organisational units, which can then use budgets purely within AURUM to manage their shared use of the computer resources and to contribute towards its upkeep accordingly.

But, more excitingly, with mechanisms like Bitcoin allowing for money to be transferred across trust boundaries, it starts to become practical to think about allowing our computers to participate in economies between them. What if my desktop PC and servers rented out their space disk space, CPU time, and bandwidth to all comers? And with the money they accumulated from doing so, in turn rented offsite disk space for their backups, and when I gave them a particularly tough job to do, hired some extra CPU and bandwidth to do it, dynamically? Without me having to hand-hold it all as the middleman, pulling my debit card out to pay for resources... If I wanted to do lots of resource-intensive work I might put more money in from my own pocket to give it more to hire extra resources with; if I tend to under-use my system and it makes profits from renting out spare capacity, then I could take cash from it from time to time.

I guess the first step would be to create standard protocols in AURUM for things like auctions and commodity markets, to facilitate transferring between different 'currencies' such as CPU time, bitcoin, fiat currencies, printer credits, disk space, and the like. And a standard interface to bank accounts, where balances and transaction histories can be queried, and transfers requested. A bank account in the context of AURUM would be a third party that holds control of some budget on your behalf, so it should look like an ordinary budget in every way possible. That would make it practical to have software that needs a given resource to find a way, through a registry of trusted markets, to convert them into the resources it wants.

That'd be neat...

Bitcoin security

I've been learning about Bitcoin lately.

It's an electronic currency. I've seen electronic currency before - in the late 90s there were efforts to create them based on virtual banks issuing coins. The coins were basically long random serial numbers which, along with a statement of the value of the coin, were then signed by the bank. The public key of the bank is published, so people can check they're valid coins issued by the bank. The idea was that rather than withdrawing a bunch of notes from the bank, you can ask the bank to mint you a bunch of these signed numbers instead; and anyone who sees them can check their value, and eventually, return them to the bank (which can also check their value in the same way) to get their account credited.

This simple approach has two problems: the coins can be traced by their unique serial number (even more conveniently than the serial numbers on notes, and about as conveniently as card transactions and inter-bank transfers already can), and that it's hard to detect somebody spending the same coin twice - as it's just a number, you can make as many copies as you like. Various elaborate cryptographic techniques were proposed to avoid this, with the person withdrawing from the bank choosing the random numbers and letting the bank "blind-sign" them without knowing them, people spending the coins having to hand over a recipient-chosen random set of bits from a secret number such that if the same coin is spent with two different recipients enough bits are revealed to identify the double-spender, and so on...

These things just complicate the process of transferring funds, in ways that make it harder and harder to trust the security. And it leaves a currency that relies on central banks to issue it (which can be exploited by determined and/or powerful attackers).

So, enter bitcoin. I won't bore you with the deep technical details (see the paper for that), but the basic idea is this: I have a pool of bitcoin addresses, which are just public+private key pairs - the well-studied basis of cryptographic digital identity. Other people can send money to those identities by issuing transactions, signed by an identity that has enough money, specifying the hash of my public key (my address, that I publish) and an amount to transfer. For this transaction to be valid, there has to be enough money in the source address - so trying to spend the same money twice means the transaction is not valid. The money assigned to any one address can be traced back through the transactions to an event that first created some money (more on that in a moment).

Now, how do people know if a transaction is valid? Because when I issue a transaction, it gets broadcast into the network. And all the other nodes in the network check their copy of all the transactions that have ever happened to see if it matches the rules. If so, they accept it - and demonstrate this fact by competing with each other to solve a Hard Maths Puzzled based on my transaction. The computer that does this first then receives a fixed bonus, which creates new money; and it also receives any optional "transaction fee" I put in my transaction, encouraging computers to pay attention to my transaction first.

That's really clever. My transaction is vouched for by other computers - ones I do not control - vouching that it meets the rules by spending their time competing to solve the puzzle and get the bounty. Claiming the bounty is a transaction much like any other, creating money from nothing and sending it to an address; other computers won't accept it unless the rules are kept (meaning there's no incentive for a computer to try and solve the puzzle for an invalid transaction, as other computers won't accept it and give them the bounty).

And the difficulty of the puzzle that needs to be solved, and the maximum bounty that can be claimed for solving it, changes with time. The difficulty is adjusted based on how quickly previous puzzles were solved, and the amount of bounty with the amount of money in circulation, so even as more and more computers join the system, the average time before a transaction is wholly accepted by the system remains about the same (about one hour) and the total amount of money in circulation will slowly rise for a while, then remain roughly constant (the bounties will get smaller and smaller until, eventually, transaction fees are the main motivation for trying to solve the puzzle).

Who sets the difficulty of the puzzle and all that? The computers in the network do - when the system was created, rules were agreed, and written into the software. As everyone runs software following those rules, anybody solving easier puzzles or trying to award themselves more bounty for doing so will have their bounty-claiming transaction rejected as invalid. To loosen the rules, a majority of the computers in the system will all need to accept the new rules - so it will require consensus from the community.

Bitcoins started off being worthless (so the original "miners" setting their computers to solve the puzzles made lots of them and hoarded them), but over the past months, they've started gaining real cash value. As I write this, they're about $5 each, and people are racing to build supercomputers to solve the puzzles faster and faster so they get a bigger share of the approximately 300 an hour that currently get generated as bounties. The recent meteoritic rise suggests a speculative bubble, which will burst some day - the ten I bought for £2.20 each yesterday are worth about £2.80 each today.

But the recent public attention (Forbes article, This Week in Startups interview) has caused people to start raising questions. Is this going to encourage money laundering, tax evasion, buying and selling illegal goods and services? Will it be stomped down on by governments?

I have a few thoughts on the matter.

Read more »

IPv6 versus NAT

I was enthusiastic about IPv6 when I first read of it, in the late 1990s. Mainly, I liked the autoconfiguration, and the inbuilt support for anycast and multicast, which are used to great effect: there is s standard IPv6 address for "my nearest time server" and the like, which has various benefits.

However, it comes at a cost. It's a whole new Internet that has to be built alongside the existing one and a careful handover done with complex mechanisms to let them coexist transparently. And the better autoconfiguration of IPv6 isn't that useful in the presence of recent developments such as automatic IPv4 address assignment, mDNS for finding things, and of course, good old DHCP for managed networks.

And it's not working. More than a decade has passed, and IPv6 is still a toy. It's extra work to set up, and the IPv4/IPv6 migration mechanisms you need to be able to still access the IPv4 Internet actually break existing stuff, mainly because the IPv6 side isn't being maintained well (so often breaks without being noticied) and hosts using the mechanisms will prefer IPv6 over IPv4 (as otherwise, IPv6 would never get used, as almost everything that offers IPv6 also offers IPv4) if it's advertised.

So there's little motivation for people to bother turning on IPv6 - it's more work, and it breaks your Internet access (or, if you're a service provider, unless you're careful, it offers an alternate way to access your site that is more work to maintain, but breaks more often as you won't be putting as much effort into maintaining it). This means that the critical feedback loop of people wanting IPv6 because there are good things that are only on IPv6 will never kick in. It'd be stupid to try and be IPv6-only, but until useful things are IPv6-only, there's little incentive to even support IPv6 alongside IPv4.

Now, the main reason people say we should move to IPv6 is because of the IPv4 address space exhaustion. But there are other solutions.

The widespread one is Network Address and Port Translation (or "NAT" for short). Under NAT, an entire network has a single public IPv4 address and the devices inside the network are assigned addresses from a special private range (that can be reused for every private network), and outgoing connections get their source address and port rewritten so they all come from that one address, and when the replies come back, they're mapped back into the private address of the actual device. This means an entire network (which could be an entire organisation with millions of PCs, or an entire ISP with millions of customers) can use just one (or a few, if they need more ports to support all the connections at once) public IPs.

There are issues with this - the NAT device needs to remember what external ports are used by what connections, and it needs to keep track of when those connections are still being used so it can re-use the ports. But if a device is switched off or unplugged or dies, it will never explicitly close the connection,. so the NAT device has to discard connections that just aren't used for a long time, assuming the owner to have died. However, this means that long-lived connections that aren't used much tend to get killed. But since NAT is so widespread now, most apps that open those kinds of connections nowadays send "keep-alives", empty messages that just keep the connection alive so the NAT device doesn't forget them.

And it also means that devices behind NAT can't accept incoming connections; the NAT device only lets incoming connections out and remembers the return path for replies - if an incoming connection comes in, it has no way of knowing what device "wants" it unless it's been specifically configured with a "port forward". Standards like UPnP exists to allow devices to find their nearest NAT router and ask for a port forward to be set up, but they suck for various reasons I shan't elaborate right now.

This isn't a great issue, though. As a laptop user, I am resigned to being behind NAT most of the time. Almost everything I do from my laptop is based around connecting out to remote servers, and for the exceptions, I have an N2N VPN that lets my peers connect to me via an encrypted IP-level relay server. My long-lived SSH connections have keepalives turned on. It works out OK in practice.

However, I think it could easily be improved...

Before NAT became popular, the standard way of doing the same thing was via a SOCKS5 proxy. This worked much like NAT - you'd have a network using private addresses, and a single border device on that network that also had an Internet connection with a public IP. The border device ran some software - the SOCKS5 proxy.

When applications on devices inside the network wanted to connect to somewhere outside of the local network, rather than trying to reach it directly, they'd instead connect to the SOCKS5 proxy. Over that connection they'd send a request for the connection to be forwarded on. The SOCKS5 proxy would then open a connection, from its public IP address, to the destination server. It would then forward traffic between the two halves of the connection, making the device's connection to the SOCKS5 server in effect be a connection to the remote server - and back again in the opposite direction.

So it basically did the job of NAT, except that it required the devices to know about SOCKS5, and to know where the SOCKS5 server was. NAT won, as it was transparent: the NAT box just pretended to be a router offering access to the Internet (the "default route" you have to put in when manually configuring a network, or configured automatically via DHCP or PPP). SOCKS5 didn't really require you to modify the application (although many applications did add support to SOCKS5), as it was possible to write a "socksify" tool that pretended to be the OS's normal interface to the network (the "sockets API"), but which actually made connections via SOCKS where applicable.

But SOCKS5 doesn't have NAT's problems with keepalives. And it has a big advantage over NAT - the SOCKS5 protocol lets a client request an incoming connection, in which case the SOCKS5 server opens an incoming connection port on the public side and reports its address back to the app, along with a notification when the connection is taken up. It's a bit limited, as it only lets a single connection in (while a proper listening port lets multiple connections).

Also, SOCKS5 actually makes it easier to adopt IPv6. When an outgoing connection is requested, the app can specify an IPv4 address, an IPv6 address, or a hostname - and in the latter case, the SOCKS5 server could in principle find an IPv6 server at that hostname (with an AAAA record) and open an IPv6 connection, even though the application has connected to the SOCKS5 server via IPv4 - or vice versa, if the client connects to it via IPv6.

And unlike NAT, SOCKS5 has a login phase:: each connection can supply a username and password to identify the user. Under NAT, all you have is the private IP address of the device. This means that SOCKS5 servers can give better connections to more important users, and better log who did what (where that matters).

So perhaps it's time for a SOCKS5 comeback. The protocol has been extended to support IPv6, but I think it could do with a bit more sprucing up to make it more powerful and modern. Here's what I'd suggest:

• Proper listening socket support. It should be possible to request a listening socket, and if you are accepted, then be sent messages every time a client connects; but rather than your connection then becoming the relayed client connection, the accept message just gives you a magic token identifying the connection. You can then open another connection to the SOCKS5 server and, rather than requesting an outgoing connection, offer up the magic token to accept the incoming connection and have it relayed. Or just reply on the original listening-socket connection to reject the request.

• Listening sockets should be able to request a specific port to listen on, along with a flag to specify whether they're happy to accept another, or should just give up the attempt if they can't have the one they request. Such a request might be rejected due to it being already in use, or certain listening ports might be reserved for specific users.

• Better UDP support. The current UDP support in SOCKS5 amounts to asking the SOCKS5 server to set up a UDP relay. All your UDP traffic must then be sent to an IP+PORT the SOCKS5 server sends in the reply, with a header added to authenticate it; this eats up some of the limited available size of a UDP packet. It'd be nice if the UDP packets could tunnel over the SOCKS5 connection, like TCP connections are, with suitable framing.

• Ubiquitous support for SOCKS5-over-SSL in clients and servers. Then it can be used as a simple VPN - offer a SOCKS5 server on the public side of your SOCKS5 relay, too, that lets authenticated users who are outside of the office connect in to access servers on the private network. Or just trust your internal network less, as some SOCKS5 connections are better than others (due to being optionally authenticated to a specific user) so are worth stealing. For this use, it'd be nice if a SOCKS5 server could announce (when it's connected to) what addresses it provides access to - for a normal Internet gateway, it'd reply "all addresses"; for a VPN, it'd just report the private IP range.

• Better support in devices. SOCKS5 should be a standard feature of the sockets library, not something you need to hack in under an app. SOCKS5 should be in smartphones and tablet computers. There should be the option to specify a list of SOCKS5 servers as well as a default route (they can be connected to and asked what address ranges they provide, and connections made via them accordingly). DHCP servers should announce SOCKS5 proxies (there doesn't seem to be a DHCP option for SOCKS5 proxies; am I looking in the right place?).

I think that extending SOCKS5 in the above way (to make SOCKS6!) and then getting a good implementation of it open-sourced under a BSD license and thence it device OSes as standard would be a LOT less work than migrating to IPv6, while also offering an improvement over IPv4 with NAT - and yet also able to coexist happily with IPv4+NAT, as non-SOCKS devices can still be NATed via the default route.

So, how about it? If somebody volunteers to write a decent "SOCKS Next Generation" server (using nice scaleable event-driven IO and all that) and client, I'll volunteer to help you as best I can, and write up a proper draft RFC for the enhanced protocol. If we can get the server into consumer and small office ADSL routers (whose manufacturers seem to be quite open to adding extra features to the brochures), along with advertising themselves as such via DHCP option that clients listen to, it can be come ubiquitous and useful; then we can work on getting the ISPs that to support it (making sure our SOCKS server is happy to pass connections on to an upstream SOCKS server, for when we are proxying to an ISP's own private network). I reckon that'd be a few weeks' development time, at most, then it's all about the lobbying to get it accepted into OSes and routers.

Fame and glory await!