Same here. This latest beta finally works for me.
I wonder why we're centralizing DarkSend... Why can't it be as equally distributed as the BlockChain? TOR chooses Rendezvous nodes for hidden services entirely at random, so no "MasterNode" can be identified...
I'm not opposed to a setup like that. Maybe that can be V2. I'd argue our system is still decentralized though, there will be many masternodes each doing mixing for a small time.
I realize it's not a black and white issue, I'm suggesting that it
be made into a black and white issue. Still testing, too...
I'd like DarkSend a lot more if it distributed the pool of darksends in the same way the memory pool currently distributes all sends. It's a good model for many reasons, why re-invent the wheel?
As it is, if one node is compromised or malicious, what stops it from hosing up darksend? Sure, that TX will fall out of the memory pool and eventually be not a sent transaction according to my client, but how about something that actively avoids the incident? Why shouldn't all clients hosting the full chain also be darksend nodes? For that matter, why is darksend optional? Why aren't all sends done in that manner automatically?
Surely there are many instances where a public record of a transaction is useful. I think if mainstream legitimate businesses ever want to accept DRK, it could be a good idea for transactions to be on the public ledger. I think darksend should be the default option though.
