Pages:
Author

Topic: SPV Mining and how to slow it down ... if you care to ... - page 4. (Read 12859 times)

-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
In this case, where they know the previous block is valid b/c they mined it, why wouldn't they simply mine the next with tx's in it?  the reason these spv miners do what they do is b/c they don't want to waste time validating another pools just received block, which is not the case in this situation since it's their own.
It is both as can be seen when 2 blocks back to back come from an SPV pool and the 2nd block has zero txns. The reason is they've not gone to the effort to make the bitcoind validation process fast in their own nodes and they don't want to wait for bitcoind to validate the block (it takes time) before starting on their next block. For solo.ckpool.org and kano.is we run a customised bitcoind which speeds up the validation process dramatically, making this delay negligible.
legendary
Activity: 1764
Merit: 1002
... and for those less scrupulous than me, they might even consider sending bad/corrupt headers to the spv 'dead pool miners' since they aren't providing any mining results, that's not gonna affect their "shares" ... and see what havoc you can cause to their spv mining process Smiley
They may just have to resort to doing fully verified mining like everyone else Cheesy

what good would this do?  from what i hear they validate that the headers hash to the correct target to be a valid solution, no?
legendary
Activity: 1764
Merit: 1002
Forgive me if i'm wrong; but Antpool appears to be doing the same thing (found block, not submitting straight away,  mining on header of found block, submitting both in quick succession).. standard behaviour from them?
This is not quite correct. They are submitting it straight away as they have a lot to lose by not submitting it. It's just that they start mining on the header of a any pool's found block without verifying it's valid. As they're only mining on the header they are also unable to generate work with further transactions in it so they are always empty transaction blocks they're mining. In their next work update from the pool they are then working on verified blocks with transactions mined in. The effect you are seeing is that SPV mined blocks by design only ever occur within a short timespace of a previously solved block. The fact that it's often two blocks back to back by the same pool is purely because those pools are TOO FUCKING BIG and get lots of blocks.

in this case, where they know the previous block is valid b/c they mined it, why wouldn't they simply mine the next with tx's in it?  the reason these spv miners do what they do is b/c they don't want to waste time validating another pools just received block, which is not the case in this situation since it's their own.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Angry Just looked that KNC also does SPV Mining.

Is it just me who think it is like "steeling" the work of other Pools.
(I know it is not real steeling, but it feels like it)
It is not a verry social behavior.
 
They've generated empty transaction blocks. While SPV mined blocks always have empty transaction blocks, empty transaction blocks aren't always SPV mined. Either way it's a bad practice in its own way, but it doesn't necessarily mean they're SPV mining.
legendary
Activity: 2483
Merit: 1482
-> morgen, ist heute, schon gestern <-
 Angry Just looked that KNC also does SPV Mining.

Is it just me who think it is like "steeling" the work of other Pools.
(I know it is not real steeling, but it feels like it)
It is not a verry social behavior.
 
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Heh, someone pointed out a link to reddit where stolfi was still trying to blame the devs for the July fork there also and claim that SPV is OK.

Someone there even explained the point about the fact that only 1 miner with 0.001% of the network could have caused that fork any time after the 95% consensus was reached, even weeks after.
Doesn't matter adding 2 weeks delay.

When it happened, and for any period after that while the active SPV code at those big pools was unchanged, it only takes one single V2 block for SPV mining to create a > 50% fork of bitcoin.

I wonder how he explains that SPV mining isn't bad for bitcoin ... when a single block from a single tiny miner can > 50% fork the blockchain ...
Edit: and in case it wasn't obvious, that situation exists still today while those pools continue to SPV mine.

Clearly he has an agenda.
I'd suggest anyone reading what he says to check other more respected posts before taking any notice of what he says.
legendary
Activity: 2483
Merit: 1482
-> morgen, ist heute, schon gestern <-
Thank you Kano, as a non english native, it is hard to find out the meaning behind those shorts.

legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
legendary
Activity: 2483
Merit: 1482
-> morgen, ist heute, schon gestern <-
forgive me for asking that:
what stand S P V for?
The Subject is clear but not the words.

I.e. S Single P Pool V Verification ?
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
... and for those less scrupulous than me, they might even consider sending bad/corrupt headers to the spv 'dead pool miners' since they aren't providing any mining results, that's not gonna affect their "shares" ... and see what havoc you can cause to their spv mining process Smiley
They may just have to resort to doing fully verified mining like everyone else Cheesy
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
I didn't ask you to trust me Smiley
Please don't go near mining at my pool Smiley
P.S. read the thread title ... moron Smiley
copper member
Activity: 2996
Merit: 2374
I hope the OP realizes that it would be trivial for any SPV miner to simply direct a small amount of hashpower to your pool and listen for block changes the exact same way they were previously doing as described in the OP. It would also be trivial to use different addresses to mine on (have the payout sent to).

The only thing that the OP is doing is leaking private information that you have no business making public. If you are going to leak the IP address and payout address of someone you suspect to be SPV mining, then why should I (or anyone for that matter) trust that you will not leak my IP address and payout address if you think I am doing something that you do not like? If you are willing to leak this private information, then I do not see any reason why I should even trust you to payout my mining revenue when mining on your pool.

If you think that SPV mining is "bad' then I would suggest that you not engage in this practice. If you feel strongly about SPV mining then you can warn others about this practice and why it will result in them loosing so much mining revenue. It is not however any of your business as to what business practices that others engage in when you are not a party to a transaction.

If you seriously think that shaming a "evil" entity because they are doing something "bad" for Bitcoin is going to produce any results then you are naive. If someone wishes to harm Bitcoin and the Bitcoin network, and has the resources to do so, then they are not going to care that someone is shaming them.

If you think that SPV mining is as evil as you claim, then I would suggest proposing a BIP that prevents this practice. If SPV mining is as dangerous as you claim, then surely the entire network will quickly adopt a BIP that prevents SPV mining
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
The pools have good hardware and block propagation is indeed fast with the help of the centralised relay network and well coded full validation.

His interest is p2pool, so yeah that's a lot of everyday crappy servers.
However, p2pool solves the problem itself anyway due to effectively having it's own fast propagation network
(though the way he and others centralise p2pool reduces that advantage)
hero member
Activity: 692
Merit: 500
http://youtu.be/ivgxcEOyWNs?t=149m

Scaling Bitcoin presentation about GFWC and block propagation.
legendary
Activity: 4256
Merit: 8551
'The right to privacy matters'
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Forgive me if i'm wrong; but Antpool appears to be doing the same thing (found block, not submitting straight away,  mining on header of found block, submitting both in quick succession).. standard behaviour from them?
This is not quite correct. They are submitting it straight away as they have a lot to lose by not submitting it. It's just that they start mining on the header of a any pool's found block without verifying it's valid. As they're only mining on the header they are also unable to generate work with further transactions in it so they are always empty transaction blocks they're mining. In their next work update from the pool they are then working on verified blocks with transactions mined in. The effect you are seeing is that SPV mined blocks by design only ever occur within a short timespace of a previously solved block. The fact that it's often two blocks back to back by the same pool is purely because those pools are TOO FUCKING BIG and get lots of blocks.
hero member
Activity: 700
Merit: 501
https://bitcointalk.org/index.php?topic=905210.msg
Forgive me if i'm wrong; but Antpool appears to be doing the same thing (found block, not submitting straight away,  mining on header of found block, submitting both in quick succession).. standard behaviour from them?

Blocks 387005 and 387006..

Yup, it's standard behavior for pools that SPV mine I'm afraid, not just f2pool  Angry

Yes, this has been going on for far too long.

You have to ask yourself why it is hidden so well. It actually is not hidden at all, it is hidden in plain sight.

