Topic: [ANN][PIVX] - PRIVATE INSTANT VERIFIED TRANSACTION - PROOF OF STAKE - ZEROCOIN - page 337. (Read 782479 times)

You could run ./darknet-cli -rpcconnect=IPNUMPER  -rpcuser=masternodeusername -rpcpassword=yoursecurepassword getinfo

I assume you are running this from within your masternode's server...

You might need to set "rpcallowip=" to allow you to connect from wherever you are trying to connect to.
It's prudent to set rpcallowip to  only  allow internal connections. (best to firewall all unnecessary ports).
RPC could be used over ssl, but I suppose this could be used to generate extra load on the server if left open,
and worse is possible if you use easily guessable usernames and passwords.

flicking through using the ipv6 on vultr option i think i have it sorted just wondering how you do ./darknet-cli getinfo for all of them? I found the exe in cd /var/lib/ but it does not accept commands and gives error

You must set rpcpassword= in the configuration file:
/root/.darknet/darknet.conf
If the file does not exist, create it with owner-readable-only file permissions.

i have done that for the 5 that are on there

any help appreciated

I am happy that 60k coins were burnt.

I understand that finding transactions containing the initial 60k premine for the masternodes
would be more work and would need a more complex transaction to burn them than what
was carried out.

Whatever decisions are made, or whatever is done, not everyone will be happy.

While proposals might be described and discussed in bitcointalk. I think the decision to stray
from the original plan should have been formalized with a proposal and vote. In the case of a
crisis, security incident, etc. it could be acceptable for the developers make changes that
need to be done quickly.

There is no way for the poll to reflect the share of masternode voters. I think that this is why
we have this masternode based proposal and voting system. Seeing that the system is not
being used reduces its credibility.

In my understanding it was an informal poll (unless I missed a message explaining it), which
indicated that for 20 out of 64 who participated, It mattered which coins were burnt. Votes
are not always decided based on 50% majority. Enough, that it could be discussed further...
and a decision to stray from the initial plan, it could be formalized by a proposal and vote.

As for the comment about the fork, this is definitely a small issue. There is not much at
stake and no change in the intended supply of DNET. The Ethereum hard fork and
Ethereum classic is a good example of what can happen when there is a lot at stake and
when differences in principles.

thank you sir!

been stressing me out for few hours now

Enable coin control, click the Send tab, then click on "Inputs" and make sure you're not trying to spend coins that have less than 100 confirmations.

my wallet is nakered.

when i try to send coins it wont let me and says transaction rejected. this might happen if some of the coins are already spent.

I have tried rescan, zap wallets. sync from scratch but still same error. what can i do??

second that, meantime due to reports of stability I have switched from POS to master nodes configuration all 48 of them , as soon as I collect new nodes are being added

Not entirely sure what you are implying, but there was a vote, and we did what the vote said.

looks like alot of people switching to ipv6 ips. cheaper do at only $1 a node on vultr.

just tried to build and sync the lastest wallet to get some coins out of my wallet... and it stop here with this messsage:

