Quote from: Kai Proctor on June 24, 2014, 12:45:34 AM

Quote from: pbremen01 on June 24, 2014, 12:34:13 AM

Quote from: Kai Proctor on June 24, 2014, 12:17:03 AM

Quote from: pbremen01 on June 23, 2014, 11:58:56 PM

One technical question about DarkSend.

Let's say that I have 110 DRK in one address and I want to pay 30 DRK to another user using DarkSend.

DarkSend does something called "denomination". What does this mean? That it will send first 100 DRK to another address and then include these 100 DRK in DarkSend pool from this address?

Is this just this one transaction (in this example) or maybe denomination does also something else so that the original address (with 110 DRK at the beginning) is somehow obfuscated?

Thanks.

Quote

Recap of How DarkSend Works

DarkSend functions in a way that is very similar to a tumbler, which is an idea that has been around for quite a while, but with a few specifications that increase the effectiveness. It has went through multiple changes and updates, but the most recent release, release candidate 2 (RC2), is nearing complete anonymity.

When a user, lets call him Tim, sends darkcoins through DarkSend to another user, lets call her Sandy, he must send 10 darkcoins, even if that amount is larger than what he would like to pay her. DarkSend then puts his coins in a pool, and pauses until two additional users initiate transactions. These new users will add their own 10 darkcoins to the pool, and DarkSend blends the 30 coins into a random assortment. If we assume that Tim wanted to send Sandy 8 darkcoins, then at this point 8 darkcoins would be deposited into Sandys wallet, but those 8 coins would be a mix of coins from all 3 users that had initiated transactions. Tims remaining 2 coins are placed into a Random Pool Address (RPA) which was created during the transaction. This RPA is not tied to any user, thus it is impossible to connect to a specific user, but Tim can access it.

This process is happening for the other 2 users that sent 10 darkcoins through DarkSend as well, so at the end, it is impossible to determine which transaction was related to a specific user. To an outside observer, 3 users put 30 darkcoins in, and 3 6 addresses receive coins out (3 if each user intended to send a full 10 darkcoins, up to 6 if each user intended to send less than 10 darkcoins).

Source : http://coinbrief.net/darkcoin-darksend-bitcoin/

Some additional (more recent) informations :

Quote from: eduffield on June 01, 2014, 03:34:08 PM

Quote from: R160K on May 27, 2014, 05:39:17 PM

[...]

Thanks for the questions. It does seem like you're missing something. Although, it might not be your fault. The whitepaper is definitely out of date. We've done a lot of work at tweaking the trust model so that it can't be exploited. I'll try to explain how it works briefly, then hopefully if I get time I can revisit the whitepaper soon.

- Masternodes don't have any power over the transactions. They just coordinate the signing. All parties must sign in order for the transaction to be valid. So there's no way to cheat and take the money.
- Users submit collateral. At a later phase if a user doesn't provide the signature as agreed, the transaction will fail. Without colateral this could be done over and over bringing the system to a halt.
- Masternodes have the ability to take the collateral transaction if they wish, but it's paid to the bounty fund. So it doesn't benefit them, it just benefits the community. This removed the incentive to cheat and take the money.

There's no relying on pools at all anymore. Payments to masternodes are done with a voting system embedded into the blockchain. It would take 51% of the mining power to pay the wrong masternode, or another party (because the last few miners to solve blocks must agree on who should be paid)

Transaction currently require 3 parties to be created, so there's a short wait. There are no fake transactions to make that quicker, although this could be done. There's usually 5 or so transaction per 2.5 minutes, so the network should be able to function pretty efficiently under these requirements.

Hoping that helps . Thanks,

Evan

Ok, thanks, but I don't see any "denomination" happening in these examples?

The amount sent, depending on its value, go thru a pool of 10, 100, 1000 etc. DRK.

It's worth mentioning that Evan decided to scrap denominated pools because of various issues (needing more coins than you want to send, "dirty" addresses that result from the splitting off of a denominated amount, etc). The plan is to allow inputs of any size into a single pool (with a minimum resolution of .1 DRK), the change addresses will be denominated and sent back to several different addresses. Denominated change addresses will come in RC4, pool size change will happen in either RC4 or maybe later, not sure.