Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bitcoin – Potential Network Disruption on July 31st

bitcoin.org

Post reply on HN
Print view View original

121–130 of 381 posts

Re: Bitcoin – Potential Network Disruption on July 31st

#121

Post by rothbardrand »

jpatokal wrote: post #49
beaner wrote: post #46

Earlier quoted context omitted.

> any changes require consensus from the miners who create Bitcoins and process transactions, and because it's not in their best incentive to do anything to reduce those transaction fees Can you explain how this jives with miners supporting Segwit2X, which brings both segwit and bigger blocks?

The opposing and (IMHO) ultimately greater pressure is that it's also in miners' best interest to keep Bitcoin alive and successful. It took a long time to hammer out SegWit2x and it's still not certain that it's going to work.

You would think so, but I think that they think they have enough hash power to take over the whole thing. They may be right. They are clearly making a power grab and opposing Segwit2X: https://blog.bitmain.com/en/uahf-contingency-plan-uasf-bip14...

Segwit2X would activate effectively Bip148, though it was originally a proposal to use a different mechanism it is acceptable enough that Core is happy to have segwit activated that way.

Re: Bitcoin – Potential Network Disruption on July 31st

#122

Post by rothbardrand »

modeless wrote: post #68

The problems described in this post are unlikely to happen. There is an attempt to split ("fork") the network scheduled for August 1. The people forking will force activation of a new feature, Segwit, while the non-forkers won't. However , the non-forkers are currently planning to activate Segwit as part of a compromise plan before the deadline. If this compromise happens as planned, there will be no need to force-ac…

