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

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.

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.

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.

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.

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?

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.

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.