Blockchain split of 4 July 2015 - page 8.

tspacepilot

legendary

Activity: 1456

Merit: 1081

I may write code in exchange for bitcoins.

Quote from: RealBitcoin on July 06, 2015, 08:54:50 AM

Quote from: avatar_kiyoshi on July 06, 2015, 08:52:43 AM

So for now is risky to make a transaction? Without use core wallet?
I used electrum wallet.

I think only incoming transactions are risky, because they can be double spent easily.

But outgoing transactions should be fine i guess

Some1 please confirm this!

I know the thread has been growing fast, but this has already been asked and answered, post 169:

Quote from: jl2012 on July 04, 2015, 08:10:30 AM

Quote from: LFC_Bitcoin on July 04, 2015, 08:01:51 AM

So this will only potentially effect people who are making transaction, sending & receiving coins atm?
If I'm a simple HODLER & haven't & won't be buying any coins this weekend I'm safe & ok yes?
Thanks in advance to anybody who responds.

Hodlers are unaffected

Payers, technically speaking, are unaffected, despite that your payees may require more confirmations than usual

Payees, with Bitcoin core 0.9.5 or above, are unaffected.

Payees, with anything else, please follow the instructions in the header of the forum

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: JorgeStolfi on July 05, 2015, 10:15:49 PM

In understand that clients don't need to update if a soft fork only makes the rules for blocks more restrictive. However, if it makes the rules for transactions more restrictive too, then the clients must update anyway, otherwise their transactions will be rejected (except by nodes and miners who are still running the old version, which may cause those transactions to be confirmed and then unconfirmed). isn't that so? Isn't that the case of BIP66?

This was considered by the developers when they wrote the BIP. Essentially, these transactions have been around since version 0.8.0 and this soft-fork simply makes said transactions a protocol rule.
From the BIP itself:

Quote

Compatibility

The requirement to have signatures that comply strictly with DER has been enforced as a relay policy by the reference client since v0.8.0, and very few transactions violating it are being added to the chain as of January 2015. In addition, every non-compliant signature can trivially be converted into a compliant one, so there is no loss of functionality by this requirement. This proposal has the added benefit of reducing transaction malleability (see BIP 62).

RealBitcoin

hero member

Activity: 854

Merit: 1009

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

Quote from: avatar_kiyoshi on July 06, 2015, 08:52:43 AM

So for now is risky to make a transaction? Without use core wallet?
I used electrum wallet.

I think only incoming transactions are risky, because they can be double spent easily.

But outgoing transactions should be fine i guess

Some1 please confirm this!

avatar_kiyoshi

legendary

Activity: 1106

Merit: 1000

So for now is risky to make a transaction? Without use core wallet?
I used electrum wallet.

drakoin

hero member

Activity: 826

Merit: 1000

see my profile

Quote from: drakoin on July 05, 2015, 05:03:50 AM

Is it conceivable to add a service network which announces "block XYZ was invalid"?

A service that miners could subscribe to;
or organize themselves, even on one of their machines only?

Could make sense if those instances are rare.

Then SPV miners start hashing with what they assume (but not check) is a valid block,
and when a few seconds later an "invalid block" alert is broadcast, they simply restart.

Possible? Wrong approach? Then sorry - I do not understand enough of this yet.

But the other thing ... miners deliberately mining empty blocks, that sounds ruthless, no?

No answer. So I am probably wrong?

What I was thinking is:
This "two-phases SPV / full" mining could give them their headstart
for the first seconds phase after they receive a block on top of which they want to build.

Then in "phase 2":
If this questionable block is really valid, they just continue.
If invalid, they immediately drop it, and restart.

Could that approach reduce the harm that SPV miners are causing?

RealBitcoin

hero member

Activity: 854

Merit: 1009

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

Quote from: RealBitcoin on July 05, 2015, 10:09:34 AM

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?

Does anyone have an answer to this? I am more worried of centralization than rather blockchain split Sad

Zeroxal

hero member

Activity: 896

Merit: 508

So basically, we should wait for the transactions to get a confirmation other than from Antpool or f2pool to safely get the bitcoins in the wallet?
If Antpool and/or f2pool finds blocks in a chain its not safe anymore? Did someone actually get a loss from this incident?

