Pages:
Author

Topic: ghash.io is becoming SHOCKINGLY AGGRESSIVE NOW, closing in 45% - page 4. (Read 65472 times)

STT
legendary
Activity: 4088
Merit: 1452
You could ask btcguild to set their fees to near 0%   since he puts up fees when its too popular, now might be a good time to do the opposite.

Or any pool could offer to do that, might help some
legendary
Activity: 2576
Merit: 1186
There isn't a problem with solo mining nor GBT here.
The entity which controls the hardware has control of it period.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
it's still an interesting theoretical misuse of the protocol which was lauded for its ability to prevent this.
Nah. They control the equipment, so at any instant they could be using the same hashpower to solo mine it with the same effect. It's absolutely equivalent in terms of ability to double spend an unconfirmed transaction. (And highlights that cex.io having physical control of the hashpower is actually the root concern, not what 'pool' their hashpower was showing up on 12 hours ago).

If you step back and think about it, you'll realize the argument there is somewhat incoherent. Basically you're saying GBT gives the actual miner control of what their hashpower does and so perhaps they could misuse it. But since the hashpower is physically in their hands— they already have that control going forward no matter what.
Lulz - since solo mining has the same problem that's OK for GBT to have the problem?

OK you really need to learn how to argue.
Quote
It's also the case that GBT itself is sort of neutral on the question of miner control, with stratum a pool couldn't implement miners choosing their own transactions, with GBT they could allow it or not (and at the moment, I don't think that any centralized GBT using pools actually allow it: it complicates pooling for the transaction fees). Even not allowing the mutation at least the miner can be aware of what they're being asked to mine, though thats sort of useless without smarter miner software that does something useful with that knoweldge.
Ah, so you are saying that GBT isn't implemented fully anywhere so all these arguments by you and  your boss Luke-Jr about how GBT is the way to mine now, are crap.
It's slow, network data intensive (compared to stratum) and doesn't provide transaction selection (a so called advantage) with any miners or on any pool anywhere.

Sigh - nothing new.
legendary
Activity: 1223
Merit: 1006
Nah. They control the equipment, so at any instant they could be using the same hashpower to solo mine it with the same effect. It's absolutely equivalent in terms of ability to double spend an unconfirmed transaction. (And highlights that cex.io having physical control of the hashpower is actually the root concern, not what 'pool' their hashpower was showing up on 12 hours ago).

If you step back and think about it, you'll realize the argument there is somewhat incoherent. Basically you're saying GBT gives the actual miner control of what their hashpower does and so perhaps they could misuse it. But since the hashpower is physically in their hands— they already have that control going forward no matter what.

It's also the case that GBT itself is sort of neutral on the question of miner control, with stratum a pool couldn't implement miners choosing their own transactions, with GBT they could allow it or not (and at the moment, I don't think that any centralized GBT using pools actually allow it: it complicates pooling for the transaction fees). Even not allowing the mutation at least the miner can be aware of what they're being asked to mine, though thats sort of useless without smarter miner software that does something useful with that knoweldge.

All of this ^ plus I will note that currently Eligius does not allow transactions to be changed with GBT.  The goal currently is to provide a method of transparency to those who desire it.

A point of clarification of gmaxwell's post is that even if the pool allowed a miner to mine their own transactions via GBT, the pool itself does not change what other miners on the pool are mining based on what other miners would be trying to mine.  So any miner mining unique transactions (double spends or not) would essentially be trying to solo mine them which has the same effect with or without the pool.  (It was implied but I'm not sure that was clear in the above post.)

-wk

Edit: Side note: I have no knowledge of Ghash.io utilizing Eligius in any way currently.
staff
Activity: 4284
Merit: 8808
it's still an interesting theoretical misuse of the protocol which was lauded for its ability to prevent this.
Nah. They control the equipment, so at any instant they could be using the same hashpower to solo mine it with the same effect. It's absolutely equivalent in terms of ability to double spend an unconfirmed transaction. (And highlights that cex.io having physical control of the hashpower is actually the root concern, not what 'pool' their hashpower was showing up on 12 hours ago).

If you step back and think about it, you'll realize the argument there is somewhat incoherent. Basically you're saying GBT gives the actual miner control of what their hashpower does and so perhaps they could misuse it. But since the hashpower is physically in their hands— they already have that control going forward no matter what.

It's also the case that GBT itself is sort of neutral on the question of miner control, with stratum a pool couldn't implement miners choosing their own transactions, with GBT they could allow it or not (and at the moment, I don't think that any centralized GBT using pools actually allow it: it complicates pooling for the transaction fees). Even not allowing the mutation at least the miner can be aware of what they're being asked to mine, though thats sort of useless without smarter miner software that does something useful with that knoweldge.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Of course if they were mining with stratum to another pool they wouldn't be able to do that - only with GBT can the miner do double spends and 51% Tongue
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
I just looked and it seems GHASH is around 31% now, and as a result eligius went from 11% to 17% almost overnight
Maybe ghash is mining for eligius now.
The thought had crossed my mind and in fact the ultimate irony is that if they're mining on eligius with the GBT protocol and choosing their own transactions, then GBT would actually be giving them a way to still perform their 51% attack while using eligius as the unwitting proxy for their actions. A very vigilant pool op would pick this up but it's still an interesting theoretical misuse of the protocol which was lauded for its ability to prevent this.
full member
Activity: 120
Merit: 100
Maybe ghash is mining for eligius now.
legendary
Activity: 2128
Merit: 1005
ASIC Wannabe
I just looked and it seems GHASH is around 31% now, and as a result eligius went from 11% to 17% almost overnight
newbie
Activity: 56
Merit: 0
Call Winklevii and ask them to buy a chunk of miners at ghash.io Grin

I hope large bitcoin holders and investors are looking at security issues of bitcoin. They can do much in improving security of bitcoin and have a very good reason to do so.
legendary
Activity: 1750
Merit: 1007
For some reason, I thought that the miner itself could pick what transactions to include with a local bitcoind. I've got a pretty good understanding of bitcoin (see code in sig) but the merkle tree generating process still goes completely over my head. The wiki entry says something to that effect.

GBT can be used in that way for solo mining.  Actually, all pools use GBT to build their blocks.  But no pool implementation has been developed that allows miners to pick & choose transactions with GBT, mostly because it would require WAY too much bandwidth since miners would have to submit shares including the transactions used to build their share.

Every TX you include would be 64 bytes of data you have to send to the pool (since current GBT implementation communicates with ASCII, so 32-bytes represented as hex pairs = 64 bytes), plus a little more for markup.  The pool would then have to use a *lot* of extra CPU power to identify all those transactions in its own list and build the merkleroot to then validate your share.

If you go further, and allow miners to pick transactions from their local bitcoind, you need to send the entire raw block worth of data to the pool since the pool might not have the raw tx data for the transactions you're picking, preventing it from matching the data with just the transaction hashes.
legendary
Activity: 1260
Merit: 1000
Drunk Posts
GBT in itself as it's currently implemented and used gives you precisely zero protection.

Please explain? Huh
Mining on a pool via the GBT protocol (and virtually everyone mines on stratum) only means that your mining software gets the summary of all the transactions that are included when you're mining. This is also why stratum was more popular because it uses a lot less bandwidth. However, as a miner, are you personally monitoring all those transactions and watching exactly what they're doing and making sure they're not doing a 51% attack? Do you have the tools and know how to investigate them in real time? Also if you're not actually mining on ghash.io then you're not even looking at what transactions they're including.

For it to protect you, you'd have to be mining there with the gbt protocol and investigate the transactions in real time, notice the transaction differences from what's going on in the bitcoin network at large, and then somehow inform the world that it was going on and then manage to convince the other 5PH of miners to stop mining there.

For some reason, I thought that the miner itself could pick what transactions to include with a local bitcoind. I've got a pretty good understanding of bitcoin (see code in sig) but the merkle tree generating process still goes completely over my head. The wiki entry says something to that effect.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
GBT in itself as it's currently implemented and used gives you precisely zero protection.

Please explain? Huh
Mining on a pool via the GBT protocol (and virtually everyone mines on stratum) only means that your mining software gets the summary of all the transactions that are included when you're mining. This is also why stratum was more popular because it uses a lot less bandwidth. However, as a miner, are you personally monitoring all those transactions and watching exactly what they're doing and making sure they're not doing a 51% attack? Do you have the tools and know how to investigate them in real time? Also if you're not actually mining on ghash.io then you're not even looking at what transactions they're including.

For it to protect you, you'd have to be mining there with the gbt protocol and investigate the transactions in real time, notice the transaction differences from what's going on in the bitcoin network at large, and then somehow inform the world that it was going on and then manage to convince the other 5PH of miners to stop mining there.
legendary
Activity: 1260
Merit: 1000
Drunk Posts
I know I'm jumping in on this halfway and I'm going to get caught up ASAP, but all morning I've been wondering the same thing... What have the OTHER pools been doing to make it more attractive for miners to leave GHash.io? Why are all the efforts focused on getting people to leave?

eligius has 0% fees, a simple structure, NMC merged mining, and also shared the tx fees. I moved 600Gh there already

Don't forget GBT, so even with 51% they couldn't attack the network.

Although the raspi on my bitfury can't seem to handle it Sad
GBT in itself as it's currently implemented and used gives you precisely zero protection.

Please explain? Huh
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
I know I'm jumping in on this halfway and I'm going to get caught up ASAP, but all morning I've been wondering the same thing... What have the OTHER pools been doing to make it more attractive for miners to leave GHash.io? Why are all the efforts focused on getting people to leave?

eligius has 0% fees, a simple structure, NMC merged mining, and also shared the tx fees. I moved 600Gh there already

Don't forget GBT, so even with 51% they couldn't attack the network.

Although the raspi on my bitfury can't seem to handle it Sad
GBT in itself as it's currently implemented and used gives you precisely zero protection.
sr. member
Activity: 280
Merit: 250
Unless this is resolved in a better way, it removes much of the value of project bitcoin.

Agreed.  Any currency which relies on well-behaved market participants is doomed.  The protocol must enforce good behavior.
newbie
Activity: 42
Merit: 0
They released a statement here: https://ghash.io/ghashio_press_release.pdf
If they do indeed start allowing CEX.IO users to choose their own pool that will greatly improve the situation.

If cex.io users can "choose their own pool", then ghash.io may drop to, say, 20% of the hashing power.  Leaving them *actually in control* of more than 51%... but with no clear way to track it.

Couldn't a malicious cex.io employee execute a 51% attack by:

  - switching everyone over to "bad pool X"
  - double spending like crazy to line some wallets
  - confirming it
  - switching everyone back


legendary
Activity: 1750
Merit: 1007
Per the PR ..

~45% of GHash.IO hashing power is BitFury ASIC based miners ..
~55% of GHash.IO hashing power is independent miners ..

So, the problematic bit is the 45% of hashing power in the "cloud mining"  product ??
Because that hashing power is under the direct control of CEX.IO/GHash.IO ??

Are we not individually; by either participating in the "cloud mining" product or as
members of the GHash.IO mining pool; causing the very network hashing share issue
you all are ( over ) reacting to ??

Triff ..

is the 45% bitfury just thier own private mining facility (which is bitfury based) or does it also include all the pool members with bitfury systems (which is what im hoping)

Im not sure how they would determine this though, besides looking at worker names (ie: username.Bitfury1 vs username.Avalon1 vs username.mydamnfineminingrig)

It's their private mining capacity.  It makes sense given their rise in hash rate compared to the overall network growth.  I had estimated last night in IRC that their private farm was in the 2 PH/s range since new mining capacity historically gets spread proportionally among pools (a pool with 20% network share gets ~20% of the hash rate from a company shipping a batch of miners), yet GHash.io's rate of growth was nearly double that of the rest of the network, which would mean ~50% of their hash rate was coming from their private farm.
legendary
Activity: 2128
Merit: 1005
ASIC Wannabe
Per the PR ..

~45% of GHash.IO hashing power is BitFury ASIC based miners ..
~55% of GHash.IO hashing power is independent miners ..

So, the problematic bit is the 45% of hashing power in the "cloud mining"  product ??
Because that hashing power is under the direct control of CEX.IO/GHash.IO ??

Are we not individually; by either participating in the "cloud mining" product or as
members of the GHash.IO mining pool; causing the very network hashing share issue
you all are ( over ) reacting to ??

Triff ..

is the 45% bitfury just thier own private mining facility (which is bitfury based) or does it also include all the pool members with bitfury systems (which is what im hoping)

Im not sure how they would determine this though, besides looking at worker names (ie: username.Bitfury1 vs username.Avalon1 vs username.mydamnfineminingrig)
Pages:
Jump to: