[06:02:31] just setup a testnet node (ubuntu 18.04) with latest master branch on build.nav.community [06:02:35] mqJnPgN2Crg4wpkTiqMwYoqdW2PpMAXWUt [06:02:47] you can send some test coins to this address [06:16:51] @sakdeniz can you post your server details as a comment on this issue so we can understand the shape of the testnet and which hardware, region, os etc are covered [06:16:51] https://github.com/navcoin/navcoin-core/issues/626 [06:18:58] I can confirm those binaries are correct, they match my hashes; https://build.nav.community/binaries/master/ [06:19:34] @roast the binaries are ready for you here; https://build.nav.community/binaries/master/ [06:19:58] either of these links should work [06:27:04] @sakdeniz i just sent you 50k testnet coins 🙂 [07:28:20] @prole I ended up compiling from the git repo, after a few dependency issues, all is now good. Node is running. [07:30:08] @roast can you write instructions for compile navcoin core on ubuntu 18.04? [07:30:22] sure [07:30:42] thanks [07:32:55] cd navcoin-core/depends make -j8 cd .. ./autogen.sh ./configure --prefix=pwd/depends/x86_64-pc-linux-gnu make -j8 [07:33:37] -j8 for 8 cores [07:35:16] do i need other dependencies? [07:38:43] paul05/02/2018 so here is all youi need sudo apt-get update sudo apt-get upgrade -y sudo apt-get install -y git build-essential libcurl3-dev libtool autotools-dev automake pkg-config libssl-dev libevent-dev bsdmainutils sudo add-apt-repository ppa:bitcoin/bitcoin sudo apt-get install -y libboost-all-dev sudo apt-get install -y libminiupnpc-dev sudo apt-get install -y libzmq3-dev [07:39:35] thanks! [07:49:08] https://github.com/navcoin/navcoin-dev-tools/blob/master/ubuntu-18.04-navcoin-core-dev-setup.sh [07:57:49] @sakdeniz when you get a chance, pls send a few test coins to mjQLGRYfdiMtvp2gPEW3XxZMMeDKpXwXWL 🙂 [08:00:07] received. thanks. [08:00:50] staking 🙂 [08:11:15] Just got my first 2 Nav stake on testnet [08:11:46] orphan 😦 [08:16:07] I will create a page for monitor clients status on testnet [08:17:29] So we can compare each clients synced headers [08:21:44] 2 orphans and a 2 Nav stake. balance 25002 [08:24:00] alex is staking like 50M tNAV so i wouldn't feel bad about getting orphaned out [08:24:06] 😛 [08:24:18] staking 24 hour calculator appears to be adding the orphan stakes. 24 hour says I've staked 6 Navs. should be just 2. [08:24:29] hopefully he can share a bit more around when he wakes up, he only sent me 250k to start [08:24:43] good spotting [08:25:08] skimpy alex [08:28:05] error also applies to 7 day, 30 day, 1 year and all. [08:33:51] transactions show 2x2Nav Stakes=4, and 5 orphans. staking calc shows 8 Nav's staked. should be 4. [08:34:23] balance 25004 [08:35:05] im only staking 100k but the difficulty is very low yet. give me addresses and ill send you more coins 🙂 but its also good to leave nodes with little coins [08:35:24] ah okay [08:35:49] I may not have noticed this if I had lots of coins. [08:35:56] Vote yes for my awesome proposal [08:36:00] proposalvote 4550a78a3d1b1ed76162dfd48327397042b2f23c582783b2759e4743994f7457 yes [08:37:12] proposalvote 4550a78a3d1b1ed76162dfd48327397042b2f23c582783b2759e4743994f7457 yes [08:39:12] And what am I voting for @sakdeniz ? test coins are not on the navexplorer 🙂 [08:39:30] getproposal 4550a78a3d1b1ed76162dfd48327397042b2f23c582783b2759e4743994f7457 { "version": 2, "hash": "4550a78a3d1b1ed76162dfd48327397042b2f23c582783b2759e4743994f7457", "blockHash": "927aa97f3fb66d6aee42f5674fcecb8d43796cc7d247c5bd401d395bff46e26f", "description": "Testing - sakdeniz", "requestedAmount": "5000.00", "notPaidYet": "5000.00", "userPaidFee": "0.0001", "paymentAddress": "mqJnPgN2Crg4wpkTiqMwYoqdW2PpMAXWUt", [08:39:31] "proposalDuration": 604800, "votesYes": 1, "votesNo": 0, "votingCycle": 0, "status": "pending", "state": 0, "paymentRequests": [ ] } [08:39:47] there's only 500 tNAV in the CFund yet [08:40:07] Can we donate to fund? [08:40:12] i wonder if we should get some more nodes setup and come with a more conclusive test plan first? i guess any regular user testing is helpful also [08:40:53] ./navcoin-cli donatefund "amount" [08:56:58] i think i can add 2/3 more nodes today [08:59:22] https://cdn.discordapp.com/attachments/416000318149754881/645171037373333515/Screen_Shot_2019-11-16_at_8.59.05_PM.png [08:59:38] im keeping the list updated. we have quite a good geographical spread so far [09:00:49] I'm going to get a windows 10 box setup in the next couple of days and try to spin up a couple VPS across south america and africa if i can get it to work. Unless some of our NavCoin Africa or Argentina people want to setup some nodes for us 🙂 [09:00:59] the more the merrier [10:00:24] stake error appears to be 2n-2, 2n, 2n+2 (n is correct stakes, error appears in stake totals) [10:01:34] @aguycalled ive reviewed the diff of #622 in depth and left some questions there for you; https://github.com/navcoin/navcoin-core/pull/622#pullrequestreview-317959708 [10:03:13] its 10pm here, im going to get off the computer and start fresh in the morning [10:03:16] ttyl [10:03:32] good work today team! [10:25:07] is it possible to increase max connection limit to 300+ [10:25:42] i think default is 8 [10:27:11] if possible i think i can make a node monitor for whole mainnet [10:27:57] 2n-10 [10:29:21] appears to go astray when there are multiple consecutive orphans [10:50:52] @sakdeniz the maximum size is set dynamically based on how many connections your system can maintain in parallel. Just set it as high as you like and you should get a warning message that shows your systems maximum capable connections [10:50:54] https://github.com/navcoin/navcoin-core/blob/083e790aed0120dd271a648d87948e5ae1870814/src/init.cpp#L1100 [10:51:09] From what I understand reading that code at least [10:52:26] Ok i will try thanks [11:03:24] 2n-14 another bunch of consecutive orphans [11:06:33] total tNav = 25046, staking 24H = 78 [14:13:36] @sakdeniz how do you plan to monitor the network? would you also be able to compare the output of listproposals ? [14:42:21] getpeerinfo returns too many useful details about node status [14:44:20] looks like they are ~ 200 nodes on mainnet [14:45:10] if 1 node can connect to all node, we can get details about connected nodes [14:45:38] so we can compare them, is nodes on same block etc [14:46:57] another solution is broadcast node sync status to network [14:47:56] so we can grab these details with our node and process to our database for monitoring [14:49:19] @aguycalled [14:53:17] as a result, node details must come from the nodes somehow [16:17:03] i think second option better [16:17:38] there is no risk to broadcast current node sync details [16:19:46] also node can broadcast itselfs proposal outputs [16:20:42] so we can compare nodes sync status and listproposals output [16:42:16] getpeerinfo gives only the block height and not the block hash [16:42:53] i think nodes would better need to expose the rpc server so the monitor node can monitor it like that [18:19:13] http://navcommunity.net/testnet/ [18:30:02] cool [18:30:21] i've made a telegram group where i will have my nodes broadcasting every hour their best hashes [18:30:35] #dev-testnet [19:01:46] @roast the staking report in the main page can take a few seconds (maybe 30 or 1 minute) to update [19:01:57] does it happen that it shows the right values if you disable staking for a while? [20:59:53] @aguycalled I have approved #622 [21:00:43] What do you think about what i said here; https://github.com/navcoin/navcoin-core/pull/622#issuecomment-554599193 [21:01:04] should we cover the proposal reorganisation with a similar test, or this test we have is enough for now? [21:02:01] re: As far as I can tell the test only reorgs a payment request, after the proposal is accepted on the same chain by each node. Is it also worth having the same test but reorg the proposal itself and ensure payment requests can still be submitted? answer is yes [21:02:33] re: the check list, only payment request creation and payment request payout are consensus-critical [21:03:20] yeah? what if a incorrectly re-organised vote is the difference between a proposal/preq passing or not? [21:03:41] pretty slim chance [21:03:46] but possilbe right? [21:03:46] but the fork will only happen when a preq is created [21:03:52] and nodes have a different view of the proposal votes [21:03:57] or when a preq is paid [21:04:04] and nodes have a different view on the payment request state [21:04:35] okay [21:04:47] should i copy out the test and check that it re-orgs the proposal correctly? [21:05:08] so many different things can cause state inconsistency but only two cause a fork because that inconsistency [21:05:32] cool [21:05:47] okay, im on the test. can i just commit it straight to your branch when its done? [21:06:06] I'll also run it against 4.7.0 to double check what happens tehre [21:06:33] yup [21:06:48] 👍 [22:38:44] @aguycalled the send_raw_paymentrequest method you have there. it modifies the version of the raw transaction to 05 [22:38:51] # Modify version for payreq creation raw_proposal_tx = "05" + raw_proposal_tx[2:] [22:39:03] Is this the same for proposals? [22:39:19] nope [22:39:30] but its easier if you use createproposal [22:39:36] and set dump_raw to True [22:40:05] okay, can do. i mean ive already got; def create_raw_proposal(self, amount, address, deadline, description): amount = amount * 100000000 # Create a raw payment request raw_proposal_tx = self.nodes[0].createrawtransaction( [], {"6ac1": 1}, json.dumps( {"v": 2, "a": address, "n": amount, "d": deadline, [22:40:06] "s": description, }) ) # Modify version for payreq creation raw_proposal_tx = "05" + raw_proposal_tx[2:] # Fund raw transacion raw_proposal_tx = self.nodes[0].fundrawtransaction(raw_proposal_tx)['hex'] # Sign raw transacion raw_proposal_tx = self.nodes[0].signrawtransaction(raw_proposal_tx)['hex'] # Return the raw hex return raw_proposal_tx [22:40:15] which i think is pretty close [22:40:22] but can do the other way [22:40:36] you would need "04" instead of "05" [22:40:41] okay [22:40:57] but good to know that there's a dump_raw flag [22:42:17] and same script right? Just donate to the cfund [22:42:32] are they differentiated just by the params in the strDeezl? [22:42:43] now taht i see u need to update the strdzeel too [22:42:55] so prob itll be faster if u just set dumpraw to true and then sendrawtransaction [22:43:10] okay