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

v0.10.17.x Testing

Status
Not open for further replies.

eduffield

Core Developer
****** PLEASE UPDATE TO v10.17.0 *******

- This supports a complete InstantX implementation. This implementation has teeth, the masternodes have the final say if a specific transaction will make it into the block. To do this, they can actually orphan conflicting blocks, up to five blocks deep if an attack happened. To pull off such an attack, the attacker would propagate a lock request, masternodes would form a lock, then the attacker would mine a conflicting transaction. With this implementation, that block will be orphaned.
- Current setting, requires 7 of 10 masternodes to form a lock
- Masternodes MUST have their port open, or they will be forced into an inactive state (not implemented yet)
- Each InstantX transaction will use a different set of masternodes. These are chosen based on the POW hash of the block that transaction was included in. This means you can't tamper with the masternodes you'll use, but the system can use all masternodes at once.
- Masternode network backwards compatibility, dsee/dseep messages now will be backwards/forwards compatible. Masternodes in the list will have protocol versions, so the code will know which are compatible with their versions.
- Gradual forced masternode updates, the network will now support paying out-of-date masternode versions for a period of time while allowing the network to update. Each update will have a deadline (probably 1 week after an update is released) before payments stop. This means the network could support multiple versions of Darksend at once, which is ideal.
- Support "min protocol version" for Darksend, allowing mixing between different versions of compatible protocols.
- New parameter -masternodeminprotocol = Only track masternodes beyond this version
- New parameter -wallet = Use a wallet other than wallet.dat (UdjinM6)
- New command "masternode list protocol"
- Wallet will stay locked during Darksend and only be able to mix (UdjinM6)
- Improved CalculateScore, using a much harder to trick calculation

Code:
// Deterministically calculate a given "score" for a masternode depending on how close it's hash is to
// the proof of work for that block. The further away they are the better, the furthest will win the election
// and get paid this block
//
uint256 CMasterNode::CalculateScore(int mod, int64 nBlockHeight)
{
    if(pindexBest == NULL) return 0;

    uint256 hash = 0;
    if(!darkSendPool.GetLastValidBlockHash(hash, mod, nBlockHeight)) return 0;
    uint256 hash2 = HashX11(BEGIN(hash), END(hash));

    // we'll make a 4 dimensional point in space
    // the closest masternode to that point wins
    uint64 a1 = hash2.Get64(0);
    uint64 a2 = hash2.Get64(1);
    uint64 a3 = hash2.Get64(2);
    uint64 a4 = hash2.Get64(3);

    //copy part of our source hash
    int i1, i2, i3, i4;
    i1=0;i2=0;i3=0;i4=0;
    memcpy(&i1, &a1, 1);
    memcpy(&i2, &a2, 1);
    memcpy(&i3, &a3, 1);
    memcpy(&i4, &a4, 1);

    //split up our mn hash
    uint64 b1 = vin.prevout.hash.Get64(0);
    uint64 b2 = vin.prevout.hash.Get64(1);
    uint64 b3 = vin.prevout.hash.Get64(2);
    uint64 b4 = vin.prevout.hash.Get64(3);

    //move mn hash around
    b1 <<= (i1 % 64);
    b2 <<= (i2 % 64);
    b3 <<= (i3 % 64);
    b4 <<= (i4 % 64);

    // calculate distance between target point and mn point
    uint256 r = 0;
    r +=  (a1 > b1 ? a1 - b1 : b1 - a1);
    r +=  (a2 > b2 ? a2 - b2 : b2 - a2);
    r +=  (a3 > b3 ? a3 - b3 : b3 - a3);
    r +=  (a4 > b4 ? a4 - b4 : b4 - a4);

    /*
    LogPrintf(" -- MasterNode CalculateScore() n2 = %s \n", n2.ToString().c_str());
    LogPrintf(" -- MasterNode CalculateScore() vin = %s \n", vin.prevout.hash.GetHex().c_str());
    LogPrintf(" -- MasterNode CalculateScore() n3 = %s \n", n3.ToString().c_str());*/

    return r

How can you help?

- Run a masternode
- Point hashing power at my pool (I'm going to be attacking InstantX and will need most of the hashing power)
- Test InstantX

**** Downloads : v0.10.17.0 ***********************************

Source: https://github.com/darkcoin/darkcoin/tree/instantx

--

Windows 32bit:
https://github.com/darkcoinproject/darkcoin-binaries/raw/master/instantx/windows/darkcoind.exe
https://github.com/darkcoinproject/darkcoin-binaries/raw/master/instantx/windows/darkcoin-qt.exe

Mac OS X:
https://github.com/darkcoinproject/...aster/instantx/mac/darkcoin-0.10.17.4-osx.dmg

Linux 32bit:
https://github.com/darkcoinproject/darkcoin-binaries/raw/master/instantx/linux/32/darkcoin-qt
https://github.com/darkcoinproject/darkcoin-binaries/raw/master/instantx/linux/32/darkcoind

Linux 64bit:
https://github.com/darkcoinproject/darkcoin-binaries/raw/master/instantx/linux/64/darkcoin-qt
https://github.com/darkcoinproject/darkcoin-binaries/raw/master/instantx/linux/64/darkcoind
 
Last edited by a moderator:
eduffield Not to take thunder away from testing instantx, but the smart contract fix to the dead change issue fell flat. What timeframe can we realistically expect a fix for darksend? Is it time to bite the bullet and realize that microdenominations and future pruning are the only logical means of solving this issue with change beyond the lowest denomination going to the network (miners/masternodes).
 
- wallet = Use a wallet other than wallet.dat (UdjinM6)
- wallet will stay locked during Darksend and only be able to mix (UdjinM6)

very utile, I`ll mix definitly more now rather than before with always wallet opened.
 
- wallet = Use a wallet other than wallet.dat (UdjinM6)
- wallet will stay locked during Darksend and only be able to mix (UdjinM6)

very utile, I`ll mix definitly more now rather than before with always wallet opened.
Few notes on "locking for anonymization only" feature:
a) This feature still need to be tested in almost every possible way to break it from usual user perspective. Though I think it should be pretty robust - don't just trust me, try to break it yourself please :wink:
b) Be aware that wallet is locked ONLY in tx sending and importing/dumping private keys code (and in UI of course), it still keeps passphrase in memory to be able to sign mixing transaction just like when you unlock it completely. So advanced hacker/trojan who can scan memory and knows exactly what he is looking for will be able to get it or switch protection off. Common security rules is still a must-to-follow anyway.
 
