What's the status of percent total that can be dug having been dug? Is there a nice website that shows starts like this?
The client has this information via getinfo. Is there a public facing daemon I can make RPC calls with? Seems a little silly to sync entire blockchain to get the answer to a simple question about a coin I don't currently own any of... If it'll help ... "blocks" : 1447934,
"moneysupply" : 16117986.13048927,
"digsupply" : 850917.81888962,
"stakesupply" : 1343584.72641731,
"activesupply" : 2194502.54530693,
"proof-of-stake" : 83263.57566592998
Cheers Graham |
|
|
|
Srry for bothering where i can learn how to use CLI slimcoind
It's no bother, it's why this thread exists  You can open the debug window, select the console tab and type help on the built-in console which results in the following list of commands ... addmultisigaddress <nrequired> <'["key","key"]'> [account]
backupwallet <destination>
burncoins <fromaccount> <amount> [minconf=1] [comment] [comment-to]
calcburnhash [fPrintRegardless=false]
checkwallet
dumpprivkey <slimcoinaddress>
encryptwallet <passphrase>
getaccount <slimcoinaddress>
getaccountaddress <account>
getaddressesbyaccount <account>
getbalance [account] [minconf=1]
getblock <hash> [txinfo]
getblockcount
getblockhash <index>
getblocktemplate [params]
getburndata
getcheckpoint
getconnectioncount
getdifficulty
getgenerate
gethashespersec
getinfo
getmemorypool [data]
getmininginfo
getnetworkghps
getnewaddress [account]
getpeerinfo
getrawtransaction <txid> [verbose=0]
getreceivedbyaccount <account> [minconf=1]
getreceivedbyaddress <slimcoinaddress> [minconf=1]
gettransaction <txid>
getwork [data]
help [command]
importpassphrase "<passphrase>" [label]
importprivkey <slimcoinprivkey> [label]
keypoolrefill
listaccounts [minconf=1]
listburnminted [verbose=false]
listreceivedbyaccount [minconf=1] [includeempty=false]
listreceivedbyaddress [minconf=1] [includeempty=false]
listsinceblock [blockhash] [target-confirmations]
listtransactions [account="*"] [fBurnTx=false] [count=10] [from=0]
makekeypair [prefix]
move <fromaccount> <toaccount> <amount> [minconf=1] [comment]
repairwallet
reservebalance [<reserve> [amount]]
sendalert <message> <privatekey> <minver> <maxver> <priority> <id> [cancelupto]
sendfrom <fromaccount> <toslimcoinaddress> <amount> [minconf=1] [comment] [comment-to]
sendmany <fromaccount> {address:amount,...} [minconf=1] [comment]
sendrawtransaction <hex string>
sendtoaddress <slimcoinaddress> <amount> [comment] [comment-to]
setaccount <slimcoinaddress> <account>
setgenerate <generate> [genproclimit]
settxfee <amount>
signmessage <slimcoinaddress> <message>
signrawtransaction <hex string> [{"txid":txid,"vout":n,"scriptPubKey":hex},...] [<privatekey1>,...] [sighashtype="ALL"]
stop
submitblock <hex data> [optional-params-obj]
validateaddress <slimcoinaddress>
verifymessage <slimcoinaddress> <signature> <message>
Detailed help on each command is available by typing help <command>, e.g. help submitblocksubmitblock <hex data> [optional-params-obj]
[optional-params-obj] parameter is currently ignored.
Attempts to submit new block to network.
See https://en.bitcoin.it/wiki/BIP_0022 for full specification.
(You can also use the CLI with the headless daemon by setting listen=1 in the config file and then ./slimcoind help submitblock for example). BTW, there's a list of command-line options at the foot of the master branch's README file https://github.com/slimcoin-project/Slimcoin/blob/master/README.mdHTH Cheers Graham Edit: added README ref |
|
|
|
is this coin a chinese coin?
why is it being traded traded with CNY? and at 100X lower the price and 80X the volume?
well maybe because it's no fee, so the volume may be bloated, but 100X lower the price? dat arbitrage.
1. No. 2. Because it’s a wide, wide, unregulated world in which two altcoins with the same name and trading symbol can exist simultaneously. 3. No. https://www.19800.com/chc/infoHTH Cheers Graham |
|
|
|
I can reproduce the error on my OS X Sierra VM. I will check it on 16.10 later (after I've upgraded my laptop), expecting to see the same error there. Likely to be a version-related C++1z issue.
Wrong. Fortunately wrong: looks like it's just a trivial fix of a transcription error. https://github.com/slimcoin-project/Slimcoin/commit/a73bb282dc7d61a9eaa44902f850cc064d371dd5Compiles and synchs up to date (from the downloaded datadir tar.gz) on Ubuntu 16.10 and OS X Sierra. ( Edit: and Ubuntu 15.04) There's still some qmake config work yet to be done on getting the Qt moc files automatically generated. Until then, if “ #include optionsdialog.moc” and its ilk proves a compilation-stopper, you will need to run ” moc xxx.h > xxx.moc” for each of optionsdialog, overviewpage, rpcconsole and torrentpage. Edit: after a make clean, on the initial run, compilation won't proceed until you create them. on the next run they're reported as duplicates and compilation won't proceed until you delete them, sigh.Cheers Graham |
|
|
|
As I already wrote, I was now able to compile with Boost 1.58. Unfortunately, the slimcoind daemon crashes ("Segmentation Fault") now after receiving the first block (in debug.log I see as last message the CBlock line). Maybe it's the same problem like gavrilo77's.
Tried it also with the version before you deleted the line referring to the != operator. Same problem.
I can reproduce the error on my OS X Sierra VM. I will check it on 16.10 later (after I've upgraded my laptop), expecting to see the same error there. Likely to be a version-related C++1z issue. I believe Debian is still in the process of transitioning to full C++1z support so compilation failures there are to be expected ( https://unix.stackexchange.com/questions/284817/how-to-install-gcc-5-on-debian-jessie-8-1). Travis CI isn't a suitable continuous integration service for Slimcoin master as it stands, it only offers Ubuntu 12.04 or 14.04, both of which are, not to put too fine a point on it, obsolete. https://travis-ci.org/gjhiggins/slimcoin-dev#L148
g++ (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
vs
gjh@ashpool:~$ g++ --version
g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
It's worth noting that Slimcoin 0.5 (as it will be, now that I've figured out the build script uses the version number from the git tag) will be a soft fork in that the blockchain structure is unchanged and clients running previous Slimcoin versions (0.3 & 0.4) will continue to function as before. It's probably possible to avoid the C++[0|1]z issues (specifically the CTxDestination template issue) by paring down the changes to just 1) enabling OP_RETURN tx as standard and 2) disabling the non-functioning sync checkpoint feature. The rest of the changes that I have made are basically in pursuit of UI improvements and so in principle could be confined to a separate “UI-plus” branch. This would allow Slimcoin to continue to run on heritage OS distros whilst still allowing users of contemporary OS distros to leverage the advertised increased robustness and speed of state-of-the-art compiler technology. Cheers Graham |
|
|
|
I have got now this error with boost 1.58 obj/walletdb.o: In function `copy_file':
/usr/local/include/boost/filesystem/operations.hpp:497: undefined reference to `boost::filesystem::detail::copy_file(boost::filesystem::path const&, boost::filesystem::path const&, boost::filesystem::detail::copy_option, boost::system::error_code*)'
collect2: error: ld returned 1 exit status
make: *** [slimcoind] Error 1
I can't explain it failing under 1.58 but I've pushed a commit lifted from PIVX in which presstab created a fix for earlier versions of boost: “Don't use file_copy with boost < 1.58”: https://github.com/slimcoin-project/Slimcoin/commit/4218e2071853c2dbd82d15dafd7b71344aed7a8bCheers Graham |
|
|
|
Thanks for the input, I can see a few approaches to investigating the issue. I retro-populated the checkpoint list with checkpoints (the old list ended at block height 121300), resolving the remaining checkpoint test failures. Running test_slimcoin now returns: Running 62 test cases...
*** No errors detected
(There is one problematic commented-out basic tx i/o test which results in a low-level error but I suspect that the problem lies with the test code itself rather than what's being tested.) Next up: configuration of deployment scripting and continuous integration - which will provide a more tractable platform for investigating OS/library-based issues. Cheers Graham |
|
|
|
uint256.h:473:13: note: no known conversion for argument 1 from ‘CTxDestination {aka boost::variant<CNoDestination, CKeyID, CScriptID, CStealthAddress>}’ to ‘const base_uint160& {aka const base_uint<160u>&}’
I wonder ... Line #319 in src/base58.h showed up as a discrepancy between the PPCoin code ( https://github.com/peercoin/peercoin/blob/master/src/base58.h#L250) in which it is absent and the Slimcoin code ( https://github.com/slimcoin-project/Slimcoin/blob/master/src/base58.h#L319) in which it is present. Absence/presence made no difference to the success of the compilation or (apparently) to the execution of the binary. Given that it's a != operator which is the focus “ note: bool operator!=(const uint160&, uint64)” and a skim of the DDG search results for similar compiler error messages reveals mentions of duplicate definitions, p'raps it's related to the issue in point. I've pushed a new commit in which that apparently superfluous line of code is commented out, does that fix the issue? Cheers Graham |
|
|
|
uint256.h:473:13: note: no known conversion for argument 1 from ‘CTxDestination {aka boost::variant<CNoDestination, CKeyID, CScriptID, CStealthAddress>}’ to ‘const base_uint160& {aka const base_uint<160u>&}’
On this machine (Ubuntu 14.04), Boost 1.54 or 1.55 are available (I tried it with both). On another machine with Boost 1.60 "master" at least compiles fine. Is there a minimum Boost version for Slimcoin? As there is no backport available, it seems I would have to install the required boost version manually or via a PPA. Haven't found Boost-1.60 as a PPA. Thanks for testing out the master branch and the issue report, that is most helpful. I will check out the issue. Locally, I have boost 1.58 (under Ubuntu 16.04) and so has the remote server which is 15.10. I do have a 14.04 VM and will investigate the issue. Cheers Graham |
|
|
|
On the subject of Python, in my wanderings, I came across this bit of Python for converting a compressed pubkey into an uncompressed one: """
Slimcoin key values produced by src/test/key_tests.cpp:
* secret (hex): f092e90100000000c693e90100000000c693e901000000000000000000000000
* : uncompressed
* secret (base58): 7S78qD9aBwpiCNCZsx9BmMKtsLY58p2zWKftnSPJkyV1SQULjGz
* pubkey (hex): 0480d647bf15e05abcad608725c56fd7722a76335ad248fcf4032f7ae7d3ae09be4b13b00a4853bbf4cd00a1b1812cd401da8386405613a4927110e1db4cf21f19
* address (base58): SkM4auwYLe4R59zkXFnVJ3tCzCkZGms9cu
* : compressed
* secret (base58): VPp5ZncqVJyaqAa47tP8WkiPwBE9FUbnpRQfZZ3TP6Jcvtmy6WWR
* pubkey (hex): 0380d647bf15e05abcad608725c56fd7722a76335ad248fcf4032f7ae7d3ae09be
* address (base58): Siy45aBFsMzqtDEik4taLgDucHm5Tf1BdR
"""
def get_uncompressed_pubkey_from_compressed_pubkey():
"""
Uncompressed pubkey from compressed pubkey
"""
def pow_mod(x, y, z):
"Calculate (x ** y) % z efficiently."
number = 1
while y:
if y & 1:
number = number * x % z
y >>= 1
x = x * x % z
return number
compressed_key = "0380d647bf15e05abcad608725c56fd7722a76335ad248fcf4032f7ae7d3ae09be"
p = 0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f
y_parity = int(compressed_key[:2]) - 2
x = int(compressed_key[2:], 16)
a = (pow_mod(x, 3, p) + 7) % p
y = pow_mod(a, (p + 1) // 4, p)
if y % 2 != y_parity:
y = -y % p
uncompressed_key = '04{:x}{:x}'.format(x, y)
print(uncompressed_key)
# 0480d647bf15e05abcad608725c56fd7722a76335ad248fcf4032f7ae7d3ae09be4b13b00a4853bbf4cd00a1b1812cd401da8386405613a4927110e1db4cf21f19
The Slimcoin key values were generated by src/test/key_tests.cpp - it basically generates a new Slimcoin key (the hex secret key) and serializes the priv/pubkey in various familiar output formats. To use it, simply change to the src/test and run BOOST_TEST_LOG_LEVEL=message ./test_slimcoin, then copy the output. Cheers Graham |
|
|
|
Are there any blockchain to download? WTB slimcoin.. price PM thx.  I managed to nuke my copy of the blockchain during development shenanigans. I didn't notice for a while as I had to close down the started-on-bootup Qt client in order to run the version I was developing. Basically, it just wouldn't synch, the log immediately started filling up with orphans and endless consensus disagreements. I totally failed to persuade the client to read a copied-down blk0001.dat, even if renamed as bootstrap.dat. In the end, I simply ssh'd into my remote-host server, ran cd ~/.slimcoin; tar -zcf /tmp/slmblock.tar.gz blk* database, copied that and it worked, even going from the remote server's Ubuntu 14.04 to my laptop's 16.04. Seems to need the index, dunno why. It's a bit inelegant but what the hey. So, if you're on an Ubuntu box, there's a solution, might even work on other distros. I've set up a cron job on the server to make a daily tar gzip dump. https://minkiz.co/noodlings/slm/slm-datadir-blockfiles.tar.gz (655M) I can't do much with Windows native (IIRC, wine-hosted is no good because the db files are still wrongly endian). OS X (again, IIRC) is okay using Linux bzips. I have created a zip file just in case: https://minkiz.co/noodlings/slm/slm-datadir-blockfiles.zipThere is, ofc, linearize, the preferred solution, which I'm working on. The trouble is that it's so slooooow (I mean days) that it's computationally infeasible on my local kit. So I shovelled it up to the server and let it run there but it just silently failed after some time. (I suppose I should check whether PyPy makes any difference). Cheers Graham Edit: corrected archive compression & file extension |
|
|
|
I cant build "master" [...] a lot of "no known conversion"
Used make -f makefile.unix
You’re a leetle ahead of the game, I hadn't actually gotten round yet to updating the makefiles for the headless client. Two object files were missing from the list and the -std=gnu++11 CXXFLAG wasn’t set. The latest commit should allow a successful compilation of the slimcoind headless client and the test_slimcoin binary (it does for me on 16.04 at any rate). As soon as I’ve figured out how to generate compressed & uncompressed pubkeys, I can make the correct value bindings in the test suite and then I can move on to sorting out the Travis CI config. Cheers Graham |
|
|
|
The mist begins to dissipate ... More specifically, a public key in Bitcoin is a pair integers (x,y). For uncompressed public keys, these integers are encoded as 256-bit unsigned big-endian ints, concatenated together, and then prepended with a single 0x04 byte. The result is 65 bytes long.
For compressed public keys, only the x coordinate is encoded (like above, as 256-bit unsigned big-endian int). It turns out that the y coordinate can only be one of two values, one even and one odd. Instead of prepending a single 0x04 byte, a single 0x02 or 0x03 byte is prepended depending on y's value (0x02 for even, 0x03 for odd). The result is 33 bytes long.
Cheers Graham |
|
|
|
any news?
https://github.com/slimcoin-project/Slimcoin/commits/mastergjh@ashpool:~/minkiz/fabshop/SlimCoinWork/slimcoin-master/src$ ./test_slimcoin
Running 61 test cases...
test/key_tests.cpp(120): error in "key_test1": check fCompressed == false failed
test/key_tests.cpp(122): error in "key_test1": check fCompressed == false failed
test/key_tests.cpp(128): error in "key_test1": check secret1 == secret1C failed
test/key_tests.cpp(129): error in "key_test1": check secret2 == secret2C failed
test/key_tests.cpp(137): error in "key_test1": check addr1.Get() == CTxDestination(key1.GetPubKey().GetID()) failed
test/key_tests.cpp(138): error in "key_test1": check addr2.Get() == CTxDestination(key2.GetPubKey().GetID()) failed
test/key_tests.cpp(139): error in "key_test1": check addr1C.Get() == CTxDestination(key1C.GetPubKey().GetID()) failed
test/key_tests.cpp(140): error in "key_test1": check addr2C.Get() == CTxDestination(key2C.GetPubKey().GetID()) failed
test/Checkpoints_tests.cpp(29): error in "sanity": check !Checkpoints::CheckHardened(19080, p121300) failed
test/Checkpoints_tests.cpp(30): error in "sanity": check !Checkpoints::CheckHardened(99999, p15165) failed
*** 10 failures detected in test suite "Slimcoin Test Suite"
peercoin original test bindings: static const string strSecret1 ("7AChr8cfXUxKJCpjekqEQGoRgpN1iFw44egp4jtqzmX8xTdtsiy");
static const string strSecret2 ("79kbfhqh1HV1B8ZxnsbSnu2F9jbm7XryrNBgvSKusoTpeppWmZr");
static const string strSecret1C ("UBcfHrcR3YP9kwBhFeTt9ijuxk3k96uaX7LijWKqFyW27MPrVSuX");
static const string strSecret2C ("U9dS1qFuaFkbmiQVFUK2qacVTZ2RhqDbvtWBCrnUPE5PKkLweTka");
static const CBitcoinAddress addr1 ("PKkaDEczLygWFN1C3ccEGraLshKMMEoBgn");
static const CBitcoinAddress addr2 ("PXYTm8BcoygtXB7VrAn77DeXhXCNSxxwsW");
static const CBitcoinAddress addr1C("PJC1cL5mBMKmQ357ZNMDVAWH5sDVJNX3p8");
static const CBitcoinAddress addr2C("P95CZ3kFgAvjnMdRgqLoApDuQ49ir7VAP7");
Note: strSecret?C values have an extra char. TIL TWIWMBLA (*) “compressed keys” ... https://bitcointalk.org/index.php?topic=1046919.0Cheers Graham (*) TWIWMBLA = “This week I will be mainly learning about ...” ( https://www.youtube.com/watch?v=SWr0E_Qb39A) |
|
|
|
I think your link to Github is about SlimCoin. It is, and it isn't. Sprouts and Slimcoin share a lot inherited code from their common Peercoin ancestor. My interest was piqued by the original post: Currently we are looking for more nodes, someone to fix the warning on the wallet and a response from https://chainz.cryptoid.info/ regarding a new block explorer. I'd seen that unwelcome warning message message before in Slimcoin and knew there was a crude but effective solution in the Slimcoin code, so I hunted it down. After some research, I was able to understand that the “old block chain, contact the dev” error message originated in Peercoin’s centralised “sync checkpoint” feature. The problem is that this feature depends on a central server continuing to automatically produce new “sync checkpoints”, each authenticated with the dev’s privkey (look for “-checkpointkey” in the output from typing “help” on the debug window's command line). Once I'd worked out what it was all about, I could safely disable the feature and the irrelevant warnings. https://github.com/gjhiggins/sprouts/commit/c8fec8e57bf0b36de65ff3b856b7680cffe769f2#diff-c33d3ce1a2a004536aaf1b90f6458900R362And because I believe that if a job's worth doing, it's worth doing well, I made one of my “drive-by” contributions and: - upgraded the code to use Qt5 if available - eliminated a number of compilation warnings - added a checkpoint from a recent block - added a copy of the in-wallet block explorer that I used for Slimcoin - copied the (known to work and edited for Sprouts) Slimcoin build instructions into the README. and posted the result as a Pull Request to the Sprouts community Github repos: https://github.com/SproutsCommunityRep/sprouts/pull/1So, all the changes are laid out in detail in the commits: except for disabling sync checkpointing and adding the explorer, everything else is aimed at addressing compiler warnings. HTH Cheers Graham |
|
|
|
How about a blockchain that changes the underlying algo constantly, or at random?
Roulettecoin is a close match: - new randomized mining algorithm (Roulette): block is hashed with sha2, then 16 rounds of hashing are performed, each round with randomly chosen algorithm from the set of 16 hashing algorithms: blake bmw cubehash echo fugue groestl hamsi jh keccak luffa sha2 shabal shavite simd skein whirlpool
for(unsigned i = 0; i < 16; i++)
{
unsigned hdec = hash[0] & 0xf;
switch(hdec)
{
case 0:
sph_blake512_init(&ctx_blake);
sph_blake512(&ctx_blake, hash, 64);
sph_blake512_close(&ctx_blake, hash);
break;
case 1:
sph_bmw512_init(&ctx_bmw);
sph_bmw512(&ctx_bmw, hash, 64);
sph_bmw512_close(&ctx_bmw, hash);
break;
[ ... ]
But jonald_fyookball’s observation still holds. AFAIK, the only effective anti-ASIC technique is to ring the changes on memory, given that is a key economic factor in an ASIC solution. Vertcoin's Lyra2 takes that approach, as this chunk from the white paper describes: Under Lyra2, whilst increasing the time cost only involves more iteration, increasing the memory requirement means that any potential ASIC device would have to physically be designed with more memory for each thread. In the future, if ASICs ever were developed for Lyra2RE, we would simply have to fork to a higher memory requirement and those ASICs would no longer properly function.
Then there's Slimcoin's Dcrypt algo ( whitepaper PDF): The Dcrypt algorithm is an algorithm that uses SHA256 internally. What makes this algorithm FPGA/ASIC resistant is they way it was designed.
It is unknown beforehand how many internal SHA256 hashes will be calculated
It is unknown beforehand how much system memory will be required
Large amounts of memory IO is required
Each next step of the Dcrypt algorithm requires the result of the previous step, making parallelization difficult/impossible
The final step of Dctypt is to SHA256 hash a large generated piece of data of variable size
- original bitcointalk ANN thread: https://bitcointalk.org/index.php?topic=613213.0- latest bitcointalk discussion thread: https://bitcointalk.org/index.php?topic=1141676.0Other ASIC “delaying tactics” exploit the variety of permutations available by changing the parameters of scrypt, Cheers Graham |
|
|
|
Ubuntu 14.04 and 16.10. Same error
Master i compile without problem including qt
Okay, thanks. I'll run it up on a VM. Cheers Graham |
|
|
|
... broadly, everything up to the top of that page is relevant to Slimcoin and I spent yesterday evening working my way through the sequence, fixing conflicts from cherrypicking the commits
This approach seems to have paid off. I've been able to replace the half-assed partial bridge code that I smuggled in with (more trustworthy) commits that I cherry-picked from the PPC development stream --- to the extent I have been able to successfully merge the latest PPcoin master branch. The “stealth transactions” addition has been put on hold, it won't compile when merged with the new Slimcoin code because of an organisational infelicity: In file included from src/script.h:11:0,
from src/main.h:12,
from src/bitcoinrpc.cpp:8:
src/base58.h:334:60: error: expected template-name before ‘<’ token
class CBitcoinAddressVisitor : public boost::static_visitor<bool>
^
src/base58.h:334:60: error: expected ‘{’ before ‘<’ token
src/base58.h:334:60: error: expected unqualified-id before ‘<’ token
In file included from /usr/include/boost/asio/handler_type.hpp:20:0,
from /usr/include/boost/asio/async_result.hpp:19,
from /usr/include/boost/asio.hpp:20,
from src/bitcoinrpc.cpp:24:
/usr/include/boost/asio/detail/push_options.hpp:71:40: error: expected declaration before end of line
Makefile:7525: recipe for target 'build/bitcoinrpc.o' failed
The source code is both syntactically and semantically correct, the compilation error points to a problem with the organisation of the codebase. So I decided “first things, first”: I've merged all the existing prerelease code into the master branch and have now turned my attention to the ensuring that the test suite fixtures are adjusted to use Slimcoin addresses, etc. and that the tests pass. Ultimately, I'll update the Travis CI configuration file and then we should be able to return to the reassuring position where Travis CI triggers on each new Slimcoin GH commit: automatically cloning the repos, compiling the code and running the test suite. When that's complete (and both Windows/MacOX binaries generated) I will cut a release, assuming we don't hit any snags on the way. Cheers Graham |
|
|
|
|
Show Posts
