Bitcoin Forum

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

Key-ID: 331B6406
Fingerprint: BE9209A6C773FBF91E4ED2E425C33539331B6406
Last updated: 2017/03/25 04:48 UTC


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.

• 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.

• luke-jr's prototype of how a PoW change could be implemented in code: https://github.com/luke-jr/bitcoin/commit/8d3a84c242598ef3cdc733e99dddebfecdad84a6
• Bitcoin Hard Fork Research (https://bitcoinhardforkresearch.github.io/) - repository of quality research into general Bitcoin hard forks
• Malice Reactive Proof of Work Additions (MR POWA) (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013744.html)
• Github BIP - in the works
• 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.

• "Proof-of-Work update is not a threat to miners, it is a necessity for users (https://medium.com/@nicolasdorier/proof-of-work-update-is-not-a-threat-to-miners-it-is-a-necessity-for-users-e7450a0cc146#.r6g3uzaox)" [Nicolas Dorier]
• Reddit+Twitter+SocialMedia:
        
  • "Let's THINK about changing PoW, to ensure we can get rid of Jihan/Bitmain/MGMT/Ver if we really need to (http://archive.is/kPfeV)"
  • "Dear Core, please change Proof of Work function to CPU-only model. (http://archive.is/95T3D)"
  • "Keccak as proof of work for bitcoin? Will the big miners accept it? (http://archive.is/NAyGm)"
     

(pm me if you would like to recommend edits to this list)

[BrCoh1] Cuckoo cycle is one of the most ASIC-resistant Proof-of-Work algorithms.

• Website: btcpowupdate.org (http://btcpowupdate.org/)
• Twitter: @BtcPowUpgrade (https://twitter.com/BtcPowUpgrade)

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 (http://archive.is/FTSn2)". 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.
   

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):
   
(1) Empirical data - Tests, competitive benchmarks between PoW algorithms when merged with Bitcoin codebase, accurate descriptions of vulnerabilities/exploits with sample code.

(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

iQEcBAEBCAAGBQJY1fjOAAoJECXDNTkzG2QGfcoIAJEp1+LmBom2ZDAEC13PeIdH
8V9w6bP0/dRe2lcrwU5bOSCZHrzqI7JOCUC28KMXrt3RvHUdtuwcnoPpS3Rebaub
+5BloS+OEwSNDb5qvLIJX7dp38GYKThK/Kw70r5/NS+Vh1VMCwZyWd+BLjoMSnmw
QyNZOLSVk9bR7WShxdq0aj4ADGAPhTwBey0/R9CfHZOlQzWHQIVwmOXShOBfDI1O
ENomlu9k1b1fPf5U5V8Zg3rEyPU0nfWLSGjNqwGNeRuofob61XCFfYGHopyPdmRP
cliCCXg1R236sJICFjYJ/c/+gyzw9cxRXwwXseJ/ik2wM/5dl9rzgnQp4TmnNB8=
=fBZw
-----END PGP SIGNATURE-----

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.

PKI Mining and Node relay.  (Public Key Infrastructure Mining and Node Relay)

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.

Great, lets work to be prepared for the worst!

I don't like hardforks, but let's better be prepared if things get really ugly!

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...


https://twitter.com/JihanWu/status/843341104531427336

So 2 newbie accounts trying to post something and stir up some debates in the community I see ;D ;D ;D

It is good to be prepared for any eventuality. Just because we talk about a PoW hard fork doesn't mean we'll use it on a whim.

A good thing would be to have some script somewhere tracking blocks and transactions, so that if any big censorship re-orgs happen then it can be proved to the public.

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?

Yes, we should only use this after an attack occurs, but need to test and prepare now. If anything showing we are prepared is likely to prevent an attack in the first place.

https://twitter.com/petertoddbtc/status/843450186416365569




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.

PoS doesn't work, see this PDF https://download.wpsoftware.net/bitcoin/pos.pdf

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.



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?

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 secure
3) 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


Sounds to me like extension blocks for more capacity, but that is outside the scope of this topic.

whats needed from the regular folk that are just miners?

Software will be deployed soon for you to start mining once the testnet is up with your GPU . If you want to prepare , get a high end gaming GPU for a desktop computer. 

Since most of you obviously haven't read it, let me direct your attention to Section 6 of the Bitcoin white paper (https://bitcoin.com/bitcoin.pdf):

already got those ready, lets get this test underway  8)

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

We studied Proof-of-Work functions for a long time, chose Equihash (https://z.cash/blog/why-equihash.html), hired a legendary hacker to study it and write his evaluation (https://z.cash/blog/the-zcash-equihash-analysis.html), gave out $30,000 dollars in bounties to make the best implementations for CPU and GPU (https://z.cash/blog/announcing-miner-contest.html), got lots of good open source implementations (https://zcashminers.org/submissions), launched the network (https://z.cash/blog/zcash-begins.html), and mining has been working very well at scale ever since (http://www.coinwarz.com/network-hashrate-charts/zcash-network-hashrate-chart).

The reasons we chose Equihash are:

* 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.

No need to be fancy, just triple SHA256 would be enough to change the current dynamic and not deviate too much from Satoshi's plan.

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 .

Something to consider, definitely.

Hmm... but either way , this introduces the same costs and risks as Keccak and at least we can delay ASICs a bit more with Keccack

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.

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

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

here is a list of the flaws from the whitepaper-
https://gist.github.com/harding/dabea3d83c695e6b937bf090eddf2bb3
https://github.com/bitcoin-dot-org/bitcoin.org/issues/1325

Is this for real or is this a joke?

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 want 1 secure algo , not many as that would make bitcoin more insecure



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.

Interesting altcoin proposal, when can I mine it?

Any idea when Poloniex will list it?

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.

Have you guys looked at Cuckoo cycle?

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)"

https://github.com/tromp/cuckoo

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


Another good candidate.

I doubt that this is true. Can you point me to where you heard that?

You should probably think carefully and make up your mind whether decentralization or 51%-attack-resistance are more important to you:

https://bitcoinmagazine.com/articles/zcash-creator-on-the-upcoming-zcash-launch-privacy-and-the-unfinished-internet-revolution-1472568389/

(Search in text for "fundamental trade-off".)

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

https://twitter.com/ZcashMiner/status/815512912546541568





yes, I agree... something to think about

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.

Interesting to hear that, thanks for sharing.

If anyone's interested Aeternity has a testnet running using Cuckoo Cycle https://github.com/aeternity/testnet

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.

Thank you for taking the initiative on this.

Alternative that doesn't screw over the all the miners.

https://bitcointalk.org/index.php?topic=1833046.0

....yeah... I don't think that works... For reasons others commented in the thread.

Keep working on it though-- the mutually assured destruction angle seems interesting. It may be possible to salvage the concept. I might even give it a few cycles.

Regarding deterrence it would be cool to change the PoW algorithm at the same moment BU activates.

there is something here - its about "scaring" miners to stop signaling BU .. hope someone else can run w this idea.. changing POW is a bad idea - it will push all "good" miners  to BU

yes, as a poison pill, that will stop it from happening on the first place

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.

Just google "luke-jr insane religious fanatic best-of quotes" or take a look at this reddit thread https://www.reddit.com/r/Buttcoin/comments/4936kw/lukejr_is_a_seriously_a_super_crazy_person_quotes/ - This guy has some messed up views. He is certainly not a developer or contributor. He is just trying to stir shit up because Core is becoming desperate since it's become inevitable that SegWit will not be activated.

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 (http://archive.is/9WKT7)).

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 (http://archive.is/ymscw).

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.

Yes, I noticed that BitFury has been sending their people to meet with Bitmain recently; maybe they are feeling a bit nervous due in part to this PoW talk.

some kind of financial incentive to non BU signaling miners is a must. also I think there are two separate issues

1) how to avoid the fork
2) how to defend against attack post fork

starting the convo with POW change will not help to stop the fork

maybe we change from "PoW Upgrade initiative" to "Defending Bitcoin initiative" 
 

THIS!!! So fucking much!

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.

Zooko, I appreciate the information-driven post. I think we should attempt to model this discussion on an empirical approach...

Everyone, I am not the judge here, but I would like to offer a ranking of different types of communications, from most to least valuable:

(1) Empirical data - Tests, competitive benchmarks between PoW algorithms when merged with Bitcoin codebase, accurate descriptions of vulnerabilities/exploits with sample code.

(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.

========================

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.

BU is cesspool - BU is negative - BU is unsustainable  

Such a proposal, changing POW, is a sign of insanity.
It wil be the end of the trust in BTC, the network will be unsecure for a long time and BTC will become a shitcoin

Denying scientifically proven, empirical evidence under the guise of religious views is not valid. It's insanity. And luke-jr is not a developer.

changing POWis on the table because current centralized miners are attacking bitcoin, and will kill it. Satoshi said 1 CPU 1 vote.. never envisioned asics
 

religion is insanity - whats your point - ive read luke-jrs code

i can scientifically prove with empirical evidence that luke-jr is a developer... hmm guess the religion here is called "BU"   

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.

I created a topic on this idea, possibly in the wrong location:
https://bitcointalk.org/index.php?topic=1832581.0

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?

So basically only way to make this work is to get every single exchange out there to change their software to this new POW and it should work correct.

Because the SHA256 ASIC miners won't accept this.

How would this work exactly?

Aren't we repeating just another cycle: Change algo -> asics get developed at some point -> same problem again ?

Btw this coin implemented sha256t for some empirical evidence: https://bitcointalk.org/index.php?topic=1801129.0



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:

...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".

IMHO

Alex from Bitfury is cool but Bitfury George has gone off an a mad totalitarian rant -

http://www.trustnodes.com/2017/03/19/bitfury-threatens-prosecution-potential-pow-bitcoin-fork

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 would never try to find a PoW that does anything useful but would consider what else the chip doing the PoW can do.

It was one of the reason why I was into Primecoin in it's beginning.

I'm no mathematician but I thought if you can produce an ASIC that find Cunningham Chain Of Primes, maybe that chip can do many different calculation that could be scientifically useful.

Agreed. You can hate ASICs, but they do provide a very robust network, very expensive to attack. Change of PoW would do more harm than good.

For the network to stay secure the PoW algorithm should not be "useful" for anything else. If the price of that other thing becomes higher in the future...the network loses hashrate.

Creating a decentralized payment network is useful enough by itself.

You are only agreeing on my prelude, I'm for using a PoW that run best on a chip that can do many other things.

The whole point of this thread is to find a replacement PoW not to argument whether it's a good or bad thing to do.

Oh ok, I missed that :) Sorry

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

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.

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.

Here he is talking about it on Whale Pool: https://youtu.be/HZOD3ytZLWo?t=2395

Aww cute biased opinions by TWO brand NEW accounts....

For eveyone else guys pllllllease run your own Node at home now.

The testnet hasn't implemented Cuckoo Cycle yet; they're running some dummy PoW...

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.

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.

Wow! A Luke-Jr project!

I've got one of his immortal quotes hanging on my fridge:

"By the way, the Sun really orbits the Earth, not vice-versa. " (https://www.reddit.com/r/Buttcoin/comments/4936kw/lukejr_is_a_seriously_a_super_crazy_person_quotes/)

Anyhew, Wouldn't it make sense to look some more at PoS, as PoW clearly doesn't scale?

Is it desirable to include some kind of asic resistance?

Also, would it not make sense to make a HF segwit for this and make adjustments to max_block_size, as it would have to be implemented in a HF anyway?

Best of luck with the project!

Alternate PoW's.

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.

This has to have been thought of before?

It cannot work on it's own as there is nothing at stake, allowing an attacker with large holdings in the future to rewrite the chain at no cost.

However, it can work in a hybrid model, where the sole purpose of POS is to solve the 51% hashpower attack problem. For more info, see Interleaved Mining,
https://bitcointalk.org/index.php?topic=1317240.0

The primary benefit of this approach is to not punish miners who are not hostile. It allows them to retain their investment in SHA256 hashing hardware.

Casper should be looked at

How to kill million-dollar industry in one commit (c)LukeJR
Never 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 14
Yet 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.

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:

http://trilema.com/2016/the-necessary-prerequisite-for-any-change-to-the-bitcoin-protocol/

and they still are:

http://trilema.com/2016/the-necessary-prerequisite-for-any-change-to-the-bitcoin-protocol/#comment-121472

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.

I also participated to an interesting survey with live results update : http://www.strawpoll.me/12569383/r

I invite you to do the same as it is related to this project.

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.

The more I think about it , the more concerned I become. Ver and Wu are a bunch of crazy guys , and we must be prepared for the worst.

So, I for one strongly support the change of PoW algo.

I personally suggest some RAM-intensive problem, say 8GB at lease,  basically you need a lot of memory, which makes the ASIC impossible.

Just adding my suggestion to counter the bot net fear mongers (aka altcoin gpu farm owners).

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.

Edit: lol tonymidlee you beat me to it.

I'm into this idea.


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.

And Carlton Banks is right.

A change of PoW as a quickfix (to fool currently manufactured ASICS) without too much risk of bugs can be as follows:

Instead of checking for n zero bits, implement checking for n one bits instead.

If you are bold, you can have the sequence of leading bits to check to be dependant on the trailing bits of the previous block.

I like the idea of a memory-hard (Equihash?) PoW.

Another option would be a PoW that's randomized every retargeting period to make it ASIC-proof. A block hash would be used as the source of randomness.

https://medium.com/@vcorem/lesson-learned-from-the-classic-coup-attempt-or-why-core-needs-to-prepare-a-gpu-only-pow-6a9afe18e4b0#.fv0s8ll36

A long term ASIC-resistant solution would be where the PoW algo itself is dynamic:

The algo, consistent of base code blocks, will be compiled using (previous) block parameters.

So the exact algo will not be known beforehand, thus ASIC-resistant.

Does it make sense?

Jihan and bitmain have given plenty of statements they intend to attack -

https://twitter.com/gavinandresen/status/827904756525981697

https://archive.is/zjvh1



https://www.cryptocoinsnews.com/bitcoin-market-needs-big-blocks-says-founder-btc-top-mining-pool/


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.

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.

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.

Nice with CPU-only model. when do we start ;)

Feathercoin and some other coins changed proof of work. And guess what? It's still Feathercoin.

https://twitter.com/bramcohen/status/843856434999844864



Proof of space is too hypothetical and not well tested to be considered

Thus we are left with these options

Keccak - Code already ready and ASIC resistant
Equihash - Code tested on zcash and ASIC resistant
Ethhash- Code tested on ETC and ASIC resistant
or combination of the above...

I would stay away from PoS because it is insecure and goes against bitcoins ethos. I would stay away from Cuckoo because we dont have code ready like others.

Or they prepare counter-measures to whatever is (publicly) tested, because they are too belligerent to back down, tail between legs. I seriously doubt your scenario.



Or buying time.


I pretty sure you don't get it.

Bitmain et al don't care about their infrastructure, or negotiating, I'm convinced you've never dealt with sufficiently pathological characters to understand 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.

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.0
If 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.

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.

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

Their security would increase with ours and they would contribute more to bitcoin testing and development

We saw this happen when Dogecoin started merge mining with litecoin.

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?

Whats about "SpreadX11" from SpreadCoin?

Why are these new sockpuppets posting here directly? Have they removed the post count prevention mechanism?

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?

Im merely suggesting that your concerns are valid and we should also prepare a secret second backup PoW change if they attack again. There is a great suggestion to protect devs here by forcing  pseudonymous BIP submissions :
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013735.html

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.

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.

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.

I am being pragmatic

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.

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

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


I've provided sound reasoning already, refute it.

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?

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

EDIT: Grammar

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.


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.

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.



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.

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

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 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.


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.

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.

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

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.

You do realise that the PBOC prints electronic fiat at zero cost?

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.


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.

Sorry mate the sky isn't falling.

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.

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)

Then this would seem to be the way to go, since functions like Equihash are already available for use as drop-in replacements for SHA256. A randomized GPU PoW would be much more work to implement.

Could someone fork Bitcoin-core and make the necessary changes so we can have a bitcoin-equihash-testnet?

Also might be worth considering a fork for sha256+equihash, so we can evaluate one of the popular propositions here (i.e. so as not to totally destroy the friendly miners (BitFury, BTCC, et al.)).

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.

Maybe as a progressive but relatively quick PoW switch as a SF, it could be done. As Maxwell describes here: https://www.reddit.com/r/Bitcoin/comments/60j1zi/bram_cohen_bittorrents_creator_a_soft_fork_change/df6snyy/

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.

Damn... think about it: this is the key for decentraliced mining? OR?


https://www.reddit.com/r/Bitcoin/comments/60k5ya/powa_with_hybrid_pow_you_could_have_2_algos_an/

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.

BitClub just mined a block signalling both BU and Segwit: http://archive.is/1RXeH

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.

Or maybe bitcoin-cuckoo-testnet? We need to evaluate the relative strengths/weaknesses of these two PoWs, I think, and decide on one of them.

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

The variable of block reward time make mining pools economical. small percentage of hashpower won't get steady income when it mined solo.

So the mining itself can always leads to a bit centralize under current consensus, what ever PoW you switched to. It's not the right solution for central mining.

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...


Rico

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.

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.

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)

