To research the suitability of alternate proof-of-work algorithms, to test them, and then to implement the algorithm that makes it through these filters as Bitcoin mainnet's new proof-of-work function.

Contributors

luke-jr - renowned Bitcoin Core developer - Development

/u/riiume (me) - Marketing/publishing

r00tdude

desantis - is working on a PoW fork proposal

... Perhaps you? If interested in going full bore on this project, please PM me, along with a one sentence bio, then you will be added to this list.

Rule #1: We are not here to debate against PoW change-- this thread is for people who have already decided to help with a PoW change of some kind. It is, however, acceptable (and desirable) to debate exactly what kind of PoW fork, based on data, testing, exploit discovery, etc.

Wiki - in the works - a curated reference to the most valuable data/tests/benchmarks to come out of these discussions. Hopefully a sort of "rock-of-objectivity" upon which the ongoing planning and discussing can be built.

Bitmain is close to having de facto control of a great majority of the network hashrate:

"Bitmain, one of bitcoin’s biggest miners with a current hash-share of around 15% of the network, is to launch a new giant mining facility this December with 45 rooms, independent substations, offices and a total size of 140,000 kilowatts. By some calculations, that translates to around 45% of the network hash-share, but it is not clear whether the new facilities are simply for a relocation or to accommodate additional mining power." [ Quentson, A. (2016, February 11). "Bitmain to Launch a Giant New Bitcoin Mining Center". CryptoCoinsNews.]

This poses the risk of: - transaction censorship ("PBoC does not approve of your transaction, so Bitmain has their pools exclude it from blocks") - double-spend attacks (if Bitmain is not motivated by mining profits (as a KnC miner executive once speculated) because e.g. their real profits come from a ChinaGov paycheck), then they will happily destroy the value of Bitcoin's network by executing double-spend attacks.

Recommended Discussion Guidelines

Given the urgency of settling these issues in order to protect Bitcoin's prime reputation and its adoption rate, I offer the following recommended ranking of types of communications on this thread, starting with the most valuable at (1):

(2) Analysis of data - Identification and further extrapolation of patterns in data, technical critique of methods used in tests, model-based predictions of outcomes of tests (if the tests themselves are too resource/labor intensive to actually carry out)

(3) Interpretation of results - Discussion (with proof/justification) of what the results and analysis of the tests will mean for the Bitcoin market cap, decentralization, censorship-resistance, and any new vulnerabilities.

(4) Broader discussion - Including discussion of businesses related to Bitcoin, quotes by notable personalities relevant to Bitcoin, regulations and other activities of governments with respect to Bitcoin, and what implications these things have for the PoW project.-----BEGIN PGP SIGNATURE-----Version: GnuPG v2

While not specifically related to a PoW change, I would like to see whether there is something that might be investigated to provide more choice to users for any PoW implementation. I'm pretty sure this isn't a re-direct. Let me know if it is.

Would it be possible to add an encryption key to a txn that signals that you will only allow miners that have the key to mine your txns? This then might be solved as a configuration setting on the nodes :

1. Accept/relay all txns. 2. Key management solution within client that allows me to select from a list of miners that I, as a user, find acceptable. 3. I accept/relay txns that meet a library of keys (white-list). 4. Reject txns that meet a library of keys (black-list).

The immediate issue is that your txn would need to have several keys, for the list of pools/miners that you would be prepared to use to include your txns in a blocks. I'm thinking that there needs to be some method using nodes to re-direct around hostile miners, to miners that meet your requirements. GnuPGP provides the facility for using multiple keys to encrypt the same key. The miner defines a private key, generates a public key from that private key, and the user encrypts their transaction using the private key(s) of their choice.

This might not even be handled in any other way than a 'handshake' between nodes. When a node connects to another node, it passes along its white-list. Perhaps its black-list too, but not necessary. The node it has connected to can then replicate the transactions that meet the list. The node then weeds out the transactions that meet its black-list.

So how would a node perform its validation function with some or all of the content of txn encrypted? Would it be possible to use the public key of one of the encryption keys in order to do a blind validation? I can't see how that would work. Does anyone know of a model that would allow this?

The reason I like this type of option is that it is opt-in, which satisfies the ethos of bitcoin. Then there is incentive for miners to 'do the right thing' and be an accepted miner. You can have white-lists, and black-lists, managed by the user. But it also might give you control, as a node owner, to decide which txns destined to which miner are relayed through your node. I don't want my node to be used to relay transactions to that miner. I think it would also encourage for there to be more nodes.

This entire system doesn't deal with block propagation, so I think it would have a negligible effect on traffic.

But you'd also need to be able to remove transactions from your pool if they are in the block. So it sounds like you wouldn't be able to use encrypt all of the data, just some of it. Enough so you couldn't mine it, but not enough so that you couldn't identify it.

Definitely more cpu processing time though.

Reckon you could do it by making a hash of your transaction details, and then referencing that vs a hash of each of the transactions in the new block. Compare the two, and you'll know you can remove the transactions in the block with matching hashes. So whether all of the txn was encrypted or not, the hash is a header field that isn't. This would allow you to remove transactions in your pool when a new block confirms that they have been included in a block.

Think I might even be over-thinking the validation part. There are two validations. One of the txn, and one of the txn in a block. The second one isn't affected by this process. The first one is. BUT. Do I care about the first one much? The miner still has that key. They can decrypt the txns they have, validate them, and therefore include them in blocks. So the issue doesn't become is it validated, but of incentives.

Validation would still be issue for txn at node though. Spam. Adversarial users could create transactions that clog nodes that will never be included in blocks. If the transaction is invalid, but the relaying node can't validate it, they'd be replicating it to all of the nodes You'd need to have some method of making the user has to pay for this type of transaction. So they lose money the more of them that they create.

I think a hardfork change is too drastic, and will certainly end in a contentious hard fork. A POW change light can be implemented as a soft fork by a requirement for an extra proof of work of a different type in the coinbase transaction or in another special transaction. This will encourage cooperation between miners having lots of specialized SHA256 hardware and users mining the extra proof of work on their CPUs. If miners behave badly, users will turn their backs to them, and it will become more difficult/expensive for the miners to create new blocks. Another important advantage is that old nodes and wallets will still work, as long as the majority of the hashrate is behind the soft fork. Still safeguards must be put in place to stop someone with a very large SHA256 hashrate to overtake the main chain at a later time when the extra POW difficulty is high, since a SHA256 only chain will still be valid for old nodes and SPV nodes.

Sjå https://bitmynt.no for veksling av bitcoin mot norske kroner. Trygt, billig, raskt og enkelt sidan 2010.I buy with EUR and other currencies at a fair market price when you want to sell. See http://bitmynt.no/eurprice.plWarning: "Bitcoin" XT, Classic, Unlimited and the likes are scams. Don't use them, and don't listen to their shills.

I think a hardfork change is too drastic, and will certainly end in a contentious hard fork. A POW change light can be implemented as a soft fork by a requirement for an extra proof of work of a different type in the coinbase transaction or in another special transaction. This will encourage cooperation between miners having lots of specialized SHA256 hardware and users mining the extra proof of work on their CPUs. If miners behave badly, users will turn their backs to them, and it will become more difficult/expensive for the miners to create new blocks. Another important advantage is that old nodes and wallets will still work, as long as the majority of the hashrate is behind the soft fork. Still safeguards must be put in place to stop someone with a very large SHA256 hashrate to overtake the main chain at a later time when the extra POW difficulty is high, since a SHA256 only chain will still be valid for old nodes and SPV nodes.

Good thoughts but miners will never approve this proposal with BIP 9 and I doubt even 51% so would need to be a UASF , whicj will likely end up as a HF only . This proposal is more of a HF in reaction to a 51% attack from miners which would not be as controversial.

Judging from this latest tweet, we may need to prepare for the worst...

Instead of PoW change could it be possible to add a supplementary PoS layer which requires a block to be validated in some way by nodes prior to miners being able to build the next block, reducing the centralizing effect of propagation times?

Instead of PoW change could it be possible to add a supplementary PoS layer which requires a block to be validated in some way by nodes prior to miners being able to build the next block, reducing the centralizing effect of propagation times?

A hybrid PoW / PoS version should be investigated as well, my only concern is that we should keep the PoW HF as simple as possible and adding a "secure PoS" algo into the mix will be sure to complicate the HF as no secure PoS really exist and politically adding PoS to bitcoin will be much more difficult.

My advice it to first test and get running a testnet version of simple PoW Keccak with 0.14 and than investigate a Hybrid SHA256/Keccak proposal ... and after these are running on a testnet with individuals actively mining we can start to explore a PoW /PoS hybrid.

Instead of PoW change could it be possible to add a supplementary PoS layer which requires a block to be validated in some way by nodes prior to miners being able to build the next block, reducing the centralizing effect of propagation times?

A hybrid PoW / PoS version should be investigated as well, my only concern is that we should keep the PoW HF as simple as possible and adding a "secure PoS" algo into the mix will be sure to complicate the HF as no secure PoS really exist and politically adding PoS to bitcoin will be much more difficult.

I'm glad you think its worth looking at, thanks.

The benefit I think is that miners will fight a PoW change tooth and nail and may gain some sympathy for that from users, because it is a little bit unfair to miners even if it does have benefits and will look to many like a major change. If miners fight such a supplementary PoS they are transparently only doing so in the self-interest of big pools trying to centralize power. So perhaps it won't be more difficult politically.

Also perhaps security is less of an issue for PoS if it could be structured as a supplementary layer which doesn't actually secure transactions, only serves to reduce centralization?

Yes, this is why we should not waste our attention on PoS at the moment, but there is an argument to be made for a PoW/PoS hybrid temporarily preventing a 51% attack if the economic majority is against the miners.

Also perhaps security is less of an issue for PoS if it could be structured as a supplementary layer which doesn't actually secure transactions, only serves to reduce centralization?

Perhaps , but a lot more testing and thought needs to go into this and we don't have time, so as a matter of practical urgency we need to start a testnet with us mining on it with as simple of a Pow change as possible... Keccak is the best candidate.

Instead change the mining algorithm or the way blocks are mined, maybe even develop a secondary software to take all the combined hash power of the entire network and secures the blockchain by mining exactly every 10 minutes with blocks of any size up to even 16MB?

I want to know what happens if there was only one mega pool mining and then rewarding miners based on their hash rate?

Instead change the mining algorithm or the way blocks are mined, maybe even develop a secondary software to take all the combined hash power of the entire network

The combined protocol would simply become the new protocol and thus this is essentially over complicating matters.

A simple change in this case has 3 unique advantages:

1) breaks less software code (APIS, firmware, custom apps , wallets, ect... ) 2) Is less likely to contain exploits and easier to secure3) Is less likely to contain propositions people disagree with and can argue over.... if we are being attacked by the miners and a speculative coin vote fails than we have no choice but to perform a HF and we don't want to add anything to the HF that would leave others behind because they disagree with part of the proposal

Since most of you obviously haven't read it, let me direct your attention to Section 6 of the Bitcoin white paper:

Quote from: Bitcoin: A Peer-to-Peer Electronic Cash System, Section 6

The incentive may help encourage nodes to stay honest.If a greedy attacker is able to assemble more CPU power than all the honest nodes,he would have to choose between using it to defraud people by stealing back his payments,or using it to generate new coins.

He ought to find it more profitable to play by the rules,such rules that favour him with more new coins than everyone else combined,than to undermine the system and the validity of his own wealth.

* it is memory-oriented rather than computation-oriented which makes it less cost-efficient to implement in ASIC,* it is asymmetric, meaning that verifying a solution is much cheaper than generating that solution (_even_ starting from the nonce that generates that solution); In particular it requires substantial RAM (hundreds of MB, depending on parameter choices) to generate a solution (or an attempted solution), but it does not require that much RAM to verify a solution. This may be useful for constrained implementations such as SPV wallets in constrained hardware, implementation inside the Ethereum VM, etc.* it has a good level of scientific investigation behind it, which makes me think it relatively unlikely than an algorithmic breakthrough would enable someone to find solutions much cheaper than the competition. This has been born out by the experience of live Zcash mining, where developers have made tremendous progress on micro-optimization, but as far as we know no algorithmic breakthroughs.

A reason to choose Equihash is that you benefit from the all of the research and implementation work described above. There are many well-tested implementations available, both open source and proprietary.

If you're looking for a new Proof-of-Work, I can recommend the Equihash Proof-of-Work that we selected for Zcash.

Thank you for the suggestion.I like how both Ethereum's Dagger-Hashimoto ethash and Equihash have both been relatively well tested in the wild. The concern I have with it is that there is already a FPGA developed with Equihash, and we dont want future ASICs/FPGA's from alts attacking bitcoin, but than again perhaps there could be a benefit to merge mining with either ETC or Zcash for better security .

I think a hardfork change is too drastic, and will certainly end in a contentious hard fork. A POW change light can be implemented as a soft fork by a requirement for an extra proof of work of a different type in the coinbase transaction or in another special transaction. This will encourage cooperation between miners having lots of specialized SHA256 hardware and users mining the extra proof of work on their CPUs.

Good thoughts but miners will never approve this proposal with BIP 9 and I doubt even 51% so would need to be a UASF , whicj will likely end up as a HF only . This proposal is more of a HF in reaction to a 51% attack from miners which would not be as controversial.

The current miners will still have a huge advantage with the extra-POW soft-fork model, since SHA256 hashing power as well is required to find blocks, so I think a large enough economic majority will make the current miners come along in a UASF. The miners have no interest in mining worthless coins after all. They will have to share their power and some of their income with CPU miners, since none of them can operate alone, but will likely still have most of the payout. It is easier to recruit another CPU miner for peanuts, than getting enough ASIC hashing power to compete at the current difficulty. The most challenging task here is to find the right balance between first and second POW difficulty, and how to adjust this autonomously in a way compatible with the current difficulty adjustment scheme.

Sjå https://bitmynt.no for veksling av bitcoin mot norske kroner. Trygt, billig, raskt og enkelt sidan 2010.I buy with EUR and other currencies at a fair market price when you want to sell. See http://bitmynt.no/eurprice.plWarning: "Bitcoin" XT, Classic, Unlimited and the likes are scams. Don't use them, and don't listen to their shills.

