In general on bitcointalk, every thread devoted to a specific altcoin (aka “ANN”, an abbreviation of “Announcement”) carries at least some details of the coin and pertinent matters of interest to an assumed would-be new member of the coin's user community. In this instance ... https://bitcointalk.org/index.php?topic=1141676.0 and ...


Were you a human, you would/should be aware of that. However, of late a substantial number of account-farming bots have been making ill-written posts masquerading as posts from humans with ESL (English as a Second Language, i.e. non-native speakers).

I regret to inform you that your post has failed the Turing test and so has received a stock textual answer.

Cheers

Graham

That's a good find - better than most on blockchain tech but, as is characteristic of altcoin “white papers”, its loose writing and appeals to bogus “common knowledge” tends to undermine my confidence in the entire effort. e.g. this completely unnecessary and laughably false inference ... “PoS has a potential flaw that has been described as the ’nothing at stake’ problem, it is commonly misunderstood and therefore many think it is a myth.” It makes for uncomfortable reading in what purports to be a serious discourse on cryptocurrency.

Otherwise, it's an interesting approach, attempting to harmonise the otherwise competing interests of those who mine and those who stake in a way that also enhances network security and robustness.

Unfortunately, the intersection of Witness/PoW/PoB will significantly complicate any implementation and, as Slimcoin is a bespoke variant reference client for the Bitcoin protocol, will require a correspondingly significant amount of not just professional competence in C++ but also professional-grade software engineering skills.

Cheers

Graham

An XPS doing duty not so much as a laptop or a desktop but as an occasionaltabletop, well-suited to a semi-retired dilettante such as myself, plus the dubious benefits of a stable IP address, NAT and UPNP ... I guess.

Cheers

Graham

My client is reporting 90 connections, fwiw.

Cheers

Graham

Well, yeah it won't change by itself, a real bummer I know but ...



You're missing a trailing slash there ... there's no slash separator between the directory path and the executable file in /mnt/mxe/usr/i686-w64-mingw32.static/qt5/binlrelease.exe, the RCC errors are a direct consequence.


Then BDB_INCLUDE_PATH either was bound incorrectly or not at all (see references to BDB_* in bitcoin-qt.pro)

Cheers

Graham

Yes, it was just coincidence, I'd had a look at timemachine, a Linux backup app and had apparently inadvertently enabled it, along with its default config to back up on the HD. I've reinstalled ipfs.

w.r.t. my committed boost 1.66 compat fix: https://github.com/slimcoin-project/Slimcoin/commit/bb6c7a3ce5fb4e0b714fee72ce87b0ebd74aa136, it'll be worth keeping an eye on the solution for this Verge issue raised on the same problem: https://github.com/vergecurrency/VERGE/issues/418

I doubt whether anyone runs that code anyway, it implements SSL for RPC calls and was removed entirely in 0.12 Core along with the dependency on openssl.

Cheers

Graham

I should've bided my time ... I'd followed the destructions to get ipfs running on my XPS, left it idle and have returned a few hours later to find my HD at 100% usage, apps and altcoin clients falling over everywhere, the logging system hysterically shrieking at the console and /var/lib/docker sat at 461Gb.

It may just be coincidence and not down to ipfs, depends if docker is implicated - I don't believe I'm running any docker apps and I certainly haven't created any myself, so why it used nearly half a terabyte is beyond me atm.

Caution is advised, as ever. I'll report back once I've scrubbed things clean.

Cheers

Graham

Further to using OP_RETURN data to carry immutable resolvable references to externally hosted content, I'm also exploring options available via IPFS ...

https://neocities.org/

https://blog.neocities.org/blog/2017/08/07/ipfs-dns-support.html

https://ipfs.io/docs/install/

Cheers

Graham

If anyone's interested in making a non-technical contribution to the group ...

A pointer to the bitcoin wiki entry for Proof-of-Burn was posted to HN recently (without comment) and I noticed that the link to the Slimcoin white paper that appears in the bitcoin wiki entry needs editing because currently it unfortunately references the now-unresolving address: http://www.slimcoin.club/whitepaper.pdf.

I'd do it myself but that would be hogging all the fun.

Cheers

Graham

Just guessing here because I can't reproduce the problem but perhaps default security has been tightened up, maybe sudo -E might help:

https://www.sudo.ws/man/1.8.21/sudo.man.html

Cheers

Graham

Glad it works. I occasionally forget to stop the client which is a sure fire recipe for getting an incoherent datadir and a terminally confused 2nd client.

Cheers

Graham

Stop your currently-running client. Archive the entire CLAMS datadir. Restart the client. Copy the archived complete datadir to the 2nd m/c, unarchive so that the datadir is where you want it, delete wallet.dat (2nd client will automatically create a new empty wallet.dat) then start your 2nd client. It should sync up straight away.

Cheers