If PoW is changed can it still be called bitcoin?

If such fork happens what will they call it?

How different will this coin be from the original vision?


You can't still compete with their hardware prices and electricity costs.

Same stuff when GPU mining, I could buy the same GPUs as everyone else in the world but it was much more expensive for me and electricity costs would make my mining operation unprofitable.

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)

The PoS 0 reward solution (empiric example here: https://bitcointalk.org/index.php?topic=1801129.0)  would be much more attractive, putting some control to nodes and the people that actually own BTC.

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.

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

Bitcoin should be alted to PoS.

There's already a boatful of shitcoins.

Jeebus!

This thread is really catching on. Have any of you thought of maybe trying find a pragmatic solution to the issue at hand?

Can't we all just get along?

https://www.texascosplayphotography.com/wp-content/uploads/2014/09/mars-attacks-nicholson-get-along.gif

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.

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?

Any chance of coming up with something that has benefits outside Bitcoin as well?  Similar to GridCoin or CureCoin?

...ok... so just tried to hash the entire .bitcoin/blocks on my node... that takes a long time lol. Something like: (following) might work better/ be more practical...

sha256(sha256( nonce + NormalValidBlockData + hash2(hash2(first n bytes of all previous blocks/blockhashes concatenated + nonce)) ))

where n is difficulty2...

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).