Since most of you obviously haven't read it, let me direct your attention to Section 6 of the Bitcoin white paper:

Quote from: Bitcoin: A Peer-to-Peer Electronic Cash System, Section 6

The incentive may help encourage nodes to stay honest.If a greedy attacker is able to assemble more CPU power than all the honest nodes,he would have to choose between using it to defraud people by stealing back his payments,or using it to generate new coins.

He ought to find it more profitable to play by the rules,such rules that favour him with more new coins than everyone else combined,than to undermine the system and the validity of his own wealth.

Satoshi wasn't accounting for extrinsic economic motivations or shortcomings in miners' ability to assess what is in their own best interest.

Since most of you obviously haven't read it, let me direct your attention to Section 6 of the Bitcoin white paper:

Quote from: Bitcoin: A Peer-to-Peer Electronic Cash System, Section 6

The incentive may help encourage nodes to stay honest.If a greedy attacker is able to assemble more CPU power than all the honest nodes,he would have to choose between using it to defraud people by stealing back his payments,or using it to generate new coins.

He ought to find it more profitable to play by the rules,such rules that favour him with more new coins than everyone else combined,than to undermine the system and the validity of his own wealth.

Satoshi isn't infallible or god ... wise , yes, but made plenty of mistakes along the way ...

Dead serious. Should have been done years ago as we knew this moment may come.

"Speak softly, but carry a big stick"

We should welcome the miners back in a coin vote and forgive them for their miscalculation, but Jihan is threatening to attack the minority chain and steal funds from users on cores slack and twitter. He made multiple threats, may be bluffing , but we have to treat this seriously for him or any other attacker in the future.

Although I never really took the coin seriously due to their spammy and scammy sounding marketing, I think it's interesting how Myriad Coin attempts to introduce a plethora of POW algorithms... Something like this... an integrated feature whereby it is trivial for nodes to introduce new POWs, which all maintain their own difficulty is interesting in this context:

It appears to be the case that any one choice of POW will lead to eventual hardware specialization, and the way to fight this is to add hooks to make investment in any one hardware specialization scheme ineffective. Dynamic POW may achieve this.

I'm no expert on the hardware implementation of ASIC SHA, and have read earlier in this thread that simply switching to 3xSHA2 would be enough to break current hardware optimizations... what if the dynamic POW affected the depth of SHA required to find a hash?

To summarize, a few ways forward include:

1) Nodes choose POW dynamically... some single algorithm... valid for some number of blocks... before switching to a different one. Nodes communicate, perhaps with POS backing... which POW they currently accept?

2) Difficulty is assessed in both nonce as well as hash depth... though it would seem to me that it would be possible to develop specialized hardware which can perform sequential SHA calculations... (now that I think about it... why isn't this possible with current SHA2 chips?)

3) We just do this a few times... pick some new hash function with a HF... re-decentralize mining-- until it becomes clear that in general, it is not profitable to develop specialized mining hardware... so maybe we have to do it less in the future. maybe eventually never.

We just do this a few times... pick some new hash function with a HF... re-decentralize mining-- until it becomes clear that in general, it is not profitable to develop specialized mining hardware... so maybe we have to do it less in the future. maybe eventually never.

Asics will happen regardless, and we do not want to have developers forcing HF changes on the community because this opens up an attack surface. A pow HF must individually be decided upon by economic users, and preferably as a reaction after an attack occurs.

We just do this a few times... pick some new hash function with a HF... re-decentralize mining-- until it becomes clear that in general, it is not profitable to develop specialized mining hardware... so maybe we have to do it less in the future. maybe eventually never.

Asics will happen regardless, and we do not want to have developers forcing HF changes on the community because this opens up an attack surface. A pow HF must individually be decided upon by economic users, and preferably as a reaction after an attack occurs.

Agreed-- I'm not suggesting developers lobby for the POW changes. Obviously, this has to be a grassroots economic stakeholder driven process. I proposed a few mechanisms whereby the POW is somewhat dynamic to avoid the normalization of HFs in the context of, perhaps unavoidable, hardware optimization. In a perfect world, we wouldn't even have the need for this dialogue today.

Though, today, it is becoming clear that high percentage miners can hold the network ransom and make all kinds of DOS threats, so I'm not sure exactly what constitutes an attack from your perspective.

It has very strong ASIC-resistance and even a phone can mine without orders of magnitude loss in efficiency:

"The most cost effective Cuckoo Cycle mining hardware should consist of a relatively cheap and tiny many core memory controller that needs to be paired with commodity DRAM chips, where the latter dominate both the hardware and energy cost (about 1 Watt per DRAM chip)"

It will not be able to be mined for profit , and not listings on exchanges. If the testnet coins for this testnet start to find value for some odd reason we will reset it just like in bitcoins main testnet.

IF we are forced to carry out this HF , than yes, there will be 3 coins / chains ... with 2 new alts created, this , BTU , and the original chain. All three groups will likely fight over the "bitcoin" brand

It has very strong ASIC-resistance and even a phone can mine without orders of magnitude loss in efficiency:

"The most cost effective Cuckoo Cycle mining hardware should consist of a relatively cheap and tiny many core memory controller that needs to be paired with commodity DRAM chips, where the latter dominate both the hardware and energy cost (about 1 Watt per DRAM chip)"

Still more of a rumor, but I would not be surprised ... FPGA and ASIC development will be much quicker in the future, if anything the only thing keeping ASICs away from ETHhash is Vitalk's threat to switch to PoS

