Bitcoin Forum
December 04, 2016, 08:40:02 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 [267] 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 ... 426 »
  Print  
Author Topic: [CLOSED] BTC Guild - Pays TxFees+NMC, Stratum, VarDiff, Private Servers  (Read 828629 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
CYPER
Hero Member
*****
Offline Offline

Activity: 630



View Profile
January 06, 2014, 02:45:47 AM
 #5321

I for one would not care what the luck was within a certain time period because it has absolutely no indication of future luck. 

This.

Past results do not indicate future performance.


You hear this time after time elsewhere, yet people still do not understand.

Yet every pool has a luck index, because wait for it... it does not matter  Cool

If this post helped you and you feel generous you know what to do: 1P9tXFy9bVgzrfPGeV7F8np26ZtFdCCWvz
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480884002
Hero Member
*
Offline Offline

Posts: 1480884002

View Profile Personal Message (Offline)

Ignore
1480884002
Reply with quote  #2

1480884002
Report to moderator
1480884002
Hero Member
*
Offline Offline

Posts: 1480884002

View Profile Personal Message (Offline)

Ignore
1480884002
Reply with quote  #2

1480884002
Report to moderator
1480884002
Hero Member
*
Offline Offline

Posts: 1480884002

View Profile Personal Message (Offline)

Ignore
1480884002
Reply with quote  #2

1480884002
Report to moderator
xstr8guy
Hero Member
*****
Offline Offline

Activity: 784


Glow Stick Dance!


View Profile
January 06, 2014, 03:44:34 AM
 #5322

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.
opentoe
Legendary
*
Offline Offline

Activity: 1190

Personal text my ass....


View Profile WWW
January 06, 2014, 04:01:36 AM
 #5323

From the numbers I've seen floating around, and since not one pool operator would indugle us in the money they make I can only assume they are making from the low end $10000 to the high end to $40000 / monhtly. Still beats most 9-5 jobs out there....and if operator was losing money he wouldn't be around here anymore. Average it out at $20kmonth and the operator is hauling in $240000. Most more then most people I know. A lot more. They are living quite comfortably it seems. Don't let 'em fool ya!
Does it bother you that someone is being successful providing a service in an open market?

I'm a little jealous.

Need help with your Newznab usenet indexer? http://www.newznabforums.com
opentoe
Legendary
*
Offline Offline

Activity: 1190

Personal text my ass....


View Profile WWW
January 06, 2014, 04:17:57 AM
 #5324


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

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

Need help with your Newznab usenet indexer? http://www.newznabforums.com
eleuthria
Legendary
*
Offline Offline

Activity: 1750


BTC Guild Owner


View Profile WWW
January 06, 2014, 04:29:13 AM
 #5325

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

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.

R.I.P. BTC Guild, 2011 - 2015.
BTC Guild Forum Thread
sbfree
Sr. Member
****
Offline Offline

Activity: 336



View Profile
January 06, 2014, 04:55:14 AM
 #5326

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

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
Sr. Member
****
Offline Offline

Activity: 293


View Profile
January 06, 2014, 12:06:16 PM
 #5327

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

Put something in my tip jar if I made your day. Smiley
BTC:
1MkmBHDjonAFXui6JEx9ZmEemfMtUo9Cmu
AussieHash
Hero Member
*****
Offline Offline

Activity: 675



View Profile
January 06, 2014, 12:42:43 PM
 #5328

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
Hero Member
*****
Offline Offline

Activity: 630



View Profile
January 06, 2014, 12:55:57 PM
 #5329

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? Smiley
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.

If this post helped you and you feel generous you know what to do: 1P9tXFy9bVgzrfPGeV7F8np26ZtFdCCWvz
opentoe
Legendary
*
Offline Offline

Activity: 1190

Personal text my ass....


View Profile WWW
January 06, 2014, 08:11:52 PM
 #5330

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

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?

Need help with your Newznab usenet indexer? http://www.newznabforums.com
AussieHash
Hero Member
*****
Offline Offline

Activity: 675



View Profile
January 06, 2014, 11:22:19 PM
 #5331

@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
Legendary
*
Offline Offline

Activity: 1750


BTC Guild Owner


View Profile WWW
January 06, 2014, 11:27:12 PM
 #5332

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

R.I.P. BTC Guild, 2011 - 2015.
BTC Guild Forum Thread
AussieHash
Hero Member
*****
Offline Offline

Activity: 675



View Profile
January 06, 2014, 11:35:12 PM
 #5333

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
Legendary
*
Offline Offline

Activity: 1750


BTC Guild Owner


View Profile WWW
January 07, 2014, 12:15:23 AM
 #5334

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.

R.I.P. BTC Guild, 2011 - 2015.
BTC Guild Forum Thread
guytechie
Sr. Member
****
Offline Offline

Activity: 293


View Profile
January 07, 2014, 12:57:15 AM
 #5335

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!

Put something in my tip jar if I made your day. Smiley
BTC:
1MkmBHDjonAFXui6JEx9ZmEemfMtUo9Cmu
AussieHash
Hero Member
*****
Offline Offline

Activity: 675



View Profile
January 07, 2014, 01:22:40 AM
 #5336

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
Legendary
*
Offline Offline

Activity: 1750


BTC Guild Owner


View Profile WWW
January 07, 2014, 02:06:50 AM
 #5337

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.

R.I.P. BTC Guild, 2011 - 2015.
BTC Guild Forum Thread
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
January 07, 2014, 02:19:02 AM
 #5338

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

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
eleuthria
Legendary
*
Offline Offline

Activity: 1750


BTC Guild Owner


View Profile WWW
January 07, 2014, 02:26:20 AM
 #5339

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.

R.I.P. BTC Guild, 2011 - 2015.
BTC Guild Forum Thread
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
January 07, 2014, 02:42:24 AM
 #5340

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

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
Pages: « 1 ... 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 [267] 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 ... 426 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!