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

231–240 of 381 posts

Re: Bitcoin – Potential Network Disruption on July 31st

#231

Post by stale2002 »

Taek wrote: post #66
stale2002 wrote: post #38

Earlier quoted context omitted.

The doomsday scenario is that Bitcoin forks for a long period of time, but then one fork down the road, crashes in value to worthlessness. There is nothing that prevents 2 forks from existing for an indefinite amount of time, just look at ethereum and ethereum classic. The question of the year is whether one side will suddenly crash down to a price of 0.

No, that's not correct. In the case of the UASF, something very frightening is possible. If the UASF has majority economic support (unlikely) and also the miners do not support it, initially the UASF side will be behind, and there will be multiple chains. There will be the UASF chain and the normal chain. But since the UASF has more support, it'll have more block reward, and eventually it'll have more hashrate behind…

It doesn't actually delete the other chain, in all Wipeout scenarios, despite what everyone is saying

Nodes can continue to follow it if they feel like it, and change their code.

There is nothing that stops someone from saying "yes, this chain has less proof of work, but I don't care".

You could argue that this would cause the old chain the be less valuable, but the old chain doesn't literally get deleted from people's hard drives in all scenarios.

The Wipeout scenario is overhyped, because of how nodes can choose to follow the old chain if they feel like it.

IE, old nodes would effectively be soft forking by adding a check point onto the old chain.

Re: Bitcoin – Potential Network Disruption on July 31st

#232

Post by anopows »

Taek wrote: post #199
anopows wrote: post #150

Earlier quoted context omitted.

How do you define user support? All the definitions I heard are able to be manipulated easily: -The/r/bitcoin consensus? Is mainly in existence because of censorship -User wallets online? Can be easily created with AWS instances -Bitcoin core? Who decides these bunch of people are in charge to represent all users and not a bunch of other developers? One obvious alternative is to let Bitcoin follow economic incentives…

User support is really easily measured in the event of a split and really hard to measure before the split. Quite simply, the coin price indicates support. After the split, there will be two versions of the Bitcoin network with independent prices. A non zero price indicates non-zero support, and as long as it's at least 25% of the original price, it'll probably be okay. A high price indicates high support. In the lon…

So you say mining of Bitcoin only follows the market value?

Isn't it at least to a large degree the other way round? That market value is following based on what is the most mined chain? If there's a split and 80% of mining power switches to one branch. Then the 20% branch loses a lot of utility for at least some time. It now has five times slower transactions until difficulty gets adjusted(or you change the proof of work of bitcoin, which itself can be precarious). And now to a minor degree the minority chain has also less safety (less hashing power).

Meanwhile why should anyone buy or send Bitcoins at the point of a split? There's a real chance that one branch will die and then you can lose the coins. The best strategy is probably to wait. So the market at least is in some way inhibited during a split.

On the other hand I'd argue miners of the minority chain have a lot of pressure to change branches. Market is not yet a good indicator only hashing power and they'll lose money if they don't continue to mine on the more profitable chain. Their safest bet is to change chains. Also they know that other miners of the minority chain think probably similarly. That's why imo in Bitcoin history every fork/split was resolved very quickly and a branch "won".

Re: Bitcoin – Potential Network Disruption on July 31st

#233

Post by stale2002 »

Cakez0r wrote: post #131
stale2002 wrote: post #35

Earlier quoted context omitted.

Kinda, they could DoS the UASF chain, but then the UASF chain could respond by doing a proof of work hard fork. If the community is behind it, then a POW change would render the 10s/hundreds of millions of dollars in mining equipment worthless. So the real question is whether or not the UASF side has the support of the community or economic majority.

You mean proof of stake? Is there a working implementation of proof of stake yet? I thought it was mostly theoretical and academic at the moment.

No, I meant proof of work.

You change the proof of work algorithm so that the existing miners can't use their fancy Bitcoin miners, and it becomes profitable to mine with GPUs instead.

Re: Bitcoin – Potential Network Disruption on July 31st

#234

Post by deelowe »

falcolas wrote: post #203
knocte wrote: post #173

Earlier quoted context omitted.

This is only layer1 (like IP in the networking world). Wait until layer2 comes (Lightning Network, TumbleBit), then we will reach the scalability levels we need for the entire planet to use the same blockchain.

Err, each layer on top of IP slows down traffic, not speeds it up. The extra overhead and retransmits result in less useful data being transferred with each packet. Perhaps not the best example to use.