No, because that would be braindead unless someone comes with a breakthrough that makes an arbitrary/useful PoW rock-solid and didn't need a massive amount of extra gossiping in the network.

Sadly this doesn't exist AFAIK and these two are completely broken.

Yes, it reads as conspiracy theory mixed with confirmation bias.

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.

Here's their thread: https://bitcointalk.org/index.php?topic=657601.0

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.

Why? We're talking about Bitcoin. Unless you mean to one of their concrete PoWs for some reason. I didn't see much documentation on their PoWs there.

Yes. Specifically, we're talking about changing Bitcoin's Proof-of-Work.

OK try this then:
https://en.wikipedia.org/wiki/SHA-3

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).

SHA-3 does that.

For reference here are the lifespans of various cryptographic hash functions including our beloved SHA-2(56)
http://valerieaurora.org/hash.html

As you can see SHA-3 (Keccak) is the most secure and it has been brought up earlier in this thread.

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

Whenever any cites that Val Aurora article, please follow-up and link to this newer, better, article:

https://z.cash/technology/history-of-hash-function-attacks.html

blog post about this article when we posted it:

https://z.cash/blog/hash-functions.html

Sincerely,

Zooko

testing image: https://z.cash/images/hash-functions-chronology.png

testing image: https://i.imgur.com/rAxg7qP.png

