I was thinking the same thing... one reason I can think of is nervousness of having way too much money on a single exchange... you want to be exposed for the least time possible and move out of there ASAP. Could explain the upward impatient move.

If you know there is a large dumper and you want all his DRKs, why not put large orders in place. What I'd do differently is wait at 51 instead of 57. It's not like the dumper hesitates to take it that far down. If they are stolen Mintpal DRKs it's possible a -10/-15% is not very important for the dumper.

It could be substantially more than 1000 SPR. The number of 1000 DRK was decided so that masternodes would be expensive and that someone would not buy / control a lot of them cheaply... the price was decided when DRK was around 0.0015 BTC (and it was understood that the price would rise over time - now it's 4x at 0.006)....

SPR is currently at a weak* 0.00025 which would require 24.000 SPRs to run an equivalently expensive node as Darkcoin's. But given the low liquidity this is unlikely, so the price per SPR has to rise instead. Or a mix of price-rise and something like 3000-5000-7000 coins per node could be the result.

* Meaning that even 10 bitcoins of purchases will easily multiply this price. Buying 24.000 SPR at 0.00025 is unlikely.

Hmm... I would think that diamonds, being unique / non-uniform / subjective in their valuation, are not a very suitable for backing assets of financial instruments. Precious metals on the other hand are much better suited for this job. They are divisible and fungible.

I was thinking that it shouldn't be too difficult, code-wise, to create 2-3 buttons or options in the qt client that would restart the wallet with such options.

It would be extremely useful to prevent "scares" for users who do not know how to recover, reindex or delete/reset a broadcast and who come here for help.

It would be much easier, support-wise, to simply tell a user "click on the reindex button", or "click on delete unconfirmed payments" (which would automatically restart the client in this mode).

CMD-line is so 80's and 90's....

I think the author has, by accident I suppose, started the article from the wrong angle of trying to hide one's wealth from the state and the tax collector and, to a non-crypto audience, it might sound "bad". "Oh these people are the wealthy fuckers who don't want to pay taxes" etc etc.

In this era, "tax evasion" is like "terrorism" and "child porn": An excuse for totalitarian controls over our lives.

The end-goal of the Elite is to have a centralized, electronic, global currency where all of the transactions can be monitored (by them) and as an added bonus they'll be able to force compliance of the citizens by cutting them off from transacting - kind a like the sanctions on nations that are prevented from global exchanges and global trade.

Bitcoin, being decentralized, preempted their plans as it can represent the alternative of choice for all those who do not desire the global financial control through a centralized electronic currency. Darkcoin took it a step further by obfuscating the transactions, increasing the level of privacy.

In a sense, Bitcoin, Darkcoin and other anon-cryptos are the alternative to the monopoly of tomorrow of the Elite's electronic currency. They are ahead of their time and the needs that will arise once the global monetary system is reshuffled in favor of centralized electronic currencies instead of cash. We'll hear all kind of reasons on how electronic money will be better for us as there will be no tax evasion and how it will benefit the poor (lol), how it'll be "safer" against cases like terrorism funding etc etc etc. And all those evils will then be projected on btc, drk, etc etc.

You could say the exact same thing for Gold and Silver... if Russians aren't buying it as a hedge to the ruble, then PMs are surely "finished". But we are not really factoring in market manipulation and perception management. For Bitcoin in particular, the idea is to have Bitcoin portrayed as the worst investment of the year in a large number of financial and mainstream articles.

What's happening is not by accident... The price pressure, the timing of the auctions, articles like "is bitcoin done?" etc are co-ordinated.

TPTB want to highlight in every financial and mainstream media the message that "the worst investment of 2014 = bitcoin". Just count the number of articles with that theme in the next couple of weeks.

Size is indeed an issue from what I've read, but at some point it has to be done.

As for the alternate method, if you reveal it only during the time of the transaction, the time that the public key is exposed is minimal... the attacker must "race" ahead of you to not only extrapolate the private key (using his Quantum Computer) but also broadcast a spend transaction (with the cracked private key) that is processed by the network faster than yours.

Good stuff...

May I also propose a few more suggestions, beyond the fixing / upgrading of the masternode payments system?

1) Block time of 1 minute could create bloat in the long run and might need upward adjustment. It is also worth looking into a mini-blockchain integration. If InstantX is also copied from Darkcoin in the future (something that only coins with masternodes can emulate - and spreadcoin will be in that position), block time can be safely revised upwards.

