Topic: Slimcoin | First Proof of Burn currency | Decentralized Web - page 10. (Read 136744 times)

Reasonable at first glance but I'd prefer to find out first how an 0.16.3 Slimcoin reference client performs with a lavishly-funded wallet before adding more potential for bugs. There's also the possibility of riffing off've (or ripping off) John Doering's dual-thread staking solution for Orbitcoin https://github.com/ghostlander/Orbitcoin/commit/a846b5d8b55bc09cc0fb20f86cc1ef4426b450f9 - a rather well-executed  Peercoin clone that still has a respectable profile on freiexchange (https://freiexchange.com/market/ORB/BTC).

Cheers,

Graham

I'll emphasise this point until its significance is acknowledged and the issue addressed ...

Cheers

Graham

I think people hodl without informing themselves about what's going on. They are also not participating in anything that has to do with SLM hoping someone else will solve for them or something will miraculously happen and the price of SLM will go up. And in any case it's free internet money for them till there is someone ready to buy on the market.

We don't have to incomodate them with anything new. If they are comfortable with the things as they are they can carry on like that for as long as it will last, anybody of us can also have a look into the things and adjust if there is something to adjust. Maybe someone of those people will like to work on developing SLM as well.

But in the same moment we'll have another coin, (like people that have BTC and BCH in the same time) that carries on the original idea of PoB and develops it into direction that can help it recover the community and the market price.

I'm thinking about it because we are near to PoD launch, which is the idea I was working on for the last years and I wouldn't like to see it failing or maybe being much more successfully implemented by another community only because we are approaching the technical limits of SLM, as it was thought in the beginning, and nobody (or very few of us) really cares about its fate.


Blackcoin by himself is not the point for me, the point is if we can implement something or even launch a new coin that would solve the issues and let us advertising SLM as it should be advertised, without fear to have hoards of people complaining about the code, we should consider that option, at least from my point of view.

No, for a PoB coin it would make no sense at all as Blackcoin derivatives are pure PoS. Only Peercoin derivatives are hybrid PoW/PoS and they necessarily inherit Peercoin's PoSv1 staking kernel. You can dismiss all thoughts of a PoB/PoSv2 chain.

(I didn't realise that by mentioning blackcoin, I'd be creating quite so much confusion, sorry)

Cheers

Graham

Given the number of Slimcoin addresses in the top 100 that have been active in the last couple of years (https://chainz.cryptoid.info/slm/#!rich), it would appear that the majority of Slimcoin owners are fairly comfortable with the approach of occasionally firing up the wallet in order to collect their accrued stake. I have contemplated your suggested approach but, given the apparent fact that the majority of the community seem to be uncomplaining hodlers, I find it difficult to see any significant demand for a new Slimcoin chain, which makes the personal ROI very doubtful.

Cheers

Graham

I've solved this a bit buying more RAM for my computer. The launch time of my wallet is about 1 h 20 minutes with almost fully synchronized blockchain's snapshot when I launch it for the first time, the next times it becomes much quicker, with additional RAM.

I think switching to this model would make more sense. Maybe we can create SLM+ based on blackcoin?
To launch a new coin we don't need to ask the Community if someone wants to switch he'll be able to using swap.

Yes, that's my experience too. Immediately after startup and at arbitrary times the GUI is so sluggish that it appears to freeze (even with iguanadon1's PoS optimisation). I haven't found it to be unreliable, just very, very slow for a while after initial startup but if I let it run for a while, the response improves after it's finished its initial staking frenzy. The latter is an unfortunate but obvious side-effect of running a PoS v1 coin where staking isn't tied to the time online but to having UTXOs. The Slimcoin community (as with the Peercoin community) has shown no interest in moving to a PoS v2 staking kernel (a la blackcoin) where the node has to be permanently online in order to accrue opportunities to stake.

Cheers

Graham

I'm not a developer, so I'm afraid I can't make meaningful suggestions here, but generally speaking I was thinking whether it can make sense to launch a new coin, let's call it Slimcoin-Plus, with the same idea of PoB and with a swap premine for all the willing Slimcoin owners in which we'd change all the parameters that you mentioned in order to make it more "slim".

i started it because wallet began to freeze very often for a long time and I decided to reduce the size of wallet.dat (4 mb now)
with Linux, I started experimenting because subjectively it seems to me that synchronization there is much faster

Just to throw in an idea: Could it be possible to require UTXOs to be "whitelisted" for them to be enabled to stake?

This would change the standard mode of "stake with all UTXOs you find in the wallet" to "only stake with UTXOs that are specifically enabled to participate in the minting process". So if new staking/mining/burn rewards come in, they would not be used for staking, giving the owner time to consolidate the wallet.

If this was possible, and along with iguanadon's optimizations (which obviously are another "item" that would have to be ported to the new wallet), this could result in less computational load.

