out of curiousity, is there any chance in reducing the block time for 2.5mins? There are alot of coins that have much faster block times now which would lend to be better accepted as a currency for every day purchases in the future.
No. This is wrong and people shouldn't practice it. Bitcoin is fine with 10 minute block as well. why is this wrong. The 10-minute block times that BTC has make it unusable as an everyday currency, no? Who wants to wait that long for an in-store purchase and such? At least DRK's block times are alot lower, but still 2.5mins could be a long time to wait if used as a currency for day-to-day purchases. The time to process a credit card payment can be much longer. |
|
|
|
Dumb question if someone can help: How can one verify that they sent money to someone if its anonymous? Is there a way of overcoming this or are there various sending methods? Anon payments are great but tracked payments have their place as well.
If you own a shop, you can have an address assigned to each client like the exchanges do (you'll know that your client sent the money, but you'll not know from what wallet). And if you are neither the client nor the seller, you don't have to track payments in the first place.  |
|
|
|
Search for the discussion between Evan and AnonyMint earlier this month to not waste your time trying to reinvent the wheel. |
|
|
|
Let me just float this one in the air and see if it has some merit.
Imagine if Darkcoin could be used by governments for local, regional and eventually national voting in political elections.
Stick with me for a bit.
Voting costs a lot of money. There is a lot of administration.
Voting has to be fair, anonymous and foolproof.
[...]
So I can use thousand of wallets and have more weight in an election ? More money more rights ? It's anonymous yes, but fair no... And that's why they'll say : "let's tie the wallet to the id to have a really fair vote" Clearly, it needs some thought into linking issued addresses or numbers of addresses issued with counted votes. You still need to have the principle of one person one vote. That's the type of extension coloured coins would probably be considered, but I'm not a fan of those. If you can solve the issue of anonymous voting using a crypto currency, you also begin to solve a lot of other problems - like shareholder voting for decentralised anonymous corporations. 1-If the weight of the vote is function of the number of shares it's possible : let's say that the number of shares is equivalent to the number of coins in a wallet, a vote coming from a big wallet (or many of the same user) can have more power than a vote coming from a smaller one. 2-But if it's "one person, one vote" the identity has to be tied to the vote one way or another. |
|
|
|
Let me just float this one in the air and see if it has some merit.
Imagine if Darkcoin could be used by governments for local, regional and eventually national voting in political elections.
Stick with me for a bit.
Voting costs a lot of money. There is a lot of administration.
Voting has to be fair, anonymous and foolproof.
[...]
So I can use thousand of wallets and have more weight in an election ? More money more rights ? It's anonymous yes, but fair no... And that's why they'll say : "let's tie the wallet to the id to have a really fair vote" |
|
|
|
Huge buy walls on cryptsy and mintpal  Nethash >50GH, block reward 9.   You have to find (solo) 111 blocks to make a masternode. The price can only increases at that point.  |
|
|
|
From the whitepaper: Improved Pool Anonymity
Users who want to increase the anonymity of the pools can run scripts to “push” DarkSend
transactions through the pool by sending money to themselves with DarkSend. This will allow
them to take up a space in the pool to ensure the anonymity of other users. If enough users run
scripts like this one, the speed of transactions and the anonymity of the network will be
increased.
The problem I see with this is that it would be really easy to tell which addresses were pushing transactions and which were just using darksend naturally by merely the frequency of the transactions. ie "pushed" coins will have only been sitting on the address a short while whereas non-pushed darksend transactions will have likely stood still for quite some time. Maybe we could incorporate this pushing behavior into the masternodes themselves? There will likely be many hundreds of masternodes (each with 1000 coins), so maybe if a subset (maybe 5-10%) pushed a few coins through darksend every mixing cycle it could create more anonymity. The big advantage here is that there are so many masternodes with so many coins, each masternode would only have to push a small number of coins infrequently. This would make it harder to distinguish pushed coins from those that were just sent by darksend naturally. I don't see the problem. The purpose is to unlink the sender and the receiver, using DarkSend (will be) is pretty normal and frequent, the part to hide is "for what". |
|
|
|
Let's take a look at the previous transaction of one of the mixing addresses (Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4) : http://chainz.cryptoid.info/drk/tx.dws?231912.htmInputs
Index Previous output Address Amount
0 ac1654bc6b...:0 Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4 10.0 DRK
Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4 received a total of 162.26753362 DRK from XenyqcvgMbQ42FPph6eZZttYJEuKJzusSk (a sender) distributed like this : Index Redeemed in Address Amount
0 d08bcb0576... Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4 10.0 DRK
1 16dbc9dbff... Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4 152.15753362 DRK
2 Not yet redeemed Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4 0.11 DRK The 152.15753362 DRK and the rest of the real DarkSend transaction (10 - x) never came back directly to XenyqcvgMbQ42FPph6eZZttYJEuKJzusSk I guess I don't get it. The whitepaper does not explain this very clearly which is unfortunate. Maybe some improvements were implemented following the discussion between Evan and AnonyMint. |
|
|
|
As far as the network is concerned, wallets do not exist, only addresses. Your wallet just holds all of your addresses and the private keys associated with them.
Back to your original question about timing analysis, look at the bottom figure on page 3 of the whitepaper. Each user will be placing the same # of coins into the pool (100 for example) - they will also provide a "spare change" address - coins that they don't want to spend but will come back to them. This is a NEW address that has not been associated with them up to this point.
So lets say 3 people each put in 100 coins
A -> 100 sending 2 coins to D
B -> 100 sending 24 coins to E
C -> 100 sending 56 coins to F
The outputs will be
2 coins to D
98 coins to G
24 coins to E
76 coins to H
56 coins to F
46 coins to I
Now from this we can determine that the current holder of address G sent two coins to D, but it's impossible to determine whether G belongs to the same person as A, B, or C.
A new problem arises though, in that the coins are now sitting on address G, and it can be determined that the holder of those coins sent 2 coins to address D. There would need to be another level of mixing to ensure that those 98 coins are washed another time - maybe Evan can clarify whether this mixing step happens or if I am misunderstanding something.
The risk is if address G sends money to something like coinbase (or some other site that has your personal info) -> that would expose them as the sender of 2 coins to address D.
Evan can you clarify?
It doesn't work like this, it's far more complex. It seems when I follow a transaction that all the address' balance is spent including 10 DRK which is used for the mixing. I guess I don't follow. According to the whitepaper it works as I describe above (as far as I can tell). Do you have a link to the blockchain so I can take a look? Send 1 DRK to an other wallet via DarkSend and try to follow the money using http://chainz.cryptoid.info/drk/The whitepaper talks about 100 DRK (10 DRK now) to the pool but it never says if 100 is the total output from the wallet  I'm relatively certain you are incorrect, darksend transactions look exactly as I describe above and is described in the whitepaper: http://chainz.cryptoid.info/drk/tx.dws?d08bcb05760f7291e641b79e6ff9e4986b7c22ecc8ac61bae01c68d04df3246d.htmLet's take a look at the previous transaction of one of the mixing addresses (Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4) : http://chainz.cryptoid.info/drk/tx.dws?231912.htmInputs
Index Previous output Address Amount
0 ac1654bc6b...:0 Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4 10.0 DRK
Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4 received a total of 162.26753362 DRK from XenyqcvgMbQ42FPph6eZZttYJEuKJzusSk (a sender) distributed like this : Index Redeemed in Address Amount
0 d08bcb0576... Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4 10.0 DRK
1 16dbc9dbff... Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4 152.15753362 DRK
2 Not yet redeemed Xo1zVXtXftfGaZbzdc4DcJoprzGjntLYx4 0.11 DRK The 152.15753362 DRK and the rest of the real DarkSend transaction (10 - x) never came back directly to XenyqcvgMbQ42FPph6eZZttYJEuKJzusSk |
|
|
|
As far as the network is concerned, wallets do not exist, only addresses. Your wallet just holds all of your addresses and the private keys associated with them.
Back to your original question about timing analysis, look at the bottom figure on page 3 of the whitepaper. Each user will be placing the same # of coins into the pool (100 for example) - they will also provide a "spare change" address - coins that they don't want to spend but will come back to them. This is a NEW address that has not been associated with them up to this point.
So lets say 3 people each put in 100 coins
A -> 100 sending 2 coins to D
B -> 100 sending 24 coins to E
C -> 100 sending 56 coins to F
The outputs will be
2 coins to D
98 coins to G
24 coins to E
76 coins to H
56 coins to F
46 coins to I
Now from this we can determine that the current holder of address G sent two coins to D, but it's impossible to determine whether G belongs to the same person as A, B, or C.
A new problem arises though, in that the coins are now sitting on address G, and it can be determined that the holder of those coins sent 2 coins to address D. There would need to be another level of mixing to ensure that those 98 coins are washed another time - maybe Evan can clarify whether this mixing step happens or if I am misunderstanding something.
The risk is if address G sends money to something like coinbase (or some other site that has your personal info) -> that would expose them as the sender of 2 coins to address D.
Evan can you clarify?
It doesn't work like this, it's far more complex. It seems when I follow a transaction that all the address' balance is spent including 10 DRK which is used for the mixing. I guess I don't follow. According to the whitepaper it works as I describe above (as far as I can tell). Do you have a link to the blockchain so I can take a look? Send 1 DRK to an other wallet via DarkSend and try to follow the money using http://chainz.cryptoid.info/drk/The whitepaper talks about 100 DRK (10 DRK now) to the pool but it never says if 100 is the total output from the wallet |
|
|
|
Btw, I got an idea just now: It would be an interesting twist if one could send to two addresses instead of one, in a single transaction, with the sent amount being broken into two randomly sized parts. For example I send you 16 DRK and you get 5.4 DRK in one address and 10.6 DRK in another. You still got 16 but it's in two addresses so noone can corelate my 16 output and your receiving of ..5.4 and 10.6. If a further layer is added (for practical purposes) to treat these addresses as one (for the sender and receiver) it could also be quite easy to use. Kind of meta-addresses that overlap/include the sending/receiving addresses.
ok -- but with a timing analysis, the number of transactions in (let's say) a 60 second window will be relatively few, so it's not too hard to reconstruct what really happened, especially with uncommon amounts (e.g. I send you 16.023957). [Note- i don't know what is chain pooling that you mentioned...] When someone here ran a script to calculate the rich-list (many pages back), I remember he/she managed to correlate between different addresses as being part of the same wallet. So if I understand correct, what AlexGR suggested sounds intriguing, but 'hackable'. My question is- what if we take it further and instead of having the transactions divided between several addresses, it ius divided into several 'wallets' that reside on the same qt, feed from the same blackchain dat, but each having a separate wallet.dat file/keys ? As far as the network is concerned, wallets do not exist, only addresses. Your wallet just holds all of your addresses and the private keys associated with them. Back to your original question about timing analysis, look at the bottom figure on page 3 of the whitepaper. Each user will be placing the same # of coins into the pool (100 for example) - they will also provide a "spare change" address - coins that they don't want to spend but will come back to them. This is a NEW address that has not been associated with them up to this point. So lets say 3 people each put in 100 coins A -> 100 sending 2 coins to D B -> 100 sending 24 coins to E C -> 100 sending 56 coins to F The outputs will be 2 coins to D 98 coins to G 24 coins to E 76 coins to H 56 coins to F 46 coins to I Now from this we can determine that the current holder of address G sent two coins to D, but it's impossible to determine whether G belongs to the same person as A, B, or C. A new problem arises though, in that the coins are now sitting on address G, and it can be determined that the holder of those coins sent 2 coins to address D. There would need to be another level of mixing to ensure that those 98 coins are washed another time - maybe Evan can clarify whether this mixing step happens or if I am misunderstanding something. The risk is if address G sends money to something like coinbase (or some other site that has your personal info) -> that would expose them as the sender of 2 coins to address D. Evan can you clarify? It doesn't work like this, it's far more complex. It seems when I follow a transaction that all the address' balance is spent including 10 DRK which is used for the mixing. |
|
|
|
Apologies if this has been answered before.
If I have 3000 Dark and want to create 3 masternodes, Do I need to put 1000 Dark into 3 separate wallets on 3 separate servers.
Or can I have all 3000 dark sitting in 1 wallet on a secured server and I will get 3 tickets/chances to allow me to be selected as a masternode during the random selection process?
Thanks!!!
Right now, run 3 masternodes with 1000 in each or run 3 masternodes on a server with 3 corresponding masternodes on another server for the future, I think you could: run 3 masternodes "B" on 3 server opening each one, one at a time with a personal computer running a masternode "A", when finished starting the server "B", you can put the wallet that was running masternode A into cold storage, and take it off your machine. Do that 3 times, and it'll be the safest option for your setup.
Nope, both need to be online. At least for now.
|
|
|
|
I don't get how the 2 machine masternode setup is more secure. If someone can break into either, your setup is toast. And the wallet's security is independent of the machines hosting it -- it relies on the strength of your password & the encryption algorithm. I can't see how the 2 machine configuration helps at all.
Because your master node IP is static, broadcast to the network, and an attacker knows 1000 DRK is on it. Your local machine IP is not listed on the master node list with the 2 machine setup and there are no coins on the server that's running the master node. Double win. If we could get a port of Armory for Darkcoin you could theoretically do all this with the coins in cold storage. Triple win. Masternode has to communicate with the node holding the coins, to verify the 1000 DRK are there. So if the masternode can do that, so can an attacker who has compromised the masternode. From there, they just need to break into the secondary node holding the wallet, which will presumably have no better security than the one they already broke into. My guess is that masternodeA (the one holding the coins) registers in the network like "hey, I want to be a masternode, and I hold 1k DRK, you can check it, and my "masternodeaddr" is this 'masternodeB' (which has 0DRKs)", then the network verifies that masternodeA has 1k DRKs and registers masternodeB in the list of masternodes. When you get the list of masternodes you only get masternodeB. I guess someone could sniff that initial part of the protocol and find out that masternodeA has 1k DRKs masternodeB has 0 DRKs, but I would say that you don't really even need to have masternodeA available in the network as long as the wallet holds the 1k DRKs, so (and this is just thinking and writing the same time) you could probable even disconnect masternodeA from the network after the initial registration and just leave masternodeB in the network. If that's how it works, then I wonder why a second machine is necessary? If you only need the wallet present at the initial verification step, why not have a single masternode that verifies the wallet, closes it, and allows you to remove it from the machine? If it was like this nothing could prevent someone to build thousand masternodes with the same 1000 DRK. Network would reject a masternode registering twice with the same address, and if you think about moving the 1k DRK to another wallet, network would detect it and stop accepting you as a masternode. Register a masternode with a wallet with 1000 DRK ----> send the 1000 DRK to an other wallet ----> Register a new masternode with the new wallet ----> send the 1000 DRK to an other wallet ----> etc. You didn't read my reply, the moment you send the 1k coins the network will see it, then it will stop accepting your masternode. Meanwhile if I have setup a lot of masternodes, I have a higher probability to be selected and to earn some DRK between two verifications ? |
|
|
|
Ok, I have verified it works.
Start darkcoind on remote machine.
On your local machine specify the IP at launch with -masternodeaddr=YOUR_SERVER_IP
Unlock your local machine wallet with your passphrase.
On your local machine, ./darkcoind masternode start
Slickness indeed.
So you have to keep it running on another machine, presumably your home machine, with the wallet unlocked? You don't have to keep your local machine's wallet unlocked permanently, or even open. Once the remote machine master node starts you can close the local machine's wallet and hide it away for safe keeping. I look forward to this being officially explained with tutorial. But thanks for this! But if we need 1000DRK on our local machine, or another server, to get the main master node running (which has 0 DRK), .... what is there to stop us making multiple nodes with empty wallets from one set of 1000 DRK. All I can think is we need the 1000DRK wallet to start each empty master node running. Then use a different wallet with 1000DRK locally to fire up another one. I look forward to understanding more lol. I think that you have to run both simultaneously. The advantage is that the IP of the machine containing 1000 DRK is not public. |
|
|
|
I don't get how the 2 machine masternode setup is more secure. If someone can break into either, your setup is toast. And the wallet's security is independent of the machines hosting it -- it relies on the strength of your password & the encryption algorithm. I can't see how the 2 machine configuration helps at all.
Because your master node IP is static, broadcast to the network, and an attacker knows 1000 DRK is on it. Your local machine IP is not listed on the master node list with the 2 machine setup and there are no coins on the server that's running the master node. Double win. If we could get a port of Armory for Darkcoin you could theoretically do all this with the coins in cold storage. Triple win. Masternode has to communicate with the node holding the coins, to verify the 1000 DRK are there. So if the masternode can do that, so can an attacker who has compromised the masternode. From there, they just need to break into the secondary node holding the wallet, which will presumably have no better security than the one they already broke into. My guess is that masternodeA (the one holding the coins) registers in the network like "hey, I want to be a masternode, and I hold 1k DRK, you can check it, and my "masternodeaddr" is this 'masternodeB' (which has 0DRKs)", then the network verifies that masternodeA has 1k DRKs and registers masternodeB in the list of masternodes. When you get the list of masternodes you only get masternodeB. I guess someone could sniff that initial part of the protocol and find out that masternodeA has 1k DRKs masternodeB has 0 DRKs, but I would say that you don't really even need to have masternodeA available in the network as long as the wallet holds the 1k DRKs, so (and this is just thinking and writing the same time) you could probable even disconnect masternodeA from the network after the initial registration and just leave masternodeB in the network. If that's how it works, then I wonder why a second machine is necessary? If you only need the wallet present at the initial verification step, why not have a single masternode that verifies the wallet, closes it, and allows you to remove it from the machine? If it was like this nothing could prevent someone to build thousand masternodes with the same 1000 DRK. Network would reject a masternode registering twice with the same address, and if you think about moving the 1k DRK to another wallet, network would detect it and stop accepting you as a masternode. Register a masternode with a wallet with 1000 DRK ----> send the 1000 DRK to an other wallet ----> Register a new masternode with the new wallet ----> send the 1000 DRK to an other wallet ----> etc. |
|
|
|
I don't get how the 2 machine masternode setup is more secure. If someone can break into either, your setup is toast. And the wallet's security is independent of the machines hosting it -- it relies on the strength of your password & the encryption algorithm. I can't see how the 2 machine configuration helps at all.
Because your master node IP is static, broadcast to the network, and an attacker knows 1000 DRK is on it. Your local machine IP is not listed on the master node list with the 2 machine setup and there are no coins on the server that's running the master node. Double win. If we could get a port of Armory for Darkcoin you could theoretically do all this with the coins in cold storage. Triple win. Masternode has to communicate with the node holding the coins, to verify the 1000 DRK are there. So if the masternode can do that, so can an attacker who has compromised the masternode. From there, they just need to break into the secondary node holding the wallet, which will presumably have no better security than the one they already broke into. My guess is that masternodeA (the one holding the coins) registers in the network like "hey, I want to be a masternode, and I hold 1k DRK, you can check it, and my "masternodeaddr" is this 'masternodeB' (which has 0DRKs)", then the network verifies that masternodeA has 1k DRKs and registers masternodeB in the list of masternodes. When you get the list of masternodes you only get masternodeB. I guess someone could sniff that initial part of the protocol and find out that masternodeA has 1k DRKs masternodeB has 0 DRKs, but I would say that you don't really even need to have masternodeA available in the network as long as the wallet holds the 1k DRKs, so (and this is just thinking and writing the same time) you could probable even disconnect masternodeA from the network after the initial registration and just leave masternodeB in the network. If that's how it works, then I wonder why a second machine is necessary? If you only need the wallet present at the initial verification step, why not have a single masternode that verifies the wallet, closes it, and allows you to remove it from the machine? If it was like this nothing could prevent someone to build thousand masternodes with the same 1000 DRK. |
|
|
|
There is no good reason why the private key needs to be stored on a masternode.
In an ideal setup, you would just broadcast a signed message "Authorizing 123.123.123.123 as masternode with input 1bcd1c22a3687e1ec1ea6ce61d3a43fae3581da9305d64fda298bbb66d1691ec expires 1398622305"
In this case 123.123.123.123 would be your masternode, but you don't need to have the private keys on that node. The signed message proves you are authorizing that IP to be the masternode for that input.
Did you see Evan's post about not needing the 1000 DRK on the actual master node? You just start a master node on your local machine and then call a darkcoind command to forward the master node to some other machine running darkcoind. I'm sure it works the way you describe, or something very similar. The best setup is to have 2 machines:
Machine A: Holds 1000DRK, runs as masternode. Use configuration option -masternodeaddr=machineB
Machine B: Holds 0DRK, runs as masternode.
There's no target.
Hummmm, I don't think that's implemented yet, 'cause I haven't seen anything saying you could do that??? Yes you just saw it. The best setup is to have 2 machines:
Machine A: Holds 1000DRK, runs as masternode. Use configuration option -masternodeaddr=machineB
Machine B: Holds 0DRK, runs as masternode.
There's no target.
|
|
|
|
|
Show Posts
