I love Darksend but you have to realize it will be replaced once someone starts a zero knowledge proof coin.
While I've been working on DarkSend I've been thinking about this alot. You know what the problem is with a zero knowledge proof? There's a secret key that will be attacked by governments and it will eventually be cracked. That will make every transaction that ever happened in that blockchain cleartext and allow every future transaction to also be viewed as cleartext. I'm going to venture to say the government is working on quantum computers and such crypto can be solved with shor's algorithm. When they do, they're not going to tell anyone. So it's a giant honeypot. DarkSend is immune to such attacks, all involved crypto functions could be cracked and the mixing is still done off blockchain by the masternodes. Off blockchain means that the information is lost and that's the only way to secure it, you can't do it with cryptography. |
|
|
|
|
Can a few people try to DarkSend with the updated client? It should be functioning pretty smoothly, I'd like to hear what people think of the new user experience.
Thanks
|
|
|
|
Is there an ETA for the hard-fork to implement masternode payments?
I'm going to be releasing a couple more updates for V6 to stabilize masternodes and payments. Then V7 will have masternode signatures for secure communication (ECDSA). After that maybe a couple fixes, then we'll be out a beta. After that my next project is masternode payments. I'd say 3-4 weeks out maybe? Then we'll start the RCs and after the network grows and we have stability, I'll opensource. |
|
|
|
Great. That's 2 x 6.2 and 2 x 6.3 shots of Tequila tonight to mark progress. Chaps and Mrs Robinson, posts might get a little ugly later  DarkSend Beta v6.4 - v.0.10.3.3 (same) - More stability fixes for masternodes - Windows client will be pushed up soon https://www.darkcointalk.org/threads/darksend-beta-v6.226/ |
|
|
|
Great work!  Things are getting very exciting now! Looks like it's time for me to setup a masternode or two!  One question. I understand there has to be a transfer of exactly 1000 DRK. Could I first test the wallet by sending over 0.1 DRK, and then the 1000 DRK? .. So it would have 1000.1 DRK? I'm not sure if the total has to be 1000DRK in the wallet, or just the 1000 DRK transfer. Cheers Evan. Yep, that will work. |
|
|
|
As it is, if one node is compromised or malicious, what stops it from hosing up darksend? Sure, that TX will fall out of the memory pool and eventually be not a sent transaction according to my client, but how about something that actively avoids the incident? Why shouldn't all clients hosting the full chain also be darksend nodes? For that matter, why is darksend optional? Why aren't all sends done in that manner automatically? Input volume, yes...
The idea of masternodes is to create a very expensive network similar to mining, where users invest money to make money. If you decide to be malicious, the only power you have is to not allow transactions for that 2.5 minutes, in which case you forfeit the money the network will pay you. If all nodes were able to do it, the network would be vulnerable to sybil attacks. See my conversation with Anonymint. Really the concept sounds great -- I guess what I am really worried about is DOS attacks on the Master nodes. Some people will do due diligence, but I am betting that most won't (don't know how) and the result will be that DRK suffers a black eye because one person brings down Darksend for a time. What protections are there against this other than urging master nodes owners to read up on net security? It's the same thing pools must deal with and we don't have many problems with attacks on that front. I think it's even slightly better than the situation with pools. With pools you can DDOS bad work that must be processed. With DarkSend we can lock it down while it's the masternode so it only will accept new inputs with a new collateral transaction, otherwise it will disconnect you and you'd lose the collateral. |
|
|
|
We have six masternodes running ./darkcoind masternode list { "121.156.120.112:9999" : 1, "23.23.186.131:9999" : 1, "112.175.123.94:9999" : 1, "162.243.234.7:9999" : 1, "87.242.50.175:9999" : 1, "142.161.23.40:9999" : 1 } |
|
|
|
As it is, if one node is compromised or malicious, what stops it from hosing up darksend? Sure, that TX will fall out of the memory pool and eventually be not a sent transaction according to my client, but how about something that actively avoids the incident? Why shouldn't all clients hosting the full chain also be darksend nodes? For that matter, why is darksend optional? Why aren't all sends done in that manner automatically? Input volume, yes...
The idea of masternodes is to create a very expensive network similar to mining, where users invest money to make money. If you decide to be malicious, the only power you have is to not allow transactions for that 2.5 minutes, in which case you forfeit the money the network will pay you. If all nodes were able to do it, the network would be vulnerable to sybil attacks. See my conversation with Anonymint. |
|
|
|
DRK will be USD$101 in 2015.
We should turn this into a competition. Price is right style (the closest without going over). What is the closing price January 1st, 2015 in USD (using cryptsy and bitcoinaverage.com)? Winner gets??? |
|
|
|
In this case, one could also encrypt the wallet.dat with a random key and immediately destroy it forever (so even you don't know it) with a single key pair inside and print out the private key as a paper wallet which can be kept somewhere safe (e.g. not in your house and/or next to the server hardware).
When you decide to shut the node down and spend your coins, you simply delete your wallet.dat and import the private key from the paper wallet to a freshly generated wallet.dat
That's not really going to work. Upon starting the masternode up, it's going to need to sign the input with the 1000DRK to show you own it. After that all messages will use a separate key, so the wallet can be encrypted until the next restart. Where will node reward coins be sent?
If they go to the same address, won't the increased amount of coins disqualify that node from becoming a masternode?
In the initial message that you sign with the vin, you will sign your IP and darkcoin address to pay. It's using ECDSA signatures like the "signmessage" and "verifymessage" commands. Also the "tickets" into the election require 1 unspent output equal of 1000DRK. We know it's unique because of the vin. Pretty amazing what you can use bitcoin for, eh? Is it checked if your address had exactly 1000 DRK transaction once and it still has that 1000 DRK but ignores any other incoming and/or outgoing transactions?
The 1000DRK needs to go into a single input and that vin gets passed around. When you start the masternode it locks that input, so it actually can't be spent. You'd have to shutdown the client and disable the masternode to move it. If you spent it somehow, the other clients look at the memory pool for changes and disable masternodes automatically (that's the error you got from me testing). |
|
|
|
Same here. This latest beta finally works for me.
I wonder why we're centralizing DarkSend... Why can't it be as equally distributed as the BlockChain? TOR chooses Rendezvous nodes for hidden services entirely at random, so no "MasterNode" can be identified... I'm not opposed to a setup like that. Maybe that can be V2. I'd argue our system is still decentralized though, there will be many masternodes each doing mixing for a small time. |
|
|
|
not you, people accusing you of scamming.  edit:what i meant to say is that this is not the first time they are on to scam coin. Ah. I was thinking I must be creating coins in my sleep or something |
|
|
|
I really love the validation you guys are giving Darkcoin.
The one precious resource in the world is our time on this planet.
And you want to spend it hunting down darkcoin when there are so many blatant scams in the world. False IPOs and all sorts of people that remain hidden and don't have the front to tell everyone who they are.
Spending your limited resource on this planet trying to knock one particular coin is all the validation I need to invest more.
You guys rock.
you know, this is not their first scam coin. they were all over dozens of similar scams. guys, nice to see you again. it's like january/february times all over again. Ha, what other coins have I done? |
|
|
|
why did you change the number of coins "in the middle of the game"? what did the big investors say to that? We didn't, it was going to have an infinite supply, 1M coins added forever. We added a 7% decline per year to the block rewards (starting next January). |
|
|
|
The problem is that darkcoind won't save more than a few hundreds of keys into the wallet.dat, no matter how big keypool I ask for (it does generate all the 10000 or more keys into the thin air but saves only ~500 initially and only ~200 new after it flushes those original 500 unencrypted keys when you later encrypt the file) and I figure DarkSend will eat the keys from the keypool like a crazy addict, and thus you will either need to periodically input your password on the online server (risking your coins if somebody hacked it, even more if you do it automatically and thus you keep the password on the online machine) or copy the wallet.dat to a flash drive, refill it's keypool on an offline computer and copy it back (while your masternode is offline).
Masternodes will never use any new addresses in the keypool, unless you send funds from the node itself. They're simply the center point that all users will connect to for mixing at a specific moment in time. Other than that, great guide. |
|
|
|
Another question about DarkSend: - Do masternodes pay TXfee while they move coins as part of the DarkSend transactions? Or course, the planned node-reward will cover that if they do, but there is no reward yet, so I would effectively pay for being a node.  Nope. I saw you were having problems and it's really difficult to debug at the moment. I'll add some commands and upload a new daemon. |
|
|
|
|
Show Posts