Depends on what you mean by speed doesn't it? Segmentation via additional layers certainly speeds up the network as a whole. I thought the ability to scale via adding additional layers is why SDN took off.

Re: Bitcoin – Potential Network Disruption on July 31st

#235

Post by hueving »

xorcist wrote: post #214
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…

Bitcoin may not scale well, but it is the capacity problems that lead to high fees. These are two different things and it is important to not conflate the two. Scalability has improved somewhat during the past two years and most developers believe it is time to increase capacity as well. The question you refer to is how to increase capacity, within the scaling constraints. I understand the ambition to be neutral in a…

Capacity is scaling from the user perspective. If it costs $5 to send $5 worth of bitcoin because of transaction congestion and it's only processing a tiny fraction of what a single US credit card network does, the entire system is not scaling, regardless of how many nodes are running it.

Re: Bitcoin – Potential Network Disruption on July 31st

#236

Post by gopz »

rmah wrote: post #226
gopz wrote: post #220

As someone with a basic Comp Sci understanding of crypto currencies could someone explain to me why there is a scalability problem? I thought one of the primary benefits of Bitcoin was that higher transaction fees will attract more miners and ergo the transactions can be processed at a higher rate. Why won't this problem be resolved naturally? Tinkering with the block size makes sense to me as a way to crank through…

The scale problem exists because of two things: 1) currently, only about 6 blocks can be verified by the network per hour. That is fixed, any faster and the difficulty rises. Any slower and the difficulty declines. With the current code in use, it will always be about 6 blocks per hour. 2) currently, blocks are limited to 1MB in size. This means that only a certain number of transactions can be processed per block (a…

Thanks, I forgot about the automatic increase/decrease in difficulty as miners come and go. Why won't increasing the transactions per block scale forever? I see lots of people saying it's not a permanent solution. Is the SegWit stuff basically just going to allow for 'meta-transactions' so that you can create a faster overlay network as a sort of clearing house?

Re: Bitcoin – Potential Network Disruption on July 31st

#237

Post by sp332 »

wyldfire wrote: post #213
zero_iq wrote: post #165

Earlier quoted context omitted.

I am rather stunned that the entire global bitcoin network, with its colossal combined computing power, and staggering electricity consumption, is only capable of sustaining 7 tps. The level of inefficiency here is mind-boggling. Surely this must be one of the least efficient, least environmentally-friendly computing ventures ever?

> colossal combined computing power It's colossal because of the sliding difficulty. The block period is a big portion of why the transaction rate is what it is.

That's right, the reward for mining a block doesn't change just because you put more effort into it, and the difficulty adjusts to keep the rate approximately the same over time. The only reason it takes so much power to mine is there are so many people competing for the same limited prize.

Re: Bitcoin – Potential Network Disruption on July 31st

#238

Post by gtrubetskoy »

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…

Increasing the block will solve the problem until the new size is not enough, which will be very soon. A larger block means a larger blockchain, and the nice thing about the blockchain is that you can download the entire thing. With a larger block it will outpace the storage advances and will not be downloadable for the average user, which means that only specifically equipped entities such as miners will be able to have a copy of it, and that is a big problem.

10x the transactions is not much at all. The comparison with the VISA network is not a valid one - with micropayments the volume could be 100x or 10000x - we should be able to accommodate it.

The only solution is to begin handling transations off-chain. But the problem is that there is no one good proposal for it. Until it is clear how off-chain transactions work, we will keep seeing this sort of stuff.

Re: Bitcoin – Potential Network Disruption on July 31st

#239

Post by beachbum8029 »

colordrops wrote: post #103
zby wrote: post #73

Earlier quoted context omitted.

Well - increasing the block size is not costless - it is not just pushing the gas pedal a little more like in your example.

Pushing the gas peddle is not costless either. It costs gas.

This thread is about bitcoin, not ethereum.

Re: Bitcoin – Potential Network Disruption on July 31st

#240

Post by JackFr »

mdekkers wrote: post #149
acjohnson55 wrote: post #26

Earlier quoted context omitted.

That's a much more informative post than the link, and yet, I still don't really understand all the jargon. But it also reinforces for me just how not ready for primetime BTC is, and it makes me think the appreciation over the past year is truly insane.

the appreciation over the past year *Speculation

Not just simple speculation, explicit "greater fool" speculation.
Post reply on HN