[CLOSED] BTC Guild - Pays TxFees+NMC, Stratum, VarDiff, Private Servers

[eleuthria]

I'm glad other people can spot when the pool isn't doing it's job. If no one caught onto this, would this just be buried by time? I guess I'm glad I don't understand the hard technical stuff, cause I'd be looking for holes all the time and would probably be spotting them all the time. I guess it's like taking money from a blind person. Who monitors the monitor?

Not doing it's job, but not working %100 I guess.

It's extremely rare since all of the bitcoind's on the various pool servers are connected to the payment server, so the odds of the payment server seeing a competing block before a Guild block are *very* low (less than 1 in 10 orphans).  When they are missed, it's generally corrected a few hours later manually without anybody noticing, but it does take a few hours because correcting it is a manual process, including the detection that it happened in the first place.  Bitcoind does not report orphaned blocks via any RPC commands if they were not originally accepted.


The current project for the pool is a complete ground-up rewrite of the Stratum code to make it more scalable (full utilization of many-core systems), allow for better merged mining integration (instead of the fairly limited version currently implemented), and multiple chains (for an scrypt multipool).

Part of this rewrite is also going to make the pool servers insert found blocks directly to the database, and then the payout server will check against them before awards are assigned.  It won't prevent them from still needing manual intervention to get them paid (as a security/sanity check), but it will make sure they're properly logged at the time they're found and identified as not yet paid out in the Pool Stats page.

[1713461927]

1713461927

[1713461927]

1713461927

[1713461927]

1713461927

[sbfree]

I'm glad other people can spot when the pool isn't doing it's job. If no one caught onto this, would this just be buried by time? I guess I'm glad I don't understand the hard technical stuff, cause I'd be looking for holes all the time and would probably be spotting them all the time. I guess it's like taking money from a blind person. Who monitors the monitor?

Not doing it's job, but not working %100 I guess.

It's extremely rare since all of the bitcoind's on the various pool servers are connected to the payment server, so the odds of the payment server seeing a competing block before a Guild block are *very* low (less than 1 in 10 orphans).  When they are missed, it's generally corrected a few hours later manually without anybody noticing, but it does take a few hours because correcting it is a manual process.  Bitcoind does not report orphaned blocks via any RPC commands if they were not originally accepted.


The current project for the pool is a complete ground-up rewrite of the Stratum code to make it more scalable (full utilization of many-core systems), allow for better merged mining integration (instead of the fairly limited version currently implemented), and multiple chains (for an scrypt multipool).

Part of this rewrite is also going to make the pool servers insert found blocks directly to the database, and then the payout server will check against them before awards are assigned.  It won't prevent them from still needing manual intervention to get them paid (as a security/sanity check), but it will make sure they're properly logged at the time they're found and identified as not yet paid out in the Pool Stats page.

yeah! ... what eleuthria says

get'em @el

[guytechie]

Wow, we're at 3120 TH now.  That was quick...

[AussieHash]

Wow, we're at 3120 TH now.  That was quick...

I know, 2-3 days ago i had 3.5 million shares per shift, now down to 2.8million

[CYPER]

No, I wish to stand outside the restaurant saying that the restaurant and the food are good in general, but can be improved.
What is so bad with adding luck per user selectable length of time to the already good selection of statistics?
How is that against the interest of pool users?
Wouldn't you like it if you could see what the luck was for the past 7 days for example?

I've said this before, but I'll repeat myself.  Why does it matter?  Luck is luck.  Sometimes it's good, sometimes it's bad.  You have no control over it.  If you're considering going to a pool because it has "good luck", make sure you throw salt over your shoulder first.

M

If it doesn't matter then why every single major pool including BTCGuild display luck?
You are making a point that luck does not matter, yet the reality shows it does: people use it to feel good about their choices, regardless of being completely random.

GHash.io doesn't have and luck stats.

Ghash.io have a total proofs of work per block data, from where a 6 years old could easily check luck.

Who monitors the monitor?

Realistically a pool admin can always do shady things behind the curtains, so that is why it is important to have transparency in order to sustain trust in its user base by giving them the power to check/verify.
When an admin refuses to publish specific data, that doesn't speak very well for the transparency of his service.
There is a saying that goes: if you want something you will find a way, if you don't then you will find an excuse.

[opentoe]

I'm glad other people can spot when the pool isn't doing it's job. If no one caught onto this, would this just be buried by time? I guess I'm glad I don't understand the hard technical stuff, cause I'd be looking for holes all the time and would probably be spotting them all the time. I guess it's like taking money from a blind person. Who monitors the monitor?