FWIW we evaluated Cuckoo as well for Zcash, and it was a strong second-place contender. There wasn't really anything wrong with it — it just didn't seem to have quite as much of a rigorous scientific analysis as Equihash. However, that is a very subjective thing for me to say. You could argue (and Cuckoo's author, John Tromp, does argue persuasively) that Cuckoo's history of analysis and refinement is better than Equihash's.

FWIW we evaluated Cuckoo as well for Zcash, and it was a strong second-place contender. There wasn't really anything wrong with it — it just didn't seem to have quite as much of a rigorous scientific analysis as Equihash. However, that is a very subjective thing for me to say. You could argue (and Cuckoo's author, John Tromp, does argue persuasively) that Cuckoo's history of analysis and refinement is better than Equihash's.

Zooko has a point here. There are trade-offs, but these are only some of the concerns.Take Monero for example. It is CPU/GPU but the CPUs do better for the money invested.The issue with it is that it is highly mined by botnet.

If Bitcoin goes the CPU route with its economic heft, it will encourage botnet mining to a significantly greater extent. This could have consequences for public relations, legality, VC investment appetite and other problematic results.

If the goal is to 'forever end the specter of miner influence on development direction', CPU PoW change might not be radical enough of a change, Bitcoin might have to go one of the more tested PoS methods, or find another solution to the Byzantine General problem.

If PoS is chosen, the longest successful, tried and tested PoS chain is probably Bitshares, which was refined again for Steem.

If a CPU PoS is chosen, may the governments of the world have mercy upon Bitcoin.

LOL. Core has offially jumped off the deep end. This proposal is insanity.

Can't win the vote by means that were established since 2009, and for good reasons (The Byzantine Generals Problem) - No Problem! Let's just change the way voting works.

You guys just proved that YOU are the ones trying to take control over Bitcoin. YOU are the ones trying to centralize it. You should be ashamed of yourselves for this blatant attempt to hijack the blockchain.

Go fuck yourselves, you dimwitted fanatics. But what did I even expect from people like luke-jr that officially stated that the Sun orbits around the Earth, and not vice versa? It's like talking to someone that's never even been to a school before.

But hey, be my guest, have fun with your centralized altcoin controlled by Blockstream. Great choice!

FYI: There aren't even any real developers contributing to this proposal - because they are not insane. Nobody with half a brain would put his name under this stinking turd of mental diarrhea. This is merely a marketing ploy to stir up shit. Luke-jr is not a developer, and he is far from being renowned. He's a religious fanatic that's paid to spread propaganda in Core's bitcoin reddit. I can provide you some of his quotes if you're interested. In short, he said that the death sentence is justified, that slavery is not immoral, that gays should not be allowed to marry, that the Sun orbits around the Earth, that masturbation and any kind of sexual relation not leading to procreation is a sin, and many more nonsensical statements like these.

... I think a large enough economic majority will make the current miners come along in a UASF. The miners have no interest in mining worthless coins after all.

Sturle, I am not an expert cryptocurrency programmer, but on the topic of business I feel qualified to comment: as a KnC exec said during their company's dying swan song, it's unlikely the Chinese mining operations would be able to operate at their margins unless the Chinese miners receive virtually unlimited funding from a state-level entity (e.g. the government of China or perhaps the PBoC).

Many of the people in those original reddit threads expressed concerns about Bitmain's disregard for market cap (e.g. Jihan Wu going unhinged, saying ""These stupid c*nts are going to be caught unprepared for the complex circumstances in which the fork is going to occur." source).

Recently, in the face of Bitfinex releasing tokens for people to speculate on the future value of forked variants (with BitcoinCoreCoin being valued around 0.8 BTC, and BitcoinUnlimitedCoin valued around 0.125 BTC), Jihan doubled down (and dropped the market cap a good $1 billion or so) by threatening to accelerate the BU hard fork.

That is why I suspect Bitmain does not simply want to gain control of Bitcoin, they are paid by governments to actually see to its destruction (economically).

In my view, the best way to remove Bitmain and other tyrants (for a year or two) is to have the full PoW change, rather than having 50% SHA-256 and 50% a new algorithm.

OTOH, yes I feel regret about the economic harm it would do to the non-tyrannical miners; maybe it's worth keeping say a 15% weighing of SHA-256 work so they are not totally wiped out.

I think a hardfork change is too drastic, and will certainly end in a contentious hard fork. A POW change light can be implemented as a soft fork by a requirement for an extra proof of work of a different type in the coinbase transaction or in another special transaction. This will encourage cooperation between miners having lots of specialized SHA256 hardware and users mining the extra proof of work on their CPUs.

Good thoughts but miners will never approve this proposal with BIP 9 and I doubt even 51% so would need to be a UASF , whicj will likely end up as a HF only . This proposal is more of a HF in reaction to a 51% attack from miners which would not be as controversial.

The current miners will still have a huge advantage with the extra-POW soft-fork model, since SHA256 hashing power as well is required to find blocks, so I think a large enough economic majority will make the current miners come along in a UASF. The miners have no interest in mining worthless coins after all. They will have to share their power and some of their income with CPU miners, since none of them can operate alone, but will likely still have most of the payout. It is easier to recruit another CPU miner for peanuts, than getting enough ASIC hashing power to compete at the current difficulty. The most challenging task here is to find the right balance between first and second POW difficulty, and how to adjust this autonomously in a way compatible with the current difficulty adjustment scheme.

LOL. Core has offially jumped off the deep end. This proposal is insanity.

Can't win the vote by means that were established since 2009, and for good reasons (The Byzantine Generals Problem) - No Problem! Let's just change the way voting works.

You guys just proved that YOU are the ones trying to take control over Bitcoin. YOU are the ones trying to centralize it. You should be ashamed of yourselves for this blatant attempt to hijack the blockchain.

Go fuck yourselves, you dimwitted fanatics. But what did I even expect from people like luke-jr that officially stated that the Sun orbits around the Earth, and not vice versa? It's like talking to someone that's never even been to a school before.

But hey, be my guest, have fun with your centralized altcoin controlled by Blockstream. Great choice!

FYI: There aren't even any real developers contributing to this proposal - because they are not insane. Nobody with half a brain would put his name under this stinking turd of mental diarrhea. This is merely a marketing ploy to stir up shit. Luke-jr is not a developer, and he is far from being renowned. He's a religious fanatic that's paid to spread propaganda in Core's bitcoin reddit. I can provide you some of his quotes if you're interested. In short, he said that the death sentence is justified, that slavery is not immoral, that gays should not be allowed to marry, that the Sun orbits around the Earth, that masturbation and any kind of sexual relation not leading to procreation is a sin, and many more nonsensical statements like these.

(2) Analysis of data - Identification and further extrapolation of patterns in data, technical critique of methods used in tests, model-based predictions of outcomes of tests (if the tests themselves are too resource/labor intensive to actually carry out)

(3) Interpretation of results - Discussion (with proof/justification) of what the results and analysis of the tests will mean for the Bitcoin market cap, decentralization, censorship-resistance, and any new vulnerabilities.

(4) Broader discussion - Including discussion of businesses related to Bitcoin, quotes by notable personalities relevant to Bitcoin, regulations and other activities of governments with respect to Bitcoin, and what implications these things have for the PoW project.

* it is memory-oriented rather than computation-oriented which makes it less cost-efficient to implement in ASIC,* it is asymmetric, meaning that verifying a solution is much cheaper than generating that solution (_even_ starting from the nonce that generates that solution); In particular it requires substantial RAM (hundreds of MB, depending on parameter choices) to generate a solution (or an attempted solution), but it does not require that much RAM to verify a solution. This may be useful for constrained implementations such as SPV wallets in constrained hardware, implementation inside the Ethereum VM, etc.* it has a good level of scientific investigation behind it, which makes me think it relatively unlikely than an algorithmic breakthrough would enable someone to find solutions much cheaper than the competition. This has been born out by the experience of live Zcash mining, where developers have made tremendous progress on micro-optimization, but as far as we know no algorithmic breakthroughs.

A reason to choose Equihash is that you benefit from the all of the research and implementation work described above. There are many well-tested implementations available, both open source and proprietary.

There will be no PoW change, this is merely a propaganda act by Blockstream to spread FUD about Bitcoin Unlimited. Core is about to lose the vote and now they're butthurt about it.

And luke-jr is a despicable idiot. Nothing more. Certainly not a developer of or contributor to anything, other than outdated views and retarded ideas.

BU is technically incompetent.... nobody will ever run the BU node with that mess of a codebase.. only chance for BU is: after they signal, make a large bounty and give real developers 14-30 days to properly upgrade core to 2mb limit.

Nobody trusts BU code - who cares about LuekJr religion. i trust his code.. and have nothing else in common with him.... I probably have more in common with you and Roger Ver, but will never run your BU nodes.

bitcoin is first and foremost a technical miracle.. economics is secondary

BU is actively attacking an 18 billion dollar asset that is owned by all humanity and has the best engineers volunteering their time for the greater good.

I believe the best option would be the addition of multiple proofs of work. Perhaps 4 (including SHA256).

There are many benefits: diversity of hardware, it dilutes the impact of centralised technology in one method, doesn't totally punish those who invested in ASICs - more likely to gain support.

Also, we could round robin different types of method, this would mean incompatible hardware would have 'down time', lowering the electric cost in relation to the hardware - also good for decentralisation.

If you had 4 proof of work methods, you could require that 2 seperate methods have found a block before a method is allowed to commence hashing again.

This also would allow for a soft fork if one method became malicious so that method could no longer produce blocks. Keeping each method honest.

pondjohn, I know similar ideas have been tested in myriadcoin-- would you be able to create a test branch of Bitcoin and modify it to run your proposed round-robin method? Once you have it running in, say, testnetPodJohn, other developers and QA people will look for unexpected exploits, performance drags etc.

tl;dr - I like the proposal, can you and other contributors create a test version we can all analyze/evaluate? Also what is a loose-estimate for when this could be ready?

I believe the best option would be the addition of multiple proofs of work. Perhaps 4 (including SHA256).

There are many benefits: diversity of hardware, it dilutes the impact of centralised technology in one method, doesn't totally punish those who invested in ASICs - more likely to gain support.

Also, we could round robin different types of method, this would mean incompatible hardware would have 'down time', lowering the electric cost in relation to the hardware - also good for decentralisation.

If you had 4 proof of work methods, you could require that 2 seperate methods have found a block before a method is allowed to commence hashing again.

This also would allow for a soft fork if one method became malicious so that method could no longer produce blocks. Keeping each method honest.

The same link above, the "OneCoin" has PoS with 0 block reward. Would such a solution be more feasible? PoS only might really not work, but if its complimented with PoW they make a good combination IMO.

But my real opinion is, don't change bitcoins fundamentals. The block size increase was planned by Satoshi anyway. Change of the proof of work algorithm was not and such a change would only lead to an "altcoin".

Bitcoins legacy is present in many altcoins, if you do not like Bitcoin then go devote your energy to an altcoin (like Vertcoin with its strong commitment to avoid ASICs and with that avoiding problems like this miner centralization).

bitcoin the protocol (the main thing behind Satoshis invention) is present in many of the altcoins, many up to date with Bitcoins codebase, even on the way of activating SegWit.

You will not betray Bitcoin if you do this, that's the point of a free market, if you do not like something, chose the alternative...

I assume Satoshi never wanted some fanatics fighting over this, if this means anything to you:

Code:

const char* pszTimestamp = "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks";

...the main point is to get away from this centralized systems, if you suspect Bitcoin is becoming one, go support another coin. That will make the miners think again and start caring more about their "customers".

Streisand effect? I thought Bitfury were the good guys, the fact George even is threatening this is affront to individual sovereignty and is reprehensible. Now I am further motivated to move forward with a PoW change backup. Lawyers from the US don't scare me ... good luck tracking all of us down throughout the world.

Hybrid SHA256/Keccak is now off the table for me , if a PoW algo change is done 100% of SHA256 ASICs will be ignored.

Let's change PoW so that anyone with moderate amount of capital can attack us, sounds like a great idea! Both cpu and gpu minable chains would be an easy target at this point when the economic target is as big and hated? as BTC. You sit here and worry about BU miners trying to kill a minority chain in case of a fork and want to trade that for gpu miners (who many are heavily invested into alt coins) and/or bot net owners. I guess the BU miners wouldn't mind since they would win by default when the core chain self destructs on a new PoW.

If you want some tinfoil this is how I would take over BTC on a budget and couldn't just 51% the current network due to my inability/unwillingness to spend the needed funds.

- Get cosy with lead devs. - Push for PoW change to something supposedly ASIC resistant.- Develop ASIC solution in advance for when switch happens (can be on shit node and somewhat low cost, use mining profits to jump to bleeding edge asap later) This would cost a fraction of what building hardware to try and take over current network by building hardware (more than factor of 10-20x). This might even be within reach of a wealthy early adopter *hint*, a couple of mil is enough to do a mass rollout on say 65/40 nm. - Easily keep CPU/GPU miners at bay due to them being unprofitable, doesn't even make it apparent anything strange is going on (someone just have cheaper power and more cards duh!)- Reap majority of all block rewards.- Stay cosy with the devs and push for any and all changes you want to do, congrats you now own the network without anyone the wiser.- Even if competition starts developing their own ASICs its something that takes months to get working hardware out of and even longer to mass produce.

... I think a large enough economic majority will make the current miners come along in a UASF. The miners have no interest in mining worthless coins after all.

Sturle, I am not an expert cryptocurrency programmer, but on the topic of business I feel qualified to comment: as a KnC exec said during their company's dying swan song, it's unlikely the Chinese mining operations would be able to operate at their margins unless the Chinese miners receive virtually unlimited funding from a state-level entity (e.g. the government of China or perhaps the PBoC).

I doubt that, but it is a different issue. I don't think we should base an altcoin on a conspiracy theory.

In my view, the best way to remove Bitmain and other tyrants (for a year or two) is to have the full PoW change, rather than having 50% SHA-256 and 50% a new algorithm.

My point is that you can't change the POW in Bitcoin. You can make a new coin with a different POW, and you can even carry over all the coins fro Bitcoin in a genesis block or whatever, and fix everything else which is wrong in Bitcoin in the same go, but you can't change the POW agorithm. It is impossible. It will become a new coin either you want to or not, It is just as stupid as those scammers who pretend it is possible to increase the blocksize in Bitcoin. It will become a new coin either you want to or not.

The only way to upgrade the POW while keeping Bitcoin Bitcoin, is to add an extra POW as a soft fork.

I see there are mostly newbies posting in this thread. Perhaps you should take some time to educate yourself about how bitocoin and blockchains work.

Sjå https://bitmynt.no for veksling av bitcoin mot norske kroner. Trygt, billig, raskt og enkelt sidan 2010.I buy with EUR and other currencies at a fair market price when you want to sell. See http://bitmynt.no/eurprice.plWarning: "Bitcoin" XT, Classic, Unlimited and the likes are scams. Don't use them, and don't listen to their shills.

What do you guys think of Bram Cohens Proof of Space/Proof of Time?I agree with him that PoW is a waste of energy, however all the experts say everything else is a joke and won't work. (Proof of Stake etc...)So I guess our only option is to use PoW to secure the blockchain. But then again I'm no expert so I don't know if Proof of Space/Proof of Time is feasible or not.

LOL. Core has offially jumped off the deep end. This proposal is insanity.

Can't win the vote by means that were established since 2009, and for good reasons (The Byzantine Generals Problem) - No Problem! Let's just change the way voting works.

You guys just proved that YOU are the ones trying to take control over Bitcoin. YOU are the ones trying to centralize it. You should be ashamed of yourselves for this blatant attempt to hijack the blockchain.

Go fuck yourselves, you dimwitted fanatics. But what did I even expect from people like luke-jr that officially stated that the Sun orbits around the Earth, and not vice versa? It's like talking to someone that's never even been to a school before.

But hey, be my guest, have fun with your centralized altcoin controlled by Blockstream. Great choice!

FYI: There aren't even any real developers contributing to this proposal - because they are not insane. Nobody with half a brain would put his name under this stinking turd of mental diarrhea. This is merely a marketing ploy to stir up shit. Luke-jr is not a developer, and he is far from being renowned. He's a religious fanatic that's paid to spread propaganda in Core's bitcoin reddit. I can provide you some of his quotes if you're interested. In short, he said that the death sentence is justified, that slavery is not immoral, that gays should not be allowed to marry, that the Sun orbits around the Earth, that masturbation and any kind of sexual relation not leading to procreation is a sin, and many more nonsensical statements like these.

My point is that you can't change the POW in Bitcoin. You can make a new coin with a different POW, and you can even carry over all the coins fro Bitcoin in a genesis block or whatever, and fix everything else which is wrong in Bitcoin in the same go, but you can't change the POW agorithm. It is impossible. It will become a new coin either you want to or not, It is just as stupid as those scammers who pretend it is possible to increase the blocksize in Bitcoin. It will become a new coin either you want to or not.

The only way to upgrade the POW while keeping Bitcoin Bitcoin, is to add an extra POW as a soft fork.

I see there are mostly newbies posting in this thread. Perhaps you should take some time to educate yourself about how bitocoin and blockchains work.

The number of mind numbingly unaware posts here and on reddit has become ridiculous over the last week. I mean there are people literally suggesting forking to a different PoW algorithm while calling Bitcoin Unlimited the altcoin if it hard forks, etc. If you're the coin that's forking to a different algorithm entirely and also changing the way transactions are sent then how can you argue that the other coin is the altcoin?

Adding an extra PoW might genuinely help to regain some of the distributed nature of early Bitcoin, but I think that long term this will be just a bandaid again. Someone somewhere will likely work on an ASIC that's better for any new algorithm and then in a few years we'll again be very centralized.

The number of mind numbingly unaware posts here and on reddit has become ridiculous over the last week. I mean there are people literally suggesting forking to a different PoW algorithm while calling Bitcoin Unlimited the altcoin if it hard forks, etc. If you're the coin that's forking to a different algorithm entirely and also changing the way transactions are sent then how can you argue that the other coin is the altcoin?

testerx, I believe what is being discussed here is if bitmain decides to attack the bitcoin blockchain. If they have 51% of the hashing power (and there's no reason to think they don't) they can stop all transactions that they don't want. In this likelihood, it will be very good to have an alternate PoW available that can be introduced as an emergency fork.

I don't think anyone doubts that this just kicks the can down the road in its current implementation. It is, however, important that we, the users, protect bitcoin from this hostile take-over attempt. Maybe if they see the gun cocked at their heads they'll rethink it. They better.

Would it be possible to have multiple PoW's, where the difficulty reset of each PoW algorithm was dependent upon how quickly they resolved the next block?

Each node has the logic to validate multiple PoW blocks. At the difficulty reset, the timing for each PoW is calculated, and the difficulty for each PoW is reset based upon how quickly they found blocks for that PoW. Then, you could introduce other PoW's into the system without negatively affecting (at least too much) existing miners of a specific PoW. You could soft-fork in a new PoW (like keccak?) which already has miners using it. I suppose you could also soft-fork specific miners out. What are the chances of a single miner being proficient in all algorithms? Not high I imagine.

How to kill million-dollar industry in one commit (c)LukeJRNever gonna happen. He can create just another altcoin.Also, it is old stuff in his own repo "luke-jr committed on 16 Jan 2016", he planned it on beginning 2016 Apr 14Yet another FUD to play on bitcoin value?

No joke as far as I'm concerned. We have to have a plan in place in case bitmain attacks the network when they don't get their way. To not have a plan when someone is repeatedly threatening you isn't a good way to manage risk. I hope it isn't required. Only bitmain can answer the question about whether it is required or not.

How to kill million-dollar industry in one commit (c)LukeJRNever gonna happen. He can create just another altcoin.Also, it is old stuff in his own repo "luke-jr committed on 16 Jan 2016", he planned it on beginning 2016 Apr 14Yet another FUD to play on bitcoin value?

This is decidedly not about luke-jr, or 'Core' (as some have suggested) or Jihan Wu.

Others were discussing change of POW at the same time as that github commit:

So finally i had the answer to my question in the first page of the thread, i would like to ask for all the Advantages/Inconvenients who could result from an algorythm change, i am aware of bitmain's attempt, and if ViaBtc is really a child of Bitmain, they will own more then 51% of the network.

If the algorythm change can really bring protection against this situation, then i am totally for algo change. yet i want to know what are the expected effects on the network, users, markets. I don't want bitcoin to turn to BU, both philosophies are different, and opposing at some points.

The recent events should really get every user to think about what would happen if bitmain achieves the 51%+ network hashrate, and to the announcements in the twitter account of Jihan Wu.

Don't like the options. Don't think there should be a hard-fork unless bitcoin is attacked by the china-coin chain. If they want to fork-off, it is their right. There's no reason to punish the miners that don't. While I think a PoW needs to be investigated in the medium to long-term, I don't think it's necessary unless bitcoin is attacked.

This is my take on what would happen if BU forked and took 50% of the hashing power. It would almost immediately see SegWit being enabled. That's one thing I would love to see, and I suspect the UASF trigger could make this happen, because you could set the UASF trigger to be the middle of a difficulty epoch.

Let's assume we're talking about mid epoch. The only thing we can really be sure of, yes? The average? For brevity, let's say 1000 blocks.

1000 blocks : one week. 10 minute blocks.

1000 blocks : 50% hashing rate. Two weeks. 20 minute blocks.

Three weeks til difficulty reset. Then, because the difficulty calc will include both parts of this (50% full-mine, 50% half-mine), the new lowered difficulty will be 2/3 of the difficulty it was before, with 50% of the previous hashing power. So ~15 minutes blocks.

Off the top of my head, I reckon that would be another three weeks instead of two. Then the difficulty resets to the available miners, and you're back to normal.

So :

Fork happens.

Two weeks : 20 minute blocks

~Three weeks : ~15 minute blocks.

Then back to normal. Assuming miners don't see the potential for huge fees to be had by switching over. Cuz, you know, money. I might be out for a few days or so, but I reckon it'll be about this assuming 50%. Seeing as I think bitmain actually has 50% or so of hashing power, I think I'll be close to right.

It's almost like you want bitmain to fork off. Because blocks will be bigger, so more transactions, but the block creation time will be longer, so less blocks. So less miners creating blocks less often, each with more transactions. Net effect to miners? More total fees in larger blocks and more for each miner. Net effect to users? Same fees for larger blocks that are created less often.

For those five weeks, miners will have a field-day. 50% more profit? Good on em I say.

And if they do attack? PoW change (to something like Keccak that already has an infrastructure?) and bonza, off we go again, no difficulty reset, and everyone wants to pile into keccak mining. I really hope we have a real solution to miner centralization instead of kicking the can down the keccak road though.

It would be a good idea to use a memory intensive pow, 6gb or more. This will eradicate the supposed threat from bot nets and allow for anyone with a CPU to mine with a simple ram upgrade. One CPU one vote. The bitcoin network can be secured once again by off the shelf parts.

I also think having this ready to go and on testnet as a counter to any malicious actors is great. Hopefully consensus can be reached but China pboc has already announced they want to make their own crypto coin we can not ignore the fact it is in their interest to try and undermine the open bitcoin network.

But let's not fuck about, forget the "only in an insurmountable emergency" rhetoric, the emergency is already here.

The longer it takes to build support, the quicker proven bad actors like Bitmain will just develop a Keccak ASIC, if they've not started doing that already. Keccak PoW coins have already been tested in the market, doing 101% rigorous QA is a trade-off against the actual attack we're trying to fend off.

And if it's more appropriate to change the name, The Blockchain Formerly Known as Bitcoin, whatever, then so be it. The brand is the flimsiest aspect of the current Bitcoin's value proposition, it's arguably a highly desirable public relations move, as it then forces the attackers into coming up with different reasons why they're now desperate to "save" everyone from the evil developers who switched from Bitcoin to neoBitcoin.

i.e. If BU saved everyone from the evil Bitcoin Core devs, what is the need to follow them around, constantly trying to hard-fork the new project?

I doubt Bitmain will loose time and money to develop a keccac ASIC, they did an enormous investment in the new farm.

The emergency is to make bitcoin compliant with an algorythm change, if the miners still wants to force a protocl change, then he will simply be activated. It can be used a threatening option.

Do not forget that miners have to follow the community, not force it to adopt the changes they want, if the miners want a more suitable version of bitcoin to mine, let them create their own, i will stay with bitcoin-core as long as they respect the original ideology, because i respect people who do so, and i respect their ideology.

I don't care about bitcoin price, nor about his name, these can change as long as the heart remains the same.

I suggest to change the name of new PoW BTC chain to Bitcon.Then evil pissed-off miners and alnasty Ver-guy can't sue us for usage of Bitcoin(TM).Let them fail in price of BTU on exchanges, when all honest believers in Core The Blessed will dump all free BTU sinful tokens.So everyone will see then that it's their fault that Bitcoin(aka BTU) suffers so harsh fate.

As to new algo for PoW i think we must invite here Mike Hearn.He is very cool cryptodude. He can manage to master it with small help of Peter Todd and Gavin Andresen.Together we shall win.And sinful BU will fall under our swords miserably !

"...Enemies are everywhere ! Angka is all rage ! Be a good soldiers, blow everything... " <-- Pol Pot (C)

“We have prepared $100 million USD to kill the small fork of CoreCoin, no matter what POW algorithm, sha256 or scrypt or X11 or any other GPU algorithm. Show me your money. We very much welcome a CoreCoin change to POS.”

We must prepare!

How about developing a ethash and Equihash PoW change so we can have ETC and Zcash merge mine bitcoin for much more security in case Zhuoer and other miners decide to spin up their GPU farms in an attack as they have claimed? Having 2 different tested PoW algos would also have the benefit of being more difficult to create an asic for. What do you guys think?

I told you already: "preparing" sounds too much like a euphemism for "fucking around"

Quit the bandying of hashing algorithms around already, we need to pre-empt their attack, not sit around waiting for it to happen. If the lead-time to develop a Keccak ASIC is long enough, we need to get the ball rolling, as soon as is diligently possible.

I agree that giving the user control is the way to go, any change of PoW only kicks the can down the road.What do you think about addition of a database where every miner is defined by his bitcoin address and every set of miners is defined by an unique string.Then any block that includes a transaction containing incorrect string (miner missing in set) is rejected by the network.This way rogue miners will be penalized with lost fees and signaling of code changes can be based on amount of earned fees instead of hashrate.

I told you already: "preparing" sounds too much like a euphemism for "fucking around"

Quit the bandying of hashing algorithms around already, we need to pre-empt their attack, not sit around waiting for it to happen. If the lead-time to develop a Keccak ASIC is long enough, we need to get the ball rolling, as soon as is diligently possible.

Simply changing the PoW pre-emtively sets a bad precedent because it harms good miners and long term investors and it will harm cryptocurrency in general by showing how flippant the community can be. Most of the users and core developers I have spoken to do not support pre-emptively changing the PoW algo, thus this HF would have very few following it , and we would not have the moral high ground. Also , merely preparing and testing is a form of pre-emption because it is enough to scare the hell out of miners so they do not attack in the first place . We already see Jihan opening up and looking for a compromise by the mere mention of a PoW change. We should not let this stop the work we are doing here though.

Perhaps there can be another way though to prepare .... where we develop a full node wallet , like Knots, where it simultaneously mines the other PoW algo on a testnet, where during times of contention users can enable this secondary mining and have the users ready to quickly HF over when ready.

I told you already: "preparing" sounds too much like a euphemism for "fucking around"

Quit the bandying of hashing algorithms around already, we need to pre-empt their attack, not sit around waiting for it to happen. If the lead-time to develop a Keccak ASIC is long enough, we need to get the ball rolling, as soon as is diligently possible.

Simply changing the PoW pre-emtively sets a bad precedent because it harms good miners and long term investors and it will harm cryptocurrency in general by showing how flippant the community can be. Most of the users and core developers I have spoken to do not support pre-emptively changing the PoW algo, thus this HF would have very few following it , and we would not have the moral high ground.

Perhaps there can be another way though to prepare .... where we develop a full node wallet , like Knots, where it simultaneously mines the other PoW algo on a testnet, where during times of contention users can enable this secondary mining and have the users ready to quickly HF over when ready.

True, someone aleready experimented a multi algo coin, i forgot the name of the coin, but it can't bring good results as each algorithm requires custom GPU tweaks, so if you change the algo at each new block, miners will leave. Annother sollution would be to define an ASIC safe algo and use it, i don't know much about Keccac, but if luke-jr believes that he can be amended to fit in bitcoin-core code, then we should go for this sollution.

True, someone aleready experimented a multi algo coin, i forgot the name of the coin, but it can't bring good results as each algorithm requires custom GPU tweaks, so if you change the algo at each new block, miners will leave. Annother sollution would be to define an ASIC safe algo and use it, i don't know much about Keccac, but if luke-jr believes that he can be amended to fit in bitcoin-core code, then we should go for this sollution.

Fair concern ... but if the algos match ETC and zcash and merged mined couldn't this concern be negated as we would be bringing in 2 different communities to help secure Bitcoin? ETC and zcash folks get along with Bitcoin Core folks as well and share many similar values and we could benefit from their collaboration against those who wish to attack immutability.

What do you guys think of Bram Cohens Proof of Space/Proof of Time?I agree with him that PoW is a waste of energy, however all the experts say everything else is a joke and won't work. (Proof of Stake etc...)So I guess our only option is to use PoW to secure the blockchain. But then again I'm no expert so I don't know if Proof of Space/Proof of Time is feasible or not.

Forget their words, or rhetorical actions, and look strictly at what their primary mode of behaviour adds up to. They will do or say anything in order to get what they want; the destruction of this currency and it's economy.

Decisive, strike-first and belligerent evasive action is probably the only thing that can save the value in the Bitcoin network as it is today, and if you can't see that, and some surprise move that nobody (except apparently me) anticipated sends things into even more of a tailspin, then you and everyone else who are saying "let's talk and pro-crastinate on our options for another 9 months" will get everything you deserve.

To put it another way, imagine that those directing Bitmain's actions have a planned killer blow to land. Do you think they're going to announce it 6 months in advance on a public forum? We must act, we're being forced into an "eat or be eaten" situation, and you can't see it.

Again Carlton is right, they are too beligerant to be trusted, they use any opportunity to blaim bitcoin-core devs, have anyone here checked the issue opened in BU's repo by gmaxwell ? It is an edifiant example of how they behave when it comes to core devs.They actions untill know proofs they want to take over bitcoin, plus, their code is in appearance open sourced, but only to watch, if you want to contribute you need them to accept your modifications, and they some says they are glad to pay for others to work on BU code. This makes me thinking of some shitcoins, they always work like that.Actions, either offencive, or deffencive, must be taken to ensure the future of bitcoin.I don't know for you, but i won't accept a paypal 2.0If miners take controle of bitcoin, they will for sure play with fees, or, who knows, maybe they will totally screw the code, the same way they screw BU code.

I have nothing agains capitalism, but it is really bad for decentralised projects, as they tend to add more centralisation in order to controle it. think about this.

Forget their words, or rhetorical actions, and look strictly at what their primary mode of behaviour adds up to. They will do or say anything in order to get what they want; the destruction of this currency and it's economy.

Decisive, strike-first and belligerent evasive action is probably the only thing that can save the value in the Bitcoin network as it is today, and if you can't see that, and some surprise move that nobody (except apparently me) anticipated sends things into even more of a tailspin, then you and everyone else who are saying "let's talk and pro-crastinate on our options for another 9 months" will get everything you deserve.

To put it another way, imagine that those directing Bitmain's actions have a planned killer blow to land. Do you think they're going to announce it 6 months in advance on a public forum? We must act, we're being forced into an "eat or be eaten" situation, and you can't see it.

Do you really believe that they can produce a Equihash, Keccak, or ETHhath asic in 6 months?

We should also be prepared with a secret backup HF algo tested and ready to go in the event they do indeed decide to attack with a secret ASIC, this should alleviate your concerns. If your concern is that they will fund gpu farms to attack , than we should be pushing for a Equihash and /or Ethhash merge mine option to protect ourselves.

There is something to be said with maintaining the moral high ground as well.... defensive only approach will attract many more people and thus much more investment , trust and security as we already see from the fact that almost everyone wants defensive only.

Forget their words, or rhetorical actions, and look strictly at what their primary mode of behaviour adds up to. They will do or say anything in order to get what they want; the destruction of this currency and it's economy.

Decisive, strike-first and belligerent evasive action is probably the only thing that can save the value in the Bitcoin network as it is today, and if you can't see that, and some surprise move that nobody (except apparently me) anticipated sends things into even more of a tailspin, then you and everyone else who are saying "let's talk and pro-crastinate on our options for another 9 months" will get everything you deserve.

To put it another way, imagine that those directing Bitmain's actions have a planned killer blow to land. Do you think they're going to announce it 6 months in advance on a public forum? We must act, we're being forced into an "eat or be eaten" situation, and you can't see it.

Do you really believe that they can produce a Equihash, Keccak, or ETHhath asic in 6 months?

We should also be prepared with a secret backup HF algo tested and ready to go in the event they do indeed decide to attack with a secret ASIC, this should alleviate your concerns. If your concern is that they will fund gpu farms to attack , than we should be pushing for a Equihash and /or Ethhash merge mine option to protect ourselves.

Talking about merged mining, what would happen to the other coins who have merged mining with bitcoin ? and counter party assets ?

Carlton is on the right track. If we're going to do the "nuclear option" (change POW), then we must assume the worst. Assume the adversary has ulterior motives, like to destroy bitcoin. Assume the adversary is extremely well funded, like from a large government. Assume the adversary has anticipated POW changes and has CPU/GPU/FPGA farms along with massive botnets standing by. It is not unreasonable to assume our current adversaries have this level of resources at their disposal. Given these assumptions, perhaps there should be some "fallback" contingency plans in case a POW change proves ineffective. Would allowing only trusted mining pools be an acceptable level of existence, at least until a better trustless system can be developed?

Do you really believe that they can produce a Equihash, Keccak, or ETHhath asic in 6 months?

Do you really believe that alternative attacks won't get used by an exasperated opponent?

Imagine a group of "concerned nation states" collaborate on issuing an international arrest warrant for the Bitcoin devs for "conspiracy to launder money", or "conspiracy to fund terrorist organisations"? How long do you think that would take to draw up, in the event, 6 months?

What are you going to say if that happens? "No-onnnnnnne could possssssssibly have predicted that!" Again, except me, apparently.

This ceased to be a computing problem a long time ago, we wouldn't be in this situation if solving computing problems was all we needed to overcome this situation. The $ 5 wrench is poised to get cracked over Bitcoin's soft head, and the inability to take in this particular big picture could be the difference between a deft sidestep and the absolute end of the Bitcoin project.

If we sit on our hands taking the moral high ground, predators will predate. Are you understanding what I'm saying to you, or what?

We should assume the worse and prepare for it , I just don't agree with you practically that doing so preemptively will lead to better security , in fact I believe it will lead to far less security because few will follow such a HF

Doing it pre-emptively without getting at least the exchanges on our side, will make us the altcoin in the market.

PoW change needs to be ready but I think activation needs to only happen if/when they get near to a hashrate that allows for a HF. This can be done relatively safely.

Obviously we could discuss the phasing out of this PoW in favour of another one in a situation of calm, maybe with a progressive transition period to allow for miners to adapt. But that's a different situation.

We should assume the worse and prepare for it , I just don't agree with you practically that doing so preemptively will lead to better security , in fact I believe it will lead to far less security because few will follow such a HF

Did you hear Bitmain's recent announcement about a mining facility that will push their hashrate share up to 80%? Possibly hyperbole, and I'm fully aware too of the temporary nature of hashrate shares, but the status quo is looking decidedly less secure also.

I suspect the remaining well intentioned miners will either accept the BU gruel, and/or accept the inevitable necessity of pre-emptive action. What makes you think Bitmain would honour the 3 difficulty adjustment periods that BU needs to activate it's fork? They've been so incredibly honorable and straight up to now, huh?

We should assume the worse and prepare for it , I just don't agree with you practically that doing so preemptively will lead to better security , in fact I believe it will lead to far less security because few will follow such a HF

Did you hear Bitmain's recent announcement about a mining facility that will push their hashrate share up to 80%? Possibly hyperbole, and I'm fully aware too of the temporary nature of hashrate shares, but the status quo is looking decidedly less secure also.

I suspect the remaining well intentioned miners will either accept the BU gruel, and/or accept the inevitable necessity of pre-emptive action. What makes you think Bitmain would honour the 3 difficulty adjustment periods that BU needs to activate it's fork? They've been so incredibly honorable and straight up to now, huh?

BitUsher has a point. A preemptive fork simply won't get enough support. Best to develop contingency plans in secret.

We should assume the worse and prepare for it , I just don't agree with you practically that doing so preemptively will lead to better security , in fact I believe it will lead to far less security because few will follow such a HF

Did you hear Bitmain's recent announcement about a mining facility that will push their hashrate share up to 80%? Possibly hyperbole, and I'm fully aware too of the temporary nature of hashrate shares, but the status quo is looking decidedly less secure also.

I suspect the remaining well intentioned miners will either accept the BU gruel, and/or accept the inevitable necessity of pre-emptive action. What makes you think Bitmain would honour the 3 difficulty adjustment periods that BU needs to activate it's fork? They've been so incredibly honorable and straight up to now, huh?

I am assuming the worse, as I previously stated... but rather than react based upon emotion or have second thoughts towards their intentions , I believe being defensive in this circumstance is far safer and will rally far more behind the HF than doing it preemptively. It is merely a matter of pragmatism with the best position forward.

Bitmain could pre-emptively hardfork themselves during an unknown 24 hour timeframe, with 75% of the hashrate and a pathological desire to destroy Bitcoin, why do they need to even pretend to be cautious?

We'd have very little useful time available to turn that situation around, but I strongly suspect disenfranchised miners would be only too happy to support the PoW change, once it's potentially too late.

I fail to see how that argument could not convince all who percieve they will lose out in a PoW change situation to support pre-emptive action.

Bitmain could pre-emptively fork themselves during an unknown 24 hour timeframe, with 75% of the hashrate and a pathological desire to destroy Bitcoin, why do they need to even pretend to be cautious?

We'd have very little useful time available to turn that situation around, but I strongly suspect disenfranchised miners would be only too happy to support the PoW change, once it's potentially too late.

I fail to see how that argument could not convince all who percieve they will lose out in a PoW change situation to support pre-emptive action.

Why would it be too late after an attack to HF? A few txs get stolen or blocked?

By my estimates 95% won't preemptively fork the PoW algo ... do you really think you can convince them all to preemptively HF?

It's profoundly unreasonable to pass off unbacked assertions as any form of reason

I've provided sound reasoning already, refute it.

I would if I could find it, but from what I see you've taken some facts, made up a story around them, and then because your story fits the facts you say it must be true. But of course your story fits the fact, you used them to make it up.

Bitmain could pre-emptively fork themselves during an unknown 24 hour timeframe, with 75% of the hashrate and a pathological desire to destroy Bitcoin, why do they need to even pretend to be cautious?

Its very unreasonable to assume that have a pathological desire to destroy Bitcoin.

Is it unreasonable to assume they have a very pragmatic incentive to destroy bitcoin, like state-funding and influence?

No, but its unreasonable to assume that because they have an incentive they must be doing it. You seem to have seen a possibility and jumped from it being possible (but quite unlikely) to saying it must be true.

We all have incentives to rob, murder and rape people all the time. We generally don't do it though, and to assume that people are doing that is not a good thing.

Why would it be too late after an attack to HF? A few txs get stolen or blocked?

For a similar reason you're giving not to pre-empt it: building support for the new idea. It's possible that too many people will be psychologically impacted by the success of the attack, and consequently do what you're suggesting is wrong with my approach (despite the fact I've made no emotional arguements at all): allow emotions to dictate their decision instead of reason.

If we engage people to support pre-emptive action, a determined mindset would replace a fatalistic reaction. It's about harnessing a positive psychological feedback loop instead of a negative psychological feedback loop.

By my estimates 95% won't preemptively fork the PoW algo ... do you really think you can convince them all to preemptively HF?

Including Bitmain's current hashrate %? Clearly not. A PoW fork only needs to get the support of the miners who don't want to be ruled by a malign majority, although I'm seeing an obvious problem; how to measure that. Setting a block height activation would invite counter measures. Not sure how it could be achieved.

We all have incentives to rob, murder and rape people all the time. We generally don't do it though, and to assume that people are doing that is not a good thing.

you're one of those people who think crime is as depicted on TV; crime occurs, victim is able to phone the police, and the police turn up just in time to catch the blundering criminal? Grown ups are talking

No, but its unreasonable to assume that because they have an incentive they must be doing it. You seem to have seen a possibility and jumped from it being possible (but quite unlikely) to saying it must be true.

We all have incentives to rob, murder and rape people all the time. We generally don't do it though, and to assume that people are doing that is not a good thing.

State involvement creates a strong enough incentive to override all others against (mining revenue, ethics, etc)

This is a reasonable assumption when planning a POW change, since the only reason to do so would be in response to a 51% attack. Why bother otherwise?

We all have incentives to rob, murder and rape people all the time. We generally don't do it though, and to assume that people are doing that is not a good thing.

you're one of those people who think crime is as depicted on TV; crime occurs, victim is able to phone the police, and the police turns up just in time to catch the blundering criminal? Grown ups are talking

I have difficulty making out what point you are trying to make, other than that you are trying to insult me in some very strange way.

You are saying that because police can't prevent crimes we should just assume everyone is a criminal and act accordingly? If so that is one of the most absurd things I've ever heard.

No, but its unreasonable to assume that because they have an incentive they must be doing it. You seem to have seen a possibility and jumped from it being possible (but quite unlikely) to saying it must be true.

We all have incentives to rob, murder and rape people all the time. We generally don't do it though, and to assume that people are doing that is not a good thing.

State involvement creates a strong enough incentive to override all others against (mining revenue, ethics, etc)

This is a reasonable assumption when planning a POW change, since the only reason to do so would be in response to a 51% attack. Why bother otherwise?

I do not agree that we would all be raping and murdering all the time if it wasn't for the all powerful government putting us in our place.

It is reasonable to plan a PoW change in response to a 51% attack. It is unreasonable to suggest that Bitmain are mentally deranged and intent on destroying Bitcoin for no reason and that we should pre-emptively attack to punish them for something you have no evidence for.

Why would it be too late after an attack to HF? A few txs get stolen or blocked?

For a similar reason you're giving not to pre-empt it: building support for the new idea. It's possible that too many people will be psychologically impacted by the success of the attack, and consequently do what you're suggesting is wrong with my approach (despite the fact I've made no emotional arguements at all): allow emotions to dictate their decision instead of reason.

