Luke-Jr when we can expect full functionality on Eligius pool ?
No idea. Still haven't heard anything from wizkid057. |
|
|
|
Is anyone else minting new coins or just Elig?
P2Pool? |
|
|
|
Did you ever hear from him? -Dave No  |
|
|
|
|
I wonder if anyone might volunteer to help wizkid057 finish the migration?
|
|
|
|
Why could[n't] we have the old stats until the new are available!?? He's not just changing the stats. The pool's reward system changed too. The old stats never supported the new reward system. Hey Luke, it says Eligius is one of your projects/didn't I read somewhere that you created it? Could you help out with a temporary stats page if wizkid is too bogged down?  Do you still have a role on the admin side of this pool. Is it all wizkid now? It might be theoretically possible, but I don't know how wizkid057 has changed things since I moved on, and I'm not sure it'd be the best use of my time. (Keep in mind that when I ran the pool, I never had any web stats at all... that was always contributed by someone else) |
|
|
|
Why could[n't] we have the old stats until the new are available!?? He's not just changing the stats. The pool's reward system changed too. The old stats never supported the new reward system. |
|
|
|
|
If you're really worried, you could mine on another pool temporarily. There's nothing saying you have to be monogamous with Eligius. :p
(Not that I have any reason to doubt wizkid057 will make good on everything.)
|
|
|
|
What is the status or plans for support of altcoin algos? I'd really like to switch to bfgminer for the configurability and monitoring, but sha256 is not profitable on my rig.
If someone else wants to maintain different algos, we can merge it and cooperate, but I am not interested. |
|
|
|
|
Note the submitted patch actually changes the max block size to 32 MB.
This is a hardfork and, as always, cannot be done without consensus.
|
|
|
|
|
There shouldn't be any benefit to pool hopping with CPPSRB, so I'd stick to Eligius.
|
|
|
|
luke how about your promise for an implementation for 2mb base 4mb weight?? It is still a work in progress. See my hardfork2016 branch on github. [as an independent coder as i fear your employer and paid colleagues will refuse it in core] I do not have an employer by choice. It certainly should be refused in Core unless the community comes to agreement to deploy it first - same as with any hardfork proposal. your vote is unclear especially in concern of the word "blocksize increase" (you dont explain legacy blocksize vs base/weight) There is no such thing as "legacy blocksize". Witness data has always been included in the block size, and there is no reason for that to change with segwit. what should happen:
is node implementations are released first and the community upgrade. that way miners can see that a high percentage of nodes are running and able to FULLY validate and be ready to accept what miners will produce/allow later.
then when happy of a secure large % FULL validation by the network, the pools then and only then vote, due to being happy with the usernode adoption. and if pools reach the high percentage, then it activates. knowing the network is high majority fully validating The problem is that nodes are anonymous and cannot be detected. We could add some system where they publish their agreement, but it would only work for new nodes, not the old ones which are just as important. (Note that listening nodes are not all nodes.) phase one: users(full nodes)
a year is given for getting to 95%, when/if it is at 95% at any time within the year..(a)
a month is then given to ensure it stays at 95%, incase of temporary fluke/sybil attack etc(b)
and then a months grace(c) 95% is not consensus sufficient for a hardfork. The remaining 5% would continue Bitcoin and the 95% would simply leave into an altcoin. please note:
the time between (b) and (f), ends up being many many months. meaning alot of time is given for the ~270 lingering user nodes to well surpass the 95%
thus only making the orphan risk well under 5%.
That's assuming those lingering nodes are actually lingering, and not actively objecting. If they are objecting, then they cannot be forced to switch. |
|
|
|
|
Softforks require community support, and miners should evaluate this before signalling activation of them. If the community is significantly divided over whether a softfork should be deployed, miners should not signal support for the softfork until this contention is resolved.
Bitcoin Core and [segwit-capable] derivatives by default will indicate to segwit-enabled miners that they should signal for segwit support, but GBT's versionbits support (see BIP 9) is intentionally designed such that the miner may safely choose to ignore this recommendation and omit the signal - Core does not force anyone to signal segwit. Miners and pools should choose whether to signal for segwit (and other softforks or policy decisions) on their own, and not rely on defaults.
People using stratum mining pools should note that they may not be able to override the pools' decisions. If your pool does not disclose to you whether they signal for a given softfork, or they signal (or don't-signal) for one inappropriately, you should switch to a pool that matches your position.
Note that I am intentionally not saying whether or not segwit actually is controversial here. Personally, I support segwit and think the only rational objection is that the block size limit increase may be unsafe if we cannot trust miners to continue making 1 MB or smaller blocks for the near future. But the community should make their own decision (perhaps post your position here for miners to see), and miners should decide whether or not to signal based on the community's consent.
|
|
|
|
|
This is fixed in Knots 0.13.1.
|
|
|
|
Just seems to have below posted in the wrong subforum and it needs tot be here :
Does someone has a idea on this problem :
I'm running a full node Bitcoin Core v0.13.0 (64-bit) with BFGminer 5.4.2-win64 on the same computer.
Starting as : bfgminer.exe --stratum-port=3333
I connect with 2 Antminer S1's to BFGminer ( stratum+tcp://192.168.0.xxx:3333 )
All seems working fine for the real Bitcoin network but NOT (no longer) for the testnet.
Alltrough it worked fine before and only Testnet=1 needs tot be changed in the Bitcoin.conf
BFGminer keeps complaining :
Pool 0 slow/down or URL or credentials invalid.
No servers were found that could be used to get work from
If I remove Testnet=1 from the Bitcoin.conf and start again, no longer complains.
Would this has to do something with the 'versionbit 28' in use for the moment on the testnet ?
And if so, what can I do about it ?
Thanks for all reply's !
Kind regards.
For testnet, the RPC server is on port 18332, so you will need to provide the URI manually I think. You will also need the segwit branch of libblkmaker. |
|
|
|
|
This issue has been assigned CVE-2016-8889 and will be fixed in the next release of Bitcoin Knots.
|
|
|
|
Has anyone ever made something to describe the layout(what everything means) of BFGminer?
You mean like the README file? |
|
|
|
Hey quick question. Why does "sudo apt-get install bfgminer" install 5.2?
Because your distro hasn't bothered to update it since mid-2015 apparently. |
|
|
|
Hello,
Is there any possibility that BFGMINER will support rx480 cards?
No reason I'm aware of that it wouldn't already. |
|
|
|
|
Show Posts
