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.

Wednesday, January 24, 2018

NP problem-based signatures - scaling signable data

For fun, I proposed a crossword puzzle-based signature scheme. It suffers a rather serious limitation. I expect one can securely sign a single bit of data in a one-time fashion with it, but security falls apart as you go above a few bits. Even a single bit likely requires two puzzles, one solved to indicate a 1 and the other solved to indicate a 0 (as partial solutions to the whole key degrade the key massively).

The attraction of NP complete problems is the idea that the difference in complexity of signing, versus complexity of forging, can be made arbitrarily large, and that we have very high assurance this is true. That by itself does not guarantee the system is practically secure with today's technology, nor does it (by itself) say what signing complexity must be chosen for the complexity of attack to exceed some target threshold, but it seems like a good first step. Any such problem can be used to sign one bit, but can any such problem be scaled to much more than that? For any given number of bits x, one can make a composite key out of 2x smaller keys, so if we fix X in advance (at any value!) the answer is yes. But again, simply being NP complete does not guarantee security in practical applications on today's hardware. It seems improbable that crosswords would be a good way to secure terabytes under this scheme.

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...