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. I very much doubt the remote master node knows the private keys, because as you have pointed out, it would be of no advantage. The way I'm thinking about this is that an attacker follows this path: Get static IP of masternode --> compromise masternode --> figure out IP of secondary node by [magic] --> compromise secondary node The [magic] part I'm assuming must be possible because the masternode must at some point communicate with the secondary node. But maybe there's some reason why this is infeasible? Nope, they don't need to communicate. The masternode with the money just needs to sign a message with it. That node broadcasts it to the whole network. After than the secondary masternode is good to go. |
|
|
|
|
Think we could try to get a wikipedia page again? I think it's possible this time, being that Darkcoin is the first truely decentralized eCash system to ever exist. They said it wasn't notable before... now it is.
|
|
|
|
is there an ircchannel for the testing? What can we do to help the testing?
#darkcoin-test on freenode |
|
|
|
Interesting thing this darkcoin. I bought some a week ago, and am very happy I did.  Thinking about setting up a masternode... but then again... I would NEVER DREAM OF putting a wallet on a server. That just invites hackers to steal my DRK. How do you guys guarantee the masternode holders are not just some noobs who have no idea about how to secure a server??? This is seriously dangerous... I wonder when we'll hear about the first masternode losing all it's dark. (and possibly even some DRK of other people?) Or am I missing something? Other then that, I very much like DRK! And will continue to buy a few every day... :-) Yes, you are missing something. The 1000DRK is just a collateral to ensure it is very expensive to attack the network. The coins have nothing to do with the Masternode roll of being randomly selected to mix a Darksend transaction. The masternodes play a role in the anonymity and they get pay for that service, the collateral coins are very unlikely to be stolen. But wait a minute. My wallet has to be on a publicly accessible server with static ip. Visible to all. My wallet must be on the same machine. No wallet, no working masternode. Am I right? So a hacker gets a free list of juicy static ips with each having a wallet of 1000 DRK, and we should just sleep tightly? 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. |
|
|
|
I wonder how Eduffield is doing today +1  +1 Just fine  |
|
|
|
What is a good mpos or p2p pool that I can switch to. I cannot stay connected to the darkcoin.io pool. Not sure if it is getting ddos'd or what but i need a backup.
i was just going to post the pool was down. it has been so long i touched the configs that i have lotterymining as primary with drkpool as backup Ran into some database troubles and we're working on it. Should be back up soon. |
|
|
|
Evan, will the next RC support Windows masternodes?
The current version does, you just need to use the debug window to start it up |
|
|
|
same problem for me it says syncing but it stays unsynced...
it is synced up to 57146 block
Anyone that is stuck syncing on windows, can you email the debug log to evan@darkcoin.io? |
|
|
|
Could anyone help me?
My wallet shows that it is currently synchronizing with the network -- however, It states that it is " 0 hours behind "
As far as i can tell, all my transactions are always up to date, and i instantly receive most payments.
My first steps to diagnose the problem were too delete peers.dat , blocks folder, and chainstate folder.
After a cold re-sync, The wallet is up to date for a few minutes before it resorts back to synchrnozing with the network with a status of " 0 hours behind " ...
When hovering over the progress bar it shows - 56,920 blocks out of 470,000 have been proccessed.
Can anyone explain this issue to me ?
Mine behaves exactly the same. Version v0.10.3.4-38-gd79df3d-beta. Grab RC1, the version is v0.10.4.0. There was a bug with downloading blocks in the previous beta Ok thanks for the prompt response! I was under impression that RC1 was optional. Edit: Can confirm - RC1 has resolved the issue. Wait some longer. I have the RC1 running since it was available. The issue did not dissapear.
Agreed, The issue is reoccuring for me. Chaeplin's instructions were a little confusing for me to follow - did it solve the issue?
Could DEV please comment on the severity of this issue? Is it simply not an issue? Not sure =/
It is something that has to be corrected in the coin itself. Amuseing to me LimeCoin dev's understood it. They decided not to do it since it requires a hard fork. I recomment the dev to read it up on the link I posted. It links over to that Limecoin. I didn't mine LimeCoins because that issue and I don't see any future in that coin anyway (byway there a 2 different LimeCoins now so they kill themself) DarkCoin is a bit a different story. I am not really happy with DarkCoin for a number of reasons but I know that it is a major player and gains values and so I go along with it. Chaeplin's instruction is a workaround. He listed all the foreign IP's coming from LiteCoin and WorldCoin that connect to DarkCoin and tells you to set your routing on your system to route those IP's into nirvana so the client doesn't sees them. I haven't tested it yet. Busy with others. But I am confident it will work. However in looking into the future I more liked the dev would take it serious and fix it by the next occasion. A serious coin with such a flaw is a bit of a joke. Try deleting peers.dat and restarting. I'm curious to see if that fixes it. |
|
|
|
Could anyone help me?
My wallet shows that it is currently synchronizing with the network -- however, It states that it is " 0 hours behind "
As far as i can tell, all my transactions are always up to date, and i instantly receive most payments.
My first steps to diagnose the problem were too delete peers.dat , blocks folder, and chainstate folder.
After a cold re-sync, The wallet is up to date for a few minutes before it resorts back to synchrnozing with the network with a status of " 0 hours behind " ...
When hovering over the progress bar it shows - 56,920 blocks out of 470,000 have been proccessed.
Can anyone explain this issue to me ?
Mine behaves exactly the same. Version v0.10.3.4-38-gd79df3d-beta. Grab RC1, the version is v0.10.4.0. There was a bug with downloading blocks in the previous beta. I just tested both updated versions with no problem |
|
|
|
Problem with a variable requirement would be that maybe I have a masternode now and after 10 minutes it's not a masternode anymore.
I think 1k DRK currently is the right amount, but once 1DRK > $10 it's going to be a little bit costy to run a few masternodes.
Long term a vote system that allows people to vote the minimum amount and it changes every few weeks, not often, could be an amazing way to go, and in order to vote probably should be by solving blocks.
I'm sorry but voting is a bad idea, we've seen how it messes everything up and causes havoc. I would say the developers need to make that decision based on facts and how things are going. If there aren't enough masternodes, they need to lower the amount based on critical thinking. Masternode requirements are going to be 1000DRK forever, for the following reasons: - We need a bunch of masternodes, but more is NOT better. They cause chatter on the network saying they're still around and more memory usage everywhere. It's also more processing for the nodes to figure which to use. - We want them to be reasonable expensive to start now and insanely expensive down the line. - This will cause a feedback loop which will create upward pressure on price of darkcoin even making it more expensive to start one of these in the future (I detail this concept here: https://darkcointalk.org/threads/darkcoin-update-masternode-requirements-masternode-payments.225/) - Every client on the network needs to keep a list of all of these, we don't want a list of 100k - 10k masternodes @ $1000 is the same thing as 50k @ $200. The only difference is a lower barrier to entry and lower end equipment. In either case it would cost a million to add enough nodes to see half of the traffic. - Also the clients need to download this list upon booting up - There's also a consideration for the masternodes themselves. We have 576 blocks per day, If there's 10000 master nodes that means they'll on average get paid once every month and a half. I feel like if that number goes any higher we'll have nodes that won't want to wait to recoup their investment. |
|
|
|
Still going to say MORE MASTERNODES please. The network should stand out making it impossible to duplicate down the road for any cloners.
My 10 masternodes are prepared but the binary client does not run on debian. Please someone create some good static linked rc1 binary which works on debian too. I'll do that for RC2 |
|
|
|
so its a problem with mintpal? still only 9 DRK there. 18 DRK missing.  Yeah. You can have multiple payments to the same address in 1 transaction and it's legal, so it's something on their side. |
|
|
|
I found some interesting commentary about X11 in the dogecoin subreddit:
http://www.reddit.com/r/dogecoin/comments/23fk2i/very_long_very_serious_development_summary_week/At the time of writing the development team has no plans to change proof of work algorithm outside of the eventuality of a major security break to Scrypt. We are focusing on mitigation approaches in case of a 51% attack, and adoption of the coin as the most sustainable approaches to dealing with this risk.
The X11 algorithm has been proposed as an alternative proof of work algorithm. X11, for those unaware, was introduced with Darkcoin. It’s a combination of 11 different SHA-3 candidate algorithms, using multiple rounds of hashing. The main advantage championed for Darkcoin is that current implementations run cooler on GPU hardware. Beyond that, there’s a lot of confusion over what it does and does not do. As I’m neither an algorithms or electronics specialist, I recruited a colleague who previously worked on the CERN computing grid to assist, and the following is primarily his analysis. A full technical report is coming for anyone who really likes detail, this is just a summary:
A lot of people presume X11 is ASIC resistant; it’s not. Candidate algorithms for SHA-3 were assessed on a number of criteria, including simplicity to implement in hardware. All 11 algorithms have been implemented in FPGA hardware, and several in ASIC hardware already. The use of multiple algorithms does significantly complicate ASIC development, as it means the resulting chip would likely be extremely large. This has consequences for production, as the area of a chip is the main determining factor for likelihood of an error in the chip.
The short version being that while yes it would take significant resources to make an efficient ASIC for X11, for a long time Scrypt was considered infeasible to adapt to ASICs. As stated earlier, any move would most likely be nothing more than an extremely expensive and risky delaying manoeuvre. ASIC efficiency would also depend heavily on ability to optimise the combination of the algorithms; a naive implementation would run at around the rate of the slowest hashing algorithm, however if any common elements could be found amongst the algorithms, it may be that this could be improved upon significantly
There are also significant areas of concern with regards to X11. The “thermal efficiency” is most likely a result of the algorithm being a poor fit for GPU hardware. This means that GPU mining is closer to CPU mining (the X11 Wiki article suggests a ratio of 3:1 for GPU/CPU mining performance), however it also means that if a way of was found to improve performance there could be significantly faster software miners, leading to an ASIC-like edge without any of the hardware development costs. The component algorithms are all relatively new, and several were rejected during the SHA-3 competition for security concerns (see http://csrc.nist.gov/groups/ST/hash/sha-3/Round2/documents/Round2_Report_NISTIR_7764.pdf for full details). Security criteria for SHA-3 algorithms was also focused on ability to generate collisions, rather than on producing hashes with specific criteria (such as number of leading 0s, which is how proof of work is usually assessed).
X11 is a fascinating algorithm for new coins, however I would consider it exceptionally high risk for any existing coin to adopt.
|
|
|
|
- Why does the problem exist (i.e. what's the specific attack vector for taking a masternode's earned payment?)
There's really no easy way to pay a dynamic address. If we accepted any address, the payments to masternodes would basically become optional. We'd see large solo miners making payments to themselves instead. So I came up with a voting system. - Does the voting have a manual component, or is it fully automated?
Miners will vote for whomever they believe is the current masternode, this is completely automatic. - Can the voting be gamed? Does it introduce bias? Might I miss out on masternode payments if I for some reason don't get enough votes?
It would take 51% of the network to game it. You would need to be able to solve 5 blocks and vote for an address that wasn't suppose to be paid. The whole network should know who won, so it will be extremely unlikely to miss a payment. |
|
|
|
Transaktions with darksend enabled don't work for me. Everytime the darksend status idle after some time (never goes after 1/3), and no transaktion happen. I have RC 1, "addnode=23.23.186.131" is in darkcoin.conf. Also I've made a clean start with the romaing folder removed. Any ideas?
Darksend requires 3 transactions to complete (it won't be an issue when we have more people using it), try sending 3 times with darksend. You'll see 1/3, then 2/3 then signing and complete. Ok that worked. But now there is another problem. I've sent 3x 9 DRK to mintpal but only 9 DRK arrived. 27.003 DRK where deducted from my wallet. thats the id from those 3 transactions http://chainz.cryptoid.info/drk/tx.dws?d08bcb05760f7291e641b79e6ff9e4986b7c22ecc8ac61bae01c68d04df3246d.htmd08bcb0576... 56385 2014-4-23 10:37:38 + 9.0 DRK 18.0 DRK
d08bcb0576... 56385 2014-4-23 10:37:38 + 9.0 DRK 27.0 DRK
d08bcb0576... 56385 2014-4-23 10:37:38 + 9.0 DRK 36.0 DRK
Seems ok for you now. Yeah, that looks fine. |
|
|
|
I'm a bit confused -- what's being voted on with this mechanism?
It's the code for paying masternodes. It's done in a way that requires network consensus to avoid people just taking the money. |
|
|
|
Transaktions with darksend enabled don't work for me. Everytime the darksend status idle after some time (never goes after 1/3), and no transaktion happen. I have RC 1, "addnode=23.23.186.131" is in darkcoin.conf. Also I've made a clean start with the romaing folder removed. Any ideas?
Darksend requires 3 transactions to complete (it won't be an issue when we have more people using it), try sending 3 times with darksend. You'll see 1/3, then 2/3 then signing and complete. |
|
|
|
I've forked the blockchain on testnet and added a voting mechanism. This turned out really cool.  Here's how the voting works: - You have to mine a block to vote, the software will automatically vote for the current masternode to get paid. - You can only enter a new candidate for the block you mined - You can vote on all other candidates in the previous block - You can only up vote (+1 to the total) - If an entry has 5 votes, a new payment is made on the next block (that miner has no choice) - If a candidate doesn't reach 5 votes in 10 blocks, they're removed. Hoping to launch some serious testing next week on testnet. Still working out the bugs. I also modified the block explorer so we can see the votes that are stored in the blockchain. |
|
|
|
|
Show Posts
