Blockchain split of 4 July 2015 - page 11.

ElectricMucus

legendary

Activity: 1666

Merit: 1057

Marketing manager - GO MP

Quote from: TooDumbForBitcoin on July 05, 2015, 12:22:31 PM

Quote from: ElectricMucus on July 05, 2015, 06:52:59 AM

No supporter of a website, web-server software or any other type of Internet appliance makes stupid claims like being "anti-fragile", "backed my math" or "secured by the laws of the universe" though.

out of ass?

Well, here is what /r/buttcoin has to say.
http://www.reddit.com/r/Buttcoin/comments/3c76ng/why_yesterdays_bip66_accidental_hard_fork/

Quote

And in general, actually verifying the transactions - the precise thing miners are paid the block reward for - is too much overhead when you could be mining the next block. Sooo the miners just ... assumed other miners' blocks were okay! As in: multiple miners, amounting to roughly half the hashrate.

This is completely right, the whole point of mining is verifying transactions, that it was possible for even some of the miners to circumvent that requirement and then reap the rewards is a tremendous fail of the bitcoin software and as such it's developers.

turvarya

hero member

Activity: 714

Merit: 500

Quote from: QuestionAuthority on July 05, 2015, 07:23:58 AM

Quote from: turvarya on July 05, 2015, 05:44:21 AM

Quote from: ?? on ??

Quote from: stingers on July 04, 2015, 11:33:57 PM

Can someone advice me if this split would affect the price of bitcoin anyhow? If yes how?

The "split" like you call it, was resolved by the network 6 blocks after it happened - which shows how resilient (or anti-fragile) the Bitcoin network has become. Regarding the price of bitcoin, please go to the speculation section of the forum.

It requires manual intervention, so anti fragile my ass!
Also where is the 6 blocks figure from? Your ass?

It just requires you to keep your software up to date.
It's like having a website and complain to be hacked, just because you didn't install security patches.
Do you also want the dev team to wipe your ass?

ElectricMucus is right, it's not anti-fragile at all unless you think the Bitcoin fairies are magically keeping everything patched and updated for your downloading enjoyment. Someone has to monitor the system like a 24hr a day security guard. Nothing is automated. Every version of Bitcoin core after 0.9.5 can detect invalid blocks. Web wallets, SPV wallets and core 0.9.4 and earlier are still vulnerable to double spending. They need to wait 30 confirmations to be safe. That's the complete opposite of anti-fragile. That's more like fucked-in-a-hand-basket. I can't go to a store that uses SPV devices and buy something because I'll need to sleep there overnight to wait for my money to clear. What would you do if you were in a restaurant with family and pulled out your debit card to pay and the cashier told you to wait for a few hours because your bank is having a problem. I'd shit bricks. I'd close every account I had at that bank immediately and talk shit about them to anyone that would listen for the rest of my life.

That doesn't change anything about, that in this case, people had just to keep their wallet up-to-date.
If your web-wallet provider wasn't up-to-date. Sure, close your account there. Find one, who takes his job more serious. (I actually changed my bank half a year ago, because my former bank's online banking sucked)
If you use a SPV-wallet, make sure to connect to an up-to-date node.
And yes, there is no Bitcoin fairy doing that for you. I can agree on that.

monbux

legendary

Activity: 1736

Merit: 1029

Quote from: redsn0w on July 05, 2015, 08:43:53 AM

Quote from: shorena on July 05, 2015, 08:10:54 AM

Quote from: redsn0w on July 05, 2015, 07:55:06 AM

Quote from: bitnanigans on July 05, 2015, 07:49:57 AM

So what exactly was responsible for this error?

The miners, not all the miners but some of them....

To elaborate this a bit further:

My understanding of the situation is that some miners use a mining technique called SPV mining that relies on the assumption that the rest of the network produces valid blocks to mine a tiny bit faster. Those miners using SPV mining essentially have a few seconds advantage over those that completly verify the block first. What happend is that a big pool using said technique received an "invalid" block, a block version 2. These have recently been declared invalid as over 950 out of 1000 blocks mined are version 3. The pool tried to build the chain on top of the now invalid version 2 block, causing the fork. Because of the way bitcoin works we had two chains competing over which is the correct one. Those running nodes 0.10.x or 0.9.5 would not accept the invalid blocks and those following it, while other nodes would still accept them as valid and thus accept a different chain as the longest and currently valid chain. This resulted in wasted hash power for the miners and confusion as different services and wallets that rely on bitcoin core in the background showed different information / statuses depending on the version of bitcoin core running in said background.

