Dear Chris, > I think this is an unfair characterization. You have to opt into using > drivechains.
I have heard this nonsense repeated countless times in order to justify adopting Drivechain. This is not how security works. A child can "opt-in" to using a loaded gun, but is it a good idea to make it easy for them to do that? No. This is effectively the same thing Drivechains is doing. It is a request to modify the Bitcoin protocol to make it easy for Bitcoin users to give their Bitcoins to miners. Does that sound like a good idea to anyone? If so, please leave, you are compromising Bitcoin's security. Security is about making it difficult to shoot yourself in the face. If I design a car that has a button that randomly causes the brakes to give out if pressed, is that a good idea? Can I justify pushing for such a "feature" just because it's "opt-in"? No. That is fallacy. It is not how secure systems are designed. It is how *insecure* systems are designed. > Care to share? I'm unaware if there is. Sure, happy to, as soon as I have it written up in detail. Kind regards, Greg Slepak -- Please do not email me anything that you are not comfortable also sharing with the NSA. > On Jul 12, 2017, at 12:19 PM, Chris Stewart <ch...@suredbits.com > <mailto:ch...@suredbits.com>> wrote: > > Hi Greg, > > >Here, you admit that the security of the sidechains allows miners to steal > >bitcoins, something they cannot do currently. > > If I put my coins in an anyone can spend output, a miner will take them. They > can do this today. I suggest you try it if you don't believe me :-). You have > to be more specific with contract types instead of generically talking about > 'all contracts ever'. > > > Drivechain is an unmistakeable weakening of Bitcoin's security guarantees. > > This you have not denied. > > I think this is an unfair characterization. You have to opt into using > drivechains. Other outputs such as P2PKH/Multisig etc are unaffected by a > drivechain output. As Pieter Wuille stated earlier in this thread (and Paul > has stated all along), drivechain outputs have a different security model > than other contracts. Namely they are controlled by miners. I think we can > all agree this is unfortunate, but it is the current reality we live in. I > look forward to the day we can solve the 'ownership' problem so we can have > trustless interoperable blockchains, but that day is not today. > > As a reminder, most users will not have to go through the drivechain > withdrawal process. Most withdrawals will be done via atomic swaps. > > >There is no reason to weaken Bitcoin's security in such a dramatic fashion. > >Better options are being worked on, they just take time. > > Care to share? I'm unaware if there is. > > >https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014600.html > > > ><https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014600.html> > > Everyone should re-read this email though, this is something that could > happen. Paul's design makes it so that if this occurs it is *VERY* obvious. I > guess we can argue if there is any difference between an obvious robbery vs a > hidden robbery, but I think if we have to pick one or the other the choice is > clear to me. Other designs (that I'm aware of) for sidechains had attack > vectors that weren't so obvious. > > -Chris > > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
