Topic: [ANN][DASH] Dash (dash.org) | First Self-Funding Self-Governing Crypto Currency - page 6158. (Read 9724097 times)

Quote from: eduffield on April 29, 2014, 01:33:59 PM

Wallets X, X1, etc. aren't associated in any way to wallet A. Nor can input and output amounts be matched - unless someone gains physical access to the machine where John keeps his wallet, I suppose.

This got me thinking:

What prevents wallets A, X, X1 from being associated by IP address? There's no association on the block chain, but IP association is just as bad...

I2P.

Need to get smart on this I guess - I've never heard of it :p. Is that something that will be built into the client or is it a separate protocol (like tor) that will need to be set up?

If separate, that's something that needs to be made clear with like a flashing neon sign...

I think the I2P stuff is run on the masternodes, it will be built into darkcoind I assume, regular clients don't need to know anything about it or set anything up.

coins101

legendary

Activity: 1456

Merit: 1000

Quote from: Simcom on April 29, 2014, 11:57:55 AM

I spent a fair amount of time thinking about the discussion with dime, humanitee, luigi1111, camosoul and others yesterday about the anonymity of Darksend. I suspected that the logic behind darksend as currently implemented was not sound, and I thought it would be best to determine how exactly darksend was working, and do an in-depth analysis of a mixing cycle and the transactions that follow mixing.

...

Best,
Sim

Wow! This is great. About 400+ pages ago I talked about having a different kind of pool for change outputs only. Put in all of your change outputs and you'll get new fresh clean inputs of 10DRK. The client could automatically do this after each darksend, which would also get you new inputs for the next round.

I'm currently embedded in patching stratum and p2pool to support the masternode payments, which is why I haven't been around. It takes a lot of work to make something so different from anything else out there, dare I say, revolutionary?

It just occurred to me, I'm a bit slow, that having to patch the supporting infrastructure to make DarkSend work is genius - it will limit the number of potential clones.

They would be breaking their infrastructure every two minutes, no one would bother mining.

humanitee

hero member

Activity: 1302

Merit: 502

Quote from: eltito on April 29, 2014, 05:29:57 PM

Quote from: humanitee on April 29, 2014, 05:26:31 PM

Quote from: eduffield on April 28, 2014, 07:56:11 AM

Wallets X, X1, etc. aren't associated in any way to wallet A. Nor can input and output amounts be matched - unless someone gains physical access to the machine where John keeps his wallet, I suppose.

This got me thinking:

What prevents wallets A, X, X1 from being associated by IP address? There's no association on the block chain, but IP association is just as bad...

I2P.

Need to get smart on this I guess - I've never heard of it :p. Is that something that will be built into the client or is it a separate protocol (like tor) that will need to be set up?

If separate, that's something that needs to be made clear with like a flashing neon sign...

I think I have a better solution than that, I want to turn the masternodes into I2P relays for darkcoin. So your client will pick one when you start, then relay any messages through that one. It encrypts all of the traffic, removes the connection between IP and address and it the blockchain is still a complete fog. Plus it'll be a private I2P, so it'll be super fast. Masternodes are going to be awesome Grin

There's the quote about it.

Pretty great anonymity could also be obtained by sending the broadcast 4+ peers away from you. Encrypt the packets and you'd be good.

GhostPlayer

legendary

Activity: 1092

Merit: 1000

how come I've never seen these Darkcoin videos!?

http://blog.coinium.org/announcements/darkcoin/new-pool-darkcoin/

daddeo

full member

Activity: 129

Merit: 100

Quote from: coins101 on April 29, 2014, 05:27:46 PM

Quote from: daddeo on April 29, 2014, 05:13:59 PM

Quote from: CryptoGuy on April 29, 2014, 04:37:43 PM

I feel my last post may have been confusing so I’ll try to explain it better.

Sender A (SA) sends 8DRK to Receiver A (RA)

The masternode takes the 10DRK from SA and parks it, none of those coins will be used in the rest of the transaction.

The masternode from its 1000DRK balance takes 8DRK and sends to RA and 2DRK to SA as the change.

The original 10DRK from SA will be used at a later date to fulfill someone else’s transaction.

This way the change SA gets back isn’t even part of the original transaction of 10DRK. There’s no worry about tainting your next transactions with the change from previous transactions. If it’s done this way none of the coins can technically be tracked back to the original sender because they stopped for a layover on the masternode for X number of blocks before being used again. So you have separation of not only the addresses but it will appear that the coins sat in another wallet for a period of time before being spent again. Please correct me if I’m wrong about this, I’m trying to comprehend DarkSend as well.

The coins in the masternodes aren't used for mixing. 1000 coins is way too small an amount for something like that. As I understand it the coins coming in from other clients form the mixing pool.

Perhaps the master nodes or some kind of "exchange" node could be used in the mixing process at least in the beginning. I'm finding it hard to believe that the mixing pools will have enough collateral early on to make speedy transactions.

DarkSend is the default for all transactions. You have to opt-out of DarkSend to use regular Darkcoin with an ordinary block chain.

