pull down to refresh

If you would find it useful to be able to transfer your bitcoins to and from another chain (which can implement ~ any feature imaginable) without needing to go through a permissioned custodian or federation, and think bitcoin miners would be well-incentivized to manage the transfer process instead, then you can consider BIP-300 useful. I think BIP-300 is worth activating if only to allow the community of people who want to use BIP-300 to be able to, they should be allowed to do what they want with their coins and I see no harm to bitcoin in allowing them to.
What's your steel man of the downsides of activating BIP-300?
reply
I think the strongest argument against activating BIP-300 is the argument that making any change to bitcoin (consensus or otherwise) risks breaking something, and consensus bugs in particular are hard to fix without another consensus change (potentially even a hard fork). But this is why we review and test things, and BIP-300 has had an active testnet for a while and running smoothly, and I imagine any PR against Bitcoin Core would get lots of review and testing as well prior to activation. I am cautious of changes to the bitcoin codebase and consensus in particular, but not so much that I oppose all changes.
reply
There have been other widely supported changes to Bitcoin that have been implemented, so surely this can't be the strongest argument or the best steel man of those who oppose it?
How does testnet reveal potential issues related to the economics and game theory of the change?
reply
There have been other widely supported changes to Bitcoin that have been implemented, so surely this can't be the strongest argument or the best steel man of those who oppose it?
I think it is. If you can think of a stronger argument I'd like to hear it.
How does testnet reveal potential issues related to the economics and game theory of the change?
afaict BIP-300 does not affect bitcoin economics or game theory for any bitcoin users who aren't using a hashrate escrow, so to everyone who doesn't plan to use a hashrate escrow, the most important consideration is whether or not the implementation is technically sound.
reply
What about only allowing 1/100000th of the hashrate to be allowed on a drivechain at any time? Or another amount?
reply
I'd appreciate it if it's constructed with opcodes that have other uses! Otherwise agree.
reply
One nice thing about the hashrate escrow mechanism is that it is indifferent to what's on the other side of the hashrate escrow. Could be a drivechain, could be some other flavor of sidechain, could be a chaumian mint of some kind... imo this flexibility makes up for the otherwise "single purpose" nature of the BIP. If hashrate escrows could be implemented with a multipurpose op code that would be an interesting result, assuming the other capabilities of the op code were themselves desirable. I remember zmn posting about being able to implement drivechains via recursive covenants, though in that context zmn was using this as an argument against recursive covenant op codes rather than for them.
reply