Well, if you have been paying attention, Luke already coded a Keccak PoW change last year. It would literally take just changing the activation block if that was the change.

But thanks for your input.

I'm very familiar with it. I have coded a Keccak lib myself and a BLAKE as well.

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 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.

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.

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.

Would be nice to get some feedback on all this from one of the devs.

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.

An automatic full PoW switch trigger on extremely anomalous conditions.

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.

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 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.

An extension of this post :

   https://bitcointalk.org/index.php?topic=1833391.msg18247163#msg18247163

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.

PKI txnpool.

Setup :
Miner creates prv/pub key pair.  Miner publishes pub key.  Could be anywhere.  Miner creates black-list of nodes (empty).  Pseudonymous.  Miners signs black-list with priv-key.

Node creates prv/pub key pair.   Pseudonymous. Node creates white-list miners using pub keys of miners.

Adding txns to PKI txnpool.

Node reads node mempool for new txn.  Node validates txn.  Node creates hash of txn.  Node encrypts txn using pub-keys of all miners in white-list.  Node signs encrypted txn.  Node creates txn-relay-file with : hash of txn, Node pubkey, Signature, list of white-listed miners, encrypted txn.  Node adds encrypted txn to PKI txnpool for relay.
   
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.

One word; hurry.

Oh, and also, hire a good public relations team.

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 (http://www.coindesk.com/fire-the-miners-radical-ideas-emerge-as-bitcoin-fork-talk-escalates/)], [2 (https://themerkle.com/bitcoin-may-switch-to-an-alternative-proof-of-work-algorithm-in-the-future/)], [3 (https://news.bitcoin.com/bitcoin-developers-changing-proof-work-algorithm/)], [4 (https://qz.com/937312/bitcoin-btc-is-tearing-itself-apart-again-and-its-price-is-yo-yoing/)]).

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?

Block 1 JH
Block 2 Skein
Block 3 Groestl
Block 4 Cuckoo
Block 5 Keccak
Block 6 Equihash
Block 7 BLAKE2
Block 8 SCrypt
Block 9 CryptoNight
Block 10 Ethash



Right now, to attack Bitcoin you only need to bamboozle Jihan.  Not very expensive.  :D

If Bitcoin is in danger due to such an attack, it's nice to have fully prepared contingency plans ready to deploy.

But the socioeconomic consensus will allow Roger and Jihan to initiate aggression before it reacts with overwhelming retaliatory force.

Your first suggestion seems to be the simplest thing which would actually work.

But I also like the 2nd one!



An option worth considering on all doomsday machines....

https://en.wikipedia.org/wiki/Dead_Hand_%28nuclear_war%29

My opinion from the miner's economic point of view ...

a GPU Farm get a much lower hardware depreciation than ASIC hardware economics.

A GPU farm can also be used for Deep Learning rent (for instance.:
AWS, Google, Azure GPU cluster (on average costs) $0.90 per hour to run)
also some small GPU providers https://www.leadergpu.com/

You can reseller your used hardware to gamers on ebay, etc.

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.

Each algorithm would have its own difficulty I would imagine.

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:

https://cloud.githubusercontent.com/assets/6071028/24692587/508560a8-19c9-11e7-863a-1feda9ce9621.png
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-blocks are 100 Kb in size; new PoW blockchain has one-minute block discovery rate (i.e., confirmation time).
• 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.

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)

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).