Understood. But a tx could still take a long time in the early stages of adoption if the pools are waiting for similarly sized inputs to mix with.

eltito

full member

Activity: 322

Merit: 105

Quote from: humanitee on April 29, 2014, 05:26:31 PM

Quote from: daddeo on April 29, 2014, 05:13:59 PM

Wallets X, X1, etc. aren't associated in any way to wallet A. Nor can input and output amounts be matched - unless someone gains physical access to the machine where John keeps his wallet, I suppose.

This got me thinking:

What prevents wallets A, X, X1 from being associated by IP address? There's no association on the block chain, but IP association is just as bad...

I2P.

Need to get smart on this I guess - I've never heard of it :p. Is that something that will be built into the client or is it a separate protocol (like tor) that will need to be set up?

If separate, that's something that needs to be made clear with like a flashing neon sign...

coins101

legendary

Activity: 1456

Merit: 1000

Quote from: CryptoGuy on April 29, 2014, 04:37:43 PM

I feel my last post may have been confusing so I’ll try to explain it better.

Sender A (SA) sends 8DRK to Receiver A (RA)

The masternode takes the 10DRK from SA and parks it, none of those coins will be used in the rest of the transaction.

The masternode from its 1000DRK balance takes 8DRK and sends to RA and 2DRK to SA as the change.

The original 10DRK from SA will be used at a later date to fulfill someone else’s transaction.

This way the change SA gets back isn’t even part of the original transaction of 10DRK. There’s no worry about tainting your next transactions with the change from previous transactions. If it’s done this way none of the coins can technically be tracked back to the original sender because they stopped for a layover on the masternode for X number of blocks before being used again. So you have separation of not only the addresses but it will appear that the coins sat in another wallet for a period of time before being spent again. Please correct me if I’m wrong about this, I’m trying to comprehend DarkSend as well.

The coins in the masternodes aren't used for mixing. 1000 coins is way too small an amount for something like that. As I understand it the coins coming in from other clients form the mixing pool.

Perhaps the master nodes or some kind of "exchange" node could be used in the mixing process at least in the beginning. I'm finding it hard to believe that the mixing pools will have enough collateral early on to make speedy transactions.

DarkSend is the default for all transactions. You have to opt-out of DarkSend to use regular Darkcoin with an ordinary block chain.

humanitee

hero member

Activity: 1302

Merit: 502

Wallets X, X1, etc. aren't associated in any way to wallet A. Nor can input and output amounts be matched - unless someone gains physical access to the machine where John keeps his wallet, I suppose.

This got me thinking:

What prevents wallets A, X, X1 from being associated by IP address? There's no association on the block chain, but IP association is just as bad...

I2P.

eltito

full member

Activity: 322

Merit: 105

Quote from: humanitee on April 29, 2014, 05:17:54 PM

Wallets X, X1, etc. aren't associated in any way to wallet A. Nor can input and output amounts be matched - unless someone gains physical access to the machine where John keeps his wallet, I suppose.

This got me thinking:

What prevents wallets A, X, X1 from being associated by IP address? There's no association on the block chain, but IP association is just as bad...

philipmicklon

full member

Activity: 176

Merit: 100

Quote from: CryptoGuy on April 29, 2014, 04:37:43 PM

I feel my last post may have been confusing so I’ll try to explain it better.

Sender A (SA) sends 8DRK to Receiver A (RA)

The masternode takes the 10DRK from SA and parks it, none of those coins will be used in the rest of the transaction.

The masternode from its 1000DRK balance takes 8DRK and sends to RA and 2DRK to SA as the change.

The original 10DRK from SA will be used at a later date to fulfill someone else’s transaction.

This way the change SA gets back isn’t even part of the original transaction of 10DRK. There’s no worry about tainting your next transactions with the change from previous transactions. If it’s done this way none of the coins can technically be tracked back to the original sender because they stopped for a layover on the masternode for X number of blocks before being used again. So you have separation of not only the addresses but it will appear that the coins sat in another wallet for a period of time before being spent again. Please correct me if I’m wrong about this, I’m trying to comprehend DarkSend as well.

This idea sucks for the same reason my stealth DarkSend idea ended up sucking, you have to have the private keys online. Master nodes would then have to have the DRK on the node, with the private keys in memory.

Yeah, it would be better to provably burn all inputs and issue new coins than to mix them with the masternode's coins.

eltito

full member

Activity: 322

Merit: 105

Quote from: CryptoGuy on April 29, 2014, 05:16:43 PM

Quote from: CryptoGuy on April 29, 2014, 04:37:43 PM

I feel my last post may have been confusing so I’ll try to explain it better.

Sender A (SA) sends 8DRK to Receiver A (RA)

The masternode takes the 10DRK from SA and parks it, none of those coins will be used in the rest of the transaction.

The masternode from its 1000DRK balance takes 8DRK and sends to RA and 2DRK to SA as the change.

The original 10DRK from SA will be used at a later date to fulfill someone else’s transaction.

