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

List of future development ideas

1. Quantum computing resistance for public/private keys. The algorithm currently used by Bitcoin isn't QC-proof. It will allow DRK to be "first Quantum Resistant" - offering hedging and diversification options for Bitcoin holders and expanding the innovation frontier. This will require some very expert advice from cryptographers to propose the right algorithms to use.

2. Quantum storage button (this should be easy): As long as the public key hasn't been published (no spends), and an address only has deposits in it, the lack of a public key prevents someone with a quantum computer to find the private key. So Quantum storage consolidates part or all of the wallet to a new single address that has never been used for spending.

3. We need a very strong encrypted system for transmitting addresses between merchants and users. If the merchant / client communication is intercepted, there is no anonymity even if the money flow is obfuscated. Hence the need for something like a browser popup that opens an encrypted channel in which the client can receive the newly-generated address and where he can write what he wants, where he wants it delivered etc.

4. We could consider running merchant shops on masternodes in something like an encrypted / I2P intranet. Not illegal stuff though.

5. We need to find a way in which prior change addresses are isolated and slowly spent or laundered, one by one, so that they can re-accumulate themselves "clean". Otherwise their simultaneous spending in the future breaks the anonymity through linking change (if I understand correctly the current DarkSend implementation). It would be like a process of "defrag"... Alternatively, the wallet should not pick up 2 separate change amounts from prior DarkSends for next DarkSends if a "paranoia" checkbox is ticked.

6. Stealth addresses could be useful for more casual sending.
 
1. Quantum computing resistance for public/private keys. The algorithm currently used by Bitcoin isn't QC-proof. It will allow DRK to be "first Quantum Resistant" - offering hedging and diversification options for Bitcoin holders and expanding the innovation frontier. This will require some very expert advice from cryptographers to propose the right algorithms to use.


Is this even possible at the moment? links to any papers about this?
 
