[ANN] Slimcoin : Proof of Burn NEW BLOCK GEN, Mineable by low power computer!

[hankrules]

if block 89923 is in your blockchain, you probably are on the right fork.

What are you getting for

slimcoind getblockhash 90141
00000010e9815d44f9f3e3dcba3ad793a8f81d9bf28498c81d83aed28b30d3b9

?

[d5000]

I get the same hash.

[gjhiggins]

Just for confirmation:

Code:

gjh@tessier:~/Projects/Coinage$ ./slimcoin/src/slimcoind getblockhash 90141
00000010e9815d44f9f3e3dcba3ad793a8f81d9bf28498c81d83aed28b30d3b9

Cheers

Graham

[gjhiggins]

I suppose we like the idea.

And some of us don't think it's had a decent chance to prove its merit.

I see altcoin space as feature-oriented. To take a deliberately jaundiced perspective: it's all just a pile of whistles and bells decorating classic bitcoin - the basic feature set is fixed by the fork parent. In that context, PoB is a potential genuine extension of that feature set and has some claimed merit - this we are checking out because if it can be made to work, it gives the coin a valuable USP.

The idea does seem to make sense, at least at a surface level and I guess we're big enough and ugly enough to want to persist in finding out whether it is actually capable of delivering. Maybe the dev didn't get the initial implementation quite right. It's not as if it's the first time that's happened.

A few competent people could always take over.

I agree with the dev's assessment, a revised implementation based on the Peerunity fork holds some promise. The current slimcoin implementation is based on the Bitcoin 0.7.3 codebase (from which Peercoin was originally forked) and that's possibly a bit of an unsteady reed, still using BerkeleyDB and missing a raft of subsequent bugfixes, tweaks, etc.

Ironically, the collective task of getting this particular p2p engine firing smoothly is helping to establish a stronger sense of community ownership. Whilst it's not a strategy one would necessarily choose if given the option, there's little sense in throwing away all the progress to date in an impatient hissy-fit. I prefer to provide support where I think it'll be most effective, even if it's merely contributing a reliable node, as in this instance. I'm not at all sure that the effect of the last round of fixes wasn't banjaxed by the seed nodes going down while the dev was on holiday. We're still regaining network stability and that seems to be a problem in principle for any relatively low-hashrate coin.

We shouldn't underestimate the amount of work involved here. A browse through the repos commit history will inform you that “John Smith” has been consistently and persistently working on the code since December last year. The kids have only just gone back to school and his last post was about three weeks ago. I'm not anticipating full-time commitment from a man with a family, that would be unreasonable and, by my lights, undesirable.

However, I do think that the basic initial promise has been kept - mining on a Raspberry Pi and I prefer not to lose sight of this original goal because I can see a nice little brand story (“marketing strategy”, if you like) that would position this coin rather prettily in the spectrum of altcoin offerings and while it wouldn't necessarily demand involvement from the community of Slimcoin miners/owners, I believe it would definitely invite it. If-and-when the boat stops rocking, I'll start developing the idea further.

Cheers

Graham

[BitcoinFX]

I suppose we like the idea.

And some of us don't think it's had a decent chance to prove its merit.

I see altcoin space as feature-oriented. To take a deliberately jaundiced perspective: it's all just a pile of whistles and bells decorating classic bitcoin - the basic feature set is fixed by the fork parent. In that context, PoB is a potential genuine extension of that feature set and has some claimed merit - this we are checking out because if it can be made to work, it gives the coin a valuable USP.

The idea does seem to make sense, at least at a surface level and I guess we're big enough and ugly enough to want to persist in finding out whether it is actually capable of delivering. Maybe the dev didn't get the initial implementation quite right. It's not as if it's the first time that's happened.

A few competent people could always take over.

I agree with the dev's assessment, a revised implementation based on the Peerunity fork holds some promise. The current slimcoin implementation is based on the Bitcoin 0.7.3 codebase (from which Peercoin was originally forked) and that's possibly a bit of an unsteady reed, still using BerkeleyDB and missing a raft of subsequent bugfixes, tweaks, etc.

Ironically, the collective task of getting this particular p2p engine firing smoothly is helping to establish a stronger sense of community ownership. Whilst it's not a strategy one would necessarily choose if given the option, there's little sense in throwing away all the progress to date in an impatient hissy-fit. I prefer to provide support where I think it'll be most effective, even if it's merely contributing a reliable node, as in this instance. I'm not at all sure that the effect of the last round of fixes wasn't banjaxed by the seed nodes going down while the dev was on holiday. We're still regaining network stability and that seems to be a problem in principle for any relatively low-hashrate coin.

