Blockchain split of 4 July 2015

[QuestionAuthority]

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.

[Zeroxal]

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?

[RealBitcoin]

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

[drakoin]

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?

[avatar_kiyoshi]

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

[RealBitcoin]

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!

[achow101]

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:

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).

[tspacepilot]

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:

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]

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?

Well such as service shouldn't have to exist. SPV Miners should be validating blocks that they receive while they are mining. The issue with these validations is what happens if they mined the block before they finish validating the previous?

[Friki Verax]

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.

Double-spending transactions won't work because transaction included in the blocks in question are invalid blocks and will be rejected in Bitcoin Core 0.10.x or 0.9.5 and Bitcoin Core <0.10.x switches to longer chain(main chain) which will also make those blocks useless. So the transaction you got earlier won't be there when those blocks are rejected. That's why, you should wait for ~30 confirmations or near to it for making sure the transaction you received is included in longer chain(main chain).

But outgoing transactions should be fine i guess

No, its not. Like in the above case, if your transaction is included in invalid block but not in valid block, your Bitcoins returns to your address when that chain or block is rejected. You will have to make sure your transaction gets enough confirmation.

Some1 please confirm this!

In other words, wait for more confirmations than usual.

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

[drakoin]

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 that approach reduce the harm that SPV miners are causing?

Well such as service shouldn't have to exist. SPV Miners should be validating blocks that they receive while they are mining.

Let us hope they do. A "should" is a "could" plus some ethics. *lol*

The "... validating blocks that they receive while they are ..." is exactly what I was suggesting, indeed.
And it would be enough to be done on only one of their thousands of machines.

The issue with these validations is what happens if they mined the block before they finish validating the previous?

I see a question mark there.

What were the blocktimes between those 6 invalid blocks?
And the last of those 6 blocks, how many seconds after the 1st invalid block was that?

[achow101]

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 that approach reduce the harm that SPV miners are causing?

Well such as service shouldn't have to exist. SPV Miners should be validating blocks that they receive while they are mining.

Let us hope they do. A "should" is a "could" plus some ethics. *lol*

The "... validating blocks that they receive while they are ..." is exactly what I was suggesting, indeed.

F2Pool apparently had stopped simultaneous validation after they lost an orphan race, but since the fork they have reimplemented the validation. That means that during the fork, they did not validate the incoming blocks at all.

The issue with these validations is what happens if they mined the block before they finish validating the previous?

I see a question mark there.

What were the blocktimes between those 6 invalid blocks?
And the last of those 6 blocks, how many seconds after the 1st invalid block was that?

I don't know the blocktimes. However, since F2Pool wasn't validating, those times don't matter. I guess we can assume that AntPool wasn't validating either or they had seen that F2Pool's chain was the longest, assumed it was the right one, and saw that F2Pool was creating valid v3 blocks.

The problem with simultaneous validation and a service alerting miners of invalid blocks is that there is nothing forcing miners to use the service or validate. The only way that they are forced to do any of these is if there are financial incentives.

[drakoin]

The only way that they are forced to do any of these is if there are financial incentives.

So it is truely great that they lost money in this.

[drakoin]

there is nothing forcing miners to use the service or validate.

add a PoV = Proof of Validation?

[RealBitcoin]

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

I know that this thread grows fast but please can some1 answer to my question, its really important. I am really concerned about mining pool consolidations. How big risk does this pose?

[jonald_fyookball]

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

I know that this thread grows fast but please can some1 answer to my question, its really important. I am really concerned about mining pool consolidations. How big risk does this pose?

The market has proven to be self correcting.  When GHash got 49%, action was taken, now
its down to 10% or something.  So if for some reason a pool died because it couldnt follow
proper procedures, yes other pools would grow, but if no single pool would get to 50% because
it wouldn't be in the miner's best interests to allow that to happen, at least for long.

[Friki Verax]

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

I know that this thread grows fast but please can some1 answer to my question, its really important. I am really concerned about mining pool consolidations. How big risk does this pose?

Almost all pools don't do this because they will loose their block rewards. So there is an incentive for miners to not to do this which will prevent >50% attack. Besides, miners moves their hash power to another pool if this happens like they did when Ghash.io had nearly 50% of total hash power. This is not a big concern unless if more pools start closing down.

[manselr]

I wonder why miners don't pay more attention to this. Im assuming they want the best for Bitcoin, so why can't they just predict this from happening and take action? I can't be that difficult to pay attention to the hashrate distribution.

[achow101]

I wonder why miners don't pay more attention to this. Im assuming they want the best for Bitcoin, so why can't they just predict this from happening and take action? I can't be that difficult to pay attention to the hashrate distribution.

That is a pretty bad assumption. You should assume that miners are in it for the money. Sure there are some miners that mine to help the network, but really, right now the largest miners exist because of the financial incentives. They do everything they can to make the most money, which includes cutting corners. And sometimes cutting corners has big risks and can cause problems for other people.

[dooglus]

So how can we correct the reward function?  Is there some key the miners can't possibly know, some test they cannot pass, unless they have REALLY checked the blocks?

Interesting question , perhaps by requiring some kind of checksum be calculated and inserted into the next block?

As I understand it, f2pool didn't even have a copy of the block they were mining on top of. All they had was the bare minimum needed to build on top of it. If validating a block produces a checksum that is needed to be included in the next block then whoever is giving them the details they need will just add that checksum to the list of details they provide. f2pool still won't have to validate anything.

I don't see a way of checking that the miners even have a copy of the parent block let alone checking that they have verified it without breaking compatibility with all existing mining hardware.