Development Updates - July 15th

[MangledBlue]

Got home, fixed dinner, did stuff - seen the SPIKE on the charts - came here - FOUND THIS ! ! !
<<< can't wait to see what happens next >>>
teehee . . . like a school girl :-D

 

[Carrot]

How awesome a group of crypto forging, pushing, innovative, badasses, above all the rest are you guys. I mean the trolls on the bitcoin forum catch my eyes with new coins so I go to look at them just out of curiosity. Well I know curiosity killed the cat so I know better than to abandon this ship. Never am I in awe after reading what all the other coins are doing compared to DRK. This DARKSEND+ is just so technologically far ahead and above, guess I should just say superior, to all the rest of the advertised tor network that has been infiltrated bla bidy bla talk sent out to the poor people who maybe did not understand the need for this type of masternode implementation. This flowchart explains very detailed processes and mathematical processing in my kind of terms so I know my leg is not being pulled into crypto fool land. I appreciate the updates very much and am just so astonished by this communities hard work and dedication to make this the new standard in privacy centric denerology : ) . I cannot wait to see what is next. Being able to have a looking glass in to the future of cryptographic monetary processing is so just bad ass to the bone its mind blowing to think I am part of the future now. I just can't wait until more people actually understand a little bit more. I think when the new wallet GUI comes out I am going to make a YouTube if knowone is opposed. One from obtaining bitcoin to buying dark on one of the exchanges maybe this is my chance to set up my bitfinex. Ah I'll stop now, but did I say how exciting all this is?

 

[LonnieDRR]

very cool!! I like how things are progressing.

 

[daaarkcoins]

What happens with change.

Have a look at the flowchart again. There won't be change.

 

[crowning]

[...]Every 10 blocks, user clients network-wide will send any unmixed, traceable Darkcoins in their possession through an anonymization phase. In this phase, Masternodes are used in chained succession to mix the coins they receive from the network and break them down into homogenous denominations. After being processed by a minimum of 2 Masternodes, the coins are either sent to the next Masternode in the chain or back to the user’s wallet at randomly generated change addresses.

What happens when one (or all) masternodes involved break down/get hacked/do intentionally bad things/... while _my_ coins are on their trip to anonymity?

Was this question not answered so far because...

1. it's incredibly dumb because it's already answered on page one of a manual I don't know of?
2. it's even more dumb because it's trivial to find out by firing up some Masternodes in a source-code debugger?
3. it's already answered in about 10000 posts but I always failed to enter the proper search string in the forum search?
4. I'm already on everyone's ignore list ?
5. nobody cares because Evan knows what he's doing?
6. nobody knows (really?)
7. [ insert your preferred option here ]

Curious minds would like to know...

 

[fusecavator]

Was this question not answered so far because...

1. it's incredibly dumb because it's already answered on page one of a manual I don't know of?
2. it's even more dumb because it's trivial to find out by firing up some Masternodes in a source-code debugger?
3. it's already answered in about 10000 posts but I always failed to enter the proper search string in the forum search?
4. I'm already on everyone's ignore list ?
5. nobody cares because Evan knows what he's doing?
6. nobody knows (really?)
7. [ insert your preferred option here ]

Curious minds would like to know...

The coins are never in the control of the masternodes, so you'll still have them.
Here is the process:
Your client sends what transaction it wants to do to the masternode.
The mastenode crafts a transaction joining multiple peoples' transactions together, however it needs all of them to sign off on it.
The masternode sends out the that transaction to the people involved, so they can check it and sign off on it.
The clients check to see that their inputs and outputs are in the transaction sent to them.
If they agree that it looks right, they send a signature for it to the masternode.
Once the masternode collects up the signatures, it can publish the transaction.
As the coins are never under the masternode's control, if it fails to complete the process your coins will still be in your wallet, just not mixed.

 

[TsuyokuNaritai]

The coins are never in the control of the masternodes, so you'll still have them.
Here is the process:
Your client sends what transaction it wants to do to the masternode.
The mastenode crafts a transaction joining multiple peoples' transactions together, however it needs all of them to sign off on it.
The masternode sends out the that transaction to the people involved, so they can check it and sign off on it.
The clients check to see that their inputs and outputs are in the transaction sent to them.
If they agree that it looks right, they send a signature for it to the masternode.
Once the masternode collects up the signatures, it can publish the transaction.
As the coins are never under the masternode's control, if it fails to complete the process your coins will still be in your wallet, just not mixed.

Will another attempt to mix them be made automatically, or must the user do it manually?
Must every client wait for every other client whose coins their coins are being mixed with? How many clients is that on a typical 8-masternode transaction?
Thanks.

 

[Walter]

I'm blown away with the speed of development going on here.. So - first off - hats off to the dev team and everyone involved in the project for all their hard work!
A couple of things have crossed my mind though...