This way the change SA gets back isn’t even part of the original transaction of 10DRK. There’s no worry about tainting your next transactions with the change from previous transactions. If it’s done this way none of the coins can technically be tracked back to the original sender because they stopped for a layover on the masternode for X number of blocks before being used again. So you have separation of not only the addresses but it will appear that the coins sat in another wallet for a period of time before being spent again. Please correct me if I’m wrong about this, I’m trying to comprehend DarkSend as well.

The coins in the masternodes aren't used for mixing. 1000 coins is way too small an amount for something like that. As I understand it the coins coming in from other clients form the mixing pool.

Either way the change sent back to the original sender should never be coins that have come from their wallet in previous transactions. I don't see the big deal in having the requirement of masternodes having a certain amount of coins at any given time. Maybe make it a preference system, your transaction goes to the closest node that matches your transaction value (1/10/100/1000/etc) with the most coins on hand. This would give incentive for the masternode operators to not just dump their coins as well.

Thoughts?

So what happens when I want to darksend 501 coins? Or >50% of whatever the masternode is holding.

humanitee

hero member

Activity: 1302

Merit: 502

Quote from: CryptoGuy on April 29, 2014, 04:37:43 PM

I feel my last post may have been confusing so I’ll try to explain it better.

Sender A (SA) sends 8DRK to Receiver A (RA)

The masternode takes the 10DRK from SA and parks it, none of those coins will be used in the rest of the transaction.

The masternode from its 1000DRK balance takes 8DRK and sends to RA and 2DRK to SA as the change.

The original 10DRK from SA will be used at a later date to fulfill someone else’s transaction.

This way the change SA gets back isn’t even part of the original transaction of 10DRK. There’s no worry about tainting your next transactions with the change from previous transactions. If it’s done this way none of the coins can technically be tracked back to the original sender because they stopped for a layover on the masternode for X number of blocks before being used again. So you have separation of not only the addresses but it will appear that the coins sat in another wallet for a period of time before being spent again. Please correct me if I’m wrong about this, I’m trying to comprehend DarkSend as well.

This idea sucks for the same reason my stealth DarkSend idea ended up sucking, you have to have the private keys online. Master nodes would then have to have the DRK on the node, with the private keys in memory.

CryptoGuy

hero member

Activity: 524

Merit: 500

Quote from: CryptoGuy on April 29, 2014, 04:37:43 PM

I feel my last post may have been confusing so I’ll try to explain it better.

Sender A (SA) sends 8DRK to Receiver A (RA)

The masternode takes the 10DRK from SA and parks it, none of those coins will be used in the rest of the transaction.

The masternode from its 1000DRK balance takes 8DRK and sends to RA and 2DRK to SA as the change.

The original 10DRK from SA will be used at a later date to fulfill someone else’s transaction.

This way the change SA gets back isn’t even part of the original transaction of 10DRK. There’s no worry about tainting your next transactions with the change from previous transactions. If it’s done this way none of the coins can technically be tracked back to the original sender because they stopped for a layover on the masternode for X number of blocks before being used again. So you have separation of not only the addresses but it will appear that the coins sat in another wallet for a period of time before being spent again. Please correct me if I’m wrong about this, I’m trying to comprehend DarkSend as well.

The coins in the masternodes aren't used for mixing. 1000 coins is way too small an amount for something like that. As I understand it the coins coming in from other clients form the mixing pool.

Either way the change sent back to the original sender should never be coins that have come from their wallet in previous transactions. I don't see the big deal in having the requirement of masternodes having a certain amount of coins at any given time. Maybe make it a preference system, your transaction goes to the closest node that matches your transaction value (1/10/100/1000/etc) with the most coins on hand. This would give incentive for the masternode operators to not just dump their coins as well.

Thoughts?

eltito

full member

Activity: 322

Merit: 105

Quote from: daddeo on April 29, 2014, 05:13:59 PM

Quote from: CryptoGuy on April 29, 2014, 04:37:43 PM

I feel my last post may have been confusing so I’ll try to explain it better.

Sender A (SA) sends 8DRK to Receiver A (RA)

The masternode takes the 10DRK from SA and parks it, none of those coins will be used in the rest of the transaction.

The masternode from its 1000DRK balance takes 8DRK and sends to RA and 2DRK to SA as the change.

The original 10DRK from SA will be used at a later date to fulfill someone else’s transaction.

This way the change SA gets back isn’t even part of the original transaction of 10DRK. There’s no worry about tainting your next transactions with the change from previous transactions. If it’s done this way none of the coins can technically be tracked back to the original sender because they stopped for a layover on the masternode for X number of blocks before being used again. So you have separation of not only the addresses but it will appear that the coins sat in another wallet for a period of time before being spent again. Please correct me if I’m wrong about this, I’m trying to comprehend DarkSend as well.

The coins in the masternodes aren't used for mixing. 1000 coins is way too small an amount for something like that. As I understand it the coins coming in from other clients form the mixing pool.

Perhaps the master nodes or some kind of "exchange" node could be used in the mixing process at least in the beginning. I'm finding it hard to believe that the mixing pools will have enough collateral early on to make speedy transactions.

I was just thinking the same thing. Chicken and egg problem.

daddeo

full member

Activity: 129

Merit: 100