Thanks for that, appreciated!
BTW, the mac binary seems to get stuck at "Loading addresses...". May be because it's intended to use on a testnet and my wallet is on the mainnet?
Thanks for the problem report, I'll re-check the OS X client's functioning on my Sierra VM. The 0.5.0 client should sync up on either mainnet or testnet (depending on command-line option or config) defaulting to mainnet as per standard. Begging testers to confine their experimentation to the testnet is only really a vague courtesy to the public ledger, a client shouldn't be able to “break” the blockchain, that would demonstrate a vulnerability in the protocol. Technically speaking, the “release” process in this context is primarily a bit of software engineering theatre because it offers no surety of functionality. In fact, if I could successfully bring the blockchain to a halt with a specially-crafted client working outside the majority consensus, that would actually be a win from a white hat perspective. The 0.5 binaries are actual release candidates and have full functionality. ATM I'm in the process of finishing off the conversion from torrentpage to inscriptionpage so that users at least have a scrollable list of their previous inscriptions. I have read up about Github releases, the process seems simple enough. I now just need to read through any FAIL reports to see what I'm missing  Cheers Graham |
|
|
|
If anyone's interested in running their own instance of the Fuseki SPARQL server, I have published a github repository containing a vagrant+ansible deployment script that does the entire job: https://github.com/gjhiggins/va-fusekiCheers Graham |
|
|
|
Hello , srry for bothering all the time , but im very interested in mining this coin , my problem is that when i put the chain block data into the dir it saays the error : "blockchain download required".
It means that i need to download the chain block with the slimcoind program?... how ?
Sorry you're having trouble with the “snapshot” archive. It's not a “proper” linear bootstrap file, just a token “this might work for you” gesture. The usual approach is to clear -datadir of everything other than wallet.dat, unzip the archive and try with that. If it doesn't work, then just delete the files extracted from the archive, start again with just wallet.dat and let the client synch from the network. Cheers Graham |
|
|
|
there are quite a few coins I have wallet.dats for that when i checked were not on that list so i was assuming there were quite a few more that had slipped past you somehow. They however must be recorded on this forum somewhere and would have only been deleted if they did something very wrong. I know some launches that then turned into give away threads were deleted at a later date.
Some literally lasted only hours before they died off...
I used to get emailed with every new ANN in the Altcoin Announcements section and I noticed that as my alacrity eventually faded, I did start miss a few ANNs that had been deleted by the time I got round to trying to view them the following day [1]. It also became clear that the most aggressively fraudulent operators were beginning to shift their announcements to other social media, presumably in an effort to escape the close scrutiny that bitcointalk ANNs often get. That's why I suspect that “complete” can only really be discussed in reference to a generally-endorsed operational definition. I stopped collating altcoin metadata in mid-March 2016, if your alts were launched later than that, then they won't be in the list. Cheers Graham [1] Some ANNs were (are) of easily-detected attempts to defraud --- and some ANNs proved to be of more difficult-to-detect attempts to defraud and, in the same context, the interpretation of some ANNs is still being hotly debated. |
|
|
|
I think these old alts will become very very sought after as time goes on/
The direction of that vector looks vaguely plausible (from a psychologist's standpoint) but I would argue that its magnitude is over-stated. I just can't see “very very sought after” at all. Part of the problem is that key distinguishing characteristics of an instance of expensive-to-serialize classes (e.g. an instance of a Ming porcelain dish) do not transfer to cheap-to-serialise classes such as old files of data conforming to the Bitcoin 0.6.7 byte protocol. especially those mined to the wallets they are still contained in Not possible to ascertain canonically because of [export|import]privkey. Some alts that were released as pow were only mined for a few hours then died. Although there is nothing to stop them being revived I guess.
Am I there and staking out the ground already? (Take a guess). I would love to see a historical site for alts set up because their inception date is on this board still but if this board ever went down the records would be lost.
Tried that, turned out to be not worth the effort. I know graham listed a great historical list once on here but even that was far from complete.
Dunno about “far from” (I put in a *lot* of effort on that score) but the notion of “complete” here is extremely difficult (perhaps even impossible) to define operationally. A spider could be developed to easily spider this board and list in chronological order the exact release date of every single alt ever created and if possible preserve a copy of each original wallet.
Tried that, the results are not pretty. Cheers Graham |
|
|
|
It has an elevated reservebalance level and a blocknotify script specialised to testnet.
“What blocknotify script?” asks a hypothetical discourse device. Well, the client can be configured to execute a specified program whenever the client receives a new block. In my slimcoin_testnet.conf it is configured as a shell script: blocknotify=/opt/slm/scripts/slm-testnet-blocknotify.sh %s
when executed, the %s gets replaced by the actual block hash, bound in the shell environment to $@. The shell script: #!/bin/sh
BLOCKHASH="$@" /usr/bin/python3.5 /opt/slm/scripts/slm-testnet-blocknotify.py > /tmp/blocknotify.log 2>&1
echo "${@}" >> /tmp/blocknotify.log
which, in turn, runs a Python script that picks up the block hash from the environment, performs a series of RPC calls on the client, starting with getblock <BLOCKHASH>, converting the returned JSON statements into RDF statements and working its way through the pointers finally to create an complete RDF graph representation of the block, its transactions, their values and the addresses involved. It records around three dozen facts about each block. (~950000 blocks * 36 triples = 34,200,000 triples, so an RDF graph of mainnet will a) take time to generate and b) have to be maintained in separate chunks. Fortunately SPARQL can run “federated” queries, i.e. treat the separate chunks as one for querying porpoises.) The RDF is then posted to an instance of the Apache Jena Fuseki SPARQL server running on the (same) machine which then offers SPARQL querying of a contemporaneous RDF graph of the blockchain. The following image shows a SPARQL query that lists all distinct OP_RETURN tx messages on the testnet blockchain:  (The SPARQL endpoint shown in the image is active and accessible) That's all she wrote, literally. If we want to provide more information about a particular inscription, such as a description of the nature of the content of the torrent identified by the inscribed torrent hash, then for us it has to be off-chain. Off-chain data storage is often implemented by creating additional data tables in the -datadir. Unfortunately, this approach also adds significantly to the maintenance load and this directly translates into a significant increase in the cost of ownership for the already woefully under-supported user. Let’s be realistic, people aren't exactly queuing up to shoulder the load of curating the content that they create in the course of their netsocializing, they much prefer it to be someone else's problem even at the price of a significant concession of privacy. The real show-stopper is that the locally-stored data isn't broadcast across the peer-to-peer network, it remains locally siloed and thus useful to neither man nor beast. A more plausible approach would be to engineer a reliable external social consensus using an RDF graph representation of the blockchain for provable veracity. The RDF representation is both public and accessible so it's trivial to establish whether or not it's a correct mapping from the acyclic directed blockchain graph to the acyclic directed RDF graph. Given that the RDF graph is a one-to-one symbolic correspondence to the blockchain, referring to :C0000000733567067927d0778bdee1ad3034ecc60e49cfc3ae05dbc3a1eddbb60 will get you the recorded metadata for that block:
:C0000000733567067927d0778bdee1ad3034ecc60e49cfc3ae05dbc3a1eddbb60 a :Block ;
:difficulty 0.06464541 ;
:flags "proof-of-work"^^xsd:string ;
:height 759 ;
:mint 6.19 ;
:previousblockhash :C8fe77bb34c5aec9206a3c73beccaf1fc53e6d4afe297c3782f57c09e4eb9c627 ;
:size 355 ;
:time 1492346152 .The absence of a statement about the nextblock defines this as the last block in the chain at the time recorded. So, given that the query: SELECT ?subject
WHERE {
?subject rdf:type <http://purl.org/net/bel-epa/ccy#TransactionOutput> .
?subject <http://purl.org/net/bel-epa/ccy#inscription> "magnet:?xt=urn:btih:e940a7a57294e4c98f62514b32611e38181b6cae"
}yields a reference to the TxO <http://purl.org/net/bel-epa/ccy#C1887d7380f770c99c0f9d08c38b7f01d71913b2ce791d1771ddfcfddda69f49d-O-2>I can make further statements, using the retrieved TxO reference as an identifier and using expressions drawn from familiar vocabularies (in this instance, for clarity I'm using just the Dublin Core metadata elements): :gjh-00000001 a :Inscription ;
:inscription "magnet:?xt=urn:btih:e940a7a57294e4c98f62514b32611e38181b6cae"^^xsd.string ;
dc:title "Arch Linux 2013.01.04 (www.archlinux.org)"^^xsd.string ;
dc:date 2013-01-04T22:09:20Z ;
dc:identifier http://purl.org/net/bel-epa/ccy#C1887d7380f770c99c0f9d08c38b7f01d71913b2ce791d1771ddfcfddda69f49d-O-2 ;
dc.source: "magnet:?xt=urn:btih:c8cde7428b44142b04d88b91785ecf0f20d16903&dn=archlinux-2013.02.01-x86_64.iso&tr=udp://tracker.archlinux.org:6969&tr=http://tracker.archlinux.org:6969/announce" ;
dc:description "kernel_version 3.6.11"^^xsd.string .I can add that to my local graph, dump it on pastebin or, one day in the dim and distant future, I could even publish it to a group-maintained community-serving RDF graph running on several DO/AWS instances so that other users can choose to add to their whitelisted resources. Cheers Graham |
|
|
|
Successfully compiled and running a Mac OS GUI. Now let's play with the OP_RETURN thingie...
Good to know, thanks. Background reading: Bartoletti and Pompianu's paper (reporting Feb '17 results) “An analysis of Bitcoin OP RETURN metadata. Massimo Bartoletti and Livio Pompianu, Universit`a degli Studi di Cagliari, Cagliari, Italy” (PDF), presented at Financial Cryptography and Data Security April 2017. Latest commit: https://github.com/slimcoin-project/Slimcoin/commit/05ee8c0a879afa3263a1b348a94e8a98e87206db - “Show OP_RETURN message in transaction details”  Note, cost of creating an OP_RETURN tx has doubled (from 0.01 SLM to 0.02 SLM) - it transpires that 0-valued tx are prohibited as a hard-coded element of the consensus mechanismhttps://github.com/slimcoin-project/Slimcoin/blob/slimcoin/src/main.cpp#L587if ((!txout.IsEmpty()) && txout.nValue < MIN_TXOUT_AMOUNT)
return DoS(100, error("CTransaction::CheckTransaction() : txout.nValue below minimum"));
Changing this to allow 0-valued tx would create a ... <dramatically-clashing-chord/> hard fork. Old clients would be peremptorily excluded from any new, 0-valued-tx-tolerant consensus and that would be a bummer. So instead, I adjusted the OP_RETURN tx generation code to add a 0.01 CENT value to the tx, which enables it to be accepted as a valid tx by legacy 0.3/0.4 clients as well as the 0.5 johnny-come-latelys. NOTE: TESTNET ONLY PLEASE I've removed the “enforced testnet mode” from the code, so there's every opportunity to be a good Slimcitizen and use -testnet when experimenting. I create a copy of ~/.slimcoin/slimcoin.conf as ~/.slimcoin/slimcoin_testnet.conf and reference that specifically on the command line: ./slimcoin-qt -testnet -conf=slimcoin_testnet.conf. It has an elevated reservebalance level and a blocknotify script specialised to testnet. Testnet seed node (1 thread devoted to mining just to keep the blockchain ticking over): addnode=144.76.64.49:41684, PM me for testnet coins. Cheers Graham Edit: addeddaddnodde |
|
|
|
Now known to work reliably, chapter and verse on building for Debian Jessie Vagrant VM. Cheers Graham |
|
|
|
yes, googled this too - but no solution suggested.. will try to build on Ubuntu VM and move to Debian You may not need to go down that route. Fortunately, I am unable to replicate the issue. I have a Vagrant VM of Jessie on which Slimcoin master compiles, the GUI executes and all tests pass. I can't give you chapter and verse just yet. I was working on a Vagrant+ansible Jessie deployment but abandoned it, upgrading to the desktop for convenience - that's where I built the Jessie binaries. I'll update the repos: https://github.com/gjhiggins/ansible-slm-jessie with a known-to-work version. Cheers Graham |
|
|
|
Debian 8 x64 - still crashing with: from src/bitcoinrpc.cpp:8:
src/bignum.h:52:24: error: invalid use of incomplete type ?BIGNUM {aka struct bignum_st}?
class CBigNum : public BIGNUM
Known bug with Debian 8 apparently: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855574Cheers Graham |
|
|
|
I don't understand why I was able to compile on Digital Ocean vps but not Vultr and i did the same steps.
Different distributions of Linux uses different versions of boost. Try Ubuntu 14.04. Or try the patch included below for 16.04: diff --git a/configure.ac b/configure.ac
index 7208c72..3ade7e5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -354,6 +354,8 @@ fi
if test x$use_hardening != xno; then
AX_CHECK_COMPILE_FLAG([-Wstack-protector],[HARDENED_CXXFLAGS="$HARDENED_CXXFLAGS -Wstack-protector"])
AX_CHECK_COMPILE_FLAG([-fstack-protector-all],[HARDENED_CXXFLAGS="$HARDENED_CXXFLAGS -fstack-protector-all"])
+ AX_CHECK_COMPILE_FLAG([-fPIE],[HARDENED_CXXFLAGS="$HARDENED_CXXFLAGS -fPIE"])
+ AX_CHECK_COMPILE_FLAG([-fPIC],[HARDENED_CXXFLAGS="$HARDENED_CXXFLAGS -fPIC"])
AX_CHECK_PREPROC_FLAG([-D_FORTIFY_SOURCE=2],[
AX_CHECK_PREPROC_FLAG([-U_FORTIFY_SOURCE],[
@@ -367,6 +369,11 @@ if test x$use_hardening != xno; then
AX_CHECK_LINK_FLAG([[-Wl,-z,relro]], [HARDENED_LDFLAGS="$HARDENED_LDFLAGS -Wl,-z,relro"])
AX_CHECK_LINK_FLAG([[-Wl,-z,now]], [HARDENED_LDFLAGS="$HARDENED_LDFLAGS -Wl,-z,now"])
+ if test x$TARGET_OS != xwindows; then
+ # -pie will link successfully with MinGW, but it's unsupported and leads to undeterministic binaries
+ AX_CHECK_LINK_FLAG([[-pie]], [HARDENED_LDFLAGS="$HARDENED_LDFLAGS -pie"])
+ AX_CHECK_LINK_FLAG([[-pic]], [HARDENED_LDFLAGS="$HARDENED_LDFLAGS -pic"])
+ fi
CXXFLAGS="$CXXFLAGS $HARDENED_CXXFLAGS"
CPPFLAGS="$CPPFLAGS $HARDENED_CPPFLAGS"
diff --git a/src/Makefile.am b/src/Makefile.am
index ab22d1b..7cdf221 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -1,6 +1,6 @@
include Makefile.include
-AM_CPPFLAGS += -I$(builddir)
+AM_CPPFLAGS += -fPIC -I$(builddir)
noinst_LIBRARIES = \
libchaincoin_server.a \
diff --git a/src/chainparams.cpp b/src/chainparams.cpp
index e91dc75..9810694 100644
--- a/src/chainparams.cpp
+++ b/src/chainparams.cpp
@@ -65,13 +65,21 @@ public:
vSeeds.push_back(CDNSSeedData("seed2.chaincoin.org", "seed2.chaincoin.org"));
vSeeds.push_back(CDNSSeedData("seed3.chaincoin.org", "seed3.chaincoin.org"));
vSeeds.push_back(CDNSSeedData("seed4.chaincoin.org", "seed4.chaincoin.org"));
-
+#if BOOST_VERSION >= 158000
+ base58Prefixes[PUBKEY_ADDRESS] = std::vector<unsigned char>(1,28); // Chaincoin addresses start with 'X'
+ base58Prefixes[SCRIPT_ADDRESS] = std::vector<unsigned char>(1,4); // Chaincoin script addresses start with '7'
+ base58Prefixes[SECRET_KEY] = std::vector<unsigned char>(1,28 + 128); // Chaincoin private keys start with '7' or 'X'
+ base58Prefixes[EXT_PUBLIC_KEY] = boost::assign::list_of(0x02)(0xFE)(0x52)(0xF8).convert_to_container<std::vector<unsigned char> >(); // Chaincoin BIP32 pubkeys start with 'drkv'
+ base58Prefixes[EXT_SECRET_KEY] = boost::assign::list_of(0x02)(0xFE)(0x52)(0xCC).convert_to_container<std::vector<unsigned char> >(); // Chaincoin BIP32 prvkeys start with 'drkp'
+ base58Prefixes[EXT_COIN_TYPE] = boost::assign::list_of(0x80000005).convert_to_container<std::vector<unsigned char> >(); // Chaincoin BIP44 coin type is '5'
+#else
base58Prefixes[PUBKEY_ADDRESS] = list_of( 28); // Chaincoin addresses start with 'X'
base58Prefixes[SCRIPT_ADDRESS] = list_of( 4); // Chaincoin script addresses start with '7'
base58Prefixes[SECRET_KEY] = list_of(28 + 128); // Chaincoin private keys start with '7' or 'X'
base58Prefixes[EXT_PUBLIC_KEY] = list_of(0x02)(0xFE)(0x52)(0xF8); // Chaincoin BIP32 pubkeys start with 'drkv'
base58Prefixes[EXT_SECRET_KEY] = list_of(0x02)(0xFE)(0x52)(0xCC); // Chaincoin BIP32 prvkeys start with 'drkp'
base58Prefixes[EXT_COIN_TYPE] = list_of(0x80000005); // Chaincoin BIP44 coin type is '5'
+#endif
// Convert the pnSeeds array into usable address objects.
for (unsigned int i = 0; i < ARRAYLEN(pnSeed); i++)
@@ -132,12 +140,21 @@ public:
vFixedSeeds.clear();
vSeeds.clear();
+#if BOOST_VERSION >= 158000
+ base58Prefixes[PUBKEY_ADDRESS] = std::vector<unsigned char>(1,80); // Testnet chaincoin addresses start with 'x' or 'y'
+ base58Prefixes[SCRIPT_ADDRESS] = std::vector<unsigned char>(1,44); // Testnet chaincoin script addresses start with '8' or '9'
+ base58Prefixes[SECRET_KEY] = std::vector<unsigned char>(1,88 + 128); // Testnet private keys start with '9' or 'c' (Bitcoin defaults)
+ base58Prefixes[EXT_PUBLIC_KEY] = boost::assign::list_of(0x3a)(0x80)(0x61)(0xa0).convert_to_container<std::vector<unsigned char> >(); // Testnet chaincoin BIP32 pubkeys start with 'DRKV'
+ base58Prefixes[EXT_SECRET_KEY] = boost::assign::list_of(0x3a)(0x80)(0x58)(0x37).convert_to_container<std::vector<unsigned char> >(); // Testnet chaincoin BIP32 prvkeys start with 'DRKP'
+ base58Prefixes[EXT_COIN_TYPE] = boost::assign::list_of(0x80)(0x00)(0x00)(0x01).convert_to_container<std::vector<unsigned char> >(); // Testnet chaincoin BIP44 coin type is '5' (All coin's testnet default)
+#else
base58Prefixes[PUBKEY_ADDRESS] = list_of( 80); // Testnet chaincoin addresses start with 'x' or 'y'
base58Prefixes[SCRIPT_ADDRESS] = list_of( 44); // Testnet chaincoin script addresses start with '8' or '9'
base58Prefixes[SECRET_KEY] = list_of(88 + 128); // Testnet private keys start with '9' or 'c' (Bitcoin defaults)
base58Prefixes[EXT_PUBLIC_KEY] = list_of(0x3a)(0x80)(0x61)(0xa0); // Testnet chaincoin BIP32 pubkeys start with 'DRKV'
base58Prefixes[EXT_SECRET_KEY] = list_of(0x3a)(0x80)(0x58)(0x37); // Testnet chaincoin BIP32 prvkeys start with 'DRKP'
base58Prefixes[EXT_COIN_TYPE] = list_of(0x80000001); // Testnet chaincoin BIP44 coin type is '5' (All coin's testnet default)
+#endif
}
virtual Network NetworkID() const { return CChainParams::TESTNET; }
};
|
|
|
|
Still don't see why it is fun. But I do believe you are the one being sardonic now  . No. It's an actual thing. You may wish to take a look at Simon Baron-Cohen's work (at MRC, alongside Uta Frith) https://en.wikipedia.org/wiki/Simon_Baron-Cohen Cheers Graham |
|
|
|
me personally, I would never describe it as fun. That's just me though.
To be fair, it's not just you. Many subscribers to bitcointalk have expressed the same puzzlement. On the whole, it doesn't seem to perturb people unduly; I believe the expression is “different strokes for different folks”. To some extent the gap is understandable, especially if coupled with a defensive and dismissive attitude towards the ( very misleading term) “soft sciences”. To understand the appeal of Dogecoin, you need to be educated and experienced in psychology and marketing. To experience the appeal of Dogecoin you need to be a fun pro-social person. By and large, engineers are not especially pro-socially inclined (it seems to come with the math ability territory). So, nothing to be really concerned about. Cheers Graham |
|
|
|
Something I've always wondered, why do people use the word "fun" when describing this coin? Doge is fun! What is fun about it?
Is that a genuine question or are you being sardonic? Cheers Graham |
|
|
|
after i put the content of slm-datadir-blockfiles.zip in datadir , i cant check wallet or do something , it says: "blockchain download required" , there is a way to fix it?
Blockfiles created by a Linux-hosted client may not work for a Windows-hosted client. At worst, shut down the client, delete everything in datadir (except wallet.dat, ofc) and then re-start the client - it should synch from the network. Other than that, somewhere in the previous posts around Dec/Jan there was a Windows blockchain dump for Slimcoin made available which should cut down the syncing time. I hope you'll forgive me for not providing a precise reference, Real Life(tm) is calling. Cheers Graham |
|
|
|
Hey guys. What would be the best way to store my BELAcoins? I want to keep a significant amount for later to see what the coin does, but they're all on exchanges now. If I download the desktop wallet, but my PC crashes.... than what? Will my coins be lost?
If I'm not mistaken, you should store wallet.dat file not only in one secured place to avoid your problem. You are not mistaken. OP, you may replace “Bitcoin” with “Belacoin” throughout the following: https://en.bitcoin.it/wiki/Securing_your_walletSecuring the Bitcoin-Qt or bitcoind wallet
Bitcoin transactions send Bitcoins to a specific public key. A Bitcoin address is an encoded hash of a public key. In order to use received Bitcoins, you need to have the private key matching the public key you received with. This is sort of like a super long password associated with an account (the account is the public key). Your Bitcoin wallet contains all of the private keys necessary for spending your received transactions. If you delete your wallet without a backup, then you no longer have the authorization information necessary to claim your coins, and the coins associated with those keys are lost forever.
The wallet contains a pool of queued keys. By default there are 100 keys in the key pool. The size of the pool is configurable using the "-keypool" command line argument. When you need an address for whatever reason (send, “new address”, generation, etc.), the key is not actually generated freshly, but taken from this pool. A brand new address is generated to fill the pool back to 100. So when a backup is first created, it has all of your old keys plus 100 unused keys. After sending a transaction, it has 99 unused keys. After a total of 100 new-key actions, you will start using keys that are not in your backup. Since the backup does not have the private keys necessary for authorizing spends of these coins, restoring from the old backup will cause you to lose Bitcoins.
Creating a new address generates a new pair of public and private keys, which are added to your wallet. Each keypair is mostly random numbers, so they cannot be known prior to generation. If you backup your wallet and then create more than 100 new addresses, the keypair associated with the newest addresses will not be in the old wallet because the new keypairs are only known after creating them. Any coins received at these addresses will be lost if you restore from the backup.
The situation is made somewhat more confusing because the receiving addresses shown in the UI are not the only keys in your wallet. Each Bitcoin generation is given a new public key, and, more importantly, each sent transaction also sends some number of Bitcoins back to yourself at a new key. When sending Bitcoins to anyone, you generate a new keypair for yourself and simultaneously send Bitcoins to your new public key and the actual recipient's public key. This is an anonymity feature – it makes tracking Bitcoin transactions much more difficult.
So if you create a backup, and then do more than 100 things that cause a new key to be used, and then restore from the backup, some Bitcoins will be lost. Bitcoin has not deleted any keys (keys are never deleted) – it has created a new key that is not in your old backup and then sent Bitcoins to it. A backup is therefore recommended roughly every 50 transactions (or address creations) just to be safe.
(emphasis, mine) HTH Cheers Graham |
|
|
|
The intended location for the block files in slm-datadir-blockfiles.zip is wherever datadir is configured to be. datadir is the ( individually-configurable) location of the standard set of data files and sub-directories that are automatically created when the app is first run i.e. peers.dat, wallet.dat, debug.log, blk00001.dat, database/, etc. (The command-line option -datadir=<dir> is how a non-default location for the data files is specified: https://en.bitcoin.it/wiki/Running_Bitcoin) By default, datadir is located in the user's home directory (commonly aliased as HOME or ~). The default datadir values are hard-coded - https://github.com/slimcoin-project/Slimcoin/blob/master/src/util.cpp#L861 // Windows: C:\Documents and Settings\username\Application Data\SLIMCoin
// Mac: ~/Library/Application Support/SLIMCoin
// Unix: ~/.slimcoin
The content of the zip archive is reported as: gjh@ashpool:~/.slimcoin$ unzip -l slm-datadir-blockfiles.zip
Archive: slm-datadir-blockfiles.zip
Length Date Time Name
--------- ---------- ----- ----
510494780 2017-03-28 01:17 blk0001.dat
611368960 2017-03-28 01:17 blkindex.dat
0 2017-03-28 01:07 database/
10485759 2017-03-28 01:17 database/log.0000010055
--------- -------
1132349499 4 files
(Yes, sorry, 28th March is correct. I did set up a scheduled task to refresh it daily but it just fails and I haven't yet figured out why). Finally, the answer: Copy slm-datadir-blockfiles.zip to your datadir and unzip the archive in place, i.e. the contents will be written to datadir. (In due course, when I've learned to pronounce correctly the spell of create-slimcoin-readable-bootstrap.dat, I will publish a bootstrap.dat at reasonably frequent intervals but until then, all I can manage is a stammered “ cd ~/.slimcoin; zip -r slm-datadir-blockfiles.zip blk* database” which is rather crude but at least it's known to work on Linux and OS X platforms.) Cheers Graham |
|
|
|
Linux users, please upgrade at your earliest convenience.
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libcrypto.a(dso_dlfcn.o): undefined reference to symbol 'dlclose@@GLIBC_2.2.5'
//lib/x86_64-linux-gnu/libdl.so.2: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Makefile:659: recipe for target 'Sterlingcoin-v1.6' failed
required somewhere in the .pro file (I edited the Makefile, hardly worth submitting a PR, otherwise I would). Cheers Graham |
|
|
|
Did you really just scam me for $10?
Hey, that's nearly a week's wages now here in gig-economy UK Cheers Graham |
|
|
|
|
Show Posts
