I don't understand it well enough to give you an answer. *Paging Evan*

I do appreciate that you put time into thinking this through. I might have a read through the debate you linked to when I have some time.

the problem with anonycoin, he is dismissive even before he has really seen it, and even before knowing anything regarding the way it works,

its always good to have 3rd party to look things trough, but being desmissive before even knowing anything about this particular implementation thats more like trolling...

This is all ad hominem. Why not simply attack his argument if you believe it's unfounded?

There's a difference between bashing and commenting.

Everyone here is part of the community even if you deem them negative. Any shit can lead to good shit. Embrace it instead and stop the personal level shit. That just ruins for outsiders wanting to get in.

Here is the fix for the R9 290 mining.
Tested on BAMT 1.6, it worked.
You can put it in first post, or not.


I have sent a 30 Darkcoin Bounty to cryptogretzky by myself, for the bug finding.

If any-one want to pay me back a part of that bounty, here is my address to share the cost.
XavaNMidPmofBUt4RWLf6YHhNDUNA7TjY6

As I only have 3 r9 290 I'll make 3 month to recover that bounty with my increased hasrate, but I'll be in peace with this bug.






run "aticonfig --adapter=all --initial -f".

add these 4 lines intoetc/rc.local before exit 0


Just in case it's not already executable, run:


Enjoy, and sleep in peace now

the master node is still elected randomly, so no node will be default master everytime

Earlier in the development someone attacked DarkSend this way and broke it for a day or so. I ended up coming up with what I call collateral transactions. A collateral transaction is a transaction that is only sent to the master node and if broadcast will transfer money from the node in question to the master node.

The main problem is CoinJoin happens in 3 main stages:

1.) ACCEPTING INPUTS (inputs are the money I’m sending)
2.) ACCEPTING OUTPUTS (outputs are who I’m sending to)
3.) SIGN INPUTS (everyone signs their input separately then sends them)

In stage 2, what if someone fails to send their output?  
In stage 3, what if someone fails to sign?

So with blind signing (footnote 1) when a user adds an output, you know it’s one of your users but you don’t know which. So if a user fails to provide outputs, the whole session must restart and no one can be punished.

I've thought about multiple designs for DarkSend, many of which do have the issue you’re talking about:

Design A: Users provide inputs and collateral, then later will provide outputs. The master node must know which user didn’t provide the outputs to be able to charge him. If we use blind signing we can’t charge the bad actor fees.

Design B: Users provide inputs, outputs and collateral at once. In this case the master node knows who is sending money to who, but later it can tell who didn’t sign.

I’ve chosen to use design B (users will add inputs and outputs at the same time) because it’s the only design that can’t be attacked in the way you’re saying.

//Accepting inputs
1. User A provides (Input, txCollateral, Output1, Output2)
2. User B provides (Input, txCollateral, Output1, Output2)
3. User C provides (Input, txCollateral, Output1, Output2)

//Signing
1. User A provides (Input, txCollateral)
2. User B fails to provide to sign
3. User C provides (Input, txCollateral)

//Fees
1. User B is charged

So to be clear, the master must know who is sending money to who. But ONLY the master node will need to know this. Beyond that the blockchain is still anonymous, and master nodes can be decentralized among the users of the network.

(1) More about blind signing:
http://ojs.academypublisher.com/index.php/jnw/article/viewFile/0508921928/2053