Drawing on what I know about espionage theory, legal systems, monopolies, insurance, racketeering, and extortion, I have dreamed up a concept for how to implement a marketplace in a hostile environment. This is a concept for something that gets even easier with a smart contract system like Ethereum, although for the street people, really, bitcoin is the best for now, because it is possible to get it in and out, in most places quite easily.

How do black and grey markets get shut down?

Usually, in the middle of the network, there is the administration, the people who do most of the communication, do the accounting, and manage security for the members of the network. But usually these measures are weak. The most probable way for a black market to get shut down is by determining social networks, by looking for who visits who, and where. It is easy enough especially if the delivery of the contraband is personal, but this little outer-tentacle is not necessarily privileged to anything. Maybe they have only one link further into the network.

So either you watch this person, trying not to let them know, and you establish their movements, and associates. Then you sift through the associates, and the circuit repeats. But on the street, the closer you get to the central nodes of the network, the more dangerous it is, and the more careful they are.

This is why these markets tend to have vicious, clever psychopaths at the centre, and as you move outwards, more petty and pitiful hustlers.

Communication in the network is centralised, and obedience is required to protect the money makers at the centre.

The little fish are expendable. They are also of limited use to the would-be attackers, and often, being a leak, a blaggart, just generally using this job as a thing to boast about, can often get back to the centre, and get you killed. Or maybe just driven a very long way away from home with a bag over your head, and dropped in a foreign country.

But how can this be done, with the empowerment of distributed, encrypted network systems? Without using violence? Eliminating violence from a black market is a very desirable goal, and the most lofty goal of the theory of Agorism.

Well, we have immediately presentable technologies right here right now. Bitmessage can be both an advertising system, and a coordination system for order processing. And obviously, cryptocurrencies can become the money of the network. Bitcoin is the simplest, as I have mentioned in a previous post, going from fiat to bitcoin now is as simple as feeding money and a special code into very widely distributed machines that are used to let people pay bills without having to go all the way to a cashier's office of a company whose services you use.

Dead Drops

A key element in the design of this hypothetical system is the use of dead drops. There is many places within urban centres, and especially when the contraband is very small in size, where an item can be dropped, and then the recipient notified through a bitmessage, with coordinates and perhaps a link to a photograph of the vicinity of the drop. Dead drops, carefully operated, can allow a delivery to take place, without the exchanging parties being observed together. Indeed, the two parties may not even know each other, it is better if this is the case.

The delivery process can be protected by issuing an encrypted USB stick which the operative has been trained in how to use it. Largely, it is just about the secure communications system, but if the configuration of this little live installation is set up by the people in the centre, not only can they use it to coordinate with outlying members of the team, the team can use it to communicate with their immediate next colleague.

For example, a buyer, or producer of a contraband item, is sent an order by the warehousing node. The Buyer can be requested to procure, or notify the Warehouser of a new item or source at some given price. The procurement order is then issued, the Buyer designates a drop, and the Warehouser then sends an emissary to retrieve it and bring it back to the warehouse, where it is securely stored.

The Warehouser's job is to keep a track of standing inventory, of changes in availability of supply from the Buyers, and periodically, using a broadcast message, updates all in the network the current state of their supply, and possibly, expectations or predictions about upcoming changes.

Then, when an order comes in, on the same broadcast channel the Warehouser uses to keep the network updated, the Administrator then accepts the payment, or if it is a two signature multisig, they draw from the petty cash pool, which is precisely for this purpose. The administrator pays the Warehouser for their costs, and including the fee for their courier, and the Warehouser sends out an emissary to place the order at a drop, where the Courier picks it up, drops it at a new drop, and then afterwards, sends the location of the drop to the customer.

Then we have the administrator.

The administrator is at the centre of the network. Their task is to field orders from customers, and as money flows through, divide it up and distribute it onwards for order fulfilment. They also know the contact reference for every node in the network, whereas Buyers only know Warehousers, and Warehousers also must know Couriers.

The administrator takes orders, and then after taking their admin fee cut out, they also divert another small percentage into a pool of funds in which is managed the funds provided by investors, and serves as a pool of resources for protective activities that the Administrator oversees. Some also goes to maintain a 'petty cash' balance which is used for covering paying Warehousers and the Couriers to deliver, and then the customer can place the second signature on the transaction, and the Administrator then distributes the funds, taking their fee, replenishing some portion into the petty cash pool, some into the insurance pool, and the remainder goes into the Shared pool, in proportion with the stake of each shareholder.

