Overall I think the launch went well. Most people have had their coins denominated and to date all major "DRK are gone" problems have been resolved. At this point there are 2 issues I see that need to be addressed.
1) Darksend rounds > 1 never finishes denomination for a number of users (myself included)
2) Handful of users aren't seeing their transactions confirmed and be included in the blockchain -- this results in the coins getting stuck.
I expect Evan to take care of these in the next day or two.
I'm going to be working on #2. Can people send me the TXID's that are unconfirmed, their debug.log and a screenshot of the transactions tab? evan@darkcoin.iobump. if you have stuck transactions please do as Evan asks. This issue is resolved! Update coming soon |
|
|
|
Overall I think the launch went well. Most people have had their coins denominated and to date all major "DRK are gone" problems have been resolved. At this point there are 2 issues I see that need to be addressed.
1) Darksend rounds > 1 never finishes denomination for a number of users (myself included)
2) Handful of users aren't seeing their transactions confirmed and be included in the blockchain -- this results in the coins getting stuck.
I expect Evan to take care of these in the next day or two.
I'm going to be working on #2. Can people send me the TXID's that are unconfirmed, their debug.log and a screenshot of the transactions tab? evan@darkcoin.io |
|
|
|
This is normal? What I see is a couple "Payments to Self", which means the client was either splitting up large inputs or creating fee sized inputs, then a bunch of denomination transactions. It looks like the payments yourself got stuck, those will have whatever minimum fee you set or whatever the client thought was needed. If you don't have a minfee set and your client thought it'd pay 0.00000DRK, then you'll have to wait for a really nice miner to include them in a block for free. However, after that the other transactions (Denominations) will go really quick, because they pay miners really well. |
|
|
|
So I can just update my local client, no need to update my MNs again today? correct |
|
|
|
I don't get to check this thread as often anymore so maybe I missed it, but any updates on the Kristov review?
He's working on it now, he's been asking me questions everyday. |
|
|
|
|
Who's going to be the first to send coins anonymously with 8 rounds of Darksend? Should they get a prize?
|
|
|
|
I'm pretty sure the Deathstar is a fitting analogy (minus the blowing up part. We've got that covered  ). An email I just sent to Kristov explaining how the pairing strategy works: the goal is for all participants to use the same denominations, so you can't tell who's are whos afterward. For example, here's one approved pairing: Bob: 500, 100, 100, 100, 10, 10 Mary: 500, 100, 100, 10 Joe 500, 100, 10 Another Bob: 100, 100, 100, 10, 10, 1 Mary:100, 100, 10, 1 Joe 100, 10, 1, 1, 1 This means that if one has a 500DRK output, they all must have one. If one has a 100DRK output, they must all have at least one. So the way this is accomplished is very complicated, I've attached the newest source and I'll point you to the correct locations where things are happening. The flow of events is like this: 1.) DoAutomaticDenominating is executed, inputs are queried to see what work needs to be done (main.cpp:7080). The total amount is added up at main.cpp:7114, then this is fed into GetDenominationsByAmount. GetDenominationsByAmount creates a unique integer via bitshifting for each combination of inputs (main.cpp:7533, main.cpp:7527). So that integer can be recreated by another client pretty easily without having to pass the entire datastructure all around the network (std::vector<CTxOut> vs int), it's a huge savings on that front. 2.) A DSA (Darksend Acceptable main.cpp:3928) is sent to a masternode with the total value that is going to be submitted. The next thing that happens is the masternode sees if it has any active sessions (main.cpp:7487), if it does it uses a few session variables. This is then fed into GetDenomationsByAmount, which gives us that bitshifted integer again. 3.) The masternode sends out a DarksendQueue object stating it's open for business, along with the bitshifted integer (main.cpp:6377). Then the next client when they run DoAutomaticDenomination, they'll look through those objects and see if they're compatible with any of the open sessions (main.cpp:7119). So as a result, we get to let clients pick the masternodes they use randomly and can use the entire network at once for all of the different combinations of denominations (which I'm really excited about, this is something that's been hard to achieve!). 4.) Then the signing begins and all of that jazz |
|
|
|
Unless I have to register on the forums of DRK and ask there, I would like to get some input from Evan or some developer on this. There are two things that concern me:
1. Outputs can still be linked to addresses. If you send 20 DRK and it sends all these other outputs along with it to obfuscate, the 20 DRK still ends up in someone's address. That this can be observed on the blockchain means that analysis is easy, and we all know how often people leak addresses associated with their wallet (eg. posting it up for giveaways etc. etc.) This is an immutable problem in any Bitcoin-forked cryptocurrency that exists, as the solution (stealth addresses computed w/random data) has to be enforced for every transaction from the genesis block. If you enforce it halfway through you're stuck with old outputs that don't use stealth addresses, which makes it exceedingly complex to ensure the anonymityset is not at-risk.
2. Masternodes are an Achilles' heel. Let us say that there are 10 000 masternodes on the network. Their IP addresses and the port they operate on is, by necessity, known to the network. Let's assume that an attacker controls 5 masternodes of the 10 000. Let's also assume that each of the masternodes on the network is on a dedicated server (none of them use a VPS, because a VPS could be trivially owned by the host operating system) and each of these servers is on a 1gbps unmetered, dedicated port (clearly not the case right now, but I'm talking about a future time). How hard would it be for an attacker to knock the other 9995 masternodes off the network, leaving theirs as the only accessible masternodes (and thus not only earning them all the fees, but giving them perfect insight into transactions moving within their controlled group)? Well, NTP amplification attacks have let attackers launch 400Gbps attacks against a single machine from a sole 2mbps connection. SNMP has a theoretical 650x amplification factor. All an attacker needs to do is max out the unmetered port in an obvious attack, and the datacenter will have to react. Even straight up LOIC-style / botnet SYN floods to the port that the masternode has open will lead to the the DC null-routing traffic to that box, typically for 6 hours whilst they wait for the attack to stop. Mitigating this is an extremely difficult and expensive operation for each masternode to individually undertake, and not all DCs will even be able to provide DDoS mitigation at this level. An unsophisticated attacker using extremely traditional tools can knock all of the masternodes off the network except those they control. This is a threat to anonymity.
Incidentally, the other problem with masternodes that nobody seems to have thought of is that the limited number of them will mean they're in direct competition with each other. It is in a masternode operator's financial interests to make life difficult for the rest of them - DDoS attacks, reporting the box to the datacenter, anything that can knock a single competitor off the masternode network means more fees for the remaining masternodes. This is different to PoW mining where, for instance, knocking the pools offline doesn't mean you'll get more transaction fees, as miners always have backup pools. I'm not sure how sustainable this is as a system if it unmistakably pitches operators against each other to fight for fees. Given the cost and capital required to own a masternode, it's appreciable that this will happen as a natural result of wanting to maximise masternode profits.
Anyone considering this FUD or something is an ignorant idiot. This is just objective input from another developer who obviously has high knowledge. Very good questions. I'm excited that we're starting to see some higher level questions again. 1.) Payee addresses are arguably the less important aspect of privacy. As the sender, it's more important to protect your identity. The other side can simply be addressed by generating a new change address per payment. Between the two of these the system would be completely anonymous. Also, after receiving payment, your client will prepare the funds again, increasing their anonymity. 2.) There's not a perfect solution to this yet, but Masternode operators have an interest in getting more darkcoin and keeping their existing inventment as valuable as possible. By attacking the network, they would cause harm to their investment. Also, the client is resistant to DDOS attack currently and masternode operators are instructed to close all other ports and have some kind of DDOS protection. As a longer term solution, we could not broadcast the IPs of masternodes, but an identifier. Users could then say they want to broadcast to that masternode, but not actually connect to it. This would hide the identities and create a much more robust system. |
|
|
|
...
Darkcoin suffers from a bad methodology to achieve anonymity and it's put everything into this one basket.
Sorry to hear you lost faith in the project. Also, sorry you're going to be getting out at a horrible time (right before I announce I have EVERYTHING figured out to make Darkcoin mainstream?). Over the past couple of days, I've made huge leaps in the Darksend technology. In fact, RC4 will be the final solution to Darkcoin's anonymity. The client will automatically look at all of your funds and it will be able to tell which funds are not anonymized, if it finds non-anonymous outputs it will run them through a darksend with other clients. After that process, users can send without Darksend using the anonymous outputs for instant transactions without waiting for other nodes (with no upper limit on transaction sizes). The other thing you're missing is that there is a reason I forked Bitcoin. Adoption for Darkcoin will be MUCH faster and easier for vendors, because all of the APIs are the same. Expect more news in a few days. I have lots of work to do, but soon we can start testing all of this new functionality. |
|
|
|
What's up with drkpool.com ? It redirects to some shitty site. There goes my coinz.
use drkpool.darkcoin.io, you have a couple weeks still to get out your coin. |
|
|
|
|
Hello everyone!
Yes I'm alive and have been very busy working. There's actually three of us working constantly on Darkcoin at the moment so there will be lots to report. We've been also working on a press release and I need a top secret flowchart remade, if you have experience making flow charts and have some time today shoot me a PM.
-Evan
|
|
|
|
|
Show Posts
