Topic: bitHopper: Python Pool Hopper Proxy - page 184. (Read 355816 times)

1) Where have you been?
Hiking traffic etc...

2) btcguild doesn't work!
I know I disabled it.

3) There is a wierd miner hanging issue?
I know I just saw it.

4) You need to merge flower's version into yours?
I'll talk to him. I literally just read the thread.

5) How are stats coming?
I did no work this weekend. So the same as friday.

Actually, I didn't explain myself well. I was thinking that you'd compare, for each listening node, arrival times and then compare that to which block actually was first. Collect say 24 hours of data for each listener. This will calibrate each listener to it's particular circumstance. Then the listener send its best guess to a central collecting website. If this is reliable, then you'll get a whole lots of listeners sending you their best guess. As long as:

a) Fakers don't make up a large percentage of the group;
b) non-faking listening nodes tend to agree most of the time
c) you can automatically remove fakers by their monitoring how consistently well or poorly they guess

then you'll get much better results than using one listening node alone.

The nice thing is that we can only win, as there are only so many things "they" can hide...

Multiple listening posts might be fine, the difficult task then would be aggregating them as anyone could sends bogus data.

Also the data from multiple listening nodes might be hard to combine, as geographical distance and other stuff makes network latency really uncomparable... all you could say is that block 1234 was likely from the same source as block 1230. If a lot of listening nodes agree, this might be a stronger indicator, that it's correct. BUT there's no guarantee that they don't all just send fake data, so the only listening node I would trust would be either my own or a big trusted one that had correct predictions in the past already (+ is open source).

In the end we need to find a way to be able to be individually spammed by as many nodes as possible when a block gets announced - preferrably in the hundreds, thousands or beyond. The more nodes send us that data, the finer that "fingerprint" would become - and the less we have to rely on certain nodes.

Specs are here btw.: https://en.bitcoin.it/wiki/Protocol_specification

Seems like you need to send a "version" packet first, then you get a similar one back from the other client (to gain the current block count, just send out a few ones and look at the answers, then report the max. value from there). It might be necessary to have the headers stored though, as the listener node might be asked for them (you can claim to not have any full block data) via "getheaders". I don't know what happens if you just ignore these request: in the worst case, the other node drops the connection/blacklists you. In the best case you just send nothing and the other client tries somewhere else.

On https://en.bitcoin.it/wiki/Protocol_rules you can see that there is a lot of computation going on, until a block is verified. It is only communicated to other clients AFTER this. This means a bigger block can take nearly half a second in reality to verify --> should show nice patterns!

According to https://en.bitcoin.it/wiki/Network we need to send something (maybe a "ping" message? https://en.bitcoin.it/wiki/Protocol_specification at the bottom...) every hour or so to our neighbours.
"Heartbeat
If thirty minutes or more has passed since the client has transmitted any messages it will transmit a message to keep the connection to the peer node alive.
If ninety minutes has passed since a peer node has communicated any messages, then the client will assume that connection has closed."

Do we jump at 43.5%?  Isn't that 630k shares?  Seems to have jumped off of mtred onto arsbitcoin at around 550k shares.

It won't net you more coins, just a more consistent supply by dividing risk by two pools, so this mod is to reduce variation, right?

Maybe that was my suggestion a few pages back?

Anyways:
For detecting (at least quite) reliably which pools solved which block we need an alternative implementation of the P2P protocol of bitcoind itself.

We need a pure listening node that can connect reliably and steadily to a lot of bitcoind clients and keep this connection alive.

We do NOT need direct connections to pools, what I suggested was to measure from which nodes you FIRST get a block announce (since we just listen and do not relay, we should get a "new block found" from node 23, then a few miliseconds later from node 42 and so on) and in which order. Still there might be a certain churn rate in the network, but with a little bit of luck (and enough connections/quickly enough found blocks...) it should be possible after an hour to say that blocks which are first announced by node 23 and then node 42 are from deepbit and blocks that are first announced by node 79 and then node 38 are from btcg for example.

