"blktmpl error: Unrecognized block version, and not allowed to reduce or force it"
when trying to mine to a bitcoin classic node. Will this require an updated version of libblkmaker? looking at bitcoin-cli getblocktemplate I see
I don't support altcoins. When/if Classic actually proposes a hardfork (no such proposal has been made yet) and it achieves consensus to replace Bitcoin (from the entire community, not merely some niche with an agenda), I will add support at that time. (Also, people who support a reckless hardfork without consensus, ought to seriously consider whether they think the project can actually survive without any competent developers involved...) I figured your reply would be something like that. I wont be a jerk and ask why scrypt asics are supported if you dont support altcoins. I don't maintain the scrypt support, and certainly don't provide [unpaid] support if someone has problems with some scrypt altcoin.  |
|
|
|
"blktmpl error: Unrecognized block version, and not allowed to reduce or force it"
when trying to mine to a bitcoin classic node. Will this require an updated version of libblkmaker? looking at bitcoin-cli getblocktemplate I see
I don't support altcoins. When/if Classic actually proposes a hardfork (no such proposal has been made yet) and it achieves consensus to replace Bitcoin (from the entire community, not merely some niche with an agenda), I will add support at that time. (Also, people who support a reckless hardfork without consensus, ought to seriously consider whether they think the project can actually survive without any competent developers involved...) |
|
|
|
do bfgminer support Avalon 6?
No, I haven't any sample/specs to work with yet for Ava6. |
|
|
|
BIP's are accepted or rejected based on merit. Not really. There's been some pretty crappy BIPs the community has accepted, and some good BIPs that are as of yet not. |
|
|
|
If they really actively participated in the decision making process of BIP66, they would have known that BIP66 might create a hard fork, thus they will reject BIP66 from the beginning. BIP66 could not and did not create a hard fork. |
|
|
|
The most important is the decision making mechanism
Current mess is caused by that there is no decision making mechanism, so that all the design happens without first have a consensus based decision. When the design finished, programmers find out that there is no miners interested in their solution, this result in waste of time and human resource
But that's what BIP's are for. BIP's are design proposals, but how are they get approved? That's decision making mechanism Currently they are approved by the 5 core devs that have Git commit right, but their approval does not mean the approval of miners and other interested community members. And this is especially problematic when those 5 core devs have a conflict of interest themselves Not quite. First of all, git commit access is not a privilege at all - it is only a job of merging things which has passed peer review. Secondly, BIPs do not require approval from any Core devs. Most BIPs simply need approval from multiple software projects (Core or otherwise) which implement them. For example, lots of wallets implement BIP 13 (p2sh address format), and a number of mining programs implement BIP 22 (getblocktemplate). Softfork BIPs need approval from a supermajority of miners. For example, BIP 65 not long ago was adopted by 95% of the network hashrate. Hardfork BIPs need approval from everyone using Bitcoin. The only hardfork ever in the history of Bitcoin was in the aftermath of the 2013 crisis, with no argument against it whatsoever. We do not yet have a single example of a hardfork deployed in non-crisis situations or by planned agreement in advance, much less a contentious hardfork that has successfully been forced on a subset of the community. |
|
|
|
|
That is users vs nodes, not nodes vs miners.
|
|
|
|
I can never remember bitcoin beeing about what a majority wants. Bitcoin wasn't designed that way.
Au contraire, Blackadder... 12. Conclusion
We have proposed a system for electronic transactions without relying on trust. We started with the usual framework of coins made from digital signatures, which provides strong control of ownership, but is incomplete without a way to prevent double-spending. To solve this, we proposed a peer-to-peer network using proof-of-work to record a public history of transactions that quickly becomes computationally impractical for an attacker to change if honest nodes control a majority of CPU power. The network is robust in its unstructured simplicity. Nodes work all at once with little coordination. They do not need to be identified, since messages are not routed to any particular place and only need to be delivered on a best effort basis. Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism.
And indeed, needed rules are added in that way. It's another thing entirely when you speak of removing current rules, however. On that, Satoshi said (emphasis mine): The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime. Also keep in mind that back when Satoshi was around, the idea was that every node would be a miner among equals. That is no longer the case. |
|
|
|
|
Segregated witness and SegNet are now supported in the "segwit" branch.
|
|
|
|
I think the plan behind bip101 was that the average internet connection will likely keep getting faster with time, even today some people have 1Gbit fiber connection at home, others are probably watching 4k netflix right now. Average internet connectivity improvements only give about 30% per year optimistically. BIP 101 was far more aggressive than that. And while some minority of the world has 1 Gbit available, requiring it would be saying nobody else can use Bitcoin. I'm only slightly rural and I can't get better than 5/0.5 Mbps yet. |
|
|
|
I ask because this is the question that we have been asking ourselves a lot recently.
We are a Chinese BTC company that has invested a lot in mining and also runs an off-chain wallet service. So we have a vested interest in Bitcoin not failing. Like many Chinese miners, we believe that a simple and conservative solution to the block size question would be the best, but it seems that neither Core or Classic is willing to offer. I would very much like to hear your views.
Segregated witness is the simplest conservative solution possible, and not very complicated at all once you understand it. While a hardfork block size increase would be "simpler" in terms of lines-of-code, it is hugely more complicated socially because Bitcoin was specifically designed to make such changes impossible without agreement from every single user (not merely miners). Cconvert2G36, shame on you for quoting Satoshi and Greg out of context. Miners do not represent the economy, but must follow the economy's lead, especially when it comes to hardforks. |
|
|
|
|
Try messing with those workarounds in README.ASIC...
|
|
|
|
It has come to my attention that the 2D-work engine fails to submit shares with GBT servers. - If you only use stratum mining pools, you are NOT affected.
- Otherwise, if you use GBT pools or solo mine with a local node:
- If you use an Avalon2 or newer, you ARE affected.
- If you use the --stratum-port option, you ARE affected.
- If you don't use either of the above, you are NOT affected.
Note that if you are affected, you would most likely notice that you're never getting credit for any shares. Therefore, since this bug went unreported for so long, I assume nobody is actually trying this particular use case, and as such I deem it to be not a high priority issue. I will try to get it fixed in the next release at my convenience, unless it actually bothers someone. |
|
|
|
Latest version is 5.4.1, have you tried it ?
Sorry but it is the same... the miner failure? Probably. What miner is it? Note that earlier Hex*Fury and OneStringMiner have bugs that require workarounds documented in README.ASIC. |
|
|
|
Just an advise to newbies, with the pool low hashrate and rising difficulty it is now time to say good bye to your green graph.
Newbies like you probably shouldn't be giving advice to other newbies. Pool hashrate is not relevant to earnings. |
|
|
|
|
If you want to send me one of the problematic Compacs, I can try to take a look at what's going wrong.
(Or maybe setup remote/SSH access to one?)
|
|
|
|
Luke Will this matter with BFG for GekkoScience Compac BM1384 Stickminer batch 2 ?. BFG won't pick it up batch 2, a few others are having the same issue. batch one works fine with BFG. I posted this in the https://bitcointalk.org/index.php?topic=1173963.msg13312792#msg13312792 thread asking if there is a issue, I'm not aware of, with batch 2 and BFG ?. This is what side said : "batch 2" sticks are the same as "batch 1" except each stick has a unique serial number is greater than about 480 and he changed the diode on the LED flash circuit. CG picks it right up. I'd rather use BFG but will us whats needed to make it work. BFGMiner doesn't care what the serial number is. |
|
|
|
|
You don't need hidapi for the Compac driver.
|
|
|
|
|
FWIW, the Compac driver in BFGMiner is heavily integrated with the "Icarus" driver, so what Kano is saying makes sense to me.
Future devices using a new protocol should probably get a separate driver from the Compac anyway.
|
|
|
|
|
I suggest editing out scam addresses.
|
|
|
|
|
Show Posts