From what I read there are quantum-resistant algorithms for that purpose - however I'm not aware of their other pros/cons...
The ecdsa that bitcoin uses though is as good as dead when a QC comes out (or if it's already out and nobody knows):
https://bitcointalk.org/index.php?topic=3008 (nice discussion here)
Our whole technology like SSL, PGP, etc. will be dead as soon as we have QC, this is not a Bitcoin issue at all.
I think measures will be taken soon enough.
 
The 8th idea is IMO of the highest priority for a wider adoption. A lot of people don't keep track of updates, are surprised when their wallet doesn't sync , may stay in a wrong fork or endanger the network. A notification when a new version is available and an update button would be a good addition.
But how to avoid a single-point-of-failure attack ?
1 - Create a // blockchain or a blockchain in the blockchain containing the last version number of the wallet, and the hash of the genuine executables.
2 - The MN can have as other function to host those executables.
3 - The wallet will check if the new version available in a MN is genuine before installing it (compare version number & hash of the // blockchain to the version number & hash of the MN).
What do you think about it ?
eduffield InternetApe TanteStefana LimLims ErrorId
 
Goodness gracious! I didn't realize so many points have come in, sorry! I'll update here... but gotta feed the animals first, LOL
 
Our whole technology like SSL, PGP, etc. will be dead as soon as we have QC, this is not a Bitcoin issue at all.
I think measures will be taken soon enough.
This is why a non-crypto approach such as what evan is doing is important (talking about the mixing). What Evan is doing is sort of a mechanical solution. It's a logic solution. It can't be broken by a quantum computer, because it's not a mathematical.
 
Last edited by a moderator:
The 8th idea is IMO of the highest priority for a wider adoption. A lot of people don't keep track of updates, are surprised when their wallet doesn't sync , may stay in a wrong fork or endanger the network. A notification when a new version is available and an update button would be a good addition.
But how to avoid a single-point-of-failure attack ?
1 - Create a // blockchain or a blockchain in the blockchain containing the last version number of the wallet, and the hash of the genuine executables.
2 - The MN can have as other function to host those executables.
3 - The wallet will check if the new version available in a MN is genuine before installing it (compare version number & hash of the // blockchain to the version number & hash of the MN).
What do you think about it ?
eduffield InternetApe TanteStefana LimLims ErrorId
I suspect people wouldn't like it because, as stated before, it might be hacked. But an update notification on it's own might be ok, as long as people have to go to the website to download the client.
 
I suspect people wouldn't like it because, as stated before, it might be hacked. But an update notification on it's own might be ok, as long as people have to go to the website to download the client.
That why I said that they can be hosted by every MN and that the hash have to be checked by the wallet. The reference being in the blockchain. If the hash is different it means that the executable has been altered.
 
I'm posting this here because it was deleted on bitcointalk by a mod, for no apparent reason:

Btw, as Evan is working on payments and later-on, on DarkSend itself, wouldn't it make sense for "parallel processing" so to speak? What I mean by that is that we know we need work on the IP obfuscation part, and it's unlikely he can work it out while working on payments.

The I2P part could be outsourced if anyone is willing to do it. Evan could issue the "specs" and have someone start doing it right now through a bounty. In this way the project is not linear (make A => make B => make C) but parallel in things that can be paralleled (make A and make B simultaneously). In this way we'll have a complete package sooner.

Things that can be paralleled by using developer resources from developers wanting to help or through bounties:

1. I2P
2. "Your client needs update" code for every wallet that is forgotten in some past fork
3. Stealth addresses if we want them as a parallel option to DarkSend
4. A system of anonymous encrypted communication that allows users and merchants to communicate their order/delivery/payment details etc. Without it, the anonymity is broken (the flow is obfuscated but communication between user and merchant is transparent).

...in this way we don't have to wait for A => B => C, but have A + B + C done in parallel, improving our market position. Altcoins are moving fast these days as DRK made them realize that without innovation they are just dead scrypt clones.
 
I would like to have ARM CPU suport for mining.
I curently have a script over on github for installing CPU mining software to any Linux device (32/64bit PC's, Android phones, Raspberry Pi, and VPS) which works great for all the the devices I've tested it on for mining Doge, Lite, Bit and Vert coins but due to errors in the make file I've yet to be able to mine Darkcoin on Android devices so far.
I've already done some digging and it looks like 64bit is the only CPU supported; is there a way to build and mine on ARM that I've missed?

Link to the github script mentioned if readers are interested in a quick installer
https://github.com/S0AndS0/Debian-K...s/CryptoCurrencies/CPUMiner_LinuxInstaller.sh

I'm also starting a script for installing and configuring P2Pool nodes for as many coins as posible so hit me up if there's a feture I should add to either.
 
I would like to have ARM CPU suport for mining.
I curently have a script over on github for installing CPU mining software to any Linux device (32/64bit PC's, Android phones, Raspberry Pi, and VPS) which works great for all the the devices I've tested it on for mining Doge, Lite, Bit and Vert coins but due to errors in the make file I've yet to be able to mine Darkcoin on Android devices so far.
I've already done some digging and it looks like 64bit is the only CPU supported; is there a way to build and mine on ARM that I've missed?

Link to the github script mentioned if readers are interested in a quick installer
https://github.com/S0AndS0/Debian-K...s/CryptoCurrencies/CPUMiner_LinuxInstaller.sh

I'm also starting a script for installing and configuring P2Pool nodes for as many coins as posible so hit me up if there's a feture I should add to either.
Couldnt you just compile the cpuminer on arm platform?
 
Couldnt you just compile the cpuminer on arm platform?
I have tried it; three different forks with different "CFLAGS" and "make clean" commands run between fails. If we can get ARM suport I'll be adding Darkcoin to the app I'm researching to build for Android :-D currently I use the "Debian Kit" app from Google play store for Installing ARMel (soft float) and it works at the same hashing rate as the Mining apps available on the play store. I'll be off work earlier tomorrow and will be back to testing this among the other coins I'll be adding into the previously linked script.
... Edit and update ... This is the error I'm getting with Qubit and Dark coins on ARM processors :-: emmintrin.h "fatal error : emmintrin.h : No such file or directory."
I do not recive these errors with original cpuminer or Vert and Quark coin forks.
I've checked all dependancies, and performed a fresh Linux install too.
 
Last edited by a moderator:
1) What about a set of rules for pre-authorized automated handling of coins or other actions? For example:
- If balance > 1050, send 50 DRK to <address> (this could be used by MN operators or miners to send profits to an exchange or consolidate to one computer)
- If payment received, send notification email to <emailaddress> (this could be useful for merchants to be notified of payments)

2) Something like VeriBit, which is a service that allows you to send Vericoin to merchants that accept Bitcoin. This would be HUGE, giving Darkcoin users instant access to all merchants that accept Bitcoin (and could even be a profit center for Darkcoin development / foundation by charging 1-2% for processing or something).

3) Preview a transaction button (e.g., see how much transaction fees will be). Right now, a user has to hit "send" on a transaction and the user might be worried how much it will cost... yes, the wallet will tell him/her that there is a fee and and ask "do you still want to proceed", but new users might not realize that the warning will come up and be concerned about the fee (especially if they are transferring a small amount like from mining on their PC).

4) Automatic notification of a qt upgrade available.
 
I think it would be really cool if our POW would somehow benefit society by tying it in with some of the projects in BOINC such as Seti or Protein Folding. In order to solve a block, the miner would have to do some work for SETI or something similar. Primecoin is already doing this by calculating large primes (http://bitcoinmagazine.com/5635/primecoin-the-cryptocurrency-whose-mining-is-actually-useful/). There is another coin out there called GridCoin (http://www.gridcoin.us/) that uses Seti but it only had a Windows client and you had to have the BOINC client running at the same time. Wouldn't be cool if all that processing power used to mining could be put to good use?
 
Wow, a lot of these ideas are now in the wallet! Keep it up everyone! This is great!

DeathRay, that would be cool, but at the moment we need to keep it hard to make asics and I think that having so many algos makes it a bit harder to create asics at the moment. I'm trying to understand more deeply if there is anything good about having asics? If not, perhaps our primary goal should be to remain flexible so that algorithms could be switched out at any time?
 
How about the Darkcoin Browser Idea,

The Tor Protocol forked to be used with master nodes, But you need Darkcoins to be able to use the service, some very minor fee gets payed to the MN owners.

That way there is a demand created for owning DRK and people can benefit from more secure exit nodes. +MNs get a extra fee

Edit: LOL Evan did the announcement 2hr after I posted this
https://darkcointalk.org/threads/development-update-august-19-2014.2086/
 
Last edited by a moderator:
DarkTor seems like another great idea coming from Evan especially if it would be "a lean version, that has much higher throughput." (than the "original" Tor which slowness drove me insane)
 
decentralized cloud storage

masternodes are perfect for that task
I'm not sure we can compete with Google Drive or Dropbox on that field. And MNs doesn't have that much disk space I guess.
What MNs are good for is something about verifying or transmitting but not for holding things imo. That's a network of nodes after all. :wink:
 
Back
Top