• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Development Update - July 30th

i am generally excited about all this
but i only posted that fork question, as i understood it was kind of a problem.
Spork or Hardfork senario, but if you guys tell me to chill and live with the Spork,
so i will ....>>
and did not want to distract from the great update from the MASTA himself (above) ...>
 
Last edited by a moderator:
As I can only guess what you mean by "IP-address matching", I'd say that the proposed IP obfuscation mechanism solves that. It's actually the concept of Tor ported to the masternode network.
and without any equivalent of a browser footprint to track.

EDIT : I'm looking for a few thousand burly workers to commence a 400/500 year, multi-generational project in building a group of huge monstrous monolithic stone structures in various parts of the world honoring his Galactic Prime Duffness. I'll be drawing up plans shortly.
 
I would prefer to use the public key...
Well ECDSA encryption (what darkcoin and bitcoin use) is not the same as an asymmetric encryption such as PGP, which you may be more familiar with. You cannot give someone a bitcoin public address and have them use that to encrypt a message. You can, however, encrypt a message with the private key and decrypt it with the public key.

I had this thought as well. How would the user client acquire the privkeys of these masternodes without risking the security of the given masternodes?
Evan didn't mean the same private key associated with the actual masternode address itself I would not imagine.

eduffield If my assumptions were correct, I would be curious and slightly concerned with the performance impact this could have on masternodes. This would mean masternodes would readily be accepting incoming connections which would force them to use a non-trivial amount of processing power to decrypt. This may open up a new DDOS vector. As for mitigation, you could just rate-limit how many incoming connections you would be willing to accept, but then instead of the MN itself being DDOS'ed, the network would be DDOS'ed and there would be no room for valid entries.

IP obfuscation is an interesting problem because it is so _easy_ to solve on an individual level but so challenging to solve on a protocol level. However I do think it is important to solve on a protocol level. Whatever can be done to make the process as seamless for the user is critical.

I did have one potential alternative solution I came up with a while back, though my implementation is only high-level and I am not confident all the details would click in reality. However, the way I see it, the darkcoin network, as a whole, essentially is a P2P mesh. When you broadcast a transaction, you send it to any node, who then forwards it on again and again. However, this mesh network could be utilized slightly more. Instead of openly broadcasting a transaction to the network, what we could do would be to attach another variable (HOP_COUNT_REMAINING) to a transaction and only broadcast it to one node. When a node receives the transaction, it decrements HOP_COUNT_REMAINING, and sends it to another node. Because the starting HOP_COUNT_REMAINING is random, no one, not even the original node who received the transaction, would have any idea at which point in this chain they were. And not until the hop count reached 0 would the transaction actually be pushed onto the open network as a transaction. There clearly are some issues with this, but it is just something to think about!
 
Ok nice. What is the standard fee btw?
It can vary depending on the size of the transaction data, so there is no simple answer for this.

Recently there was an "attack" on the Tor network by researchers that tried to see if they could anonymize Tor users. I was just worried about the IP obfuscation so that we don't inherit open holes from the Tor network (even though I am not sure in what way the "attack" on Tor was conducted and if it is inheritable by adopting the same style on our IP obfuscation).

Thank you for your answers btw.
The attack you are referring to is not likely. In that attack, malicious nodes nodes were encoding identifiers into a spot in the header of data being sent. Other malicious nodes would later be able to decode that data to identify that it was the same chunk seen earlier. When the attacker had a lot of nodes, this allowed the attacker to find out what user ip was connecting to service ip, but only when both the first and last nodes were owned by the attacker. The attacker still couldn't read any of the data being sent, they could only see that a connection occurred. Since the attack is about abusing the ability to encode some data into headers, the problem is not with the idea, but the implementation.

In the darkcoin version, the protocol will most likely be much simpler than tor, which results in less places to attempt to hide things, and should be easier to secure. Without a place to stash data, in order to identify an ip to an address, the attacker would have to own all masternodes involved(3 for obfuscation + selected masternode). Since coins are mixed several times before being used, even if the attacker was to get lucky and have a transaction go through only nodes owned by them, it wouldn't likely tell them much, as it would only be one step of mixing they see. For an attacker to be lucky enough to see a whole set of mixing cycles for some coins, they'd have to own a significant portion of all masternodes, which would be very costly.
 
Because the starting HOP_COUNT_REMAINING is random, no one, not even the original node who received the transaction, would have any idea at which point in this chain they were. And not until the hop count reached 0 would the transaction actually be pushed onto the open network as a transaction. There clearly are some issues with this, but it is just something to think about!
The first node would know the originator because it's not any of the masternodes?
 
The first node would know the originator because it's not any of the masternodes?
Nope, I wasn't talking about masternodes, I was talking about normal wallets. It has to be normal wallets instead of masternodes for that reason
 
OMG this stuff is getting crazy complicated. I can see surely now where the boys get separated from the men in the sense that the coins that are intellectually unchallenging, but market blingy scam thingy rich will die soon and this coin will thrive. With emerging markets and ecosystems so rich in thought provoking ideas and innovation this Darkcoin is going to bring what the world has yet to see. Dang this is just plain exciting. Thanks for letting me buy enough at first to be a part of this, and contribute to what I am certain will be part of the future.
 
Dang this is just plain exciting. Thanks for letting me buy enough at first to be a part of this, and contribute to what I am certain will be part of the future.
Good to see our buyers happy. You understand the future nicely. I said pretty much the same thing the day I signed up here.
I just hope the price stays this low for enough critical mass to adopt because then merchants can participate.
With bitcoin the price rose so prolifically high and suddenly, without the many services we have today. Dark is gonna kill it.
 
Good to see our buyers happy. You understand the future nicely. I said pretty much the same thing the day I signed up here.
I just hope the price stays this low for enough critical mass to adopt because then merchants can participate.
With bitcoin the price rose so prolifically high and suddenly, without the many services we have today. Dark is gonna kill it.
Yes it will.
 
I would like to see it run on testnet for at least 30 days without any errors at all... Needs to be 100% when its released. Please Evan, no rush.
I agree. Please don't rush, Evan. This is so important.

I agree wholeheartedly with the general sentiment, but for trailblazing software of this complexity, waiting till at least 30 days have passed on testnet without even a minor bug isn't realistic if we want RC4 released this year. There is ALWAYS one more bug.
 
Well it's good not to rush things, but on the other hand... I guess that week after last update whole testnet will go to sleep (little ot no activity) and this way no bug gets discovered.
Let's leave this decision on developers. I'm sure they learned from past and they release it only when sure no major bugs can appear.
 
It can vary depending on the size of the transaction data, so there is no simple answer for this.


The attack you are referring to is not likely. In that attack, malicious nodes nodes were encoding identifiers into a spot in the header of data being sent. Other malicious nodes would later be able to decode that data to identify that it was the same chunk seen earlier. When the attacker had a lot of nodes, this allowed the attacker to find out what user ip was connecting to service ip, but only when both the first and last nodes were owned by the attacker. The attacker still couldn't read any of the data being sent, they could only see that a connection occurred. Since the attack is about abusing the ability to encode some data into headers, the problem is not with the idea, but the implementation.

In the darkcoin version, the protocol will most likely be much simpler than tor, which results in less places to attempt to hide things, and should be easier to secure. Without a place to stash data, in order to identify an ip to an address, the attacker would have to own all masternodes involved(3 for obfuscation + selected masternode). Since coins are mixed several times before being used, even if the attacker was to get lucky and have a transaction go through only nodes owned by them, it wouldn't likely tell them much, as it would only be one step of mixing they see. For an attacker to be lucky enough to see a whole set of mixing cycles for some coins, they'd have to own a significant portion of all masternodes, which would be very costly.
With this type of attack in mind, albeit unlikely, should we consider a way of verifying that a mastermind is using unmodified (I.e. authentic) code? My thought is that one drk goes open source, someone could modify the code to open all there wrappers on a transaction (just an example) then re wrap it correctly and pass it on while logging the originating IP. I suspect there are already many safeguards against tampering with the transaction itself, but if I was looking for a place to attack the network, it would be in the obfuscation and mixing protocols.
 
Back
Top