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 June 29, 2017 05:36 AM
Comments

SegWit does not remove signature data from transactions. SegWit creates a bigger block, and in the bigger block all transactions contain signatures. Transactions without signatures continue to be invalid and signatures continue to be committed in blocks.

SegWit allows partial validators who do not check signature validity to do so without downloading the signatures themselves. This does not make invalid transactions valid. It does not make invalid blocks valid. It does not make invalid signatures valid. It does not make transactions without signatures valid. It does not remove signatures from blocks, as all block content continues to be committed in the block header. SegWit simply lets you verify non-witness transaction data without downloading (then discarding) the witnesses, which solves the problem of light clients having to download things they donít care about.

Posted by: Myth #6: SegWit removes signature data from transactions. at August 6, 2017 04:47 AM
Post a comment









Remember personal info?






Hit preview to see your comment as it would be displayed.