This Shared pool has an important purpose. The stake one holds in it increases the payments received during distribution of profits. This fund can also be disbursed by the Administrator and one of the other two key-keepers, at the request of the shareholder. The size of stake weights voting processes, when a decision about some change needs to be made. Whoever has the biggest stake, has the biggest vote, and so on down the hierarchy. This incentivises stakeholding, to start with, but it also gives a benefit, in that those with the biggest stake have the most to lose if something goes wrong, the possible scenarios I describe below. And not only that, if such a stakeholder does get in trouble, they can instead of making a claim from the insurance pool, pay for their defence with all or part of their stake, by designating a third party who will be given the time-based authentication code that only the authentic owner of the stake in the pool can know. Besides, if things go wrong for them, they may decide to leave the network altogether anyway. The bigger stake a node holds, the more likely they are to get away clean, with their earnings, and thereby also by leaving the network, leave attackers one less node to grasp hold of the central parts of the system.

Each member in the network has a deduction taken out of their payments, and it is placed in this administrator-managed pool. This pool should be multi-signature, and each member of the network, including investors, have an address on the wallet for this, towards which they can send funds, but also tracks the overall amount of money they have been bringing into the system. The allocation of these 'taxes' is weighted by stake. The bigger holders get more, because it is better for everyone if there is more, so having more means certain other mechanisms can be more powerful, such as funding the development of the encrypted access devices (encrypted live USB disks), and when it comes to such as the very important IT manager getting paid for managing the infrastructure (They are the tech administrator, whereas the Administrator manages orders and communications with all the other nodes).

The IT manager's job is to build and distribute the means by which the network communicates, and as much as possible, automates the distribution of funds. They produce simple documentation and when new customers, buyers, warehousers, couriers or administrators join, they have to teach the new members, but not just teach them, because this makes them vulnerable. They have to teach others, to teach others, and they have to make the interface as simple as possible to understand. The dead drop distribution system allows new issues of these devices to also propagate without linking people together.

All involved are motivated to know how to use the system, because it enables them to be isolated from each other. By being isolated, if one goes down, not everything goes down. Emergency protocols can then be invoked, and this is part of the reason why there is an automatic distribution of part of all payments to members of the network into the 'Share Pool' at the centre. These payments are investment, and insurance. One is a user's stake, the other is a pool that is used to help a fallen node.

Dead Man Switches

It is possible to passively monitor the status of a fallen node, by the fact that it does not check in and let the administrators, and between buyer and warehouser, and warehouser and courier, and between the administrator and the courier, that a node has gone dark. For this reason, there is a protocol that operates like a dead man's switch. Each node propagates an enccrypted, time-based 'heartbeat' message on a daily basis to a broadcast channel on the network. This sensitive information is sent to the administrator, who holds the time-based key that can unlock the message, and inside that, it is encrypted to the Administrator.

Yes, this does mean that administrators hold a privileged position, but that is because it is their job to protect their flock. They get paid for this, and in this system, they can also issue a total kill signal across the network, and all the nodes tied to it wipe themselves clean, in a total DefCon IV type situation where multiple nodes have gone dark. No evidence on disk, even with the password, means it becomes very hard to get at the rest of the network. This encoded message can even be a self-destruct message link, ensuring that once the code is decrypted, and the URL accessed, knowing the unlock does an attacker no good, and the trusted third party is notified and forwarded the funds, whether the insurance claim, or some or all of the node's stake in the Share pool.

But there can also be a less irreversible broadcast from an Admin or IT manager who suspects there may be trouble afoot, that of a network blackout, for a given period, with instructions, for the safety of all nodes, to sequester their access devices and any stock they may have on hand, take it to another secure location, as soon as possible, and await the prescribed period. This notification can cause the access device to immediately shut itself down even before the user is prompted for the key, until the designated time period elapses. And if in this period, the Administrator decides that the access device must be purged, this signal will propagate and within a short period of time, given that the access device is booted, rather than copied and cryptoanalaytically attacked, all of the data will quickly be wiped. The shredding procedure will hit the most delicate parts first, the secret keys, and the mailboxes and wallet keys controlled by the access device, and then, the whole thing wiped.

