Satoshi Roundtable V Recap

It was my pleasure to once again attend the Satoshi Roundtable organized by Bruce Fenton; I enjoy this event each year because it’s a relaxed atmosphere without massive herds of people and it offers lots of opportunities to have frank face-to-face discussions with people in the industry who are generally too busy to chat. The Roundtable is rather unstructured and as such there are innumerable informal conversations that occur — even the more formally scheduled meetings number in the dozens. As such, it’s not possible for anyone to give a full summary of what happened this year — I attended the conversations that I thought would be most interesting to me, and will attempt to convey the outcome of those discussions to you.

Lightning Network

Lightning is fascinating because it’s enabling completely new use cases that aren’t possible with traditional payment networks. We’ve seen proof of concepts such as Satoshi’s Place, Lightning Spin, and the Bitcoin Graveyard. There are still plenty of unexplored opportunities when it comes to leveraging Lightning to improve user experience. For example, the process for selling BTC at an ATM is pretty terrible — you have to make the deposit, leave while you wait for confirmations, and return to actually get the cash payout. With Lightning deposits the deposit and cash payout could happen instantly. The recent #LNTrustchain has been a fun demonstration on Twitter!

Some participants expressed skepticism that Lightning will be easy enough for the average person to use it safely and easily any time soon. They noted that while it’s not too difficult to onboard current bitcoin users to Lightning, explaining Bitcoin and Lightning to someone at the same time can be overwhelming. There seems to be general agreement that if Lightning is to gain mainstream adoption, the concept of channels will need to be abstracted away from the user. Rather, the user should only need to know what the max value is that they can send and receive. Due to the limited tooling currently available, this is difficult to manage, but improvements that are coming down the pipeline such as atomic multipath payments, channel splicing, multiparty channels, and streaming payments should make it easier for software developers to improve channel management under the hood.

Another major challenge with user onboarding is finding sources of liquidity. Shout-out to Bitrefill for their Thor service that makes it easy to buy inbound liquidity, though I believe that the optimal user experience should not require users to even think about it. I do expect that as more exchanges and liquidity providers jump onto the Lightning Network, we’ll see integrations into Lightning wallets that make it simple to “top up” your Lightning wallet with an experience that is similar to buying a prepaid debit card for complete crypto newbies and even smoother for those who already have exchange accounts.

While awesome open source software like BTCPay enables merchants to manage their own nodes and channels, it’s still quite likely that many merchants will opt for custodial payment processing services such as Strike. On the flip side, even if Lightning Network gets adopted by custodial companies faster than individuals there are plenty of efficiency gains to be had. At time of writing there are quite a few services that have many users and these users are sending value with on-chain transactions between the various services on a regular basis, which is quite inefficient from a block space usage standpoint. If these services only “settled” balances with each other on a daily / weekly basis then they could greatly reduce the amount of on-chain transactions required. However, it’s not possible to do so currently because service A doesn’t know what bitcoin addresses belong to service B. If these custodial services use Lightning instead, it will automatically take care of removing redundant on-chain payments between the services without them needing to know each others’ identities.

While I was building infrastructure at BitGo I saw visualizations similar to the following on a regular basis, with thousands and thousands of transactions going back and forth between our own customers who had no idea how inefficiently they were using this global ledger. It was frustrating to see, but our brainstorming fell short at ways to enable our own users to settle with each other in a way that didn’t destroy their privacy. This is one of the many reasons why I’m so eager to see Lightning Network adopted — it seamlessly solves this massive inefficiency.

Some of the biggest known unknowns at this point involve liquidity. Nobody really knows what kind of ROI will be reasonable for liquidity providers to expect, though there are some early efforts at trying to quantify a “Lightning Reference Rate.” Ultimately the time value of capital allocated to Lightning channels will be compared to other interest bearing assets, though to be fair there aren’t many highly similar crypto assets that can bear interest natively other than perhaps Maker DAO.

