[ANN][DASH] Dash (dash.org) | First Self-Funding Self-Governing Crypto Currency

[humanitee]

X will always be less than 10DRK, therefore we need another input to bring it to 10DRK total. This way no one can tell who is receiving which inputs, thus cleaning them in the inverse way DarkSend works. Checkout my post above again, I modified it a bit.

Make sense?

If X1 is just some other change address that belongs to John then yes, I got it. I was expecting X + Y = 10 DRK, introducing X1 made it ten times more confusing for me.

[eltito]

So what happens in this scenario:

Jon wants to darksend n DRK from A -> C
He doesn't have enough in A to cover it
He does have enough in A + X (change from a previous transaction) to cover it
He has not yet received enough change from transactions for X + X1 = 10


Is address X somehow excluded or disallowed from usage until there is X + X1 + ..... = 10?

[Simcom]

John darksends 2 coins from A to C, gets 8 back as change on address X
Joe darksends 3 coins from E to G, gets 7 back as change on address W
Suzie darksends 3 coins from K to Q, gets 7 back as change on address S

Now, we make a pool with X+X1+W+W1+S+S1.

Pool total output == 30DRK

X+X1 = 10DRK
W+W1 = 10DRK
S+S1 = 10DRK

X will always be less than 10DRK, there for we need another input to bring it to 10DRK total. This way no one can tell who is receiving which inputs, thus cleaning them in the inverse way DarkSend works.

Make sense?

I'm not sure I understand.

John darksends 2 coins from A to C, gets 8 back as change on address X.
He then contributes 2 additional coins from another address in his wallet, address X1?

If that's how it works I'm not sure I get how this helps.  It just exposes the holder of address X1 as the person who darksent 2 coins to C.

I am probably misunderstanding where X1 S1 and W1 are coming from.

[eltito]

John darksends 2 coins from A to C, gets 8 back as change on address X
Joe darksends 3 coins from E to G, gets 7 back as change on address W
Suzie darksends 3 coins from K to Q, gets 7 back as change on address S

Now, we make a pool with X+X1+W+W1+S+S1.

Pool total output == 30DRK

X+X1 = 10DRK
W+W1 = 10DRK
S+S1 = 10DRK

X will always be less than 10DRK, there for we need another input to bring it to 10DRK total. This way no one can tell who is receiving which inputs, thus cleaning them in the inverse way DarkSend works.

Make sense?

I'm not sure I understand.

John darksends 2 coins from A to C, gets 8 back as change on address X.
He then contributes 2 additional coins from another address in his wallet, address D?

If that's how it works I'm not sure I get how this helps.  It just exposes the holder of address D as the person who darksent 2 coins to C.

I am probably misunderstanding where X1 S1 and W1 are coming from.

If I'm not mistaken, X1 would be John's change address from a subsequent darksend.  So all of John's change addresses are subsets of X (X1, X2, etc.).  When two or more of these total 10DRK, the 10DRK is sent to the change pool to be cleaned.

The block chain would only ever show denominations of 10 leaving or coming back in to John's wallet A (10 coins out for darksends, 10 coins in from the wallet the change pool sends to (if John so chose)).

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.

I'm still curious to know what would happen if John tried to send a DarkSend for more than he had in wallet A, but less than he had in wallets A + X, before his change wallets totaled out to 10+ DRK so they could be sent out for cleaning.

[chaeplin]

Hi

did someone successfully build and run the wallet on a i686 (=32 bit) linux ?

i build successfully, but then after start, the sync stops at block "blocks" : 45993,

2014-04-29 20:04:48 received block 00000000000b304562f734cdc04f201f9e0497188a26362f76b4642606ebbc70
2014-04-29 20:04:48 ERROR: AcceptBlock() : incorrect proof of work
2014-04-29 20:04:48 ERROR: ProcessBlock() : AcceptBlock FAILED

I have used the latest git source.

Please help, I would like to set up a p2pool node for DRK.
And no, I can not switch to x86_64, as I have other p2pools up and running at the moment on the same node.