Graham

Not orig dev, was included in subsequent development: https://github.com/kryptoslab/slimcoin/commit/d9fad6ec8acef772f1d68c75159a0c74a3279814

Cheers

Graham

The code in bitcoinrpc.cpp uses some boost asio/ssl calls that were deprecated in boost 1.48 and which are going to kick in as compilation errors sooner or later unless the version is pinned or code added to enable a version compability switch.

Although there aren't any specific examples for me to use as a model, the boost documentation is clear enough to work with in terms of making explicit the new “idiom” and the code comment links to the relevant boost version documentation pages ...

https://github.com/slimcoin-project/Slimcoin/commit/bb6c7a3ce5fb4e0b714fee72ce87b0ebd74aa136

Cheers

Graham

FFS, RTFM

https://duckduckgo.com/?q=undefined+reference+to+%60leveldb

Neither do I, what you've written is opaque. Could you re-transmit?

As expressed, that doesn't make sense to me. What would be the point of that particular piece of pantomime? Yobit can do this for themselves when they compile the client. Do you have a pointer to where these requirements are detailed? I appreciate the motivation behind the pasted list but without any kind of provenance, I don't see what relevance it can have in a cryptocurrency context - particularly when the Slimcoin client offers a getpeerinfo RPC command which provides the required information.

In case this basic point has slipped anyone's attention, absolutely anyone is free to edit the source code

... to include either an updated/expanded strDNSSeed binding or an expanded pnseed binding, or both

... and either just simply run it for themselves or public-spiritedly submit a PR to the slimcoin-project repos - or indeed set up their own repository to offer an alternative reference client.

All that would remain to be done is for someone to invent and implement a mechanism which will then impose this change on all Slimcoin users, including the half-dozen or so apparently very satisfied users of Slimcoin 0.3 who see no reason to change anything, thank you very much

Which is why it is an obvious piece of pantomime, all show and no substance.

While we're on the subject, Slimcoin was launched with just one strDNSSeed binding (dnsseed.slimcoinpool.com), augmented later with dnsseed.furiousnomad.com and dnsseed.shitcoinrapist.club¹, none of which were resolvable by Nov '16 so I removed them entirely.

I replaced them with a(n also unresolving) Namecoin placeholder: seed.slimcoin.bit, ready for when someone volunteers to commit to funding a stable DNSSeed seed node/domain address or set up and maintain a reliable Slimcoin dnsseeder.

Cheers

Graham

¹ A sad testament to the immaturity of the developer's judgement - if you're anything like me, you'll find yourself asking “Jeez, if he's screwed up such a no-brainer, what else has he screwed up that I haven't yet spotted?”

You mean actual Alice-to-Bob txs or stake rewards - if the latter are these not merely orphans?

Cheers

Graham

(Pls forgive the brevity, busy atm)

You'll lose some stake weight in the initial rounding up of the “micro-stake rewards” but that's to be expected. Doing this housekeeping on a regular basis in the future will better preserve stake weights.

Cheers

Graham

AIUI, the optimization of the protocol structure (from block templates to header templates) that was introduced in Bitcoin Core 0.10 resulted in the disappearance from the protocol of some information that was key to the stake calculations performed by PoS coins. So, until someone publishes a general solution, the upgrade path for nearly all Bitcoin protocol PoS alts is capped at Core 0.9.

To my current knowledge, there are only three exceptions: PIVX, Navcoin and Spectre. I don't know much about Spectre, I only found out about it while assembling this response. I can't argue with Max Guevara's opinion of PIVX, so that's not a solution - and anyway it's a Dash clone so that pins it to a variant of Core 0.11. Navcoin is a clone of 0.13 with some elements of 0.14 back-ported.

I've been investigating the possibility of removing the proprietary anon stuff from Navcoin and cross-referencing it back against Bitcoin Core 0.13 to create it as a vanilla PoS 0.13 to use as a new base for Beecoin. It's basically complete afaict (all the expected tests pass), I just need to work out how to kickstart a PoS coin.

I wouldn't bother mentioning it except for the fact that the Navcoin clone retained the original proof-of-work code and so a plain PoS version with the PoW re-enabled might be a potential candidate for a future Bitcoin Core implementation of Slimcoin.

Such an implementation would require a re-write of the Slimcoin PoW, PoS, PoB code and the emission control routines to use contemporary Bitcoin Core objects and methods, i.e. pretty much the creation of a new coin --- so it might as well be launched as one (from the perspective of whoever's grafting away on the code) - because it's going to involve a lot of technically demanding work.

Cheers

Graham

I will be interested in seeing how this plays out ...

https://www.ssb.texas.gov/sites/default/files/BitConnect_ENF-18-CDO-1754.pdf

(Texas Securities Board issues Emergency Cease and Desist against BitConnect using some very interesting accusations.)

Cheers

Graham