There was some concern expressed around the sustainability of Bitcoin’s thermodynamic security if transaction fees move mainly to the Lightning Network. It seems to me that if Lightning Network allows a user to reduce their on-chain transactions by a factor of X, then it makes economic sense for a user to be willing to pay any fee that is less than AVERAGE_BITCOIN_FEE * X — AVERAGE_LIGHTNING_FEE * X. Since Lightning enables completely new use cases that are not possible on-chain, I expect it will bring more economic activity (and mining fees) to bitcoin as users open and close channels. An interesting result of Lightning’s reliance on on-chain transactions is that a wildly popular Lightning Network could create more demand for on-chain transactions than it offloads, drastically increasing the on-chain fees that users are willing to pay. We will eventually see the adoption of new technology that allows users to use block space more efficiently with aggregated signatures and with multiparty Lightning channels; if many users are “sharing” a single on-chain transaction then it’s easy to see how the mining fee could be relatively high for the transaction, but relatively low from the perspective of each participant.

Finally, there was some discussion of a use case I hadn’t heard of before — Lightning payouts for Bitcoin miners. If hashers could get paid directly via Lightning then it changes mining dynamics in several ways:

• Payouts would no longer have to go into a custodial pool wallet
• Automated payouts wouldn’t fill the blockchain with dust UTXOs
• Hashers could be paid in realtime as shares are submitted without needing to wait for blocks to be found (there are probably other game theory implications behind this that would require slightly lower payouts for insurance purposes)
• By combining LN payouts with Matt Corallo’s BetterHash mining protocol, it would further reduce the power of mining pools and improve Bitcoin’s censorship resistance.

Lightning Network was a hot topic this year — it’s exciting because so much progress was made in 2018, but there’s still a ton of missing functionality and infrastructure that need to be built before we can realize its full potential. Shameless plug — if you’ve been delaying getting involved in Lightning Network due to its complexities, consider buying a plug and play Casa Node!

Privacy

This is a tricky subject for folks who are building companies, because our companies are subject to intervention by state actors. Those of us in this discussion were interested to learn how to enable user privacy without becoming a target ourselves. Some people in the group noted that they used to run services with lots of users, but after receiving plenty of letters from government agencies they decided that they didn’t want to deal with the hassle and shut down the service instead of rolling over. We discuss privacy at lot at Casa because we are a heavy service-driven company, so we need to maintain relationships with users. The safest approach we can determine is to store as little data about the user as possible — we must assume that at some point we may be coerced into handing over all of the data we have stored regarding a user. As such, “can’t be evil” is a stronger stance to take than “don’t be evil” because it’s not merely about our own intentions.

One of the biggest problems resulting from poor privacy on cryptocurrency networks is that is harms fungibility. There are several surveillance companies now that track funds and apply “taint analysis” to them to tell services how likely it is that funds are from an “illegitimate” source. Of course, these are generally probabilistic educated guesses and can result in innocent users getting caught up in an algorithm’s dragnet. These tools have clearly resulted in many Bitcoin users being deplatformed from various services because they were deemed to be risky customers.

One particularly interesting point that was brought up was that no one has been prosecuted as a result of blockchain analysis because it’s insufficient evidence on its own for criminal charges. Rather, it’s but one of many tools used by investigators to get a bigger picture of just how much money their target actually has so that they can be more confident that a seizure action is more successful.

Depending upon how many hops back in a UTXO’s history you look, you can probably find a good reason to consider it “tainted” — much like how the majority of physical fiat bills have trace amounts of cocaine. Perhaps the real problem is that bitcoin UTXOs aren’t tained enough — if more people mixed their UTXOs, eventually taint analysis would yield the same score for all UTXOs and we’d be back at a level playing field of fungibility. But until that point in time there’s a first mover disadvantage where privacy-conscious users who do mix their coins are likely to get flagged as suspicious.

Another downside to poor privacy against blockchain analysis is that it opens up bitcoin businesses to corporate espionage. Many exchanges and services with customers who make recurring deposits still have not adopted the best practice of not reusing addresses, making cluster analysis of their funds even easier than it needs to be! Also, it’s possible for tech savvy folks to make tiny deposits into addresses owned by a competitor’s service and then watch the UTXOs move in order to try to gauge the value and volume of their hot and cold wallets.

It was noted that there are widespread issues regarding correlation of IP addresses with Bitcoin addresses via SPV wallet flaws, sybil Electrum servers, and network observers. The solution to most of these issues is to run a full node so that all of your wallet queries occur locally and can’t be surveilled, but on the flip side if you’re broadcasting transactions from your full node it creates a privacy leak for network observers that watch transactions propagate through the network. Thankfully Dandelion should be coming to Bitcoin Core before long, thus obscuring the node from which a broadcast transaction has originated.

