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

371–380 of 381 posts

Re: Bitcoin – Potential Network Disruption on July 31st

#371

Post by rothbardrand »

joosters wrote: post #170
rothbardrand wrote: post #111

Earlier quoted context omitted.

The cost is that larger blocks have difficulty crossing the great firewall of china and mining is already centralized there. I have seen this myself with a production blockchain and blocks that were less than 1mb. Increasing the size increases this effect and gives Chinese miners and artificial advantage. Plus there's no congestion on the network right now. There's not a scaling problem. It was spam. Further, segwit…

'The great firewall of china' isn't someone manually inspecting every byte that enters and leaves china, it can manage more than a 1mb transaction just fine. And, even if the delays were more than minuscule, how does it favour one side over the other? Both sides have the same delay. Plus there's no congestion on the network right now. There's not a scaling problem. It was spam. Woohoo! No need for anyone to do anythi…

You don't even seem to understand what we are talking about (not 1mb transactions) and you're flat out wrong. I have direct experience with a p2p network that I have built, and the problems getting blocks between nodes on opposite sides of the "Great Firewall of China". Really any engineer with an understanding of that system and P2P networks should understand why.

Everyone is trying to scale bitcoin because bitcoin is growing dramatically... that doesn't mean that the "full blocks" and "high fees" we saw recently weren't due to spam.

Please logic.

Re: Bitcoin – Potential Network Disruption on July 31st

#372

Post by rothbardrand »

oh_sigh wrote: post #348
RandVal30142 wrote: post #171

Earlier quoted context omitted.

>Segwit will disable ASICBOOST Incorrect. It would make 'stealth' ASICBoost mining improbable but still possible overall. > Therefore, BitMain has been launching FUD campaigns. Substantiate your claim. > proven to be due to spam Show it. Just show it already. Its a transparent blockchain but no one can show this spam, identify how it is malicious, show where it is coming from. Show the spam already. Like ASICBoost it…

Btc noob: What's wrong with asicboost? Is it just because it's patented?

It's an exploit that gives a miner a way to boost profits, but in order to do so, they have to mine empty blocks, which is bad for bitcoin because the purpose of miners is to build blocks with transactions in them.

Re: Bitcoin – Potential Network Disruption on July 31st

#373

Post by rothbardrand »

lawn wrote: post #134
rothbardrand wrote: post #130

Earlier quoted context omitted.

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.

The article contains a technical explanation... Don't be lazy and dismissive. It also explains that Segwit fixes the malleability and that Flexible Transactions also does (but in a non hacky way), so what is your point?

My point is that you don't understand what you are talking about and are feeding us FUD based bullshit. And you have failed to give an explanation when called on it, just linking to someone else (also ignorant) as "proof".

Re: Bitcoin – Potential Network Disruption on July 31st

#374

Post by rothbardrand »

lawn wrote: post #140
rothbardrand wrote: post #132

Earlier quoted context omitted.

> How so? Because bigger blocks will give lower fees than Segwit only. Who profits from high fees? Core? No. Miners. BitMain is very adamant about not wanting low fees. The idea that Segwit, which quadruples block size and offers a fee discount is an attempt to keep fees high is absurd on the face of it. >And btw, you think UASF is the majority? Because they are not. You're convincing me that you're operating from a…

Uh I'm obviously referring to BIP148 when I say UASF, but way to argue with semantics. > BitMain is very adamant about not wanting low fees. Yet Bitmain supports larger blocks, you're not making sense. > Your personal attacks and failure to address the technical issues speak for themselves, so I have not quoted them, nor responded. What personal attacks? Sure, continue dismiss it as "FUD" or "non-technical people".

It's not semantics when you're talking about different activation mechanisms... that you think it is proves to me you don't really understand what's going on.

I point out a contradiction in Bitmains position and you say that means I'm not making sense? Once again, you are arguing that your ignorance somehow trumps the facts.

And of course, you resorting to insults is all the proof I could have needed.

Go educate yourself. Start at bitcoin.org

Re: Bitcoin – Potential Network Disruption on July 31st

#375

Post by rothbardrand »

RandVal30142 wrote: post #327
rothbardrand wrote: post #116

Earlier quoted context omitted.

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…