If we engage people to support pre-emptive action, a determined mindset would replace a fatalistic reaction. It's about harnessing a positive psychological feedback loop instead of a negative psychological feedback loop.

By my estimates 95% won't preemptively fork the PoW algo ... do you really think you can convince them all to preemptively HF?

Including Bitmain's current hashrate %? Clearly not. A PoW fork only needs to get the support of the miners who don't want to be ruled by a malign majority, although I'm seeing an obvious problem; how to measure that. Setting a block height activation would invite counter measures. Not sure how it could be achieved.

It seems like you're calling for a marketing campaign. You may be right that this is what needs to be done, but I don't think a bunch of technocrats will be able to successfully carry it out.

I do not agree that we would all be raping and murdering all the time if it wasn't for the all powerful government putting us in our place.

It is reasonable to plan a PoW change in response to a 51% attack. It is unreasonable to suggest that Bitmain are mentally deranged and intent on destroying Bitcoin for no reason and that we should pre-emptively attack to punish them for something you have no evidence for.

You completely misunderstood my point. State involvement doesn't keep people from raping and murdering. It actually tends to do the exact opposite. If the people running Bitmain are primarily funded by government, then they are acting in their government's best interest. If you can't see how this is a mortal threat to bitcoin, there's no point discussing it further in this thread.

