Topic: [ANN] Bitcoin PoW Upgrade Initiative - page 3. (Read 42931 times)

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?

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?

Each algorithm would have its own difficulty I would imagine.

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.

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.

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

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.  

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.

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

One word; hurry.

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

An extension of this post :

   https://bitcointalksearch.org/topic/m.18247163

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.

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.

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.

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.

An automatic full PoW switch trigger on extremely anomalous conditions.

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?

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.

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.

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.

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.