Topic: [ANN] Slimcoin : Proof of Burn NEW BLOCK GEN, Mineable by low power computer! - page 7. (Read 284890 times)

Very interesting developments, thanks gjhiggins!

Now if we decide to hard fork: It's true what rfcdejong says, it could weaken the network. It would be nice to have some kind of "census" of active slimcoin users, or even better, to have an own forum to coordinate the protocol switch. Well, at least we have a reddit, it's pretty inactive but could be used for these cases: http://www.reddit.com/r/slimcoin/ I've seen at least some recent post have been made ... things are getting better.

I am a bit delayed with my little "PoB report" project but expect to launch it next week. Will announce it here and at Reddit.

Sounds good to finally have a true fork from peercoin (and then being able to use peer unity forks as well?). Great job! But testing is really important. A manditory wallet update will make the network weak for a period of time, especially if people don't know in time.

Graham, this looks awesome!
I'm very happy to see that Slimcoin is able to intrigue developers.
By making your work public you can count others in for testing!
I'm already cloning your repo and will try to compile slimcoind on Ubuntu and Raspbian.

As the main dev position is still vacant (and as far as I understood "Mr E" he doesn't want to have that), you could think about taking that position. It looks like your work is an application for that position
I don't know how many people are still actively following the Slimcoin development, but are still running nodes.
As development might sooner or later cause a hard fork, it will become important to make sure the "network" is aware of that development.
E.g. bter.com still offers trading of Slimcoin. In case of a hard fork they need to update their wallet.

I'm very excited to see such a progress at Slimcoin.
PoB to secure a block chain is just too interesting to let Slimcoin end.

I've been doing some integration work on the quiet. I intended to do more testing before announcing the results of my efforts but contemporaneity trumps caution.

I've been hacking around with the PPCoin git repos and (with a bit of judicious conflict resolution) have been able to retrofit SLIMCoin as a branch , thereby recruiting the full PPCoin commit history as the base for “John Smith’s” SLM initial commit and subsequent commit history.

I was able to merge all the way up to the latest commit of the standard PPCoin master (not the more extensive “develop” branch tho' which is a shame because it integrates the 0.8.6 codebase, leveldb, coincontrol and all).

I've also integrated all the contributions from the recent changes in the three extant forks

TBH, I'm mainly interested in getting a better understanding of the PoB element of SLIMCoin and (for me, at least) a coherent, detailed commit history is essential.

The exercise has made the SLIMCoin codebase much more amenable to inspection with a 3-way diff tool such as meld and (for instance), when compared with the original PPCoin codebase, better reveals the PoB-related code.

Whilst I was engaged, I spruced up the graphics and added a couple of features to assist with my analysis; an in-wallet block explorer and a difficulty plot.

At the moment, the repos is under my personal GitHub a/c and I've taken the liberty of adding the other forkers as collaborators:

https://github.com/gjhiggins/SLIMCoin




* The master, develop and sunny branches are contemporary PPCoin.
* The primary branch for SLIMCoin work is slimcoin.
* prerelease has all feature.* merged in for one-stop convenience.


N.B. I've barely begun to test the code, in the interim please consider it as an inspection device.


Overview page with diffplot:




* I chose to roll with the PPCoin switch to protocol v4, hence the spurious 0.4 upgrade deadline warning.
* I've only just begun to investigate the plunges in diff, they're probably PoS blocks.
* If they are, then I'm tempted to call it a “feature” as it usefully indicates PoS/PoW proportion.


Block browser page:



HTH

Cheers

Graham

Yes, I pulled the whole fork. But I'm not using it productively still (that is still one of the last of a123's versions). Will try it out these days.

I followed the advice of some of you and have re-enabled PoS - without problems so far. And I got my first PoB block, with only 20 SLM burnt so far Will burn some more now and play around.


I'm running the linux version (without gui) and I get the errors and crashes only when I run it with too low memory / swap space (512 MB seems to be too low, for example). But here I can't help you because I'm not so much of a techie ...

Ditto that. I've been buying the odd SLM here and there when the price is low, mainly because it's a really interesting concept and I hope to see it grow. And if it does grow, then the price will (hopefully?) go up... so kind of like investing in a start-up company in the hope that it will become popular. (And, of course, I need actual coins to burn in order to try out PoB.)

Heh, I'm not sure I know exactly how it works just yet, but the source code is right there, and there's a lot of information back in this thread if you have the time to read through it (look for posts from 'slimcoin', the original dev). The principle is not that complicated -- burn coins to 'buy' virtual burn-mining 'hardware', and then keep your client running to mint coins -- but how that interacts with Proof of Work and Proof of Stake seems to have caused some issues in the past.


Even in the absence of a main dev right now, I'm confident the network's stable enough to keep running as long as there are people who still want to run it.

There are some who know very well how Slimcoin works - ask "Slimcoin" or a123 for example.
Everyone one who is interested and has the skill can find out as well - the code is open source.
That's what "Mr E" did and - boom! - there's another one who knows how it works.

The interaction between the different processes and their difficulty adjustment is for sure something that needs to be watched closely or even tuned.
But I need to underline it:
Slimcoin is working. It's still running. The block chain is safe. Forking seems to be no longer a problem.
Although it's not maintained for some months the last updates by a123 seem to have kept Slimcoin alive.

Why do people buy coins? Because the speculate on price development, because they like to play with their features, because they want to know how things work.
I have Peercoins, because I want to play with minting.
I have Emercoins, because I wanted to play with the DNS and PKI features.
I have NuShares, because I wanted to play with voting.
I have had Slimcoins, because I wanted to play with burning - which was quite successful

Slimcoin is very experimental. Proof of Burn to secure a block chain is unique.
What's intriguing is that it's working!
And it solves one of the problems PoS processes face: after the SLM have been burned, you have a (strong!) incentive to mint continuously, because the decay whether or not you mint with them.

Slimcoin is a great experiment. It would be nice to see that continued, which would be a reason for speculators to buy low these days

So, I feel like I'm broaching something a little taboo, but I have to ask.  It seems like no one really knows how slimcoin works, but every now and then someone buys a few hundred bucks worth of it. Why?

That's good to hear. Did you pull my whole github fork, or just make the change I gave to a123's version?

I seem to have gotten rid of the slimcoin-qt crashes by compiling a version which is more aggressive at banning 'old version' clients (ones that keep spamming getblocks requests). This suggests that the crash is due to dealing with large numbers of requests in close proximity or something similar - which would be consistent with what I've seen where the memory usage suddenly spikes upwards before a crash. I'm just not sure about pushing that pach out widely, since I don't know what the chances are of it banning a legitimate node by accident. I am still showing 27 active connections, though, which suggests it hasn't banned everyone (yet?).

I don't know if slimcoin on linux has the same problem; as far as I know, I'm the only one reporting issues with this and I'm mainly running the Windows client. (I should try running a linux one too and see how it goes.)


Yes, it was changed so by default it has a 'reserve balance' of like 10,000,000 or something, so it won't stake coins unless you have more than that. But PoS blocks are still accepted, and you can still re-enable staking in the debug console (by setting 'reservebalance false'), which I've done and haven't seen any problems so far. If I have time, I should go back and look over the old posts to try and figure out what exactly the problem was... (or someone else could if they're feeling bored!)