Thank you, this is basically the kind of randomized PoW I had in mind. The author's objection to memory-hard functions is that they're susceptible to botnets. However, if the memory requirement were made really big (>16GB, say), the number of infected computers that could run the PoW (and undetected by their owners all the more so) would be more-or-less insignificant, I think.

I agree let them try and fork first. Imo bitcoin community is very resilient.

They have been dumping trying to drive the price down and pumping shit corporate coin like zcash (where Ver and pboc by proxy are investors and receiving a portion of every block mined).

Bitcoin is fine - have pow ready (memory Intensive) stick to it and announce it so the bitcoin faithful know what to expect. And if pboc want to fork off let them. No users that understand what bitcoin really stands for will be following them no matter how many threats they make. This is very simple.

Side note I never bothered posting on here but I signed up in 2013. Bitcoin will be just fine. Buy cheap coins spend and replace and hold on. They will keep throwing their money away till they have none left. Bitcoin is an idea And you can not kill it. You can only replace it with a better one and that one is not centralized mining.

Memory hardened is not susceptible to bot nets if the memory requirement is adequate. That is the fud gpu farmers push. Higher memory requirement would eliminate that non issue.

I have difficulty making out what point you are trying to make, other than that you are trying to insult me in some very strange way.

You are saying that because police can't prevent crimes we should just assume everyone is a criminal and act accordingly? If so that is one of the most absurd things I've ever heard.

This isn't relevant, create a thread in the Politics section for your derailing

Please don't try to bully me, because it won't work.

You were trying to suggest a pre-emptive PoW change because you believe that Bitmain are irrational actors who were only interesting in trying to destroy Bitcoin. I pointed out you have no evidence for that and its irrational to proceed on the basis on something for which there is no evidence. You then started ranting about police; I just said I didn't understand what (relevant) point you were trying to make.

I suggest if you want to engage in exploring unfounded conspiracy theories you take that to the politics section.

I do not agree that we would all be raping and murdering all the time if it wasn't for the all powerful government putting us in our place.

It is reasonable to plan a PoW change in response to a 51% attack. It is unreasonable to suggest that Bitmain are mentally deranged and intent on destroying Bitcoin for no reason and that we should pre-emptively attack to punish them for something you have no evidence for.

You completely misunderstood my point. State involvement doesn't keep people from raping and murdering. It actually tends to do the exact opposite. If the people running Bitmain are primarily funded by government, then they are acting in their government's best interest. If you can't see how this is a mortal threat to bitcoin, there's no point discussing it further in this thread.

Perhaps I did misunderstand your point then, but I think you also haven't recognized mine: It is possible that the Chinese government could be exerting pressure on Bitmain and the fact that it is a possibility should not be ignored, but it is very dangerous to make the jump from it being possible to assuming that it is true.

I understand that many of you may be engaged in security type work where you have to see any threat and assume that it will happen. But when dealing with people that is a very dangerous way to act. It is a big mistake to assume the worst possible scenario and act accordingly, because you are assuming significant costs associated with your actions which are most likely uneccessary.

Also if you want to assume the worst, the conspiracy theory about Blockstream trying to take over with their lightning network is just as plausible. At some point we have to all back down from the extremes and stop creating more problems that there needs to be.

Ok, this is getting offtopic ... whether some people want to fork before an attack can be discussed later as the first step must be deciding upon the algo , finishing the code, peer review, creating a testnet , testing , compiling the binaries...

So we should probably compensate some devs to incentivize quick execution on some of the above. We need a mutisig address with three known non anonymous trusted member of the community to accept donations like with UASF and a list of tasks to get started ... I'll be more than happy to donate.

I beg of you to put off this debate until after we have completed the tasks above.

You do realize that the main fiat currency btc is exchanged for is usd? By your logic China can just print 20b usd equivalent in yuan and just buy every bitcoin. Not gonna bother explaining why that wouldn't work.

Ok, this is getting offtopic ... whether some people want to fork before an attack can be discussed later as the first step must be deciding upon the algo , finishing the code, peer review, creating a testnet , testing , compiling the binaries...

So we should probably compensate some devs to incentivize quick execution on some of the above. We need a mutisig address with three known non anonymous trusted member of the community to accept donations like with UASF and a list of tasks to get started ... I'll be more than happy to donate.

I beg of you to put off this debate until after we have completed the tasks above.

I'm game but if the devs need extra money to motivate them, then I'm not sure we'll get the code we want. Better to have devs that feel just as threatened as us. The motivation is already there.

whether some people want to fork before an attack can be discussed later as the first step must be deciding upon the algo , finishing the code, peer review, creating a testnet , testing , compiling the binaries...

So we should probably compensate some devs to incentivize quick execution on some of the above. We need a mutisig address with three known non anonymous trusted member of the community to accept donations like with UASF and a list of tasks to get started ... I'll be more than happy to donate.

I beg of you to put off this debate until after we have completed the tasks above.

I agree.

But we must keep in mind the serious nature of who our opponent/s really are. All we know about the opponent/s is that it's unlikely to be Bitmain operating on it's own, and that they're very determined (considering the overall confluence of pressures being exerted against Bitcoin over the past 2.5 years, if they're not all working together, they may as well be), and so therefore must have some incredibly strong incentive to achieve their goals.

That taken together makes the unknown opponent dangerously adept and unpredictable IMO. Planning for the full range of "IRL side-channel attacks" is potentially vital, and I'm very concerned that an opponent sufficiently formidable may throw everything they have at their problem if their efforts are continually frustrated (and it looks to be emerging that way, I can't see the Bitcoin economy getting behind BU as things stand, our opponent/s are likely more pissed than the last time it failed)

I think a hardfork change is too drastic, and will certainly end in a contentious hard fork. A POW change light can be implemented as a soft fork by a requirement for an extra proof of work of a different type in the coinbase transaction or in another special transaction. This will encourage cooperation between miners having lots of specialized SHA256 hardware and users mining the extra proof of work on their CPUs. If miners behave badly, users will turn their backs to them, and it will become more difficult/expensive for the miners to create new blocks. Another important advantage is that old nodes and wallets will still work, as long as the majority of the hashrate is behind the soft fork. Still safeguards must be put in place to stop someone with a very large SHA256 hashrate to overtake the main chain at a later time when the extra POW difficulty is high, since a SHA256 only chain will still be valid for old nodes and SPV nodes.

