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

[humanitee]

Not at all. Check my edit as well.

DRK sends information back to your computer when it's done combining the transactions, and you sign the giant transaction it makes with your private key.

It appears to be different in more ways than that, but since I can't fully grasp CLOAK I'm not going to bother typing it out.

Hmm ok I just thought it went from one MasterNode to another and then out. Looks like I have some reading to do. Thanks for the discussion guys!

In a completely generalized explanation, that is more or less correct. But the nodes never have control of your coins, they can't redeem the inputs.

Steps:
1) You and everyone else sends amounts to masternode 1, along with randomly generated change addresses.
2) Masternode 1 denominates to those addresses, with the help of your client (your client says something like "I need 10 DRK, 5 DRK, and (3) 1 DRK to send 18 DRK")
3) Then those outputs get sent to masternode 2 with the addresses where these coins are destined (where you and everyone else are sending them).
4) Then masternode 2 combines them all into 1 transaction, asks each individual user to use their private keys to sign the transaction, and then the transaction is broadcast.

By signing they of course do not give away their private keys, they merely prove that they own those coins.

[rygamble]

Not at all. Check my edit as well.

DRK sends information back to your computer when it's done combining the transactions, and you sign the giant transaction it makes with your private key.

It appears to be different in more ways than that, but since I can't fully grasp CLOAK I'm not going to bother typing it out.

Hmm ok I just thought it went from one MasterNode to another and then out. Looks like I have some reading to do. Thanks for the discussion guys!

In a completely generalized explanation, that is more or less correct. But the nodes never have control of your coins, they can't redeem the inputs.

Steps:
1) You and everyone else sends amounts to masternode 1, along with randomly generated change addresses.
2) Masternode 1 denominates to those addresses, with the help of your client (your client says something like "I need 10 DRK, 5 DRK, and (3) 1 DRK to send 18 DRK")
3) Then those outputs get sent to masternode 2 with the addresses where these coins are destined (where you and everyone else are sending them).
4) Then masternode 2 combines them all into 1 transaction, asks each individual user to use their private keys to sign the transaction, and then the transaction is broadcast.

Thanks for the simple explanation. I might just have to throw some money back on the DRK train once Cloak has calmed down a bit. Who knows, I might even make enough from Cloak to buy up a MasterNode

[slapper]

MNs can always transition into other VPS providers and solutions.

The authorities are going to go after the staking wallets for trying to make rogue purchases like they did to bittorrent users. Some coins will have to think of shrink raps.

/only half serious here. Making fun at how every single anon wannabes come here on DRK thread. Not directed at any individual.

[eltito]

Not at all. Check my edit as well.

DRK sends information back to your computer when it's done combining the transactions, and you sign the giant transaction it makes with your private key.

It appears to be different in more ways than that, but since I can't fully grasp CLOAK I'm not going to bother typing it out.

Hmm ok I just thought it went from one MasterNode to another and then out. Looks like I have some reading to do. Thanks for the discussion guys!

In a completely generalized explanation, that is more or less correct. But the nodes never have control of your coins, they can't redeem the inputs.

Steps:
1) You and everyone else sends amounts to masternode 1, along with randomly generated change addresses.
2) Masternode 1 denominates to those addresses, with the help of your client (your client says something like "I need 10 DRK, 5 DRK, and (3) 1 DRK to send 18 DRK")
3) Then those outputs get sent to masternode 2 with the addresses where these coins are destined (where you and everyone else are sending them).
4) Then masternode 2 combines them all into 1 transaction, asks each individual user to use their private keys to sign the transaction, and then the transaction is broadcast.

By signing they of course do not give away their private keys, they merely prove that they own those coins.

To clarify: the client never tells MN1 exactly how much it wants to ultimately send.  Your client sends MN1 some higher amount and says "Here's a bunch of DRK, send it back to me in smaller denominations".  Then the actual send amount (from random addresses, not tied to your primary address) is sent on to MN2 for delivery to the intended recipient.

[humanitee]

To clarify: the client never tells MN1 exactly how much it wants to ultimately send.  Your client sends MN1 some higher amount and says "Here's a bunch of DRK, send it back to me in smaller denominations".  Then the actual send amount (from random addresses, not tied to your primary address) is sent on to MN2 for delivery to the intended recipient.

Thanks for the correction.   

[slapper]

Not at all. Check my edit as well.

DRK sends information back to your computer when it's done combining the transactions, and you sign the giant transaction it makes with your private key.

