Papcio77
|
|
April 13, 2015, 10:54:17 AM |
|
How to open it?
|
|
|
|
timbereagle
|
|
April 13, 2015, 10:56:34 AM |
|
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
|
|
April 13, 2015, 10:59:49 AM |
|
And how to check if my knot work?
|
|
|
|
|
Papcio77
|
|
April 13, 2015, 11:05:43 AM |
|
How to run craved on the server? What is the command to use?
|
|
|
|
fmz89
Legendary
Offline
Activity: 1762
Merit: 1002
|
|
April 13, 2015, 11:08:45 AM |
|
is dump over
|
|
|
|
coinmaster222
|
|
April 13, 2015, 11:12:45 AM |
|
Again can someday tell me where to get a BLUR address is it your crave? ??
|
|
|
|
johnson1990
Jr. Member
Offline
Activity: 224
Merit: 1
|
|
April 13, 2015, 11:12:57 AM |
|
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
|
|
April 13, 2015, 11:16:22 AM |
|
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
|
|
April 13, 2015, 11:17:56 AM |
|
./craved & [2] 29601 [1] Exit 127 ./craved root@vultr:~# ./craved: symbol lookup error: ./craved: undefined symbol: secp256k1_start
|
|
|
|
fmz89
Legendary
Offline
Activity: 1762
Merit: 1002
|
|
April 13, 2015, 11:20:53 AM |
|
where the dumper,come on dump on me
|
|
|
|
TimC
Legendary
Offline
Activity: 1764
Merit: 1022
|
|
April 13, 2015, 11:25:31 AM |
|
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
|
|
April 13, 2015, 11:27:35 AM |
|
./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
Legendary
Offline
Activity: 1960
Merit: 1156
|
|
April 13, 2015, 11:42:20 AM |
|
./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? 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
|
|
|
|
fnz
Newbie
Offline
Activity: 21
Merit: 0
|
|
April 13, 2015, 11:55:22 AM |
|
./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
|
|
|
|
Thomasvd
Newbie
Offline
Activity: 30
Merit: 0
|
|
April 13, 2015, 11:59:39 AM |
|
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
|
|
April 13, 2015, 12:00:10 PM |
|
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
Sr. Member
Offline
Activity: 308
Merit: 250
Millionaires Club 47
|
|
April 13, 2015, 12:15:23 PM |
|
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!!!!!!!!!!!
|
Altcoins programming is a race between software engineers, who strive to produce idiot-proof programs, and the universe which strives to produce bigger idiots
|
|
|
snafflecoin
|
|
April 13, 2015, 12:16:26 PM |
|
how many master nodes are there up and running?
|
|
|
|
Troublesome96
|
|
April 13, 2015, 12:17:58 PM |
|
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?
|
|
|
|
|