2) There are two DarkSend parameters which can be tweaked for a DarkSend implementation that can differentiate spreadcoin: Default and max mixing rounds. So Spread could opt for better anonymity by default by increasing the default number of rounds and taking the max number of rounds to 10 or beyond instead of 8 max (DRK).

3) Darkcoin faced an interesting problem with the compromise between speed of mixing and sybil resistance*. With 2 participants speed was ok but sybil protection was practically non-existant (the one party mixing knew the other party mixing). With 3 participants sybil protection is much better but it can still go higher (at the expense of mixing speed). Spreadcoin can use a higher number of mixing participants if it wants to. To ensure mixing takes place and mixing parties don't wait for a very long time, a happy hour can be established where the client has a scheduler to start mixing at a predefined hour, or a certain block. In this way a lot of participants can start mixing at a predetermined point and be almost assured of mixing success. This will be less of a problem when greater adoption happens and more of a problem as fewer people are mixing.

* Resisting the attempt of fake mixing parties to take all the mixing seats and thus know the rest of the legitimate parties who are mixing.

4) DRK's Sybil resistance is relatively low right now due to not having a fee structure that acts as a preventative measure. A weakness was discovered where through the fees paid by each mixing participant => the fees betrayed the participants. Evan kind of shut down the fees to solve the issue, or used the fee structure in a way where one out of several mixings is charged. This allows a degree of Sybil abuse which needs an alternate system in place to charge participants per use (so as to penalize sybil attempts), but without revealing the participants identities.

5) A strong IP obfuscation method, integrated to the client, is a must. DRK doesn't have an IP obfuscation method in place at this point of time - although it is on the cards. Anonymity is not complete without IP obfuscation.

6) It would be good to have a system of encrypted communication so that merchant and user (or user-to-user) can exchange encrypted information that preserve anonymity (like exchanging fund addresses, providing shipping details). There are probably implementations that could be ripped from other coins or open source software, modified, integrated and adopted for use.

7) CPU mining is ideal in the way it is conducted through the menu, but the mining speed should be faster / more optimized for certain architectures and instruction sets. This needs some work.

It would be ideal if GPU mining can also be integrated or "associated" from the mining menu... ie spreadcoin-qt calling the gpu miner program with the right parameters (that the newbie user doesn't know how to setup).

8 ) Low network hashrate is a danger. Complicated solo mining (=anything that isn't click and play) creates the possibility of 51% by even moderate-size "whale farms / whale miners". This creates the need for an upgrade of (7): If mining is to be decentralized by a multitude of solo miners, low-hashrate cpu mining need to be optimized and gpu-mining must be merged or "called" from the wallet client itself in a way that is noob-friendly.

9) A real problem that DRK-clones will face, is that the DRK network has a serious value in its own masternode network. This means that breaking sockpuppet* resistance is an expensive proposition. Coins implementing DarkSend do not have the same value on their network and are thus much easier to sockpuppet by obtaining a large number of masternodes. This will require a well-thought out strategy to deal with the issue of proper value per masternode. A much better alternative -if the dev can make it work- is to attempt blind signing of transactions where the masternode does not know who transacts what. IIRC from some discussions back in April-May, Darkcoin abandoned this approach because blind signing could be DOSed in a way where the network could not penalize the attacker (as the node didn't know who was transacting). Again IIRC, Kristov Atlas in his Darkcoin review believed that sockpuppet resistance could probably be improved through blind signing.

* Sockpuppet = Fake actor controlling masternodes to map transactions

10) Quantum-resistance: The ECDSA of Bitcoin / Bitcoin clones is not quantum-computing resistant. This means that once a public key is known, a private key is weaker against a QC attack.

I believe there can be two solutions for this issue: Changing the algorithms to QC-resistant and thus creating the first QC-resistant altcoin (there is the possibility that they might introduce bloat). Alternatively a work-around QC-resistance can be created through a checkbox. When ticked, all addresses with even one spend transaction will have their funds moved, automatically, to new addresses with zero spends. This will prevent the pub key from being publicly known (and thus being reversed), if and when a QC attack occurs / if and when a QC is developed and deployed. Futureproofing in this way could create a new way of crypto-diversification asset to counter a QC-attack risk (that will leave vulnerable the other coins).

Yes, that's my thoughts on this also. DRK initially went to do it the hashrate way / protocol way, through a voting mechanism where nodes would collect "votes" and then get paid in the next block once their vote count had reached the predetermined limit (6 votes IIRC). But it proved problematic (sporadic forking of the network) in practice and debugging it while in production was attracting all sort of negative attention. Thus it was consequently abandoned in favor of the "spork". So there is definitely room for improvement there.