Bitcoin privacy is a whole research field in and of itself; for those of you who wish to dive into it I recommend checking out the Open Bitcoin Privacy Project’s threat model.

Sidechains & Scaling

This was one of the few recurring discussions that also happened at last year’s Roundtable. Paul Sztorc has been working on his Drivechain concept for several years with the goal of decreasing the contentiousness we see from proposed protocol changes that require hard or soft forks.

One of the tricky things about distributed consensus systems is that they tend to ignore everything that occurs outside of the system; this makes the system more robust against external threats but also makes it hard to change the system to add new features. As a result, people who want to experiment with exotic unproven ideas often end up building their own consensus system from scratch that ultimately ends up competing with Bitcoin in terms of attention and other resources. This ends up irking many Bitcoin supporters because the creators of competing projects become money issuers.

Drivechains would enable anyone to spin up their own network that leverages the power of Bitcoin miners and pegs the new asset to BTC — it’s basically a method for maintaining a sidechain that is pegged to Bitcoin by miners rather than by a federation of signers. Dynamic Membership Multiparty Signing (mining) is arguably more robust than a federation because signers can come and go and compete with each other. The optimal form of sidechain would be pegged without requiring any special involvement from miners, but as far as I know no one has worked out a practical way to do that — it would likely require the ability to challenge SPV proofs for the sidechain-to-bitcoin peg in order to prevent theft, which would be a significant change to the Bitcoin protocol.

One question that came up was whether or not Lightning Network should be considered a sidechain. The general agreement was that a sidechain is a system that has a globally shared state and a consensus mechanism while also having some sort of pegging mechanism to another system with its own separate globally shared state and consensus mechanism. As such, Lightning can’t be a sidechain even if you consider it to be pegged to bitcoin — the Lightning Network has no globally shared state that results from a consensus mechanism.

It was also noted that the security of a sidechain is a function of how popular it is since it is reliant upon coordination of a group (miners or a federation) to manage the peg. But there is reason for hope, as we’ve seen plenty examples of coordination occur amongst bitcoiners in response to problems such as the UASF movement, March 2013 fork resolution, and 2010 inflation incident.

The drivechain concept is still seen as questionable by some developers due to its miner-reliant security model; it relies upon user activated soft forks in order to counter theft via miner collusion. It seems that drivechains offer a middle ground in terms of security — not as secure as Bitcoin’s base layer, but far more secure than many systems that are reliant upon trusted third parties. However, drivechains are a permissionless innovation — they don’t require changes to the Bitcoin protocol to build. It just needs buy-in by miners to start adding the required transactions to blocks. Since the last Roundtable we gained the ability to run drivechains on testnet; I bet we’ll see a production drivechain deployed before Roundtable VI!

Secure Hardware

This is a particularly challenging problem for a variety of reasons. There was general agreement that it’s impossible to build hardware that is secure against an attacker who has unlimited time and resources. However, reasonably secure hardware should at least buy you more time to move your crypto assets to a new set of private keys before an attacker can extract the ones from a seized device.

One challenge to secure Bitcoin hardware is that there are no FIPS certified chips for the Bitcoin ECDSA curve — secp256k1. Satoshi’s choice of this curve is rather mysterious, as it was not popular at all 10 years ago. Unlike the popular NIST curves, secp256k1’s constants were selected in a predictable way, which significantly reduces the possibility that the curve’s creator inserted any sort of backdoor. The flip side is that this curve hasn’t seen the same level of resources put into building secure chips for it.

We discussed the vulnerability of most silicon chips to physical attack — by peeling off the top layer of a chip you can attach a probe to the silicon and read data directly off it. Secure elements, however, are designed with a top layer that completely destroys the chip if it is removed. They often also have self contained power supplies so that an attacker with physical access can’t simply put a probe on the power conduit to infer the data that’s being processed inside the chip.

One underappreciated aspect of secure elements is that they usually come with a certified random number generator — the generators that ship with most operating systems tend to be questionable. The downside to secure elements is that someone still has to write the software that runs on it — this can create trust issues and a single point of failure. Secure hardware that runs insecure software is not secure after all. Also, secure elements generally can’t perform complex operations because they have limited computation abilities — the actual construction of bitcoin transactions has to occur outside of secure elements and on a less secure microcontroller. Saleem Rashid covered some of the problems with this design in a post about the Ledger Nano S.