tl;dr - DeSantis is testing Keccak & Cuckoo using a Bitcoin Network Simulator.

-----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)?

1) Please send PGP-signed emails to jecooper@alum.mit.edu (you may encrypt if you wish to remain anonymous, my PGP key ID is 331B6406 (pgp.mit.edu)).

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

iQEcBAEBCAAGBQJY2FrYAAoJECXDNTkzG2QGrvwH/0CjwKRgSmHmMPFXKA8F1YWa
CMcrWx0KN2ykhqxclxEAlMIs8Zb4u3KO89nejza/Guh0f2sNWSCW6NvrEhRzHodf
TSn8VpCcjpeYc1Iu5wSMBTVk6h/dqZy0eJJRukN4M8qTstnwvU2B48I7Q24x9zLe
B2lOxqhm3fIauaXCTgey4YLgvMfo058jg7+x9DrYKtmP8jht49AmvBv+XI69YfHq
XHvTpbipeNsoTR7qQUXnsnGtbMW7Sl0jywFjRUe1Gq7xGBf6ICH6WkCBLgRDCPCA
z+7gqv6zqjZaAqmbaZej/+4JShnhX2wgj1LKvtW65TdJuyxy4KG6sS231wgAp/4=
=yOSx
-----END PGP SIGNATURE-----

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.

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.

