I'm compelled to nitpick, sorry.

It's a UX/UI issue. It's possible to lose access to a wallet by failing to back it up before switching to a later non-backwards-compatible client which, if for some reason proves undesirable to the user, causes them to switch back to the old client. That's when they discover that the new client automatically upgraded their wallet to the new db format which cannot now be read by the old client. That's why the advice (for distributed binaries, i.e. OS X/Windows) is to link against 4.8.

It may be an edge case and it may be perceived as a userland issue but I categorise it as a development UX/UI issue because of the underlying loose assumption of technical competence on the part of the user without an accompanying specification of the minimum level of technical understanding required to perform basic wallet/chain maintenance operations. (A principle lucidly expressed by my father as: "If a man doesn't understand, it's because he hasn't been told properly.").

Cheers

Graham

Your question  was overly casual and didn't really contain enough information to motivate me to find out why you were asking (I've learned to be thrifty with my time). If you had made some/any effort to describe your problem, that might have helped.

You will need to download 4.8, compile it separately and adjust the build process to use the 4.8 headers and libs.

Cheers

Graham

It will if you simply restart the client. Feel free to contribute a fix.

For clarity, I'm an occasional technical contributor and I also help with curating the community resources, so your sage advice on pursuing success is misdirected, as is your lack of appreciation of the amount of community effort required to maintain a working blockchain.

Cheers

Graham

Which OS?

Cheers

Graham
 

Yes, that can happen if the clients are compiled with a version of BerkeleyDB other than 4.8.

Scenario: User has client compiled with 4.8, creates wallet that is 4.8-format. User upgrades to a client compiled with (say) 6.2 which automatically updates the wallet (on loading it) to 6.2-format. User decides to return to previous client but that can only read a 4.8 wallet, not the upgraded 6.2 one saved by the new client. This is why users are urged to make regular and frequent backups of their wallet, especially when upgrading the client. A backed-up 4.8-format wallet can be read by any client and generally, any later version can read a previous-version wallet.

Decision: slow but compatible 4.8 or fast but incompatible 6.2?

Linux users can decide for themselves but users of proprietary OSes (Win/OSX) have to depend on whether I can be arsed to provide compiled binaries for both compatible and incompatible bdb versions.   

Cheers

Graham

Initially, the query came from Novaexchange during their pause in trading after they were bought out. Apparently the 0.5 wallet failed to create appropriate change addresses and listunspent was "wrong" and so the exchange's accounting didn't add up and under new strict accounting rules, that was a delisting issue. I tried to divine the precise nature of the problem from the informal description I was given but couldn't make any headway. I suggested they try the -avatar option but apparently that didn't work either.

At that time there was no difference between the PPCoin and Slimcoin transaction-handling code apart from P4Titan's additions for handling burn txs so I was unable to provide a fix. muf18 asked around various devs for help but no-one was interested. In a fit of desperation I copied over the coincontrol backport from PPCoin but I was informed by my exchange contact that they had been able to solve the problem by using a different approach.

All went quiet until mid-April when (unbeknownst to me) one of the Novaexchange staff DM'd me on Discord to report "problems with the wallet" and a fragment from the log that showed the exchange were using a checkout of the unstable "optimized-pos" master, followed a couple of weeks later by a "?". (I've learned to be really, really resistant to the development of casual assumptions of on-demand provision of technical support for exactly this reason. The exchanges are in permanent technical debt which they casually offload on to the same communities that they profit from. Nice trick if you can pull it off.)

When I picked up the laptop again in early May, I saw the DM and responded, advising the exchange to use a checkout of the updated master.

The next message was from the exchange staffer I'd worked with originally and who'd informed me that they'd solved the issue by a different means - apparently the accounting was incorrect due to an issue with change addresses but this time his description gave me a better understanding of the origin of the problem and I was able to commit a putative fix which my contact said he'd try out. That was over a week ago. I sent a follow-up "did it work?" a couple of days ago but haven't had a response yet.

Freiexchange don't experience the same accounting issues with their back end but I'm sure they'd be happy to pick up on a version where the change addresses actually work as intended.

Cheers

Graham

You seem not to understand the role of burnt coins in Slimcoin. I recommend that you read the ANN a bit more closely before making offensively rude postings.

Cheers

Graham

Ah, well. I guess we should just not bother with 0.6 then. At least I tried.

Cheers

Graham

UPNP re-enabled client binaries compiled from current master:

 - Win 32bit
https:minkiz.co/noodlings/slm/slimcoinqt-5.0-win32.zip

 - OS X High Sierra
https:minkiz.co/noodlings/slm/SLIMCoin-Qt.dmg

Cheers

Graham

It's a community rather than a project so it's more useful to talk about strategy rather than specific marketing plans. d5000 has done a good job of keeping the ANN up to date.

The original basic raison d'être of a tripartite PoW-PoS-PoB minting system seems to have some practical merit as Slimcoin has turned out to be a survivor coin, having just passed its 5th anniversary. d5000 and I are separately exploring not-entirely-unrelated avenues of inquiry aimed at leveraging the Slimcoin blockchain to support content publishing.

Cheers

Graham

Thanks for responding positively but I must confess that you have me at a slight disadvantage.

