v0.10.17.x Testing

eduffield · Nov 27, 2014

****** 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

yidakee · Nov 27, 2014

YESSS !!!

SHOTGUN !! lol ...

splawik21 · Nov 27, 2014

Ahhhh I was waiting for this moment.
Testing ready...

flare · Nov 27, 2014

Awesome

oblox · Nov 27, 2014

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).

splawik21 · Nov 27, 2014

- 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.

jiggytom · Nov 27, 2014

where should we point hashing power?

Lukas_Jackson · Nov 27, 2014

Good I'm on holiday...and at home :grin:

UdjinM6 · Nov 27, 2014

splawik21 said:
- 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.

eduffield · Nov 27, 2014

oblox said:
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.

vertoe · Nov 27, 2014

Posting on Page 1 in an epic, game-changing thread. Can't wait to test.

oblox · Nov 27, 2014

eduffield said:
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.

BrainShutdown · Nov 27, 2014

vertoe said:
Posting on Page 1 in an epic, game-changing thread. Can't wait to test.

:grin:

Propulsion · Nov 27, 2014

Qt shows version v0.10.16.16-39-gd839c0b-beta.

Daemon shows 10.17.00.

Both compiled from the instantX branch.

Light · Nov 27, 2014

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

crowning · Nov 27, 2014

Light said:
...gonna fix Darksend first...

That would be Instant-Fix.

First we test InstantX :tongue:

eduffield · Nov 27, 2014

oblox said:
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

Propulsion · Nov 27, 2014

eduffield For masternodeminprotocol use 70046 for the config file?

Bash:

masternodeminprotocol=70046

Also have any addresses to send to?

TaoOfSatoshi · Nov 27, 2014

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:

eduffield · Nov 27, 2014

Propulsion said:
Qt shows version v0.10.16.16-39-gd839c0b-beta.

Daemon shows 10.17.00.

Both compiled from the instantX branch.

Do a "git fetch origin" then qmake && make . Looks like you're missing the tag.

v0.10.17.x Testing

Core Developer

Well-known member

Yeah, it's me....

Well-known member

Well-known member

Yeah, it's me....

Member

Active member

Official Dash Dev

Core Developer

Three of Nine

Well-known member

Active member

The buck stops here.

Well-known member

Well-known member

Core Developer

The buck stops here.

Well-known member

Core Developer