Our "coders" (and I say our because if you have a single satoshi then you have a stake), our "coders" of bitcoin core are scared of those pools. If they rock the boat they may have to deal with something sooner rather than much later. Look at the blocksize debate. Regardless of which side of the isle you are on it was a fixed match from the beginning with ALL of the core "coders" including Hearn and Gavin looking to what the 60% controlled by China's "elite" pools had to say.

I haven't been concerned about a 51% attack. That is too degenerative to our economy and would hurt "them". "Them" meaning the pools coordinating the control of bitcoin. They want far more than such. They want to tell us what the price will be, what coins we mine, when we mine them, and what percentage we receive. They want and are dictating the core code in front of our faces.

Bitcoin is mine, yours, and each person's individually. No different than a revolution in a country except this is the world financial revolution which has the opportunity to change the world's future for the better. We do not need this war on two fronts with internal fighting. Miners should unite by dissolving their presence into pools which adhere to appropriate mining protocols and pools who practice the ethics of what is good about bitcoin. Get away from the greed of centralization.

Surely anyone can see that those pools having the amount of hash they posses today cannot be good for the infrastructure.
If others see such and receive education from their peers many will care, and will act. Many will also ride greed and ignorance, but it is not something to take lightly.

At the rate they are growing we will see the China pool cartel dictate what bitcoin becomes through the decisions of a handful of people.
They already refuse to do things such as distribute the source of cgminer when they make changes which completely goes against the license to use it by the creator(s). How can anyone think that is anything but a conscious decision to give everyone the middle finger at any opportunity to continue protecting themselves?

macbook-air has openly stated and it is quoted here on the forum that there is no room for conversation regarding SPV mining. They will continue to do so regardless of what anyone thinks, regardless of the hard forks it has been PROVEN to cause.
This was literally stated by MANY community members AND if anyone cares to recall it was in giant red letters on the bitcoin.org front page which is when people were told they could not trust the normal amount of confirmations.

No, we cannot support them, it is that you must block them. The only way they will listen is if money leaves their pocket in a significant fashion.
full member
Activity: 157
Merit: 103
This guy leaked our IP addresses to the public, I pm him kindly and begged him to remove them but he refused.
Are you serious?! Any IP address is PUBLIC and nobody need to have any permit to post this info anywhere.
hero member
Activity: 700
Merit: 501
https://bitcointalk.org/index.php?topic=905210.msg
....

while i agree with much of what you say, i don't agree with it's sentiment.

there is no way in hell Bitcoin is going to be controlled by 3 Chinese mining pools stuck behind a GFC with shitty bandwidth and a Communist gvt.  the ROW has much more going for it and it's just a matter of time before the economic majority of Bitcoin holders will exert their influence to change this situation.  there is no room for bad attitudes and authoritarianism in what has now become a public good, ie, a new monetary system for the ppl.  bullshit like spv mining and 0 blocks won't be tolerated in the long run as they don't serve the system well.  

it's just a matter of time.

We cannot assume action will be taken in the face of a rising dictatorship.
We must inform.
We must go on the offensive.
We must lead, work with, and follow great community leaders with the agenda of making bitcoin what it should be.
We cannot sit back and allow miners to be uneducated regarding the issues which are well past at hand.
These are problems today where those "elite" should have previously stepped in.

Are we going to wait for our governments to save us from financial destruction as well?
I have not been. I work everyday for my own personal independence with more than a fair amount of time of that involving cryptocurrency and 99% of my crypto involvement is pure bitcoin.

Do not wait for our beloved Bbitcoin to be saved by an "elite" who are only poised to lose some control, save it yourself by whatever means possible.
sr. member
Activity: 266
Merit: 250
Forgive me if i'm wrong; but Antpool appears to be doing the same thing (found block, not submitting straight away,  mining on header of found block, submitting both in quick succession).. standard behaviour from them?

Blocks 387005 and 387006..

Yup, it's standard behavior for pools that SPV mine I'm afraid, not just f2pool  Angry
Pages:
Jump to: