Bitcoin Optech
Date: October 9, 2018
Transcript By: Bryan Bishop
https://twitter.com/kanzure/status/1049527415767101440
Bitcoin Optech is trying to encourage bitcoin businesses to adopt better scaling techniques and technologies, things like batching, segwit, down the line maybe Schnorr signatures, aggregatable signatures, maybe lightning. Right now we’re focusing on things that businesses could be doing right now. Exchanges could be batching, and some aren’t. We’re talking to those companies and listening to their concerns and what they’re doing, and just trying to nudge them in the right direction.
We also produce content. We produce a weekly newsletter largely thank to David Harding. We’ve gotten really positive response to that newsletter. It’s hard for bitcoin engineers to keep track of everything going on in Bitcoin Core and protocol development and the mailing list and github.
We’re also doing workshops. We did one in July in San Francisco. We’re doing another one in Paris next month. We’re also producing documentation around better scaling technologies. We’re calling it a scaling cookbook, and it summarizes things like replace-by-fee, child-pays-for-parent, and best approaches for using scaling approaches. So what we want to talk with you about is whether you’re interested in helping, and is there anything we can do to feedback the knowledge from industry engineers to the people in this room?
To take it back a step as to why optech is a good idea… I think we all know that bitcoin businesses aren’t the only constinuency for which we’re building Bitcoin Core and maybe not the most important one. But they are a big constituency. A lot of people using bitcoin and benefiting from bitcoin do it through these businesses, and if these businesses can use bitcoin better then that’s better for the users. We saw a year ago or two years ago that there was a big disconnect between the open-source development community and the industry about what development was and where it was going… there was no feedback loop from them to us or vice versa at all. To me, this is a great way to improve that communication. But it should go both ways. The feedback should go back the other way as well. Ideally, in the future, maybe there are more people that work for a company and contribute to open-source software but I think there’s other ways that could happen to.
Our first workshop was in San Francisco back in July 2018. We had engineers from six bitcoin companies in the Bay Area come and talk about coin selection, fee estimation, replace-by-fee, child-pays-for-parent, etc. Andrew Chow came and spoke about those things as well. We got idea exchange between those companies and we got an understanding of how people are using bitcoin in the field. If any of you are interested in attending future workshops or being on our online forum or talking with engineers at companies and finding out what we’ve been doing, then let us know.
Replace-by-fee is hard to use. People like child-pays-for-parent.
How do people use Bitcoin Core software? Do companies use the wallet? No. We met with two dozen bitcoin companies, all but one use Bitcoin Core, but they all use it for validation but not for anything else. Purse uses something else for their validation. Some exchanges in Asia use the actual Bitcoin Core wallet. Their wallets have grown very large, very slow, and they are suffering. They are deathly afraid to leave that wallet. Another pattern we’ve seen across all businesses is that they will use open-source software but they have to choose it based on their internal infrastructure and language of choice at the company, and that varies like java, scala, golang, ruby, python. I think another thing we’ll see in the exchange space is hardware security modules, hardware wallets, things like that. The wallet changes discussed today could be put to work there. Yes, they use RPC. They use Bitcoin Core for validation, then they search through it again. They build their own transaction indexes and their own transactions. They would love to use some high-quality open-source version, the problem is that there’s different languages and infrastructure and nobody wants to write bindings.
So why haven’t they implemented segwit yet? Some of them want to, but they use bitcoinj, and it doesn’t implement segwit. So do they wait or do it themselves. Also, some of them want to treat bitcoin and litecoin the same. The library bitcoins can represent the differences between addresses across coins, which include different network bytes. Most of these companies support multiple coins, and they have internal abstraction layers which is generally good software engineering practice but it’s hard to abstract ethereum’s model and a utxo model. It sets them up to introduce errors where they don’t handle reorgs right.
I have experienced quite often, that even if an exchange wants to use Bitcoin Core for quality reasons, they struggle because they want something like addresses indexes usually for bad reasons but nobody can stop them from wanting to use them for bad things. As a result, they end up using bad abandonware.
David Harding has a wiki page with a list of optimizations available to scale bitcoin- why haven’t these been adopted? Transaction batching, segwit, utxo consolidation are generally well-understood by the engineers and they have either done them or they want to do them but it’s not been a priority yet. Replace-by-fee, there’s much more mystery about how to go about it and what’s the right way or best way. There’s also user interface or UX concerns. For example, if a big company was to implement it, and if you were to transfer a coin to another wallet, and bump the fee, and you look at the block explorer that hasn’t upgraded the UX for replace-by-fee you might think the coin is lost. It’s also non-trivial to do that because you could do a redirect to the new transaction, but is it really the same transaction? If only a few inputs are the same, is it the same transaction? It’s non-trivial. RBF and CPFP is an area where optech can help. John started a document on replace-by-fee best practices.
Another thing coming down the pipeline is the Schnorr signature stuff. Bitcoin Core libsecp256k1 has java bindings but there needs to be newer versions of those bindings into Bitcoin Core’s libsecp256k1. We need to offer easy ways for popular programming languages to use those features. I think Jonas is working on Schnorr sig module right now so we should think about getting that done too so that it actually gets adopted by exchanges or whatever, otherwise they don’t have incentive to adopt this.
One of the things that went wrong before was that people were told a message on behalf of Bitcoin Core or open-source developers that other people didn’t agree with. We definitely don’t want that to happen again. I think these guys are making a concerted effort to not speak on behalf of Bitcoin Core, and be very public. So we should pay attention and speak up if we disagree. We’re trying to improve the understanding of Bitcoin Core and how developers think about it.
There’s no way of gtetting a feature request from a user in a format about yes here’s a user that wants a feature. For the exchanges over there in the room, they have like a n+1 query, like Ruby on Rails, where you ask Bitcoin Core one thing, you get a reuslt, then you ask it for n things. In the first query, you have all the n things it could be, then you end up querying the RPC and it ends up being a bottleneck. There’s no way to get that report about this extension would be helpful in a standardized way. That might be a helpful thing. Getting bug reports like this and feedback is important. It’s the formality of it. I’ve had people ask for thes ethings, and then people ask well who has asked for this. Why isn’t there an issue on github discussing that feature request? If it’s not on github, then you’re not going to get your feature. If you get people to comment on it then you’re vote brigading on it which might be a little bit wrong.
If there’s a 50 block reorg, what is the response from Coinbase going to be? Maybe they wont advertise it but they should have a plan. Maybe have another testnet, specifically for companies, and we can simulate things that we want people to think about a little bit more. If they are using that testnet then they experience those larger reorgs so that their systems will pick it up and deal with it. Not make testnet do that, but make another testnet. If you can survive this testnet then your system is good.
For companies that are making reports to regulators about how bitcoin works, we would like to make ourselves available for peer review on behalf of regulators or the companies.
From the perspective of exchanges, they have plans for coin systems failing, especially for exchanges that list every coin under the sun. They probably would apply whatever strategy they have for some small altcoin, for bitcoin. But most altcoins have a phone number for someone to call… but really not bitcoin.