Of course it would be easier if we connect directly or to neighbours of pools (with ~20 000 nodes online this is kinda hard to just randomly get out of luck though) but even a bit further away we still would hopefully see some patterns (which would naturally change over time as intermediate nodes leave and come who verify + relay blocks slower/faster) that would only shift slowly over time.

This entity should however in my opinion be open source (and hand out the acquired data via an API for free) BUT be hosted on Google App Engine or something similar, as I'm not 100% sure if it does not harm the network to have some well connected black holes in there (I seriously doubt it, but you never know...)

Advantages:
No need for ANY statistics besides eventually numbers of solved blocks (not even that is really needed as you get payouts that can be traced back to generations).

No way to delay or to develop countermeasures, as pools HAVE to rely on announcing their blocks to all neighbours as fast as possible. We just count on the fact that the pools have some different neighbours and this way new block announcements spread differently though the net.

Once in place this can be even useful beyond finally getting rid of proportional pools: It might be useful to find out if pool operators really don't steal blocks, detect hidden pools (or at least proof their existance) and/or huge solo miners and maybe other stuff I didn't think of yet.

Disadvantages:
Countermeasures from pools would involve hiding any kind of statistics to the users (noone is allowed to ever see which blocks are found by it's users) and additionally putting income of several pools in a mixing cascade before paying out. Even then we could probably guess that Pool X has found a block and by trying out deduct which one Pool X is after some time though. These countermeasures would be even worse than just faking/delaying stats for users there, but the fanbois would still praise them for their pool hopping fight.

It also might not be as reliable as APIs, but these fail also all the time (as you see).

Also it might be hard(er) to track small pools - hopping deepbit + btcguild should anyways be far more fun though, hm?

Most likely some serious development work needed (probably, I have no idea how complex the P2P protocol of bitcoind really is)

Pretty sure its proportional right now.  They are apparently going to be switching to a different method soon though, but I highly doubt they would do that in a middle of a block.

What kind of scoring are they using? May not be worth hopping. They also don't list any past shares. The lack of transparency isn't good.

From the bitp.it thread:


Edit:  Bitp.it fixed their stuck share problem.  Re-enabled them and we will see how stable they are.

i also do think we need more configuration options (eg port). i just didn't do it, because i want to merge easily with c00w's new versions (you know... he is really fast; my old versions couldn't never catch him up)

soo it's late (germany)... will come back tomorror evening.
enjoy your hopping :

Just disabled bitp.it by changing 'mine' to 'info'.  Starting to get pretty thin here on the hoppable pool front. 

I second that thought about one version thats configurable. c00wie where art thou

ozcoin has a 15min stats update-delay and sometimes an unstable api.
thats why i thought about 30min.

EDIT: btw: suggestions are welcome
EDIT: regarding github: i want to wait for c00w. maybe we can combine our "trees". i dont like the idea of multiple versions. one version which is configurable - that should be enough

sweet! it is working now..

Thanks for the help and the work.

You too c00w

 

no it's confirmed

bitp.it is faking stats. so it stays at 438035 - which is "better" than ozcoin 581449

just implementing a feature to automatic disable pools which didnt changed their round_shares in a 30minute frame.

btw: bitp.it is currently thinking about a new payout system. maybe just kick them out.

my patched hopper evenly splits my shares between them atm

Edit: (Thank you bitpit for good sample data for two pools next to each other. now i need a pool at 40% and all others at 60% - ok i think i just have to do the math myelf

They got the boost because of how bithopper works I think.  We discussed this within the last page or two of comments.  Bitp.it was sitting around 420k shares while we were all mining at ozco.in.  Ozco.in passed 420k shares + 10%, so bithopper jumped over to bitp.it.  You will see ozco.in lost about the same hashrate that bitp.it gained.

Looks like it. They are still on round 14 but suddenly got a 90 Gh/s boost

sorry
i am running it at port 80
you can change it in bithopper.py at the very end)

that was the main reason i use a proxy: i wanted to be able to mine from work

in case of dynamic ips we could just use hubs near to the pools (near means: known to be connected to that pool)

social engineering times begin

but i don't believe that: from a pool's point of view it is important to spread new blocks as fast as possible - to reduce invalids.