BitcoinPool.com open thread

[grndzero]

That's not how it works.

Invalid blocks are a function of how far away (from an average node distance standpoint) the pool's bitcoind is from the rest of the bitcoin network. A high number of invalid block submissions implies that the bitcoind instance is relatively closer to an edge of the network than the center.

The pool is working on a block with a prevhash pointing to the previous found block. But if the pool's bitcoind doesn't have the latest information from the blockchain, then it will be working against the wrong prevhash. The further away the pool is from the center of the network, the longer it will take (on average) for the pool to get blockchain updates.

Ok, that makes sense.

How can you be closer of farther away to the center of a distributed p2p network if there's no central node to connect to? lol

If their client is too far from 'center' how could that be improved? Is there a polling time that can be increased or something?

[1714770999]

1714770999

[xenon481]

How can you be closer of farther away to the center of a distributed p2p network if there's no central node to connect to? lol

The "center" (there can actually be multiple centers if there are bottlenecks...) is the general area of the network that is most tightly connected with the highest number of other nodes. Think of it like The 6 Degrees of Kevin Bacon. There is actually a whole new area of math and networking theory that has grown around this. In the Kevin Bacon game, there are certain actors that have been in a LOT of movies (those nodes have a lot of connections to other nodes). This makes them very close (from a network distance standpoint) to Kevin Bacon and thus are centers of activity (hubs) for the game. But there are other people that may have only ever had one role in some really obscure movie. This person has very few connections and thus is on an edge. The more hops that it takes to get from any one node to a major hub is in general (there could be bottlenecks between hubs) the distance that needs to be surmounted in order to obtain updates.

If their client is too far from 'center' how could that be improved? Is there a polling time that can be increased or something?