That's good news! I haven't tried that as my a123 version of the RaspberryPi binary runs like a charm.

I'm not aware of that issue at Peercoin as well. I have Peercoin clients running on several machines, some of them full nodes, some not, some with Peercoin client, some with Peerunity client and have 1 minter running on a RaspberryPi (compiled ppcoind) for months now without issues.
The Peercoin clients seem to run fine.
The trouble with PoS at Slimcoin might be related to memory issues or strange behaviour with the interaction of the 3 processes.
I don't remember exactly, although I've read almost the whole thread, but I think there were some posts regarding the PoS issues.
After all that was the reason for a123 to disable PoS (by adjusting the default configuration), right?

Thanks Mr. E! I have compiled your fork and it worked without errors. If I remember right the error you mention (ambiguous type conversion) was also the one that prevented me from compiling a123's last code.

I had a Slimcoin crash recently but that was because I was running it with very low memory & swap after a reboot.


Unfortunately I don't know if Peercoin had this issue or if they resolved it. I never had problems or crashes with my Peercoin client.

When you compile the new version please remove my old nodes.

addnode=107.181.250.216:41682
addnode=107.181.250.217:41682

I'm no longer running Slimcoin at these IP addresses.

I will put some new public nodes up asap.

Same here; I've manually re-enabled staking when I run slimcoin and haven't had any major problems. (There is the fact that it crashes every so often, but it does that regardless of whether staking is enabled.)