Not doing it's job, but not working %100 I guess.

It's extremely rare since all of the bitcoind's on the various pool servers are connected to the payment server, so the odds of the payment server seeing a competing block before a Guild block are *very* low (less than 1 in 10 orphans).  When they are missed, it's generally corrected a few hours later manually without anybody noticing, but it does take a few hours because correcting it is a manual process, including the detection that it happened in the first place.  Bitcoind does not report orphaned blocks via any RPC commands if they were not originally accepted.


The current project for the pool is a complete ground-up rewrite of the Stratum code to make it more scalable (full utilization of many-core systems), allow for better merged mining integration (instead of the fairly limited version currently implemented), and multiple chains (for an scrypt multipool).

Part of this rewrite is also going to make the pool servers insert found blocks directly to the database, and then the payout server will check against them before awards are assigned.  It won't prevent them from still needing manual intervention to get them paid (as a security/sanity check), but it will make sure they're properly logged at the time they're found and identified as not yet paid out in the Pool Stats page.

Can't you just program an exception report and post that? I'm sure you are human and maybe have missed some yourself, no?

[AussieHash]

@eleuthria

I realize blockchain is not always correct in assigning blocks, but I cannot see this orphan on the list (unless it is out of sequence)

https://blockchain.info/block-height/278777

[eleuthria]

@eleuthria

I realize blockchain is not always correct in assigning blocks, but I cannot see this orphan on the list (unless it is out of sequence)

https://blockchain.info/block-height/278777

The block you just linked is from ghash.io