We shouldn't underestimate the amount of work involved here. A browse through the repos commit history will inform you that “John Smith” has been consistently and persistently working on the code since December last year. The kids have only just gone back to school and his last post was about three weeks ago. I'm not anticipating full-time commitment from a man with a family, that would be unreasonable and, by my lights, undesirable.

However, I do think that the basic initial promise has been kept - mining on a Raspberry Pi and I prefer not to lose sight of this original goal because I can see a nice little brand story (“marketing strategy”, if you like) that would position this coin rather prettily in the spectrum of altcoin offerings and while it wouldn't necessarily demand involvement from the community of Slimcoin miners/owners, I believe it would definitely invite it. If-and-when the boat stops rocking, I'll start developing the idea further.

Cheers

Graham

Good post.

Did anyone test a windows build yet with the devs. last commits ? They should help to fix the RAM issues at least. I can run Slimcoin again on 2x windows vps nodes and provide a build myself if necessary, if we know if that build does fix the RAM exceptions.

v0.3.2.0-2-g53d7c33-alpha is the devs last 'official' build ?

Anyway, have just got the above client in sync. and currently see a block height of 90540.

[pantheist]

Any ideas how to fix this?  It's driving me crazy to see all my burned coins degrading and I can't keep the wallet open for more than a few minutes at a time.  I've tried deleting everything but wallet.dat and letting the blockchain reload, but it doesn't help.

[BitcoinFX]

Any ideas how to fix this?  It's driving me crazy to see all my burned coins degrading and I can't keep the wallet open for more than a few minutes at a time.  I've tried deleting everything but wallet.dat and letting the blockchain reload, but it doesn't help.

See:

As for the bad alloc exception, I looked around and found an explanation that is probably the solution:

From https://github.com/bitcoin/bitcoin/issues/2353

This is how bitcoin runs out of memory (virtual address space) while downloading blocks:

Whenever a node receives a block that it cannot link to the chain, it stores it in memory in mapOrphanBlocks. There is no limit to the size of that data. When a node is downloading blocks, it may download and keep in memory many blocks that it can't currently link to the chain. In particular, if your node connects to another node which is also downloading blocks and which is further along in the download, the other node will spam your node with an "inv" message for every new block that it downloads (no, the logic in CBlock::AcceptBlock does not prevent it), and your node will download and store those blocks in mapOrphanBlocks. This can occur with multiple connected nodes simultaneously which are at different points in the download.

I encountered this problem several times with 0.8.0rc1. With the current size of the blockchain, it is not hard to exhaust the virtual address space (at most 4GiB) in 32-bit builds, which includes all Windows builds.

The fix could proceed in one of two directions: (1) store orphan blocks on disk instead of in memory, or (2) don't keep an unbounded set of orphan blocks. For (2), the ideal would be to prevent downloading of too many orphans rather than discarding orphans that have already been downloaded, which is wasteful. The goal would be to download blocks roughly in order. One idea is to make use of "getheaders" during block download. Headers would be downloaded and linked together, and blocks would only be downloaded if we already know based on headers that they are not too far away from the chain of blocks that we already have.

How much memory does your system have?

I could implement the second option, but will look into how bitcoin fixed this issue.

Also, if you have any other exceptions, please post them.

Before Slimcoin went awol he posted an 'untested' fix to github that should mostly resolve this issue. I don't think that anyone has compiled or tested the fix for windows yet.

I see the exact same errors with the current release on my windows VPS nodes each with 1 GB RAM, however another PC with 16 GB of RAM is 'stable', although these memory issues are still present ofc.

Windows OS below windows 7 is also worse for some reason.

I had a PM discussion with Slimcoin about compiling the new code for testing - I suggested that he should compile it - maybe he is re-writing the code base from unity instead ? It is doubtful that he would just abandon Slimcoin.

[BitcoinFX]

Last commits by Slimcoin on Github see:

https://github.com/slimcoin/slimcoin/tree/master/src

init.cpp    Added excess orphan block pruning    20 days ago
main.cpp    Added excess orphan block pruning    20 days ago
main.h    Added excess orphan block pruning    20 days ago

