Topic: [CLOSED] BTC Guild - Pays TxFees+NMC, Stratum, VarDiff, Private Servers - page 159. (Read 903163 times)

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.

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.

Teams offer no advantage.

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?

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

M

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

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

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.

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 : 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)?

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

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.

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

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.

@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

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

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

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.

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

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

yeah! ... what eleuthria says

get'em @el

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.