Not mitigate, no. My skillset doesn't extend that far. Apart from adding a few GUI/RPC-API enhancements, the majority of the changes I made were basically to bring the Slimcoin codebase up to date with Peercoin development - as far as I could. That activity came to an end when Peercoin hard-forked its protocol and I couldn't see any support for that in the Slimcoin community. iguanadon1's PoS optimisation does mitigate the computational effort via caching of the computational results, thus reducing the load and enabling the client to be responsive to user commands.

If you've any concrete suggestions to make on how this might be achieved, this'd be a good place to air them.

Cheers

Graham

If I understand correctly you were trying all these years to mitigate the consequences of the decisions of the other people, that have left this project years ago.

Maybe it may make sense to change the architecture that is creating all this resources usage, since we are presumably in the middle of the upgrade to the latest Peercoin's code?

I'm not at all clear what you're trying to do here. Reverting to earlier, unsupported versions of the Slimcoin codebase isn't going to clarify matters, rather the reverse.

It's a very old codebase which is being severely taxed by the consequences of choosing a 90s block time, calculating a UTXO set is requiring more and more computation as the blockchain continues to grow.

The instructions are for 0.6.0 (https://github.com/slimcoin-project/Slimcoin/releases/tag/SLMv0.6.0). Any later version of bdb will load a wallet.dat file created with an earlier version but an earlier version of bdb cannot load a wallet created with a later version of bdb. The cross-compiled WIndows binaries used to use the recommended bdb-4.8 but as this just creates yet another factor potentially slowing the wallet's processing, I subsequently enabled the use of whichever version of bdb is provided by MXE. I'm not sure why older Windows versions of the wallet are being referenced, it's not as though they're any more reliable or faster or anything other than potentially problematic.

Only the latest release of Slimcoin is supported --- the current practical meaning of this is: "successfully compiles on Graham's laptop running Mint Ulyana (Ubuntu 0.20), on a VirtualBox VM of Ubuntu 18.04 and cross-compiles to Windows64/32 bit on VirtualBox VM of Ubuntu 18.04 using MXE". Unfortunately, I can no longer successfully cross-compile OS X binaries, so Mac users will have to make do with older (but nevertheless adequately functional) versions of the wallet.

If you're trying to compile code from older releases (which I don't recommend) then you're unlikely to be successful unless you're using a Linux version contemporary with that release.

You haven't lost any burned coins, it's just that the GUI wallet overview page is erratic in its display of the totals, sometimes showing wildly incorrect values. Again, the likely root cause of this is the  consequence of a slow, elderly codebase (lacking the efficiency gains from the generic optimisations of later improvements to the Bitcoin codebase architecture/implementation), exacerbated by the high processing demand imposed by continuously calculating UTXO sets for a blockchain of 2.2 million blocks and an even larger number of transactions. However, if your experience is anything like mine, you'll find that if you just leave it to crunch its numbers, it'll eventually show you the correct totals - once it's synced, leave it overnight and check in the morning.

It's worth reflecting on the fact that Slimcoin is a clone of Peercoin and the Peercoin blockchain is currently just over 500k blocks.

There is an unfortunate consequence of the design of the Slimcoin burn approach - coins are burned in a transaction and any unspent burn rewards will qualify as staking coins and if allowed to stake, those stake rewards themselves will qualify as staking coins, which if allowed to stake ... and so on, and so on. Setting a reservebalance merely limits the amount of stake processing, it doesn't stop it entirely. The computational demand of stake processing (effectively, continuously calculating the UTXO set) isn't such a significant factor with Peercoin with its shorter blockchain but with Slimcoin the (not entirely unpredictable) computational consequences of a 90s block time on the PoS staking calculations are starting to kick in quite sharply for those with well-funded wallets. It's not even clear whether an update to a later clone of Bitcoin would provide any actual solution - Bitcoin, being pure PoW, has no specific UTXO calculation optimisations that the PoS staking calculations could benefit from.

Cheers

Graham

Have you checked that with the same command your new wallet returns the same results? (sorry I'm asking it's just to be 100% sure I've understood it right)

this command returned 3 addresses
i dumped it and imported again in fresh wallet
result is above
 

Hm, is it possible that some of your private keys wasn't dumped?

no, i dumped they all
but after importing i have lesser balance, etc (see above)
in the same OS, same blockchain, same version v5-232
new thing is only wallet.dat

Unfortunately that's quite true at the moment. Things need to be improved here.

You don't have to apologize if there is an issue we need to find a solution so thank you for your questions and for not giving up.

You are not able to dump your private keys from version 232, right?

yes, it works with v6 only, compiling v5 still breaks with error
now i started sync from zero then i will try again import my privkeys
if all ok, i will forget for v5

upd

which upnp port slimcoin uses ? "map port using upnp" option has no effect on my router automatically

very problematic coin   

version 5 has subversions
for Graham's instruction here is v5-268
i have v5-232 on windows and seems like my wallet.dat and blockchain are compatible with 232 only
how to compile 232 ?
i wouldn't ask so many questions if I didn't have so many burnt coins that I don't want to lose
which, apparently, are not supported even in different versions of the 5 release, especially in the 6

Are you testing Graham's instructions above?