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

[eleuthria]

There are a few issues with this system though, specifically as it comes to "stale" work.  If somebody has a share being paid in the current coinbase, and a new piece of work comes out where their work has been pushed off the payment list, they could purposely remain mining the old work (as long as the block itself isn't stale).  While this can be prevented by making it so their new submissions are considered stale as far as the pool is concerned, they would still get their reward if they solved a block.

No different than if they were solo mining and claimed the full 25 BTC...
As long as you don't credit stale shares (from the pool's perspective), nobody is hurt.

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.

[mdude77]

There are a few issues with this system though, specifically as it comes to "stale" work.  If somebody has a share being paid in the current coinbase, and a new piece of work comes out where their work has been pushed off the payment list, they could purposely remain mining the old work (as long as the block itself isn't stale).  While this can be prevented by making it so their new submissions are considered stale as far as the pool is concerned, they would still get their reward if they solved a block.

No different than if they were solo mining and claimed the full 25 BTC...
As long as you don't credit stale shares (from the pool's perspective), nobody is hurt.

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.

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

[cryptouser]

A brief update on the weekend's events:  BTC Guild is not closing down in the near future.  BTC Guild is not being sold in the near future.  I am beginning to go over options with some colleagues in other countries and lawyers to consider moving BTC Guild to another country.  This may involve taking on a partner, but I would maintain the primary role in the management and operations of the pool itself.  More on this will be made available as it develops.