Thats what I think. My next question for that would be, wont it make the network open to attacks if the difficulty suddenly drops low? The idea might be good on paper but its really only complicating matters. Best to come with a new POW algorithm that uses less energy.

Not really.  Until it stabilizes, my expectation would be that you would just need to wait for more confirms before you can be assured that the chain you've put a transaction in hasn't been orphaned.  Now 6, perhaps as high as 20.  When lightning is available, I don't think that's really that much of an issue.

There is collateral damage.

But the trade-off is this: allow a certain attack from a malicious actor or potentially allow cheaper-than-usual attacks from unknown actors temporarily.

Right now the mining cartel protects us from any other potential attackers in terms of hashing. Still, not an acceptable situation.

This is why a gradual phase-in of the new PoW via PoWA is the best option.

Yeah, I was talking about changing the PoW generally. Not championing my personal favourite as I'm still reading what others think.

I would like to share an hypothesis.

With enough asics a group of miners could offer/sell an alternative to SWIFT for banks?

The group could settle a secret agreement with some banks to raise a few billion US$ for their hash capacity (they would have to leave bitcoin).
They would need something like 40% to 50% of bitcoin hash rate to avoid attacks (Bitcoin unlimited is in almost 40%?).
 They would have to keep building asics to keep hash capacity in bitcoin level. Or build even more.
Them we would live in a world with 2 major coins. Both only vulnerable to each other hash capacity.
The miner (banks backed) would have lot of budget to keep pumping asics until bitcoin is forced to change POW or other mitigation strategy.
The group would guarantee its future in asics manufacturing and operations and would ´t care if bitcoin fails. Quick $ with low risk. As it would have a signed contract with major banks to back them.
Actually this group of miners would gain with bitcoin suffering.
Banks could have a chance to have its own SWIFT and damage bitcoin considerably, gaining more time for their fiat party, with very low costs for them(comparing to acquisitions we are seeing today and the SWIFT value) .

 
I love this one.  

Like you said, but an extension of what you suggest, have the check-bits being searched for as a function of the previous mined block.  Instead of searching for 00000000000 starting at nth 0, search for 76436753432 at nth 7.  Or that at 21, going backwards.  21/20/19/18/etc.  Or pick the Xth prime, and skip the Yth prime of each element, where the primes used is a function of the hash of the previous block.

