Thursday, November 15, 2018

Converting the Lightning Network into an electricity market protocol

(For sake of expediency, the following will be rather dense and presumes some background in both electricity markets and the Lightning Network. If I find time, I might post a more accessible description.)

Although technically blockchain-agnostic, the “Lightning Network” is a layer-two protocol originally conceived for the purpose of scaling bitcoin transaction throughput. It works by moving the majority of bitcoin transactions off-chain, while using the underlying blockchain primarily as a settlement and dispute resolution mechanism for the off-chain transactions. In the lightning network, pairs of individuals are connected by “payment channels”, and payments may then be routed from payer to payee even when they do not directly share a payment channel, by making use of the network of payment channels. The lightning network thus includes a routing protocol for discovering these routes, and intermediaries who choose to make their channels available to this protocol may extract a transaction fee along the way. The mechanism by which transaction fees are extracted is that the funds which leave a channel may be less than the funds which enter the channel. Importantly, the lightning network can exist across multiple blockchains, and can even facilitate off-chain swaps of one cryptocurrency for another, as for example has been demonstrated by swapping bitcoin for litecoin over the lightning network.

The topology of payment channels is usefully analogous to the physical topology of electricity grids, and the lightning network is therefore a perfect starting point for creating an automated and highly scalable protocol for the electricity markets. Payment channels can represent transmission lines. Transaction initiator can represent electricity consumer. Transaction recipient can represent electricity generator. Token sent by initiator can either represent, or constitute, payment. Token returned in the “currency swap” by recipient could represent either a promise to deliver an amount of electricity (in which case it may be subject to securities law), or else could represent a receipt for electricity delivered (perhaps thereby not being subject to securities law?) Intermediate payment channel endpoints could represent transmission line owners. Fees extracted in form of token A could represent rents for use of transmission lines. Fees extracted in form of token B could represent transmission energy losses. Payment channel capacity can represent transmission line capacity. Rate of token generation by generators could present rate of electricity generation. Underlying protocol could be modified to permit negative payment channel prices (as I have previously urged on the mailing list) so that transmission line owners can thereby incentivize counterflows, in scenarios where counterflow would lower net flow so as to increase sellable unidirectional capacities in an economically efficient manner. As described here, function would be analogous to spot market of an ISO in the US, although extensions could permit parallel operation of RTO-like futures markets for purpose of capacity planning. In the context of US electricity markets, this protocol could soften or eliminate today’s wholesale vs. retail market dichotomy, in alignment with the “deregulation” started in 1996 by FERC order 888, but extending all the way down to end consumer. This can incentivize rooftop solar in proportion to local market need, and could address for example the “duck curve” and negative wholesale prices experienced in CAISO markets during the summer by incentivizing electric vehicle owners to charge their cars accordingly. A competitive industry of computer-based electricity purchase appliances could arise which offer end users and producers a range of pricing models that vary in their simplicity versus fidelity, thus allowing the free market to identify an optimum mix of static versus dynamic pricing policies. In less developed markets, this protocol could facilitate the organic emergence of power grids among previously isolated producers and users of electricity, incentivizing for example the creation of transmission lines, generation, and storage in proportion to actual local need.

Monday, October 29, 2018

1769 Cugnot Steamer vs blockchain

Today's "blockchain" (acornics) technology:

Some blockchains today look like a larger version of this 1769 Cugnot Steamer, but have steam just for show while hiding ponies inside. When you ask their creators why they use ponies, they correctly point out that they burn less wood this way. When you ask why they then bother with steam, they say it is all the rage.

Ponies are cute, but I prefer EVs. Let's start making some of those.

Friday, August 17, 2018

Where legacy meets cryptocurrency, there is danger

As presently formulated, ICE's Bitcoin futures market sounds like a bad idea. They are not even creating a separate clearing house. This sort of sloppy risk management is how cryptocurrency could take out the legacy financial system.

Traders, I get that you want to play in cryptocurrency. That's great, and you are welcome, but please do so responsibly. How do you handle forks? What if some cryptography breaks? You should have solid answers before standing up new markets, and I'd have to assume that good answers would involve specialized clearing houses.

Sure, maybe one day Bitcoin will be the global reserve currency. Or, maybe it will suddenly drop to $0, due to a surprise cryptanalytic result. That surprise cryptanalytic result could come tomorrow, for all anyone knows. If that happens we will need our large institutions to survive, so make sure you can. CFTC, please make sure they can, ICE has a conflict of interest without your oversight.

Core devs, be mindful of what ICE is doing, and try to code accordingly.


Friday, August 10, 2018

IoT and traffic analysis

People always seem to forget about traffic analysis, and yet traffic analysis was a big deal in monitoring encrypted traffic even back during WWII.

Some countermeasures are very easy. For example, a device could be programmed to exchange a fixed amount of data on a predefined schedule. It can the batch whatever it cares about into those communications, and use random filler for the leftover space. Easy, yet seldom done...

Friday, July 20, 2018

RFC 2119 harmful in acornics protocol design

I see RFC 2119 terms like MUST, SHOULD, and MAY used in acornics protocol specifications, such as the BOLTS defining the lightning network protocol. This scares me.

A basic premise of acornics is that node behavior must always be only as the operator most desires. The terms in RFC 2119 presume an external source of authority which simply does not exist. What MAY a node do? Whatever it damn well pleases!

The terms of RFC 2119 may indeed prove useful long term. But at the very least, their definition requires much elaboration. In particular, the onus to prove correct usage of a term must rest entirely with the author, in that every term beyond a MAY must find explicit reference to the reason one should want to adhere.

Thursday, July 19, 2018

Acornics - the common parent of blockchains, smart contracting, cryptocurrency, et al

Bitcoin is the first example of a new class of technology that is so fundamental, that it has yet to be properly named. Blockchain, smart contracting, and cryptocurrency refer only to some of the subdisciplines - so what shall we call their common parent?

I propose "Acornics", a pronounceable yet shortened reference to Automated Coalition-Resistant Nash Equilibrium-ics, and where the "ics" suffix refers to a body of knowledge or practice. The concept of a Coalition-Proof Nash Equilibrium is borrowed from game theory, but we dial back the hubris implied by "proof" and thus substitute "resistant", since the stakes might one day merit such intellectual honesty. We add "Automated" to stipulate execution as computer code, since the rules of any society have long been built on a manually-enforced CRNE.

Acornics is a new way of thinking about the relationship between society and computer code. Rather than computer code being a tool of society, it instead becomes a programmable and explicitly engineered part of that society.

What blockchains do (and don't) do

Few introductions to blockchains manage to clearly state what blockchains do. This is odd, because they do only one thing.

Blockchains allow a group of entities (individuals or organizations) to accumulate an ordered list of shared records over time, whose tamper resistance they can trust - even if they do not trust each other.

That is it. That is the only new thing which blockchains accomplish. It turns out however that given the right context, this one little thing happens to be a big deal.

Converting the Lightning Network into an electricity market protocol

(For sake of expediency, the following will be rather dense and presumes some background in both electricity markets and the Lightning Netwo...