-----
@d5000, I've pulled a123's latest changes to my own fork and got it to compile with one change:
Without that change, my build failed with an error along the lines of "type conversion is ambiguous".

I've got my fork compiling for both linux and win32, using Gitian with the descriptor files located in slimcoin/contrib/gitian-descriptors/*. (Though I've made a lot of changes to them to get it working; I don't think it was being used for quite a while in Slimcoin, and maybe Peercoin too.)

If a123 shows up, I'll send him a pull request to integrate it all back into his copy (as long as someone can check it builds ok for them too!).

Not sure if staking just doesn't work on a large scale or if something else solved the problem, but I've continued to stake and haven't had any stability issues.

I agree; whether on not PoS is kept will I think mainly determine which one we end up following.

I also would like to keep the 3-way generation if possible, but I need to make sure I understand what the issue with PoS was first. If I've got it right, the problem was that stake transactions would end up creating a whole bunch of small credits, and then each one of those would be a candidate for future staking which led to too much processing (searching a huge stack of transactions constantly). If that's the case, then I'll need to understand better how staking actually works to know whether it's fixable or not.

I'm not at all familiar with Peercoin, but I can't help thinking -- did they have this problem? Did they solve it? 

From an "economical" perspective, I agree with you, PoS can make sense as a component of the economic model.

My favourite would be a mainly PoS/PoB model with PoW slowly declining in importance due to the difficulty model where PoW rewards decline when the hashrate/difficulty grows (I think that's the actual model, or at least it was the original one). What I don't know is if it is harder from the programming/stability perspective if the three models coexist. Now without PoS at least my client works very fine.

I am planning a thread in the main altcoin forum with a at least weekly report of the main Slimcoin statistics, to draw conclusions about the PoB activity and its relation to price. Actually I'm writing a little script that reports the main data for SLM like the burn address balance, nEffectiveBurnCoins, price at BTER etc.. every day at the same hour, so I can compare data more exactly. Obviously, a planned side-effect is to draw more attention to SLM

We should try to re-instate / re-activate PoS imho. Slimcoin should try to remain a Tri-Block Gen. coin.

Slimcoin as the developer clearly put a lot of thought into the economic viability of Slimcoin, PoS is an important part of that model imho.

This coin has so much innovation its hard to understand why it isn't much more popular. I would like to start contributing and testing builds when I have time perhaps.

Hi Mr E!



Peercoin seems to be switching to the BTC 0.8.6 codebase with the 0.5 release (see https://github.com/ppcoin/ppcoin/tree/develop and the pull requests). PPC 0.5 has important features regarding PoS (cold-locked minting, duplicate stake detection), but they will be irrelevant if SLM decides to take down PoS.

Perhaps it will be best if we decide first if we want to keep PoS (I don't want to take much part of this decision as I'm not a programmer) or not, because in the case we drop it perhaps it is better to rebase SLM on the latest Bitcoin.

@all: I have compiled a123's latest version on Linux and the brain wallet code added as last commit probably contains a bug, I cannot get it to compile (can anyone confirm?). The version inmediately prior to it from October 28 (0fc7bc779d82999c99cff44c970871da29c2df38) works fine.

Yay. 
I would say that a123 was doing a good job as developer before the end of the year came around -- perhaps he'll show up again as the new year starts rolling. Here's hoping...

I've been thinking about this while trying to get the build working, and I wholeheartedly agree -- it would be ideal if we can rebase our code off either the latest bitcoin, or peercoin if they're reasonably up-to-date with bitcoin-core. Perhaps I can look at how much work that will be, once I get the current version building...