The administrator can also monitor the network for activity at this point. By the use of a distinct time-based key issued to each node by the administrator, that is to be used for direct messages with the administrator, if messages hit any of the associated addresses, the broadcasts and the administrators, without this time based key at the end of the broadcast heartbeats, it can then be known that a node is compromised, or alternatively, the likely identity of a compromised node, and then when the blackout is lifted, all other nodes are warned to not deal with this suspected node.

Thus, yes, each node must know two passwords. One unlocks their USB device/laptop, the other is known only between the admin and each individual node, and allows the administrator to be sure that whoever is operating the node's access device, if it has been compromised, and immediately they can send the killwipe to this one, also, and the last heartbeat from this node prior to this gives the approximate location, and the administrator's special key, the one for the time-based authentication signature, the administrator can contact the or trusted third party, lawyer by sending out the special USB key that the node provided at the beginning that is locked with a key only given to the Lawyer (or other trusted third party), to a postal address contained in this message. This can be protected by using a self-destructing message as the payload, which will also verify that the node has been compromised.

Obviously, the Administrator is very privileged. But they are also the best paid, and ultimately could make off with everyone's money. But to defend against that, the share pool and the insurance pool are both multi-signed, and require 2 of 3 keys to spend the coins. Ostensibly this would then be the Administrator, the IT manager, and one other node that both agree are trustworthy. There could be a collusion but in the event of trouble, this third person can send a cancel transaction that nullifies these colluding trusted parties. And likely this person would know these two central figures personally, and can easily serve as a trusted notification party for the rest of the network, that collusion is going on, and it may well be that everyone can kiss their share goodbye.

Obviously it is very much indicated that administrators and tech admins be honest and trustworthy. The position attracts a greater share of the redistributed parts of payments, but if the rest of the network isn't happy, if they ask for a withdrawal of their stake in the share pool, and it is tardily, or not performed, very quickly the whole network could go dark and if 1 of the 3 keyholders of the three pools is amongst the mutinous, they can nullify the transactions, and go vigilante on them, just run a little node app (This could be part of the protocol) that watches for attempts to again spend these pools, and keep sending the cancel. At which point, the would be trust-bandits have to come back to the table and negotiate. Or just do the right thing, and dissolve the trust. So there should be a URL that each of the privileged members can access, with their own password, that once it is invoked, will continue to veto any attempts to spend any of these shared pools.

It is not perfectly ideal, but it is a design that can be implemented relatively easily with a little code and some systems deployment skills.

This is the insurance system for members

The member has both their total stake in the Shared Pool, as well as the group's insurance pool. The insurance pool is contributed on an equal basis, per person, as a proportion of what they get paid. When one member goes down, this pool of funds is drawn on to fund their assistance, and of course, having claimed, it will double their premium until such time as they have fully paid back what they took out. And the administrator also may, at the request of the downed Node, for a full withdrawal of their stake in the shared pool, to assist their defence. The insurance pool is a mandatory redistribution taken from the payments going to all nodes, because the stake of voluntarily held shares in the operation are variable in size, and may not be sufficient to get the poor bugger out of trouble. They can also instead ask for their stake to be drawn out and forwarded to the trusted third party to fund their defence.

And at this point, the network is notified there is a man down, and at this point, any other member may, with more than normal expeditiousness, have their share taken out and sent to a requested address, and at the same time, the killwipe command will be sent via bitmessage to their node, so that the next time that it is online, it is gone. Assuming the member does not do this of their own accord.

Most members of this type of network will not know, and will not be told, that the administrator can at any time make the member's media become erased. Sure, perhaps the attackers will try to wheedle the password out of the user, but, after having had the insurance pool disbursed to their aid, via the trusted third party, if so much as a peep appears from this user's private key, into any of the group's other addresses, the broadcast addresses, the heartbeat broadcast, or the administrator's address, without the authentication token, then it can be known that the fallen node has given up their password, and is now an enemy of the network, and an emergency migration protocol will be then invoked, which rolls a new secret for every node in the network, new broadcast and heartbeat addresses are propagated to the admin node, who then replies by providing their own new admin address to each member individually.

At this point then, discussions will be taking place as to what to do, presumably, it will be decided to disburse the share pool, and the remaining insurance pool according to stake, and the network will be disbanded.

I apologise for not putting this together in the most optimally logical order, but I will refine the concept further, get it nice and clear and logical, so that someone can put together a package of scripts that produces every element of the system, and through careful procedural analysis, can determine any glaring logic errors in the protocol, as well as precisely specify the mechanisms required to implement it.