You're misunderstanding the issue. Core / Bitcoin.org don't have a problem with Segwit2X which is a UASF like Bip-148 which core supports. (It uses a different BIP and is slightly different but it's perfectly find with all of us.)

The threat is that BitMain, the controller of a very large amount of hashing power, something like %70 is threatening a hard fork into their own, non-segwit chain:

https://blog.bitmain.com/en/uahf-contingency-plan-uasf-bip14...

Re: Bitcoin – Potential Network Disruption on July 31st

#123

Post by rothbardrand »

jstanley wrote: post #101

I wrote this in case anyone wants more information: https://smsprivacy.org/bip148-uasf Should be a bit more informative than TFA.

Naw, this isn't about Segwit2x, it's about the hard fork bitmain wants to do: https://blog.bitmain.com/en/uahf-contingency-plan-uasf-bip14...

Re: Bitcoin – Potential Network Disruption on July 31st

#124

Post by rothbardrand »

mhluongo wrote: post #16
isubkhankulov wrote: post #12

this post feels like propoganda. prior bitcoin upgrades have gone much smoother and when they do go wrong the community banded together to spread the right information. albiet the userbase was likely a lot smaller back then.

Bitcoin.org definitely has a position. I wouldn't be surprised if they were pro-UASF, even though it appears there's consensus behind an alternative. That said- this is a legit notice and is probably good advice. This is a contentious upgrade.

The consensus is behind Segwit2X which IS a UASF. The original UASF proposal is BIP-148 and Segwit2X uses a different mechanism (BIP-9 and 91? I think) but those differences are implementation details that Bitcoin.org doesn't the a problem with.

The Segwit2X and Core factions agree on Segwit. Core doesn't like later doing a 2MB hard fork, but most of us think it's a reasonable compromise. There won't be a lot of complaining.

The real threat is Bitmain which wants to do its own hard fork, that will NOT be compatible with Segwit, which they intend to mine privately and which will have unlimited block size:

https://blog.bitmain.com/en/uahf-contingency-plan-uasf-bip14...

That's what the original post is about. That fork is very dangerous.

Re: Bitcoin – Potential Network Disruption on July 31st

#125

Post by lawn »

rothbardrand wrote: post #116
lawn wrote: post #110

Earlier quoted context omitted.

This is the main narrative being pushed by Blockstream and Core who are afraid of loosing control over the main Bitcoin reference client, beware. > I think you missed the key issue. Mining is largely centralized under the control of Bitmain, both via pools and indirectly via miners they have sold False, bitcoin mining has never been as decentralized as it is now: https://coin.dance/blocks > Segwit2X is a compromise--…

This is not a narrative, this is the technical facts. You're pushing a narrative. Bitcoin mining has never been as centralized as it is right now with one man controlling over %70 of the hash rate via multiple pools. Many of those pools are just the same player operating under different names. Segwit2X is in fact a compromise, and I linked to a blog post where Bitmain complains about it. They want to "activate segwit…

You're repeating your arguments without any technical arguments yourself.

You repeat the mistakes as outlined in this article:

https://medium.com/@johnblocke/decentralization-fetishism-is...

> They back a solution that gives them more control over the network and higher fees, not lower fees. You think they will give lower fees but you're uninformed about the current fee situation.

How so? Because bigger blocks will give lower fees than Segwit only.

> Blockstream doesn't have control. You're pushing an uninformed narrative that makes Blockstream out as some sort of evil corporation--- the reality is block stream employees are a minority of core, core development is done in the public eye (unlike even Segwit2X and certainly any of Bitmains's hacks, like BU which was closed source for awhile before people just gave up on it.)

The censorship in those channels are well documented.

> You keep talking as if the miners are supposed to be in control, as if that's right. It's not.

You don't understand the point of PoW in Bitcoin.

> You act as if there are a lot of miners and they are the bitcoin community, they are not, they are the minority.

Doesn't matter. And btw, you think UASF is the majority? Because they are not.

> Your articles are non-technical nonsense full of FUD written by people who do not understand the bitcoin code.

Where are the technical arguments against these supposed "non technical FUD pieces"? You provide none.

Re: Bitcoin – Potential Network Disruption on July 31st

#126

Post by spiralx »

awestroke wrote: post #81
dekz wrote: post #74

Earlier quoted context omitted.

That's 86.5% miners signalling to signal support. Segwit2x is still yet to have a working and tested implementation. Would you support something which has not been fundamentally tested?

> Segwit2x is still yet to have a working ... https://github.com/btc1/bitcoin > ... and tested implementation. It will go online on the testnet tomorrow

> It will go online on the testnet tomorrow

It seems rather premature to call it working before it gets properly tested. And three weeks is a woefully short time to test something like this, fix any issues that are found, and then re-test.

Re: Bitcoin – Potential Network Disruption on July 31st

#127

Post by rothbardrand »

ithought wrote: post #83
isubkhankulov wrote: post #12

this post feels like propoganda. prior bitcoin upgrades have gone much smoother and when they do go wrong the community banded together to spread the right information. albiet the userbase was likely a lot smaller back then.

If the soft fork goes through, the Chinese miners are going to attack the chain. If the soft fork fails, Core developer Luke-Jr said they'd change the Proof of Work algorithm and possibly create an altcoin (or bitcoin if enough follow). This is like a Russian Roullete situation. The gun's loaded, all signs point to neither side conceding. It's the cypherpunks vs the corporate miners (plus some former devs and very cr…

No, Luke is saying that if chinese miners attack the chain and are successful, then the core chain will need to change PoW (otherwise with a minority of hash power it will take al long time for difficulty to adjust.)

There are three factions here-- Segwit2X and Core, who both want segwit, and Bitmain which does not want segwit and which has threatened a forcible hard fork into a bitcoin that has unlimited block size-- and they are even talking about doing an ICO and things like that:

https://blog.bitmain.com/en/uahf-contingency-plan-uasf-bip14...

Re: Bitcoin – Potential Network Disruption on July 31st

#128

Post by julian_1 »

rothbardrand wrote: post #109
julian_1 wrote: post #75

Earlier quoted context omitted.

A counter-argument is that the Lightening work is a proprietary development outside of bitcoin core (lead by Blockstream) and the work is even patent-encumbered. They state the ip is for defensive purposes only - however that is questionable given that anything they implement, automatically becomes prior-art. It is also contrary to the spirit and practice of the majority of crypto/alt projects. It is unreasonable to…

There's nothing proprietary about Lightening Network. Lightning network was started by a startup, who published the paper, there are several open source implementations of it, and to my knowledge there's no actual involvement of Blockstream. Blockstream has their own solution (that doesn't need segwit right now) called Liquid. Liquid Network and Lightening Network are different things and work in a different ways. A…

I referred to Blockstream and this is their patent front announcement,

> Today we are excited to announce some important steps we are taking on the patent front, why these defensive steps are necessary, and our hope that others will see merit in our approach and follow our lead.

...

> Our Patent Pledge assures developers and users of our technology that we will not sue them for patent infringement, provided they comply with the terms and conditions of our pledge...

https://blockstream.com/2016/07/19/blockstream-defensive-pat...

Edit: Here is a discussion of Blockstream's patent application for side car design,

> The application, submitted on 9th May and published earlier this week, outlines “systems and methods...for transferring an asset from a parent chain to a sidechain”.

http://www.coindesk.com/bitcoin-blockstream-patent-sidechain...

Here is blockstream talking about Lightening,

> Blockstream’s work on the Lightning protocol began two years ago with the intention of enabling new applications and developing new use cases that could help further the adoption of Bitcoin and related technologies

https://blockstream.com/2015/09/01/lightning-network.html

Also presumably if segwit activates then Liquid is no longer needed?

Edit: The relationship between Blockstream and Lightning is underscored, by the fact that the largest contributor to the specification is a Blockstream employee (Rustee Russell),

https://github.com/lightningnetwork/lightning-rfc/graphs/con...

Re: Bitcoin – Potential Network Disruption on July 31st

#129

Post by rothbardrand »

shp0ngle wrote: post #117
lawn wrote: post #110

Earlier quoted context omitted.

This is the main narrative being pushed by Blockstream and Core who are afraid of loosing control over the main Bitcoin reference client, beware. > I think you missed the key issue. Mining is largely centralized under the control of Bitmain, both via pools and indirectly via miners they have sold False, bitcoin mining has never been as decentralized as it is now: https://coin.dance/blocks > Segwit2X is a compromise--…

FlexTrans are far more crappy and far far less tested than segwit. It introduces its own weird format that nobody uses, that's sort-of-XML-but-binary (I mean, the authors said to themselves "I like XML so much I want it in a binary protocol") - and problems with types of formats is exactly where the various maleability problems come from! Which was reason for the segwit in the first place! I am not for UASF and I thi…

You oppose Segwit2x AND BIP-148, but you like Segwit?

Re: Bitcoin – Potential Network Disruption on July 31st

#130

Post by rothbardrand »

lawn wrote: post #120
shp0ngle wrote: post #117

Earlier quoted context omitted.

FlexTrans are far more crappy and far far less tested than segwit. It introduces its own weird format that nobody uses, that's sort-of-XML-but-binary (I mean, the authors said to themselves "I like XML so much I want it in a binary protocol") - and problems with types of formats is exactly where the various maleability problems come from! Which was reason for the segwit in the first place! I am not for UASF and I thi…

> and problems with types of formats is exactly where the various maleability problems come from! Which was reason for the segwit in the first place! You obviously have no idea what the maleability problem is and you didn't read and understand the linked articles.

Do enlighten us. Please be very detailed. Don't just link to some random article from a non-technical propagandist like you have been. Explain it.

Segwit does fix malleability, and this is critical for bitcoins future, for many reasons.

Post reply on HN