is it a good assumption the payout queue is down  Doing some maintenance That last payout, seems to be taking a long time to verify, its only been seen by 1 peer after 4 hours. Makes no sense since every Eligius payout is in a block. So, wherever you got that information from is providing useless info... Could only part of the block take longer to confirm than other parts? Nope. Uhhh... yes? Generation transactions always take >=100 blocks to confirm, while others are subjective to wallet/human decision on when they confirm. Everything in the block receives the same numbet of confirmations though, which is what I was getting at. Confirmation is a (fuzzy) boolean, not a number  |
|
|
|
is it a good assumption the payout queue is down Doing some maintenance That last payout, seems to be taking a long time to verify, its only been seen by 1 peer after 4 hours. Makes no sense since every Eligius payout is in a block. So, wherever you got that information from is providing useless info... Could only part of the block take longer to confirm than other parts? Nope. Uhhh... yes? Generation transactions always take >=100 blocks to confirm, while others are subjective to wallet/human decision on when they confirm. |
|
|
|
Standard transactions:
OP_RETURN: allow up to 80 bytes Do you know of any other pool that follows your lead? No, I'm not aware of any other pools actually making policy decisions. They all seem to be "forcing" that decision on to the reference defaults. Non-standard transactions:
P2SH, by request at admin discretion, or 100 TBC per 512 bytes rounded up Hm? Eligius will consider P2SH as non-standard? Or non-standard scripts embedded in P2SH? There is a general movement within the mainline codebase to remove the IsStandard check for P2SH-embedded scripts in 0.10. The "P2SH" here is the intention to deploy that on Eligius "now". |
|
|
|
NEW VERSION 4.9.0, OCTOBER 5 2014Please note that the new Titan driver is maintained by KnCMiner, and neither nwoolls nor myself can provide support for it. Human readable changelog:- titan: Driver for KnCMiner's scrypt ASIC machine.
Full changelog:- Upgraded Windows libraries:
- libcurl from 7.37.0 to 7.38.0
- libusb from 1.0.18 to 1.0.19 (Win64 only)
- mingw64-runtime from 3.1.0 to 3.2.0 (Win64 only)
- uthash from 1.9.7 to 1.9.9
- Travis: Update for titan driver
- configure: Accept --enable-titan=CONTROLLER to select controller
- make-release: Remove unnecessary knc-asic/{*.rbf,*system,waas} from release source
- extra_work_queue so devices can influence their effect on the central work queue somewhat (titan needs less than 1-per-proc)
- Avoid adding include paths for titan driver
- Bugfix: titan: Add missing printf formatting for core busy status
- avalon: Drop custom hexdump logging
- Build titan driver independently from knc (Jupiter) driver
- titan: Do not fill up next slot immediately after urgent setwork
- titan: Pre-fill work queue so that all ASICs have fresh jobs after a flush
- Build instructions for KnC Titan
- Doesn't compile without explicitly included inttypes.h on some machines
- knc-asic: Updated to e5c986d3c44fde8c5b069508ef6979f2f2be92d6
- Fix Makefile.am to build bfgminer for titan
- titan: Subdivide full nonce range only between cores in one ASIC (because works are now distributed per-ASIC too)
- titan: DC/DCs does not like broadcast flushes (urgent setwork). Do not do it!
- titan: Preparation to setting threads-per-core externally, by user
- titan: Re-flush cores in case of slot number collision
- titan: Per-ASIC flush, per-ASIC work management
- titan: Start cores after flush individually, not by broadcast.
- titan: Default frequency is 275 MHz
- titan: Difficulty is offset by one in ASIC cores.
- titan: Fix first_proc pointer
- titan: Use 2 threads per core
- titan: Use setup_core from knc-asic library
- titan: Poll all enabled ASICs amd dies, not only one
- titan: Properly set work_accepted flag
- titan: Hint detection function about expected device type
- titan: Fix setup_core command
- titan: Use knc-asic library for transport layer
- Add knc-asic as submodule
- titan: Change spi device to spidev1.0
- titan: Add define to .h file
- titan: Increase workqueue size up to number of slots per core
- titan: Send data to hashmeter
- titan: Disregard stale reports after flush
- titan: Check for next asic/die switch when processing info results
- Bugfix: titan: Fix segfault
- titan: Set actual hardware nonce_diff for works in prepare_work
- titan: Do clean flush ("purge") on init
- titan: Store last_nonce right
- titan: First attempt to process nonce responses
- titan: Change 'scanhash' minerloop to 'queue'
- titan: Init all cores for their own nonce ranges
- titan: For RPi we use spidev0.1
- titan: Setup_core command implemented
- titan: New commands set_work & get_report
- titan: Move asic-specific functionality to the separate file (titan-asic.c)
- titan: First ugly detect of Titan chip over SPI
- knc-titan: Begin work on Titan (scrypt miner) driver
- libbase58: Use git URI for submodule to avoid failure on systems without HTTPS support
- Travis: Cross-compile a Win64 build
- RPC: Initialise json_config to silence false warning
- Make sure MOUSE_MOVED from wincon is ignored (it conflicts with curses)
- Travis: Perform full builds with libbase58's base58 tool (which is used for tests)
- Travis: Test many configuration variations
- Travis: Build with libsensors and VFIO
- Travis: Upgrading GCC triggers locale rebuild, so just do the one in use
- Travis: No need to upgrade GCC for LLVM build
- Travis build configuration
- Run BFGMiner's unit tests for 'make check', and have --unittest exit with failure if any problems occur
- libbase58: Update to pick up on LLVM fixes
- Bugfix: configure: Affect gridseed driver with --disable-other-drivers
- Bugfix: configure: minergate driver needs lowlevel for claiming sockets
- Bugfix: configure: --disable-other-drivers should not affect non-driver options
- Bugfix: configure: --with[out]-vfio needs $withval, not $enableval
- Bugfix: rockminer: Correct types for short read error message
- Bugfix: icarus: fix the STATS RPC API call crashes with a multi-proc device
- Bugfix: cointerra: Check lowlevel device is USB before trying to probe it (as USB)
- bitforce: Reinstate device work inprogress count sanity check for 28nm devices
- littlefury: Read uC temperature sensor
- littlefury: Keep track of enabled chips and power state explicitly in case of trouble
- Bugfix: async minerloop fix for devices disabled at start
- twinfury: Implement device protocol dump more low-level
|
|
|
|
Quick question: Is it possible to request a higher difficulty by default in BFGMiner?
Yep, see --request-diff in README. Most (all?) pools ignore the request, though. Ok. Banging on the code for the BFL Monarchs. Still need to fix the highly annoying error where it gets stuck, drives me nuts that the custom 4.2 64 bit code works perfectly but the 4.8 has queueing problems. Can you bisect that issue? |
|
|
|
Quick question: Is it possible to request a higher difficulty by default in BFGMiner?
Yep, see --request-diff in README. Most (all?) pools ignore the request, though. |
|
|
|
Summary of the Eligius mining policy meeting: - Transaction filtering:
- Mark outputs spent in others’ mempools for not mining (prevent policy abuse)
- Spam pkh matching: current policies
- Dust: ban regardless of fee
- Bare multisig: ban (no change)
- Non-softfork-safe: ban
- Non-shortest-pushop: ban
- Standard transactions:
- OP_RETURN: allow up to 80 bytes
- Transaction priority:
- p2pkh/p2sh: deprioritise address reuse
- Hash randomness testing: influence priority
- Non-standard transactions:
- P2SH, by request at admin discretion, or 100 TBC per 512 bytes rounded up
- Transaction fees:
- 0.1 TBC per 512 bytes, without rounding, up to 128 KB block
- >128 KB blocks, logarithmically increase min fee rate to 10 TBC
- Tx size discounts for UTXO reduction: not for the moment
Note: These will probably take some time to implement, and are not live yet. |
|
|
|
I think you are taking what Danny Hamilton said out of context.
This thread started off with an improper contrast with importing to Bitcoin-Qt, which is also equally dangerous. He is correct that importing to bitcoind is not more dangerous. But it remains dangerous no matter what wallet you import to. |
|
|
|
End users should never manage ECDSA private keys. Doing so, especially importing, is likely to lead to loss of bitcoins.
Can you elaborate further? I am not sure what you mean by manage? I think users should manage their own keys. Like making paper wallets or making a backup of the online wallet keys, to name a few. To use those coins on those addresses when we need to, importing them into a client is an inevitable process. Do you expect end users to use only bitcoin core and only backup by having multiple copies of wallet.dat? Yes, backups should always be of an entire wallet, not of individual keys. End users should never manage ECDSA private keys. Doing so, especially importing, is likely to lead to loss of bitcoins.
See Danny Hamilton's response above, importing is NOT likely to lead to loss of bitcoins. What are you talking about? No, he clearly states: If you don't understand why, then you should not be importing private keys.
If you do understand why, then you realize the importance of knowing absolutely for certain that a process works the way you think it does before you start messing around with your money. This is what "dangerous" means. |
|
|
|
|
Perhaps it can be phrased better. The important thing is that it conveys that importing private keys is dangerous and shouldn't be done.
|
|
|
|
|
End users should never manage ECDSA private keys. Doing so, especially importing, is likely to lead to loss of bitcoins.
|
|
|
|
Need drivers for AntMiner S3's bad.
Don't even have a S3 here... |
|
|
|
BFGMiner 4.6 (just released) can now support Avalon2 devices - even alongside other devices or more Avalon2 devices.
Do you have decent fan logic/thermal control? The stock avalon2 cgminer driver has a limitation where fans don't ramp until >59degC which is just way too hot for my application. I'm not sure that's something the host has control over... |
|
|
|
How can I use bfgminer with rockminer T1? It has a specific controller. How to connect it with other system, like PC or RpI.
Run BFGMiner with --stratum-port 3333 Then point your T1 controller at the PC's IP and that port, with a unique username. |
|
|
|
I've setup a local stratum server using eloipool. I'm trying to test the stratum server manually using either telnet or curl as in: curl --data-binary '{"id": 1, "method": "mining.subscribe", "params": []}' -H 'content-type:text/plain;' http://myuser:mypassword@127.0.0.1:3334/The connection is closed as soon as the first line of the http headers is sent (usually POST) (curl prints: curl: (52) Empty reply from server) Any idea of what's happening? Eloipool does not support StratumMP over HTTP (nor does any other StratumMP server AFAIK), only GBT and getwork. For StratumMP, you need to connect over a raw TCP stream. |
|
|
|
It's possible the device cannot keep up at difficulty 1 (the default). Try using --set pxy:diff=128 or such.
I have been in the " market" for a proxy miner, and this can be my prayers answered since I already run bfgminer for my usb hashers, but would like to add my S3's to it to " focus" my mining might. For the case of ghash, it is OK to have the option to set the difficulty on the command line with, e.g --set pxy:diff=128, since you can set your worker difficulty poolside to whatever you want (so long as it is above 32). For other pools though, e.g slush, the difficulty is set dynamically dependent on your speed, so the question is: Is it possible to flag bfgminer in proxy mode to pass on the difficulty to the connected rigs dynamically too? Not currently. However, if the upstream (pool) difficulty is lower than the one configured, it will be used to avoid losing shares. So in effect, you'd get the behaviour you want with eg --set pxy:diff=100000000 I am possibly missing something very obvious, but wouldn't setting the proxy diff to a large abstract number then instruct the connected rigs to only submit shares larger than that number to the proxy, thus the rigs discarding (not sure whether that is the correct term) otherwise valid shares? Yes, but BFGMiner actually uses the lower of the configured diff and the upstream diff. So, if the pool wants 128 and you have configured 1000, BFGMiner will actually use 128. On another but related note, I remember reading somewhere that the maximum diff size (due to a design oversight?) is 1024, or was that P2Pool only and now resolved?
Neither stratum nor GBT specify any maximum diff. |
|
|
|
Is there a cap on the speed of an individual device when running BFGMiner in proxy mode? When I connect my S3 to the proxy, my speed runs at about 250 GH/s for the device, if I connect directly to GHASH it runs over 450 GH/s. It's possible the device cannot keep up at difficulty 1 (the default). Try using --set pxy:diff=128 or such. I have been in the " market" for a proxy miner, and this can be my prayers answered since I already run bfgminer for my usb hashers, but would like to add my S3's to it to " focus" my mining might. For the case of ghash, it is OK to have the option to set the difficulty on the command line with, e.g --set pxy:diff=128, since you can set your worker difficulty poolside to whatever you want (so long as it is above 32). For other pools though, e.g slush, the difficulty is set dynamically dependent on your speed, so the question is: Is it possible to flag bfgminer in proxy mode to pass on the difficulty to the connected rigs dynamically too? Not currently. However, if the upstream (pool) difficulty is lower than the one configured, it will be used to avoid losing shares. So in effect, you'd get the behaviour you want with eg --set pxy:diff=100000000 |
|
|
|
Is there a cap on the speed of an individual device when running BFGMiner in proxy mode? When I connect my S3 to the proxy, my speed runs at about 250 GH/s for the device, if I connect directly to GHASH it runs over 450 GH/s. It's possible the device cannot keep up at difficulty 1 (the default). Try using --set pxy:diff=128 or such. |
|
|
|
 I am hopefully on my last error but, since I have not seen any of the errors above this line, I am skeptical this will be the end-all. Hello, I am seeing a bug, tried changing my hostname already, that was not the cause. 2014-09-21 19:13:26,818 SocketListener ERROR ('127.0.0.1', 8338) Traceback (most recent call last): File "/home/pi/eloipool/util.py", line 144, in tryErr return func(*a, **kw) File "/home/pi/eloipool/networkserver.py", line 262, in setup_socket sock = self._makebind(server_address) File "/home/pi/eloipool/networkserver.py", line 253, in _makebind return self._makebind_py(*a, **ka) File "/home/pi/eloipool/networkserver.py", line 229, in _makebind_py sock = socket.socket(self.address_family, socket.SOCK_STREAM) File "/usr/lib/python3.2/socket.py", line 94, in __init__ _socket.socket.__init__(self, family, type, proto, fileno) socket.error: [Errno 97] Address family not supported by protocol Eloipool only supports IPv6. If you want to use obsolete IPv4, you will need an OS that supports IPv4 connections on IPv6 sockets (like Linux) and configure it to bind on the appropriate iPv6 address (as in the example config). |
|
|
|
|
Show Posts