Even with solo miners it can still play out with a "selfish miner" scenario where one hacks the client for 0% MN payout if he finds the next block. So, yes, it would be good to see it at the protocol level.

In theory it should just fork out those who aren't updated and the people who run the updated client should not experience issues.

If I remember correctly, the second or third time around when it was tried, the network regrouped itself but it did so in something like 20 minutes - which was more than the confirmation window (6 conifrms x 2.5m = 15m) and thus it was reversed.


To be honest, it still remains a workaround. There is no need to praise it beyond what it is. The code should maintain the network, not the enforcer. The spork could be useful for implementing new features in the future though.

Initially (RC2/3) the protocol would ensure 100% compliance through a voting mechanism. The implementation had issues and it led to sporadic forks - and it was difficult to fix these issues due to the time required and the market pressure during the pump period of May/June.

Then, as a workaround, the power went to the pools and the enforcement switch which, as a workaround, is not the ideal way. Hopefully one day we'll get it as it was meant to be and it will not cause sporadic forks either.

May I post a suggestion here?

Since some DRK features are implemented, and some could be improved upon, the original concept for the Darkcoin masternodes (RC2/RC3 releases) involved a protocol-level enforcement of the masternode payments. The problem with these releases was that there was some kind of bug that triggered sporadic network forking by misbehaving nodes or mining clients. The consensus wasn't working as it should.

In a sense, Darkcoin tried to use a dual consensus for every block: One for the transactions / mining, and one for the masternode payout. This didn't work as planned (there were sporadic forks of the network) and DarkSend development was lagging - so a workaround system was created instead that was "safer" and relieved some of the price speculation (it was the period of the great pump - and all eyes were on DRK news and how something would succeed or fail).

In that payment system (an evolution of which, is the current system of MN payments) the pools decided whether to pay or not in a semi-voluntary scheme. If a pool wanted to cheat payment, they could. The strategy was to shame the pools that "cheated" and it worked to compliance levels of 80-90%. The added threat of "enforcement" where Evan would "flip the switch" to fork off the non-compliant pools was also added as an extra measure. However, in my view, this is not the ideal solution to the problem. Rather, it should be done like it initially was conceived so that misbehaving clients are simply forked by themselves out of the network. No centralization / enforcement switch, no need for asking pools to play nice etc etc.

Perhaps the dev wants to give it a look* and see if he can come up with a system that works and which is free of forking bugs. It could also be implemented by DRK if successful, and it would also give added credibility to SPR itself for improving something in a significant way. The good thing with SPR is that, unlike DRK which is more mature, it can risk multiple hard forks to try things out.

* Perhaps the RC2/RC3 bugged solutions of DRK where there was a voting system in place to decide the MN payments are not the ideal concept for this implementation and another idea can be used altogether.

I think we have a definition problem here. What I mean by semi-voluntary is the fact that the possibility of "foul play" is even possible.

The normal design should be in a way where if one attempts to cheat, he would be ousted by the networked / forked by himself. No going around "oh please pool X, update so that you pay 20% instead of 10% or 0%".

That's, IMO, where the project should be headed. I always regarded the current payment scheme as a temp fix* and thus bugs in it do not really concern me - as it is known to be suboptimal as a solution that should eventually be replaced with a cleaner and more robust system where the pools have zero power to cheat or not comply without forking themselves out (and which is not dependent on enforcement).

* Necessary to proceed with DarkSend development because anonymity got behind schedule after 2 months of development on the masternode payment protocol (May-June).

I don't remember when you got on board, but prior to the semi-voluntary scheme of payments with enforcement threat, there was a direction of mandatory payments (100%) with no enforcement needed whatsoever. Unfortunately it caused forks in the production environment so then we got to a situation where some people were calling for no hard forks, others were in favor to get the job done - even if it includes a few more problematic forks as a byproduct etc etc. Then we got the spork and the rest is history.

Tens of bugs and vulnerabilities have been found in prior reviews. It will take some more time (and more eyes) to make it bulletproof.

Personally I think the whole Masternode payment system should be replaced by another cleaner system that works at the protocol level. No enforcement or centralization would be necessary, while eliminating forking risk.

Perhaps the spreadcoin dev might want to have a go at such a system.

DRK's fundamentals just got significantly better. The number and quality of programmers are very important factors.