Hi!
....
I means that an anonymity level of one specific tx doesn't depend on "forced mixin" flags in its outputs. This flag only influences future transactions.
Yes, it is. Generating subset of such transactions in blockchain poviding a way of to do guaranteed anonymous transfers.
......
Unlock_time is different from the issue we are talking about because forced mixin introduces additional dependency links between transactions: spendability depends on output availability in the blockchain:
- without forced mixin txes depend on each other with strict OUTPUT->INPUT links.
- with forced mixin txes additionally depend on each other with weak OUTPUT -> OUTPUT links.
Why can't you implement spendability verification before accepting tx to mempool?
Whether it makes sense to take unspendable tx into blockchain?
Unlock_time is different from the issue we are talking about because forced mixin introduces additional dependency links between transactions: spendability depends on output availability in the blockchain:
- without forced mixin txes depend on each other with strict OUTPUT->INPUT links.
- with forced mixin txes additionally depend on each other with weak OUTPUT -> OUTPUT links.
Why can't you implement spendability verification before accepting tx to mempool?
Whether it makes sense to take unspendable tx into blockchain?
You right about verification but you wrong about the place where it should be done - the problem of unspendable transaction is the wallet's problem, it is not problem of transaction pools or daemon in general. So additional verification and validation is planned to be done in wallet.
Another problem with validation in transaction in daemon: for example i'm going to generate some amount of transactions with subset of guaranteed outputs (and i'll need to do that in future) - i know that i'm gonna do hundreds transactions with different amounts, and first transactions in this flow may look like unspendable (because other transactions in this subset is not received yet), than this will cause rejection of such transactions and imposibility to generate this subset in blockchain with such restrictions that you suggesting.