For some reason I didn't get my Westhash mining payout today? Was suppose to get it 3 hours ago and I check the trans IX and it says 0 confirmations in the last 3 hours. What is going on?
Topic: Blockchain split of 4 July 2015 - page 7. (Read 45589 times)
This is ridiculous. I think people are ignoring the fact that 30 confirmations is freakin 12 hours. What a coincidence right? So everyone was talking about forks last week, and now there are rogues and new chains being built.
People make stuff up, and then someone takes the hint and makes it reality. People are so oblivious to what's happening right under their noses.
People make stuff up, and then someone takes the hint and makes it reality. People are so oblivious to what's happening right under their noses.
Let's see if the miscreant pool operators are suitably punished for their incompetent and/or dishonest behavior. A suitable punishment would be for minors to remove sufficient hash power from these pools that they cease to be major players.
The market has proven to be self correcting. When GHash got 49%, action was taken, now
its down to 10% or something.
its down to 10% or something.
IIRC, GHash actually got more than 50%.
The community can be sure that they got down to 10% by turning off 80% of their equipment, all for the good of the community. They would never think of moving that equipment to other pools. [/sarcasm]
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?
If Antpool and/or f2pool finds blocks in a chain its not safe anymore? Did someone actually get a loss from this incident?
Some pools apparently monitor other pools and "steal" the hash of their last mined block even before the block has propagated to the relay nodes. Since they don't have the block, not even the header, they cannot validate it immediately as they start mining on top of it.
I have read that those two pools and also BTC-China use this trick. I don't know whether others do the same, but since it gives them several seconds of advantage in the race for the next block, we must assume that every miner will do it if they can. And the shortcut usually works; it failed this time only because of the version switch. Therefore, the miners will not stop doing that, in spite of having lost 9 block rewards altogether (half of which they would have lost anyway).
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.Everyone knows miners are in for the money, but if they don't act right, soon they could be mining a valueless coin because they fucked up, something no one here wants, not if you are a dev, not if you are a miner, and not if you are a regular user.
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.
This! Mannotkind is the biggest threat to the system. And so it will always be vulnerable.
I'm looking forward to the day when mining income is derived mostly from including transactions. Miners/pools who create empty blocks on purpose are bad for the blockchain.
By creating problematic 0tx blocks (and reminding us that scaling Bitcoin isn't as simple as bloating a sanity-check constant), miners force the devs to invent better solutions. Et voilà, anti-fragile!
Well put. I love anti-fragile technology.
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.
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.
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.
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?
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.
legendary
Activity: 1302
Merit: 1004
Core dev leaves me neg feedback #abuse #political
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?
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.
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?
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?
there is nothing forcing miners to use the service or validate.
add a PoV = Proof of Validation?
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.
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?
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?
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.
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?
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.
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?
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?
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?
So for now is risky to make a transaction? Without use core wallet?
I used electrum 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 -
Payers, technically speaking, are unaffected, despite that your payees may require more confirmations than usual
- snip -
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?
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?
Jump to: