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

[MoreBloodWine]

Saw latest news item, just how much of the current guild hash is in New York would you say ?

[1713974274]

1713974274

[1713974274]

1713974274

[1713974274]

1713974274

[1713974274]

1713974274

[1713974274]

1713974274

[1713974274]

1713974274

[eleuthria]

Saw latest news item, just how much of the current guild hash is in New York would you say ?

I'm guessing very, very little.

[MoreBloodWine]

Saw latest news item, just how much of the current guild hash is in New York would you say ?

I'm guessing very, very little.

So if you can't say for sure, then how would you enforce a new TOS ?

[eleuthria]

Saw latest news item, just how much of the current guild hash is in New York would you say ?

I'm guessing very, very little.

So if you can't say for sure, then how would you enforce a new TOS ?

It will require an affirmitive "I am not a resident of the state of New York" and "I do not run any of my equipment from within the state of New York" before allowing you to register a new account, and existing accounts will have to affirm that within a certain time frame or else the account will be frozen.

I will also be adding IP-range lockouts for known New York IP addresses which will give a splash page stating that New York residents are forbidden from using the pool.

[MoreBloodWine]

Saw latest news item, just how much of the current guild hash is in New York would you say ?

I'm guessing very, very little.

So if you can't say for sure, then how would you enforce a new TOS ?

It will require an affirmitive "I am not a resident of the state of New York" and "I do not run any of my equipment from within the state of New York" before allowing you to register a new account, and existing accounts will have to affirm that within a certain time frame or else the account will be frozen.

I will also be adding IP-range lockouts for known New York IP addresses which will give a splash page stating that New York residents are forbidden from using the pool.

Ok, but for the users that sneak through, and there will be a few. Would the pool be protected from actions against it ?

[eleuthria]

Saw latest news item, just how much of the current guild hash is in New York would you say ?

I'm guessing very, very little.

So if you can't say for sure, then how would you enforce a new TOS ?

It will require an affirmitive "I am not a resident of the state of New York" and "I do not run any of my equipment from within the state of New York" before allowing you to register a new account, and existing accounts will have to affirm that within a certain time frame or else the account will be frozen.

I will also be adding IP-range lockouts for known New York IP addresses which will give a splash page stating that New York residents are forbidden from using the pool.

Ok, but for the users that sneak through, and there will be a few. Would the pool be protected from actions against it ?

Pro-actively blocking a state, and requiring users to affirm they are not from that state should be adequate in preventing the state from trying to establish a nexus when there are clear attempts to prevent that state from accessing it.

[ManeBjorn]

It is looking more like you would not have to even worry about that as they do not intend to encompass mining pools and services.

Saw latest news item, just how much of the current guild hash is in New York would you say ?

I'm guessing very, very little.

So if you can't say for sure, then how would you enforce a new TOS ?

It will require an affirmitive "I am not a resident of the state of New York" and "I do not run any of my equipment from within the state of New York" before allowing you to register a new account, and existing accounts will have to affirm that within a certain time frame or else the account will be frozen.

I will also be adding IP-range lockouts for known New York IP addresses which will give a splash page stating that New York residents are forbidden from using the pool.

[eleuthria]

It is looking more like you would not have to even worry about that as they do not intend to encompass mining pools and services.

They will never provide an exact definition of "financial services".  I would say a pool probably is a financial service, though it certainly isn't the kind they're targeting.  All we can do is wait to see what the next form of BitLicense looks like and then adjust as necessary.

[eleuthria]