Good thoughts but miners will never approve this proposal with BIP 9 and I doubt even 51% so would need to be a UASF , whicj will likely end up as a HF only . This proposal is more of a HF in reaction to a 51% attack from miners which would not be as controversial.

Judging from this latest tweet, we may need to prepare for the worst...

Couldn't this be implemented as a UASF instead? The SHA256 side can be rendered insignificant from the get-go and blocks would still be backwards compatible.

That would be pretty risky on a flag day without knowing which side every service and exchange would take. The argument for a HF is politically harder. This is silly, but it's the current status of the Bitcoin culture.

Couldn't this be implemented as a UASF instead? The SHA256 side can be rendered insignificant from the get-go and blocks would still be backwards compatible.

That would be pretty risky on a flag day without knowing which side every service and exchange would take. The argument for a HF is politically harder. This is silly, but it's the current status of the Bitcoin culture.

This may be the best way to get a POW change started as it gets everyone used to the idea. If things go south quickly, I'm sure the transition could be accelerated through another SF (more palatable at that point) or even an emergency HF.

Bram Cohen makes the (possibly true) claim that [BrCoh1] cuckoo cycle is one of the most ASIC-resistant algorithms usable as a Proof-of-Work function. It would be interesting if anyone had the tools/ability to test (or at least heuristically justify) this claim.

Couldn't this be implemented as a UASF instead? The SHA256 side can be rendered insignificant from the get-go and blocks would still be backwards compatible.

That would be pretty risky on a flag day without knowing which side every service and exchange would take. The argument for a HF is politically harder. This is silly, but it's the current status of the Bitcoin culture.

This may be the best way to get a POW change started as it gets everyone used to the idea. If things go south quickly, I'm sure the transition could be accelerated through another SF (more palatable at that point) or even an emergency HF.

Actually I had not thought of going about it in this order and it makes an awful lot of sense.

I was thinking in having the contingency ready for the sudden one and the longer term progressive one to be applied in a more "relaxed" period. But actually the "I'm altering the deal, pray I don't alter it any further" approach makes even more sense from the incentives point of view.

-----

As for intricate, not proven combinations of multiple algorithms: I'd stay away. More risk that some attack vector is discovered in the future.

If someone has relative cheap electricity, he can be sure to get comparative advantage as long as bitcoin use PoW.

Unlike mining ASICs, the hardware required by memory-hard PoWs (DRAM) is available everywhere. This alone will lead to decentralization. Cheap electricity is available in other countries, so mining will no longer be monopolized by China.

If someone has relative cheap electricity, he can be sure to get comparative advantage as long as bitcoin use PoW.

Unlike mining ASICs, the hardware required by memory-hard PoWs (DRAM) is available everywhere. This alone will lead to decentralization. Cheap electricity is available in other countries, so mining will no longer be monopolized by China.

Even without cheap electricity: Hardware, that has been democratized (CPU, GPU) - we can speak of general purpose computational devices - is warranty enough for decentralization. Special purpose hardware, expensive AND available only from a few vendors (moreover concentrated in one region) is the exact opposite.

I for one would be happy to throw my Bitmain Devices out of the window (and I do run them on free electricity), for a CPU-only PoW.Ok - I would bring them to a civic amenity site instead throwing them out of the window, but still...

I'd like to see a change to PoW as well, but I highly doubt it will ever happen. Way too much mining happens in China and off of Bitmain asics, but this has been going on for years. That doesn't happen easily without the right kind of partnerships and influence in place. The war in mining is fueled by network difficulty, cost of power, and, coin price; it's a science to balance those to be able to mine at a profit, which is what these miners are doing.

If you change PoW to only remove asic mining capability, that won't stop someone throwing up racks and racks of computers in a datacenter in China again. To address some the blockchain control concerns, I think the way that difficulty is leveraged would need to be modified as well. If you can just throw hardware at the difficulty, you'll just repeat the same path again in months/years. If asics are removed from the equation and replaced with cpu/memory, that will disrupt the mining swarm in the short term, but the mining collective would just regroup and retarget again where cpu/memory commodities can be leveraged in low cost environments where power and cooling are inexpensive. If you can keep adding n+1 nodes, you can just game the ability to solve a block with more hardware you control. However, I do think it's a better approach though to bring mining back to the node because it at least lowers the bar on power requirements on mining back to lower-cost equipment that gives entry nodes a better chance to solve a block.

Thanks to the universal availability of DRAM, those racks can now go up all over the world. That's the key difference.

Exactly

Maybe we can't level the whole playing field definitively, but that's no argument for not taking the steps that can be made towards a free-er market in mining

(and that's true of all markets for all goods, there will always be cat and mouse protectionist games being played, the current cartel based world trade paradigm being the most salient example, for instance)

Yes, we must switch to PoW as soon as possible, to prevent Core from running Bitcoin.Coz BU will win then, and will become mainstream Bitcoin.Introducing new PoW will make BTC an altcoin.Good luck with it.

Whom do you try to scare ?Weak hands already sold all their BTC.

"...Enemies are everywhere ! Angka is all rage ! Be a good soldiers, blow everything... " <-- Pol Pot (C)

Guys isn't one of the main reasons that Bitcoin is so valuable because of the crazy high mining difficulty and capital investment that is required for ASICs, electricity...etc.

To me it sounds like if you go back to GPU mining, you cut off one leg to the market, making the price of bitcoin plumet and stabilize much lower than it is now.

Wont the 16nm development wall that was reached recently, decentralize mining organically as time passes?

I think this "mining centralization" problem is only a temporary issue. And making the shift from ASIC to GPU just gives power to another entity (in most cases probably the same people since most ASIC farms also include a GPU farm).

I am not so naive to believe that going to GPU will magically put home hobby miners in control or decentralize the hashing in any significant way (maybe for a month, but then we are back to pools and farms being in control)

Nicee...BTC is mindlocked in what we have now.We can't change PoW, we can't switch to PoS.Any fork maintaining current mining related features will outperform mutated BTC on all exchanges.

Core already lost battle to BU.Coz when blocks will get full 110%, BTC network will get jammed and then HF will happen for sure,with support of majority of miners.Not just by 40% of them like now.

Yes you can invent the best and coolest PoW or PoS or any combination of them.But there is no difference between such "saving plan" for Bitcoin and creation of new altcoin.Value of BTC after such change will plummet.

"...Enemies are everywhere ! Angka is all rage ! Be a good soldiers, blow everything... " <-- Pol Pot (C)

Thanks to the universal availability of DRAM, those racks can now go up all over the world. That's the key difference.

Exactly

Maybe we can't level the whole playing field definitively, but that's no argument for not taking the steps that can be made towards a free-er market in mining

(and that's true of all markets for all goods, there will always be cat and mouse protectionist games being played, the current cartel based world trade paradigm being the most salient example, for instance)

It may not be definitive and it may not be perfect, but it sure would be an improvement.

Bonus 1: being able to introduce script versioning and L2.

Bonus 2: the very threat of a future PoW change will make sure the miners will at least think twice about building up too much in-house and much less brazenly collude like they have already done.

Since most of you obviously haven't read it, let me direct your attention to Section 6 of the Bitcoin white paper:

Quote from: Bitcoin: A Peer-to-Peer Electronic Cash System, Section 6

The incentive may help encourage nodes to stay honest.If a greedy attacker is able to assemble more CPU power than all the honest nodes,he would have to choose between using it to defraud people by stealing back his payments,or using it to generate new coins.

He ought to find it more profitable to play by the rules,such rules that favour him with more new coins than everyone else combined,than to undermine the system and the validity of his own wealth.

What if the mining pools are controlled by government (china) hell-bent of killing Bitcoin? The rules are then thrown out of the window.

If you change PoW to only remove asic mining capability, that won't stop someone throwing up racks and racks of computers in a datacenter in China again.

Racks of computers in datacenters is a given, but why only in China? Thanks to the universal availability of DRAM, those racks can now go up all over the world. That's the key difference.

China has very inexpensive power, so they can run more systems less expensively than elsewhere. However, I get your point, while it's not the silver bullet it would certainly help level the playing field again, at least for a little while.

Couldn't this be implemented as a UASF instead? The SHA256 side can be rendered insignificant from the get-go and blocks would still be backwards compatible.

That would be pretty risky on a flag day without knowing which side every service and exchange would take. The argument for a HF is politically harder. This is silly, but it's the current status of the Bitcoin culture.

This may be the best way to get a POW change started as it gets everyone used to the idea. If things go south quickly, I'm sure the transition could be accelerated through another SF (more palatable at that point) or even an emergency HF.

Actually I had not thought of going about it in this order and it makes an awful lot of sense.

I was thinking in having the contingency ready for the sudden one and the longer term progressive one to be applied in a more "relaxed" period. But actually the "I'm altering the deal, pray I don't alter it any further" approach makes even more sense from the incentives point of view.

-----

As for intricate, not proven combinations of multiple algorithms: I'd stay away. More risk that some attack vector is discovered in the future.

The more I think about it the more I believe a SF PoW change is the best option -- even in an emergency. It's the least disruptive to users and businesses with alternate clients. Exchanges, wallet providers, etc should only need to set up a border node and they'll have all the time they need to upgrade their legacy systems. AFAIK, this can't be done with a HF and would cause a lot more economic disruption.

Couldn't this be implemented as a UASF instead? The SHA256 side can be rendered insignificant from the get-go and blocks would still be backwards compatible.

That would be pretty risky on a flag day without knowing which side every service and exchange would take. The argument for a HF is politically harder. This is silly, but it's the current status of the Bitcoin culture.

This may be the best way to get a POW change started as it gets everyone used to the idea. If things go south quickly, I'm sure the transition could be accelerated through another SF (more palatable at that point) or even an emergency HF.

Actually I had not thought of going about it in this order and it makes an awful lot of sense.

I was thinking in having the contingency ready for the sudden one and the longer term progressive one to be applied in a more "relaxed" period. But actually the "I'm altering the deal, pray I don't alter it any further" approach makes even more sense from the incentives point of view.

-----

As for intricate, not proven combinations of multiple algorithms: I'd stay away. More risk that some attack vector is discovered in the future.

The more I think about it the more I believe a SF PoW change is the best option -- even in an emergency. It's the least disruptive to users and businesses with alternate clients. Exchanges, wallet providers, etc should only need to set up a border node and they'll have all the time they need to upgrade their legacy systems. AFAIK, this can't be done with a HF and would cause a lot more economic disruption.

I'm pretty much there also. Block needs to be SHA2'd just like before... as well as "something else'd" to be valid. If we roll out SW and ideally LN strikes at the exact same time... the affect would be pretty effective. In my understanding-- there would still be the difficulty lag, which would be overcome with SW/LN ... no hardfork. What's not to like?

How about (just another fun log to throw on the fire... feel free to pick it apart... not too thoroughly though out...) miners need to hash THE ENTIRE BLOCKCHAIN + the new block?

come to think of it... there really is no need for difficulty2... difficulty1 (the normal difficulty) will have to come way down after the block interval goes way up due to 1) asic deprecation and 2) more complex hash function...

effectively putting the big hash in the inner loop of the little hash.

This would be very difficult to build an asic for... specialized hardware is fast ram. a commodity.

incentives to keep blockchain size down. way easier to verify than to hash... but it breaks node pruning.

Could be very simple to include the hash2(hash2()) value... just encode it in a transaction in the block. Nodes check to see if the transaction exists by calculating the hash per the reported nonce and looking at OP_RETURN or something... if not... the block is invalid.

...another idea to prevent an initial shock to the block creation time is to initialize n as a function of the regular difficulty such that n = 1 at the current difficulty (on flag day).

It's profoundly unreasonable to pass off unbacked assertions as any form of reason

I've provided sound reasoning already, refute it.

I would if I could find it, but from what I see you've taken some facts, made up a story around them, and then because your story fits the facts you say it must be true. But of course your story fits the fact, you used them to make it up.

Why would it be too late after an attack to HF? A few txs get stolen or blocked?

For a similar reason you're giving not to pre-empt it: building support for the new idea. It's possible that too many people will be psychologically impacted by the success of the attack, and consequently do what you're suggesting is wrong with my approach (despite the fact I've made no emotional arguements at all): allow emotions to dictate their decision instead of reason.

If we engage people to support pre-emptive action, a determined mindset would replace a fatalistic reaction. It's about harnessing a positive psychological feedback loop instead of a negative psychological feedback loop.

By my estimates 95% won't preemptively fork the PoW algo ... do you really think you can convince them all to preemptively HF?

Including Bitmain's current hashrate %? Clearly not. A PoW fork only needs to get the support of the miners who don't want to be ruled by a malign majority, although I'm seeing an obvious problem; how to measure that. Setting a block height activation would invite counter measures. Not sure how it could be achieved.

Sounds like the "Coalition of the Willing" and "Weapons of Mass Destruction" argument which lead to the disaster that was the Iraq pre-emptive strike/invasion and war.

If you're serious about a Proof-of-Work switch I would humbly point you to what Nexus (http://nexusearth.com/features.html) is doing with ASIC and quantum computer resistant Pure SHA-3 (Using Skein-1024 and Keccak-1600) CPU pool/GPU solo mining.

If you change PoW to only remove asic mining capability, that won't stop someone throwing up racks and racks of computers in a datacenter in China again.

Racks of computers in datacenters is a given, but why only in China? Thanks to the universal availability of DRAM, those racks can now go up all over the world. That's the key difference.

China has very inexpensive power, so they can run more systems less expensively than elsewhere. However, I get your point, while it's not the silver bullet it would certainly help level the playing field again, at least for a little while.

FYI: Electricity in parts of Washington State, USA is as cheap or even cheaper than China due to the hydroelectic PUDs. That's why McAffee/Bitmain are building their facility there.

changing pow would be a temporary method of opposing the chinese miners. it should be a tool used alongside a UASF if there is going to be one.