Introduce them as a randomized instantiation.  ~10/1000 is this new 'format'.  Then, after 1000, it's ~20/1000.   Have a new difficulty setting for these new elements.  Who cares if you get a virtually instantaneous block reward for 10/1000.  No different than chance happening for that normally.  By the time that it got to 100/1000 there would be an entirely new set of miners, on an entirely new set of difficulty settings.

It doesn't punish the miners that are currently mining in an untoward manner.  It gives them an acceptable return on their existing hardware.  That would account for a two year rollover.

Then, let the miners know that the same thing is going to happen again in two years.

It de-incentivizes hardware solutions, but doesn't kill them.  I'm not sure this solve the long-term problem of centralization though.  While the prime thing is good, you want all of that calculation to be done by the miner, with the least amount effort you can come up with so that it can be validated.  This just means that you could have relatively minor modification to the hash validation that current hardware wouldn't be designed for.  I don't actually know how the ASIC's verify that a specific hash meets the requirements of validation.  It might be as simple as updating a single variable within their hardware or software implementation.  Instead of looking for "000000" look for "123456".

If theres a POW upgrade what will happen to the Chinese miners? Will it be possible for them to continue to mine using the old SHA256 and fork away from the upgraded POW algorithm? I think that would be a losing move for the current developers and the ones behind them.

They can try to keep their fork alive but who wants to use a crypto completely dominated by 4 odd dudes from China? Maybe Roger and a few other lunatics? Win-win.

exactly!, who wants?
i say Banks or SWIFT!!imagine a new SWIFT based in sha256. As secure as bitcoins(because it would have a considerable hash capacity!), at least for now. 250millions usd$? its a bargain for a startup that aims to detrone SWIFT! People need to prepare , investigate this hyphotesis. we must be negotiating with people(BU miners) that are already out of bitcoin.
Read my post , few posts below, for more info.

That is your point of view yes, but what about the rest? Will they follow the people who can secure the network or will they follow the new POW upgrade and take the road less traveled? It will be a hard decision but I think the majority will follow the safer road.

If these people believe in security by being under a racket with full control over their currency, let them have their coin. I didn't need BTC for that.

AFAIC their presence is a liability, if they get to influence the decision process.

By that I assume you mean the big Chinese miners. Wasnt the specialization of mining a part of the natural evolution of Bitcoin? There are some people who argue against the POW upgrade because they say they would preferably go with the ASIC miners than the botnet that hackers are known to be using. 

Does that argument not favour a hashing algo that does work with GPUs/FPGAs? Is that even possible without the risk of an ASIC being developed?

No, I mean the "coffees in the chain" brigade.

I can understand the thought behind wanting to make this change and call me sentimental, but I don't think Satoshi would have wanted this for Bitcoin. Bitcoin still functions as it's supposed to as long as there's not a 51% attack and changing something for people's benefit is still just that.

The argument is about the developers who are proposing the POW upgrade shaking the cage too much. Its either theyre an opposition controlled by the miners or just your ordinary Bitcoiners who hate to change the status quo.

Sounds interesting idea. I'm thinking here about 'Parallelism' and 'Message Passing Interface' ( I will review some academics papers and lectures 101 about 'Parallel Computing Theory'  such as https://www.youtube.com/watch?v=j1H2UbzeNrY (https://www.youtube.com/watch?v=j1H2UbzeNrY) ) after these technical (perhaps some GPU/CUDA?)  ..

then, I will think about



... is that roll out would follows the yield curve ?

My soft-fork PoWA proposal has been somewhat revised and expanded:

https://bitcointalk.org/index.php?topic=1833391.msg18344077#msg18344077

Discussion of the proposal on Reddit:

https://www.reddit.com/r/Bitcoin/comments/62taef/can_powa_proofofwork_additions_provide_a_way_out/

Lets pretend Bitcoin really did upgrade to a new POW algorithm and left all the asics and mining farms, mining equipment and whatnot useless. Is this really what Bitcoin needs? I dont think this will have a good image to the general public. It could be viewed much worse than Ethereum's hard fork.

In every job, if you do not do your work, you get fired.
If Miners stop to work on the protocol that the majority of users want, it's only natural to fire the miners and hire new ones.
Can't see anything wrong with that, it will be seen as a strength of bitcoin.

PoWA allows us to just downgrade the miners a bit without firing them. It could be a politically acceptable solution for the entire ecosystem.

