Cyphering the TXs until they are confirmed

[Hyena]

When I was reading this article, I figured that it would actually make sense to encrypt the TX details before sending it to the bitcoin network. That way, miners cannot discriminate TXs by their contents. The TX originator would wait until their TX has received 6 confirmations and then publish the encryption key to the bitcoin network. All nodes (miner or not) can then decrypt the already confirmed TXs. Miners would only get the fee for confirming the TX and they will see the TX inputs at first.

Has this been discussed before? Would it make sense to introduce it to the bitcoin's protocol?

[achow101]

I see two problems with this.
1) How would miners know the fee? They include transactions based on the fee.
2) How would the network know that the transaction is valid? If it isn't valid, they would be including an invalid transaction into the blockchain, which is not good.

[Kazimir]

And more importantly:
3) How would individual nodes detect whether a transaction is valid or not, thus knowing which txs they should relay or not?

Lowering the risk of double spends to an acceptable level in case of zero confirmation payments (think Point of Sale situations) are very much dependent on this. It would also allow for an incredibly easy (and free) DDOS attack on the entire network.

And besides, exactly how would you prevent some people (non-miners) from decrypting your tx, while allowing others (miners) ?

[shorena]

-snip-
And besides, exactly how would you prevent some people (non-miners) from decrypting your tx, while allowing others (miners) ?

The way I understood it is that not even miners can decrypt the TX only the person issuing the TX can do so once it is confirmed, or rather publish the key to do so. Which could increase the problem of invalid TX as its one thing to have an invalid TX with 1 confirmation, but another if it has 1008 confirmations.

[Hyena]

You all bring up some valid points. I initially thought that the network can tolerate invalid TXs since a fee has to be paid for any TX. However, this sort of encryption would require unencrypted statement to be included in the TX indicating the fee to be paid to the miner. The latter could turn out to be difficult to implement.

About DDOS... Isn't it already possible to DDOS anyway? By spamming dust TXs, for example.

[shorena]

You all bring up some valid points. I initially thought that the network can tolerate invalid TXs since a fee has to be paid for any TX. However, this sort of encryption would require unencrypted statement to be included in the TX indicating the fee to be paid to the miner. The latter could turn out to be difficult to implement.

About DDOS... Isn't it already possible to DDOS anyway? By spamming dust TXs, for example.

In a sense yes, but the TX can be analysed and blocked. E.g. core does not relay dust TX. An encrypted TX can not be checked. It could also be invalid entirely which would make the block its in invalid as well.

[Hyena]

In a sense yes, but the TX can be analysed and blocked. E.g. core does not relay dust TX. An encrypted TX can not be checked. It could also be invalid entirely which would make the block its in invalid as well.

If an invalid TX gets confirmed then it should remain invalid without making the block invalid.

IMO miners should only care about the TX fee and confirm anything that is signed with a private key that holds unspent inputs. But there are other ways to implement such encryption. For example, the encrypted TX might require a reasonable amount of coins to be locked until the TX gets confirmed and the encryption key broadcast. If the TX turns out to be invalid then the locked funds would remain locked as a penalty for making an invalid TX.