It appears to be different in more ways than that, but since I can't fully grasp CLOAK I'm not going to bother typing it out.

Hmm ok I just thought it went from one MasterNode to another and then out. Looks like I have some reading to do. Thanks for the discussion guys!

In a completely generalized explanation, that is more or less correct. But the nodes never have control of your coins, they can't redeem the inputs.

Steps:
1) You and everyone else sends amounts to masternode 1, along with randomly generated change addresses.
2) Masternode 1 denominates to those addresses, with the help of your client (your client says something like "I need 10 DRK, 5 DRK, and (3) 1 DRK to send 18 DRK")
3) Then those outputs get sent to masternode 2 with the addresses where these coins are destined (where you and everyone else are sending them).
4) Then masternode 2 combines them all into 1 transaction, asks each individual user to use their private keys to sign the transaction, and then the transaction is broadcast.

By signing they of course do not give away their private keys, they merely prove that they own those coins.

To clarify: the client never tells MN1 exactly how much it wants to ultimately send.  Your client sends MN1 some higher amount and says "Here's a bunch of DRK, send it back to me in smaller denominations".  Then the actual send amount (from random addresses, not tied to your primary address) is sent on to MN2 for delivery to the intended recipient.

And a serious question to Evan.

Would it be possible to extend the # of participating MNs via a configurable user option to enhance anonymity past Ring Sig levels?

MN = 0 ; Normal Transaction
MN = 1 ; Current mode
MN = 2 ; Darksend+
MN = 3 ; Darksend++
MN = 4 ; Good luck NSA
MN = 5 ; OKTHXBAI

Are we concerned about bloat in this case? Too complicated for average Joe to use in GUI?

[eltito]

Not at all. Check my edit as well.

DRK sends information back to your computer when it's done combining the transactions, and you sign the giant transaction it makes with your private key.

It appears to be different in more ways than that, but since I can't fully grasp CLOAK I'm not going to bother typing it out.

Hmm ok I just thought it went from one MasterNode to another and then out. Looks like I have some reading to do. Thanks for the discussion guys!

In a completely generalized explanation, that is more or less correct. But the nodes never have control of your coins, they can't redeem the inputs.

Steps:
1) You and everyone else sends amounts to masternode 1, along with randomly generated change addresses.
2) Masternode 1 denominates to those addresses, with the help of your client (your client says something like "I need 10 DRK, 5 DRK, and (3) 1 DRK to send 18 DRK")
3) Then those outputs get sent to masternode 2 with the addresses where these coins are destined (where you and everyone else are sending them).
4) Then masternode 2 combines them all into 1 transaction, asks each individual user to use their private keys to sign the transaction, and then the transaction is broadcast.

By signing they of course do not give away their private keys, they merely prove that they own those coins.

To clarify: the client never tells MN1 exactly how much it wants to ultimately send.  Your client sends MN1 some higher amount and says "Here's a bunch of DRK, send it back to me in smaller denominations".  Then the actual send amount (from random addresses, not tied to your primary address) is sent on to MN2 for delivery to the intended recipient.

And a serious question to Evan.

Would it be possible to extend the # of participating MNs via a configurable user option to enhance anonymity past Ring Sig levels?

MN = 0 ; Normal Transaction
MN = 1 ; Current mode
MN = 2 ; Darksend+
MN = 3 ; Darksend++
MN = 4 ; Good luck NSA
MN = 5 ; OKTHXBAI

Are we concerned about bloat in this case? Too complicated for average Joe to use in GUI?

Yes it's possible.  No, the way he would do it wouldn't cause a lot of bloat.  Nor would it complicate the UI.

[coins101]

https://darkcointalk.org/threads/development-updates-july-7th.1735/





Darksend+

Bump

What does BUMP mean? is it code for, Bump?

[Kai Proctor]

But you can't tell us how PoSa works?

I can't answer that specific question because PoSA hasn't been released to the public yet. Feel free to browse the white paper though.

From the whitepaper:
"As part of the stake mining process, the elected node will process the special transaction package from
its memory pool. The anonymization system is a two-pass process flow. If the elected node is
processing Phase 1, it will solve the block and the output will be assigned to an internal address at the
node. The node will earn a fee for this service, and then redeem the input by recursing back to the
election process, to elect a node for Phase 2. The node then constructs an anonymizing transaction
package and broadcasts it to the elected Phase 2 node.
Again in the Phase 2 pass the originator and recipient are not recorded, instead the transaction occurs
between the Phase 1 and Phase 2 nodes."