You shouldn't need to. Under the standard modus operandi, Slimcoin is assumed to be running in a local network and uses UPNP in the background to negotiate port mappings with your router. At least that's how it works on the bog-standard consumer router supplied by our ISP.

Well, at least that's how it works now that I've re-enabled UPNP in the Slimcoin code. However, that's still in master and I haven't yet updated the Win/OSX binaries mostly because I'm waiting for a response from Novaexchange as to whether the last update to the code fixed their change address problem. If I have correctly understood their description of the problem, I'm reasonably confident that it was successful.

Given this positive response to making the network more robust, I will get straight onto compiling up fresh binaries for Win/OSX and will post their availability here (in about an hour or so, I expect). Until then, you may care to experiment with making an explicit port mapping.

Cheers

Graham

More than enough (see below). Just add listen=1 to your slimcoin.conf file.

Strictly speaking, a static IP address isn't required, it's just more effective ...

When you run the client as a listening node and open the debug window, you'll see that "Number of connections" is more than 3. I just restarted my local node here (88.98.87.243) and it's reporting 13 connections - 3 are "inbound: false", that means they are listening nodes and my node connected to them so the connection is not inbound to me and so it reads "false" and the rest are (atm) "inbound: true" which means they are not listening to incoming connections but instead they are making incoming connections to my node to pick up tx/block broadcasts, hence "inbound" reads "true".

Slimcoin has a 90-sec block generation time and the chain is running a little fast atm (according to the chainz explorer "overview" tab) so in the initial stages at least, check your outgoing bandwidth from time to time in case the traffic starts approaching your upload limits - which it shouldn't be but YMMV.

Apologies for the slight delay in responding, I had to check my facts first.

Cheers

Graham

Useful pointers, thank you. It's a pity that the articles are such a mixed bag but that's typical of altcoinland.

Cheers

Graham

Unfortunately ... "This code is now unmaintained. The replacement code for electrum server is ElectrumX: https://github.com/kyuupichan/electrumx"

Could I ask you to spell out the advantages of introducing non-contributory SPV wallets when the network is so precariously positioned at the moment?

There are now just three (3) Slimcoin nodes that are broadcasting transactions (i.e. configured with listen=1) and they are currently saving the network from grinding to a complete halt. Two of these nodes are hosted in Germany on Hetzner boxes (one of those is mine) and there's one hosted by OVH in either France or (more likely) Spain. That's it.

If the three people currently funding these hosted nodes (with their own fiat) decide to terminate their support then (AIUI) the chain will  seize up and stop - because no listening nodes means that no further txs can be confirmed.

Given that the community can muster only three listening nodes out of 25-30, I doubt whether you'll see much enthusiasm for anything that requires hosting.

Cheers

Graham

I'm aware of a coin at Yobit whose wallet has been in maintenance for a few years now - and still is.

Cheers

Graham

Well, I have fixed the issue where coincontrol was failing to respect an explicitly-set change addy and have suggested to the exchange representative that they check whether the fix also cures the problematic listunspent issue.

Cheers

Graham

Yes. Apparently the Slimcoin code does not behave as expected in that it does not properly handle the inclusion of change txs in either getbalance or listunspent, the accuracy of which is crucial to the exchange's accounting requirements for AML/KYC complicance. This isn't the first time we've had a run past this problem and I was privately advised on an earlier pass-through that this is a delisting issue for the exchange.

Unfortunately, even if I did have a clue where to start looking for the source of the problem, right now is not a good time. Ngaio and I have a couple of months to move out of the property we've been renting for the last 18 years and find somewhere else to live (sadly, our landlady was widowed earlier this year and this is all probate fallout). So my attention will be very much elsewhere for the next calendar quarter at least.

The gory details are on the discord server. I've advised the person representing the exchange of my position/unavailability and recommended that they approach the group.

(There are times when I wonder whether any of the active addresses in the SLM "rich list" are actually controlled by human actors or whether they're now all just algorithmically-driven, given the apparent degree of  disconnection with the reality of the Slimcoin blockchain.)

Cheers

Graham

Yes indeed, if the qualification is met.

Full details are listed in the (maintained) ANN post: https://bitcointalk.org/index.php?topic=623147.msg6906295#msg6906295

Cheers

Graham

Yes, surely. In order to provide our CLAM representatives with the full info we'd need to know how many liquidity tokens are required and how much the listing fee actually is.

The language of that listing form is quite surreal in places, btw. Very off-putting.

Cheers

Graham

That too is my experience, also with several K of effective burnt coins. It seems to go in cycles as far as I can make out. As I mentioned, the code is canonical (albeit probabilistic, AIUI).
There's possibly some further enlightenment to be had from the Technical Discussions doc that I added (basically just a collation of early bitcointalk posts but it is focused on minting/mining).

BTW, I have reworked ACME so that it now gets its data from SPARQL queries of the blockgraph and not from RPC commands sent to the client. It's is mostly working, just a few wrinkles to iron out. It's testnet-only atm, handling a few K blocks is way more tractable than 1.7million:

http://tessier.bel-epa.com:5064/test/

Work on browsing the blockgraph is continuing, as is the calculation of network hash stats, the ordered list of balances and the address/tx history.

Cheers,

Graham