|
My last communication with HashBuster was as recent as 4 days ago.
|
|
|
|
I just want to get the NF1 running on any os other than Windows, has anyone done this, if so can you describe the steps please? With Gentoo, you can just emerge bfgminer with the nanofury USE flag. Gentoo is not very mainstream, meaning that's probably not what Linux users of the NF1 are going to be running, it's like #37 on http://distrowatch.com/ nevertheless I will try it. I would have thought it would be tested on on a Debian or Redhat derivative by now. I've tested another HID miner on Debian with no problems, so I would be surprised if NanoFury didn't work as well. How did you get bfgminer to detect the hidapi libraries during configure? Did you have to move them from the default location /usr/local/lib/hidapi? the bfgminer configure seems to be looking for a package installed. No, Everything is under /usr/local: /usr/share/doc/hidapi
/usr/share/doc/hidapi/README.txt
/usr/local/include/hidapi
/usr/local/include/hidapi/hidapi.h
/usr/local/share/doc/hidapi
/usr/local/share/doc/hidapi/LICENSE-gpl3.txt
/usr/local/share/doc/hidapi/LICENSE-orig.txt
/usr/local/share/doc/hidapi/AUTHORS.txt
/usr/local/share/doc/hidapi/README.txt
/usr/local/share/doc/hidapi/LICENSE.txt
/usr/local/share/doc/hidapi/LICENSE-bsd.txt
/usr/local/lib/libhidapi-libusb.so.0.0.0
/usr/local/lib/libhidapi-hidraw.so
/usr/local/lib/libhidapi-libusb.a
/usr/local/lib/libhidapi-libusb.la
/usr/local/lib/libhidapi-libusb.so.0
/usr/local/lib/libhidapi-hidraw.so.0
/usr/local/lib/libhidapi-hidraw.a
/usr/local/lib/libhidapi-libusb.so
/usr/local/lib/libhidapi-hidraw.la
/usr/local/lib/libhidapi-hidraw.so.0.0.0
/usr/local/lib/pkgconfig/hidapi-libusb.pc
/usr/local/lib/pkgconfig/hidapi-hidraw.pc Note the README's FAQ entry "Q: Why can't BFGMiner find lib<something> even after I installed it from source code?" for actually running, after you get it built... |
|
|
|
I just want to get the NF1 running on any os other than Windows, has anyone done this, if so can you describe the steps please? With Gentoo, you can just emerge bfgminer with the nanofury USE flag. Gentoo is not very mainstream, meaning that's probably not what Linux users of the NF1 are going to be running, it's like #37 on http://distrowatch.com/ nevertheless I will try it. I would have thought it would be tested on on a Debian or Redhat derivative by now. I've tested another HID miner on Debian with no problems, so I would be surprised if NanoFury didn't work as well. |
|
|
|
I just want to get the NF1 running on any os other than Windows, has anyone done this, if so can you describe the steps please? With Gentoo, you can just emerge bfgminer with the nanofury USE flag. |
|
|
|
I just recently realized that I have not received a NMC payout in almost 2 weeks. I then looked at my MyEligius account, and discovered that my NMC payout address is one that I do not appear to own! How could my NMC address get changed??? I have never changed it since I initially set it - although I have set other options, like BTC payout amount.
Wizkid, can you check and see how/when my NMC address got changed? I am waiting until you look into this before I set it back to my correct payout address.
Address? |
|
|
|
Mr Wangchun have add with success the "momentum" protocol (ProtoShares) to the Minerd (cpu mining) software. https://github.com/wangchun/cpuminerCan is possibile to add it to BFGMiner ? Maybe with the GPU support too ?  I don't have time for this at the moment. Maybe if someone submits a pull request with code... |
|
|
|
|
You really spent 3 posts on trolling and FUD? Amazing.
|
|
|
|
Trying to get a Nanofury NF1 mining on Debian. Compiled 3.6.0 This is what I get: # ./bfgminer -S NFY:all -d? -D
[2013-11-19 13:10:50] setrlimit: Soft fd limit not being changed from 1024 (FD_SETSIZE=1024; hard limit=4096)
[2013-11-19 13:10:50] Started bfgminer 3.6.0
[2013-11-19 13:10:50] lowlevel_scan: Found usb device at usb:002:003 (path=(null), vid=04d8, pid=00de, manuf=Microchip Technology Inc., prod=NanoFury NF1 v0.6, serial=0000073625)
[2013-11-19 13:10:50] lowlevel_scan: Found usb device at usb:005:001 (path=(null), vid=1d6b, pid=0001, manuf=Linux 2.6.32-23-pve uhci_hcd, prod=UHCI Host Controller, serial=0000:00:1d.3)
[2013-11-19 13:10:50] lowlevel_scan: Found usb device at usb:004:001 (path=(null), vid=1d6b, pid=0001, manuf=Linux 2.6.32-23-pve uhci_hcd, prod=UHCI Host Controller, serial=0000:00:1d.2)
[2013-11-19 13:10:50] lowlevel_scan: Found usb device at usb:003:001 (path=(null), vid=1d6b, pid=0001, manuf=Linux 2.6.32-23-pve uhci_hcd, prod=UHCI Host Controller, serial=0000:00:1d.1)
[2013-11-19 13:10:50] lowlevel_scan: Found usb device at usb:002:001 (path=(null), vid=1d6b, pid=0001, manuf=Linux 2.6.32-23-pve uhci_hcd, prod=UHCI Host Controller, serial=0000:00:1d.0)
[2013-11-19 13:10:50] lowlevel_scan: Found usb device at usb:001:001 (path=(null), vid=1d6b, pid=0002, manuf=Linux 2.6.32-23-pve ehci_hcd, prod=EHCI Host Controller, serial=0000:00:1d.7)
[2013-11-19 13:10:50] Devices detected:
[2013-11-19 13:10:50] Timers: Using clock_gettime(CLOCK_MONOTONIC_RAW)
0 devices listed
So it can detect the NF1 but says it's disabled. Any ideas? Looks like you built without nanofury support. That's the default if you're missing the hidapi dependency... (README) |
|
|
|
My suggestion around luke's patch would be the following.
Create a BIP32 key/pair and supply the public part of the key.
Every implementation of the Mastercoin protocol should use this chain and check a list of addresses based on transaction volume of the last 25 blocks. We would start with a gap limit of 50 and retarget this number if the average volume across the last 25 blocks was more then half of this number to avoid collisions. We could also just hardcode a list but this solution should offer a bit more scaling and save some CPU cycles.
Luke is an idiot. We will always find the design around strategy. Mike Hearn listens carefully each day to important information which will make bitcoin work for all - including organized society. Anarchists like Luke - who don't sit in these important meetings - who don't consider both sides of the story - who aren't invited to talk to congress about what is going on - force these rules of idiots. Luke will lose every time. Mike Hearn and congress will find a nice middle road which works for all of society. Anarchists will not interrupt good progress no matter how hard they try. And if Luke tries to stuff it to the Mastercoin protocol, it will take guys like Tachi 5 minutes to write a few lines of code and put Luke back in his place. Trying to stop progress is like trying to unring a bell. Mastercoin is progress on the bitcoin foundation and Luke will not be successful in his attempts to stop it. LOL thanks, this is hilarious... send me a PM next time. |
|
|
|
Isn't the thing you're describing basically just a less-decentralized version of what p2pool already does by its very nature? GBT is just as decentralised as p2pool. And unlike p2pool, GBT doesn't require the overhead of p2p. (and p2pool even manages to do GBT correctly from a python script, but without 100% cpu load at relatively modest hashrates) Good luck getting p2pool to work in KnC BBB hosts... |
|
|
|
This is why decentralised mining is so important. When I finish GBT, pools won't have nearly as much influence as they do now.
Thanks, Luke. I will read BIP 22 and BIP 23 carefully. Currently I am curious how you find a balance between giving back block creation right to the miners and avoiding selfish miners to hide the blocks they find for themselves. I am sure I can find answers in 2 BIPs written by you. The miners still send the pool a proof-of-work including proof the pool is being paid for the reward. |
|
|
|
|
This is why decentralised mining is so important. When I finish GBT, pools won't have nearly as much influence as they do now.
|
|
|
|
For some reason, unbeknownst to me, my Red Fury device is not hashing... Can anyone help? I have installed the drivers and bfgminer but can't seem to mine... Please paste output from: bfgminer -S bigpic:all -d? -D |
|
|
|
I like the idea of GBT in general- it enforces some honesty on pool operators (not that any of them are dishonest, to my knowledge  ) Even if you assume the pool operator is perfectly honest, blind pooling makes the servers an excellent target for someone to break into... If you can double-spend enough, it might even be profitable to organise a hold-up of all the big pool operators and force them to let you access the servers so you can do a 10-deep reorg or so. Fully implemented GBT will make this kind of attack impractical, thus giving pool operators more personal security too.  But no one has fully implemented GBT - even you - even though it's been around for how looooooooooong. Only due to lack of time. It's a shame you and Con don't like collaboration, otherwise I might have more time to finish other things like this... It would also be ideal to give some probability and statistical information about such an attack rather than blatantly ignoring that which determines the value of your comment ... Probability of course always increases with price. Yes you can also do the equivalent of a 50% attack on BTC with 100GH/s ... What? ... GBT is entirely unoptimised right now, so there's a possibility of improving it. In theory, I should be able to reduce its CPU load to approximately the same as stratum's. Just need to find the time... Why? There's been no need to optimise it. Only recently have people been producing (this degree of) standalone miners with underpowered controllers builtin. I guess I should have seen it coming with Avalon1/cgminer failing even with stratum when coinbases got larger... |
|
|
|
About the minimum payout: Something I would really like would be able to make auto-payout at a given frequency instead of a given amount. I've chosen my auto-payout amount such as I get payout every two weeks, but I keep adjusting the amount because of the constant increase of difficulty. So I'd be really happy if I could indicate I wish to be paid every two weeks, whatever my balance is at that point. I don't think basing your minimum payout on difficulty is a good idea. You want to have the same size coins coming in, as going out. So if you spent $1 amounts all the time, it makes sense to have payouts around $1 worth of bitcoins. On the other hand, if you buy more products at $500 value, you'd want a minimum payout close to that. $20 value seems like a reasonable expected-spending price, hence the default. Side note: Contrary to popular myth, difficulty increases do not influence price. Price does influence difficulty to a degree, but difficulty is so far behind price right now that it's not a good feedback loop. |
|
|
|
Wouldnt doing this provide further economic justification for selfish mining, as the researchers call it, because people whose tx are deprioritized will have further economic incentive to alter the blockchain?
I think you guys should really think things through a few steps ahead, the 2nd and 3rd order effects. Even if it was the original intention to not reuse addys, it was never enforced, and changing the rules now, changes the dynamics of the system possibly in unpredictable ways.
The rules aren't being changed. The rules are encoded in the protocol. Changing them requires a hard fork. The rules have ALWAYS allowed miners to choose which tx to include in a block (including none) and under what criteria they will be ranked/sorted/selected. The patch simply gives miners an effective way to use the power they are already granted by the "rules" of the game. Minor correction: changing the rules in this case only requires a softfork. |
|
|
|
I like the idea of GBT in general- it enforces some honesty on pool operators (not that any of them are dishonest, to my knowledge ) Even if you assume the pool operator is perfectly honest, blind pooling makes the servers an excellent target for someone to break into... If you can double-spend enough, it might even be profitable to organise a hold-up of all the big pool operators and force them to let you access the servers so you can do a 10-deep reorg or so. Fully implemented GBT will make this kind of attack impractical, thus giving pool operators more personal security too. |
|
|
|
I am using the version 3.4.0 BFGMiner that is distributed as part of Bertmod 0.3 on my KnCMiner Saturn. I added the lines: "coinbase-addr": <my payout address>,
"coinbase-sig": <My block sig>
to the end of the config file, because I wanted to solo mine on my local bitcoin-qt. It doesn't generate any errors, but the hashrate goes down from ~285 GH/s to more like 10 GH/s  If I remove the above two lines, it goes back to normal. Anybody have any idea what is going wrong here? Is it using 100% CPU, or less? I wonder if the BBB can't keep up with generating work via GBT... Yeah, looks like that's it - always over 95% CPU when GBT is enabled, ~22% otherwise. Bummer. GBT is entirely unoptimised right now, so there's a possibility of improving it. In theory, I should be able to reduce its CPU load to approximately the same as stratum's. Just need to find the time... |
|
|
|
|
Admittedly, the deprioritisation could be done much better.
The problem is, the code that creates the blocks is a total mess, and rewriting it is a sensitive area that would be a real pain to get merged, even with no behavioural changes.
So, it's easier for a miner to see that this patch won't make invalid blocks, than it would be if I started touching that code.
|
|
|
|
|
I think wizkid057 should reduce the default minimum payout to 40 TBC (0.04194304 BTC) instead of the current 100 TBC.
When I ran Eligius, I was targeting about $20, so this fits with that original goal, at the current price.
Yay/nay?
|
|
|
|
|
Show Posts
