Building for the future, part 1
I am not a Bitcoin expert. This article is merely a summary of my expectations. An obvious point is why has ElectrumSV not done these things? Part of this is that no other applications would be interoperable unless there were common standards requiring these, and another reason is that there is so much else to do that we haven’t gotten around to it yet. We need to move beyond the limiting techniques of Bitcoin Core and adopt the forward looking techniques that will enable us to implement all the exciting things in our future.
So let’s look at the core building blocks that I believe should be used by all developers in their services and applications, and all new protocols that are intended to be forward looking should build in and require.
Expectation 1: I should be able to derive your keys
The current model involves one of two approaches:
- You pre-create a given number of keys and more than likely embed some form of them in output scripts you give to another party.
- You give someone an xpub from your wallet and the agency to give out keys or output scripts using those keys.
These are based around the notion that you can find all your transactions on the blockchain at any time, and in a real world blockchain with big blocks this is no longer practical. Seed-based restoration of your wallet will become expensive to do, and any application with wallet functionality will be compelled to explicitly store backup data and have worst case scenario handling to recover when those explicit backups fail.
With your identity key I can use it along with a shared secret to derive public keys from it. This can be done using techniques described in nChain’s whitepaper 42. You also provide transaction templates that you prefer to be used, which might be multi-signature created from several identities, or single signature created from the one. I should be able to generate a payment (or any other kind of transaction exchange) including all output scripts and key usage from those identity keys and transaction templates.
The benefits are obvious. You know what shared secret was used to pay you and can analyse transactions you receive and verify that they are structured as you require and pay you as you should be paid. A whole step of back and forth can be abandoned and someone constructing a transaction for you can do so without you being a bottleneck. If they want you to accept that transaction they need to make sure it meets your needs, it is not a thing that just because they pay you, you have to accept the payment. A poor application that makes unsolicited payments in an unacceptable form costs it’s owner, and does not cost you as the intended recipient.
We should stop using BIP32 for any keys we give out to other parties. Seed-based restoration is going to stop working past a certain height, and we need to be ready for it.
Related reading material:
- Whitepaper 42. This details different ways to derive keys using shared secrets.
- Secret value distribution Youtube video where Craig discusses the topic.
Expectation 2: Multi-transaction payments should be the rule
If you are making all your payments as one transaction you are doing it wrong. You should be splitting the coins you add as transaction inputs over as many transactions as it takes, to ensure that unrelated coins are never grouped together. And you should know which coins are related, and manage the coins in such a way that you have sufficient unrelated coins available for use as needed.
Related reading material: