You're over-complicating it. Just add an exception for transactions that confirm in the same block, allowing the second to be without mixin. Wallets should disregard the first output, the one spent with 0 mixin, in their mixin selection algorithm. Since unconfirmed outputs are excluded from that selection as well, problem solved.
Payee pays for payer
Gingeropolous posted this 9 years ago
This spawns off of the forbid mixin 0 thread.
As mentioned in that thread, a potential use case for keeping mixin 0's is to enable child pays for parent, which is a bitcoin trick that permits spending unspent outputs in order to increase the fees going to the miners to get something confirmed faster. I may understand it wrong, but I think it goes something like this.
Transaction 1 - 0.1 fee Bob sends Jane 2 btc
Jane doesn't like that its taking forever, so jane submits a transaction to the blockchain
Transaction 2 - Jane uses transaction 1 to send another 0.1 fee to the miners.
Now the miners will include these transactions because they will get a higher reward. I think something similar can be achieved in Monero without needing a mixin 0. We just modify how we think this type of thing should work.
So, when a transaction is created in Monero, a transaction ID is created - and this transaction ID is private to the sender and receiver of the money. So if the receiver doesn't get their money in a timely fashion, the sender can transmit (out of band, say via email) their transaction ID and go "yo, I submitted it, but I messed up and the fee isn't high enough". The receiver can then go "thats cool, I'll pay some more to get it quicker". They then submit a transaction to the network that includes that transaction ID (somehow, its in some data field) and some more mining fees. The mining protocol then sees "Ok, here's this low fee transaction, but this other transaction can only be included in the block if the low fee transaction is in the block".
Hrm. It might not be as clear cut as I'm framing it, but perhaps this will get some gears turning.
Allowing other transactions to mix with a mixin 0 transaction weakens the entire system right? So I don't believe we should keep them just for 1 use scenario, unless this scenario adds more of a benefit than the negative of weakening the whole privacy.
I'm sure something could be created specifically for child payment use. I think the viewkey could be expanded on, maybe use two separate types of viewkeys, each has their own function? idk....
> Allowing other transactions to mix with a mixin 0 transaction weakens the entire system right?
Not in this case. Both transactions would confirm in the same block. Wallets need only to disregard the output that was spend in a 0 mixin. They would never get used thus wouldn't harm the privacy of anyone.
This seems reasonable, however there are two issues.
One it that it isn't currently possible to spend an uncofirmed transction in Cryptonote at all. The second is that if it does become possible then people might have already used it as a mixin.
It would be possible of course to only allow spending unconfirmed transactions only in this particular manner, but I'm not sure that is a good idea.
Yeah, that was my point with this post - to start to come up with something that produces the same result - to let a second party push a transaction into a block by adding fees to it.