Disclaimer: this attempt of a tl;dr version might be flawed, please correct me if you find any.

maybe... I didn't follow the whole situation.

Quote from: monbux on July 05, 2015, 08:33:18 AM

I'm not very technologically advanced myself when it comes to the blockchain, so I am wondering, how does this affect wallets like the trezor and its webwallet?

it affected the bitcoin blockchain, the various wallets 'validate' the blockchain....

Yes, I understand that it affected the blockchain, I'm just wondering how the webwallet for trezor is affected - what bitcoin core version would that wallet be running off of? Or would it be the trezor itself that has the blockchain info? Whichever.

turvarya

hero member

Activity: 714

Merit: 500

Quote from: freedoge.co on July 05, 2015, 07:29:01 AM

Quote from: turvarya on July 05, 2015, 06:52:45 AM

Quote from: freedoge.co on July 05, 2015, 06:28:33 AM

hey, i'd like to help bitcoin and setup electrum full node, i have 4GB-RAM 4GBvRAM VPS is it capable to run full node with 10k history limit?
Any guide or help welcome for ubuntu 12.04

That should help
https://github.com/spesmilo/electrum-server/blob/master/HOWTO.md

How much disk space to you have?

i have currently 50 GB free out of 100, is it enough?

edit. i can free up or request more space anytime

