Security can be guaranteed - the user can make the page offline-available
*Go offline on his “normal” pc, creates a adress - deletes his browser cach ect.
* ideally generate the key pair from a computer that is not connected to the internet. you’d do that by going to bitaddress.org and unplugging your ethernet cord from the wall before generating the keypair. even this won’t protect you from preloaded malware
2 secure ways - which works for other currencies also!!
Client v.0.6.4 can be set to use 0.00 FTC transaction fee if that makes you happy. I’m not sure what “policy” you’re looking for here, this is an online coin, if Bush wanted he could set the fee to 50 FTC…
To make a transaction, a input (an address which has received coins) with the sufficient amount is selected. At this time, the input is ‘spent’ in total… you can’t just spend part of an input.
So if that input has MORE than your sending, another output is generated with the remainder (the original amount of the input minus what you’re sending)… often back to the original address. So later, that new output (the change you sent yourself), is your new input when you go to spend from that address again.
This was a very intentional design, because any input can always be spent if it hasn’t already, and there’s no need to go back and look at how much as already been spent from that address: All the unspent inputs == your total holdings, no need to subtract spent outputs.
accepted share are the accepted submission and the diff is the multiplier of the base unit of work. the diff is just to prevent submitting a very large number of work proof
so yes your accepted share * pool diff should be your shared difficulty.
similar to block when you find a 31 diff on the pool it should on average takes 31 more time then finding a base unit of work. Diff is different from one miner to the other in var diff you get a pool diff. a good diff with var diff should give you a diff that provide regularly a good average of the work done over some hour without submitting constantly low diff share or not submitting enough share to get a representative average. ()
when a block is found all shared difficulty are added for all miner in the pool. so your shared diff/all miner shared diff give your part of the work done on the block.
note: the share diff don’t care the real difficulty of what you fond, it just care it’s over the diff and assign the diff to it so you get a work unit done that is at least the pool diff
Try running cgminer --benchmark and see what u get, it should be a good score. Mining BTC seems to work fine under OSX but scrypt is really bad for some reason.
If you run the same cgminer --benchmark --scrypt you will get ~10kh/s or less, tweaking gets it upto a max of 100 or so on the 5770 which is still bad, I get about 150mh/s on my debian server using a 5770.
I am trying with a 7850 on OSX (Yes hackintosh). On linux I can get over 300 kh/s just adjusting the -I setting.
On OSX I get massive HW error setting the I over 11. At best I can get about 60kh/s
It seems like something is really broken with the scrypt implementation on OSX.
I had a similar experience with an Asrock Mobo.
No signal from my ati 5860 card
I had to update the bios to get any display signal.
Once the bios was flashed I had a working system- I sent one card back before I figured this out!
Getting the correct open cl drivers loaded to successfully mine was another story.