QuestionAuthority

legendary

Activity: 2156

Merit: 1393

You lead and I'll watch you walk away.

Quote from: JorgeStolfi on July 06, 2015, 08:22:42 AM

Quote from: QuestionAuthority on July 06, 2015, 07:58:43 AM

They were cheating the system. Bitcoin has one variable that can't be predicted - human behavior. The system will always be flawed as long as someone sees an advantage in doing the wrong thing. Bitcoin isn't a worldwide corporation but it's players must act as if it were. Independent global actors must each do their part correctly and for the good of the whole except all of them are motivated differently. The problem with a system controlled by no one and everyone is the old adage, what's best for me is what's best.

Sorry, that was not the idea. Players were supposed to behave in certain ways because of the economic incentives built into the protocol, not because of "the good of the whole". If players find that it is more advantageous to them to behave in ways that are bad for the system, that is a flaw of the protocol, not a fault of the players.

I agree with what your saying with the exception that I see the system as organic. The players are the system. Bitcoin can't function alone as some sort of AI. We are Bitcoin.

JorgeStolfi

hero member

Activity: 910

Merit: 1003

Quote from: QuestionAuthority on July 06, 2015, 07:58:43 AM

They were cheating the system. Bitcoin has one variable that can't be predicted - human behavior. The system will always be flawed as long as someone sees an advantage in doing the wrong thing. Bitcoin isn't a worldwide corporation but it's players must act as if it were. Independent global actors must each do their part correctly and for the good of the whole except all of them are motivated differently. The problem with a system controlled by no one and everyone is the old adage, what's best for me is what's best.

Sorry, that was not the idea. Players were supposed to behave in certain ways because of the economic incentives built into the protocol, not because of "the good of the whole". If players find that it is more advantageous to them to behave in ways that are bad for the system, that is a flaw of the protocol, not a fault of the players.

QuestionAuthority

legendary

Activity: 2156

Merit: 1393

You lead and I'll watch you walk away.

Quote from: S4VV4S on July 06, 2015, 08:01:38 AM

Quote from: newb4now on July 06, 2015, 03:48:40 AM

I have a hard time believing that F2pool and AntPool did this by accident.

However I also cant see their profit motive in this case since everyone knew what was happening.

It seems they just wasted time/money on the wrong chain with no benefit.

What am I missing?

It was an accident, or more like their speed "cheat" cost them a few thousands of dollars.
If it was intentional then there was going to be transactions included in the blocks they found.
And there were no transactions in their blocks.

See this thread: https://bitcointalksearch.org/topic/m.11790734

Quote from: macbook-air on July 04, 2015, 01:12:23 PM

Quote from: ?? on ??

Miners will very much be impacted by the incident. Maybe you pay for this time, but you cannot continue to cover such a large loss. What about confidence? Do you think people should have confidence to mine with F2pool and no shady actions will occur?

There is no impact on miners at all, and our PPS fee is very low if you consider all those merged coins we are giving out: 7 NMC/IXC/I0C is about 0.019 BTC or 1.9% of your earning. The loss is also trivial to us. Our Bitcoin reserve is more than 10000 BTC and we also have many altcoins.

Quote from: ?? on ??

I do mine with F2pool at times, currently as a backup, and I think we deserve to hear more about how this does not impact us.
Care to comment on 'SPV mining' explanations being provided by the bitcoin folks?
The short version is they state you and antpool caused most of this because you were not validating blocks.

Do you have a response, or is this the way you plan to run your pool in the future?

We will continue do SPV mining despite the incident, and I think so will AntPool and BTC China. We will do it more carefully in the future however. Today's incident was caused by one of AntPool's outdated bitcoinds. BTC China and us simply followed AntPool's block announcement, only they have worse luck, so they did not generate as many blocks as us.

Quote from: eleuthria on July 04, 2015, 02:26:26 PM

Quote from: macbook-air on July 04, 2015, 01:12:23 PM

We will continue do SPV mining despite the incident, and I think so will AntPool and BTC China.

Another very good reason people should not mine on Chinese pools. This is EXTREMELY bad for the Bitcoin network.

Amitabh S

legendary

Activity: 1001

