Topic: BitcoinPool.com open thread - page 4. (Read 29840 times)

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

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

Yes, they are also blocking bitcoindarts.

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

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 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

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

http://bitcoinpool.com/account.php

the account login page is borked....

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

++
It's not for everyone.

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.

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.

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

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
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
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


Line 710:net.cpp

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.



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.

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.


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.

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?

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.

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.

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.

In the interest of being objective, Geebus posted that this is due to blocks being invalid and not passing confirmation. This should also fix the discrepancy in the historical payouts.

http://www.bitcoinpool.com/forum/viewtopic.php?f=1&t=27


When I was mining there, the speed would fluctuate through out the whole block quite a bit. It looked like people would hop on and request a few getworks, hardly process any, then drop off. A quick check of the user list doesn't show an active user or registered user with that name (subjective as it is) and smells like baiting to me.

According to posts on BitcoinPool's own forum, it appears that the missing payments issue is indeed more widespread than just the one single instance noticed before.

The user audaibnjad has so far tracked 2 more blocks for which is hasn't been properly paid.

http://www.bitcoinpool.com/forum/viewtopic.php?f=1&t=26


Edit:

Also, it looks like the user accounts are getting (successfully) brute forced or dictionary attacked and they haven't put in any lockout measures or other some such to prevent it.


Edit2:

Also, more concerns from users that are seeing the tell-tale signs that the pool is being attacked by implementations of the pool-hopping exploit.