2 rigs rented. Cool service! Mux, good luck and prosperity!
Topic: [ANN] BETARIGS.COM - Cryptocurrency cloud mining - thousands of rigs available! - page 97. (Read 200998 times)
February 12, 2014, 05:12:01 PM
February 12, 2014, 03:36:01 PM
2 rigs rented. Cool service! Mux, good luck and prosperity!
February 12, 2014, 03:20:17 PM
Hi, guys! I can connect 2 rigs to 1 worker?
just use the same settings on both
February 12, 2014, 03:18:54 PM
Hi, guys! I can connect 2 rigs to 1 worker?
just use the same settings on both
February 12, 2014, 02:58:29 PM
Hi, guys! I can connect 2 rigs to 1 worker?
February 12, 2014, 10:52:03 AM
ANNOUNCE - SERVER MIGRATION
The website will be shutdown for dozens of minutes tomorrow 13 Feb at 09:00 UTC
DO NOT WORRY, THE RENTED RIGS WILL CONTINUE TO WORK FOR THEIR CUSTOMERS
I will be doing a server migration, moving to new bigger servers, which will include a DNS change -- so it may take dozens of minutes while the change is propagating to you.
Meanwhile, the rented rigs will continue to work.
The only thing is, you won't be able to rent new ones, or change existing pool parameters meanwhile.
Cheers!
Mux
Edit: For those curious, this is the page you'll get tomorrow at 9 UTC
http://www.betarigs.com/migration.php February 12, 2014, 10:47:24 AM
Yes, that is correct sir! I suppose there's a valid reason behind this
Ah I see, so mux is using the wallet address as a unique identifier in his database.
I would have thought the rig name, but I guess it makes sense.
Straight forward database change relatively speaking. It'll just depend how long his to do list is.
Good to know for the future when I finally get my second rig up.
that does not make sense, you can change the rig name, but you can change the BTC address as well,
I am sure MUX uses another unique database identifier... anything else would be cruel!
Ahah yes indeed, me using this as a DB identifier would be ... noobish
No, at the moment, the main reason is to prevent users to have problems with their online wallets : some of those do not recognized correctly when 2 amounts at the same BTC address are sent at once, in one transaction, to them.
February 12, 2014, 09:42:25 AM
Yes, that is correct sir! I suppose there's a valid reason behind this
Ah I see, so mux is using the wallet address as a unique identifier in his database.
I would have thought the rig name, but I guess it makes sense.
Straight forward database change relatively speaking. It'll just depend how long his to do list is.
Good to know for the future when I finally get my second rig up.
that does not make sense, you can change the rig name, but you can change the BTC address as well,
I am sure MUX uses another unique database identifier... anything else would be cruel!
February 12, 2014, 06:29:43 AM
are you missing the point here? That is currently not possible
So if you create a new rig in betarigs, give it a different name than the other rig....it wont let you have the same wallet address as one of your other rigs?
Yes, that is correct sir! I suppose there's a valid reason behind this
I also noticed that, would also like it if we could use 1 address for all rigs.
February 12, 2014, 04:55:42 AM
Yes, that is correct sir! I suppose there's a valid reason behind this
Ah I see, so mux is using the wallet address as a unique identifier in his database.
I would have thought the rig name, but I guess it makes sense.
Straight forward database change relatively speaking. It'll just depend how long his to do list is.
Good to know for the future when I finally get my second rig up.
February 12, 2014, 04:52:55 AM
are you missing the point here? That is currently not possible
So if you create a new rig in betarigs, give it a different name than the other rig....it wont let you have the same wallet address as one of your other rigs?
Yes, that is correct sir! I suppose there's a valid reason behind this
February 12, 2014, 04:50:25 AM
are you missing the point here? That is currently not possible
So if you create a new rig in betarigs, give it a different name than the other rig....it wont let you have the same wallet address as one of your other rigs?
February 12, 2014, 04:47:30 AM
How do I add a second rig without a second bitcoin address?
Just use the same cgminer username/password as the other rig.
Both rigs will act as one, combining their hashrate
I for one, dont want to combine my rigs but I wanna use same btc address.... Does not seem possible tho
Just create a new rig with the same wallet address then
are you missing the point here? That is currently not possible
February 12, 2014, 04:39:13 AM
How do I add a second rig without a second bitcoin address?
Just use the same cgminer username/password as the other rig.
Both rigs will act as one, combining their hashrate
I for one, dont want to combine my rigs but I wanna use same btc address.... Does not seem possible tho
Just create a new rig with the same wallet address then
February 12, 2014, 04:08:51 AM
Hey mux
Thought I would let you know the end result of a bug I logged a call on your support system for.
You sent me 2 payments to the same wallet under 1 transaction.
My wallet in this case was hosted at www.coinjar.com
Here is their response
"It appears that there were two outputs of the same address 1ME4sB8R8LziuQa3q258D7hMbSnBpCh2Xk. The first one is for 0.0199871 BTC and the second one is for 0.010682 BTC. At this moment our system can only accept unique output addresses (which is a standard practice used by the reference client), and the second one was ignored.
However, we have indeed received both transactions, so we will reimburse 0.010682 BTC to you shortly. Thanks!"
So I ended up getting my BTC which is good.
Not sure what he means by standard practise though. Whether its a problem on their side or the way your database base groups together payments for single wallets.
It seems in this case, sending 2 payments to the same wallet on 1 transaction caused the issue.
Just FYI
Thought I would let you know the end result of a bug I logged a call on your support system for.
You sent me 2 payments to the same wallet under 1 transaction.
My wallet in this case was hosted at www.coinjar.com
Here is their response
"It appears that there were two outputs of the same address 1ME4sB8R8LziuQa3q258D7hMbSnBpCh2Xk. The first one is for 0.0199871 BTC and the second one is for 0.010682 BTC. At this moment our system can only accept unique output addresses (which is a standard practice used by the reference client), and the second one was ignored.
However, we have indeed received both transactions, so we will reimburse 0.010682 BTC to you shortly. Thanks!"
So I ended up getting my BTC which is good.
Not sure what he means by standard practise though. Whether its a problem on their side or the way your database base groups together payments for single wallets.
It seems in this case, sending 2 payments to the same wallet on 1 transaction caused the issue.
Just FYI
Thanks, good to know. I'll consider this when I'll review the payment system.
Ok now I'm working on using another blockchain API to handle incoming payments...
This happened to me also, you combined 2 renting payments into one but I only recieved one of them even tho blockchain showed 2.
Filed a ticked for this but no solution has been found yet
February 12, 2014, 04:02:51 AM
How do I add a second rig without a second bitcoin address?
Just use the same cgminer username/password as the other rig.
Both rigs will act as one, combining their hashrate
I for one, dont want to combine my rigs but I wanna use same btc address.... Does not seem possible tho
February 12, 2014, 03:27:08 AM
How do I add a second rig without a second bitcoin address?
Just use the same cgminer username/password as the other rig.
Both rigs will act as one, combining their hashrate
February 11, 2014, 10:09:21 PM
How do I add a second rig without a second bitcoin address?
February 11, 2014, 05:40:21 PM
hey, a general info /warning if you are using e.g. SGMINER or newer forks!
there seems to be a bug in some miner forks with pool management, that hinders the miner from switching to the primary pool (betarigs).
If a rent is over, the primary pool (betarigs) will disconnect and become unavailable.
now the problem in the miner seems to be that if it cannot reconnect within xxx time (1-3 hours?), it will somehow disable the primary pool
that way, if the rig gets rented around that time (it shows available in betarigs), the miner will not go to betarigs pool anymore but stuck on the secondary/Backup pool
since I switched to a recent SGminer with xIntensity I am facing that problem.
So just check if you are seeing that as well. if not (what miners are you using?)
there seems to be a bug in some miner forks with pool management, that hinders the miner from switching to the primary pool (betarigs).
If a rent is over, the primary pool (betarigs) will disconnect and become unavailable.
now the problem in the miner seems to be that if it cannot reconnect within xxx time (1-3 hours?), it will somehow disable the primary pool
that way, if the rig gets rented around that time (it shows available in betarigs), the miner will not go to betarigs pool anymore but stuck on the secondary/Backup pool
since I switched to a recent SGminer with xIntensity I am facing that problem.
So just check if you are seeing that as well. if not (what miners are you using?)
I'm seeing the same problem with sgminer 4.0.0. Glad I'm not the only one.
4.0 was the first where I noticed it...
they added all kinds of pool management, I guess that must have "broken" something...
February 11, 2014, 05:11:11 PM
hey, a general info /warning if you are using e.g. SGMINER or newer forks!
there seems to be a bug in some miner forks with pool management, that hinders the miner from switching to the primary pool (betarigs).
If a rent is over, the primary pool (betarigs) will disconnect and become unavailable.
now the problem in the miner seems to be that if it cannot reconnect within xxx time (1-3 hours?), it will somehow disable the primary pool
that way, if the rig gets rented around that time (it shows available in betarigs), the miner will not go to betarigs pool anymore but stuck on the secondary/Backup pool
since I switched to a recent SGminer with xIntensity I am facing that problem.
So just check if you are seeing that as well. if not (what miners are you using?)
there seems to be a bug in some miner forks with pool management, that hinders the miner from switching to the primary pool (betarigs).
If a rent is over, the primary pool (betarigs) will disconnect and become unavailable.
now the problem in the miner seems to be that if it cannot reconnect within xxx time (1-3 hours?), it will somehow disable the primary pool
that way, if the rig gets rented around that time (it shows available in betarigs), the miner will not go to betarigs pool anymore but stuck on the secondary/Backup pool
since I switched to a recent SGminer with xIntensity I am facing that problem.
So just check if you are seeing that as well. if not (what miners are you using?)
I'm seeing the same problem with sgminer 4.0.0. Glad I'm not the only one.
Jump to: