Wow! Thank you for such an extended response!First of all, regardless of how exactly the winner is chosen or how often one is declared, I think we have to make sure what exactly we incentivize and how we can avoid incentiviztation of things we do not want (like more bloat).
I Think the expected return needs to be less than 1. So for every 1 DASH that averagely gets paid as a collateral while mixing, there needs to be less (max. the equal amount of) DASH in the winner pool.
That way, there would be no incentive to game the system, because you cannot win anything. Sure, you could still try your luck, but there other, more enjoying games in the crypto-space to do just that.
The problem would be that one had to track the mixing attempts that are eligible for potential collateral payment. Thats a lot harder than just looking at the transactions, yet I think it's necessary in order to not make the expected profit go above 1.
Regarding unlinkability... well, theres always something an output can be linked to, and often that completely irrelevant for anonymity. I think the important thing is that the funds cannot be traced back to the original source, which I generally refer to as traceability. Maybe we mean the same thing though
I am going to assume the algorithm used for the lottery cannot trace coins through multiple DS rounds (because that would break DS in itself).
So we'll have to look at every output and determine for it separately if it is eligible for the jackpot or not. The winner will get the funds to the corresponding address.
That address is now containing the DS denomination and the lottery reward. If this was the last DS-round, the DS denom will remain there in order to eventually be spend and so does the lottery reward.
This can lead to problems if the lottery reward is spend somewhere for shopping (it cannot be used in a DS Tx anyway before mixing), while the DS denom is used somewhere else via Darksend.
Now my first idea was to reset the DS dounds of the denomination in question and just do some additional rounds. While this would work if the reward was already paid, in this proposal, the reward isn't paid right away. Say the DS denom has already been used and now the lottery reward gets paid and the user uses it for shopping, then whatever info he enters at wherever he is shoping is linked to the DS Tx he did BEFORE the reward was paid.
This, btw, is also an attack that can be used to de-anonymize DS Transactions. I explain:
Person A uses mixed coins to pay for something. The receiver of the Coins, Person B (or anyone else observing the Tx)B now sends an amount X to one of the input addresses of the DS-Tx in question.
Person A receives those funds as non-DS funds and in case he doesnt mix again but just use it somewhere, person B can now trade the Coins of which he knows they belong to the same person that made the DS-Tx in question.
And since the thread currently seems to be all about faster mixing, I got several proposals that might speed things up:
First of all, we take so much effort splitting our coins into different denominations and mix them just to eventually recombine them for a payment. But why? Technically, we do not have to recombine them for a payment.
For the DS Transaction, instead of just sending a single receiving address, the receiver could send a unlimited amount of addresses of the form of a public key seed similar to what hierarchical deterministic wallets use for watch-only copies that do not have any private keys or seeds thereof, but can calculate any amount of receiving addresses to which the private keys can be generated by the same private seed.
For now, i will call this an "HDPS", Hierarchical Deterministic Payment Stream.
How this would work in practice:
The receiver sends the sender the required payment information, which the sender enters into the client and then sends the money (via DS Tx). The difference is that instead of sending a receiving address, and HDPS public seed is sent (which will look similar to an address, a bunch of seemingly random numbers and letters).
Just as with addresses, the receiver would have the corresponding HDPS private seed, which can create all the private keys associated with all the addresses that are generated from all the public keys generated by the public seed.
The pros of this:
- the seeds would never show up on the blockchain
- an outside observer could, in most cases, not tell if this is a mixing round or a Payment, which makes tracing even harder
- the client could be programmed to make it even harder to tell the difference between Payment Tx or DS Tx pretty easily, making is almost always impossible to tell the difference.
- DS denominations won't have to be recombined in order to do a payment
- when mixing the incoming funds, no initial denomination creation transaction is required (therefore reducing bloat)
- there wouldn't be any leftovers when when starting the mixing process with HDPS-received funds
- the overpayment that is common with DS Transactions would go to the receiver instead of the miners. This is good because if incentivizes DASH acceptance (you will almost always get a little extra) [I admit this is not a huge pro, just listing it]
The cons:
I honestly don't see any besides the work required to implement it.
So how can this speed up DS mixing?
Well, it's possible to use HDPS' in an actual DS Tx, combining the 2. This would make is impossible for an outside observer to sell which funds are being mixed and which funds and being used for a payment in that one Tx.
It would provide extra liquidity for mixing and extra traceability protection for payments.
And I got another one... with HDPS making in unnecessary to every have non-denominated outputs and it being basically a big sea of denominations, one could mix coins with itself. Just imaging you make several denominations and a few are mixing at a time. So instead of always doing it via a masternode, the client could sometimes just throw in an extra round with a few of ones own coins. No other people needed, once your own coins are reasonably mixed, mixing them just with themselves wont look any different than an actual mixing round. The difference being that it takes close to no time to do it.
If you want to do 8 rounds and do 2 self-mixing rounds and 6 normal ones, thats already an about 25% speed increase. With only a single one thats already an around 12,5% increase.
Alright, this got longer than expected... again
Oh, and sorry for not having been that active in the DASH community within the last few months.
Regarding HDPS: sounds a lot like https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki + denominations if I got you idea, right?