That process will be the answer to the concern over regulation.  The second part, the concern about the cost of a successful compromise of the pool, is something I am working on addressing.  I have already made some changes to the pool hot wallet to significantly decrease the amount of funds kept online.  It will mean failed withdrawals may happen more frequently (we haven't had that happen in many months), though it is preferable to have a few withdrawals delayed for 12-24 hours than have the site shut down due to a compromise.

I am also exploring ways that the pool could make a transition to coinbase payments to further reduce the amount of funds at risk at any given time.  This probably won't happen for a few months, if it happens at all.

Great news

Thank you !

[clanbake]

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

[Scala]

A brief update on the weekend's events:  BTC Guild is not closing down in the near future.  BTC Guild is not being sold in the near future.  I am beginning to go over options with some colleagues in other countries and lawyers to consider moving BTC Guild to another country.  This may involve taking on a partner, but I would maintain the primary role in the management and operations of the pool itself.  More on this will be made available as it develops.

That process will be the answer to the concern over regulation.  The second part, the concern about the cost of a successful compromise of the pool, is something I am working on addressing.  I have already made some changes to the pool hot wallet to significantly decrease the amount of funds kept online.  It will mean failed withdrawals may happen more frequently (we haven't had that happen in many months), though it is preferable to have a few withdrawals delayed for 12-24 hours than have the site shut down due to a compromise.

I am also exploring ways that the pool could make a transition to coinbase payments to further reduce the amount of funds at risk at any given time.  This probably won't happen for a few months, if it happens at all.

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 

[eleuthria]

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

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.

[clanbake]

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

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.

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!

[Sir Alan]

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

Straying slightly OT, having never heard of GAW I went to take a look:

Hashlets have 99.9% uptime, are guaranteed to never break down, and have decreasing fees over time, which already start at the record low rate of $.08/day per MH.

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.

[Gws24]

GAW is mostly scrypt so no typo

[Sir Alan]

GAW is mostly scrypt so no typo

That explains it.  Thanks.

[DebitMe]

Got an email from an, info@btcguild.com 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.

[jdany]

Got an email from an, info@btcguild.com 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.

I got one too.
Be careful

[MoreBloodWine]

Got an email from an, info@btcguild.com 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.

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

[crashoveride54902]

Got an email from an, info@btcguild.com 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.

I got one too.
Be careful

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

[eleuthria]

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 support@btcguild.com (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.

[eleuthria]

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.

[MoreBloodWine]

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.

Wonder how many feelings that'll hurt lol

[Remember remember the 5th of November]

I received a phishing email today

Delivered-To: <deleted my email>
Received: by 10.152.42.232 with SMTP id r8csp132346lal;
        Thu, 6 Nov 2014 17:46:29 -0800 (PST)
X-Received: by 10.60.177.137 with SMTP id cq9mr6766581oec.45.1415324789301;
        Thu, 06 Nov 2014 17:46:29 -0800 (PST)
Return-Path: <info@btcguild.com>
Received: from mailer199.gate191.sl.smtp.com (mailer199.gate191.sl.smtp.com. [192.40.191.199])
        by mx.google.com with ESMTP id o7si5212026oeq.82.2014.11.06.17.46.28
        for <<deleted my email>>;
        Thu, 06 Nov 2014 17:46:29 -0800 (PST)
Received-SPF: fail (google.com: domain of info@btcguild.com does not designate 192.40.191.199 as permitted sender) client-ip=192.40.191.199;
Authentication-Results: mx.google.com;
       spf=hardfail (google.com: domain of info@btcguild.com does not designate 192.40.191.199 as permitted sender) smtp.mail=info@btcguild.com;
       dkim=pass header.i=@smtp.com
Return-Path: <info@btcguild.com>
X-MSFBL: ZmFybWR2ZUBkYXRhLmJnQDE5Ml80MF8xOTFfMTk5QFNlbmRCbGFzdGVyXzZA
DKIM-Signature: v=1; a=rsa-sha256; d=smtp.com; s=smtpcomcustomers; c=relaxed/simple;
   q=dns/txt; i=@smtp.com; t=1415324788;
   h=From:Subject:To:Date:MIME-Version:Content-Type;
   bh=plsX5zQy9aYdD5e23aDlwEJxNqBaSzoBtRsx9GFVHbE=;
   b=o3x8xT5U0YlsVsdhanzQvBxce/cHUr8dRPz3Jggxk6DnPLA56WK2Du4roH+rc7yg
   Kmz49XOoKQ5lTHXcClwt6bGb3fCkNCzBeZq7khADDQ0XzHi7Y9ra5N0sw5/RMTF8
   uKQyJm/k3JeWp6pP17ixW0EwoUyMsEAN8QmWUhqxelE=;
Received: from [198.72.123.97] ([198.72.123.97:62605] helo=198.72.123.97)
   by sl-mta05 (envelope-from <info@btcguild.com>)
   (ecelerity 3.3.2.44647 r(44647)) with ESMTPA
   id 67/BD-18760-4742C545; Fri, 07 Nov 2014 01:46:28 +0000
From: "btcguild" <info@btcguild.com>
Message-ID: <67.BD.18760.4742C545@sl-mta05>
Subject: [btcguild] Invoice Payment (#1232197)
To: "<deleted my username>" <<deleted my email>>
Content-Type: multipart/mixed; boundary="p=_ieZaZiIfXy6SZN2CqvmGQeWLUVhYjEp"
MIME-Version: 1.0
Date: Fri, 7 Nov 2014 01:46:26 +0000
X-SMTPCOM-Tracking-Number: 4fb914cf-9ce4-46fa-9d07-c6a9361144f8
X-SMTPCOM-Sender-ID: 25953
X-SMTPCOM-Spam-Policy: SMTP.com is a paid relay service. We do not tolerate UCE of any kind. Please report it ASAP to abuse@smtp.com

This is a multi-part message in MIME format

--p=_ieZaZiIfXy6SZN2CqvmGQeWLUVhYjEp
Content-Type: multipart/alternative;
   boundary="wy9EpkfQ=_DMTlGVSvYXIbJYUKwRetxGgA"

--wy9EpkfQ=_DMTlGVSvYXIbJYUKwRetxGgA
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

=EF=BB=BFInvoice Payment Confirmation
 Kind regards.
=20


--wy9EpkfQ=_DMTlGVSvYXIbJYUKwRetxGgA
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

=EF=BB=BF<HTML><HEAD></HEAD>
<BODY>
<P><SPAN class=3Dil>Invoice</SPAN> Payment Confirmation</P>
<P>&nbsp;Kind regards.</P>
<P>&nbsp;</P></BODY></HTML>


--wy9EpkfQ=_DMTlGVSvYXIbJYUKwRetxGgA--

--p=_ieZaZiIfXy6SZN2CqvmGQeWLUVhYjEp
Content-Type: application/octet-stream;
   name="1232197.jar"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
   filename="1232197.jar"

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.

[HPmuirt]

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

 

[Sir Alan]

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

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.