|
scan and scan-serial are the same
|
|
|
|
"antminer" : "all",
"antminer" : "chip=BM1382" You want: "scan":"antminer:all",
"set-device":"antminer:chip=BM1382" |
|
|
|
Currently it is not practical to solo mine with CSV; I would consider it unfortunate if it were to activate in this condition. I have been working on addressing that problem first, and wizkid057 is mostly waiting for me at this time. My todo list on this matter is: ☒ Add GBT upgrades to BIP 9 ☒ Implement BIP 9 GBT upgrades in Bitcoin Core ☒ Backport BIP 9 GBT upgrades to Bitcoin Core 0.12 ☐ Release Bitcoin Knots 0.12.1 with BIP 9 GBT upgrades (or alternatively Core 0.12.2 could be released with it, but this seems unlikely) ☒ Implement BIP 9 GBT upgrades in libblkmaker/BFGMiner ☐ Release BFGMiner 5.4.3 with BIP 9 GBT upgrades (at this point, solo mining with CSV becomes practical) ☐ Port Eloipool to BIP 9 ☐ Backport new CPFP code to Knots 0.12.1, or forwardport Knots features to Core master wizkid057's steps for upgrading then are: ☐ Test Knots 0.12.1+CPFP or Core master+Knots ☐ Test Eloipool with BIP 9 ☐ Deploy upgraded bitcoind + Eloipool Edit: List being updated at http://eligius.st/bip9status.html |
|
|
|
When the coinbase transaction is full (beyond the size that some mining hardware can handle without a performance penalty... mainly poorly coded or low memory embedded miners) a few ... Can you share the exact size, please. I am working on a low memory embedded miner and don't want to have it classified as poorly coded/developed  . It's easier and better to plan for more memory, than extending it latter The generation transaction can possibly be as large as 1 MB, which would requires hashing the full 1 MB per 4 Gh. Actually meeting this requirement turns out to be pretty difficult with modern hashing hardware, even with a dedicated high end PC, so I guess just "do your best" - it is possible (but not implemented yet) to use a midstate to optimise this if the extranonce is at the end of the generation transaction. A good test would be to run BFGMiner with --benchmark-intense mode. You should probably read https://en.bitcoin.it/wiki/Mining_manufacturer_tech_guidelines |
|
|
|
All I want to know is if the core devs will allow miners to "vote" for the 2MB HF activation.
Definitely not. Miners do not decide hardforks, much less vote on them. so much for "Luke is focused on fulfilling the promise"  The HK roundtable included agreement on this point, that miners do not decide hardforks. It doesn't contradict it in any way. Even if it wasn't part of the document, this inability of miners to decide hardforks is an aspect inherent in the nature of hardforks, not something I nor anyone else has decided. so you're saying you think core will not/should not, add in the code required to allow miners to activate a HF with >75% hashing power. Correct. And even if we did, it would be futile, since neither devs nor miners can force users to adopt it. It is literally technically impossible for miners to activate a HF period. |
|
|
|
All I want to know is if the core devs will allow miners to "vote" for the 2MB HF activation.
Definitely not. Miners do not decide hardforks, much less vote on them. so much for "Luke is focused on fulfilling the promise" The HK roundtable included agreement on this point, that miners do not decide hardforks. It doesn't contradict it in any way. Even if it wasn't part of the document, this inability of miners to decide hardforks is an aspect inherent in the nature of hardforks, not something I nor anyone else has decided. |
|
|
|
All I want to know is if the core devs will allow miners to "vote" for the 2MB HF activation.
Definitely not. Miners do not decide hardforks, much less vote on them. |
|
|
|
"Unfortunately, I know of multiple companies with more than 100,000,000 users that have put their bitcoin integration on hold because there isn't enough current capacity in the Bitcoin network for their users to start using Bitcoin. Instead they are looking at options other than Bitcoin." -Roger Ver The real question you should be asking, is who lied to these companies that Bitcoin can't handle their users? How exactly would it be lying? BTC couldn't handle the tx capacity added from these users right now. Forcing them to engage in a bidding war with eachother for blockspace is not good business sense. It might be able to handle them in the future, but not right now, and the now is all that matters for these companies. There's no reason they couldn't use off-chain transactions until Lightning is ready, as daytraders have been doing since 2011. If the companies are really concerned about it, they could also fund development of Lightning to get it done even faster. The limitation isn't Bitcoin - it's what the companies are willing to do the work for. Blaming Bitcoin is just propaganda to enable laziness for greedy companies that want to reap the benefits without doing any of the work. |
|
|
|
"Unfortunately, I know of multiple companies with more than 100,000,000 users that have put their bitcoin integration on hold because there isn't enough current capacity in the Bitcoin network for their users to start using Bitcoin. Instead they are looking at options other than Bitcoin." -Roger Ver The real question you should be asking, is who lied to these companies that Bitcoin can't handle their users? |
|
|
|
I'd even say more stronger: Banks have strongest security & firewalls My justification for keeping most of my bitcoins in MtGox... |
|
|
|
Whether we like it or not, Bitcoin simply cannot hardfork while a large part of the community does not consent to it.
how would you even measure how much of the community does consent? i'm beginning to think a hard fork is completely impossible, except maybe for the narrow scenario where SHA-256, ECDSA or similar are broken. maybe immutability of consensus is not worth breaking. especially when the best we seem to have to measure it is meaningless miner votes and node counts. fuck a democratic vote, especially ones that can be gamed. i dont care about miner votes for soft forks. they can do that anyway regardless of anything we do. but for change/removal of consensus rules....no. The best idea I know of today, would be to have an off-chain stake polling system, where coin-holders can indicate consent by a specially-designed signed message. Probably we would also need interested parties to fund Google ads and similar to promote awareness of the new polling system, to ensure the majority of UTXOs mark their consent or dissent. If 99% of polled stake consents to the hardfork, and a sufficient % of UTXO value participates in the polling, it'd probably be safe to move forward. A safe hardfork can also be done which leaves old nodes "locked" rather than vulnerable to attack. This protects any nodes that neglect/forget to upgrade in time, and can be designed such that if they really want to dissent too late, they can add a simple one-liner to bypass the "lock-out". THIS sounds like an alt coin sir and had nothing to do with bitcoin. Bitcoin solves bitcoin within bitcoin. Hardforks are inherently NOT within Bitcoin. That's why it requires community consensus in the first place. |
|
|
|
Whether we like it or not, Bitcoin simply cannot hardfork while a large part of the community does not consent to it.
how would you even measure how much of the community does consent? i'm beginning to think a hard fork is completely impossible, except maybe for the narrow scenario where SHA-256, ECDSA or similar are broken. maybe immutability of consensus is not worth breaking. especially when the best we seem to have to measure it is meaningless miner votes and node counts. fuck a democratic vote, especially ones that can be gamed. i dont care about miner votes for soft forks. they can do that anyway regardless of anything we do. but for change/removal of consensus rules....no. The best idea I know of today, would be to have an off-chain stake polling system, where coin-holders can indicate consent by a specially-designed signed message. Probably we would also need interested parties to fund Google ads and similar to promote awareness of the new polling system, to ensure the majority of UTXOs mark their consent or dissent. If 99% of polled stake consents to the hardfork, and a sufficient % of UTXO value participates in the polling, it'd probably be safe to move forward. A safe hardfork can also be done which leaves old nodes "locked" rather than vulnerable to attack. This protects any nodes that neglect/forget to upgrade in time, and can be designed such that if they really want to dissent too late, they can add a simple one-liner to bypass the "lock-out". Sounds awesome, but remember one of the key point of cypherpunk bitcoin is "privacy". Nobody should be forced to take part in some political public demonstration. Besides, involving google?! wtf man. Why not directly mark the bagholders with some veal blood already? Also, at what threshold do you consider the "polled stake" view (which may be as high as 99%!! omg) to overcome the whole bitcoins at stake? Well, the stake poll would be entirely based on the signed messages, so it wouldn't reveal who owns the UTXOs at all. Admittedly, there might be a privacy concern if you're already de-pseudonymised, but I don't know that there's even a hypothetical way to solve that. I don't know any way to reach the entire community, and Google ads seems like a reasonable attempt. It seems like BitcoinTalk and reddit only make up a tiny fraction of people using bitcoins. I don't understand your last question. |
|
|
|
The best idea I know of today, would be to have an off-chain stake polling system, where coin-holders can indicate consent by a specially-designed signed message.
I don't want to get too much in the weeds; however, probably, what you are suggesting would be a bit of an improvement over the status quo, but really there seems to be a broader interest in bitcoin and rights and stakeholding beyond current actual coin holders. I mean we have future coin holders, we have past coin holders, we have people who invest in bitcoin through product, services and possibly in other ways such as alt coin contributions that may be absorbed into bitcoin but may not currently hold bitcoins. There may be ways to give weighted value to a broader segment of the various bitcoin stake holders beyond actual coin holders even if they do not have actual coins (or many coins) at the moment of an actual poll/vote. The ideal would be to imitate the economic consensus of people accepting payment, but I think polling current holders is the closest we can come to this. Perhaps those who accept payments can opine publicly, and influence the poll through their potential customers? |
|
|
|
Whether we like it or not, Bitcoin simply cannot hardfork while a large part of the community does not consent to it.
how would you even measure how much of the community does consent? i'm beginning to think a hard fork is completely impossible, except maybe for the narrow scenario where SHA-256, ECDSA or similar are broken. maybe immutability of consensus is not worth breaking. especially when the best we seem to have to measure it is meaningless miner votes and node counts. fuck a democratic vote, especially ones that can be gamed. i dont care about miner votes for soft forks. they can do that anyway regardless of anything we do. but for change/removal of consensus rules....no. The best idea I know of today, would be to have an off-chain stake polling system, where coin-holders can indicate consent by a specially-designed signed message. Probably we would also need interested parties to fund Google ads and similar to promote awareness of the new polling system, to ensure the majority of UTXOs mark their consent or dissent. If 99% of polled stake consents to the hardfork, and a sufficient % of UTXO value participates in the polling, it'd probably be safe to move forward. A safe hardfork can also be done which leaves old nodes "locked" rather than vulnerable to attack. This protects any nodes that neglect/forget to upgrade in time, and can be designed such that if they really want to dissent too late, they can add a simple one-liner to bypass the "lock-out". |
|
|
|
GBT/mining is broken in Core 0.12.1. I am actively working on getting this fixed for 0.12.2 and Knots 0.12.1, but for now, solo miners will need to downgrade to 0.12.0 or alternatively hack their 0.12.1 code. If you want to hack the code, edit src/rpcmining.cpp and find the line: aMutable.push_back("prevblock");Add another line immediately before this, with: aMutable.push_back("version/force");Then recompile to have the changes take effect. Note that this hack will ONLY work for CSV/0.12.1, and WILL NOT work with segwit or future softforks. If you use this change after segwit is active, you will be mining INVALID blocks. |
|
|
|
GBT/mining is broken in Core 0.12.1. I am actively working on getting this fixed for 0.12.2 and Knots 0.12.1, but for now, solo miners will need to downgrade to 0.12.0 or alternatively hack their 0.12.1 code. If you want to hack the code, edit src/rpcmining.cpp and find the line: aMutable.push_back("prevblock");Add another line immediately before this, with: aMutable.push_back("version/force");Then recompile to have the changes take effect. Note that this hack will ONLY work for CSV/0.12.1, and WILL NOT work with segwit or future softforks. If you use this change after segwit is active, you will be mining INVALID blocks. |
|
|
|
Whether we like it or not, Bitcoin simply cannot hardfork while a large part of the community does not consent to it.
You seem to recognize exactly that a non-consensus hardfork is not necessary and is potentially damaging, so I remain a bit unclear regarding what fruitfulness comes from your going around polling people in the bitcoin community regarding what kind of scenarios they believe in which a hardfork would be a good thing? There are real improvements that can be made to Bitcoin with a hardfork. If the community could come to agreement on it, it would help Bitcoin compete in the near term at least. Likely, I do not understand technicalities sufficiently; however, I thought that almost all significant changes could be achieve through soft forks, so I remain uncertain why a hardfork would be even needed, unless there was some kind of technical emergency.. such as some kind of bug that allowed a maligned player to steal coins. In other words, to attempt to rush consensus seems to be an unnecessary (and potentially dangerous and damaging) alteration of bitcoin's governance, rather than attempts at addressing any kind of necessary technical resolution. The mentioned block withholding attack falls under "allowing ... to steal coins" IMO. I do agree any rush is unnecessary, and that a safe hardfork is probably impractical at this time (albeit I am trying to find a way to prove myself wrong here, so I can meet the terms I agreed to, but so far no success in doing so). Well, you were there for the actual discussion of the agreement, but it seems very impractical, and even a bad reading of the actual literal agreement to believe that a pursuit of a hardfork would be necessary prior to verifying how seg wit plays out first.. . I mean, really, seg wit is not even actually live on the network, yet, so isn't it feasible that seg wit could really cause a lot of the points for an actual hard fork to be mute... (at least regarding to a raising of the blocksize limit for some time to come) and yeah of course, a large number of bitcoin holders would agree that if old coins somehow become more vulnerable due to changes in security or abilities to break cryptography, then those matters are going to be weighed to potentially justify a hardfork rather than a softfork... but also, breaking cryptography is much at the theoretical level, instead of actual demonstrations of such breaks of cryptography occurring, no? Yes, it was a compromise. I don't see any strong purpose to active pursuit of a hardfork right now, and except that I promised in HK to do so, I otherwise probably wouldn't be. Of course, nobody else in the community outside of that HK meeting has agreed to do anything, and is free to reject any proposal we come up with. |
|
|
|
Whether we like it or not, Bitcoin simply cannot hardfork while a large part of the community does not consent to it.
You seem to recognize exactly that a non-consensus hardfork is not necessary and is potentially damaging, so I remain a bit unclear regarding what fruitfulness comes from your going around polling people in the bitcoin community regarding what kind of scenarios they believe in which a hardfork would be a good thing? There are real improvements that can be made to Bitcoin with a hardfork. If the community could come to agreement on it, it would help Bitcoin compete in the near term at least. Likely, I do not understand technicalities sufficiently; however, I thought that almost all significant changes could be achieve through soft forks, so I remain uncertain why a hardfork would be even needed, unless there was some kind of technical emergency.. such as some kind of bug that allowed a maligned player to steal coins. In other words, to attempt to rush consensus seems to be an unnecessary (and potentially dangerous and damaging) alteration of bitcoin's governance, rather than attempts at addressing any kind of necessary technical resolution. The mentioned block withholding attack falls under "allowing ... to steal coins" IMO. I do agree any rush is unnecessary, and that a safe hardfork is probably impractical at this time (albeit I am trying to find a way to prove myself wrong here, so I can meet the terms I agreed to, but so far no success in doing so). |
|
|
|
Whether we like it or not, Bitcoin simply cannot hardfork while a large part of the community does not consent to it.
You seem to recognize exactly that a non-consensus hardfork is not necessary and is potentially damaging, so I remain a bit unclear regarding what fruitfulness comes from your going around polling people in the bitcoin community regarding what kind of scenarios they believe in which a hardfork would be a good thing? There are real improvements that can be made to Bitcoin with a hardfork. If the community could come to agreement on it, it would help Bitcoin compete in the near term at least. |
|
|
|
|
Whether we like it or not, Bitcoin simply cannot hardfork while a large part of the community does not consent to it.
|
|
|
|
|
Show Posts