Ultimately, one of the biggest problems with secure hardware is that it’s still reliant upon best practices being followed — there is plenty of room for human error. Just as multisig is not a magic bullet for creating a perfectly secure wallet, neither is hardware — it’s one of many tools that we should use in concert to build robust solutions for users.

Mnemonic Seed Phrase Standards

This discussion went quite deep into the technical weeds but is highly relevant to wallet developers. The general issue is that Bitcoin wallet derivation suffers from the “standards” problem — we have BIP 32, BIP 39, BIP 44, BIP 49, BIP 84… and they aren’t all necessarily compatible with each other.

One particularly frustrating thing with hierarchical deterministic wallet derivation standards is that they don’t really mesh well with address format standards. Since BIP 32 does not specify the address format for a given derivation path, wallet developers have proposed altering the extended public key’s version bytes to achieve this. With the activation of SegWit on Bitcoin, the number of ways of encoding an address public key has increased. While BIP 49 proposes a method for encoding P2WPKH-nested-in-P2SH addresses, it fails to change the HD seed version bytes (retains xpub prefix), leading to unsustainable user confusion. Either the user must know that the xpub uses BIP 49 derivation, or the consumer of the xpub must scan both address spaces (P2PKH and P2WPKH-in-P2SH). This problem could continue to worsen over the long term, requiring more and more complex scanning logic for wallets that support importing seed phrases.

I actually ran into this issue last year and it led me to create this xpub version bytes converter tool. The problem gets compounded when you are building wallets that support non-Bitcoin crypto assets that have their keys all derived from a single master seed. At the moment the closest standard we have is Satoshi Labs Improvement Proposal 132, though during our discussion we wondered if it might make more sense to propose a HD standard that adds one more path to the derivation, changing it from:

m/BIP/CoinType/Account/change/index

to

m/BIP/CoinType/Account/AddressType/change/index

We also agreed that it would be extremely helpful if a standard was formed for securely splitting seed phrases. Keeping recovery seeds safe is an extremely complex physical security problem, so much so that at Casa we developed a wallet that completely gets rid of the need to manage seeds — if you lose a device, you can easily perform a key rotation within the Keymaster software and you never have to deal directly with private keys or seeds.

We suspect that many people who are splitting seeds are using some form of Shamir’s Secret Sharing, but this is problematic for several reasons. Firstly, various open source SSS tools that are available are not even compatible with each other… probably because it’s not easy to implement! In 2017 Greg Maxwell found a bug in Armory’s SSS implementation for fragmented backups. There was additional agreement that it would be a great improvement if there was a seed splitting scheme that also included checksums on each seed share so that you could verify its integrity without having to reconstitute all of the shares to see whether or not data was corrupted. It seems like this could be a pretty big win if someone were to put in the time to develop a proposal.

Security Tokens

I attended this discussion because I was willfully ignorant of security tokens. Security tokens are still in embryonic stage and their attributes are not well defined, though we did seem to settle upon a general definition that they are cryptographic tokens that are regulated by some government authority as a security. One stat that was mentioned was that while the ICO market declined ~90% in value during 2018, the value of the security token market surged 1,000%.

Why are security tokens interesting? We were told to view them from the perspective of the private placements market, which generally raises about 10X more funds than IPOs on an annual basis. Why tokenize securities?

• You can enforce their properties at a global consensus level via programmatic “smart contract” functionality. Think of things like dividends, shareholder voting, and lockup periods.
• Atomization becomes possible — the ability to make more granular investments without a lot of overhead.
• Regulator friendly due to using open, auditable ledgers.
• Potential to build a global interoperable stock market.
• Reduce counterparty risk with distributed exchanges & automated KYC.

Security tokens will certainly be more challenging to build than utility tokens.

• They must bridge traditional markets and get regulator approval.
• They can’t afford to start over from scratch and throw out existing functionality.
• Currently have to repeat AML/KYC/Accreditation on each token.
• Low liquidity on exchanges, standard 1 year lockups don’t help.
• What do you do if there is a fork on the underlying ledger platform?
• Blockchains don’t scale — this creates pressure to centralize around a few exchanges just like the traditional non-blockchain system.
• There aren’t currently any qualified custodians.
• Legal grey area around how custodians must handle forks / airdrops. If custodians have sole discretion, it’s an ERISA violation and the possibility of this happening prohibits institutional investment.
• It’s possible to be in compliance with regulations at token issuance but then fall out of compliance once cross-border trading ensues (such as exceeding the number of allowed investors in a given country.)

