Ben's Blog on Cryptography and Composition
Monday, April 1, 2019
Blockchain animation
Tuesday, January 29, 2019
Automating the detection and patching of vulnerabilities
Nice.
https://spectrum.ieee.org/computing/software/mayhem-the-machine-that-finds-software-vulnerabilities-then-patches-them
Thursday, November 15, 2018
Converting the Lightning Network into an electricity market protocol
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:
https://youtu.be/KP_oQHYmdRs
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 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.
https://www.theregister.co.uk/2018/08/10/internet_of_things_encryption_snooping/
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.
Blockchain animation
Blockchain technology offers society a new capability: sharing business records whose tamper resistance can be trusted more, and for a lo...
-
In 1976, Nobel laureate Friedrich Hayek proposed that money should be denationalized, such that privately issued moneys would compete over t...
-
The recent Ethereum hack involving a smart contract bug illustrates a type of vulnerability that we'll be seeing a lot more often. One...
-
The petro is a clever idea, although I'm not sure the, uh, tension between Venezuela's executive and legislative branches makes a c...