My soft-fork PoWA proposal has been additionally revised, with an improved schematic:

https://bitcointalk.org/index.php?topic=1833391.msg18344077#msg18344077

Discussion of the proposal on Reddit:

https://www.reddit.com/r/Bitcoin/comments/62taef/can_powa_proofofwork_additions_provide_a_way_out/

...?

PoW change without virtual unanimity just means you're launching another shitcoin.

Ethereum's hard fork is not viewed poorly by industry. It's price has gone up nearly 6x what it was after the ETH/ETC split. To industry it's hardfork was viewed as the Ethereum Community moving fast to stop a theft. Emphasis on moving fast...unlike Bitcoin.

I'll be following this closely. Correct me if I'm wrong, but won't a POW change fix all the problems BTC is currently going through?

It will fix Bitcoin's main problem, namely mining centralization. The idea doesn't seem to be gaining traction among leading representatives of our community, however. I think fear of powerful mining interests is getting in the way.

to show your support for Segwit enforcement, support BIP 148.

run Bitcoin Core and add 'uacomment=UASF-SegWit-BIP148' to your config file. It's easy.

https://i.imgur.com/CV82GIO.jpg

I liked to find your comment so successful today with 85% of the hashpower ready to make a hardfork to impose the extension of the limit of 1MB.

What do you think today given the situation?

If the miners run the hardfork successfully and set the precedent of imposing block limits, does this mean that the best ASIC chip maker will always have the supremacy in Bitcoin?

Will the mining of empty blocks during hardfork inevitably force developers to a desperate change of PoW?

So the developers would have the power?
Which is based on the old IRC takeovers (Gavin's kick true story).

If the change of PoW were successful, give enough power the non-miners to steal commissions (off-chain) in crescendo and uncontrollably damaging the security of the main blockchain?

Who rules in Bitcoin?

Thank you.

I've started a GitHub repo specifically for a possible emergency PoW change hardfork.

https://github.com/BitcoinHardfork/bitcoin

While I understand this thread works under the assumption that a PoW change will be done unconditionally, and this code can possibly be used for such a purpose, please note that it is being developed it from a strictly emergency-use-only standpoint, since the community has not rallied around the PoW change idea at this time.

I would appreciate any review and/or contributions others can provide.

The repository does not intend to select an algorithm until such time as a PoW change is needed.
For this reason, the code is being designed such that the algorithm is configurable.
Therefore, please feel free to contribute new PoW algorithm options.

MTP
https://github.com/zcoinofficial/zcoin/tree/mtptest
https://arxiv.org/pdf/1606.03588v1.pdf

Luke, I recognize your right and ability to try it.

But you must understand as soon as possible that changing the Bitcoin PoW is not viable without destroying it.

It is not an emergency option, it is the nuclear option.
And Bitcoin is not based on MAD.

And even if you execute it successfully and without destroying Bitcoin you will only change some miners for others that will soon form the same farms.

Developers will never have authority to do whatever they want in a PoW-based crypto.
Nodes are cheap and developers too.
Fortunately.

Please reconsider, we need a team of developers focused on on-chain solutions.
Only in this way can Bitcoin preserve hegemony.
People want a Bitcoin safe, fast and cheap.

Please leave in peace the future commissions that belong from the beginning to the miners.

Any idea yet when we can start mining your new altcoin??

Why would you want to mine in a altcoin with a precedent of change of PoW decided by a few people distinguished by having privileges in a centralized repository?

https://www.reddit.com/r/BitcoinABC/comments/6mmms1/new_release_of_bitcoin_abc_0142/

I propose a useful POW system where the problems will incentivize the development of energy efficient reversible computing devices. In particular, I propose that one use a reversible computing optimized POW problem RCO-POW which can just as easily be solved using a reversible computer as it can be solved using a conventional computer. Reversible computers have the potential of being many times more efficient (and hence more powerful) than is possible with conventional computers. One disadvantage of RCO-POW problems is that these problems will not be ASIC resistant since reversible computing devices will be in a sense certain kinds of ASICs. A couple ways to mitigate this disadvantage would be to implement several RCO-POW problems instead of just one or to implement RCO-POW problems along with other kinds of POW problems in the cryptocurrency.

I have discussed how RCO-POW problems would work in more detail here https://bitcointalk.org/index.php?topic=1985289.0 (https://bitcointalk.org/index.php?topic=1985289.0).

Joseph Van Name Ph.D.
boolesrings.org/jvanname (http://boolesrings.org/jvanname)