ltcd.best-pool.com still has not found a block in over 1 hour and 20 minutes.
Cause difficulty is so high from multipools No, their statistics are incorrect. The height on their statistics doesn't match the dashboard (or the actual height.) It's an MPOS thing. |
|
|
|
TrollByFire or Robbert: You should update the OP so that everyone knows that the fork was successful and people can have a little boost in faith for the coin.
It's not 100% successful. Hashlink is wasting its hashes on an incorrect chain  . Someone should notify them. The point is that the coin is safe. The blockchain is not screwing up.. It's Hashlink's fault for not being up to date. Hashlink says they updated. They did. And they are up to date, but the chain forked, and they aren't on the correct fork. This isn't their fault, it's part of the way bitcoin is designed. Eventually their node will sync with the rest of the network, but they can speed up the process by fixing it by hand. |
|
|
|
TrollByFire or Robbert: You should update the OP so that everyone knows that the fork was successful and people can have a little boost in faith for the coin.
It's not 100% successful. Hashlink is wasting its hashes on an incorrect chain . Someone should notify them. Already working on it. Thanks. Net Hashrate 240,642.90 MH/s  Pool Hashrate 3,375.80 MH/s  Multipools hit as soon as it was profitable to mine again. As predicted. |
|
|
|
Not sure if best-pool is on the correct blockchain. Hashlink seems like its on the correct one.
It's the opposite. Best-pool is on the correct blockchain an hashlink is forked out. Best-pool chain is longer. Also, Bittrex is on the same chain as best-pool (I just confirmed it by moving some coins from my wallet which is also in sync with best-pool). ^^^ +1 -- The longer chain will win. That's by design. Bestpool's expected difficulty is apparently 3,000 in 119 blocks.. That's higher than before? Will this work now the mulipools are onboard? That's what it's designed to do. The dashboard doesn't know about the algorithm, so it isn't correct. |
|
|
|
Not sure if best-pool is on the correct blockchain. Hashlink seems like its on the correct one.
It's the opposite. Best-pool is on the correct blockchain an hashlink is forked out. Best-pool chain is longer. Also, Bittrex is on the same chain as best-pool (I just confirmed it by moving some coins from my wallet which is also in sync with best-pool). ^^^ +1 -- The longer chain will win. That's by design. |
|
|
|
Not sure if best-pool is on the correct blockchain. Hashlink seems like its on the correct one. The entire network has to reach concensus before we know which chain is valid. When that happens, all pools will be correct. |
|
|
|
As we said they would. Whichever multipool just hit it, hit it hard. At least they won't leave us stranded again. |
|
|
|
A lot of nodes are having to sync with the longest chain right now. due to how far it dropped, it had to restabilize the difficulty for the proper net hash rate. Once all chains have consensus again, all will be well. Difficulty dropped to zero and basically had to recalculate it's proper place.
Even my solo rig found 34 blocks which were quickly orphaned.
Is the blockchain updated as well as the exchanges? If they updated their wallets, yes. it will take time to sync that many blocks across all nodes in the network. I know that bittrex's wallet was updated. Can't speak for the others. |
|
|
|
|
A lot of nodes are having to sync with the longest chain right now. due to how far it dropped, it had to restabilize the difficulty for the proper net hash rate. Once all chains have consensus again, all will be well. Difficulty dropped to zero and basically had to recalculate it's proper place.
Even my solo rig found 34 blocks which were quickly orphaned.
|
|
|
|
Cloning from the staging repo is now 1.1.0-pre1. You need GCC 4.8.0 or better (recommend 4.9.0) to compile it. -std=c++1y isn't supported by the default GCC in debian 7.
I have created a server using g++ 4.9 from the Debian testing repository, and I am still getting compilation errors with rpcminer.cpp. I fixed one issue by replicating Gavin Andersen's solution in the Bitcoin code (at http://sourceforge.net/p/bitcoin/mailman/message/31375039/) and implementing that solution allowed me to get further but not complete the compilation. The current blocker is: root@debian-test:~/litecoindark-staging/src# make -f makefile.unix USE_UPNP=1 USE_IPV6=1
/bin/sh ../share/genbuild.sh obj/build.h
g++ -c -O2 -pthread -Wall -Wextra -Wformat -Wformat-security -Wno-unused-parameter -g -DBOOST_SPIRIT_THREADSAFE -D_FILE_OFFSET_BITS=64 -DBOOST_NO_CXX11_SCOPED_ENUMS -I/root/litecoindark-staging/src -I/root/litecoindark-staging/src/obj -DUSE_UPNP=1 -DUSE_IPV6=1 -I/root/litecoindark-staging/src/leveldb/include -I/root/litecoindark-staging/src/leveldb/helpers -DHAVE_BUILD_INFO -fno-stack-protector -fstack-protector-all -Wstack-protector -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -std=c++1y -MMD -MF obj/rpcmining.d -o obj/rpcmining.o rpcmining.cpp
In file included from bignum.h:12:0,
from main.h:8,
from rpcmining.cpp:6:
util.h:245:22: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
return strprintf("%"PRI64d, n);
^
In file included from main.h:10:0,
from rpcmining.cpp:6:
net.h:376:20: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
printf("askfor %s %"PRI64d" (%s)\n", inv.ToString().c_str(), nRequestTime, DateTimeStrFormat("%H:%M:%S", nRequestTime/1000000).c_str());
^
In file included from rpcmining.cpp:6:0:
main.h:454:26: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
return strprintf("CTxOut(nValue=%"PRI64d".%08"PRI64d", scriptPubKey=%s)", nValue / COIN, nValue % COIN, scriptPubKey.ToString().substr(0,30).c_str());
^
main.h:454:49: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
return strprintf("CTxOut(nValue=%"PRI64d".%08"PRI64d", scriptPubKey=%s)", nValue / COIN, nValue % COIN, scriptPubKey.ToString().substr(0,30).c_str());
^
main.h:655:26: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
str += strprintf("CTransaction(hash=%s, ver=%d, vin.size=%"PRIszu", vout.size=%"PRIszu", nLockTime=%u)\n",
^
main.h:655:74: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
str += strprintf("CTransaction(hash=%s, ver=%d, vin.size=%"PRIszu", vout.size=%"PRIszu", nLockTime=%u)\n",
^
main.h:1506:16: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
printf("CBlock(hash=%s, input=%s, PoW=%s, ver=%d, hashPrevBlock=%s, hashMerkleRoot=%s, nTime=%u, nBits=%08x, nNonce=%u, vtx=%"PRIszu")\n",
^
rpcmining.cpp: In function ‘json_spirit::Value getblocktemplate(const Array&, bool)’:
rpcmining.cpp:520:59: error: conversion from ‘std::map<uint256, long int>::mapped_type {aka long int}’ to ‘std::vector<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > >, std::allocator<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > > > >::value_type {aka json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > >}’ is ambiguous
deps.push_back(setTxIndex[i[Suspicious link removed]evout.hash]);
^
rpcmining.cpp:520:59: note: candidates are:
In file included from json/json_spirit_reader_template.h:9:0,
from bitcoinrpc.h:16,
from rpcmining.cpp:9:
json/json_spirit_value.h:283:5: note: json_spirit::Value_impl<Config>::Value_impl(double) [with Config = json_spirit::Config_vector<std::basic_string<char> >]
Value_impl< Config >::Value_impl( double value )
^
json/json_spirit_value.h:275:5: note: json_spirit::Value_impl<Config>::Value_impl(boost::uint64_t) [with Config = json_spirit::Config_vector<std::basic_string<char> >; boost::uint64_t = long long unsigned int]
Value_impl< Config >::Value_impl( boost::uint64_t value )
^
json/json_spirit_value.h:267:5: note: json_spirit::Value_impl<Config>::Value_impl(boost::int64_t) [with Config = json_spirit::Config_vector<std::basic_string<char> >; boost::int64_t = long long int]
Value_impl< Config >::Value_impl( boost::int64_t value )
^
json/json_spirit_value.h:259:5: note: json_spirit::Value_impl<Config>::Value_impl(int) [with Config = json_spirit::Config_vector<std::basic_string<char> >]
Value_impl< Config >::Value_impl( int value )
^
json/json_spirit_value.h:251:5: note: json_spirit::Value_impl<Config>::Value_impl(bool) [with Config = json_spirit::Config_vector<std::basic_string<char> >]
Value_impl< Config >::Value_impl( bool value )
^
json/json_spirit_value.h:219:5: note: json_spirit::Value_impl<Config>::Value_impl(json_spirit::Value_impl<Config>::Const_str_ptr) [with Config = json_spirit::Config_vector<std::basic_string<char> >; json_spirit::Value_impl<Config>::Const_str_ptr = const char*] <near match>
Value_impl< Config >::Value_impl( const Const_str_ptr value )
^
json/json_spirit_value.h:219:5: note: no known conversion for argument 1 from ‘std::map<uint256, long int>::mapped_type {aka long int}’ to ‘json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > >::Const_str_ptr {aka const char*}’
In file included from /usr/include/c++/4.9/vector:64:0,
from bignum.h:9,
from main.h:8,
from rpcmining.cpp:6:
/usr/include/c++/4.9/bits/stl_vector.h:931:7: note: initializing argument 1 of ‘void std::vector<_Tp, _Alloc>::push_back(std::vector<_Tp, _Alloc>::value_type&&) [with _Tp = json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > >; _Alloc = std::allocator<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > > >; std::vector<_Tp, _Alloc>::value_type = json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > >]’
push_back(value_type&& __x)
^
rpcmining.cpp:525:79: error: conversion from ‘__gnu_cxx::__alloc_traits<std::allocator<long int> >::value_type {aka long int}’ to ‘const Value_type {aka const json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > >}’ is ambiguous
entry.push_back(Pair("fee", pblocktemplate->vTxFees[index_in_template]));
^
rpcmining.cpp:525:79: note: candidates are:
In file included from json/json_spirit_reader_template.h:9:0,
from bitcoinrpc.h:16,
from rpcmining.cpp:9:
json/json_spirit_value.h:283:5: note: json_spirit::Value_impl<Config>::Value_impl(double) [with Config = json_spirit::Config_vector<std::basic_string<char> >]
Value_impl< Config >::Value_impl( double value )
^
json/json_spirit_value.h:275:5: note: json_spirit::Value_impl<Config>::Value_impl(boost::uint64_t) [with Config = json_spirit::Config_vector<std::basic_string<char> >; boost::uint64_t = long long unsigned int]
Value_impl< Config >::Value_impl( boost::uint64_t value )
^
json/json_spirit_value.h:267:5: note: json_spirit::Value_impl<Config>::Value_impl(boost::int64_t) [with Config = json_spirit::Config_vector<std::basic_string<char> >; boost::int64_t = long long int]
Value_impl< Config >::Value_impl( boost::int64_t value )
^
json/json_spirit_value.h:259:5: note: json_spirit::Value_impl<Config>::Value_impl(int) [with Config = json_spirit::Config_vector<std::basic_string<char> >]
Value_impl< Config >::Value_impl( int value )
^
json/json_spirit_value.h:251:5: note: json_spirit::Value_impl<Config>::Value_impl(bool) [with Config = json_spirit::Config_vector<std::basic_string<char> >]
Value_impl< Config >::Value_impl( bool value )
^
json/json_spirit_value.h:219:5: note: json_spirit::Value_impl<Config>::Value_impl(json_spirit::Value_impl<Config>::Const_str_ptr) [with Config = json_spirit::Config_vector<std::basic_string<char> >; json_spirit::Value_impl<Config>::Const_str_ptr = const char*] <near match>
Value_impl< Config >::Value_impl( const Const_str_ptr value )
^
json/json_spirit_value.h:219:5: note: no known conversion for argument 1 from ‘__gnu_cxx::__alloc_traits<std::allocator<long int> >::value_type {aka long int}’ to ‘json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > >::Const_str_ptr {aka const char*}’
json/json_spirit_value.h:439:5: note: initializing argument 2 of ‘json_spirit::Pair_impl<Config>::Pair_impl(const String_type&, const Value_type&) [with Config = json_spirit::Config_vector<std::basic_string<char> >; json_spirit::Pair_impl<Config>::String_type = std::basic_string<char>; json_spirit::Pair_impl<Config>::Value_type = json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > >]’
Pair_impl< Config >::Pair_impl( const String_type& name, const Value_type& value )
^
rpcmining.cpp:526:84: error: conversion from ‘__gnu_cxx::__alloc_traits<std::allocator<long int> >::value_type {aka long int}’ to ‘const Value_type {aka const json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > >}’ is ambiguous
entry.push_back(Pair("sigops", pblocktemplate->vTxSigOps[index_in_template]));
^
rpcmining.cpp:526:84: note: candidates are:
In file included from json/json_spirit_reader_template.h:9:0,
from bitcoinrpc.h:16,
from rpcmining.cpp:9:
json/json_spirit_value.h:283:5: note: json_spirit::Value_impl<Config>::Value_impl(double) [with Config = json_spirit::Config_vector<std::basic_string<char> >]
Value_impl< Config >::Value_impl( double value )
^
json/json_spirit_value.h:275:5: note: json_spirit::Value_impl<Config>::Value_impl(boost::uint64_t) [with Config = json_spirit::Config_vector<std::basic_string<char> >; boost::uint64_t = long long unsigned int]
Value_impl< Config >::Value_impl( boost::uint64_t value )
^
json/json_spirit_value.h:267:5: note: json_spirit::Value_impl<Config>::Value_impl(boost::int64_t) [with Config = json_spirit::Config_vector<std::basic_string<char> >; boost::int64_t = long long int]
Value_impl< Config >::Value_impl( boost::int64_t value )
^
json/json_spirit_value.h:259:5: note: json_spirit::Value_impl<Config>::Value_impl(int) [with Config = json_spirit::Config_vector<std::basic_string<char> >]
Value_impl< Config >::Value_impl( int value )
^
json/json_spirit_value.h:251:5: note: json_spirit::Value_impl<Config>::Value_impl(bool) [with Config = json_spirit::Config_vector<std::basic_string<char> >]
Value_impl< Config >::Value_impl( bool value )
^
json/json_spirit_value.h:219:5: note: json_spirit::Value_impl<Config>::Value_impl(json_spirit::Value_impl<Config>::Const_str_ptr) [with Config = json_spirit::Config_vector<std::basic_string<char> >; json_spirit::Value_impl<Config>::Const_str_ptr = const char*] <near match>
Value_impl< Config >::Value_impl( const Const_str_ptr value )
^
json/json_spirit_value.h:219:5: note: no known conversion for argument 1 from ‘__gnu_cxx::__alloc_traits<std::allocator<long int> >::value_type {aka long int}’ to ‘json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > >::Const_str_ptr {aka const char*}’
json/json_spirit_value.h:439:5: note: initializing argument 2 of ‘json_spirit::Pair_impl<Config>::Pair_impl(const String_type&, const Value_type&) [with Config = json_spirit::Config_vector<std::basic_string<char> >; json_spirit::Pair_impl<Config>::String_type = std::basic_string<char>; json_spirit::Pair_impl<Config>::Value_type = json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > >]’
Pair_impl< Config >::Pair_impl( const String_type& name, const Value_type& value )
^
rpcmining.cpp:549:82: error: conversion from ‘int64_t {aka long int}’ to ‘const Value_type {aka const json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > >}’ is ambiguous
result.push_back(Pair("coinbasevalue", (int64_t)pblock->vtx[0].vout[0].nValue));
^
rpcmining.cpp:549:82: note: candidates are:
In file included from json/json_spirit_reader_template.h:9:0,
from bitcoinrpc.h:16,
from rpcmining.cpp:9:
json/json_spirit_value.h:283:5: note: json_spirit::Value_impl<Config>::Value_impl(double) [with Config = json_spirit::Config_vector<std::basic_string<char> >]
Value_impl< Config >::Value_impl( double value )
^
json/json_spirit_value.h:275:5: note: json_spirit::Value_impl<Config>::Value_impl(boost::uint64_t) [with Config = json_spirit::Config_vector<std::basic_string<char> >; boost::uint64_t = long long unsigned int]
Value_impl< Config >::Value_impl( boost::uint64_t value )
^
json/json_spirit_value.h:267:5: note: json_spirit::Value_impl<Config>::Value_impl(boost::int64_t) [with Config = json_spirit::Config_vector<std::basic_string<char> >; boost::int64_t = long long int]
Value_impl< Config >::Value_impl( boost::int64_t value )
^
json/json_spirit_value.h:259:5: note: json_spirit::Value_impl<Config>::Value_impl(int) [with Config = json_spirit::Config_vector<std::basic_string<char> >]
Value_impl< Config >::Value_impl( int value )
^
json/json_spirit_value.h:251:5: note: json_spirit::Value_impl<Config>::Value_impl(bool) [with Config = json_spirit::Config_vector<std::basic_string<char> >]
Value_impl< Config >::Value_impl( bool value )
^
json/json_spirit_value.h:219:5: note: json_spirit::Value_impl<Config>::Value_impl(json_spirit::Value_impl<Config>::Const_str_ptr) [with Config = json_spirit::Config_vector<std::basic_string<char> >; json_spirit::Value_impl<Config>::Const_str_ptr = const char*] <near match>
Value_impl< Config >::Value_impl( const Const_str_ptr value )
^
json/json_spirit_value.h:219:5: note: no known conversion for argument 1 from ‘int64_t {aka long int}’ to ‘json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > >::Const_str_ptr {aka const char*}’
json/json_spirit_value.h:439:5: note: initializing argument 2 of ‘json_spirit::Pair_impl<Config>::Pair_impl(const String_type&, const Value_type&) [with Config = json_spirit::Config_vector<std::basic_string<char> >; json_spirit::Pair_impl<Config>::String_type = std::basic_string<char>; json_spirit::Pair_impl<Config>::Value_type = json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > >]’
Pair_impl< Config >::Pair_impl( const String_type& name, const Value_type& value )
^
rpcmining.cpp:551:80: error: conversion from ‘int64_t {aka long int}’ to ‘const Value_type {aka const json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > >}’ is ambiguous
result.push_back(Pair("mintime", (int64_t)pindexPrev->GetMedianTimePast()+1));
^
rpcmining.cpp:551:78: note: candidates are:
result.push_back(Pair("mintime", (int64_t)pindexPrev->GetMedianTimePast()+1));
^
In file included from json/json_spirit_reader_template.h:9:0,
from bitcoinrpc.h:16,
from rpcmining.cpp:9:
json/json_spirit_value.h:283:5: note: json_spirit::Value_impl<Config>::Value_impl(double) [with Config = json_spirit::Config_vector<std::basic_string<char> >]
Value_impl< Config >::Value_impl( double value )
^
json/json_spirit_value.h:275:5: note: json_spirit::Value_impl<Config>::Value_impl(boost::uint64_t) [with Config = json_spirit::Config_vector<std::basic_string<char> >; boost::uint64_t = long long unsigned int]
Value_impl< Config >::Value_impl( boost::uint64_t value )
^
json/json_spirit_value.h:267:5: note: json_spirit::Value_impl<Config>::Value_impl(boost::int64_t) [with Config = json_spirit::Config_vector<std::basic_string<char> >; boost::int64_t = long long int]
Value_impl< Config >::Value_impl( boost::int64_t value )
^
json/json_spirit_value.h:259:5: note: json_spirit::Value_impl<Config>::Value_impl(int) [with Config = json_spirit::Config_vector<std::basic_string<char> >]
Value_impl< Config >::Value_impl( int value )
^
json/json_spirit_value.h:251:5: note: json_spirit::Value_impl<Config>::Value_impl(bool) [with Config = json_spirit::Config_vector<std::basic_string<char> >]
Value_impl< Config >::Value_impl( bool value )
^
json/json_spirit_value.h:219:5: note: json_spirit::Value_impl<Config>::Value_impl(json_spirit::Value_impl<Config>::Const_str_ptr) [with Config = json_spirit::Config_vector<std::basic_string<char> >; json_spirit::Value_impl<Config>::Const_str_ptr = const char*] <near match>
Value_impl< Config >::Value_impl( const Const_str_ptr value )
^
json/json_spirit_value.h:219:5: note: no known conversion for argument 1 from ‘int64_t {aka long int}’ to ‘json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > >::Const_str_ptr {aka const char*}’
json/json_spirit_value.h:439:5: note: initializing argument 2 of ‘json_spirit::Pair_impl<Config>::Pair_impl(const String_type&, const Value_type&) [with Config = json_spirit::Config_vector<std::basic_string<char> >; json_spirit::Pair_impl<Config>::String_type = std::basic_string<char>; json_spirit::Pair_impl<Config>::Value_type = json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > >]’
Pair_impl< Config >::Pair_impl( const String_type& name, const Value_type& value )
^
rpcmining.cpp:554:66: error: conversion from ‘int64_t {aka long int}’ to ‘const Value_type {aka const json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > >}’ is ambiguous
result.push_back(Pair("sigoplimit", (int64_t)MAX_BLOCK_SIGOPS));
^
rpcmining.cpp:554:66: note: candidates are:
In file included from json/json_spirit_reader_template.h:9:0,
from bitcoinrpc.h:16,
from rpcmining.cpp:9:
json/json_spirit_value.h:283:5: note: json_spirit::Value_impl<Config>::Value_impl(double) [with Config = json_spirit::Config_vector<std::basic_string<char> >]
Value_impl< Config >::Value_impl( double value )
^
json/json_spirit_value.h:275:5: note: json_spirit::Value_impl<Config>::Value_impl(boost::uint64_t) [with Config = json_spirit::Config_vector<std::basic_string<char> >; boost::uint64_t = long long unsigned int]
Value_impl< Config >::Value_impl( boost::uint64_t value )
^
json/json_spirit_value.h:267:5: note: json_spirit::Value_impl<Config>::Value_impl(boost::int64_t) [with Config = json_spirit::Config_vector<std::basic_string<char> >; boost::int64_t = long long int]
Value_impl< Config >::Value_impl( boost::int64_t value )
^
json/json_spirit_value.h:259:5: note: json_spirit::Value_impl<Config>::Value_impl(int) [with Config = json_spirit::Config_vector<std::basic_string<char> >]
Value_impl< Config >::Value_impl( int value )
^
json/json_spirit_value.h:251:5: note: json_spirit::Value_impl<Config>::Value_impl(bool) [with Config = json_spirit::Config_vector<std::basic_string<char> >]
Value_impl< Config >::Value_impl( bool value )
^
json/json_spirit_value.h:219:5: note: json_spirit::Value_impl<Config>::Value_impl(json_spirit::Value_impl<Config>::Const_str_ptr) [with Config = json_spirit::Config_vector<std::basic_string<char> >; json_spirit::Value_impl<Config>::Const_str_ptr = const char*] <near match>
Value_impl< Config >::Value_impl( const Const_str_ptr value )
^
json/json_spirit_value.h:219:5: note: no known conversion for argument 1 from ‘int64_t {aka long int}’ to ‘json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > >::Const_str_ptr {aka const char*}’
json/json_spirit_value.h:439:5: note: initializing argument 2 of ‘json_spirit::Pair_impl<Config>::Pair_impl(const String_type&, const Value_type&) [with Config = json_spirit::Config_vector<std::basic_string<char> >; json_spirit::Pair_impl<Config>::String_type = std::basic_string<char>; json_spirit::Pair_impl<Config>::Value_type = json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > >]’
Pair_impl< Config >::Pair_impl( const String_type& name, const Value_type& value )
^
rpcmining.cpp:555:63: error: conversion from ‘int64_t {aka long int}’ to ‘const Value_type {aka const json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > >}’ is ambiguous
result.push_back(Pair("sizelimit", (int64_t)MAX_BLOCK_SIZE));
^
rpcmining.cpp:555:63: note: candidates are:
In file included from json/json_spirit_reader_template.h:9:0,
from bitcoinrpc.h:16,
from rpcmining.cpp:9:
json/json_spirit_value.h:283:5: note: json_spirit::Value_impl<Config>::Value_impl(double) [with Config = json_spirit::Config_vector<std::basic_string<char> >]
Value_impl< Config >::Value_impl( double value )
^
json/json_spirit_value.h:275:5: note: json_spirit::Value_impl<Config>::Value_impl(boost::uint64_t) [with Config = json_spirit::Config_vector<std::basic_string<char> >; boost::uint64_t = long long unsigned int]
Value_impl< Config >::Value_impl( boost::uint64_t value )
^
json/json_spirit_value.h:267:5: note: json_spirit::Value_impl<Config>::Value_impl(boost::int64_t) [with Config = json_spirit::Config_vector<std::basic_string<char> >; boost::int64_t = long long int]
Value_impl< Config >::Value_impl( boost::int64_t value )
^
json/json_spirit_value.h:259:5: note: json_spirit::Value_impl<Config>::Value_impl(int) [with Config = json_spirit::Config_vector<std::basic_string<char> >]
Value_impl< Config >::Value_impl( int value )
^
json/json_spirit_value.h:251:5: note: json_spirit::Value_impl<Config>::Value_impl(bool) [with Config = json_spirit::Config_vector<std::basic_string<char> >]
Value_impl< Config >::Value_impl( bool value )
^
json/json_spirit_value.h:219:5: note: json_spirit::Value_impl<Config>::Value_impl(json_spirit::Value_impl<Config>::Const_str_ptr) [with Config = json_spirit::Config_vector<std::basic_string<char> >; json_spirit::Value_impl<Config>::Const_str_ptr = const char*] <near match>
Value_impl< Config >::Value_impl( const Const_str_ptr value )
^
json/json_spirit_value.h:219:5: note: no known conversion for argument 1 from ‘int64_t {aka long int}’ to ‘json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > >::Const_str_ptr {aka const char*}’
json/json_spirit_value.h:439:5: note: initializing argument 2 of ‘json_spirit::Pair_impl<Config>::Pair_impl(const String_type&, const Value_type&) [with Config = json_spirit::Config_vector<std::basic_string<char> >; json_spirit::Pair_impl<Config>::String_type = std::basic_string<char>; json_spirit::Pair_impl<Config>::Value_type = json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > >]’
Pair_impl< Config >::Pair_impl( const String_type& name, const Value_type& value )
^
rpcmining.cpp:556:60: error: conversion from ‘int64_t {aka long int}’ to ‘const Value_type {aka const json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > >}’ is ambiguous
result.push_back(Pair("curtime", (int64_t)pblock->nTime));
^
rpcmining.cpp:556:60: note: candidates are:
In file included from json/json_spirit_reader_template.h:9:0,
from bitcoinrpc.h:16,
from rpcmining.cpp:9:
json/json_spirit_value.h:283:5: note: json_spirit::Value_impl<Config>::Value_impl(double) [with Config = json_spirit::Config_vector<std::basic_string<char> >]
Value_impl< Config >::Value_impl( double value )
^
json/json_spirit_value.h:275:5: note: json_spirit::Value_impl<Config>::Value_impl(boost::uint64_t) [with Config = json_spirit::Config_vector<std::basic_string<char> >; boost::uint64_t = long long unsigned int]
Value_impl< Config >::Value_impl( boost::uint64_t value )
^
json/json_spirit_value.h:267:5: note: json_spirit::Value_impl<Config>::Value_impl(boost::int64_t) [with Config = json_spirit::Config_vector<std::basic_string<char> >; boost::int64_t = long long int]
Value_impl< Config >::Value_impl( boost::int64_t value )
^
json/json_spirit_value.h:259:5: note: json_spirit::Value_impl<Config>::Value_impl(int) [with Config = json_spirit::Config_vector<std::basic_string<char> >]
Value_impl< Config >::Value_impl( int value )
^
json/json_spirit_value.h:251:5: note: json_spirit::Value_impl<Config>::Value_impl(bool) [with Config = json_spirit::Config_vector<std::basic_string<char> >]
Value_impl< Config >::Value_impl( bool value )
^
json/json_spirit_value.h:219:5: note: json_spirit::Value_impl<Config>::Value_impl(json_spirit::Value_impl<Config>::Const_str_ptr) [with Config = json_spirit::Config_vector<std::basic_string<char> >; json_spirit::Value_impl<Config>::Const_str_ptr = const char*] <near match>
Value_impl< Config >::Value_impl( const Const_str_ptr value )
^
json/json_spirit_value.h:219:5: note: no known conversion for argument 1 from ‘int64_t {aka long int}’ to ‘json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > >::Const_str_ptr {aka const char*}’
json/json_spirit_value.h:439:5: note: initializing argument 2 of ‘json_spirit::Pair_impl<Config>::Pair_impl(const String_type&, const Value_type&) [with Config = json_spirit::Config_vector<std::basic_string<char> >; json_spirit::Pair_impl<Config>::String_type = std::basic_string<char>; json_spirit::Pair_impl<Config>::Value_type = json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > >]’
Pair_impl< Config >::Pair_impl( const String_type& name, const Value_type& value )
^
rpcmining.cpp:558:69: error: conversion from ‘int64_t {aka long int}’ to ‘const Value_type {aka const json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > >}’ is ambiguous
result.push_back(Pair("height", (int64_t)(pindexPrev->nHeight+1)));
^
rpcmining.cpp:558:69: note: candidates are:
In file included from json/json_spirit_reader_template.h:9:0,
from bitcoinrpc.h:16,
from rpcmining.cpp:9:
json/json_spirit_value.h:283:5: note: json_spirit::Value_impl<Config>::Value_impl(double) [with Config = json_spirit::Config_vector<std::basic_string<char> >]
Value_impl< Config >::Value_impl( double value )
^
json/json_spirit_value.h:275:5: note: json_spirit::Value_impl<Config>::Value_impl(boost::uint64_t) [with Config = json_spirit::Config_vector<std::basic_string<char> >; boost::uint64_t = long long unsigned int]
Value_impl< Config >::Value_impl( boost::uint64_t value )
^
json/json_spirit_value.h:267:5: note: json_spirit::Value_impl<Config>::Value_impl(boost::int64_t) [with Config = json_spirit::Config_vector<std::basic_string<char> >; boost::int64_t = long long int]
Value_impl< Config >::Value_impl( boost::int64_t value )
^
json/json_spirit_value.h:259:5: note: json_spirit::Value_impl<Config>::Value_impl(int) [with Config = json_spirit::Config_vector<std::basic_string<char> >]
Value_impl< Config >::Value_impl( int value )
^
json/json_spirit_value.h:251:5: note: json_spirit::Value_impl<Config>::Value_impl(bool) [with Config = json_spirit::Config_vector<std::basic_string<char> >]
Value_impl< Config >::Value_impl( bool value )
^
json/json_spirit_value.h:219:5: note: json_spirit::Value_impl<Config>::Value_impl(json_spirit::Value_impl<Config>::Const_str_ptr) [with Config = json_spirit::Config_vector<std::basic_string<char> >; json_spirit::Value_impl<Config>::Const_str_ptr = const char*] <near match>
Value_impl< Config >::Value_impl( const Const_str_ptr value )
^
json/json_spirit_value.h:219:5: note: no known conversion for argument 1 from ‘int64_t {aka long int}’ to ‘json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > >::Const_str_ptr {aka const char*}’
json/json_spirit_value.h:439:5: note: initializing argument 2 of ‘json_spirit::Pair_impl<Config>::Pair_impl(const String_type&, const Value_type&) [with Config = json_spirit::Config_vector<std::basic_string<char> >; json_spirit::Pair_impl<Config>::String_type = std::basic_string<char>; json_spirit::Pair_impl<Config>::Value_type = json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char> > >]’
Pair_impl< Config >::Pair_impl( const String_type& name, const Value_type& value )
^
make: *** [obj/rpcmining.o] Error 1
I manage the scrypt multi-pool Prohashing.com, and I would like to add Litecoindark as one of the coins available for payout. I was ready to do this with LTCD version 1.0.1 but the fork and the inability to compile version 1.1.0 has forced me to delayed the rollout. Could you resolve these errors so that I can enable LTCD payouts? I haven't actually even touched rpcmining.cpp yet. I'll look through these issues and try to submit a fix (or at least let you know what I've done) as soon as possible. Thanks. |
|
|
|
|
Also note: I am now sitting behind a Mac. OSX wallets soon.
|
|
|
|
Yes, and a lot of invalids happen during the ramp-up period of renting hashrate from nicehash/westhash. You don't have to be the top bidder, just be close to it and you'll push hashes that way. As rented miners switch between renters (a few of which are already pointing at best-pool) the invalid rate goes way up. |
|
|
|
|
So glad to see so much community support. Thank you all for contributing to getting us over this bump (which is getting closer and closer by the block.)
|
|
|
|
Thats just the bottom.... im sorry for this Guys way of Words.
Xircom, before I move on let me tell you that you are too stupid to realize that litecoindark just lost a LOT of cred with miners and exchanges due to this amateur hour. That can be fatal for a coin. Later son …. ~L)L~ ) n the field of software development, trunk refers to the unnamed branch (version) of a file tree under revision control. The trunk is usually meant to be the base of a project on which development progresses. If developers are working exclusively on the trunk, it always contains the latest cutting-edge version of the project, but therefore may also be the most unstable version. Another approach is to split a branch off the trunk, implement changes in that branch and merge the changes back into the trunk when the branch has proven to be stable and working. Depending on development mode and commit policy the trunk may contain the most stable or the least stable or something-in-between version.
Again, thank you for your opinion. |
|
|
|
And with respect maybe you missed the part of litecoin's documentation where it states that they have the same policy. This is fairly common practice throughout the software development industry. Some people prefer to work in a "develop" branch instead. We'll see, but if you want "stable" and "tested", always use a particular branch and/or tag.
Don't lecture me about software development. I was writing unix device drivers 35 years ago. And here's a bit of advice, don't expect people to dig through your documentation to find out that you are using non-standard development methodology and that your master branch is a piece of crap. You are a fucking idiot. First, for publishing a master commit that doesn't work. Second for trying to play in this game with 6 kids, several jobs, and no sleep for 36 hours. Thank you for your opinion. |
|
|
|
|
It has something to do with MPOS not connecting to their compiled daemon. I have not had a chance to speak with the best-pool team as I was predisposed earlier when the PM arrived. If you are wiling to help as well, great, and thank you.
|
|
|
|
Also note that the "master" branch is not intended to be stable. Each release tree carries its own branch and tag. I can't expect them to know which repo to use, but even the official repo had a branch ltcd-1.0.1 and tag litecoindark-1.0.1 that was newer than the rollback and did sync properly. Maybe I should reconsider this policy due to the many who do not know how to checkout a branch...
Dude, with respect maybe you should reconsider this policy for those of us who do know how to check out a branch but expect master to be stable. +1 hence master. And with respect maybe you missed the part of litecoin's documentation where it states that they have the same policy. This is fairly common practice throughout the software development industry. Some people prefer to work in a "develop" branch instead. We'll see, but if you want "stable" and "tested", always use a particular branch and/or tag. guess I've been in a hole the past few years along with all my project partners. I didn't say everyone does this. But it is extremely common practice. I meant no offense in any case. |
|
|
|
Also note that the "master" branch is not intended to be stable. Each release tree carries its own branch and tag. I can't expect them to know which repo to use, but even the official repo had a branch ltcd-1.0.1 and tag litecoindark-1.0.1 that was newer than the rollback and did sync properly. Maybe I should reconsider this policy due to the many who do not know how to checkout a branch...
Dude, with respect maybe you should reconsider this policy for those of us who do know how to check out a branch but expect master to be stable. +1 hence master. And with respect maybe you missed the part of litecoin's documentation where it states that they have the same policy. This is fairly common practice throughout the software development industry. Some people prefer to work in a "develop" branch instead. We'll see, but if you want "stable" and "tested", always use a particular branch and/or tag. |
|
|
|
I have no direct access to the primary github. All I can do is send a pull request, which I may have neglected to do in my sleepless state. I apologize for this, and am submitting the request now. As for the OP, I do agree that the staging repo should be listed, but again, have not even had the chance to address this with Rob.
I know that you are working hard, but please coordinate the communication better for the sake of LTCD. Also, did you coordinate with exchanges and confirmed that they updated their wallets to the new version? I assure you that they don't read this thread and won't know that there is a fork if the new version isn't even in the official repository. I am just the coder. I also have multiple real jobs and a life to live outside of crypto. I don't get paid for what I do, nor do I have time to handle every request or issue personally or even in a timely fashion. I am a 32 year old father of six who is badly in need of sleep. This is why there are other team members. We work great as a team, but our greatest weakness is in the fact that we live on different continents and timezones are way off. Not trying to be defensive, just saying that if there are any shortcomings, please understand that I'm not the only person involved, even if I do tend to be the most vocal. And I did speak with people from exchanges, but I was also busy with other major issues. As it stands, I have yet to find time to assist best-pool with their issue. I can assure you that I will, but there are only so many things one man can do at once. |
|
|
|
pchMessageStart should never have been kept the same as litecoin's.
This is true. The same goes for standard Litecoin's difficulty adjustment used for a late-2014 scrypt coin - never should happen unless someone have been living in a cave for the last year and wasn't up to speed with altcoins  . I see that you rolled back to original pchMessageStart in your fork (I was referring to the official repo which does have changed pchMessageStart). That's good. It is possible to change it, but it needs to be smooth (e.g. a transitional version which would accept both new and old values up until some block height after which it would only accept the new one). Any reason why the new version isn't available from the official git repository? Yours isn't even listed from the first post. This really creates confusion. You don't even need any external FUD if people can't get wallet to work. Source from original repo is broken, because the latest version includes changed pchMessageStart so this client won't connect to the network. Even if it wasn't broken, it would be outdated in just 27 blocks. The new version is on some outside repository which isn't even linked from OP. This is madness Please update official repository or link your repository in the OP in a visible place. Otherwise how can you expect people to upgrade? I have no direct access to the primary github. All I can do is send a pull request, which I may have neglected to do in my sleepless state. I apologize for this, and am submitting the request now. As for the OP, I do agree that the staging repo should be listed, but again, have not even had the chance to address this with Rob. Also note that the "master" branch is not intended to be stable. Each release tree carries its own branch and tag. I can't expect them to know which repo to use, but even the official repo had a branch ltcd-1.0.1 and tag litecoindark-1.0.1 that was newer than the rollback and did sync properly. Maybe I should reconsider this policy due to the many who do not know how to checkout a branch... |
|
|
|
|
Show Posts
