Is PoS really suitable for a primarily asset based chain? Normally in PoS you're intending on trusting the majority of the wealth, but with an emphasis on assets, the majority of wealth may be the assets themselves, so instead you're trusting the majority of uninvested wealth. Is that still sufficient?

the hidden service port lines need to have the rpcport after the 127.0.0.1

Yes, vtx[1] is the coinstake transaction, and it looks at it in the IsProofOfStake function, that doesn't contradict anything I said. vtx[0] is where the masternode payment verification code is looking however when the payment is part of that coinstake in vtx[1].

I pmed the dev about this a few days ago, but haven't received any response, nor has anything been done about these, so I'm posting this here now hoping it'll get some answers. This is not the message I sent, this is reworded for general users who I don't expect to know much about the code.

There are multiple things I've found in the code that seem like problems. In the masternode payment enforcement, the code for checking that masternodes are being paid is checking the wrong transaction. In btc(and pow coins like darkcoin which the code came from) the block reward is in the first transaction (vtx[0]), and in PoS forks like crave is, vtx[0] is always left empty and the block reward is in vtx[1]. It can be seen here https://github.com/industrialcoinmagic/crave/blob/master/src/main.cpp#L2375 and https://github.com/industrialcoinmagic/crave/blob/master/src/main.cpp#L2357 that the code was not updated to look in vtx[1], and continues to look at vtx[0]. It can also be seen a little higher up in the same function that the block verification does check that vtx[0] is empty https://github.com/industrialcoinmagic/crave/blob/master/src/main.cpp#L2302 . Since block verification checks that vtx[0] is empty to even get to masternode payment verification, payment verification will never find an output to a masternode in that loop, and should reject all blocks, except it doesn't deadlock due to the next point.

The hard fork never happened. If you scroll up a little from the previous section, you'll see a flag used for enabling masternode enforcement. https://github.com/industrialcoinmagic/crave/blob/master/src/main.cpp#L2341 Right below it checks it against a timestamp, and sets the flag to true if we're past the fork time. Before we actually use the flag, there's another condition calling the IsSporkActive function https://github.com/industrialcoinmagic/crave/blob/master/src/main.cpp#L2341 which is capable of turning the flag back off. If you follow that function https://github.com/industrialcoinmagic/crave/blob/master/src/spork.cpp#L80 what happens in that call is it doesn't see that flag in the map, so heads into the else block where it copies SPORK_1_MASTERNODE_PAYMENTS_ENFORCEMENT_DEFAULT to r, and then compares r to the current time. If you take a look at the value compared https://github.com/industrialcoinmagic/crave/blob/master/src/spork.h#L28 , and convert that timestamp(2428537599) to normal time ( http://www.epochconverter.com/ ), you'll see that the timestamp used is Dec 16 2046. Clearly this hasn't happened yet, so IsSporkActive returns false, and that causes it to set the flag back to false so the masternode payment enforcement code is skipped over. Until ICM quieted the logging, it could also be seen in the logs that the skipped message was still being logged after the fork supposedly happened.

Lastly at https://github.com/industrialcoinmagic/crave/blob/master/src/main.cpp#L2320 the constant passed to IsSporkActive is the timestamp from before, not a spork ID, which causes the InstantX checks to be skipped.

in the config either set listen=0, or port=somethingotherthan30104

Looking at source and looks like dev typoed the timestamp in the spork.h file. In main.h it's 1428537599(April 8 2015), but in spork.h it's 2428537599(December 16 2046). In checkblock if first checks if time is past the first one and sets a flag true, then checks against the second one, and sets it back false. It then skips the mn payment enforcement code since the flag is false.

So masternode payment enforcement isn't actually on, hardfork is set for 31 years from now.

Get this in debug.log every block:

GetSpork::Unknown Spork -1866429697
CheckBlock() : skipping transaction locking checks
CheckBlock() : skipping masternode payment checks

Is payment enforcement actually on?

I'm calling crash to 100k. hardfork still ahead and approaching

If you're honestly looking for a good time to sell, I'd do it within the next 4 hours. People may be celebrating that masternodes are working, but the hard fork hasn't happened yet, and if anything's going to go wrong, that's when it will. drk originally had multiple failed attempts getting mn enforcement working right, and icm just adapted it to a different system in a very short amount of time.

you might want to use the tor packages provided here: https://www.torproject.org/docs/debian.html.en to make sure it's up to date

for multiple nodes you duplicate the service config like this:

HiddenServiceDir /home/username/hidden_service1/
HiddenServicePort 9999 127.0.0.1:9999

HiddenServiceDir /home/username/hidden_service2/
HiddenServicePort 9999 127.0.0.1:9998

HiddenServiceDir /home/username/hidden_service3/
HiddenServicePort 9999 127.0.0.1:9997

the hot machine's config needs that changing port as it's rpcport. masternodeaddr's port is 9999. either listen=0 or changing port is needed to keep them from clashing if doing multiple.

you can add the tor= part to cold config so you don't need to specify each time you run the client.

You don't need any vpses if you run them as tor hidden services.

Run each client instance with a different rpcport and in the hidden service config each serive as 9999 -> 127.0.0.1:actualport. set listen=0 so they don't try to clash on the same port. Specify port 9999 in the masternodeaddr. If doing a hot/cold you need to add tor=127.0.0.1:9050 to the cold wallet's config and it needs tor installed also. I've tested this and gotten it working in 2 vms on one machine (1 vm for hot, 1 for cold) and set up 2mn then shut down the cold vm and got payments for both.

With the default tor config(as a client, not a relay) tor makes outgoing connections only, so you don't even need any exposed ports for that setup, and can block all incoming traffic with iptables

Is this actually practical? It looks like you staked a block, then sent your coins back to yourself a few hours later.

Open the irc.cpp file and add a line #define PRIu64 "llu" near the top. Apparently that constant is defined in the headers in some distros, and not in others. I had to add it in debian, but it compiled without in linux mint.

You can move the coins anytime just like you would normally and your node will just get removed from the list.

If you make a tor mn the address will stay the same even if your ip changes.

How is this mn getting selected so often? http://cryptoplorer.com:3033/address/C1b57q8chz2VqmZZ2tQYimvEBwQDXeMbst

What was the result of this? Can we stake collateral?

You should be able to specify any port mapping in your tor config, so you can run it locally on any port but it will be on 9999 over tor

can you get source up on github so linux users can start compiling?

Unless ICM changed his plans, you're going to need to config a tor hidden service aimed at the wallet also. Doing the 2 wallet method so you don't need your priv key to be on the mn wallet is probably also a good idea, as well as sandboxing everything in a vm.

Staking difficulty dropped to about the lowest it's been in a few days. People are probably moving their coins over to dump.

On a side note I got bit by the orphans again. Hadn't had it happen for 3 days so I thought maybe it was past.