Drivechain critiques by gmaxwell revisited, maybe you changed your mind? - page 3.

squatter

legendary

Activity: 1666

Merit: 1196

STOP SNITCHIN'

Quote from: Wind_FURY on March 10, 2020, 01:23:57 AM

I'm very curious, especially after Adam Back mentioned "trade-offs" of using Lightning, or Liquid. I believe using Drivechains might also just be a matter of accepting the trade-offs.

https://twitter.com/adam3us/status/1217845788438601733

Quote

lightning makes security tradeoffs, liquid makes different security tradeoffs

These are two very different situations.

Lightning and Liquid can be thought of as off-chain or out-of-band. They have no effect on Bitcoin's consensus. The security trade-offs -- like needing to keep private keys online in LN, or trusting Liquid validators not to steal funds -- only affect LN users or Liquid users, respectively. Bitcoin users are unaffected no matter what.

With drivechains, Bitcoin users can't opt out. That's the difference. Drivechains are soft forked into the consensus by miners.

Wind_FURY

legendary

Activity: 2898

Merit: 1823

Quote from: NotATether on March 09, 2020, 03:31:14 PM

@Wind_FURY, I found your quote at http://www.drivechain.info/, by the way.

Thanks. Yes, that's the site.

Quote

I watched the youtube video and the guy was mentioning how each sidechain has a reward attached to it that they didn't think out through. I don't know how frequently this activity happens in the bitcoin development ecosystem but it's common for a lot of altcoin devs to not think through very important parts of the system through which reflects in the stability of the altcoin.

One problem I can think of right off the bat is what will happen to sidechains that scamcoins are hosted on after their developers abandon maintenance of their sidechain. I think that would be a waste of space.

Waste of space to the people who run the side-chain, just like to the people who run the node of a shitcoin.

Quote

But I think a much more important problem is that devs can't force everyone to use drivechains due to the decentralized model of bitcoin, by pushing a new bitcoin core release. Still, lots of people/services aren't using native segwit addresses, in some cases they are even using legacy addresses. But that's a different topic.

That's actually a feature, not a problem/"bug". Cool

Quote

Now I'm not claiming to know anything about drivechains, but nothing is stopping someone from hard-forking bitcoin even if drivechains were in place. I don't think drivechains can interfere with layer-1 activity which is where the hardfork takes place.

Warning, I'm just learning about Drivechain too. There will be lots of questions, and shit posts from me. Everyone is welcome to correct me.

BUT, their forked coin won't be as secure, and as valuable as Bitcoin. We could debate that a side-chain-coin might become more valuable than a forked shitcoin. Cool

Let's wait for gmaxwell's post. I'm very curious, especially after Adam Back mentioned "trade-offs" of using Lightning, or Liquid. I believe using Drivechains might also just be a matter of accepting the trade-offs.

https://twitter.com/adam3us/status/1217845788438601733

Quote

lightning makes security tradeoffs, liquid makes different security tradeoffs

squatter

legendary

Activity: 1666

Merit: 1196

STOP SNITCHIN'

Quote from: NotATether on March 09, 2020, 03:31:14 PM

But I think a much more important problem is that devs can't force everyone to use drivechains due to the decentralized model of bitcoin, by pushing a new bitcoin core release.

I wouldn't say that's the real problem of drivechains.

My understanding is that drivechains are soft forked into the main chain consensus. This means two things: Non-upgraded Bitcoin nodes would no longer be fully validating, and fully validating Bitcoin nodes would now have greater bandwidth, latency, and storage overheads. Just like block size increases, this would negatively affect miner and full node decentralization.

Those costs probably aren't worth the gains given how insecure a drivechain is, by Paul Sztorc's own admission:

Quote

It is said that “51% of the miners can steal all of the funds on the sidechain”.

It is true that 51% hashrate can overwhelm the 13,150 ACK requirement (ie, the “train metaphor”), and (if unopposed) include any withdrawal they like. Namely, they would include a withdrawal that pays them all of the sidechain’s BTC.

A 51% attack on Bitcoin only allows miners to double spend. On a drivechain, they can just steal everything.

NotATether

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

@Wind_FURY, I found your quote at http://www.drivechain.info/, by the way.

I watched the youtube video and the guy was mentioning how each sidechain has a reward attached to it that they didn't think out through. I don't know how frequently this activity happens in the bitcoin development ecosystem but it's common for a lot of altcoin devs to not think through very important parts of the system through which reflects in the stability of the altcoin.

One problem I can think of right off the bat is what will happen to sidechains that scamcoins are hosted on after their developers abandon maintenance of their sidechain. I think that would be a waste of space.

But I think a much more important problem is that devs can't force everyone to use drivechains due to the decentralized model of bitcoin, by pushing a new bitcoin core release. Still, lots of people/services aren't using native segwit addresses, in some cases they are even using legacy addresses. But that's a different topic.

Now I'm not claiming to know anything about drivechains, but nothing is stopping someone from hard-forking bitcoin even if drivechains were in place. I don't think drivechains can interfere with layer-1 activity which is where the hardfork takes place.

Wind_FURY

legendary

Activity: 2898

Merit: 1823

For the newbies, who might not know. Drivechain is a software side-chain project by Paul Sztorc, which may help Bitcoin in scaling, privacy, and other "short-comings" that altcoins are trying to "fix". With Drivechain, we wouldn't need altcoins. Everything will be a side-chain of Bitcoin.

Quote

Drivechain allows BTC to travel back-and-forth to other software applications (called “sidechains”). Thus, BTC-owners can opt-in to new features or tradeoffs. Those who don’t opt-in, never need to care what any sidechain is doing.

As with the Lightning Network, DC-users move their coins into a “layer-2” – a zone where BTC can change hands an unlimited number of times. Eventually, just the net effect of these transfers is recorded back on layer-1.

Bitcoin Core can’t observe any layer-2 (by design), so we need a way to discourage fraudulent “netting”. LN counters theft via “justice transactions”; DC via forsaken mining revenues. LN-netting is private and instant; DC-netting is public and VERY slow (once per ~3 months).

Key benefits – only obtainable via Drivechain:

Three existential threats to BTC are neutralized – altcoin-competition, hard fork campaigns, and extension block campaigns.
BTC development becomes anti-fragile with respect to CoreDev mistakes.
BTC maintains hashrate security in the long run.
BTC can scale to credit-card level txn-processing – without changing the CONOP of Bitcoin Core. These cheap txns have optimal fungibility and supply vital pretext to the BTC ecosystem.
BTC gains new, experimental abilities, especially P2P event derivatives.

But this is not what the topic is about. It's about criticisms from the past from respected Bitcoin experts, and a revisitation of if they still believe they hold true.

gmaxwell, you said these in the past. With the dawn of Lightning and Liquid side-chains, and observing their own flaws, and short-comings, have you changed your mind from past criticisims on Drivechain?

Your July, 2017 criticism, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014726.html

December, 2018 criticism with Andrew Poelstra, https://www.youtube.com/watch?v=NA1xSe2nLoY&feature=youtu.be&t=5635

Topic: Drivechain critiques by gmaxwell revisited, maybe you changed your mind? - page 3. (Read 1110 times)