The speculation was that security token buyers will generally be the same folks who are buying traditional securities today and they probably won’t even realize that the underlying plumbing has changed to a different system. Observations from the field were that security token markets so far have been 90% purchases made with fiat, but during crypto market bull runs the dynamic changes to about 80% purchases with crypto as investors seek diversification.

I still don’t think they’re nearly as interesting as public permissionless crypto assets, but I must admit that security tokens can improve upon the traditional financial systems used to manage regulated equity ownership.

Grin

I’ve been interested in MimbleWimble since late 2016 — now there are multiple production MimbleWimble networks running and we get to see how well they perform in adversarial environments!

Aside: my interest in Grin is not investment advice. I don’t advise people to invest in BTC, much less in even more experimental altcoins.

One of the biggest questions was “why is there so much investor interest in grin?” to which there were several speculative answers:

• Investors seeking MimbleWimble exposure who didn’t get equity in BEAM may find grin more palatable.
• Given grin’s issuance schedule with near-term high inflation and long-term tail emission, the price will likely be low for a long time.
• Instead of buying grin now, it may make more sense to mine and sell it, then accumulate grin later.

Grin’s strengths:

• Ethos seems to be fairly close to that of Bitcoin and cypherpunks.
• Launched about as fairly as an altcoin can launch these days.
• Same scripting language as Bitcoin, but as “scriptless scripts” that are stealthily inserted into signatures.
• Grin’s blockchain scales relative to the number of users rather than transaction volume — about 100 bytes per user.
• You can voluntarily deanonymize your funds by giving out a view key.

Grin’s weaknesses:

• Grin’s economic model of perpetual emission of 1 grin per second for all eternity is a huge turn-off to many people. Over a long enough time frame, its inflation rate will be lower than the average fiat currency, but most people probably aren’t patient enough to wait decades for that to happen.
• Tragedy of the commons when it comes to funding devs via a donation model. Tons of money was poured into mining because the ROI is measurable, whereas money invested in development is not. Speculation was that perhaps funds will be less stingy after they have accrued some value via mining and will donate a portion of mined grin. Grinmint has chosen to donate a percentage of pool proceeds to the Grin developer team. Additionally, Obelisk has committed to donating a portion of their revenue from their Grin ASIC to supporting Grin development.
• Transaction signing is interactive, which creates complexity. Cold storage in particular will require additional steps, such as transferring partially signed transactions with QR codes to and from airgapped machines.
• One option for interactive signing is doing so via connecting to the counterparty’s IP address, which is of course a huge privacy issue.
• Interactive signing opens up possibility of man-in-the-middle attacks — a secure communications channel is a necessity.

We also talked about privacy coins in general and I learned that institutions are accepting of privacy coins because no traditional assets have anything similar to blockchain analysis tools; they rely upon standard AML/KYC processes. Blockchain analysis tools actually cause enterprises grief because many don’t understand that the law doesn’t require specific UTXOs to be earmarked, just the value of the funds in general. Thus “tainted” funds could get flagged downstream of where an enforcement action (seizure) already occurred.

I look forward to seeing the development of MimbleWimble tech progress, and perhaps some day we’ll see a MW sidechain for Bitcoin. I was pleased to hear that it sounds like there is an effort to figure out how to get MW working with Lightning; it sounds like it may be possible to implement Discreet Log Contracts and Adaptor Signatures in order to achieve the necessary functionality.

Bitcoin Price

Just kidding! There was very little price discussion. The most that did occur was during a keynote speech where S curves and adoption cycles were discussed. We did hear some neat insights regarding birth rates and resulting bubbles in various sectors as spikes or drops in birth rates create ripple effects as those populations age. For example, peak motorcycle buying age for men is in their mid-forties and Harley Davidson sales (and stock price) also peaked as the Baby Boomers were hitting middle age. As for Bitcoin, who knows… most everyone in attendance seemed to believe that we haven’t seen the last Bitcoin Bubble, but whether it happens in 1 year or 10 is up in the air.

Back to BUIDLing

As usual, this unconference was an educational and entertaining break from building out crypto ecosystem infrastructure. See you in 2020!