v0.10.17.x Testing

Status
Not open for further replies.

eduffield

Core Developer
Mar 9, 2014
1,084
5,319
183
****** 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:

oblox

Well-known Member
Aug 6, 2014
1,032
537
183
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

Grizzled Member
Dash Core Team
Moderator
Foundation Member
Dash Support Group
Apr 8, 2014
1,918
1,273
1,283
- 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.
 

UdjinM6

Official Dash Dev
Dash Core Team
Moderator
May 20, 2014
3,637
3,536
1,183
- 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 ;)
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

Core Developer
Mar 9, 2014
1,084
5,319
183
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.
 

oblox

Well-known Member
Aug 6, 2014
1,032
537
183
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.
 

Propulsion

The buck stops here.
Feb 26, 2014
1,008
467
183
Dash Address
XerHCGryyfZttUc6mnuRY3FNJzU1Jm9u5L
Qt shows version v0.10.16.16-39-gd839c0b-beta.

Daemon shows 10.17.00.

Both compiled from the instantX branch.
 

Light

Well-known Member
Foundation Member
Jun 4, 2014
346
256
233
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:

eduffield

Core Developer
Mar 9, 2014
1,084
5,319
183
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
 
  • Like
Reactions: TaoOfSatoshi

Propulsion

The buck stops here.
Feb 26, 2014
1,008
467
183
Dash Address
XerHCGryyfZttUc6mnuRY3FNJzU1Jm9u5L
eduffield For masternodeminprotocol use 70046 for the config file?

Bash:
masternodeminprotocol=70046
Also have any addresses to send to?
 

TaoOfSatoshi

Grizzled Member
Jul 15, 2014
2,762
2,616
1,183
Dash Nation
www.dashnation.com
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! :D:D:D
 
  • Like
Reactions: Raico

Propulsion

The buck stops here.
Feb 26, 2014
1,008
467
183
Dash Address
XerHCGryyfZttUc6mnuRY3FNJzU1Jm9u5L
Do a "git fetch origin" then qmake && make . Looks like you're missing the tag.
Didn't work but that's alright. All the functionality like the "Instant X" option is present in QT nonetheless.

Oh and it's usually on my end anyway so no worries! ;)
 

Walter

Active Member
Masternode Owner/Operator
Jul 17, 2014
231
201
103
****** 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

* compiling *
This is going to be good... :):):)

I'll set up a couple of test MNs shortly.

Walter
 
  • Like
Reactions: yidakee

Propulsion

The buck stops here.
Feb 26, 2014
1,008
467
183
Dash Address
XerHCGryyfZttUc6mnuRY3FNJzU1Jm9u5L
If anyone would like to send Instant X Transactions, here is my address: mtuET9MwFsL5jMWXwiN3Rdo1WyND7uG99q. Either through darksend or regular, I'm not picky.
 
  • Like
Reactions: yidakee

moli

Grizzled Member
Aug 5, 2014
3,261
1,837
1,183
If anyone would like to send Instant X Transactions, here is my address: mtuET9MwFsL5jMWXwiN3Rdo1WyND7uG99q. Either through darksend or regular, I'm not picky.
I just sent you some tDRK to empty my old wallet on testnet. :)
 

Propulsion

The buck stops here.
Feb 26, 2014
1,008
467
183
Dash Address
XerHCGryyfZttUc6mnuRY3FNJzU1Jm9u5L
I just sent you some tDRK to empty my old wallet on testnet. :)
The 216.51249981 one? I received it but that was 15 minutes ago. Since then I've dropped my connection count from >10 to 4 and haven't received a block since. The TX is at 0 confirmations.

Block count for my client is currently showing 70603 with 7 MN's.
 
Status
Not open for further replies.