pull down to refresh

Paul Sztorc is an independent Bitcoin researcher. In this interview, we discuss drivechains, his 2015 proposal that’s the focus of BiP 300 and 301. Drivechains facilitate sidechains on Bitcoin, providing a bridge to new coins. The aim is to enable developer creativity atop Bitcoin.
reply
In October 2014 Adam Back and other prominent Bitcoin developers introduced the concept of sidechains to Bitcoin’s infrastructure. In the paper, they stated “We propose a new technology, pegged sidechains, which enables bitcoins and other ledger assets to be transferred between multiple blockchains. This gives users access to new and innovative cryptocurrency systems using the assets they already own.”
Paul Sztorc then developed a proposal for a version of sidechains in 2015 that were linked to Bitcoin’s mainchain. This proposal would improve on the original sidechain idea in several ways: it did not require independent miners for the sidechains, and further, it did not require a hard-fork of Bitcoin.
A principle driver was to enable developers to create innovations within Bitcoin, outside of the need to develop separate token ecosystems. Various features, including a 1:1 peg, and a delayed redemption period, were designed to mitigate the incentive to create new alternative tokens for purely selfish financial reasons, whilst facilitating an ecosystem for innovation.
In short, it was designed to remove the marketplace for altcoins altogether, allowing Bitcoin to foster experimentation. And yet, whilst being the basis for two Bitcoin Improvement Proposals, drivechains are still yet to be adopted by the community. This is perhaps not a surprise given Bitcoin’s focus on dependability and reasonable concerns about impinging on Bitcoin’s robust security.
But, are these concerns valid?
Of course, the idea that we could retain a fixed monetary supply on a secure base layer, and at the same time have the freedom to experiment with new privacy technologies and programmability seems like the best of both worlds. The question remains why this strategy has not yet been broadly supported and adopted by the network. The “work slowly and build things” philosophy in Bitcoin is a core pillar of the Bitcoin value proposition as a reliable monetary protocol. But can drivechains be a way of enabling Bitcoin to become the gravitational centre for developers? Or, do Drivechains pose an existential choice between security and progress?
TIMESTAMPS:
00:00:00 Introduction 00:02:44 Drivechain comparison to Liquid 00:10:49 Drivechain thesis 00:23:53 Drivechain in practice 00:44:17 Will Drivechain filter out shitcoins? 00:48:04 Valid criticisms of Drivechain 00:59:35 Drivechain facilitating developer creativity atop Bitcoin 01:08:00 Pushback versus support 01:18:14 Background
WHERE TO FIND THE SHOW:
→ My website: https://www.whatbitcoindid.com/podcast/ → iTunes: https://apple.co/2OOlzVV → Spotify: https://spoti.fi/2ygc4W1 → Stitcher: https://bit.ly/2IQO8fX → SoundCloud: https://bit.ly/2CGSVQR → YouTube: https://bit.ly/3nyi9Ez → TuneIn: https://bit.ly/2ywystr
On BitcoinTV (Peertube / Fediverse):
Should Drivechains Come to Bitcoin? With Paul Sztorc
On Mastodon / Pleroma (Fediverse), follow: @wbd@bitcointv.com
reply
If it doesn't require a hard fork, then you don't need it merged to core to work. The whole thing with soft forks is that older nodes don't reject them. So if you have a custom side-chain client, it shouldn't fork the blockchain, so you should work just fine with core nodes.
reply
Which is not really what Bitcoiners want. However, its main benefit is in regards to miner fees during times of no transactions on the main chain (empty blocks) keeping the main chain secure. There are other methods of achieving this aim though.
reply