My blockchain-folder is currently 42.5 GB big, so you should be fine for a start(I don't think, electrum server needs much space)

AtheistAKASaneBrain

hero member

Activity: 770

Merit: 509

Quote from: ?? on ??

Quote from: stingers on July 04, 2015, 11:33:57 PM

Can someone advice me if this split would affect the price of bitcoin anyhow? If yes how?

The "split" like you call it, was resolved by the network 6 blocks after it happened - which shows how resilient (or anti-fragile) the Bitcoin network has become. Regarding the price of bitcoin, please go to the speculation section of the forum.

This is great news and bad news at the same time. I mean sure, the network is solid, but we now know unless you are using core, you may be prone to be a victim of accidents like that. Imagine you sent a big transaction through Electrum or were supposed to receive one... who would give your your money back? every victim is a potential bitcoin user that may get frustrated and never use it again, so this needs to be addressed so it never happens again, specially before we go fully mainstream, and Electrum type wallets will be most of the % of what people will be using, full node runners will remain a minority.

jonald_fyookball

legendary

Activity: 1302

Merit: 1008

Core dev leaves me neg feedback #abuse #political

Quote from: SebastianJu on July 05, 2015, 12:39:38 PM

So they did not want to verify the blocks with 1MB because of the size and now 8MB blocks come. Roll Eyes

At least they have a hard lesson that its risky to not verify. I mean they lost quite some, mining on the wrong fork. On top they are depending on users that might leave them now.

Can anyone explain why a miner wouldn't simply verify the last block in parallel with their mining computations?
Let their ASICS hash while another machine double checks the last block. What's wrong with that?

SebastianJu

legendary

Activity: 2674

Merit: 1083

Legendary Escrow Service - Tip Jar in Profile

So they did not want to verify the blocks with 1MB because of the size and now 8MB blocks come. Roll Eyes

At least they have a hard lesson that its risky to not verify. I mean they lost quite some, mining on the wrong fork. On top they are depending on users that might leave them now.

TooDumbForBitcoin

legendary

Activity: 1638

Merit: 1001

Quote from: ElectricMucus on July 05, 2015, 06:52:59 AM

Quote from: turvarya on July 05, 2015, 05:44:21 AM

Quote from: ?? on ??

Quote from: stingers on July 04, 2015, 11:33:57 PM

Can someone advice me if this split would affect the price of bitcoin anyhow? If yes how?

The "split" like you call it, was resolved by the network 6 blocks after it happened - which shows how resilient (or anti-fragile) the Bitcoin network has become. Regarding the price of bitcoin, please go to the speculation section of the forum.

It requires manual intervention, so anti fragile my ass!
Also where is the 6 blocks figure from? Your ass?

It just requires you to keep your software up to date.
It's like having a website and complain to be hacked, just because you didn't install security patches.
Do you also want the dev team to wipe your ass?

No supporter of a website, web-server software or any other type of Internet appliance makes stupid claims like being "anti-fragile", "backed my math" or "secured by the laws of the universe" though.

out of ass?

TooDumbForBitcoin

legendary

Activity: 1638

Merit: 1001

Quote from: ElectricMucus on July 04, 2015, 03:35:17 PM

anti-fragile my ass

Do it yourself. Preparation H usually works.

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: tspacepilot on July 05, 2015, 10:50:37 AM

What was the new rule from BIP66 that v3 blocks now follow? I understood that SPV miners were ignored the validation step so they were building blocks on an invalid chain but what was the specific difference in block structure b/t v2 and v3?

v3 requires that all transactions use strict DER signatures. However, it is not bip66 that caused the problem, it is the fact that the 950 out 1000 block threshold had been passed and that a v2 block was found. The SPV miners did not validate that (I guess they didn't check the threshold or version) and began mining on this now invalid block.

tspacepilot

legendary

Activity: 1456

Merit: 1081

I may write code in exchange for bitcoins.

What was the new rule from BIP66 that v3 blocks now follow? I understood that SPV miners were ignored the validation step so they were building blocks on an invalid chain but what was the specific difference in block structure b/t v2 and v3?

RealBitcoin

hero member

Activity: 854

Merit: 1009

JAYCE DESIGNS - http://bit.ly/1tmgIwK

Isnt this causing a systematic problem. I mean if the pool this error originated from now gains less trust, and the miners leave the pool due to lack of trust.

Now the pool can go bankrupt, and the other pools consolidate. Isnt this increase the risk of 51% attack? I think this is the main concern mostly.

As if the mining pools get sabogaged by these things, it can become very easy for 1 pool to gain monopoly and then face 51% attack?

redsn0w

legendary

Activity: 1778

Merit: 1043

#Free market

Quote from: shorena on July 05, 2015, 08:10:54 AM

Quote from: redsn0w on July 05, 2015, 07:55:06 AM

Quote from: bitnanigans on July 05, 2015, 07:49:57 AM

So what exactly was responsible for this error?

The miners, not all the miners but some of them....

To elaborate this a bit further:

My understanding of the situation is that some miners use a mining technique called SPV mining that relies on the assumption that the rest of the network produces valid blocks to mine a tiny bit faster. Those miners using SPV mining essentially have a few seconds advantage over those that completly verify the block first. What happend is that a big pool using said technique received an "invalid" block, a block version 2. These have recently been declared invalid as over 950 out of 1000 blocks mined are version 3. The pool tried to build the chain on top of the now invalid version 2 block, causing the fork. Because of the way bitcoin works we had two chains competing over which is the correct one. Those running nodes 0.10.x or 0.9.5 would not accept the invalid blocks and those following it, while other nodes would still accept them as valid and thus accept a different chain as the longest and currently valid chain. This resulted in wasted hash power for the miners and confusion as different services and wallets that rely on bitcoin core in the background showed different information / statuses depending on the version of bitcoin core running in said background.

Disclaimer: this attempt of a tl;dr version might be flawed, please correct me if you find any.

maybe... I didn't follow the whole situation.

Quote from: monbux on July 05, 2015, 08:33:18 AM

I'm not very technologically advanced myself when it comes to the blockchain, so I am wondering, how does this affect wallets like the trezor and its webwallet?

it affected the bitcoin blockchain, the various wallets 'validate' the blockchain....

monbux

legendary

Activity: 1736

Merit: 1029

I'm not very technologically advanced myself when it comes to the blockchain, so I am wondering, how does this affect wallets like the trezor and its webwallet?

Quickseller

copper member

Activity: 2996

Merit: 2371

Quote from: turvarya on July 05, 2015, 04:05:34 AM

Quote from: Quickseller on July 05, 2015, 01:54:01 AM

Quote from: ?? on ??

Quote from: Quickseller on July 04, 2015, 08:55:21 PM

Quote from: Colonel Crouton on July 04, 2015, 08:22:28 PM

How do we know if electrum and mycelium servers have been updated?

Some SPV servers were relying on 0.10.x so they were unaffected by the issue, and others were not and were effected. My personal experience with electrum on this incident is that I had a transaction that was sent to me that was showing as unconfirmed for a long time, then all of a sudden it had in excess of 6 confirmations. I am not sure what exact conclusions that I can draw from this except that the particular electrum server that I was connected to at the time was not relying on core 0.10.x as of prior to this indecent.

I also believe that by default, the electrum server that you connect to is random, so it is hard to make the determination if your server is running a "good" version of core or not.

My personal solution is to start a full node, and once the blockchain is downloaded, to run an electrum server that relies on the most recent version of Bitcoin core

The Electrum clients connect to Electrum Servers at random. However, if you have a favorite you can also default to it. I do. I personally like electrum.dragonzone.net and electrum.drollette.com. Why? They are always present, and they maintain a limit of 10 000 UTXOs (UTXO = Unspent Transactions Outputs)- which implies they are serious about being reliable Electrum-Servers (requires more computing power, memory and bandwidth to maintain a 10 000 limit, compared to a 100 limit).

Electrum-Servers are operating on pure voluntarily will - they have no incentives to do so. Higher limits show how committed they are to the SPV Electrum cause. Please support them by sending them a donation (their BTC donation addresses are usually listed in the console tab). You can select your favorite server by clicking on the Green dot (bottom right) of your Electrum window - uncheck the automatic selection, and select your favorite server.

Electrum-Servers also have to operate a full Bitcoin-core node - it would be great if they would advertise in their console msg the Bitcoin-core version they are using!

If you have a Trezor, SatoshiLabs already indicated that their backend node was already updated to the latest version 0.10.2 if you are using their mytrezor.com Chrome interface - see here

Like I said, I am in the process of starting my own electrum server that I know I can personally trust. As of now, I am in the process of downloading the blockchain for my full node, and some level of research needs to be done before I can create my electrum server that relies on my full node (I had found a thread advising how to create an electrum server, however it seems that it either contains some mistake or I am doing something wrong - I am very much a newbie when it comes to linux/ubuntu, so it could easily be either one).

I wonder, if other user think the same as you, and if so, the amount of full nodes will raise in the next days.

In my experience, a lot of bitcoin users are not very technologically advanced. There are a good number of people who cannot sign a message when requested without being explained how to do so. There are a good number of people who use coinbase as a bank and that keep massive amounts of money on web wallets like blockchain.info.

Bitcoin users want to be able to spend (and receive) bitcoin with ease, and without large amounts of effort on their part, and rightfully so. It probably took me a good two hours to shop around for a cheap VPS, find one I thought was good (including cost efficient), figure out how to use ubuntu and get core installed. Plus I am spending my own money for my node, and seriously doubt that I will be able to monetize it, or be able to receive enough "donations" to cover it's costs.

Mac Gates15

newbie

Activity: 3

Merit: 0

Quote from: Sakarias-Corporation on July 04, 2015, 12:29:35 PM

How long until we only need to wait for 1-6 Confirmations instead of 30 ? (i'm using a Trezor)

until problem with major pools like p2pool and antpool solved and they start mining on correct blockchain
and another duplicate blockchain issue fixed, if you are using latest versions then it shouldn't have any problem, as they have inbuilt header verification in code

shorena

copper member

Activity: 1498

Merit: 1528

No I dont escrow anymore.

Quote from: redsn0w on July 05, 2015, 07:55:06 AM

Quote from: bitnanigans on July 05, 2015, 07:49:57 AM

So what exactly was responsible for this error?

The miners, not all the miners but some of them....

To elaborate this a bit further:

My understanding of the situation is that some miners use a mining technique called SPV mining that relies on the assumption that the rest of the network produces valid blocks to mine a tiny bit faster. Those miners using SPV mining essentially have a few seconds advantage over those that completly verify the block first. What happend is that a big pool using said technique received an "invalid" block, a block version 2. These have recently been declared invalid as over 950 out of 1000 blocks mined are version 3. The pool tried to build the chain on top of the now invalid version 2 block, causing the fork. Because of the way bitcoin works we had two chains competing over which is the correct one. Those running nodes 0.10.x or 0.9.5 would not accept the invalid blocks and those following it, while other nodes would still accept them as valid and thus accept a different chain as the longest and currently valid chain. This resulted in wasted hash power for the miners and confusion as different services and wallets that rely on bitcoin core in the background showed different information / statuses depending on the version of bitcoin core running in said background.

Disclaimer: this attempt of a tl;dr version might be flawed, please correct me if you find any.

notbatman

legendary

Activity: 2212

Merit: 1038

Quote from: jl2012 on July 05, 2015, 07:39:53 AM

Quote from: notbatman on July 05, 2015, 07:35:58 AM

Quote from: RealBitcoin on July 05, 2015, 07:20:30 AM

Quote from: turvarya on July 05, 2015, 04:05:34 AM

Quote from: Quickseller on July 05, 2015, 01:54:01 AM

Quote from: ?? on ??

Quote from: Quickseller on July 04, 2015, 08:55:21 PM

Quote from: Colonel Crouton on July 04, 2015, 08:22:28 PM

How do we know if electrum and mycelium servers have been updated?

Some SPV servers were relying on 0.10.x so they were unaffected by the issue, and others were not and were effected. My personal experience with electrum on this incident is that I had a transaction that was sent to me that was showing as unconfirmed for a long time, then all of a sudden it had in excess of 6 confirmations. I am not sure what exact conclusions that I can draw from this except that the particular electrum server that I was connected to at the time was not relying on core 0.10.x as of prior to this indecent.

I also believe that by default, the electrum server that you connect to is random, so it is hard to make the determination if your server is running a "good" version of core or not.

My personal solution is to start a full node, and once the blockchain is downloaded, to run an electrum server that relies on the most recent version of Bitcoin core

The Electrum clients connect to Electrum Servers at random. However, if you have a favorite you can also default to it. I do. I personally like electrum.dragonzone.net and electrum.drollette.com. Why? They are always present, and they maintain a limit of 10 000 UTXOs (UTXO = Unspent Transactions Outputs)- which implies they are serious about being reliable Electrum-Servers (requires more computing power, memory and bandwidth to maintain a 10 000 limit, compared to a 100 limit).

Electrum-Servers are operating on pure voluntarily will - they have no incentives to do so. Higher limits show how committed they are to the SPV Electrum cause. Please support them by sending them a donation (their BTC donation addresses are usually listed in the console tab). You can select your favorite server by clicking on the Green dot (bottom right) of your Electrum window - uncheck the automatic selection, and select your favorite server.

Electrum-Servers also have to operate a full Bitcoin-core node - it would be great if they would advertise in their console msg the Bitcoin-core version they are using!

If you have a Trezor, SatoshiLabs already indicated that their backend node was already updated to the latest version 0.10.2 if you are using their mytrezor.com Chrome interface - see here

Like I said, I am in the process of starting my own electrum server that I know I can personally trust. As of now, I am in the process of downloading the blockchain for my full node, and some level of research needs to be done before I can create my electrum server that relies on my full node (I had found a thread advising how to create an electrum server, however it seems that it either contains some mistake or I am doing something wrong - I am very much a newbie when it comes to linux/ubuntu, so it could easily be either one).

I wonder, if other user think the same as you, and if so, the amount of full nodes will raise in the next days.

Most likely not, my full node with armory and the core is over 100 GB, so its getting intolerably big.

We need reputable, quick acting (no bureocracy) full node people who store the blockchain.

So if a problem like this happens, they can respond in less than 1 day, and fix it. If blockhain.info already fixed their stuff, which is great, they are very quick and anti-bureocratic, i love that

I'm still seeing discrepancy of .06 btc, so I'm guessing blockchain.info is still working on fixing the database between June 16-23.

This thread is about the bitcoin blockchain, not technical support for blockchain.info wallet. By the way, it is not uncommon for bc.i to provide inaccurate info

I use blockchain.info as a block explorer as p2pool links directly to it.... their problem is most definitely related to the v2/v3 upgrade being discussed here.

redsn0w

legendary

Activity: 1778

Merit: 1043

#Free market

Quote from: bitnanigans on July 05, 2015, 07:49:57 AM

So what exactly was responsible for this error?

The miners, not all the miners but some of them....

bitnanigans

sr. member

Activity: 266

Merit: 250

So what exactly was responsible for this error?

Topic: Blockchain split of 4 July 2015 - page 11. (Read 45630 times)