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

My stats look perfectly ok around that time - nothing outside the normal range (I use the eu.stratum server).  Possibly it was some kind of intermediate routing issue which was not local either to you or the server.

Greetings,

Has anyone else noticed a sudden decrease in their worker charts as of around 4pm (GMT) yesterday?

I have an Antminer S3 pointed at Slush and BTC Guild in balance mode and both the miner stats and Slush's stats report a constant 230GH/s to each site, but the BTC Guild charts show a sudden drop down to around 170GH/s and I cannot work out why, so wanted to see if it was a reporting issue for everyone or a problem somewhere for me.

Cheers n beers

HPmuirt

 

I received a phishing email today


The attached jar file was a Java executable obfuscated by Allatori, likely a wallet stealer, but no deobfuscator could deobfuscate the strings for me to see what happens.

Wonder how many feelings that'll hurt lol

Just going to go on record saying that if you actually fall for a phishing email claiming to be an INVOICE PAYMENT from BTC Guild, turn off your computer, and put it in a garbage bin.  You're not sophisticated enough to use the modern technology, let alone Bitcoin.

EDIT:  Posted this because I just got a copy of the email in my inbox for my old address used for Bitstamp.

BTC Guild does not send any unsolicited emails.  The only automated emails you will receive from the pool are confirmations for wallet/email address changes, or idle miner alerts.  If you get a wallet/email change email, you should  not click any links in that email unless you actually requested it (though you should check if its legit, because if it is it means somebody has your username+password).

There have been many phishing email scams over the years claiming to be from [email protected] (and many other major BTC domains).  In all of them, the emails were spoofing the origination address.  There have been dozens of BTC based websites that have had database leaks over the years which is likely how your email address got on a list to receive the phony emails.  MtGox, Bitstamp, and Bitcointalk have all had complete leaks of all user email addresses over the years (and in some cases, passwords to match).

My inbox is generally filled with "invoices" and similar claims from about a dozen different sources (all spoofed headers).  KNC, BFL, MtGox, Bitstamp, BTC Guild itself [my favorite], and Bitmain.  In all cases, they have a Java (.jar) file attached with a filename like "Invoice 89324".  Obviously, it's stupid to ever open a .jar file from an email attachment.  You will probably never in your life receive a '.jar' file unless you're a Java developer passing application builds over email.

ditto here...didn't see any news so i knew it was bogus and the full header said "domain of btcguild.com does not designate 192.40.181.239 as permitted sender" hehe

I've never gotten emails like this but they've all always been phishin from what Eleu's said.

I got one too.
Be careful

Got an email from an, [email protected] with a subject of, "invoice".  I assume this is a phishing email trying to get you to open the attachment, DON"T OPEN IT if you get an email like this.

I am sure Eleuthria can comment further, just wanted to bring it to everyone's attention.

That explains it.  Thanks.

GAW is mostly scrypt so no typo

Straying slightly OT, having never heard of GAW I went to take a look:
Guaranteed never to break down?  This must be some new miracle of electronic engineering.  I wonder where the other 0.1% went?

$.08/day per MH?  Even if it's a typo and they mean GH, I cannot see how anybody except the operator can make money at that price; the equivalent of a single S3+ at (say) 450GH would cost $36 per day, and could never earn that much.

Awesome! Thank you. All miners back to btcguild

I heard that the "ceo" from GAW was interested. I'm sure he would come up with, yet, another way to rip people off and I don't want to be a part of it.

Thanks again man!

Correct, the pool was not sold/transferred/partnered with anybody.  As of this moment, absolutely nothing has changed.  In the future, the pool might be moved overseas and take on a partner who would establish a new corporation (or foreign equivalent) in their country.  I'll have more information on that front late this month.  That will not actually take place unless the legal/regulatory environment forces me to move the pool, but I'm going to be making preparations so it can happen seamlessly.

Thank you for keeping you AWESOME pool working. I mainly mine on Bitminter and BTC Guild and really appreciate your passion, dedication and commitment to the Bitcoin miner's community 

you didnt sell it to the noobs at GAW, they have nothing to do with btcguild?

Great news

Thank you !

If you can figure out how to do this in a manner that is TNO (trust no one), then I think you'll be on to something.  Otherwise, who's to prevent a pool op from putting whatever supershares he wants on the share chain?

One of the great things about p2pool is the TNO principle.  Everything everyone does can be, and is verified on the share chain.  The chain itself contains the payout data, and you get on it by submitting a big enough share.

Your idea is similar to the one I had.  My suggestion was to have lower the share size significantly so that small miners can get on.  That means one of the basic principles of p2pool has to change: work has to stop restarting every time a share is added to the chain.  Instead, like conventional pools, work restarts when a block is found on the BTC chain.  At that point all the nodes use a predetermined algorithm to gather up all the shares since the last block, bundle them together into a "payout" share, and add it to the payout chain.  (That means two chains.)  That way the TNO principle still applies ... every node can independently verify both chains.  Worker data (coinbase?) is based upon the data in the payout chain, so when a block share is submitted, payout happens properly.  Note this also means the current round doesn't count towards payout.

There may be something I'm overlooking here, but that's the basic principle. 

M

Ah, good point.  They would be gambling on solving a block before the network does, and if they're going to make that gamble they might as well just mine an entire block for themselves.  Time change+a few late nights must be taking their toll on my early morning thinking skills.

---

In the rest of this post, I will be making reference to "super shares".  This is a term for grouping up multiple share submissions at a lower difficulty into a single share that is "big enough" to be put into the list of payments in the next block.

Building off my earlier post, the "5000 super shares" list of users that would get paid on the next block solve is flexible in that it could be altered to be a specific multiple of difficulty, just like PPLNS allows N to be changed to either increase or decrease the window being used.  By lumping share credit into "super shares", you can define a super share as any "difficulty sum".  Miners would continue to work at smaller difficulties like they always have in pooled mining.  Upon reaching the "super share" threshold, they enter the list of addresses to be paid the next time the block updates, and push off the oldest address in that list.

My earlier example of 5000 super shares at 8m diff each would be equivalent to PPLNS where 'N' = network difficulty.  If it was modified to the current pool setting, it would be closer to 32m diff per "super share", which would be 'N' = 4x network difficulty.


EDIT:  Just to clarify, "5000" is just an example where the minimum payment a user would receive is 0.005.  This wouldn't actually create a huge coinbase tx (in terms of data size).  There would not actually be 5000 addresses being paid in the coinbase.  Very fast users would be have multiple super shares in the list.  The fastest user on BTC Guild at this time would be 450-500 of the 5000 super shares paid in each block.