[ANN] CRAVE 1st POS Masternodes | Dark Assets | I2P | Market =Embrace The Dark=

[Papcio77]

How to open it?

[timbereagle]

How to open it?

I do not know how to open, I had 2 internet connection, thats why  I choose the other line in which 9999 port is open.

PS: If anyone knows how to open 9999 port, please let us know.

[Papcio77]

And how to check if my knot work?

[timbereagle]

And how to check if my knot work?

http://www.yougetsignal.com/tools/open-ports/     just write your port and check

[Papcio77]

How to run craved on the server? What is the command to use?

[fmz89]

is dump over

[coinmaster222]

Again can someday tell me where to get a BLUR address is it your crave???

[johnson1990]

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.

Go away fudder who wants cheap coins. The CRAVE dev is smarter than satoshi himself. His code must be perfect. How could there be bugs?  /s

[wasref]

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.

Go away fudder who wants cheap coins. The CRAVE dev is smarter than satoshi himself. His code must be perfect. How could there be bugs?  /s

this guy too funny. crave dev is not even 0.001% of satoshi. the reply from dev should be interesting

[Papcio77]

./craved &
[2] 29601
[1] Exit 127 ./craved
root@vultr:~# ./craved: symbol lookup error: ./craved: undefined symbol: secp256k1_start

[fmz89]

where the dumper,come on dump on me

[TimC]

Again can someday tell me where to get a BLUR address is it your crave???

Blur is an asset, so it is stored on the blockchain. The address that the burned crave came from is the address which owns the blur created.

[Papcio77]

./craved &
[2] 29601
[1] Exit 127 ./craved
root@vultr:~# ./craved: symbol lookup error: ./craved: undefined symbol: secp256k1_start

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

[Yaremi]

./craved &
[2] 29601
[1] Exit 127 ./craved
root@vultr:~# ./craved: symbol lookup error: ./craved: undefined symbol: secp256k1_start

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

Code:

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

Code:

sudo aptitude install libminiupnpc-dev

Code:

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

[fnz]

./craved &
[2] 29601
[1] Exit 127 ./craved
root@vultr:~# ./craved: symbol lookup error: ./craved: undefined symbol: secp256k1_start

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

do a reset in secp256k1 to commit a0d3b89

Code:

git reset a0d3b89

[Thomasvd]

Hi guys,
I bet that there are many people here that believe in this coin.
This also means many of you are probably stuck in a high rate, and would lose much money selling at this rate.
Do not sell your coins!
This dump is just a trick to buy in low again.

We are planning a new pump again.
As you, i am also stuck in a high rate, with much money.
Rate: 0.0072
So again, DO NOT SELL YOUR CRAVE!
Instead of selling your coins, PM ME WHEN YOU HAVE MONEY STUCK BECAUSE OF TROLLS AND DUMPERS.

WE WILL NOT ANN THE NEXT PUMP PUBLIC.
Instead of that. We will give the people that have faith in this coin and are stuck in a high rate a heads up start.

Mine now while it is still possible to get them cheap.

lol we believe you and by the way you do know pow is over  lol. your bags are really heavy

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

The price will go back up.
Many will be working on this.
To many people are high holders...

[Blazin8888]

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.

@industrialcoinmagic

[webprods]

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.

@industrialcoinmagic

Agree with few points.First.My old wallet before fork update was mine at masternode better.2.My second wallet giving me error ( you must add masternode=1 to conf) but I did that .I check out my conf and everything looks ok but masternode didnt start becauseof this error.I did delete 5 times wallet and now I'm scare that I've lost 500 coins from masternode.However I have backup wallet and also copy of wallet .Waiting until this f,,,wallet finally sync so I can see if I lost 500 coins or have them.
Update ...Finally my second wallet after 5 times deleted  is sync.Have that 500 coins .So it's ok except that I getting this  error when I like to set up second masternode at my second system. Error "you must set masternode=1 in the configuration" Here is my configuration
                                      maxconnections=100
rpcuser=myname
rpcpassword=my password
rpcport=9999
gen=0
server=1
daemon=1
reservebalance=9999999
masternodeaddr=my static ip:9999
masternode=1
masternodeprivkey=masternodeprivkey
rpcallowip=127.0.0.1
WHAT DA HELL IS WRONG WITH THIS CONF? Maybe RPCPORT? Help!!!!!!!!!!!

[snafflecoin]

how many master nodes are there up and running?

[Troublesome96]

Your comeback is that I made a grammatical mistake. You might want to take the next few months to clean up your own posts.
And it is actually coattails. I put a space...you left out a letter. mmmmk?

When they are down to scrutinizing your spelling, you know they have ran out of juice.

This seems to be their direction in general.
Thank you for actually noticing.

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.

If I was young biff, I would be smacking you around calling you McFly. Hello? Hello? Anybody home? Think McFly, think.
Your standard bullying tactics compounded with the projection of Biff is classic.

You'll ask me one more time? I guess you think your run this joint or is that more of the biff'ing?