DRK is the only one that does not work (at the moment).

thanks

cheers

Use this for temporary work around.

http://drk.poolhash.org/files_for_darkoin_block/blocks.tgz

Code:

:~/.darkcoin>  getconf LONG_BIT
32

darkcoind stop
cd ~/.darkcoin
wget http://drk.poolhash.org/files_for_darkoin_block/blocks.tgz
tar xfvz blocks.tgz
rm -rf blocks chainstate
mv home/user/.darkcoin/* .
darkcoind
darkcoind getinfo


{
    "version" : 90102,
    "protocolversion" : 70002,
    "walletversion" : 60000,
    "balance" : 0.00000000,
    "blocks" : 60001,
    "timeoffset" : 0,
    "connections" : 3,
    "proxy" : "",
    "difficulty" : 955.31190257,
    "testnet" : false,
    "keypoololdest" : 1398805858,
    "keypoolsize" : 101,
    "paytxfee" : 0.00000000,
    "mininput" : 0.00001000,
    "errors" : ""
}

2014-04-29 21:27:42 received block 00000000000cfe64fca7b5c3a8ad1ee39dd3f380aeb56027bc25e97904d2c99e
2014-04-29 21:27:42 Committing 9 changed transactions to coin database...
2014-04-29 21:27:42 SetBestChain: new best=00000000000cfe64fca7b5c3a8ad1ee39dd3f380aeb56027bc25e97904d2c99e  height=60001  log2_work=55.944516  tx=245698  date=2014-04-29 21:27:20 progress=0.999999
2014-04-29 21:27:42 ProcessBlock: ACCEPTED

[CryptoGuy]

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.

[philipmicklon]

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 is way beyond coinjoin. This would be cool, but its a lot more work.

You would effectively be doing a two-way exchange of coins with the masternode. I think counterparty has two-way exchange in their codebase, but its not a small feature to add. And if you did implement this, the exchange itself would be recorded in the blockchain.

SA would actually be sending 10 DRK to the masternode, not RA. You would need to make sure the didn't just keep the 10 DRK.

[coins101]

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 is way beyond coinjoin. This would be cool, but its a lot more work.

You would effectively be doing a two-way exchange of coins with the masternode. I think counterparty has two-way exchange in their codebase, but its not a small feature to add.

I don't think that masternodes have this kind of flexibility as yet. The 1000DRK is there as proof of service capability and election to the network. The wallet with the 1000DRK is not the necessarily the node orchestrating the darksend transactions, but paired to it for safety.

It would be nice to have a minimum of 1000DRK threshold for being a masternode and then nodes can participate in the way you describe.

[eltito]

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.

[humanitee]

John darksends 2 coins from A to C, gets 8 back as change on address X
Joe darksends 3 coins from E to G, gets 7 back as change on address W
Suzie darksends 3 coins from K to Q, gets 7 back as change on address S

Now, we make a pool with X+X1+W+W1+S+S1.

Pool total output == 30DRK

X+X1 = 10DRK
W+W1 = 10DRK
S+S1 = 10DRK

X will always be less than 10DRK, there for we need another input to bring it to 10DRK total. This way no one can tell who is receiving which inputs, thus cleaning them in the inverse way DarkSend works.

Make sense?

I'm not sure I understand.

John darksends 2 coins from A to C, gets 8 back as change on address X.
He then contributes 2 additional coins from another address in his wallet, address X1?

If that's how it works I'm not sure I get how this helps.  It just exposes the holder of address X1 as the person who darksent 2 coins to C.

I am probably misunderstanding where X1 S1 and W1 are coming from.

X1 wouldn't be linked to C because it'd be a CoinJoin transaction. If 1000 change addresses are input, who owned what? You wouldn't be exposed, as far as I can tell. With I2P only the master node would know.

[daddeo]

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.

[eltito]

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.

[CryptoGuy]

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?

[humanitee]

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.

[eltito]

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.

[philipmicklon]

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]

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...

[humanitee]

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.

[coins101]

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.

[eltito]

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...