Should mostly 'fix' the windows memory exception error.

EDIT: https://github.com/slimcoin/slimcoin/commit/afd8ef7e18e17f876f0bc7b44e79ee867f0b3ac1

[slimcoin]

Lately, something 'bigger' has come along and have decided to lower my activity on Slimcoin. I will do compilations and releases, maintain the master seed node for synchronized checkpointing, and review pull requests on github. Apart from that, I only plan on doing small tweaks here and there if necessary. I am not abandoning Slimcoin, I am merely giving the majority of the development up to the community. That does not mean I am gone, I may return to more development here depending on how the future goes.

[m5j0r]

How about
-actually making the wallet work. It still crashes a lot
-setting up a node that works. I've ran my sys 24/7 for nothing until a helpful user here posted another node
-doing some marketing. FFS it's your coin isn't it?
No exchange is interested in SLM at all.

No offense but it seems as if you rely on the community doing YOUR work.

Edit: My coins now randomly switch between stake and balance. Shouldn't they always be in "balance" until I eventually move them?

[BitcoinFX]

Lately, something 'bigger' has come along and have decided to lower my activity on Slimcoin. I will do compilations and releases, maintain the master seed node for synchronized checkpointing, and review pull requests on github. Apart from that, I only plan on doing small tweaks here and there if necessary. I am not abandoning Slimcoin, I am merely giving the majority of the development up to the community. That does not mean I am gone, I may return to more development here depending on how the future goes.

OK good to know. The priority being a more stable Slimcoin client wallet that functions as described.

If the wallet is stable (again) then I'm certain that more people will get involved with mining and trading Slimcoin once its on a few exchanges.

One person can't do everything and this is a centralized development approach anyway. Lets get a stable wallet running and the community will just have to run with it from here.

PoB and the economic crypto-experiment presented by Slimcoin is worthy of more research and interest imho, perhaps by university economics, mathematics and computer science departments, for example.

[m5j0r]

@BitcoinFX That's a very interesting POV but most if not all coin devs are in the game to make money. 99.99% of BTC users are in it for that.

Just like all the clones that got big. They excel in marketing and get people into it. Hype it. Strategically cash out. Then eternal downtrend. Same game with the next coin.

Anyway. My stake/balance is still switching around like mad. Looking at the prices on BTER I will probably never break even. Money down the drain. Not too much, but still annoying.

Hoping for: -a new wallet -an official dev node that actually works -dev talking to exchanges

Or I might just delete the whole thing and be done with it. So much trouble for so little.

[BitcoinFX]

@BitcoinFX That's a very interesting POV but most if not all coin devs are in the game to make money. 99.99% of BTC users are in it for that.

Just like all the clones that got big. They excel in marketing and get people into it. Hype it. Strategically cash out. Then eternal downtrend. Same game with the next coin.

Anyway. My stake/balance is still switching around like mad. Looking at the prices on BTER I will probably never break even. Money down the drain. Not too much, but still annoying.

Hoping for: -a new wallet -an official dev node that actually works -dev talking to exchanges

Or I might just delete the whole thing and be done with it. So much trouble for so little.

I don't much care for the pump and dump coins and prefer to support the alt coins that have some innovation or that are actually alternative.

I should utilize my trading skills more to try and consistently profit in the alt coin markets, but I don't and mostly just mine and hold the coins that I like best on their merits, such as Slimcoin.

...

ROOT coin (as one example of a future PoB coin) has announced that it will try to implement a technology similar to PoB and Korecoin has also announced that it will look to add PoBA (Proof-of-Burn-Anonymity), which as you will appreciate as a participant in this thread and Slimcoin user should be most interesting to watch!

Moreover, my main point being that their is actually increasing developer interest in the PoB concept and that Slimcoin will always remain the original 'stand alone' implementation of Proof-of-Burn - much like Peercoin has spawned many PoS alternatives such as Mintcoin and other coins like Cloakcoin with PoSA (Proof-of-Stake-Anonymity).

The likely hood that we will see increasing interest levels and community development for Slimcoin is therefore quite high.

I'm someone who spent well over a year mining, trading, researching, testing and promoting Bitcoin in the very early days of this forum - who cashed out at low value to pursue other projects - simply because it was taking longer than I envisaged to really take of - So, don't just delete / sell everything and quit Slimcoin, because that's just no fun whatsoever.

