SPV Mining and how to slow it down ... if you care to ...

[kano]

Well, I run a pool as some people know
I've also been involved in bitcoin for a little while (since July-2011)
and I also write some code here and there.

Anyway, yeah I do have some interest in BTC and I'm not really fond of those who do things that at least I think are bad for Bitcoin.
I've inferred same rather interesting information about SPV mining that may be of interest to any pools out there who also think it's bad for Bitcoin.

One of the details (though many probably already know this) are that: SPV pool simply run a miner to other pools that (what I'd call a 'dead pool miner') listen for block changes and uses that info to generate a new unverified empty block header and then distribute that to their pool's miners through their pool work distribution.

There are other methods that will produce the same result later, but that's the greatest speed up they can use for other pool's blocks.

If anyone has more information regarding these miners, feel free to post here.
I consider it quite appropriate to out these miners since they aren't even mining (when they 'dead pool mine' on my pool)

IP addresses:
120.55.119.224
123.57.173.63
106.187.94.193
192.155.84.181

They 'address mined' at my pool and were using the address:
https://www.blocktrail.com/BTC/address/1J1F3U7gHrCjsEsRimDJ3oYBiV24wA8FuV

They made it easy for me to determine this coz all 4 addresses were doing exactly the same thing to the same BTC address
The first 2 are inside the GFW the other 2 are outside

Edit: I updated the address as a link in case anyone didn't realise the significance

[1713536162]

1713536162

[1713536162]

1713536162

[1713536162]

1713536162

[1713536162]

1713536162

[macbook-air]

Well, I run a pool as some people know
I've also been involved in bitcoin for a little while (since July-2011)
and I also write some code here and there.

...

You have been moved to our blacklist. You will not see these IP addresses connecting to your pool and waste your pool resource anymore. Thanks.

[eleuthria]

Well, I run a pool as some people know
I've also been involved in bitcoin for a little while (since July-2011)
and I also write some code here and there.

...

You have been moved to our blacklist. You will not see these IP addresses connecting to your pool and waste your pool resource anymore. Thanks.

Fun to see the a pool that is _DOING THE WRONG THING AND HURTING THE NETWORK_ is "blacklisting" somebody.

[p3yot33at3r]

You have been moved to our blacklist. You will not see these IP addresses connecting to your pool and waste your pool resource anymore. Thanks.

So, is that an official f2pool stance - blacklisting any pool that actually contributes to the Bitcoin network?  

To make it easier, why don't you just make a whitelist of pools that SPV mine & use only them instead of leaching off every pool/node that cares & contributes towards the network? That way, you'd be doing us all a favor.

[PCComf]

@macbook-air
Do you mean that you'll intentionally not build on blocks from Kano.is? I think you need to clarify what you mean by blacklist.

[macbook-air]

@macbook-air
Do you mean that you'll intentionally not build on blocks from Kano.is? I think you need to clarify what you mean by blacklist.

We will not build on his blocks until our local bitcoind got received and verified them in full. This guy leaked our IP addresses to the public, I pm him kindly and begged him to remove them but he refused. If we ever got DDoSed due to his post, we have no choices but point our domains to his pool.

[kano]

@macbook-air
Do you mean that you'll intentionally not build on blocks from Kano.is? I think you need to clarify what you mean by blacklist.

We will not build on his blocks until our local bitcoind got received and verified them in full. This guy leaked our IP addresses to the public, I pm him kindly and begged him to remove them but he refused. If we ever got DDoSed due to his post, we have no choices but point our domains to his pool.

Your welcome.
I have reasonable DDoS protection.
Funny you consider that your only option - clearly you have no idea how to deal with network problems

As stated above, they were the IP addresses of miners mining on my pool but withholding doing any work and using my pool to help SPV mine.
I obviously do not want miners doing that on my pool.
No one asked, (I would have denied it), thus the results.
Interesting that you consider them important, you use these IPs to SPV "dead pool mine" on competitors pools with important IP address?!? ...

You also said to me in PM, after I worked out what was going on, that it is to "reduce my orphan rates" and thus to my advantage to let you SPV dead pool mine on my pool ... ... ... ...
Edit: and said that I don't care about my customers who mine on my pool getting more orphans because it wont cost me since my pool isn't PPS ... ... ...

Clearly we have a different idea about the term "advantage" and what is good for Bitcoin.

While we are at it, I will also point out fake excuses spread by SPV mining pools:
One of the excuses given was because it is often slow to distribute blocks through the GFW, so they are at a disadvantage.
In a peer 2 peer network, if you divide the network with a line, the side of the line with clearly less power is at a disadvantage.
With the GFW, the side of the line inside the GFW has the higher network hash rate ... ... ...

[jacobmayes94]

You'd point your domains to HIS pool if your being DDoSed? Even if someone DDoSed the IP addresses?

You guys are quite a sizable pool, so why do you feel it right to mess with competing pools in that way? I think this should be stickied because one of the major pools trying to do this to smaller pools... Might convince some miners to jump ship who don't appreciate this sort of thing. I don't mean to be rude, but this has been handled very badly. Not trying to start a flame war, but to fiddle with competitors pools in that way and then threaten to divert any attack from your domain to their pool, doesn't that make you as bad as the DDoSer themselves? This is not what satoshi would have wanted at all, all mining pools and solo miners alike are in this together. Fiddle around with not building on blocks from certain pools (even though you are not doing that) for example is one way to risk the stability of bitcoin and then crash its value making the currency and your equipment worth less.

Just my two cents...

[p3yot33at3r]

@macbook-air
Do you mean that you'll intentionally not build on blocks from Kano.is? I think you need to clarify what you mean by blacklist.

We will not build on his blocks until our local bitcoind got received and verified them in full. This guy leaked our IP addresses to the public, I pm him kindly and begged him to remove them but he refused. If we ever got DDoSed due to his post, we have no choices but point our domains to his pool.

IP addresses are in the public domain, view-able by anyone - you can't "leak" something that is already public knowledge.

Threatening to divert any ddos attack to a different pool is completely & utterly wrong. It's immoral & disgraceful, you should be ashamed of yourselves - or is this a common tactic employed by SPV mining pools?

This is what happens when a pool that contributes nothing to the Bitcoin network gets too big, they resort to playground bully boy tactics & statements in the false belief that they are somehow invincible & can do as they please. If I were a pool operator I would have no problem banning IP addresses from all SPV mining pools from connecting to my node & encourage every other pool or wallet owner that cares about the Bitcoin ecosystem to do the same.

Thank you kano for helping to bring this to everyone's attention, the more people who realize the harm these large SPV mining pools do to the network - & the lengths that they will go to to damage any other pool that questions them - the better, safer & healthier the network will become.

Edit: Deleting posts from your own thread regarding this won't help either.

[JorgeStolfi]

The badly named "SPV mining" is not that bad for bitcoin.  In fact it is better than the alternative

• An empty block buries the earlier ones under a chunk of hashwork, and thus helps secure them against tampering, just as well as a non-empty one.
• You *want* other pools to do SPV mining on top of your blocks, to reduce *your* orphan rate.
• You *want* to do SPV mining yourself when you learn that someone else just mined a block B(N).  The alternatives are (a) keep mining your own version B'(N) of the same block, in the hope of solving it just a few seconds later and getting it accepted by the network in place of your rival's; or (b) keep your equipment idle, or turned off, while you wait to downlad and verify that full B(N).  In both cases you will be hurting yourself, your member miners, and ultimately the network (by wasting some of your hashpower).
• SPV mining is not particularly unsafe, because the pools have no interest in broadcasting bad blocks to their members.  The pools who do SPV mining are making a calculated bet, based on the trust that their peers deserve, and will be punished if they trust a parent that turns out to be invalid.  (The "Fork of July" that followed the activation of BIP66 was the fault of the Core devs, who tried to do a stealth change in the protocol and bungled it.)
• SPV mininng does not really reduce the capacity of the network. Rather, it is a consequence of the limited bandwidth available for block propagation.  If SPV mining was suppressed somehow, instead of empty blocks there would be longer interblock delays and/or a reduction of the effective total hashpower compared to the total available hashpower. The empty blocks are just an embarrassing symptom of the limited capacity

Think of the miners as producers of a continuous stream of hashwork, like toothpaste squeezed out of a tube -- the blockchain -- with transactions being secured by being embedded in that stream.  Empty blocks are a length of that stream  that gets appended to the blockchain with no transactions embedded in it. If SPV mining were suppressed, in an attempt to fit more transactions in the stream, one would simply get a reduced hashwork output (because of longer block waits and/or lower difficulty setting).  So the max transactions *per unit of hashwork added to the blockchain* would be the same.

SPV mining could be suppressed by a protocol change, if desired: make the Merkle link (block hash) from block B(N) to B(N-1) depend on the contents of both blocks, instead of being just the hash of B(N-1); in such a way that the link cannot be computed by the miner that sets out to mine B(N) without knowing the full contents of B(N-1).  But that would probably not increase the effective capacity of the network, as said above.

[bctmke]

@macbook-air
Do you mean that you'll intentionally not build on blocks from Kano.is? I think you need to clarify what you mean by blacklist.

We will not build on his blocks until our local bitcoind got received and verified them in full. This guy leaked our IP addresses to the public, I pm him kindly and begged him to remove them but he refused. If we ever got DDoSed due to his post, we have no choices but point our domains to his pool.

Whoa

[Nuttycoins]

@macbook-air
Do you mean that you'll intentionally not build on blocks from Kano.is? I think you need to clarify what you mean by blacklist.

We will not build on his blocks until our local bitcoind got received and verified them in full. This guy leaked our IP addresses to the public, I pm him kindly and begged him to remove them but he refused. If we ever got DDoSed due to his post, we have no choices but point our domains to his pool.

WOW, you may hide behind Chinese hacking BS laws...  but that is clearly a blatant threat, and against US laws....      I would suggest forwarding it on to the appropriate authorities.

[worhiper_-_]

Well, I run a pool as some people know
I've also been involved in bitcoin for a little while (since July-2011)
and I also write some code here and there.

...

You have been moved to our blacklist. You will not see these IP addresses connecting to your pool and waste your pool resource anymore. Thanks.

Fun to see the a pool that is _DOING THE WRONG THING AND HURTING THE NETWORK_ is "blacklisting" somebody.

I hope the network will be able to recover from being this hurt. TBH I didn't even know it had feelings in the first place.

[-ck]

All false arguments from someone not actually involved in mining. We've proven that we can do block changes about as quickly as the spv mining pools yet with fully validated blocks and transactions. The SPV mining pools caused a fork they built on for a few blocks earlier this year due to mining on unvalidated block headers from other pools and more than one pool kept on bouncing broken blocks between themselves before finally having to wind back to the correct blockchain. If that's not wasted hashrate i don't know what is. With the size of the pools in question (>50% of the network combined), it could have gone on indefinitely had they not noticed.

[p3yot33at3r]

All false arguments from someone not actually involved in mining. We've proven that we can do block changes about as quickly as the spv mining pools yet with fully validated blocks and transactions. The SPV mining pools caused a fork they built on for a few blocks earlier this year due to mining on unvalidated block headers from other pools and more than one pool kept on bouncing broken blocks between themselves before finally having to wind back to the correct blockchain. If that's not wasted hashrate i don't know what is. With the size of the pools in question (>50% of the network combined), it could have gone on indefinitely had they not noticed.

I deliberately held off replying to his post as I not only didn't know if he was a miner or not, but also in the hope that someone who is more knowledgeable than me in the field would chime in.....and you did - thank you 

[RealMalatesta]

... This guy leaked our IP addresses to the public ...

Sorry, but you sound like a little kid. Actually, all of the IPs were publicly known and everybody who was interested to kno was able to link these IPs to your pool.

All that happened was that Kano found you with the hand in the cookie jar. So stop whining.

[kano]

The badly named "SPV mining" is not that bad for bitcoin.  In fact it is better than the alternative
...

Just thought I'd quote that in case he decides to delete it

Wow ...

--

Bitcoin devs dislike me coz I'm too coarse in my criticism of them, but I will say I don't know of any bitcoin dev who would agree with that statement and disagree with me on this one.

Seriously, get someone of any knowledge and reputation in the bitcoin world to come here and post agreement with your statement.

I'd wonder if you could find anyone.

I had someone ask me about this in PM

I'll post my reply to him (obviously not include his question with this name) so that anyone wondering about what I think is wrong with SPV mining understands my stance on the subject.

...
Mining off a block header (80 bytes) without checking the transactions at all (since they don't have the transactions yet or don't want to check them since that takes time)
That's the basics.

How they do that:
They run a miner that connects to other pools (and doesn't mine) and when the pool sends out a block change which includes the full header but not the transactions, they use that.

In my performance testing with antpool earlier in the year, I often got the block change for antpool blocks, on my miner at home, many seconds before the block was seen anywhere on the network.

The related issues are:

What checks are done on the block header? (other than ignoring checking the transactions)

Back when they screwed up, they weren't checking the block version number, so after the network switched to v3, their SPV mining mined on an 'invalid' v2 block someone produced (multiple times) and then they headed off on a fork that included the invalid v2 block while everyone else mined on the correct v3 fork that didn't include it
Since the SPV miners made up a large % of the network, this continued until they manually fixed the problem and moved off the invalid v2 fork.

If there are invalid transaction in a block, so everyone else rejects it, the same issue will occur.

It would seem (obvious) that they don't switch to the correct block when a new valid one arrives later that is fully verified

One of the bullshit early excuses given was that they are inside the GFW and it's slow to talk to the rest of the world so they need to be able to switch blocks faster.
The truth of that matter is that more than 50% of the bitcoin network is inside the GFW so it's no argument, since that already give them an advantage due to the GFW

and

...
The effect is only that they may mine on invalid blocks and cause network forks, since they don't fully check the blocks (as has happened already)

The problem is that somewhere from 40-60% of the network does SPV mine, so these forks can last for quite a while (one did) and this screws with anyone on the transaction side of the network, handling payments based on transaction confirmations

The other side effect is they are sending out empty blocks with their SPV block changes.

--

... and my last PM to f2pool in case anyone was wondering what I was saying about it:

...
It's very simple.

There are things I don't like and don't want to be a part of.
Yes I cannot and also do not wish to control Bitcoin - the point of Bitcoin is no central authority.

However, there are things I do not like and I've made very public and well known.
Two of the things are empty blocks and SPV mining (I consider one pretty much as bad as the other since SPV is also empty blocks)

The problem is that you involved my pool in your SPV mining without my consent
Your method was also to mine on my pool with miners that NEVER did any mining
I consider both of those things very inappropriate and have banned them already almost a day ago once I had worked out exactly what they were doing

If you had of asked me when you started dead mining on my pool, the answer would have been 'No' and that would have been the end of it

You did something that either: you knew I wouldn't want to know, or you are stupid, pick one.

Those IP addresses are there to warn others to either allow them if they like SPV or ban them if they are like me and do not want to allow you to use their resources to help you SPV mine and not ask for consent

[sloopy]

Well, I run a pool as some people know
I've also been involved in bitcoin for a little while (since July-2011)
and I also write some code here and there.

...

You have been moved to our blacklist. You will not see these IP addresses connecting to your pool and waste your pool resource anymore. Thanks.

@macbook-air
Do you mean that you'll intentionally not build on blocks from Kano.is? I think you need to clarify what you mean by blacklist.

We will not build on his blocks until our local bitcoind got received and verified them in full. This guy leaked our IP addresses to the public, I pm him kindly and begged him to remove them but he refused. If we ever got DDoSed due to his post, we have no choices but point our domains to his pool.

I knew you were a lowlife, but you have redefined the word lowlife. You threatening Kano is a threat to many people who will stand with Kano.
You have threatened too many people.

You think you are above the rest of us because you are involved with the group who run F2pool / discus fish.
You are not above anyone. You are equal to a scammer in my opinion and not only because you continue to put the bitcoin network in a precarious position with the decisions you make, because of your self-righteous attitude acting like a spoiled child.

It is easy for you to hide behind your keyboard and make threats now, but it will not always be so easy.
Your immaturity rules you, your temper has defined your way of thinking, and greed has completely muddled your sense of self-worth.

Greed will only be the motivation for mining at your pool for so much longer. When you begin to wonder why so many bad things begin to happen in your pool, your life, and your demented mind you only need to refresh this page for a reminder of why.

Kano exposed more of the evil actions and choices you make. Even though you are not alone in these choices you have squarely planted the X to your face. There is a core in this community who hold themselves and their peers to a higher standard of life choices. You should evaluate who your peers are and seek help from the core I speak of beginning with an apology for threatening Kano, the people who mine at his pool, and everyone who mines in the bitcoin network.  

Companies have been brought down for much less than what you have done and people for far less yet.

Edit:
Your threats are a shakedown aka extortion. It is the same as making someone pay you, or you attack them. This is akin to a mafia style way of doing business and that is not the way bitcoin should be represented. You, and anyone who continuously associates or mines with F2pool should be ashamed. You have no honor.

Edit #2:
None of us fear your threats.

[JorgeStolfi]

We've proven that we can do block changes about as quickly as the spv mining pools yet with fully validated blocks and transactions.

Surely the SPV mining pools will want to do that, then, if it works.  If it is in their interest to do so...

The bitcoin protocol was meant to work if each miner did whatever was more profitable for him.  If it is necessary for the miners to be "good citizens", then the protocol has faied.  In this case, I do not think it has: empty blocks are not a problem, just a normal consequence of other problems (such as limited bandwidth and excessive block reward).

The SPV mining pools caused a fork they built on for a few blocks earlier this year due to mining on unvalidated block headers from other pools and more than one pool kept on bouncing broken blocks between themselves before finally having to wind back to the correct blockchain. If that's not wasted hashrate i don't know what is. With the size of the pools in question (>50% of the network combined), it could have gone on indefinitely had they not noticed.

I insist, it was not their fault, but the fault of the devs who programmed BIP66 to be enabled immediately when 95% of the miners had updated, with no grace period -- thus ensuring that 5% of the hashpower would still be using the wrong rules at the fork time, no matter how quickly they tried to update. 

That 5% of the hashpower would have been wasted anyway, even if the SPV miners had not mined empty blocks on top of that bad one.

someone not actually involved in mining

One does not need to play football to know exactly where the coach went wrong. 

[-ck]

I was going to formulate a meaningful response to your response but your response is the most vacuous set of comments I've seen in a very long time so I shall leave this discussion as is and let others pass judgement or respond if they feel so obliged.