Gold taking off on the back of the Malaysian Airlines incident.
That means Bitcoin to follow + the rest of the alts to follow that.
I'm not following the correlation between these two things... Please, elaborate. Specifically, I see the Gold Crowd and the Cryptocurrency Crowd as polar opposites divided by the "backing" argument; those smart enough to realize backing is stupid are Cryptofans. Those too stupid to see that Au is just fancy Pb due to it's lack of fungibility and the fact that it can be lost, stolen, counterfeited, etc. It's now just an industrial metal... People with their heads stuck in the dark ages are AU supporters... Real gold bugs hate crypto like hell There are exceptions. Like myself. But I agree that for example over at zerohedge (gold bugs paradise), bitcoin is very much hated, both "tyler durden" and most of the people in the comment section are largely CONTRA bitcoin. All articles are PRO gold/silver... most articles about bitcoin have a negative undertone. They behave like prostitutes who don't like that another more beautiful and younger prostitute has entered their turf or something...  Why can't they love both, like me? (I mean the moneis, not necessarily the prostitutes) I read ZH as well, but have a bit more positive view. The Bitcoin articles seem more neutral to me than negative (in most cases). However, the comments section is indeed generally very negative (it doesn't help that many of the very few pro-btc comments are from complete tools). |
|
|
|
Experiencing some rather odd Masternode payment "variance". I have 3 nodes presently running, with monitoring showing they've never been down (once I got emails from the service, but I immediately checked all of them, and they were all still running). They show green on all of his servers as well as "1" in MN list. Highest present estimate of nodes (poolhash): 682 I had one go more than 8 days without payment (or votes): (681/682)^(576*  = ~0.00116 Worse, presently these 3 nodes haven't been payed (or voted) in more than 3 days: (679/682)^(576*3) = ~0.000492 I'll file this under category: "Unlikely" Edit: stupid smiley; should be ( 576 * 8 ) |
|
|
|
I forgot to mention... All the credit for the wallet/UI overhaul does not belong to me. We also owe a big thanks to Minotaur, raze and LittleFinger! I also want to thank the community for all of your support and gratitude, and your feedback on the design!  Thanks! -- The DRK Lord -- I lurk that thread hard, the mockups are beautiful. You guys (gals) are quite the team, thanks for doing the much needed overhaul! We got ourselves a DRK stalker! |
|
|
|
I don't know, I've had 3 nodes up for just over 3 weeks now with zero problems or downtime with any of them (local separated wallet.dat(s) launched with win-qt and remote Ubuntu VMs). Now payments over the last couple days are a totally different issue. |
|
|
|
Some Interesting Facts on Cryptocurrency Traders 1: average age is 20years 2: single male 3:speed trade (looking to make enough to pay rent) I feel like a grandpa. here 20 years? That's why the ADD issue and zero-patience for long-term projects / extremely short "investment" horizon. Why you gotta go and make fun of us 20 year olds? Fine, I'm not 20. Carry on. |
|
|
|
I think Camo's scenario is only an issue if everyone is using the exact same mixing depth. Differences in user-selected mixing depth create more or less randomized exit points, no? With volume, I'm not sure how you can provably link a sum entering the anon phase with a sum exiting.
Even he agrees there's no mathematical proof to it, but that's not really the point. |
|
|
|
the amounts being laundered are mixed with 10, 50 maybe 100 or even 1000 wallets, now if all goes through 8 mn, i would say i are going to have a real challenge to figure out what goes where. the beauty of private key vs public key is, you cannot figure out the private key by looking at the public key, and therefor you cannot point a given address to a specific person.
So, it boils down to denomination method coupled with volume, if there ever is that much... I think I saw mempool get up to 12 once... Even if a pubkey can't be used to make a privkey (the foundation of keypair encryption, so we presume it hasn't exploded yet), the sigs can still be verified as being related to the same privkey, even if we don't know the privkey. Isn't that the whole point of signing? So that the action or message can be certified as coming from the correct source? This, all pubkeys and signatures can be correlated tot he same privkey, even if we don't know what it is. We can still say "The same key did all this." I think PGP would be in a very sad state if that were not true... Not to mention all cryptocurrencies would be completely fucked... Thus, denominated sends still correlate to their aggregate value even if there are 1000 denomianted TXes all on the same block. We just wait for the same thing to happen on the exit end... A sent X to B. The MNs aren't actually mixing TXes, they're just signing.. Which makes me wonder; why even bother? So it's a fog... It's a fog that we can easilly identify that which goes in and out of said fog... So, uh, it's functionally like there is no fog. Say I walk into the fog, then I come out. Did I become a different person? Even if I change my short while in the fog, you can still tell by other traits that it's me... As far as I can tell, your whole case revolves around this: You've latched onto a trivialized case of Darksend+. The laundered amount and the transaction amount do not normally match! The only way they would match is if you laundered your wallet of 27 DRK and then emptied all the denominated addresses totally to a new address to pay for something costing 27 DRK. That's not how it will work in practical terms. You'll launder 27 coins and then send 12 of them to pay for something that costs 12 DRK. Now there's no suggestive link between laundering and transaction amount. These events also occur at different points in time (and for the laundering part, you can mix your coins 2 to 8 times over).
And what I had to say about it + others (take them at their own words): Just one point about this: sending your *full* balance anonymously has always been a problem (unless your full balance happens to be a denomination size (good luck)). It's not a problem that is easy to fix in a transparent blockchain model. I'm not sure it even can be fixed, but would love to read a solution to it. I have a solution. Don't do that. The QT client can warn the user that to send the full balance, the transaction should be broken into multiple transactions. It may even be able to space out transactions for you over multiple blocks. That would be a nice feature actually! It's not a problem anyway. Say you send your entire balance, and it's the only transaction in that block. An observer sees some randomly denominated amounts pass between multiple random addresses. What meaningful information can be gleaned from that? Bugger all, I contend. |
|
|
|
MNs will show up on the blockchain many orders of magnitude more often than non-MN clients. It's a blockchain-based form of traffic analysis. We can tell the difference between clients and MNs by this alone and it's REALLY obvious.
Not necessarily. When RC4 hits, there's going to be a frenzy of MN activity as everyone's balances get randomly denominated. After that, my gut instinct is that with increased actual use, the MN tx's aren't going to stand out at all amongst 'real' transactions. They're still going to be fundamentally different TX types: denominating transactions, versus combining (multiple inputs) transactions. The point is it doesn't matter. As I mentioned above, if you have, say, 27.000 DRK (27 DRK exactly, comma users), and you denominate it into whatever, and if you later recombine all your denominated addresses (via multiple input) to send 27 DRK to someone else (or even yourself), there exists a *suggestive* link between the original denomination TX and the new sending TX. It's not mathematical proof or anything, though. You've latched onto a trivialized case of Darksend+. The laundered amount and the transaction amount do not normally match! The only way they would match is if you laundered your wallet of 27 DRK and then emptied all the denominated addresses totally to a new address to pay for something costing 27 DRK. That's not how it will work in practical terms. You'll launder 27 coins and then send 12 of them to pay for something that costs 12 DRK. Now there's no suggestive link between laundering and transaction amount. These events also occur at different points in time (and for the laundering part, you can mix your coins 2 to 8 times over). Please don't think *I'm* latching on to that!  This is all in response to Camo's thought's/questions (just so we're all on the same page). |
|
|
|
MNs will show up on the blockchain many orders of magnitude more often than non-MN clients. It's a blockchain-based form of traffic analysis. We can tell the difference between clients and MNs by this alone and it's REALLY obvious.
Not necessarily. When RC4 hits, there's going to be a frenzy of MN activity as everyone's balances get randomly denominated. After that, my gut instinct is that with increased actual use, the MN tx's aren't going to stand out at all amongst 'real' transactions. They're still going to be fundamentally different TX types: denominating transactions, versus combining (multiple inputs) transactions. The point is it doesn't matter. As I mentioned above, if you have, say, 27.000 DRK (27 DRK exactly, comma users), and you denominate it into whatever, and if you later recombine all your denominated addresses (via multiple input) to send 27 DRK to someone else (or even yourself), there exists a *suggestive* link between the original denomination TX and the new sending TX. It's not mathematical proof or anything, though.This is very close to what I'm trying to explain. It doesn't absolutely PROVE anything, but it lets the nosy fuckers in on a hint that might find them something more... As such, it's not really helping anything... The banking laws for the EU have already been changed to declare deposits in savings are not actually your's anymore. If you're hiding your money in DRK, they can claim you've stolen your own money... Ask a Cypriot how that works out... Oh, you didn't notice that the entire European Union has quietly adopted that which Cyprus didn't quite get away with? All they need is a "suggestive link," that's what guvthugs call a "lead." It's not proof, but now they're all over you like a bad suit, and they don't even have to find anything. If they hate you enough, they'll just make shit up. You'll be yet another faux child pornographer locked away, you dirty pervert! If those addresses ever budge, they'll know who... I'm trying to demonstrate that this is a very good move by Evan, but it doesn't go far enough... I also might not understand it accurately and I await the Pimp Hand of Truth by one who actually wields it. Just one point about this: sending your *full* balance anonymously has always been a problem (unless your full balance happens to be a denomination size (good luck)). It's not a problem that is easy to fix in a transparent blockchain model. I'm not sure it even can be fixed, but would love to read a solution to it. |
|
|
|
The quantity going in and out of the mix is still obvious. Maybe it can't be tied to me with IP obfuscation, but block timing will still give away too much info Do you mean that the nature of the transaction could be identified simply from the amount being transacted ? An outside observer will have no idea whatsoever of the amount being transacted, because ALL transactions will use denominated amounts. It's just one big sea of zero useful information. That doesn't appear to be true from where I am standing. If I am standing in the wrong place, help me relocate. It seems you're missing the critical piece of the puzzle: the mixing. Multiple random-sized inputs go in, in multiple stages; denominated, homogeneous outputs come out at various stages. If you're not missing that, then your analysis does indeed apply, but only in cases of people mixing everything then sending the whole chunk back to some other address. Why would you do that? What would it accomplish? Point valid. BUT! They don't happen at random intervals. They happen all at once. But they don't happen all at once; mixing occurs over more than one round, and inputs don't all occur at round 1. Your inputs might begin at round 1 (in the graphic), while Joe's inputs might start at 2, and Sally's at 3, and so forth. So, the overall quantity can be correlated by sig. It's as if entry-point sends aren't denominated at all, even if they are. It still correlates. If 1, 5 and 10 go in at J, then 1, 5, and 10, come out at P, and 1, 5 and 10 are signed by the same key at J, and end up at the same place at P... X = 1+5+10 A sent X to B on block J and P. Somehow, we're not quite on the same page here.  (IMO) you might need to reword and flesh out clearly and exactly what you're saying, as it seems to be one of those things that seems clear in your head, but isn't translating that well to paper.Same analysis, you just have to build it backwards. Backwards or forwards doesn't matter when the chain is documented for all eternity. I await big cheese response. I want to be clear. I am not trying to troll or say "DRK iz brokenZ! Abadon ship!" Or any other such bullshit. I know that it is a work in progress, I'm just trying to figure out where the progress needs to be... If I'm way the fuck off, by all means, I crave the Pimp Hand of Truth. To your last point, we're on the same page there. |
|
|
|
MNs will show up on the blockchain many orders of magnitude more often than non-MN clients. It's a blockchain-based form of traffic analysis. We can tell the difference between clients and MNs by this alone and it's REALLY obvious.
Not necessarily. When RC4 hits, there's going to be a frenzy of MN activity as everyone's balances get randomly denominated. After that, my gut instinct is that with increased actual use, the MN tx's aren't going to stand out at all amongst 'real' transactions. They're still going to be fundamentally different TX types: denominating transactions, versus combining (multiple inputs) transactions. The point is it doesn't matter. As I mentioned above, if you have, say, 27.000 DRK (27 DRK exactly, comma users), and you denominate it into whatever, and if you later recombine all your denominated addresses (via multiple input) to send 27 DRK to someone else (or even yourself), there exists a *suggestive* link between the original denomination TX and the new sending TX. It's not mathematical proof or anything, though. |
|
|
|
The quantity going in and out of the mix is still obvious. Maybe it can't be tied to me with IP obfuscation, but block timing will still give away too much info Do you mean that the nature of the transaction could be identified simply from the amount being transacted ? An outside observer will have no idea whatsoever of the amount being transacted, because ALL transactions will use denominated amounts. It's just one big sea of zero useful information. That doesn't appear to be true from where I am standing. If I am standing in the wrong place, help me relocate. It seems you're missing the critical piece of the puzzle: the mixing. Multiple random-sized inputs go in, in multiple stages; denominated, homogeneous outputs come out at various stages. If you're not missing that, then your analysis does indeed apply, but only in cases of people mixing everything then sending the whole chunk back to some other address. Why would you do that? What would it accomplish? |
|
|
|
I agree that this makes sense for an objective, BUT:
Do the wallet-sent TX stand out in that mist? I still think the client should denominate before it sends to a masternode. This might happen by default per the pre-mix. But, sends from wallets are still not sends from identified MNs, so it's something identifiably not mist going into the mist... Thus, it might be identified coming out. I'd like to see a denominated multi-point-exit to shore this up. No ! That's the beauty of it - the transaction itself is now crystal clear which is what you want for verification, but the terminals are completely anonymous. He's separated completely the anonymising process from the transaction process which is a far more powerful configuration. There's now no practical chance of ever tracing anything because the start and end points are effectively virgin each time. You don't need to ever worry about how "visible" the transaction is because the network precipitates your holdings into a fresh address before you even send them. That's why I said he's "moved the goalposts" because instead of the emphasis being on anonymising the transaction (which is the weak link in the chain) it's now the addresses that are continually recycled and anoymised. That gives the network a *massive* level of redundancy in terms of anonymity. Even if another "algo" (e.g. cryptonote or whatever) were twice as reliable as DRK's, the DRK process would still blow it away because of the massive redundancy it has. Superb. If everyone's wallet will now contain nothing but 100,50,25,10,5,1 etc. amounts all in randomly generated addresses, this is the problem well and truly fucking solved, timing analysis becomes impossible. Want more anonymity than this? Start shopping for wigs and sunglasses. It's going to make rich-list bragging pretty hard though. The whole blockchain is going to look like homogenous heat death. Ahahahaha, fucking brilliant. No one can force you to denominate your coins though, so the rich list can be alive and well if its participants want it to be so. (if anyone is thinking the client could always do it without your permission, it really can't; there's no way to enforce it, besides having the clients discard addresses holding non-homogeneous coins after a certain period, which seems a * bit* harsh) |
|
|
|
The way I understand it, nothing is added to the blockchain between the green boxes. The masternodes never actually hold the funds, they just facilitate signing. Someone correct me if I am mistaken.
This is correct the masternodes never actually hold the funds they just facilitate transactions. Pardon me for playing Devil's Advocate: But, if the coins don't actually change hands, how does this obfuscate anything? XC is coin-forwarding (coins go to the node). DRK's masternode simply signs transactions. Please enlighten me further; elaborate. When I want to send you money through a DarkSend, the masternode does not receive my coins and forward it to you. This would be a trusted technique in which the node would potentially steal the coin. What the masternode does is use my keys for signing the transaction. It's a middleman who never owns my coins. In XC, for example, A sends the coins to node and then node sends coins to B. Can't the difference between signing and sending be identified? Yes. How does this obfuscate anything? It doesn't matter, because we don't know who/where the coins came from (the sending addresses aren't associated with anyone). You still need IP obfuscation to avoid a node associating a TX with your IP.This is rewinding the conversation a bit. No longer focusing on the mixing/denominating technique, but on the fundamental idea of whether or not anything is actually being obfuscated by MNs at all... OK, I thought I was right about that, but the announcement sounded almost like it was sying "this fixes everything" and it's really just a very large step int eh right direction with what I count as 5 small loose ends to be tied up yet. To me, what you're suggesting (requesting?) basically requires zerocoin/cash-type opaqueness; it goes beyond simple anonymity. In the new DRK, the blockchain is still very transparent, there's just *hopefully* no useful information to be gleaned from it. IP obfuscation is a separate and still very real vector that needs addressing. |
|
|
|
The way I understand it, nothing is added to the blockchain between the green boxes. The masternodes never actually hold the funds, they just facilitate signing. Someone correct me if I am mistaken.
This is correct the masternodes never actually hold the funds they just facilitate transactions. Pardon me for playing Devil's Advocate: But, if the coins don't actually change hands, how does this obfuscate anything? XC is coin-forwarding (coins go to the node). DRK's masternode simply signs transactions. Please enlighten me further; elaborate. When I want to send you money through a DarkSend, the masternode does not receive my coins and forward it to you. This would be a trusted technique in which the node would potentially steal the coin. What the masternode does is use my keys for signing the transaction. It's a middleman who never owns my coins. In XC, for example, A sends the coins to node and then node sends coins to B. Can't the difference between signing and sending be identified? Yes. How does this obfuscate anything? It doesn't matter, because we don't know who/where the coins came from (the sending addresses aren't associated with anyone). You still need IP obfuscation to avoid a node associating a TX with your IP.This is rewinding the conversation a bit. No longer focusing on the mixing/denominating technique, but on the fundamental idea of whether or not anything is actually being obfuscated by MNs at all... |
|
|
|
instead of bickering over whats the best algo for making an individual transaction disappear, just turn the entire f*cking coin supply into mist !!!
<snip> It looks like it's almost there to me... I'd start my explanation of why I say that by saying first, it looks like the mist moved from the client to the MNS, and the identifiable part moved from the MNs to the clients... Now, this is not 100% true because the clients are receiving pre-mixed. But quantities and timing are still potentially, sometimes identifiable. Noted, there is a percentage linked on a google docs spreadsheet. Probability it not absolutely. That's why it's called probability and not absolutely. <snip> Very good points. A good place to start with regards to the block cycle might be to assign it a random probabilty that stands to have it occur somewhere between every 5-15 blocks or so. The ultimate goal is to seamlessly hide the person-to-person transactions among the general mixing so that one cannot discern the difference. I know this probably won't be popular (speed-wise) but maybe a good approach would be for people to have the option to wait for the general mixing to send a transaction (built into the client)? It would certainly slow down transaction speed but if the transaction were synced with the general mixing it would be very difficult to track. It could be implemented in the form of a checkbox perhaps? Maybe call it DarkMist. I think this is expected behavior and isn't able to be masked (whether a TX is a user/buyer-to-user/seller or a denomination TX). By definition, when you denominate, change addresses are each going to receive homogeneous inputs; when you spend these inputs, you're going to use multiple inputs you need to come up with the proper amount to send to the user/seller. It's always been expected that these inputs will be associated with each other. So it's like: Mixing TX: random amounts > homogeneous amounts Sending TX: homogeneous amounts > random amounts You will always be able to determine which is which when there's only a single receiver address (which has been discussed thousands of pages ago, and determined unfeasible to use more than one). It doesn't matter when the mixing occurs; the "normal" TXs will be clear regardless. OK, but with regards to tracking transactions via timing, would it not afford greater anonymity to have the transactions as temporally close as possible? Outliers stick out like a sore thumb. I think timing becomes less of an issue because of the (relatively) long mixing process. Beyond that, I'm not quite sure what you're asking? "Normal" TXs will always be identifiable as such; this is by design and definition. It's just the senders' addresses aren't associated with anyone or anything. IP obfuscation should still be needed, though. |
|
|
|
instead of bickering over whats the best algo for making an individual transaction disappear, just turn the entire f*cking coin supply into mist !!!
<snip> It looks like it's almost there to me... I'd start my explanation of why I say that by saying first, it looks like the mist moved from the client to the MNS, and the identifiable part moved from the MNs to the clients... Now, this is not 100% true because the clients are receiving pre-mixed. But quantities and timing are still potentially, sometimes identifiable. Noted, there is a percentage linked on a google docs spreadsheet. Probability it not absolutely. That's why it's called probability and not absolutely. <snip> Very good points. A good place to start with regards to the block cycle might be to assign it a random probabilty that stands to have it occur somewhere between every 5-15 blocks or so. The ultimate goal is to seamlessly hide the person-to-person transactions among the general mixing so that one cannot discern the difference. I know this probably won't be popular (speed-wise) but maybe a good approach would be for people to have the option to wait for the general mixing to send a transaction (built into the client)? It would certainly slow down transaction speed but if the transaction were synced with the general mixing it would be very difficult to track. It could be implemented in the form of a checkbox perhaps? Maybe call it DarkMist. I think this is expected behavior and isn't able to be masked (whether a TX is a user/buyer-to-user/seller or a denomination TX). By definition, when you denominate, change addresses are each going to receive homogeneous inputs; when you spend these inputs, you're going to use multiple inputs you need to come up with the proper amount to send to the user/seller. It's always been expected that these inputs will be associated with each other. So it's like: Mixing TX: random amounts > homogeneous amounts Sending TX: homogeneous amounts > random amounts You will always be able to determine which is which when there's only a single receiver address (which has been discussed thousands of pages ago, and determined unfeasible to use more than one). It doesn't matter when the mixing occurs; the "normal" TXs will be clear regardless. |
|
|
|
instead of bickering over whats the best algo for making an individual transaction disappear, just turn the entire f*cking coin supply into mist !!!
I agree that this makes sense for an objective, BUT: Do the wallet-sent TX stand out in that mist? I still think the client should denominate before it sends to a masternode. This might happen by default per the pre-mix. But, sends from wallets are still not sends from identified MNs, so it's something identifiably not mist going into the mist... Thus, it might be identified coming out. I'd like to see a denominated multi-point-exit to shore this up. It looks like it's almost there to me... I'd start my explanation of why I say that by saying first, it looks like the mist moved from the client to the MNS, and the identifiable part moved from the MNs to the clients... Now, this is not 100% true because the clients are receiving pre-mixed. But quantities and timing are still potentially, sometimes identifiable. Noted, there is a percentage linked on a google docs spreadsheet. Probability it not absolutely. That's why it's called probability and not absolutely. If the client sent out DRK in the same denominations, and with the same IP obfuscation (which pre-suppsoes that there will be IP obfuscation added at some point) as the MNs used, there would be no way to know what the hell was going to where. IF change came out of the 8-box look randomly; 1) sometimes skipping a block in timing 2) some bits coming out earlier than others. (MN2 sends one hunk of denominated change, MN5 sends another hunk, etc) Then the when goes to hell too. Also, the 10 block cycle is a cycle, not a mist. It's the opposite of homogeneous... Then you've truly got a homogeneous mist going. The picture/updated info is a mist into which a somewhat thicker mist comes and goes... It's not quite homogenous. Don't take this as an insult or a troll. It's damn near perfect now. I'm just thinking out loud about how to make it a little MORE perfect... I wonder if blowjayxt, our resident homojenius wants to chime in on how this is or is not homogeneous? I'd thought of this as well, and it does seem superior (random exit points for change for mix > 2). It might be a pain to implement though; I think I need to mull it over a bit more. |
|
|
|
The way I understand it, nothing is added to the blockchain between the green boxes. The masternodes never actually hold the funds, they just facilitate signing. Someone correct me if I am mistaken.
This is correct the masternodes never actually hold the funds they just facilitate transactions. Pardon me for playing Devil's Advocate: But, if the coins don't actually change hands, how does this obfuscate anything? They are still mixed with all the other "dirty" coins with a group signature as before. They "do" change hands, just from your right hand to your left hand if you will. The additional nodes reduces the chance of collusion to near 0. Each "hop" occurs every ten minutes as specified; so your coins will be with multiple participants *each* hop Also, assuming user-defined mixing depth (or even just assuming minimum depth of two), coins would be entering and leaving the "train" (masternode chain in the graphic) at different intervals, not all after #8 (which would be an extended mixing time of approx. 3h 20m for your coins). |
|
|
|
I agree with the above. However, (to me) his tune seems to have kinda changed over the last few days. I'm not sure if he managed new success on the water or what, but he's overall less confrontation, almost even respectful at times. It's possible he got a few PM's from mods. And the conspiracy begins! |
|
|
|
|
Show Posts