Merit: 1005

Quote from: JorgeStolfi on July 06, 2015, 06:59:24 AM

Quote from: Amitabh S on July 06, 2015, 12:32:42 AM

On a different note, here's one proposed solution for SPV nodes that does not require us to wait for 30 confirmations. Please comment on its correctness.

Let us assume that an "invalid chain" cannot be more than 50 blocks.

Step 1. We boot our SPV node "now", several days after the July 4 fork.
Step 2. We receive the mth block, say b_m. We ensure that b_m is version 3 block.
Step 3. We need to ensure that at least 50 previous blocks before b_m were also correct. We download those blocks (not just the headers).
That is blocks b_{m-50}, b_{m-49}... b_{m-1}. Then we ensure that all were version 3, have correct signatures, etc, and correctly validate the next block (via the prevBlockHash).
Step 4. We can start counting b_m as a block of a valid chain if above checks pass.
Step 5. For any further received blocks, we follow steps 2, 4, 5 (skipping steps 1 and 3), since we have already validated 50 blocks before the "boot" block. Hence we validating only with block b_{m-1} is sufficient.

You are proposing is to modify the client so that it would do what a full node would do, only truncated to that last 50 nodes.

Just checking the version tag is not enough. This hacked client app must also know that the BIP66 rule became active at a certain block b_{n}. Otherwise it would have to keep fetching blocks until it finds a "95% majority" event, or reaches a block before the v3 software was published.

I agree, we need a timestamp. Version 3 started from orphaned block 363731 onwards. That block was generated at 2015-07-04 02:09:40.
which turns out to be 1435955980000 in Unix time.

We ensure that any block with timestamp greater than above is checked using the above logic with appropriate modification (example, v3 check in previous blocks stops at block 363730). This is still cheaper than running a full node.

I don't think we would need to hack bitcoinj because it gives us hooks (onBlock, etc) where we can add this logic.

Brangdon

sr. member

Activity: 365

Merit: 251

Quote from: SebastianJu on July 06, 2015, 04:58:13 AM

So does this mean we were 11% away from winning the wrong fork?

No. The invalid chain would never have been accepted by up to date full nodes, regardless of how long it got, because it was invalid.

Quote

What i dont understand... i can understand using SPV, but whats hindering the miner to mine on the new block and verify the actual block in the meanwhile.

It sounds like they had code to do that, but disabled it because of a bug, and never got around to re-enabling it.

S4VV4S

hero member

Activity: 1582

Merit: 502

Quote from: newb4now on July 06, 2015, 03:48:40 AM

I have a hard time believing that F2pool and AntPool did this by accident.

However I also cant see their profit motive in this case since everyone knew what was happening.

It seems they just wasted time/money on the wrong chain with no benefit.

What am I missing?

It was an accident, or more like their speed "cheat" cost them a few thousands of dollars.
If it was intentional then there was going to be transactions included in the blocks they found.
And there were no transactions in their blocks.

QuestionAuthority

legendary

Activity: 2156

Merit: 1393

You lead and I'll watch you walk away.

They were cheating the system. Bitcoin has one variable that can't be predicted - human behavior. The system will always be flawed as long as someone sees an advantage in doing the wrong thing. Bitcoin isn't a worldwide corporation but it's players must act as if it were. Independent global actors must each do their part correctly and for the good of the whole except all of them are motivated differently. The problem with a system controlled by no one and everyone is the old adage, what's best for me is what's best.

JorgeStolfi

hero member

Activity: 910

Merit: 1003

Quote from: newb4now on July 06, 2015, 03:48:40 AM

I have a hard time believing that F2pool and AntPool did this by accident.

However I also cant see their profit motive in this case since everyone knew what was happening.

It seems they just wasted time/money on the wrong chain with no benefit.

What am I missing?

According to this reddit comment, F2Pool did not even have the header of the invalid block B when they started mining on top of it. The big pools monitor the instructions that other pools send to their members, to catch the hash of a recently mined block even before that block gets to the relay nodes. They just did not notice (or had no way of knowing) that the hash came from a pool in the 5% that was still running v2, and therefore was likely to be invalid.

JorgeStolfi

hero member

Activity: 910

