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.