Topic: [ANN] CRAVE 1st POS Masternodes | Dark Assets | I2P | Market =Embrace The Dark= - page 245. (Read 826735 times)

How much crave is needed to run a masternode? I dont have any atm 

Of course you do, you are an idiot too.

Contrary to what you and your idiots friends will have everyone try and believe the facts remain set in forum history!

https://bitcointalksearch.org/topic/m.9182120

Go look and for fucks sake drop pit now please! You don't want to make a thread because you clearly have an agenda!
Live in denial all you want im not your scapegoat, kid!

You probably have a different boost lib, try to compile crave-qt

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.

[1]+  Exit 127                ./craved
root@vultr:~# ./craved &
[1] 8719
root@vultr:~# ./craved: error while loading shared libraries: libboost_system.so.1.46.1: cannot open shared object file: No such file or directory

Pleas Help (

Yup, and now the threats. Another symptom of being totally out of juice. Do you need me to make a speling error to help you?

If a post is off topic, just report it to the moderator. No need to make vague threats in public. I'm flattered that I get under your skin like this, but seriously if you are considering resorting to something that could compromise you later, then you need to take a step back from the keyboard.

SDC has a unique combination of features found in other coins. If anything is new, it's the token idea "borrowed" from zerocoin. I think I've acknowledged the novelty of that idea as implemented in SDC.

There's nothing to "expose" with CRAVE. A coin is a feature set. If the features are broken, then say so. But if nothing is broken, why spend so much energy on it except if you think the market cap of this coin is threatening the cap of your favorite?

how many master nodes are there up and running?

how many master nodes are there up and running?

It was not spelling or a gram mistake, you got the metaphor wrong completely; like young biff did in back to the future "make like a tree and get outta here"  

Ill ask one more time to get on topic. you two are way off it.

@industrialcoinmagic

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.

too much bag holders now in the crave price is going low dramatically and nobody knows who are dumping that coin.

Help someone what I'm doing wrong? Why do I get this message on the server?

git reset a0d3b89

Help someone what I'm doing wrong? Why do I get this message on the server?

sudo apt-get install build-essential libtool autotools-dev autoconf pkg-config libssl-dev libboost-all-dev automake libdb++-dev libssl-dev git

sudo aptitude install libminiupnpc-dev

git clone https://github.com/bitcoin/secp256k1
cd secp256k1
./autogen.sh
./configure
make
sudo make install
cd ..
ldconfig
wget http://104.207.135.209/craved
chmod 777 craved