Merit: 1003

Quote from: Amitabh S on July 06, 2015, 12:32:42 AM

On a different note, here's one proposed solution for SPV nodes that does not require us to wait for 30 confirmations. Please comment on its correctness.

Let us assume that an "invalid chain" cannot be more than 50 blocks.

Step 1. We boot our SPV node "now", several days after the July 4 fork.
Step 2. We receive the mth block, say b_m. We ensure that b_m is version 3 block.
Step 3. We need to ensure that at least 50 previous blocks before b_m were also correct. We download those blocks (not just the headers).
That is blocks b_{m-50}, b_{m-49}... b_{m-1}. Then we ensure that all were version 3, have correct signatures, etc, and correctly validate the next block (via the prevBlockHash).
Step 4. We can start counting b_m as a block of a valid chain if above checks pass.
Step 5. For any further received blocks, we follow steps 2, 4, 5 (skipping steps 1 and 3), since we have already validated 50 blocks before the "boot" block. Hence we validating only with block b_{m-1} is sufficient.

You are proposing is to modify the client so that it would do what a full node would do, only truncated to that last 50 nodes.

Just checking the version tag is not enough. This hacked client app must also know that the BIP66 rule became active at a certain block b_{n}. Otherwise it would have to keep fetching blocks until it finds a "95% majority" event, or reaches a block before the v3 software was published.

SebastianJu

legendary

Activity: 2674

Merit: 1083

Legendary Escrow Service - Tip Jar in Profile

So does this mean we were 11% away from winning the wrong fork? Thats actually some feary news that could be created out of it.

What i dont understand... i can understand using SPV, but whats hindering the miner to mine on the new block and verify the actual block in the meanwhile. Only the miners are time sensitive, the computer controlling it most probably has spare cpu time. They could have saved quite some damage.

I think they wont disable SPV but at least implement a fix that verifies the blocks later.

thebigtalk

sr. member

Activity: 350

Merit: 250

Bitcoin and co.

I'm experiencing delays when this happened. Good thing the transactions went through. Although Ive seen the notice, I still continued with the cash out and didn't wait for things to go back to normal. Now I learned my lesson and wouldn't proceed when this thing happens again.

DooMAD

legendary

Activity: 3934

Merit: 3190

Leave no FUD unchallenged

Quote from: newb4now on July 06, 2015, 03:48:40 AM

I have a hard time believing that F2pool and AntPool did this by accident.

However I also cant see their profit motive in this case since everyone knew what was happening.

It seems they just wasted time/money on the wrong chain with no benefit.

What am I missing?

Deliberate actions can lead to an accident, which is what happened here. It's like knowing the route to get somewhere, but making a decision to take a shortcut and then getting hopelessly lost as a result. Their intention was to cut corners by only doing part of the job they're supposed to be doing. As a result they went heading off in the wrong direction and paid the consequences. If they had done their job properly, they wouldn't have got "lost".

Quote from: ?? on ??

If blockchain.info had reported the correct blockchain all along, everyone would be laughing at those two Chinese pools who decided to (unsuccessfully) form their own version of the "blockchain" on the same day as the USA Independence celebrations... Priceless!

Blockchain.info are the ones I blame the most for this incident! They are the ones that created confusion within the community. They didn't do their job (again?). They have an official wallet and they are (were?) the source of blockchain statistics that people came to trust. They should have validated blocks for their users - they didn't. Didn't they also had a bug, a few months ago, on bitcoin addresses generation, related to entropy? bc.i should have insured that the correct blockchain (v3) was displayed on their stat page - not the (v2-based) fork - they knew better! (and if they didn't, they do now...)

I'd be a little more cautious about placing such trust in third parties. Saying that Blockchain.info have an "official" wallet is the same as saying that Gox had an "official" wallet because the community trusted them at one point. It's the same mistake people make with the traditional banking sector and we should be wary about repeating it here. At the end of the day, they're just a company and you have to decide whether to rely on them or not. Thankfully, there were enough users who noticed the problem because they weren't trusting a third party to provide the information for them. If everyone was relying on a third party, the mess could have been much worse.

Mayer Amschel

full member

Activity: 140

Merit: 100

So are we back to normal Huh

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