Introducing a very moderate (say 5% of the block reward) PoWA as a soft fork would allow the miners to stay in business while putting them on notice that if they misbehave in the future we can up that percentage with a new soft fork. This would be a permanent rather than temporary measure that would create a new class of DRAM miners.

If you're serious about a Proof-of-Work switch I would humbly point you to what Nexus (http://nexusearth.com/features.html) is doing with ASIC and quantum computer resistant Pure SHA-3 (Using Skein-1024 and Keccak-1600) CPU pool/GPU solo mining.

If you're serious about a Proof-of-Work switch I would humbly point you to what Nexus (http://nexusearth.com/features.html) is doing with ASIC and quantum computer resistant Pure SHA-3 (Using Skein-1024 and Keccak-1600) CPU pool/GPU solo mining.

I referenced Nexus as a real-world example because of their use of a combination of Skein-1024 and Keccak-1600 algorithms which leads to an ASIC and quantum computer Proof-Of-Work which is what this thread was about.

I propose if you're going to change Bitcoin's proof-of-work to something other than the current SHA-2(56) to something else then you might as well go all in on SHA-3 to make it even more secure against near-future quantum computing technology (which governments may already have).

I propose if you're going to change Bitcoin's proof-of-work to something other than the current SHA-2(56) to something else then you might as well go all in on SHA-3 to make it even more secure against near-future quantum computing technology (which governments may already have).

SHA-3 does that.

All SHA-3 candidates are rather ASIC-friendly, and Hashcash with such a hash function is highlyvulnerable to quantum speedup with Grover's algorithm.

If you're serious about a Proof-of-Work switch I would humbly point you to what Nexus (http://nexusearth.com/features.html) is doing with ASIC and quantum computer resistant Pure SHA-3 (Using Skein-1024 and Keccak-1600) CPU pool/GPU solo mining.

I referenced Nexus as a real-world example because of their use of a combination of Skein-1024 and Keccak-1600 algorithms which leads to an ASIC and quantum computer Proof-Of-Work which is what this thread was about.

I propose if you're going to change Bitcoin's proof-of-work to something other than the current SHA-2(56) to something else then you might as well go all in on SHA-3 to make it even more secure against near-future quantum computing technology (which governments may already have).

We're looking mostly at GPU friendly (possibly memory-hard, depending on the algo) PoW that will provide a good compromise against generic botnets and ASICs to gain time.

Here's my proposal: Implement the new PoW as a PoWA (proof-of-work additions) soft fork. New PoW is memory-hard Cuckoo Cycle (whose creator has joined the discussion here), or possibly Equihash.

Give 5% of the block reward to the new PoW. This is enough to create a new DRAM-based mining community + hardware/software infrastructure without alienating/bankrupting existing SHA2 miners.

If SHA2 miners continue misbehaving (blocking Segwit, threatening to use other implementations), we increase the new PoW's reward with another soft fork. Hopefully this option won't have to be used: the threat will be enough to keep them compliant.

Conservative approach allows us to use relatively untested PoW algorithm safely, as blockchain continues to be 95% secured by old SHA2 hashing power. Getting the larger community behind a conservative solution will also be easier. Pro-Core miners will support it, since it's a far better option for them than the current standoff and possible network fork.

Give 5% of the block reward to the new PoW. This is enough to create a new DRAM-based mining community + hardware/software infrastructure without alienating/bankrupting existing SHA2 miners.

If SHA2 miners continue misbehaving (blocking Segwit, threatening to use other implementations), we increase the new PoW's reward with another soft fork. Hopefully this option won't have to be used: the threat will be enough to keep them compliant.

I like the sound of that implementation. It squashes a significant argument against a PoW change, avoids a hard fork, and would keep the markets far calmer.

We're looking mostly at GPU friendly (possibly memory-hard, depending on the algo) PoW that will provide a good compromise against generic botnets and ASICs to gain time.

Here's my proposal: Implement the new PoW as a PoWA (proof-of-work additions) soft fork. New PoW is memory-hard Cuckoo Cycle (whose creator has joined the discussion here), or possibly Equihash.

Give 5% of the block reward to the new PoW. This is enough to create a new DRAM-based mining community + hardware/software infrastructure without alienating/bankrupting existing SHA2 miners.

If SHA2 miners continue misbehaving (blocking Segwit, threatening to use other implementations), we increase the new PoW's reward with another soft fork. Hopefully this option won't have to be used: the threat will be enough to keep them compliant.

Conservative approach allows us to use relatively untested PoW algorithm safely, as blockchain continues to be 95% secured by old SHA2 hashing power. Getting the larger community behind a conservative solution will also be easier. Pro-Core miners will support it, since it's a far better option for them than the current standoff and possible network fork.

I think it's worth considering but I believe this would take a long time to review and test. The possible dynamics are extremely complex and we have to make sure we done introduce new attacks or vulnerabilities.

I believe we virtually have one already (Keccak) in case we needed a very quick and sudden change, and we can try to improve upon as time allows. We don't know how much time do we have but mixed systems will have to be simplified as much as possible or it will take months or years to have reasonable confidence in them.

We're looking mostly at GPU friendly (possibly memory-hard, depending on the algo) PoW that will provide a good compromise against generic botnets and ASICs to gain time.

Here's my proposal: Implement the new PoW as a PoWA (proof-of-work additions) soft fork. New PoW is memory-hard Cuckoo Cycle (whose creator has joined the discussion here), or possibly Equihash.

Give 5% of the block reward to the new PoW. This is enough to create a new DRAM-based mining community + hardware/software infrastructure without alienating/bankrupting existing SHA2 miners.

If SHA2 miners continue misbehaving (blocking Segwit, threatening to use other implementations), we increase the new PoW's reward with another soft fork. Hopefully this option won't have to be used: the threat will be enough to keep them compliant.

Conservative approach allows us to use relatively untested PoW algorithm safely, as blockchain continues to be 95% secured by old SHA2 hashing power. Getting the larger community behind a conservative solution will also be easier. Pro-Core miners will support it, since it's a far better option for them than the current standoff and possible network fork.

I think it's worth considering but I believe this would take a long time to review and test. The possible dynamics are extremely complex and we have to make sure we done introduce new attacks or vulnerabilities.

I believe we virtually have one already (Keccak) in case we needed a very quick and sudden change, and we can try to improve upon as time allows. We don't know how much time do we have but mixed systems will have to be simplified as much as possible or it will take months or years to have reasonable confidence in them.

It's worth exploring since it is a more palatable "non-emergency" solution. As for the current fork, be it HF or SF, I like the idea of a memory intensive POW. It would indeed remove China's hardware monopoly -- and subsidized electricity can be found in many countries.

It's worth exploring since it is a more palatable "non-emergency" solution. As for the current fork, be it HF or SF, I like the idea of a memory intensive POW. It would indeed remove China's hardware monopoly -- and subsidized electricity can be found in many countries.

One that simply transitions progressively from SHA256 to a single cryptohash, I don't think it would be very complicated. I guess it depends on how the transition is coded concretely.

One that simply transitions progressively from SHA256 to a single cryptohash, I don't think it would be very complicated. I guess it depends on how the transition is coded concretely.

To keep things simple, there doesn't have to be any transition at all, just a flat 5% payout to the new miners. That percentage would be increased in a new SF only in the event of miner misbehavior. On the other hand, if we do decide to go with a gradual transition, I don't see any great technical complexity with that either. Only it would have to be very gradual, otherwise we can't expect any support from the existing mining community.

This is how the system might work:

DRAM miner solves the block with no Coinbase TX but with his payout address appended. DRAM miner broadcasts block, solution and payout address to SHA2 miners. SHA2 miner adds DRAM miner's proof to the Coinbase and a 0.625 BTC output to DRAM miner's payout address in the Coinbase TX. SHA2 miner then solves block as usual. Block is now secured by two PoWs.

Some additional protocol (or messages to existing P2P protocol) will be required for DRAM miners to relay their data to the SHA2 miners, but other than this they don't need to coordinate in any way.

The only additional work required for verifying nodes is to check that payout address and amount are correct and verify DRAM miner's proof.

Not quite sure how we'd handle the matter of difficulty retargeting for the new PoW. This seems to be the trickiest problem.

What will prevent the SHA256 miners orphaning the new hashing algo blocks? Would it not be better to start at 51% share to the new hash algo to prevent that, or would an exponential rise in blocks built on using the the new hash algo as it approaches 51% of the hashrate be acceptable?

What will prevent the SHA256 miners orphaning the new hashing algo blocks? Would it not be better to start at 51% share to the new hash algo to prevent that, or would an exponential rise in blocks built on using the the new hash algo as it approaches 51% of the hashrate be acceptable?

I doubt that any of the existing miners would agree to a proposal that immediately slashes their block reward in half, while many might agree to a 5% haircut. Especially since the miners that choose to join us will get a nice windfall at first as the difficulty adjusts downwards.

Uncooperative miners will end up on a different chain in any case—there's nothing we can do about that. We just count on the economic majority being upgraded and ignoring their chain. They can continue mining their chain at a loss or rejoin Bitcoin—the choice is theirs.

What will prevent the SHA256 miners orphaning the new hashing algo blocks? Would it not be better to start at 51% share to the new hash algo to prevent that, or would an exponential rise in blocks built on using the the new hash algo as it approaches 51% of the hashrate be acceptable?

I doubt that any of the existing miners would agree to a proposal that immediately slashes their block reward in half, while many might agree to a 5% haircut. Especially since the miners that choose to join us will get a nice windfall at first as the difficulty adjusts downwards.

Uncooperative miners will end up on a different chain in any case—there's nothing we can do about that. We just count on the economic majority being upgraded and ignoring their chain. They can continue mining their chain at a loss or rejoin Bitcoin—the choice is theirs.

Right, well I hate to resurrect previous sore points, but.....

We should begin to build support for this. If every iteration requires a soft fork, then either an additional soft fork can let us wind back to 100% SHA-2 (in the perhaps unlikely event of the uncooperative ASIC miners changing their minds), or we just carry on until 100% CPU mining is back in charge.

If we do not build support before the threat of external hard fork attacks (note the plural "attacks"), I fear we may get outplayed with lateral attacks via the internet infrastructure, the legal system, the dev team, all 3, or something I'm not even considering. It should be an obvious fact that international collaboration between those perpetrating this BU attack (at a minimum between some English speaking + Chinese interests) should indicate quite how seriously the unknown opponent is taking Bitcoin.

If the most balanced way to do this is by gradation, and I believe a good case has been made for that, then waiting for an emergency to occur could well cause the strategy to invite the opponent to produce their most potent attacks to stop it. Switching to 100% CPU mining in an emergency makes sense, switching to 5% over weeks or months does not.

Switching to 100% CPU mining in an emergency makes sense, switching to 5% over weeks or months does not.

Of course. We need both an emergency plan and a non-emergency plan. The emergency plan would be a 100% HF switch to the new algorithm. The non-emergency plan is the gradual one I'm proposing. And for it we of course need to work with the community and build support. If it activates, I don't envision ever going back to all-ASIC mining. On the contrary, the whole point is to build a new, more decentralized mining community around readily-available DRAM.

I proceed from the assumption that we might not get the emergency we're expecting, at least not anytime soon. It's too risky for our opponents. Instead, they'll just keep waging a war of attrition against us in the ways you've mentioned. This is why we need to be proactive in advancing the non-emergency plan while our position is still strong.

I proceed from the assumption that we might not get the emergency we're expecting, at least not anytime soon. It's too risky for our opponents. Instead, they'll just keep waging a war of attrition against us in the ways you've mentioned. This is why we need to be proactive in advancing the non-emergency plan while our position is still strong.

I more or less agree, but the assumption I've bolded is dangerous. There is a significant risk that a "short sharp shock" act of caprice could happen very suddenly, especially now that BU is looking increasingly unlikely to gain any foothold with users. As I mentioned in another thread, the opposition have exceeded their "crying wolf" quota. What makes anyone believe the attackers will not choose a different MO altogether?

Frankly, I would be most surprised if another hard fork campaign would ever be a genuine attempt, I would expect a sudden political act against Bitcoin (via the potential vectors I described before) to happen during the next hard fork campaign, "when it is least expected" lol. We should expect it, and prepare the user community accordingly.

Rather than change the core client, I have an extension of the method detailed above. What about having a PKI (public key infrastructure) transaction pool? PKI TxnPool.

The goal is to ensure that only miners that meet your user requirements can include your txns in a block. The desire is to de-incentivize miners that are attacking the network, and that there is a clear path between nodes and miners for transactions that are validated. This might not be able to stop a 51% attack, but it might be able to stop miner centralization occurring in the first place.

We now have a txn that has been validated, with a node identifier, and a white-list of miners that can include their txn on the block-chain.

PKI txnpool relay.

Node peers with other node. Nodes exchange pubkeys. Nodes exchange miner black-lists with version numbers greater than on node. Miner validates signature of miner black-list. Node black-lists Node that has incorrectly signed miner black-list. If valid continue, if not, cancel peer connection. Nodes remove txns from PKI txnpool that are signed by black-listed nodes. Nodes create exchange white-list, removing a miner from the white-list if it is in the miner black-list. Nodes exchange curated miner white-lists. Nodes exchange txns that meet node white-list requirements.

PKI txnpool removing txns that have been included in blocks or are too old.

Node gets new block. Node creates hash of each txn in block. Node removes from PKI txnpool that have duplicate hash. Node removes from PKI txnpool txns that are >cfg time from adding to local pool.

Miners use PKI txnpool to get txns.

Miner queries PKI txnpool. Miner node sets white-list to only that miner. It doesn't matter if they have more, they just won't be able to decrypt txns that they don't have the privkey for. Miner uses privkey to decrypt txn. Miner node validates txn. If txn is invalid, add node that created txn to miner black-list. Miner updates and signs black-list. Miner replicates new miner-black-list to peer nodes.

Through this, PKI txnpool nodes work in an independent pool from bitcoin. Nodes must ensure they create valid transactions, or they will be black-listed by any miner that opens a txn they created, and determine it is invalid, and the txns they create won't replicated. Miners can only decrypt transactions that have been encrypted using their pubkey. This solution should allow users to select from a group of miners, and by extension, de-select miners that don't meet their requirements. This provides a user and miner controlled tool to route-around malicious miners and nodes.