2016-09-02 15:15:02 UpdateTip: new best=1adab33fa2b16e7a8cd4c36c95b3dbe8b33aba7350ad2b573e3656d662bd8004  height=261411  log2_work=58.56341  tx=371842  date=2016-08-19 10:42:59 progress=0.733523  cache=49469
2016-09-02 15:15:02 UpdateTip: new best=b36a5126d8a757b3fffad42d4b329fc21511be6e785032f54ee0c4491ad194de  height=261412  log2_work=58.564562  tx=371844  date=2016-08-19 10:43:21 progress=0.733531  cache=49471
2016-09-02 15:15:02 UpdateTip: new best=222d6060369732a5c503ae4b074637fbcee576ec022f620ca91f3a2d5b8528af  height=261413  log2_work=58.56575  tx=371846  date=2016-08-19 10:43:25 progress=0.733537  cache=49473
2016-09-02 15:15:02 UpdateTip: new best=7a59132c4ca71c428db0706f117a19b82b03f1eff0bb08e686fc415f4910d22d  height=261414  log2_work=58.566993  tx=371848  date=2016-08-19 10:44:09 progress=0.733549  cache=49475
2016-09-02 15:15:02 UpdateTip: new best=1df7fae82fc5f2a08cb9dc0be60cc8e1bdfab6539e8e3b3275cc81c88e6c0ef4  height=261415  log2_work=58.568251  tx=371851  date=2016-08-19 10:43:52 progress=0.733554  cache=49478
2016-09-02 15:15:02 ERROR: GetTransaction : Deserialize or I/O error - ReadCompactSize() : size too large
2016-09-02 15:15:02 ERROR: CheckProofOfStake() : INFO: read txPrev failed
2016-09-02 15:15:02 WARNING: ProcessBlock(): check proof-of-stake failed for block cdda49c926cec1d4806e633011bc6f1d30c280e0a3e911f2f6427f0a7b945e1a
2016-09-02 15:15:02 ERROR: ProcessNewBlock : AcceptBlock FAILED
2016-09-02 15:15:03 ERROR: GetTransaction : Deserialize or I/O error - ReadCompactSize() : size too large
2016-09-02 15:15:03 ERROR: CheckProofOfStake() : INFO: read txPrev failed
2016-09-02 15:15:03 WARNING: ProcessBlock(): check proof-of-stake failed for block cdda49c926cec1d4806e633011bc6f1d30c280e0a3e911f2f6427f0a7b945e1a
2016-09-02 15:15:03 ERROR: ProcessNewBlock : AcceptBlock FAILED
2016-09-02 15:15:03 ERROR: GetTransaction : Deserialize or I/O error - ReadCompactSize() : size too large
2016-09-02 15:15:03 ERROR: CheckProofOfStake() : INFO: read txPrev failed
2016-09-02 15:15:03 WARNING: ProcessBlock(): check proof-of-stake failed for block cdda49c926cec1d4806e633011bc6f1d30c280e0a3e911f2f6427f0a7b945e1a
2016-09-02 15:15:03 ERROR: ProcessNewBlock : AcceptBlock FAILED2016-09-02 15:15:26 keypool reserve 6528
2016-09-02 15:15:26 keypool return 6528
2016-09-02 15:15:26 keypool reserve 6528
2016-09-02 15:15:26 keypool return 6528
2016-09-02 15:15:54 connect() to 80.236.18.96:51472 failed after select(): Connection refused (111)
2016-09-02 15:15:56 connect() to 185.77.129.23:51472 failed after select(): Connection refused (111)
2016-09-02 15:15:58 keypool reserve 6528
2016-09-02 15:15:58 keypool return 6528
2016-09-02 15:16:02 spork - new fe5e321483e33c9b559f9d4338f9359ee172d1f04763a60b12afedd9f4c1b812 ID 10011 Time 0 bestHeight 261415

I guess the "any 60k"  was burned even though a significant number of forum members voted for the original.

Original 60k    20 (31.3%)
Any 60k    44 (68.8%)
Total Voters: 64

I suppose no one here is interested in having any more forks. 

Yes, at the change to PoS, network fees are now destroyed. Though it is fractional, it does help overtime with inflation, and now we can remove coins from the total coin cap if needed... instead of having them just sit there at an address somewhere. Thats how burning coins should work..

Noticed that these nodes seem to be running the stable release now also.

Think that we now have enough 'public' nodes to produce some good Tor 'howto' documentation etc.,

Some crypto-currencies 'destroy' transaction fees, whilst others add transaction fees into new blocks. It is generally more common for PoS coins (over PoW) to 'destroy' transaction fees, I think.

@s3v3nh4cks - well that turned out to be a simple enough solution, should really of thought of that one!  

A milestone achieved! Congrats. Like kokokoin I don't understand what you mean by "coins were sent as a network fee which are destroyed"? And like him I ask myself what happen to network fees since POS? they get splitted at the same rate as the MN/Stake reward?

But why network fee was destroyed and not given to miner?

Seems v 2.1.2.1 fixed all issues! Controller wallet and all masternodes running without any problems since installing. Good work, devs.

First payment for my newest masternode just came.

Less than 41 hours after starting it.