>This is not a narrative, this is the technical facts. You're pushing a narrative. Then you immediately launch into narrative, one that avoids detailing how Jihan doesn't control the hashrate. Individual buyers and operators of Bitmain's mining hardware do. You are attributing things in plainly incorrect ways. >Bitcoin mining has never been as centralized as it is right now with one man controlling over %70 of the ha…

I didn't avoid dealing with your lie, I stuck to the truth.

Re: Bitcoin – Potential Network Disruption on July 31st

#377

Post by EGreg »

zby wrote: post #53
jpatokal wrote: post #20

Well, that's a remarkably uninformative announcement. Here's an attempt at a neutral tl;dr from a Bitcoin amateur. Bitcoin is currently suffering from significant scaling problems, which lead to high transaction fees. Numerous proposals to fix the scaling issue have been proposed, the two main camps being "increase the block size" and "muddle through by discarding less useful data" (aka Segregated Witness/SegWit). Ho…

It is probably not possible to solve the scaling problems on-chain - a secure decentralized consensus on a global scale cannot be fast. Currently the bitcoin protocol processes about 7 transactions per second. Doubling the speed by doubling blocks will not make it much closer to the 50K transactions per second of a system like VISA. But it is probably possible to scale the transaction system off-chain - with https://…

I don't understand how you know it can't be fast.

I think proof of work mining is extremely wasteful. But once it is in place, you can sign a merkle tree of any size. You can add as many transactions as you want. The problem is that the ledger has to grow and grow. It would be nice if something was developed where you didn't need to keep the whole history.

Re: Bitcoin – Potential Network Disruption on July 31st

#378

Post by SkyMarshal »

Hermel wrote: post #71
zby wrote: post #53

Earlier quoted context omitted.

It is probably not possible to solve the scaling problems on-chain - a secure decentralized consensus on a global scale cannot be fast. Currently the bitcoin protocol processes about 7 transactions per second. Doubling the speed by doubling blocks will not make it much closer to the 50K transactions per second of a system like VISA. But it is probably possible to scale the transaction system off-chain - with https://…

I'm really tired of hearing the "increasing the block size won't suffice"-argument. Yes, increasing blocks to 10 MB won't give us VISA-scale, but it will allow Bitcoin to serve TEN TIMES AS MANY USERS! I can't believe how many otherwise intelligent people fail to see that this is desirable. It's like driving your car at 10 km/h per hour on the high-way and refusing to increase your speed because that would still not…

>I can't believe how many otherwise intelligent people fail to see that this is desirable.

If there were no technical and economic tradeoffs to increasing the blocksize then yes, it would hard to see how otherwise intelligent people could oppose it. Everybody loves a free lunch. But there are tradeoffs, which you conveniently omit, which are giving those otherwise intelligent people pause, rightfully so.

Re: Bitcoin – Potential Network Disruption on July 31st

#379

Post by SkyMarshal »

jpatokal wrote: post #70
Taek wrote: post #59

Earlier quoted context omitted.

A neutral response would probably not use the phrasing 'muddle through' with regards to the solution endorsed by most of the technical experts in the Bitcoin space. ---- Right now there are 3 implementations of Bitcoin in the wild, and each of the 3 will react differently to different network events. The network is essentially splitting apart, with each fragment driven by a different faction. If you don't know what t…

My view is that SegWit is a bandaid, not a cure: while it would give Bitcoin some breathing room, it doesn't fix the underlying constraints and is not alone going to solve scaling, hence "muddle through".

You can characterize a blocksize increase too with those exact words. Calling one a "muddle" and not the other appears anything but neutral.

Re: Bitcoin – Potential Network Disruption on July 31st

#380

Post by SkyMarshal »

criddell wrote: post #244
jpatokal wrote: post #20

Well, that's a remarkably uninformative announcement. Here's an attempt at a neutral tl;dr from a Bitcoin amateur. Bitcoin is currently suffering from significant scaling problems, which lead to high transaction fees. Numerous proposals to fix the scaling issue have been proposed, the two main camps being "increase the block size" and "muddle through by discarding less useful data" (aka Segregated Witness/SegWit). Ho…

Were the scaling problems not predicted or known in the original design?

They were known since the beginning, but for any complex problem it takes time to explore the solution space and hone in on the best (or least bad) solutions.
Post reply on HN