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

Thank you very much again!

For the moment the developer has taken into consideration your suggestion about the local testnet, should he need more resources I'll let include your node into our "package" 

144.76.118.44

Cheers

Graham

I like the idea of v 1.0, but as you said following the current numbering is a bit more preferable.

Of course for SLM the upgrade we will possibly release is a great step ahead, but from the point of view of the general cryptoworld development we are just trying to catch the train that was about to leave. So more sober numbering is preferable, it will let understand to the more attentive people that we know where we are right now.

We can reserve 1.0 to the possible improvement of the PoB algorithm, for instance.  

I've got it, thanks.

Local to the VPS, yes - that's entailed in the connect=127.0.0.1: configuration statements.

Cheers

Graham

In my understanding you can do the same thing on a VPS, and from the point of view of that VPS it will be still a local testchain, or?

Hint:

On testnet? Something horribly wrong there. But be that as it may, in general a 1Gb VPS is too under-powered for altcoin development.

Cheers

Graham

Maybe you have a VPS with 4 GB of Ram, or are you speaking about your local computer?
Because slimcoind is using almost all the RAM on my 1GB Ram VPSs.

Same way i am doing with .bat

slimcoin-qt.exe -datadir=Data

Data is folder with wallet and blockchain

AS many time just different rpcport

That's a bit ... unusual. IME, such a network is trivial to set up on single m/c, all that's required is that each node has its own datadir and is configured with a different port number (with port= and rpcport=).

I approach this by having (say) 4 different datadir directories (typically datadir-a, datadir-b and so on) each with its own slimcoin.conf setting the ports  (typically to, 60000/60001, 60002/60003, and so on) cross-connected (with port=60000,connect=128.0.0.1:60002 and port=60002,connect=128.0.0.1:60000 and so on) and run the clients with -datadir=`pwd`/datadir-a,  -datadir=`pwd`/datadir-b, etc. I find this arrangement very handy for experimentation as I can trivially start/stop the clients and clear out the datadirs after each experiment with a couple of simple bash commands.

For anyone who may be interested in running their own local Slimcoin testnet network, create the four datadir-? dirctories and add a slimcoin.conf to each:

basic slimcoin.conf:

added to the basic slimcoin.conf for datadir-a:

added to the basic slimcoin.conf for datadir-b:

added to the basic slimcoin.conf for datadir-c:

added to the basic slimcoin.conf for datadir-d:

Then just start 4 clients, the first with -datadir=`pwd`/datadir-a, the second with -datadir=`pwd`/datadir-b and so on, and you've got yourself a neat little local testnet chain to play with.

Just sayin'

Cheers

Graham

My testnet node was not running in the last days. It is running the "hardcap" version so it would in its current state be not useful for testing the update (I think the hard cap should be implemented later so its testing does not interfere with the PPC 0.10 upgrade, and it would be much more convenient after the upgrade as PPC 0.10 should have a proper soft fork mechanism).

I can activate the "Standard" 0.6 SLM client on the testnet node after September 10/11 (because of a scheduled maintenance of my VPS), or wait until the first alpha of the PPC-0.10-based version is out.

To standardize terminology (I have planned to update this thread to include info about the SLM upgrade, and also change the thread title): Should we call the new version Slimcoin 0.7? (This would be the logical step, as the last one was 0.6) Or would it make sense to directly call it Slimcoin 1.0 to emphasize the code changes? (This would however be a pretty bold move as we would show the world that 1.0 is the first mature, "really stable" version) Both variants have their pros and cons, so I would like to hear the opinion of @everyone (I'm slightly leaning to simply follow our current numbering scheme and call it 0.7).

Ah, and I think to use a later release candidate of PPC 0.10 as a base, like you suggested is a good idea, at least in the case in some weeks we still don't see a release on the horizon. PPC has a paid full time developer, and in the past he released RCs very frequently.

Do we have any testnet node available or running at the moment?
The developer asked me to create at least 4 nodes for the testnet for its work. I have some node available, but before I distract all the 4 from the main net I'm asking, just in case.

Thank you!

One other thing that might be useful, pre-computed EXT/bip32 keys for Slimcoin - as committed to Ian Coleman's BIP39 repos: https://github.com/iancoleman/bip39/blob/863eee8ed754e4aebd5059b712deb4fca8709c27/src/js/bitcoinjs-extensions.js#L153

Cheers

Graham

Yes, pretty much so, they pertain to serial changes to the Peercoin ledger contents, tx validations/limits/fees mainly, so will be irrelevant to the Slimcoin ledger legacy.

Cheers

Graham

Considering we are already using a kind of pre-release version maybe beginning from a more modern pre-release version would make sense.


EDIT: We've just agreed with the developer, that he'll release the RC version based on PPC 0.10 and then he'll go on patching it until PPC releases the stable version. Then we'll have an additional 2 month of assistance included just in case any bug or issue occurs.

Basically, this means these switches can be deleted completely? I've looked a bit into the code but I lack proper understanding what changes in the Peercoin protocol they're referring to. 


Yep, is understandable. I have looked at the Peercoin repo and from the first RC version to the final release there are generally between 1 and 5 months of time (0.5 took 6 months). However, the 0.10 change, as far as I understand it, is much less complicated than the previous 0.8 and 0.9 changes. 0.8 was the "big update" from BTC 0.8 to 0.16 and took 5 months from RC1 to the final release, and 0.9 introduced the protocol changes like the new PoS and took 3 months.

0.10 RC1 is now 17 days old so I guess 2-3 months from now would be the time one would have to expect, but maybe not much more.

My only concern is that the v0.10 is still in pre-release phase, so or we need them to reach the "Stable" status before we go on with upgrade or we can release our rc version and then go on implementing their updates later.

What I don't like about waiting for their stable release is that I need the PoD token to be launched as soon as possible and I prefer to go on paying the developer in order for him to get paid for the whole work as soon as he is able to deliver the code (in order to avoid for him the indefinite time of final payment).

What I don't like in case we decide to go on applying the PPC updates later is that it makes our investment undefined as I'll need to ask the developer to go on with the patches and so I don't know in advance what will be the final cost.

From me also support. The changelog says that it rebases to Bitcoin 0.20 and removes centralized checkpoint support (we already removed). See here. This would basically mean that we'd have really modern code and would immensely facilitate later upgrades.

However, afaik it's still in RC state. So maybe he should wait until the final release is out?

Sensible suggestion. Not only is the new PoSTemperature mechanism worth having but migrating to an older version of PPC would be suboptimal - basically kicking the can down the road - because an eventual upgrade to PPC v10 is inevitable, surely?

Cheers

Graham