There was a very brief interruption of service for about 20% of miners.  One backend lost its bitcoind connection to the other backends (used to virtually eliminate the chance of two pool servers orphaning each other's blocks) and a restart was triggered.  Everything is working normally again, and it should have only impacted about 1 in 5 connections.  If it did affect you, it likely only lasted a few seconds (long enough to reconnect and have the load balancer put you on a different node).

[MoreBloodWine]

There was a very brief interruption of service for about 20% of miners.  One backend lost its bitcoind connection to the other backends (used to virtually eliminate the chance of two pool servers orphaning each other's blocks) and a restart was triggered.  Everything is working normally again, and it should have only impacted about 1 in 5 connections.  If it did affect you, it likely only lasted a few seconds (long enough to reconnect and have the load balancer put you on a different node).

So the restart was just on the one server then and not the pool as a whole ? In any event, that explains my one miners hiccup.

[eleuthria]

There was a very brief interruption of service for about 20% of miners.  One backend lost its bitcoind connection to the other backends (used to virtually eliminate the chance of two pool servers orphaning each other's blocks) and a restart was triggered.  Everything is working normally again, and it should have only impacted about 1 in 5 connections.  If it did affect you, it likely only lasted a few seconds (long enough to reconnect and have the load balancer put you on a different node).

So the restart was just on the one server then and not the pool as a whole ? In any event, that explains my one miners hiccup.

Correct.  When you connect there's two phases.  The first phase is a botnet/DDoS filter.  Then you get redirected to the pool's load balancer, which will put you on one of five physical servers.  One of those five had the issue.  The load balancer is extremely efficient at keeping each server within +/- 5 connections of each other, so one server going down will take out almost exactly 1/5th the connections, and the load balancer will redirect them to the next available server upon reconnect.

[ManeBjorn]

That would suck I am from NY and really do not want to lose access to the best pool.
I hope they get it figured out.
My question to you is will you file a comment during the commenting period outlining your concerns so that it can be clearly written in relation to this?

It is looking more like you would not have to even worry about that as they do not intend to encompass mining pools and services.

They will never provide an exact definition of "financial services".  I would say a pool probably is a financial service, though it certainly isn't the kind they're targeting.  All we can do is wait to see what the next form of BitLicense looks like and then adjust as necessary.

[Petete]

Hello, I have a question regarding hidden workers. If one of my workers connects to the pool but is hidden, will its shares count on my balance? I ask because I have one worker which only connects to BTCGuild as failover pool, and I set it hidden because I have Idle Workers notifications enabled.

[eleuthria]

Hello, I have a question regarding hidden workers. If one of my workers connects to the pool but is hidden, will its shares count on my balance? I ask because I have one worker which only connects to BTCGuild as failover pool, and I set it hidden because I have Idle Workers notifications enabled.

Hidden workers are fully functional.  They simply don't get shown on your dashboard, worker charts, or the API.

[RoadStress]

The following will be posted on the Eligius, BTCGuild and P2pool threads.

How willing are the pool operators to implement this? Is it hard? Any downsides? Please discuss

My position is that every periodic payment should be done using deterministic key pair generation.  Of course this includes all mining payouts.  The way this would work is that instead of generating a normal private/public key pair and giving the Bitcoin address of the public key to your mining pool for payout you would generate an extended private/public key pair and give the extended public key to the mining pool.

An extended public key contains within it the first public key and information on how to generate an entire sequence of public keys that correspond to the same key pair sequence that is generated by the extended private key.  So the mining pool would send your first payment to the first public key, your second payment to your second public key, your third payment to your third public key, etc.

Meanwhile your client can generate the first private key that corresponds to the first public key, the second private key that corresponds to the second public key, etc. so you can claim/spend the BTC when you are ready.

This way every single periodic payment can be sent to a unique public address.  Cool, right?

However, I do not know of a single pool that supports this payment mechanism.  I do not keep up with all the various mining pools having given up mining at the end of the GPU mining era myself.  So, if there is a pool that supports this please let me know.

All miners should demand this from every pool they use and only use pools that support this mechanism.

[eleuthria]

The following will be posted on the Eligius, BTCGuild and P2pool threads.

How willing are the pool operators to implement this? Is it hard? Any downsides? Please discuss

I looked into it a long time ago, but at this point I'm not looking at touching the code which handles payouts.  If something goes wrong, there is no way the pool would recover from the loss without it affecting the users.

[ManeBjorn]

I dont want a 1000 addresses for payouts.
It can be good for those that do but I do not.
I have my addresses set to I can keep track of the mining revenue and not have to slog through so many.
A good idea it is just as long as it is not mandatory.

The following will be posted on the Eligius, BTCGuild and P2pool threads.

How willing are the pool operators to implement this? Is it hard? Any downsides? Please discuss

My position is that every periodic payment should be done using deterministic key pair generation.  Of course this includes all mining payouts.  The way this would work is that instead of generating a normal private/public key pair and giving the Bitcoin address of the public key to your mining pool for payout you would generate an extended private/public key pair and give the extended public key to the mining pool.

An extended public key contains within it the first public key and information on how to generate an entire sequence of public keys that correspond to the same key pair sequence that is generated by the extended private key.  So the mining pool would send your first payment to the first public key, your second payment to your second public key, your third payment to your third public key, etc.

Meanwhile your client can generate the first private key that corresponds to the first public key, the second private key that corresponds to the second public key, etc. so you can claim/spend the BTC when you are ready.

This way every single periodic payment can be sent to a unique public address.  Cool, right?

However, I do not know of a single pool that supports this payment mechanism.  I do not keep up with all the various mining pools having given up mining at the end of the GPU mining era myself.  So, if there is a pool that supports this please let me know.

All miners should demand this from every pool they use and only use pools that support this mechanism.

[os2sam]

The following will be posted on the Eligius, BTCGuild and P2pool threads.

How willing are the pool operators to implement this? Is it hard? Any downsides? Please discuss

I looked into it a long time ago, but at this point I'm not looking at touching the code which handles payouts.  If something goes wrong, there is no way the pool would recover from the loss without it affecting the users.

And from that explanation it seems to me that may divulge enough information to help discover your original private key being that the range of sequential keys are based on it.  It's not good security policy to divulge any more information than absolutely necessary.

[xstr8guy]

Check your payout addresses! Someone has changed mine to 148z3Qq6KzSVjca8xzXPWHMPBuWm2bqEQz And stole from my BTCGuild account. They've also locked it and I can't change it back. First Lunamine and now this. 

[RealMalatesta]

Check your payout addresses! Someone has changed mine to 148z3Qq6KzSVjca8xzXPWHMPBuWm2bqEQz And stole from my BTCGuild account. They've also locked it and I can't change it back. First Lunamine and now this. 

Have you used the same address and/or password for Lunamine as well as for BTC Guild?