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

v0.10.11.x RC3 Prelaunch Testing

Status
Not open for further replies.
Same thing happened to me some time. But the master node works well though. I'm waiting for the ISP to offer me some more vps and it will be done by this week. So I can join the testnet then.

If all goes well, you'll be too late :tongue:
 
If those coins are transfered after block 24555, we have https://www.darkcointalk.org/threads/rc3-prelaunch-testing.1523/page-3#post-9682
Code:
****** PLEASE UPDATE TO 9.11.2 OR 10.11.2 ******

The recent issues are caused by the new hashing algorithm, which I've fixed in this version.
To fix it though, I'm rewinding all blocks since we updated yesterday.
This is the reason we test changes on testnet first!

To update you'll have to run with -reindex. Then starting and stopping the client won't cause issue.
Might be the problem? BTW, what did Evan mean by new hashing algorithm? He didn't change X11, did he? Is there something else that gets hashed now as well? I missed that part, thanks for any clarification. Gotta get back to this later, so sorry!

Dear HammerHead, I didn't see a newer version posted, how do I check my version number? I mean I'm on version 10.11.02 protocolversion 70019. I don't know where to find the "x.x.x.x:18998 instead of 8998 (or 7903)"

Hard drive died, gotta put new one into the main Ubuntu. I stuck it into another machine because I thought the old drive came back to life well enough, LOL, but now I need to finally replace that drive.
 
Might be the problem? BTW, what did Evan mean by new hashing algorithm? He didn't change X11, did he? Is there something else that gets hashed now as well? I missed that part, thanks for any clarification. Gotta get back to this later, so sorry!

Dear HammerHead, I didn't see a newer version posted, how do I check my version number? I mean I'm on version 10.11.02 protocolversion 70019. I don't know where to find the "x.x.x.x:18998 instead of 8998 (or 7903)"

Hard drive died, gotta put new one into the main Ubuntu. I stuck it into another machine because I thought the old drive came back to life well enough, LOL, but now I need to finally replace that drive.

He means the new hashing algo so that two block found with different votes do not look the same to the network, thus avoiding mini forks.
 
Might be the problem? BTW, what did Evan mean by new hashing algorithm? He didn't change X11, did he? Is there something else that gets hashed now as well? I missed that part, thanks for any clarification. Gotta get back to this later, so sorry!

Nope, I just added a new hashing algorithm for uniquely identifying the voting structure of identical blocks to avoid the issues we had on mainnet last launch.

https://github.com/darkcoinproject/darkcoin/blob/forkfix/src/main.cpp#L1812
 
Is anyone running the new code on mainnet yet? can we? should we? when should we?
 
I don't know if it's a viable testing strategy but here my 2 cents anyway.
I understand that it's possible to send command to all the nodes of testnet and possibly to only a selection of them.
Instead of throwing hashrate everywhere hoping in a block solved (almost) simultaneously by two or more miners, is it possible to hard code in the test version of masternode a command to schedule the solution of an extremely easy block?
I try to explain with an example:
1. all tMN have hardcoded a command to schedule the propagation of the solution (solution hardcoded or supplied with command) of a (hardcoded) block at a specific height or time
2. the command is sent to 2 or more tMNs only
3. other tMNs behaves normally
4 when height or time event triggers the hardcoded block the solution is propagated to the network (almost) simultaneously by the tMNs that received the command
5 the command can be sent anytime to repeat the test
If the hardcoded easy block is not feasible, i think about a command to lower so much the difficulty for the next block in order to increase the probability for a collision
 
****** PLEASE UPDATE TO 9.11.3 OR 10.11.3 ******

I've added a new masternode payment system for non-enforcement mode and ported over a bunch of changes/improvements from @rebroad on github (thanks!)

@rebroad's changes
- Added ability to sync from multiple nodes at once
- Added masternodes to address data (allowing mult-sync from masternodes which is awesome)
- Added a bunch of useful debug info, cleaned up some logging
- Added new proxytoo option
- NodeID's for debug purposes

Thanks for this!!

Binaries (stable)
http://www.darkcoin.io/downloads/forkfix/darkcoin-qt
http://www.darkcoin.io/downloads/forkfix/darkcoind

RC3 Binaries ( masternodes )
http://www.darkcoin.io/downloads/rc3/darkcoin-qt
http://www.darkcoin.io/downloads/rc3/darkcoind
 
Last edited by a moderator:
I don't know if it's a viable testing strategy but here my 2 cents anyway.
I understand that it's possible to send command to all the nodes of testnet and possibly to only a selection of them.
Instead of throwing hashrate everywhere hoping in a block solved (almost) simultaneously by two or more miners, is it possible to hard code in the test version of masternode a command to schedule the solution of an extremely easy block?
I try to explain with an example:
1. all tMN have hardcoded a command to schedule the propagation of the solution (solution hardcoded or supplied with command) of a (hardcoded) block at a specific height or time
2. the command is sent to 2 or more tMNs only
3. other tMNs behaves normally
4 when height or time event triggers the hardcoded block the solution is propagated to the network (almost) simultaneously by the tMNs that received the command
5 the command can be sent anytime to repeat the test
If the hardcoded easy block is not feasible, i think about a command to lower so much the difficulty for the next block in order to increase the probability for a collision

This is a good idea imo, but since they are doing a soft launch on mainnet, the point may be moot.
 