This is my interpretation:
"As part of the stake mining process, the elected node will process all the transactions that have been sent to it, which are stored in memory (duh). The system uses two passes through two separate nodes. If the elected node is processing Phase 1, it will solve the block and something will be given to the node."

Here I get extremely confused. What is being returned to the node? Since coins are not being destroyed, it appears that it is just staking rewards. This is what it appears to say next:
"This money that is given to the node, on an address in only its control, this is more or less the user's funds. The node is then given a reward for it's service (from somewhere). The user's funds are then sent to another node which does the process again."

Sounds trusted to me.

I mean it's pretty much the same way DarkCoin uses MasterNodes right? Except Cloak uses staking wallets instead?

Not at all. Check my edit as well.

DRK sends information back to your computer when it's done combining the transactions, and you sign the giant transaction it makes with your private key.

It appears to be different in more ways than that, but since I can't fully grasp CLOAK I'm not going to bother typing it out.

Hmm ok I just thought it went from one MasterNode to another and then out. Looks like I have some reading to do. Thanks for the discussion guys!

[...]

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

[coins101]

1. DRK's CoinJoin implementation is much better than a regular CoinJoin transaction. Coming in RC4 is a split masternode system, where 2 masternodes are selected and then one splits your transaction amount into denominated units (1 DRK, 5 DRK, 10 DRK, and so on) before you send it to the other one for the actual transaction. No timing analysis can be done on the blockchain to see who denominated at any point in time. The only weakness is that if you own both masternodes, you can trace the payments because you are seeing realtime what clients belong to denominationed units and where those units end up. At some point we are getting IP obfuscation, as well as I2P.

If you can string two master nodes together, you can string any number together. There is a minimum of two involved. 

Now that really rocks.

[humanitee]

If you can string two master nodes together, you can string any number together. There is a minimum of two involved.  

Now that really rocks.

But why not just do multiple DarkSends? Seems redundant to me since you must always have the coin owners sign the transactions. I probably haven't thought about it enough (is 10 minutes enough? lol) but I can't see a benefit to it.

[slapper]

And a serious question to Evan.

Would it be possible to extend the # of participating MNs via a configurable user option to enhance anonymity past Ring Sig levels?

MN = 0 ; Normal Transaction
MN = 1 ; Current mode
MN = 2 ; Darksend+
MN = 3 ; Darksend++
MN = 4 ; Good luck NSA
MN = 5 ; OKTHXBAI

Are we concerned about bloat in this case? Too complicated for average Joe to use in GUI?

Yes it's possible.  No, the way he would do it wouldn't cause a lot of bloat.  Nor would it complicate the UI.

WOW! Sorry if this was supposed to come as an announcement later as we have not seen anonymity "levels" configurable option discussed before, but thanks for the reply. That changes everything as far as transaction obfuscation was compared to CN/Ring Sigs. I think I do remember however that Evan decided to stay away from a Ring Sig port, must have been due to bloating concerns.

 

[hartvercoint]

If you can string two master nodes together, you can string any number together. There is a minimum of two involved.  

Now that really rocks.

But why not just do multiple DarkSends? Seems redundant to me since you must always have the coin owners sign the transactions. I probably haven't thought about it enough (is 10 minutes enough? lol) but I can't see a benefit to it.

One node knows the source of coins, one knows the destination, but neither knows both.

[TanteStefana2]

Funny Fud

LOL, seriously?  What kind of question is that?

[coins101]

finding nemo part 2

Code:

01.nicehash3336.sh
02.nicehash4336.sh
03.x11multipoolco3333.sh
04.x11gzltc1btccom8888.sh
05.x11bjltc1btccom8888.sh
06.pandapoolinfo4128.sh
07.poolipominercom3335.sh
08.poolipominercom3601.sh
09.ushashevolvedcom5550.sh
10.us-eastmultipoolus11111.sh
11.us-westmultipoolus11111.sh
12.eumultipoolus11111.sh
13.useastblackcoinpoolcom3333.sh
14.x11greenpooltk3333.sh
15.euhamsterpoolcom7773.sh
16.stratumcryptotrainnet3332.sh
17.stratumushashrateorg4444.sh
18.eu1dutchpooleu5555.sh
19.drkminepit3333.sh
20.suchpool.sh
21.wafflepool.sh
22.coinminepl.sh
23.miningpoolhub.sh
24.coinotron.sh
25.ltcrabbit.sh
26.coinkingiomulti.sh
27.coinkingiodrk.sh
conf
findingnemo.py
log

