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

291–300 of 381 posts

Re: Bitcoin – Potential Network Disruption on July 31st

#291

Post by jcfrei »

tree_of_item wrote: post #269
jcfrei wrote: post #195

Earlier quoted context omitted.

There are some new attempts being made without using a blockchain but still reaching the same level of consensus or finality. They are usually based on DAOs (directed acyclic graphs - not to be confused with The DAO Organization). A good introduction is this paper: Blockchain-Free Cryptocurrencies: A Framework for Truly Decentralised Fast Transactions - https://eprint.iacr.org/2016/871.pdf It was previously discussed…

The acronym for directed acylic graphs is DAG, not DAO. That's also an incredibly vague thing to be "based on" and seems more like an appeal to "impressive technical sounding name that actually happens to be extremely trivial and something people learn about in a first year undergraduate mathematics course".

DAG and not DAO of course... The mathematical description is straightforward however the implementation (for example mining fee distribution) seems fairly complicated and loses a lot of the beauty of a blockchain. AFAIK Iota is the first serious attempt at running such a crypto currency.

Re: Bitcoin – Potential Network Disruption on July 31st

#292

Post by peercoin »

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.

algorand is academic at this point with evaluation on ec2. Though the paper is available and an implementation will be following.

Peercoin is one of the first working proof of stake implementations that has been running for close to 5 years now.

Re: Bitcoin – Potential Network Disruption on July 31st

#293

Post by ilikechilis »

Taek wrote: post #61
mhluongo wrote: post #24

Earlier quoted context omitted.

You skipped the option that's closest to consensus! SegWit2x has industry support and has a short enough window to lock-in before the Aug 1st UASF EDIT: Quick reference https://medium.com/@wintercooled/the-road-to-segwit-activati...

Though it has industry support, it does not have user support, because it does not have a working, tested implementation released. With less than 3 weeks until the fork triggers, I highly doubt they are going to get substantial user adoption by the time the fork triggers. One of the most amazing properties of Bitcoin is that it's completely user driven. When it comes to the fundamental consensus rules, no amount of h…

For the august 1th date user support for segwit2x does not matter at all. If the miners that agreed to run this software stick to it, they will start signaling bit4 on 21th July, when they reach 80% hashrate it will orphan non segwit blocks (kinda like bip148 but with miner support) and at the same time signal bit1 to lock in segwit which by then if that works has enough hashrate to overcome the 95% threshold to activate it. No user support at all needed for this.

Only the 2x part of segwit2x will need user adoption, but that comes 3 months after segwit has activated (next round of drama, long on popcorn)

Re: Bitcoin – Potential Network Disruption on July 31st

#294

Post by coryfklein »

zby wrote: post #273
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?

I can imagine a situation where the transactions are of such a big value that even the 7 transactions per second are enough to pay for the whole system sustenance. But yeah the system currently burns resources on a level comparable to gold mining ( https://medium.com/@zby/proof-of-work-8d8265def194 ) - but it is much less useful than gold (for value store).

Forgive my ignorance, but hasn't the historical value store of bitcoin eclipsed that of gold?

Re: Bitcoin – Potential Network Disruption on July 31st

#295

Post by ithought »

rothbardrand wrote: post #127
ithought wrote: post #83

Earlier quoted context omitted.

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-…

https://www.reddit.com/r/Bitcoin/comments/6msyk5/comment/dk4...

And Luke's subsequent comment said if enough followed then it could still be called bitcoin.

Also Maxwell said he'd quit if BIP148 fails. If the soft fork fails, bitcoin will be something different.

Re: Bitcoin – Potential Network Disruption on July 31st

#296

Post by modeless »

rothbardrand wrote: post #122
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/…

Sorry, that's completely wrong. "UAHF" is even less likely to happen and gain adoption than UASF. BitMain does not directly control all of the hash power of people using their miners and cannot successfully fork by themselves, plus again they would have no support from exchanges.

Core absolutely does not support Segwit2x, because of the hard fork later. If they do, why don't they merge it and end this standoff?

Re: Bitcoin – Potential Network Disruption on July 31st

#297

Post by sktrdie »

qznc wrote: post #247
lawn wrote: post #167

Earlier quoted context omitted.

> And of course, claiming that anybody can have access to this hardware is very very debatable. The best indicator of how this is not accessible by everybody is how centralized this industry is nowadays (just look at the correlation between ASIC manufacturers and owners of mining pools). Even if you repeat a lie a thousand times, it's not going to become true :) https://coin.dance/blocks Where is the centralization?…

If Antpool, BTC.top, F2Pool, and Bixin conspire, they control 51% of the mining power. There is the oligarchy aka centralization.

The whole point is that the miners within the pool can change to other pools if they want to!

Re: Bitcoin – Potential Network Disruption on July 31st

#298

Post by coryfklein »

hueving wrote: post #235
xorcist wrote: post #214

Earlier quoted context omitted.

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.

> it costs $5 to send $5 worth of bitcoin

Not that this is a whole lot better, but the cost is $1.48 for fastest confirmation time, and $0.42 if a delay of 15-300 minutes is acceptable to you.

Source: https://bitcoinfees.21.co/

Re: Bitcoin – Potential Network Disruption on July 31st

#299

Post by ilikechilis »

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

The testnet is already online since a few weeks now. But according to the segwit2x timeline this step should come tomorrow if they are still on track:

July 14 - Agreement Participants Install and Test Milestone

Re: Bitcoin – Potential Network Disruption on July 31st

#300

Post by davidgerard »

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://…

The problem there is that Lightning Network is as yet vaporware.
Post reply on HN