updated:
Code:
2014-06-25 17:45:12 ProcessSyncCheckpoint: sync-checkpoint at 00000000470e82349b97e606eb8380238456c499acf5150f89de1ed99042be06
2014-06-25 17:45:12 !!! ENFORCING PAYMENTS 4085657524
2014-06-25 17:45:12 received block 00000000434dbb3f797988204b42edb49f40cbcc216c0cb0546131d4383d4f40 peer=3
2014-06-25 17:45:12 Committing 38 changed transactions to coin database...
2014-06-25 17:45:12 SetBestChain: new best=00000000434dbb3f797988204b42edb49f40cbcc216c0cb0546131d4383d4f40  height=25124  log2_work=45.147152  tx=47438  date=2014-06-25 17:44:43 progress=1.000000
2014-06-25 17:45:12 CDarkSendPool::NewBlock - Is Masternode, resetting
2014-06-25 17:45:12 ProcessBlock: ACCEPTED
2014-06-25 17:45:12 DarkSendStatusUpdate - state: 2 entriesCount: 0 accepted: -1
 
****** PLEASE UPDATE TO 9.11.3 OR 10.11.3 ******

I've added a new masternode payment system for non-enforcement mode and ported over a bunch of changes/improvements from @rebroad on github (thanks!)

Binaries (stable)
http://www.darkcoin.io/downloads/forkfix/darkcoin-qt
http://www.darkcoin.io/downloads/forkfix/darkcoind

RC3 Binaries ( masternodes )
http://www.darkcoin.io/downloads/rc3/darkcoin-qt
http://www.darkcoin.io/downloads/rc3/darkcoind

Can we run this on mainnet now?
 
Updated my 15 testnet masternodes, 5 of them are bringing in hash power..

****** PLEASE UPDATE TO 9.11.3 OR 10.11.3 ******

I've added a new masternode payment system for non-enforcement mode and ported over a bunch of changes/improvements from @rebroad on github (thanks!)

@rebroad's changes
- Added ability to sync from multiple nodes at once
- Added masternodes to address data (allowing mult-sync from masternodes which is awesome)
- Added a bunch of useful debug info, cleaned up some logging
- Added new proxytoo option
- NodeID's for debug purposes

Thanks for this!!

Binaries (stable)
http://www.darkcoin.io/downloads/forkfix/darkcoin-qt
http://www.darkcoin.io/downloads/forkfix/darkcoind

RC3 Binaries ( masternodes )
http://www.darkcoin.io/downloads/rc3/darkcoin-qt
http://www.darkcoin.io/downloads/rc3/darkcoind
 
****** PLEASE UPDATE TO 9.11.3 OR 10.11.3 ******

I've added a new masternode payment system for non-enforcement mode and ported over a bunch of changes/improvements from @rebroad on github (thanks!)

@rebroad's changes
- Added ability to sync from multiple nodes at once
- Added masternodes to address data (allowing mult-sync from masternodes which is awesome)
- Added a bunch of useful debug info, cleaned up some logging
- Added new proxytoo option
- NodeID's for debug purposes

Thanks for this!!

Binaries (stable)
http://www.darkcoin.io/downloads/forkfix/darkcoin-qt
http://www.darkcoin.io/downloads/forkfix/darkcoind

RC3 Binaries ( masternodes )
http://www.darkcoin.io/downloads/rc3/darkcoin-qt
http://www.darkcoin.io/downloads/rc3/darkcoind

Tag v0.9.11.3 in git is referencing commit df7734b684, whereas latest commit was bb7fa4f92d - is this correct? Wanted to test my gitian-builds against v0.9.11.3 and need to ensure the tag is correct :smile:
 
Last edited by a moderator:
Shouldn't we also add like 10-20 pools and spread our hashrate equal to all the pools and see how it works out if we find a lot of blocks at once?
 
First, thanks for this guide. If somebody get access to the key that was created with
enter: "masternode genkey" and press enter.
Is he able to steal the coins ?
Question is because of the key is stored onto the online server and there could be security issues
flare could someone using the private key generated by masternode genkey to authenticate with the network as the masternode and abuse that somehow?
 
3 nodes updated.

payout stats

Node A = 45 tDRK (12%)
Node B = 140 tDRK (37%)
Noce C = 195 tDRK (51%)

Seems fair so far, still too early for equal dist. :cool:

eduffield - Any news on a block explorer, or Abe patch? I'm missing being able to check earnings quick
 
Last edited by a moderator:
flare could someone using the private key generated by masternode genkey to authenticate with the network as the masternode and abuse that somehow?

As far as i understood eduffield regarding the masternodeprivkey, the key is randomly generated and never used in the wallet.

Masternodes now sign their 1000DRK vin for the first message to the network, then they specific a second pubkey that they will sign all further messages with. This second signing key must be specified for all masternodes in the configuration with the option "masternodeprivkey"

To generate a key, boot up the client and execute the command "masternode genkey" and then take the output and put it in the configuration like this "masternodeprivkey=COMMANDOUTPUT. There is also a new protocol command called "dseep" which is signed with this secondary key. This key will never be used in the wallet and is generated randomly.

This allows the client to encrypt the wallet and still be able to sign new messages to the network.

So even if someone gets access to this key, he will not have access to your 1000DRK vin.

Nevertheless the attacker might use the key to sign messages to the network, so he could presumly register a new pubkey/IP combination to hijack payouts - but i have not thought through all implications of this attack-vector and if it's feasable - or if Evan has already countermeasures in place (he is usually very good at this :smile: )
 
As far as i understood eduffield regarding the masternodeprivkey, the key is randomly generated and never used in the wallet.



So even if someone gets access to this key, he will not have access to your 1000DRK vin.

Nevertheless the attacker might use the key to sign messages to the network, so he could presumly register a new pubkey/IP combination to hijack payouts - but i have not thought through all implications of this attack-vector and if it's feasable - or if Evan has already countermeasures in place (he is usually very good at this :smile: )

Would you have fun with it if I gave you one of my node's masternodeprivkey?
 
Status
Not open for further replies.
Back
Top