July 10, 2017

EOS - An Introduction

I've written a new paper:

EOS - An Introduction

Abstract: Current technologies for blockchain fall short of providing what developers and end-users need in order to contract together and to build large scale businesses. We propose EOS, a performance-based and self-governing blockchain that provides an operating system for building large-scale consumer-facing distributed applications. This paper outlines the context, vision and software architecture underlying EOS, which we are building to serve a broad and diverse group of users with smart business.

It's located on my papers page at iang.org/papers/EOS_An_Introduction.pdf and will also be on the eos.io site at EOS: An Introduction (eos.io copy). Now also in Russian: EOS ó Введение (Ян Григг) (часть 1) & (часть 2) by 🌐 Blockchained. Chinese is coming - don't tell anyone!

Not a lot I can say beyond what's in the paper, and also I'm at the EOS booth and it's taken me 4 hours to get this many words down.

Posted by iang at 06:08 AM | Comments (0)

June 29, 2017

SegWit and the dispersal of the transaction

Jimmy Nguyen criticises SegWit on the basis that it breaks the signature of a contract according to US law. This is a reasonable argument to make but it is also not a particularly relevant one. In practice, this only matters in the context of a particularly vicious and time-wasting case. You could argue that all of them are, and lawyers will argue on your dime that you have to get this right. But actually, for the most part, in court, lawyers donít like to argue things that they know they are going to lose. The contract is signed, itís just not signed in a particularly helpful fashion. For the most part, real courts and real judges know how to distinguish intent from technical signatures, so it would only be relevant where the law states that a particular contract must be signed in a particular way, and then weíve got other problems. Yes, I know, UCC and all that, but letís get back to the real world.

But there is another problem, and Nguyenís post has triggered my thinking on it. Letís examine this from the perspective of triple entry. When we (by this I mean to include Todd and Gary) were thinking of the problem, we isolated each transaction as being essentially one atomic element. Think of an entry in accounting terms. Or think of a record in database terms. However you think about it, itís a list of horizontal elements that are standalone.

When we sign it using a private key, we take the signature and append it to the entry. By this means, the entry becomes stronger - it carries its authorisation - but it still retains its standalone property.

So, with the triple entry design in that old paper, we donít actually cut anything out of the entry, we just make it stronger with an appended signature. You can think of it as is a strict superset of the old double entry and even the older single entry if you wanted to go that far. Which makes it compatible which is a nice property, we can extract double entry from triple entry and still use all the old software weíve built over the last 500 years.

And, standalone means that Alice can talk to Bob about her transactions, and Bob can talk to Carol about his transaction without sharing any irrelevant or private information.

Now, Satoshiís design for triple entry broke the atomicity of transactions for consensus purposes. But it is still possible to extract out the entries out of the UTXO, and they remain standalone because they carry their signature. This is especially important for say an SPV client, but itís also important for any external application.

Like this: Iím flying to Shanghai next week on Blockchain Airlines, and Iíve got to submit expenses. I hand the expenses department my Bitcoin entries, sans signatures, and the clerk looks at them and realises they are not signed. See where this is going? Because, compliance, etc, the expenses department must now be a full node. Not SPV. It must now hold the entire blockchain and go searching for that transaction to make sure itís in there - itís real, it was expended. Because, compliance, because audit, because tax, because thatís what they do - check things.

If Bitcoin is triple entry, this is making it a more expensive form of triple entry. We donít need those costs, bearing in mind that these costs are replicated across the world - every user, every transaction, every expenses report, every accountant. For the cost of including a signature, an EC signature at that, the extra bytes gain us a LOT of strength, flexibility and cost savings.

(You could argue that we have to provide external data in the form of the public key. So whoeverís got the public key could also keep the sigs. This is theoretically true but is starting to get messy and I donít want to analyse right now what that means for resource, privacy, efficiency.)

Some might argue that this causes more spread of Bitcoin, more fullnodes and more good - but thatís the broken window fallacy. We donít go around breaking things to cause the economy to boom. A broken window is always a dead loss to society, although we need to constantly remind the government to stop breaking things to fix them. Likewise, we do not improve things by loading up the accounting departments of the world with additional costs. Weíre trying to remove those costs, not load them up, honestly!

Then, but malleability! Yeah, thatís a nuisance. But the goal isnít to fix malleability. The goal is to make the transactions more certain. Segwit hasnít made transactions more certain if it has replaced one uncertainty with another uncertainty.

Today, Iím not going to compare one against the other - perhaps I donít know enough, and perhaps others can do it better. Perhaps it is relatively better if all things are considered, but itís not absolutely better, and for accounting, it looks worse.

Which does rather put the point on ones worldview. SegWit seems to retain the certainty but only as outlined above: when ones worldview is full nodes, Bitcoin is your hammer and your horizon. E.g., if youíre only thinking about validation, then signatures are only needed for validation. Nailed it.

But for everyone else? Everyone else, everyone outside the Bitcoin world is just as likely to simply decline as they are to add a full node capability. ďWe do not accept Bitcoin receipts, thanks very much.Ē

Or, if you insist on Bitcoin, you have to go over to this authority and get a signed attestation by them that the receipt data is indeed valid. Theyíve got a full node. Authenticity as a service. Some will think ďbusiness opportunity!Ē whereas others will think ďhuh? Wasnít avoiding a central authority the sort of thing we were trying to avoid?Ē

I donít know what the size of the market for interop is, although I do know quite a few people who obsess about it and write long unpublished papers (daily reminder - come on guys, publish the damn things!). Personally I would not make that tradeoff. Iím probably biased tho, in the same way that Bitcoiners are biased: I like the idea of triple entries, in the same way that Bitcoiners like UTXO. I like the idea that we can rely on data, in the same way that Bitcoiners like the idea that they can rely on a bunch of miners.

Now, one last caveat. I know that SegWit in all its forms is a political food fight. Or a war, depending your use of the language. Iím not into that - I keep away from it because to my mind war and food fights are a dead loss to society. I have no position one way or the other. The above is an accounting and contractual argument, albeit with political consequences. Iím interested to hear arguments that address the accounting issues here, and not at all interested in arguments based on ďomg youíre a bad person and youíre taking money from my portfolio.Ē

Iíve little hope of that, but I thought Iíd ask :-)

Posted by iang at 05:36 AM | Comments (0)