Last edited by a moderator:
eduffield Not to take thunder away from testing instantx, but the smart contract fix to the dead change issue fell flat. What timeframe can we realistically expect a fix for darksend? Is it time to bite the bullet and realize that microdenominations and future pruning are the only logical means of solving this issue with change beyond the lowest denomination going to the network (miners/masternodes).

What do you mean it fell flat? From what I can tell that solves the problem entirely.
 
What do you mean it fell flat? From what I can tell that solves the problem entirely.
There are a ton of unanswered questions begging for answers. Feel free to answer them and then we can re-evaluate but so far it seems you either run the risk of the receiver not having funds to send back for change (because you can't use the excess change the initial party sent), the added problems of timing and how it will conflict with instantx implementation, the security issue of needing to have the wallet unlocked in order to send the second tx, additional steps running secondary daemons, how party B gets the address of party A (address C) etc, etc. On paper, it looks like it solves it but I think a few in there don't see how it actually would when you delve into the details.

Please, by all means, answer the questions everyone asked in the thread and we'll have a better idea of whether or not this works.
 
Qt shows version v0.10.16.16-39-gd839c0b-beta.

Daemon shows 10.17.00.

Both compiled from the instantX branch.
 
Holy Instant Turkey!!! I though we are gonna fix Darksend first and then start testing InstantX.

That being said, I appreciate that you are working on this even during Thanksgiving :)
 
Last edited by a moderator:
There are a ton of unanswered questions begging for answers. Feel free to answer them and then we can re-evaluate but so far it seems you either run the risk of the receiver not having funds to send back for change (because you can't use the excess change the initial party sent), the added problems of timing and how it will conflict with instantx implementation, the security issue of needing to have the wallet unlocked in order to send the second tx, additional steps running secondary daemons, how party B gets the address of party A (address C) etc, etc. On paper, it looks like it solves it but I think a few in there don't see how it actually would when you delve into the details.

Please, by all means, answer the questions everyone asked in the thread and we'll have a better idea of whether or not this works.

https://darkcointalk.org/threads/change-contracts-using-atomic-transfers.3067/page-7#post-31090
 
Fantastic! Been waiting for this moment, also! Evan, working on Thanksgiving weekend? You are truly a machine! You rocked it in that video explaining the benefits of Darkcoin, BTW! I will help in any way I can, in between getting people to SEE THE LIGHT, AND GET INTO THE DARK! :grin::grin::grin:
 
Status
Not open for further replies.
Back
Top