[d5000]

Probably I have good news.

A couple of hours ago I have compiled the newest git version with the last fixes of "slimcoin" and they seem to solve the out-of-memory problem (the crash with St9bad_alloc error). No crashes so far at a low-memory (512 MB) VPS. I will confirm it if it runs 24 hs without any issues.

Also, I am now nearly one week without any sync problems. So basically, the client is working stable now.

@m5j0r: What do you mean with the "switching" between balance and stake? If you have found a PoS block when this happened (you see it when there is a little increment in the amount of coins after it goes to "balance" again) then it is normal behaviour in all Peercoin-based coins. Its a security measure to be sure the PoS system is not gamed.

[BitcoinFX]

Probably I have good news.

A couple of hours ago I have compiled the newest git version with the last fixes of "slimcoin" and they seem to solve the out-of-memory problem (the crash with St9bad_alloc error). No crashes so far at a low-memory (512 MB) VPS. I will confirm it if it runs 24 hs without any issues.

Also, I am now nearly one week without any sync problems. So basically, the client is working stable now.

@m5j0r: What do you mean with the "switching" between balance and stake? If you have found a PoS block when this happened (you see it when there is a little increment in the amount of coins after it goes to "balance" again) then it is normal behaviour in all Peercoin-based coins. Its a security measure to be sure the PoS system is not gamed.

Indeed. It has been apparent for sometime that the issues and 'crashes' are just over RAM related exception errors.

Hopefully you won't see any crashes at R-Pi levels of RAM now then.  

Even windows systems with large RAM seem to be more stable using only the current release, probably as the network, hash rate and block propagation is becoming more stable once again.

...

PoS blocks take a while to confirm and will show as 'ticked' in transactions whilst still being 'staked' in balance, this is even more confusing if you have multiple stakes active. That's possibly what your describing m5j0r ?

[m5j0r]

I think what you're explaining might be the PoS thing I've encountered.

My SLM sometimes show up 100% in balance, sometimes 100% in stake, sometimes just a few % in stake. I thought PoS meant all coins older than x will be in stake, while newly moved coins will be in balance.
At least that is what the devs of other coins that I've been into so far explained it like. None of their PoS was actually working though, so this is new to me.

I'm still connected using that one node from one of you guys and it seems to work fine.
I do have the error "checkpoint is too old wait for blockchain to download" in the statusbar all the time. It still says "last generated block x seconds ago" and I guess that is okay.

[BitcoinFX]

I think what you're explaining might be the PoS thing I've encountered.

My SLM sometimes show up 100% in balance, sometimes 100% in stake, sometimes just a few % in stake. I thought PoS meant all coins older than x will be in stake, while newly moved coins will be in balance.
At least that is what the devs of other coins that I've been into so far explained it like. None of their PoS was actually working though, so this is new to me.

I'm still connected using that one node from one of you guys and it seems to work fine.
I do have the error "checkpoint is too old wait for blockchain to download" in the statusbar all the time. It still says "last generated block x seconds ago" and I guess that is okay.

Yes. There are a couple of user interface discrepancies in this regard still.

The check point error is just that, we need updated checkpoints or automated check pointing built in. Slimcoin probably started updating some seed node stuff for the updated release too.

[d5000]

Unfortunately I got the St9bad_alloc error again, and I even don't know if the fixes have changed something.

Now I did some testing and it seems the Slimcoind daemon (without GUI) on my machine needs in total about 1,3-1,5 GB of memory to run without these crashes. So if someone has a machine with less space you must assign it some swap space on hard disk.

On my 512 MB low memory machine it seems to work fine with 1 GB of swap (with Linux/Ubuntu OS), so on a Raspberry Pi and similar devices it should be similar.

[pantheist]

Unfortunately I got the St9bad_alloc error again, and I even don't know if the fixes have changed something.

Now I did some testing and it seems the Slimcoind daemon (without GUI) on my machine needs in total about 1,3-1,5 GB of memory to run without these crashes. So if someone has a machine with less space you must assign it some swap space on hard disk.

On my 512 MB low memory machine it seems to work fine with 1 GB of swap (with Linux/Ubuntu OS), so on a Raspberry Pi and similar devices it should be similar.

I have 4 GB on win 7 64-bit and I still get em. Haven't gotten to mess with the code yet though (thanks for posting the fixes btw BitcoinFX)

[yang5034]

fork again.