Re: Is it possible to force miners to include a transaction in a block?
I didn't have too much time the last few days, I only could read a couple of basic articles, but my intention is to investigate the Monero protocol further and look if there could be some elements which could theoretically be integrated into Bitcoin. Until now my understanding is that the censorship resistance in Monero comes from basically two elements:
1) the fact that all possible inputs which could be included in a transaction/block come from CoinJoin-style transactions with ring signatures and lots of inputs and outputs, so if the miner wants to censor transactions, he would have to do extensive blockchain analysis to see which of the inputs could belong to a tainted "chain of transactions".
2) a transaction can go to a stealth address, which obfuscates the real address of the receiver. I'm in doubt however if this is really an advantage to Bitcoin if you create always fresh addresses for your transactions (Monero seems to have an "account" model, which of course is not really privacy-friendly if it doesn't have a mechanism to obfuscate the real address).
But it leads me to another technical question: Can CoinJoin participants censor other potential participants of their CoinJoin? I.e. could there be CoinJoin transactions where a "tainted" input would be rejected by all other participants, so the often unfortunate owner of the tainted UTXO can't find a CoinJoin to integrate their transaction?
Of course it's possible that there may be altruistic
I'd be grateful if we can focus the discussion to the technical side, and not derail too much into theories about possible government actions and also let out the PoW/PoS debate which is irrelevant for this question imo.
I think for now the Bitcoin incentive mechanism works well (so I partly agree with @pooya87 and others), but we don't know what could happen in the future, so at least discussing a bit about possible technical strategies and "Plan B's" isn't in vain, imo. At least that was the intention of the OP. Thanks
1) the fact that all possible inputs which could be included in a transaction/block come from CoinJoin-style transactions with ring signatures and lots of inputs and outputs, so if the miner wants to censor transactions, he would have to do extensive blockchain analysis to see which of the inputs could belong to a tainted "chain of transactions".
2) a transaction can go to a stealth address, which obfuscates the real address of the receiver. I'm in doubt however if this is really an advantage to Bitcoin if you create always fresh addresses for your transactions (Monero seems to have an "account" model, which of course is not really privacy-friendly if it doesn't have a mechanism to obfuscate the real address).
Another possibility to prevent this kind of miner censorship is to expand upon coinjoins.
[...]Let say instead that your transaction is part of a much larger coinjoin transaction, with 50 inputs and 100 outputs, and a combined fee of 100,000 sats.
Yep, this is an interesting alternative scenario which could be enacted without any protocol change.[...]Let say instead that your transaction is part of a much larger coinjoin transaction, with 50 inputs and 100 outputs, and a combined fee of 100,000 sats.
But it leads me to another technical question: Can CoinJoin participants censor other potential participants of their CoinJoin? I.e. could there be CoinJoin transactions where a "tainted" input would be rejected by all other participants, so the often unfortunate owner of the tainted UTXO can't find a CoinJoin to integrate their transaction?
Of course it's possible that there may be altruistic
I'd be grateful if we can focus the discussion to the technical side, and not derail too much into theories about possible government actions and also let out the PoW/PoS debate which is irrelevant for this question imo.
I think for now the Bitcoin incentive mechanism works well (so I partly agree with @pooya87 and others), but we don't know what could happen in the future, so at least discussing a bit about possible technical strategies and "Plan B's" isn't in vain, imo. At least that was the intention of the OP. Thanks