I don't understand why there is confusion. We are participating in a GROUP buy and in the opening post Soniq clearly states "Each share entitles the owner to 1/360th* of the BTC proceeds from the group of 12 KNC Jupiter's mining 24/7 till no longer profitable or sold (less expenses and management fees)". Since we got to 9 Jupiters, each share entitles to 1/270 of the BTC....
As participants we pro rata share the costs and the income, no matter when we stepped in.
The equality was for me to reason to step in.
while that seems nice as we receive a bigger share, why dont we let soniq clarify that. The share might be bigger, but you do realize the income is also lower with 9 Jupiters compared to the income of 12 Jupiters ? |
|
|
|
|
I don't understand why there is confusion. We are participating in a GROUP buy and in the opening post Soniq clearly states "Each share entitles the owner to 1/360th* of the BTC proceeds from the group of 12 KNC Jupiter's mining 24/7 till no longer profitable or sold (less expenses and management fees)". Since we got to 9 Jupiters, each share entitles to 1/270 of the BTC....
As participants we pro rata share the costs and the income, no matter when we stepped in.
The equality was for me to reason to step in.
|
|
|
|
If you havnt already download Bit Message, will be using this for contacting shareholders about updates, payments and trading shares
I can't get Bit Message to run on OSX. So I'll appreciate it if messages are posted here too. |
|
|
|
Could it be they sold the BTC address to for example Zuckerberg and have a deal about extra BTC coming in ?
? We have some users making heavy use of Silk Road in here LOL |
|
|
|
|
Could it be they sold the BTC address to for example Zuckerberg and have a deal about extra BTC coming in ?
|
|
|
|
|
Have you even looked around on the forum ? There are at least 10 options to make boards or even complete machines of those chips.
|
|
|
|
|
I am trying to understand the payout, which is a bit unclear.
Suppose in total 10 miners in the GB, and I buy 25 shares, 12.5 BTC.
10 x 124 = 1240 shares; so I would get 25/1240 piece of the income of the miners for 24 months ?
10 x 350 = 3500 GH; 25/1240 * 3500 = 70.5 GH for 12.5 BTC ?
Anything I missed ?
|
|
|
|
|
You'll probably have them in an USB hub. Just add a USB fan to the setup. I am cooling four of them with a single fan.
|
|
|
|
First, it is not yet a loss: Avalon might decide to check one day and refund me the coins. Or send the chips, which would be an even better outcome. |
|
|
|
|
Better is ./reaper 2>&1 | tee -a my.log &
You'll then also catch all error messages(2>&1) in your logfile and append(-a) it to your logfile if the logfile already exist. This way you will not overwrite your logfile if you start reaper again.
Without 2>&1, you'll only log all standard output messages in your logfile.
BTW, the error in your first command line was that you were starting reaper in the background(./reaper & ) and an empty command(> mylog.log) that was sending its output to your logfile, hence your logfile was empty.
|
|
|
|
Pool stabilized (as if I did something...  ) and two blocks found as of now for today. spiccioli ps. so, stop wondering and point your hashing machines here! Sorry spiccioli, but that's too simple. I want to know how a pool handles its shares and payout and for this pool it's not clear to me, the information on the website is outdated and fireduck is missing in action. |
|
|
|
i'm planning on running my USB miners plugged straight into my litecoin mining rig (2 front mounted USB ports (2 miners ordered) - although i'm concerned about power - should i get a powered USB hub? i have also got a raspberry Pi that i have thought about using too - any recommendations?)
I think your PC will have enough power to supply juice to the USB ports for the miners. With your Raspi you'll need a powered hub for sure. IIRC the Raspi only supplies 100mA to the USB ports (in total?). |
|
|
|
|
So what I conclude and what others might also find useful is that I should not think of solving a block, but more of computing hashes of a bunch of data until the golden nonce is found. The data is not linked to one particular block, it's just a bunch of bytes, that change during the search for the golden nonce(either the nonce increases, or a block is found by another node and then the data changes even more).
The data becomes a block once the nonce is found and has been added to the blockchain.
It could then still become an orphan, but that's another story.
Before the golden nonce is found, I shouldn't even be thinking of the data as being a block.
|
|
|
|
|
Thanks for your clear answers, exactly as I suspected.
|
|
|
|
|
I had a similar problem with my Ztex on the Raspi. I reloaded the firmware while the Ztex was connected to a windows machine and then connected it to the Raspi again. Problem was solved.
So reload the firmware like the previous poster suggests and it will probably be solved.
|
|
|
|
|
I have been looking for the real answer and haven't found it.
How do they all come together.
Let me try and you correct me.
We have 2 miners, M1 to M2.
We have 100 transactions, T1 to T100.
We have 2 blocks, B1 and B2
My questions:
1. How does a miner chooses which transactions of the available 100 to include, is this done by bitcoind, and configured (minimum fee?) in bitcoin.config and/or command line options ?
2. Transactions are put in a block. Let's assume M1 is mining B1 and M2 is mining B2. Is there a mechanism that prevents T1 to be in both B1 and B2, or is it allowed for T1 to be in both B1 and B2 ?
3. What happens to M2/B2 if M1/B1 finds the golden nonce ? Does M2 have to create a new block which excludes all the transactions validated in B1, or is it ok to have T1 in both B1 (that has just been validated) and B2, which is still to be validated ?
4. If 3 is OK, where does B2 fit in the blockchain once it's validated because B2 has a reference to the previous block in the chain and B1 now sneaked in.
5. If 3 is not OK, is all the work that M2 has done on B2 a waste because it has to create a new block and start finding the golden nonce on the new block ?
|
|
|
|
IMO if we go for an overclocking option, it should be software controllable and then a temp sensor is mandatory. I like the way Ztex has implemented it for there FPGA boards, the software chooses a balance between hw errors and speed. Likewise we should go for a temp/hw errors controlled overvoltage and maybe also speed?
BUT, al this is nice to have, if it becomes too difficult, risky or fragile, we should KISS.
Post 1 says the fan will be temperature controlled, so the sensor should be already there? True, forgot that due to all the discussion about voltage ;-) |
|
|
|
|
IMO if we go for an overclocking option, it should be software controllable and then a temp sensor is mandatory. I like the way Ztex has implemented it for their FPGA boards, the software chooses a balance between hw errors and speed. Likewise we should go for a temp/hw errors controlled overvoltage and maybe also speed?
BUT, al this is nice to have, if it becomes too difficult, risky or fragile, we should KISS.
|
|
|
|
|
Show Posts