I totally get the need for multiple masternode mixing, however:

1. How does the math work when it comes to all of these additional transactions, i.e. 1 'real' transaction could take many multiples of that during the mixing process to succeed in creating a truly anonymous transaction? Is that correct? Will it therefore exponentially increase the rate of growth in the blockchain at an unsustainable rate?
2. Kristov Atlas mentioned the possibility of denominations used in the mixing process being in a base 2 form rather than decimal in his recent web vid. What are the Dev's initial thoughts on his comments?

I'm a relative newcomer to crypto so hope my questions don't come across a bit dumb. Hopefully it'll stimulate some interesting discussion...!

Thanks.
Walt

 

[crowning]

The masternode sends out the that transaction to the people involved, so they can check it and sign off on it.
The clients check to see that their inputs and outputs are in the transaction sent to them.
If they agree that it looks right, they send a signature for it to the masternode.

That feedback from the Masternode back to the client was the point I was missing....thanks a lot for this great explanation :thumbsup:

 

[fusecavator]

1. How does the math work when it comes to all of these additional transactions, i.e. 1 'real' transaction could take many multiples of that during the mixing process to succeed in creating a truly anonymous transaction? Is that correct? Will it therefore exponentially increase the rate of growth in the blockchain at an unsustainable rate?

Extra transactions will cause extra bloat. Fortunately, space is cheap, and the blockchain isn't growing that quickly, so it's unlikely to become unmanageable any time soon. If it truly did get too large(keep in mind that bitcoin's blockchain is only up to about 20GB, which although annoying to download, is hardly significant for current hard drives), there are some things that could be done to try to lower it. The current block data compresses very well, and just for the sake of testing, I ran it through winrar and was able to decrease the size by more than 40%. Obviously that isn't a format you'd try to run in-line, but I'm sure you'd get significant gains with something else that you could use to directly save and load compressed data. Another possibility is blockchain pruning could be attempted to be done, although that would likely be controversial, as it would break the ability to verify all the way back to the beginning.

 

[TanteStefana]

Extra transactions will cause extra bloat. Fortunately, space is cheap, and the blockchain isn't growing that quickly, so it's unlikely to become unmanageable any time soon. If it truly did get too large(keep in mind that bitcoin's blockchain is only up to about 20GB, which although annoying to download, is hardly significant for current hard drives), there are some things that could be done to try to lower it. The current block data compresses very well, and just for the sake of testing, I ran it through winrar and was able to decrease the size by more than 40%. Obviously that isn't a format you'd try to run in-line, but I'm sure you'd get significant gains with something else that you could use to directly save and load compressed data. Another possibility is blockchain pruning could be attempted to be done, although that would likely be controversial, as it would break the ability to verify all the way back to the beginning.

Also, one of the exciting opportunities that Masternodes provide, is that they can host the blockchain, decentralized, for lightweight users. I hope this feature happens soon. So only the masternodes, mining nodes and people who want to have a copy of the blockchain ever need have it. And yet it will still be stored in a decentralized fashion.

I'm also still wondering about what thelonecrouton said. Was he implying that with a muddy blockchain, we can't verify the validity of the coins (that they're true mined coins?) Or was he saying something else? I'm confused? Thanks!

 

[Brilliantrocket]

Another option is the mini blockchain, as implemented in Cryptonite. https://bitcointalk.org/index.php?topic=643758.0
This is more theoretical, as it appears there are certain downsides to such an implementation.

 

[flare]

Also, one of the exciting opportunities that Masternodes provide, is that they can host the blockchain, decentralized, for lightweight users. I hope this feature happens soon. So only the masternodes, mining nodes and people who want to have a copy of the blockchain ever need have it. And yet it will still be stored in a decentralized fashion.

You may have noticed that i am currently porting the electrum client to DRK --> https://darkcointalk.org/threads/darkcoin-drk-electrum-server.1648/page-2#post-12249

Doing so, i had the same idea of masternodes being "full nodes", whereas the "usual" client is only lightweight.

 

[TanteStefana]

You may have noticed that i am currently porting the electrum client to DRK --> https://darkcointalk.org/threads/darkcoin-drk-electrum-server.1648/page-2#post-12249

Doing so, i had the same idea of masternodes being "full nodes", whereas the "usual" client is only lightweight.

Thanks flare, I just sent a long overdue donation

 

[TanteStefana]

You know, I don't understand the seemingly arbitrary size limits of sending coin? I just sent some and wasn't charged a fee, then I send the same amount to someone else and I am charged a fee. Why is that? I'm not using Darksend.

forget the above, I just didn't notice the notification. I was charged a Transaction fee both times

 

[flare]

You know, I don't understand the seemingly arbitrary size limits of sending coin? I just sent some and wasn't charged a fee, then I send the same amount to someone else and I am charged a fee. Why is that? I'm not using Darksend.

Fee is depending on "complexity" and (binary) size. So if the second transaction had several inputs and the resulting rawtransaction was large, it is considered more complex than the first one (to me) which only had one input

 

[crowning]

Also, one of the exciting opportunities that Masternodes provide, is that they can host the blockchain, decentralized, for lightweight users. I hope this feature happens soon. So only the masternodes, mining nodes and people who want to have a copy of the blockchain ever need have it. And yet it will still be stored in a decentralized fashion.

This!

I disagree with the statement from fusecavator that the blockchain size isn't that important, because I'm on a slowish ISP and a day of Bitcoin-blockchain needs 30-60 minutes to download.

Masternodes holding the blockchain and slim clients would be a dream for me.

 

[vertoe]

This!

I disagree with the statement from fusecavator that the blockchain size isn't that important, because I'm on a slowish ISP and a day of Bitcoin-blockchain needs 30-60 minutes to download.

Masternodes holding the blockchain and slim clients would be a dream for me.

That's in the works already.

 

[daaarkcoins]

Using electrum as-is would render darksend useless as the client sends a list of all your wallet's addresses to a single electrum server. You'd need to ask one server per address to not connect your addresses with one another. That's massive overhead and doesn't seem practical.

edit: Having masternodes make a snapshot of all known addresses' balances every 1000 blocks that clients can download seems much more practical to me. You'd download the latest snapshot + up to 999 blocks after that or just the missing blocks if that means less data to download (e.g. if the blockheight is 19004 and you already have block 18950 in your database).
That'd give you the same privacy as using a full node wallet.

 

[TanteStefana]

Thank you daaarkcoins, for pointing that out!

 

[fusecavator]

Having masternodes make a snapshot of all known addresses' balances every 1000 blocks that clients can download seems much more practical to me. You'd download the latest snapshot + up to 999 blocks after that or just the missing blocks if that means less data to download (e.g. if the blockheight is 19004 and you already have block 18950 in your database).
That'd give you the same privacy as using a full node wallet.

Considering it's not good enough to simply give out the balances, as transactions have to reference their inputs, downloading a list of all unspent inputs every time a wallet is opened is likely far more data than the user wants to download, and could put too much stress on those serving it repeatedly. A better idea might be for full nodes to still maintain lists of all inputs, however have multiple smaller lists that one can request. If each address's inputs were stored in a list determined by something like: take_first_2_bytes(SHA256(address)), a user would be able to request the list containing the information they want without giving away which part of it they want, and only download small subsets of the full list.

 

[bananarepublic1004]

When is the next announcement. The market is starting to loose faith on DRK

 

[canibalbranco]

When is the next announcement. The market is starting to loose faith on DRK

The market is stupid now!
Wait a little longer ...

 

[vertoe]

The market is stupid now!
Wait a little longer ...

Don't wait, buy.

 

[Light]

The market is stupid now!
Wait a little longer ...

You wait now, you miss the train. The next price hike (RC4) is not gonna be gradual. It is gonna be very fast. So fast that exchanges might experience lag/shutdown and when the market is back online the price will be too high already. Experience speaks I wish i had more extra money to invest in DRK.

EDIT: This is what i was talking about. People now buying thousands of darkcoins at a time. We will not see gradual price hike. Price will teleport to the moon within hours: http://imgur.com/VDimo9s

 

[LonnieDRR]

You wait now, you miss the train. The next price hike (RC4) is not gonna be gradual. It is gonna be very fast. So fast that exchanges might experience lag/shutdown and when the market is back online the price will be too high already. Experience speaks I wish i had more extra money to invest in DRK.

EDIT: This is what i was talking about. People now buying thousands of darkcoins at a time. We will not see gradual price hike. Price will teleport to the moon within hours: http://imgur.com/VDimo9s

This post makes me happy!

 

[acidburn]

I'm getting more as I type but sadly I can't afford much!!

 

[HammerHedd]

Considering it's not good enough to simply give out the balances, as transactions have to reference their inputs, downloading a list of all unspent inputs every time a wallet is opened is likely far more data than the user wants to download, and could put too much stress on those serving it repeatedly. A better idea might be for full nodes to still maintain lists of all inputs, however have multiple smaller lists that one can request. If each address's inputs were stored in a list determined by something like: take_first_2_bytes(SHA256(address)), a user would be able to request the list containing the information they want without giving away which part of it they want, and only download small subsets of the full list.

Would it be possible to implement a torrent-like blockchain download, with both light and heavy clients participating? With a system like that, it would a) be more difficult to tell who wanted what part of the blockchain because everyone would receive different parts asynchronously and b) allow light clients to move recent blocks faster while full nodes could push the larger blockchain with the older transactions. Consider that a new wallet doesn't really needed the last two years worth of transactions, so a light client might have a creation time stamp and only load/store transactions newer than that time.