Responding to Preston Pysh on drivechains

RE: https://nostr.band/note12yse7ke6t6wcx79h2rzmwzqj2mmqyze3evdg0k2aa0xkkx79jtassf063z

I appreciate feedback on the proposal, but there is a lot in this note that I think is just flat out not true. Given Preston’s large audience I felt compelled to set the record straight. There’s also more speculative or opinionated statements I disagree with and provide an alternative perspective on. Quotes are from Preston’s note unless stated otherwise.

We don’t need the sound, pegged, money to move fast, we don’t need the money to do smart swoopty things, we just need it to be pegged, immutable, and digitally sailable to actually stop the madness of clown world.

I disagree that this is all we need. Gold is basically a slow rock that just sits there and look what’s happened to its revolutionary potential. Completely neutered. Digitization alone wouldn’t change this. Bitcoin needs to be more than “digital gold” if we do not want it to meet the same fate.

People spend money, no one is going to wait 10 minutes for a block confirmation at the store, so we need fast and secure payments. It took a change to bitcoin called segwit to enable the Lightning Network of today, which is at least a step toward solving that problem.

And storing money in a SPOF address that can be robbed immediately once compromised is just not secure, so we need at least enough programmability to do “smart swoopty things” like decentralize custody and give ourselves a chance to recover if we notice a critical compromise. This implies the op codes needed for multisig and timelocks, ~ all modern multisig uses P2SH or segwit which were soft forks, and modern timelocks were made possible by the CLTV soft fork.

Additional programmability to move bitcoin finance out of custodial tradfi and into p2p markets is also, maybe not needed, but highly desirable, lest we commit the Cardinal Bitcoin Sin of giving up our coins to custodians for the simple goal of liquidity. At a minimum, this again implies multisig, or DLCs which require Schnorr signatures, both enabled by earlier soft forks.

This premature ossification mentality is a privileged position that ignores the years of hard work it’s taken to get the changes into bitcoin that make it what it is today. Would Preston have been so gung-ho ossification 5-10 years ago? If not, why not? Why now?

The premature ossification mentality also ignores the technical need for changes to bitcoin. At the very least, we will need a hard fork before bitcoin runs out of block numbers and completely stops working. Additional maintenance changes will also be needed, and though not all of those changes will be consensus changes, consider the case of the BerkeleyDB bug. This database code wasn’t technically part of the consensus code but the bug still caused a chain split. Bitcoin’s code is going to continue changing out of necessity to prevent issues like this, and general coderot issues.

That said, Drivechain might not be a silver bullet for all of bitcoin’s problems but does have a lot of potential to improve upon existing techniques for programmability, privacy, and scaling. At the very least Drivechain allows devs and users to experiment with potential solutions in a trust minimized environment without having to making any additional changes to bitcoin. This is arguably a change that gets bitcoin closer to a state approaching ossification, since any new features people come up with could be implemented in a drivechain, lessening pressure to implement them on the base layer. This should be something cheered on by those who advocate ossification.

By introducing a whole lot of technical complexity to the base layer

BIP-300 and BIP-301 are not really that technically complex. We’ve done other soft forks (like segwit) that were much more complex, comparatively speaking.

potentially screwing with the incentives

Potentially…? I would prefer a more definitive claim and (logical or demonstrative) proof of this to justify blocking a proposal. Otherwise anyone can go around bandying the phrase “potentially screwing with the incentives” at any proposal and hold it up.

all so we can connect to a bunch of centralized shitcoin projects

This is a supreme misunderstanding of the purpose and functionality of drivechains. Have you read the original pegged sidechains paper? That would be a good place to start. Here’s a relevant quote:

The core observation is that “Bitcoin” the blockchain is conceptually independent from “bitcoin” the asset: if we had technology to support the movement of assets between blockchains, new systems could be developed which users could adopt by simply reusing the existing bitcoin currency.

No “shitcoins” needed.

A. Why the rush!?

Look at the date on this blog post:

https://www.truthcoin.info/blog/drivechain/

It’s been 8 years, Preston. 8 years!

B. Why not just go use Monero

I’m a Bitcoiner. I prefer to store my value and transact in BTC.

C. Why risk the king without deep understanding and testing of the technical risk and potential change to incentives?

afaict the person lacking deep understanding and testing experience is Preston. The first drivechain testnet I’m aware of was launched 4-5 years ago, and the community has been running various test versions ever since. You can run it and review it yourself, the software is available here.

We’ve seen live “real money” tests of the same hashrate escrow incentive model on other chains with tens of thousands of BTC worth of value at stake and the results were positive overall, I would say: https://lightco.in/2022/06/15/miners-can-steal-2/

I for one, have no use for drivechains (that doesn’t mean everyone is like me). And as a result, I will not be updating my node

Sure, run whatever software you want. But just because you personally don’t have a use for drivechains doesn’t mean you need to block other people from using them. I’m sure there are lots of things people do with their BTC today that you have no use for. Would you block them too, if given the chance?