There are known de-facto hub nodes running that you can try and get your node to connect to or close to. The next best thing (actually the best thing for the strength of the network) is to make sure that your (and the pool's) bitcoind node isn't behind a firewall and can connect to as many other nodes as possible. The more connections you have, the more likely that one of those connections will be close to a hub.

[FairUser]

Geebus hadn't found the issue yet when I posted about it.

But what Geebus found is also very interesting... Out of the last 50 blocks that the pool has found, 4 of them have been invalid.

That's an 8% invalid rate over the past 50 blocks! 

In the mean time (during basically the same time period), Slush's pool has only had 2 invalid blocks out of the past 500 (0.4%). And Tycho's pool pays 48.5BTC for each block found even if it is eventually found to be invalid.

If they are working on a block and there are 2 other pools that are 5x and 8x faster than them, then that wouldn't exactly surprise me. One of the other pools comes ripping through and finds the solution right before bitcoinpool doesn't seem that far fetched.

That's not how it works.

Invalid blocks are a function of how far away (from an average node distance standpoint) the pool's bitcoind is from the rest of the bitcoin network. A high number of invalid block submissions implies that the bitcoind instance is relatively closer to an edge of the network than the center.

The pool is working on a block with a prevhash pointing to the previous found block. But if the pool's bitcoind doesn't have the latest information from the blockchain, then it will be working against the wrong prevhash. The further away the pool is from the center of the network, the longer it will take (on average) for the pool to get blockchain updates.

It's all about how many other nodes in the network you are connected to.  This is why it's a P2P network, kinda like torrents.  The more peers you have, the faster you get information.
Currently bitcoin is set to 8 max outbound connections, and 125 inbound connections - MAX_OUTBOUND_CONNECTIONS.
Let's explain with the code itself.

Line 7:net.cpp

Code:

static const int MAX_OUTBOUND_CONNECTIONS = 8;

This means the maximum number of OUTBOUND connections (from you to someone else) is 8.  If you want your bitcoind to connect to more than 8 nodes in the network (which isn't that much), then change this number to something higher than 8.  I use 1000.

Line 710:net.cpp

Code:

else if (nInbound >= GetArg("-maxconnections", 125) - MAX_OUTBOUND_CONNECTIONS)

This means the max number of inbound connections you can have is the "-maxconnections" option (which defaults to 125) minus the MAX_OUTBOUND_CONNECTIONS (which is 8 by default).  By default, you can have 8 outbound (from you to others) connections and 117 Inbound (from others to you) connections.  Inbound connections don't work if you're behind a firewall and haven't setup port forwarding or access to port 8333.

Line 1132-1133:net.cpp

Code:

int nMaxOutboundConnections = MAX_OUTBOUND_CONNECTIONS;
nMaxOutboundConnections = min(nMaxOutboundConnections, (int)GetArg("-maxconnections", 125));

This is choosing the smaller number between MAX_OUTBOUND_CONNECTIONS and the "-maxconnections" command line argument, and uses that number for the maximum number of outbound connections.  This would be 8.

So here's the changes I made for the colo server.
Line 7:net.cpp

Code:

static const int MAX_OUTBOUND_CONNECTIONS = 1000;

Line 710:net.cpp

Code:

else if (nInbound >= GetArg("-maxconnections", 1500) - MAX_OUTBOUND_CONNECTIONS)

I also removed line 1133 entirely.

Right now the bitcoind on the server has 256 connections to others nodes in the bitcoin network. I intentionally kept this at 256 connections.  1 of those connections is to a server in a colo that was modified to have 1000 max connections. The colo server currently has 923 connections, and an uptime of 53 days.

I would say we are very, very well connected to the bitcoin network.  If nobody else is doing this, then we might be the node with the most connections in the bitcoin network.  It's probably not a good idea for everyone to do this, but since I run a pool, I want to be as well connected to the bitcoin network as possible.

You'll probably be interested to know that slush thinks this is a good idea too.  I mentioned it to him several months ago.

Hi FairUser,

I'm responding to your notice in Coop mining thread:

BTW, my modified Linux clients can maintain 1024 active connections (yes, I modified the code...452 connections at the moment) to other users bitcoind processes

Is this patch available? Or how much tricky it is? I didn't read bitcoin code too much as I'm not C programmer, but it looks like rising connection limit constant should be enough. Am I right?

Rising this limit should improve pool performance a little, because new blocks aren't distributed inside bitcoin network effective enough.

Thanks,
slush

I'm not submitting an official patch because if everyone did this the network would get very, very active with the same information being broadcast through out the entire bitcoin network several hundred times.

So back to the point, we just got unlucky with our blocks.  Someone else got a better fit answer for the block so the pool didn't get paid, and that's why everyone else didn't get paid.  We had code in place to catch when this happens, but we found the typo which caused it to not execute properly.  As a result invalid blocks were being treated as valid, which is also the reason everyone's historical earnings were off.  We have gone back through and marked the invalid blocks as invalid, and fixed the historical earnings at the same time.

Gotta love them bugs.

[slush]

You'll probably be interested to know that slush thinks this is a good idea too.  I mentioned it to him several months ago.

Firstly, I see pretty unfair that you're publishing our private communication for your own defense.

Secondly, this is 3 months old message and I learned a lot of things in meantime. My Pool is currently connected to ~100 other nodes, but I connect manually to some well known and well connected hubs. In last 400 blocks where I did some improvements, I didn't hit single failed block.

So I think that 8% is really pretty high invalid ratio. Just for curiosity - how long time takes the processing of block broadcasts? I think that there might be some hidden problem behind your custom patches. It's no offense, I'm just thinking aloud.

[xf2_org]

I also want to reinforce that most people should not follow FairUser's example.  We don't need every client out there connecting to 1,000 nodes.

Mathematically, you don't need anywhere near that many.

[FairUser]

I also want to reinforce that most people should not follow FairUser's example.  We don't need every client out there connecting to 1,000 nodes.

Mathematically, you don't need anywhere near that many.

++
It's not for everyone.

[yrral]

What happened?
Pool speed is 0ghash/s. Confirms table is broken.

[allinvain]

http://bitcoinpool.com/account.php

the account login page is borked....

[tripper22]

http://bitcoinpool.com/account.php

the account login page is borked....

I agree. It is. Come on guys get it fixed.

[homer]

http://bitcoinpool.com/account.php

the account login page is borked....

I agree. It is. Come on guys get it fixed.

I believe they are watching their own site forum.  Looks like someone else brought it up and they replied to them.
http://bitcoinpool.com/forum/viewtopic.php?f=1&t=32&p=262#p262

[xenon481]

Interesting Note: The company I work for just moved my office over to their proxy and now bitcoinpool.com is being blocked under the reason of "Games". I haven't found any other bitcoin related cites that I visit that have been blocked.

[LMGTFY]

Interesting Note: The company I work for just moved my office over to their proxy and now bitcoinpool.com is being blocked under the reason of "Games". I haven't found any other bitcoin related cites that I visit that have been blocked.

I assume it's due to "pool" - might be worth checking Bitcoin Darts! :-)

[xenon481]

Interesting Note: The company I work for just moved my office over to their proxy and now bitcoinpool.com is being blocked under the reason of "Games". I haven't found any other bitcoin related cites that I visit that have been blocked.

I assume it's due to "pool" - might be worth checking Bitcoin Darts! :-)

Yes, they are also blocking bitcoindarts.

[Miner-TE]

If it is Websense...

Bitcoinpool.com is Uncategorized
deepbit.net is Uncategorized
mining.bitcoin.cz is categorized as Information Technology
bitcoindarts.movoda.net is categorized as Games
BTCmine is Uncategorized

[xenon481]

I can't tell what it is (websense vs others) because they have completely stripped it down to just displaying the category being blocked.

[demonofelru]

Hello to geebus or fairuser it seems there was a problem with my miner last night it's not generating but still requesting getworks.  Feel free to disable me I'm not at home for the holidays.

[keybaud]

Hello to geebus or fairuser it seems there was a problem with my miner last night it's not generating but still requesting getworks.  Feel free to disable me I'm not at home for the holidays.

Feel free to post on their forums (or PM them directly) if you're a member of their pool. They reply pretty quickly there and give clear statements as to what has caused any known issues and what they are doing to resolve them.

[FairUser]

I thought I would drop in and let people know that our pool has resumed normal functionality.  We got hit pretty hard yesterday with a DoS attack, but we've been able to muffle it for the time being.

I would also like to point out that just because we had some problems with the site yesterday, we still found 7 blocks and users have been paid for the blocks that are now confirmed.

Thank you all for your understanding and participation.

[xenon481]

BitcoinPool has been getting Hacked and DOS'd fairly successfully and quite constantly for the past 2 months. That's a horrible thing to do to any service provider. But, now it looks like BitcoinPool's owners are thinking about going and hacking other people in response.

So I've been e-mailing admins of the open proxies when they've been used to attack us. Since I started doing that, I've gotten 5 reply's back. Two admins basically said "Sorry, can't help." The other 3 have been very helpful in providing use with either the logs or the IP's of the offenders...who seem to have switched to Tor.

I don't want to start pointing fingers at who this is, because I don't have the records from the ISP of the person doing this to prove it's them, but we know the specific area (city and country) and have been able to figure out who it is by other comments they've posted on the bitcoin forums. Let's just say they have a lot more to loose than our pool does.

So here's the question, do we fight back and target these fuckers for counter attacks or just leave them be?

FairUser said he doesn't want to point fingers because he doesn't have proof, but as has been shown earlier in this thread, he's already pointed fingers at both Slush and Tycho with "evidence" that doesn't even actually point to them (the IP Addresses posted in some of their earlier posts about the hacks do point to Eastern Europe, but not to where Slush is).

So just to recap for everyone.

We openly invited Slush to prove that Pool Hopping makes more bitcoins, and set some basic criteria for him to follow so that everyone could follow along and see if pool hopping really worked. He said it did, I said it didn't and asked him to prove it. He never openly excepted our challenge...

Within days we saw our first major attack on April 4th. This was a SQL injection attack that dumped everything from the database and changed people's wallet IDs. Then a few days later we saw SQL injection again that targeted wallet IDs. Then after that we had someone (the same person that stole the DB) trying to brute force into accounts, because user's didn't change their password when we advised them to. Then about 2 weeks after the first attack, we got a massive DoS from multiple IP's. Then after that someone again tried to brute force into people's accounts, and again succeeded do in doing so due to poor passwords. And last but not least was last night, we're someone was trying to brute force people account passwords through the RPC port (8334) and someone else was DoSing us at the same time. So I'm about at the end of my tolerance to deal with this shit, my patience is virtually gone.


So we believe this to be two attackers. One being slush and friends (more evidence on this later), and one being an unknown party from down under. I got a contact with the cyber crime division of the AFP (Australian Federal Police) and I'm waiting to here back about the IP's I sent him to look at. After I explained that it does in fact involved theft of currancy, he said he'd see what he can do to help us. I've also been sending e-mails to the admins of the IP's of the open HTTP proxies that have been used against us, and some have been very helpful in providing us logs. One of the proxies was from a .gov address, so the admin was very happy to have someone report that a box was mis configured and being abusive on the Internet, and he *might* be able to get me the IP's of the people doing the attack depending on whether they were going to do anything about it themselves. So that's two different government's that *might* be able to help us. Personally I'm not holding my breath expecting answers from them, but one can hope. Next step is we're going to block Tor entirely. Don't get me wrong, I love Tor too, but bitcoin and this forum are pretty anonymous anyway, so the need for Tor isn't needed at all.

So, all in all, it's been a shitty fucking month for this pool in regards to being attacked. Instead of proving what they believe to be true, they fucking hack us. So at this point I'm going to say that slush fucking knows that pool hopping doesn't make you more bitcoins, but hacking does apparently.

And now FairUser is openly accusing Slush without posting any evidence at all. He says that he's been able to figure it out from comments posted on the forums, but I haven't seen a single post from Slush that would indicate that he is hacking/DOSing them.

I'm not trying to defend Slush here. I have no idea what he does or does not actually do. But, if you are going to openly accuse any member of this forum of illegal activities, then provide your proof.



Edit:

Also, FairUser was saying that Pool Hopping doesn't actually work at all, but they put in an anti-pool-hopping measure.... One that works in a conceptually similar way to scoring (making earlier shares in a round worth less) even though they said that they would never do something like that.

We've added in code that will hopefully result in pool hoppers being deterred from leaving rounds early.

Essentially, the way this works is;

If the round duration at the end of the round is greater than 1 hour, each user is looked at to see their 'window of participation', which is the time difference between their first and last submitted shares.

If the time difference between their shares is less than one half of the round duration, their share count will be reduced by 50% and the other half of their shares will be credited to an account setup by the pool operators.

[bitcoin_ent]

It is difficult to believe that anyone would do business with this pool.  All you have to do is review a couple of their posts to see how juvenile and unprofessional they are.  Avoid!