cat 01.nicehash3336.sh
#!/bin/sh
/opt/shm/darkcoin-cpuminer-1.3-avx-aes -t 2 -a X11  -D -P \
-o stratum+tcp://stratum.nicehash.com:3336 -u ~~~~~ -p x \
2>&1 | ./findingnemo.py 01.nicehash3336

I am trying to find pool_unknown_79.
http://drk.poolhash.org/masternode.html?srch&nmstr=pool_unknown_79

Does anyone have a pool name to check except the listed pools(01 - 27) ?

cleverminingpool discussing adding x11?

https://bitcointalk.org/index.php?topic=448649.msg7387096#msg7387096

[eltito]

And a serious question to Evan.

Would it be possible to extend the # of participating MNs via a configurable user option to enhance anonymity past Ring Sig levels?

MN = 0 ; Normal Transaction
MN = 1 ; Current mode
MN = 2 ; Darksend+
MN = 3 ; Darksend++
MN = 4 ; Good luck NSA
MN = 5 ; OKTHXBAI

Are we concerned about bloat in this case? Too complicated for average Joe to use in GUI?

Yes it's possible.  No, the way he would do it wouldn't cause a lot of bloat.  Nor would it complicate the UI.

WOW! Sorry if this was supposed to come as an announcement later as we have not seen anonymity "levels" configurable option discussed before, but thanks for the reply. That changes everything as far as transaction obfuscation was compared to CN/Ring Sigs. I think I do remember however that Evan decided to stay away from a Ring Sig port, must have been due to bloating concerns.

 

Oh no worries, we're just talking possibilities .  But yeah routing through multiple MNs is doable.  User selectable...well maybe, but it might not be the best way go about it from a security or efficiency (or user-friendliness) standpoint.

[coins101]

And a serious question to Evan.

Would it be possible to extend the # of participating MNs via a configurable user option to enhance anonymity past Ring Sig levels?

MN = 0 ; Normal Transaction
MN = 1 ; Current mode
MN = 2 ; Darksend+
MN = 3 ; Darksend++
MN = 4 ; Good luck NSA
MN = 5 ; OKTHXBAI

Are we concerned about bloat in this case? Too complicated for average Joe to use in GUI?

Yes it's possible.  No, the way he would do it wouldn't cause a lot of bloat.  Nor would it complicate the UI.

WOW! Sorry if this was supposed to come as an announcement later as we have not seen anonymity "levels" configurable option discussed before, but thanks for the reply. That changes everything as far as transaction obfuscation was compared to CN/Ring Sigs. I think I do remember however that Evan decided to stay away from a Ring Sig port, must have been due to bloating concerns.

 

Oh no worries, we're just talking possibilities .  But yeah routing through multiple MNs is doable.  User selectable...well maybe, but it might not be the best way go about it from a security (or user-friendliness) standpoint.

Charge the rich bastards with plenty of money and lots of reasons for extra privacy insurance to tumble through minimum of 2 + X MN's.

Might be a waste of fees, but that's what life insurance is: lots of regular payments for money to be paid out for the benefit of others, so you can sleep well at night, if you end up sleeping permanently.

Still, would get more master nodes on the network.

[humanitee]

If you can string two master nodes together, you can string any number together. There is a minimum of two involved.  

Now that really rocks.

But why not just do multiple DarkSends? Seems redundant to me since you must always have the coin owners sign the transactions. I probably haven't thought about it enough (is 10 minutes enough? lol) but I can't see a benefit to it.

One node knows the source of coins, one knows the destination, but neither knows both.

That's not what I mean.

Beyond two, what's the point? Having more than one is obviously beneficial. There's really only two things you do when you spend, and that is to denominate and then spend. Looks like we have all bases covered. You could denominate again, or spend again, but why not just do two rounds of DarkSends instead of one?

[camosoul]

The only weakness is that if you own both masternodes, you can trace the payments because you are seeing realtime what clients belong to denominationed units and where those units end up.

And this is why multi-entry "fat stack" masternodes are a GOOD THING. There won't be any legitimate reason to run more than one masternode. The only possible use for running more than one masternode will be specifically to do this.

[rygamble]

The only weakness is that if you own both masternodes, you can trace the payments because you are seeing realtime what clients belong to denominationed units and where those units end up.

And this is why multi-entry "fat stack" masternodes are a GOOD THING. There won't be any legitimate reason to run more than one masternode. The only possible use for running more than one masternode will be specifically to do this.

The fees seem like a good reason to run more than one.