Re: Is it possible to force miners to include a transaction in a block?
For some reason (probably related to the Christmas holidays) I missed these two last thread answers. Now I've a little remark for one of them (better late than never 
):
This brings me to the idea to adapt the same principle to the relation between miners and other nodes, to prevent censorship of certain transactions:
Before a node submits transactions to another node, you could require it to send you a list of transactions which were signed by a "node key". If there is a transaction this node did not include but had been seen before when communicating with another node,* and is also not in your own transaction list, then you don't transmit your transactions.
To really prevent censorship his would of course have to be combined with the "challenger" role I outlined above -- the possibility to "overrule" a block if censorship has been detected. In this case, censorship would have been detected if a node can prove that in a block a transaction was excluded which 1) had been signed by the miner's "node key" (the public key would have to be included in the block header) in the node-to-node communication to build up the mempool, and 2) had higher fees than the lowest-fee transaction that had been included in the block.
If miners add lots of fake transactions, that would cost them (potentially a high amount of) fees.
The main problem here stays however the same, I think: The miners wanting to censor txes could simply use another "node key" for signing transactions in the node-to-node communication than the one they use later to mine blocks. If there was a way to enforce these keys to be the same, then the problem would have been solved without requiring privacy techniques. But I still have no idea how this could work and it may be impossible in a P2P context.
So in the end, if this problem is not solved, the "CoinJoin/Monero way" would be the only one to really prevent censorship.
*You could fine tune that so latency losses aren't taken into account. For example, only "punish" nodes that have excluded transactions which you already saw more than 20 seconds ago or so.
):But if there was a potential coinjoin with (say) 50 different participants, and I was holding the whole thing up because I didn't want my UTXOs to be coinjoined along side some other specific UTXOs, then the rational action for everyone else is not to ask me to share a list of the UTXOs I don't like and then double check all the other participants against my list, but rather to simply exclude me since I'm the troublemaker here.
In general I think you're right here. At a first glance, I thought being blocked in the "pre-CoinJoin negotiations" wouldn't matter because you can always change your address and IP, but then you would have to move your coins, and this would mean investing money in fees. There may be possibilities to game this for people with large pockets but I think in general the incentives should work here.This brings me to the idea to adapt the same principle to the relation between miners and other nodes, to prevent censorship of certain transactions:
Before a node submits transactions to another node, you could require it to send you a list of transactions which were signed by a "node key". If there is a transaction this node did not include but had been seen before when communicating with another node,* and is also not in your own transaction list, then you don't transmit your transactions.
To really prevent censorship his would of course have to be combined with the "challenger" role I outlined above -- the possibility to "overrule" a block if censorship has been detected. In this case, censorship would have been detected if a node can prove that in a block a transaction was excluded which 1) had been signed by the miner's "node key" (the public key would have to be included in the block header) in the node-to-node communication to build up the mempool, and 2) had higher fees than the lowest-fee transaction that had been included in the block.
If miners add lots of fake transactions, that would cost them (potentially a high amount of) fees.
The main problem here stays however the same, I think: The miners wanting to censor txes could simply use another "node key" for signing transactions in the node-to-node communication than the one they use later to mine blocks. If there was a way to enforce these keys to be the same, then the problem would have been solved without requiring privacy techniques. But I still have no idea how this could work and it may be impossible in a P2P context.
So in the end, if this problem is not solved, the "CoinJoin/Monero way" would be the only one to really prevent censorship.
*You could fine tune that so latency losses aren't taken into account. For example, only "punish" nodes that have excluded transactions which you already saw more than 20 seconds ago or so.