For my part, I will ramp up the marketing once we have 2 or 3 working branched clients (or implementations that don't require client changes) that have been subjected to extensive peer review, and hopefully some libraries+documentation to ease the transition for 3rd party service providers like light wallets and exchanges. Until then, it might not be necessary (or wise).

Actually, the work being done by the devs in this thread has already been covered by a good number of major outlets ([1], [2], [3], [4]).

FWIW we evaluated Cuckoo as well for Zcash, and it was a strong second-place contender. There wasn't really anything wrong with it — it just didn't seem to have quite as much of a rigorous scientific analysis as Equihash. However, that is a very subjective thing for me to say. You could argue (and Cuckoo's author, John Tromp, does argue persuasively) that Cuckoo's history of analysis and refinement is better than Equihash's.

What about cycling through 10 unique PoWs every 10 blocks?

I'm not the best at discrete analysis and understand this multiplies attack surface 10-fold, but could we splinter miners into small, specialized, and de-fanged factions using 10 different well-chosen hash algorithms, then scatter them among CPUs/GPUs/FPGAs/ASICs?

Bitcoin is intentionally designed to be ungovernable and governance-free. luke-jr 2016Blocks must necessarily be full for the Bitcoin network to be able to pay for its own security. davout 2015Blocksize is an intentionally limited resource, like the 21e6 BTC limit. Changing it degrades the surrounding economics, creating negative incentives. Jeff Garzik 2013

The raison d'être of bitcoin is trustlessness. - Eric Lombrozo 2015It is an Engineering Requirement that Bitcoin be “Above the Law” Paul Sztorc 2015Resiliency, not efficiency, is the paramount goal of decentralized, non-state sanctioned currency -Jon Matonis 2015

Bitcoin is intentionally designed to be ungovernable and governance-free. luke-jr 2016

Technology tends to move in the direction of making surveillance easier, and the ability of computers to track us doubles every eighteen months. - Phil Zimmerman 2013

The only way to make software secure, reliable, and fast is to make it small. Fight Features. - Andy Tanenbaum 2004

Bitcoin is intentionally designed to be ungovernable and governance-free. luke-jr 2016Blocks must necessarily be full for the Bitcoin network to be able to pay for its own security. davout 2015Blocksize is an intentionally limited resource, like the 21e6 BTC limit. Changing it degrades the surrounding economics, creating negative incentives. Jeff Garzik 2013

The raison d'être of bitcoin is trustlessness. - Eric Lombrozo 2015It is an Engineering Requirement that Bitcoin be “Above the Law” Paul Sztorc 2015Resiliency, not efficiency, is the paramount goal of decentralized, non-state sanctioned currency -Jon Matonis 2015

Bitcoin is intentionally designed to be ungovernable and governance-free. luke-jr 2016

Technology tends to move in the direction of making surveillance easier, and the ability of computers to track us doubles every eighteen months. - Phil Zimmerman 2013

The only way to make software secure, reliable, and fast is to make it small. Fight Features. - Andy Tanenbaum 2004

FWIW we evaluated Cuckoo as well for Zcash, and it was a strong second-place contender. There wasn't really anything wrong with it — it just didn't seem to have quite as much of a rigorous scientific analysis as Equihash. However, that is a very subjective thing for me to say. You could argue (and Cuckoo's author, John Tromp, does argue persuasively) that Cuckoo's history of analysis and refinement is better than Equihash's.

What about cycling through 10 unique PoWs every 10 blocks?

I'm not the best at discrete analysis and understand this multiplies attack surface 10-fold, but could we splinter miners into small, specialized, and de-fanged factions using 10 different well-chosen hash algorithms, then scatter them among CPUs/GPUs/FPGAs/ASICs?

Wont this make difficulty rise and fall like a wave? If the answer is yes, then wont this open the network to attacks if there is a fall in difficulty. Maybe it wont be the case after a year but in the beginning it could be.

If youre going that road, why not have 2 POW algorithm at first with the option of expanding it instead of starting with 10 outright.

There are several developers working on PoW changes already , but what we need is proper peer review testing and a big bounty for this work. I am willing to donate btc and help fund raise for this , but we need 3 trustworthy an public people to handle the funds. Who is interested or who should we ask to get this started?

There are several developers working on PoW changes already , but what we need is proper peer review testing and a big bounty for this work. I am willing to donate btc and help fund raise for this , but we need 3 trustworthy an public people to handle the funds. Who is interested or who should we ask to get this started?

The "public" stipulation may be difficult to satisfy. Irrespective of how much support we can build, whoever accepts an escrow role is sticking their head above the parapets rather significantly (Bitfury have already threatened legal action against PoW changes, although against who is undetermined I believe)

Can the several developers not present their designs, rates and also addresses to donate to?

Here's how I propose to decentralize mining with a PoWA (proof-of-work additions) soft fork:

New PoW chain is shown in pink, legacy blockchain in blue.

Brief description:

New PoW miners mine continuously, legacy miners almost continuously. Proofs for the new PoW blockchain's mini-blocks are embedded into legacy chain in a special output of the coinbase transaction.

All assembling of TXs into blocks and reorgs happen on the new PoW chain. Legacy miners' participation is restricted to solving the SHA256 proof-of-work, adding their payout address to the coinbase TX and broadcasting the block.

Mini-block headers are like ordinary block headers but with an added payout address.

Legacy miners experience an avg. of 10% downtime while waiting for new PoW miners to mine the next proto-block.

Initially, 90% of block reward will go to legacy miners and 10% to new PoW miners. Legacy miners' share could be gradually reduced (over a period of years?) until it reaches zero.

After legacy miner broadcasts a valid block, new PoW miner assembles a "proto-block" (a nearly complete Bitcoin block) out of TXs from all mini-blocks mined since last proto-block. Extra TXs are added from mempool to make the block full. Payout outputs for mini-blocks and proto-block are added to the coinbase TX (with 10% of block reward divided equally among them). Mini-block headers and legacy block header hash are embedded in the special output of the coinbase TX. Miner solves the proto-block and broadcasts it to legacy miners.

Legacy miner adds his payout output and proto-block header to the coinbase TX and Merkle root to the header, making the block complete. He then solves and broadcasts the block as usual. Legacy miner is allowed to alter only four pieces of data: timestamp, nonce, coinbase nonce and his payout output.

If new PoW miners solve nine mini-blocks faster than legacy miners solve one block, then they continue mining empty mini-blocks until legacy miners finally solve the block. Thus a proto-block may contain more than nine mini-blocks.

In the reverse case, proto-block will contain fewer than nine mini-blocks.

"Longest chain" according to new consensus rules is chain with the most embedded mini-block/proto-block proofs. This prevents legacy miners from initiating reorgs.

System is PoW agnostic, but a memory-hard algorithm such as Cuckoo Cycle or Equihash would be preferred, as this would lead to the creation of a new decentralized mining industry based on universally available DRAM.

This description is preliminary; certain details may be subject to change.

Benefits:

New decentralized mining industry is created.

Legacy miners are deprived of all decision-making power and possibility of attacking the chain.

Gradual or partial phase-in of new PoW reduces security risk.

Bitcoin's effective confirmation time is reduced to one minute.

Despite the 10% "haircut" they receive, legacy miners can profit from the SF if economic majority upgrades and most value remains on upgraded chain. Thus the proposal could expect to gain broad community consensus, even among miners.

Variations:

Legacy miners' share of block reward could be left at 90%, with no phase-out, making proposal more attractive to them.

New PoW miners and legacy miners mine in parallel. Proofs for the new PoW blockchain's mini-blocks are embedded into legacy chain in a special transaction.

All assembling of TXs into blocks and reorgs happen on the new PoW chain. Legacy miners' role is restricted to finding SHA256 hashes, final block assembly (calculating payouts, creating the coinbase TX) and broadcasting the block.

Mini-block headers are like ordinary block headers but with an added payout address.

New PoW miners mine with no downtime. Legacy miners experience an avg. of 10% downtime while waiting for new PoW miners to mine one block. (It may be possible to eliminate this downtime by having new PoW miners solve only mini-blocks and not entire block.)

Initially, 95% of block reward will go to legacy miners and 5% to new PoW miners. Legacy miners' share will be gradually reduced (over a period of years?) until it reaches zero.

After legacy miner broadcasts a valid block, new PoW miners assemble all TXs from mini-blocks mined so far into a single Bitcoin block with no Coinbase TX, solve the block and broadcast it along with mini-block headers to legacy miners.

Legacy miner adds mini-block proofs, TX counts and payout addresses to the special transaction, calculates payouts (initially distributing 95% of reward to himself and 5% equally among new PoW miners), adds payout outputs to Coinbase TX and then solves and broadcasts the block as usual.

If new PoW miners solve nine mini-blocks faster than legacy miners solve one block, then they continue mining empty mini-blocks until legacy miners finally solve the block. Thus a block may contain more than 10 mini-blocks.

In the reverse case, fewer than 10 mini-blocks will be assembled into a block, and the new PoW miner who assembles the block will add as many TXs to the final mini-block as required in order to reach the blocksize limit (currently 1MB).

All of the above is preliminary and subject to change.

What's the rationale for making the mini-blocks 10 per legacy block? I'm thinking of the orphan rate.

I'm also unconvinced about a "years" timeframe. I would propose 1 year, where the interval between the 5% steps starts at close to infinity increase for the 5-10% part, and gradually increases the interval between steps (like an exponential curve inverted about x=y, is that the cosine curve?)

Going faster to begin with should help to attract hashing power to newPoW, and in turn dissuade the BU miners from even attempting the various attacks they have no doubt developed. The "long tail" will gradually contribute to calming what would inevitably be a very febrile atmosphere surrounding the initial 5% change (the accompanying FUD would no doubt be typically disproportionate)

FWIW we evaluated Cuckoo as well for Zcash, and it was a strong second-place contender. There wasn't really anything wrong with it — it just didn't seem to have quite as much of a rigorous scientific analysis as Equihash. However, that is a very subjective thing for me to say. You could argue (and Cuckoo's author, John Tromp, does argue persuasively) that Cuckoo's history of analysis and refinement is better than Equihash's.

What about cycling through 10 unique PoWs every 10 blocks?

I'm not the best at discrete analysis and understand this multiplies attack surface 10-fold, but could we splinter miners into small, specialized, and de-fanged factions using 10 different well-chosen hash algorithms, then scatter them among CPUs/GPUs/FPGAs/ASICs?

DeSantis has started some work (he wants to do some testing before posting his source code for peer review though).He's creating a Keccak fork and a Cuckoo fork, and has created a beautiful automated testing utility that I hope he gives me permission to link to you guys.

The testing utility (I've viewed the source, it's not vaporware) allows you to spin up multiple Docker containers, each containing a different Bitcoin node; some of the nodes can be Bitcoin 0.14.0, some of them can be Bitcoin Unlimited, and some of them can be Keccak, Cuckoo, etc.

With these containerized Bitcoin nodes, you can then simulate various forking scenarios, and actually observe in real-time how it plays out. With my limited bitcoin programming knowledge, I am waiting for him to document the config file that controls the node counts & types, and to create some python installation script (which are easier to debug for me at least).

There are several developers working on PoW changes already , but what we need is proper peer review testing and a big bounty for this work. I am willing to donate btc and help fund raise for this , but we need 3 trustworthy an public people to handle the funds. Who is interested or who should we ask to get this started?

The "public" stipulation may be difficult to satisfy. Irrespective of how much support we can build, whoever accepts an escrow role is sticking their head above the parapets rather significantly (Bitfury have already threatened legal action against PoW changes, although against who is undetermined I believe)

Can the several developers not present their designs, rates and also addresses to donate to?

-----BEGIN PGP SIGNED MESSAGE-----Hash: SHA256

Hi devs, can you all send your nominations for who the most credible individuals are for managing an m-of-n account (for holding the PoW bounty's reward funds)?

2) Once all the nominations are received, I will make one big post containing all of the signed emails (unless the sender wishes to remain anonymous due to fear of BitfuryGeorge).

3) We reach out to the agreed upon individuals, inviting them to become custodians of the multisig address and requesting a public BTC address (for which they control the private key) from each of them.

4) Create the multisig address, notify the new custodians of the account.-----BEGIN PGP SIGNATURE-----Version: GnuPG v2

What's the rationale for making the mini-blocks 10 per legacy block? I'm thinking of the orphan rate.

In order to keep the two chains in sync and ensure that the new PoW hash power is always working, the new PoW miners can assemble the next proto-block from mini-blocks and mine it only after legacy miners have mined and broadcast the current block. The period while the new PoW miners are mining the proto-block is downtime for the legacy miners; their hash power is going to waste. In order to minimize this downtime, we need a fast confirmation time for the new PoW. One minute isn't too extreme, actually, if we consider Ethereum's 20-second confirmation time.

I'm also unconvinced about a "years" timeframe. I would propose 1 year, where the interval between the 5% steps starts at close to infinity increase for the 5-10% part, and gradually increases the interval between steps (like an exponential curve inverted about x=y, is that the cosine curve?)

Going faster to begin with should help to attract hashing power to newPoW, and in turn dissuade the BU miners from even attempting the various attacks they have no doubt developed. The "long tail" will gradually contribute to calming what would inevitably be a very febrile atmosphere surrounding the initial 5% change (the accompanying FUD would no doubt be typically disproportionate)

It's a tradeoff. Yes, transitioning faster would attract more new PoW miners. So would giving them a larger share of the block reward at the beginning, say 10%.

On the other hand, since this is "non-hostile" fork proposal that seeks to gain broad community consensus, we don't want to alienate legacy miners by turning their hardware into scrap metal too quickly. This is why I would prefer to err on the side of an overly long phase-out period rather than an overly short one. A linear phase-out is preferable to an exponential one for the same reason.

As for attacks, non-upgraded miners may attempt to attack the chain to fool non-upgraded nodes, but this is a risk for any SF. We just have to rely on having most economic nodes upgraded by flag day.