EDIT:  NVM, under it is the BTC Guild orphan.  That orphan is shown out of order (it's the one posted about on another page).  It's between 278780 and 278783.  Like I said, since that orphan was never seen by the payout server so it had to be manually forced in.

[AussieHash]

Thanks.
I see it between 796 and 800

Edit : another example of blockchain's relayed by ambiguity.
https://blockchain.info/block-index/456592/0000000000000000386fb6e0f3b250eebc22128ef10cf91501bc6c091633c8e1
Mined by guild, relayed by ghash

Edit 2: both pools are claiming it (for now perhaps?)
Ghash
5920   
2014-01-06
23:28:30   
279013   
25.0222   
3/120   
3 minutes   
4.18 Ph/s   
19/5000009572   
0.00%   
175132889   
0.00000009

Btcguild
279013   0.14562%   0.03534980   2014-01-06 11:28 PM

[eleuthria]

Thanks.
I see it between 796 and 800

Edit : another example of blockchain's relayed by ambiguity.
https://blockchain.info/block-index/456592/0000000000000000386fb6e0f3b250eebc22128ef10cf91501bc6c091633c8e1
Mined by guild, relayed by ghash

Edit 2: both pools are claiming it (for now perhaps?)
Ghash
5920   
2014-01-06
23:28:30   
279013   
25.0222   
3/120   
3 minutes   
4.18 Ph/s   
19/5000009572   
0.00%   
175132889   
0.00000009

Btcguild
279013   0.14562%   0.03534980   2014-01-06 11:28 PM

Looks like that's an orphan.  It won't get marked as one by BTC Guild until it finds another block (blocks are marked as "Orphan" once the pool finds another block and sees that the previous block does not have at least 2 confirmations).  It really sucks that ghash.io has become the dominant pool, yet has by far the worst connectivity with the entire network of any other pool, leading to significantly higher orphan rates across the board, both for them and for other pools.

[guytechie]

Wow, we're at 3120 TH now.  That was quick...

I know, 2-3 days ago i had 3.5 million shares per shift, now down to 2.8million

3225 TH/s!  105 TH in just over 12 hrs!

[AussieHash]

Looks like that's an orphan.  It won't get marked as one by BTC Guild until it finds another block (blocks are marked as "Orphan" once the pool finds another block and sees that the previous block does not have at least 2 confirmations).  It really sucks that ghash.io has become the dominant pool, yet has by far the worst connectivity with the entire network of any other pool, leading to significantly higher orphan rates across the board, both for them and for other pools.

Conspiracy theories about selfish and evil pools aside, I wonder if this hurts them more or harms them. It would probably harm other pools which pay for orphans and PPS

Vitalik writes about a "12 second propagation time" in this article
http://bitcoinmagazine.com/8972/quarkcoin-noble-intentions-wrong-approach/

If ghash's blocks take longer than 12 seconds to propogate, then all other miners are wasting time hashing the old block. As ghash have less than 51% of the network there would be a significant risk of another miner producing a competing valid block, but with 40% of the network, ghash would still have a high chance of multiple sequential blocks (6 in a row today) and lengthening their own chain

Edit <conspiracy theory> : if ghash maintained 40% share, if they were responsible for increasing the entire network's orphan rate slightly (even 0.5%) would that slowly kill off all other pools profit margin (and drive more miners to them)?</tin foil>

[eleuthria]

Looks like that's an orphan.  It won't get marked as one by BTC Guild until it finds another block (blocks are marked as "Orphan" once the pool finds another block and sees that the previous block does not have at least 2 confirmations).  It really sucks that ghash.io has become the dominant pool, yet has by far the worst connectivity with the entire network of any other pool, leading to significantly higher orphan rates across the board, both for them and for other pools.

Conspiracy theories about selfish and evil pools aside, I wonder if this hurts them more or harms them. It would probably harm other pools which pay for orphans and PPS

Vitalik writes about a "12 second propagation time" in this article
http://bitcoinmagazine.com/8972/quarkcoin-noble-intentions-wrong-approach/

If ghash's blocks take longer than 12 seconds to propogate, then all other miners are wasting time hashing the old block. As ghash have less than 51% of the network there would be a significant risk of another miner producing a competing valid block, but with 40% of the network, ghash would still have a high chance of multiple sequential blocks (6 in a row today) and lengthening their own chain

Edit <conspiracy theory> : if ghash maintained 40% share, if they were responsible for increasing the entire network's orphan rate slightly (even 0.5%) would that slowly kill off all other pools profit margin (and drive more miners to them)?</tin foil>

The 12 second time is more for full-network propagation.  Pool-to-pool communications *should* be significantly faster if they're well connected like *most* pools are.  The vast majorities of pools are just a few hops away and have the bandwidth to push/receive blocks in miliseconds unlike home connections which are likely taking 1-3 seconds to relay a 1MB block to each of their peers.

[mdude77]

I just got my first cube up and running.  It looks like it's working, going through my stratum proxy.  But my worker is showing zero hashrate?  I'm pointing to the backup server.  Is there a delay in hashrates being counted, or am I doing something wrong?

M

[eleuthria]

I just got my first cube up and running.  It looks like it's working, going through my stratum proxy.  But my worker is showing zero hashrate?  I'm pointing to the backup server.  Is there a delay in hashrates being counted, or am I doing something wrong?

M

Sure you got the right worker credentials?  Hash rates update after a minute or so.  Shares show up within 10 seconds.

[mdude77]

I just got my first cube up and running.  It looks like it's working, going through my stratum proxy.  But my worker is showing zero hashrate?  I'm pointing to the backup server.  Is there a delay in hashrates being counted, or am I doing something wrong?

M

Sure you got the right worker credentials?  Hash rates update after a minute or so.  Shares show up within 10 seconds.

EDIT: looks like cubes don't like the "no midstate" option with slush's proxy.

M

[curt.rowland]

Hello all, I am still new at this and really new here. I was wondering what advantages there are for joining a team? Should I join a team or will my rewards be just the same either way?

[Trongersoll]

Hello all, I am still new at this and really new here. I was wondering what advantages there are for joining a team? Should I join a team or will my rewards be just the same either way?

Teams offer no advantage.

[eleuthria]

Hello all, I am still new at this and really new here. I was wondering what advantages there are for joining a team? Should I join a team or will my rewards be just the same either way?

Teams are a "for fun" feature.  They offer no changes to rewards in any way.  They're designed as a way for users to either compete with a smaller subset of users in rankings (some people like competition even if it's just a numbers game), or group up with friends to compete against another group.

[mdude77]

I just got my first cube up and running.  It looks like it's working, going through my stratum proxy.  But my worker is showing zero hashrate?  I'm pointing to the backup server.  Is there a delay in hashrates being counted, or am I doing something wrong?

M

Sure you got the right worker credentials?  Hash rates update after a minute or so.  Shares show up within 10 seconds.

EDIT: looks like cubes don't like the "no midstate" option with slush's proxy.

M

Using bfgminer as a proxy is so much easier.  Once you realize only the 32-bit version has the proxy.

M

EDIT: bfgminer is easier, but it doesn't do as well.  Cruising at almost 39gh/s thru slush's proxy, couldn't top 35 thru bfg.