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

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

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

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

This is how the system might work:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PKI txnpool relay.

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

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

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

Miners use PKI txnpool to get txns.

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

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

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

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

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

What about cycling through 10 unique PoWs every 10 blocks?

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

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

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

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

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

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

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

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

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

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

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

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

What about cycling through 10 unique PoWs every 10 blocks?

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

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

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

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

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

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

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

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

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

Brief description:

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

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

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

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

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

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

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

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

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

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

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

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

Benefits:

New decentralized mining industry is created.

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

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

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

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

Variations:

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

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

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

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

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

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

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

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

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

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

All of the above is preliminary and subject to change.

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

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

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