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

[masterOfDisaster]

Well, perhaps the 40.000 buy is a new dev stepping in ... perhaps he will dump again at ~ 10.000 satoshis, but maybe we have other problems solved

The 40,000 buy was roughly 1.5 BTC of value - not exactly what I'd expect before a new dev steps in and tries to take profit from the development

I think the priority for a new dev - or "slimcoin" or "a123" if they come back - would be to follow closely the development of Peercoin 0.5, which will be based on a newer codebase (the BTC 0.6 base of actual SLM is pretty old, there are a lot of useful commands missing) and merge the new peercoin code with SLM.

That would be useful, but I think the priorities need to be focussed on the protocol:

The other one is the decision how to continue with the distribution model: PoW/PoS/PoB? PoB/PoS? or PoW/PoB?

For me, both PoB/PoS and PoW/PoB have both advantages -  three different block generation algos are a bit too much, I think. PoB/PoS would be "the ultimative green coin" without energy waste, but PoW until now determines the PoB difficulty, so it will be more difficult to replace.

Three algos might be too much, indeed.
PoB needs to stay, of course And I like it that the current combination is PoB/PoW. There are currently more than enough PoS coins for one. And coin distribution by mining in the PoW process shouldn't be underestimated. I think being able to mine a coin (instead of buying the coins) is for some people a very important option; the option to buy still remains.

But how is the PoB difficulty determined by PoW? My understanding is that the PoB difficulty is determined by "nEffectiveBurnCoins". There is only the dependency that between PoB blocks need to be (at least 3?) PoW blocks.

Why are there still PoS blocks in the chain?
I thought PoS would have been deprecated by a123's release (e.g. block 209477 is a PoS block).
Do I interpret this right that PoS blocks now have no trust value and don't generate rewards, but are still in the block chain?

[1715045630]

1715045630

[1715045630]

1715045630

[1715045630]

1715045630

[BitcoinFX]

...

Why are there still PoS blocks in the chain?
I thought PoS would have been deprecated by a123's release (e.g. block 209477 is a PoS block).
Do I interpret this right that PoS blocks now have no trust value and don't generate rewards, but are still in the block chain?

PoS function has not been removed from the code. It has only been temporarily deactivated by enforcing reservebalance= large balance to prevent staking coins in the wallet.

It is therefore still possible to stake (if you edit before compiling) the code or to fully reactivate staking in the future.

Staking (or having 3 methods of block generation active at once) seemed to be causing some issues as the block chain increased in size. This was simply part of a fix to get the chain moving again following multiple 'forks'. Staking does still appear to stall the client on occasions though. I suspect its rather like the old expression "two's company, three's a crowd" ?  

 

[masterOfDisaster]

PoS function has not been removed from the code. It has only been temporarily deactivated by enforcing reservebalance= large balance to prevent staking coins in the wallet.

I like that even better, because it might be easier to "restart" an adjusted PoS process than to create a completely new one. It might be done without a hard fork as exisiting clients already deal with PoS blocks.

It is therefore still possible to stake (if you edit before compiling) the code or to fully reactivate staking in the future.

That - especially the latter one!

Staking (or having 3 methods of block generation active at once) seemed to be causing some issues as the block chain increased in size. This was simply part of a fix to get the chain moving again following multiple 'forks'. Staking does still appear to stall the client on occasions though. I suspect its rather like the old expression "two's company, three's a crowd" ?   

I'm aware of the problems this has caused until PoS was effectively deactivated. Having a second process that secures the block chain might not bad, though.
It allows removing (or significantly lowering) the PoW block trust values while still having two processes that can create blocks with a reasonable trust value.
I doubt that this is really necessary if PoB works as intended. But having a reinsurance rarely is a bad idea

[d5000]

If there is a dev (a123 or slimcoin) still reading this thread: There is a interview series about "innovative coins" from the SuperNet initiative:

https://bitcointalk.org/index.php?topic=924275

It could be a great way to spread the word and attract new users and developers.

Also, perhaps it could be possible to try to join SuperNet, as SLM has PoB as an unique feature it's not impossible that they accept it in the mid-term. Only problem I see is the lack of a "main dev" with regular presence in this forum, and the small user base.

But how is the PoB difficulty determined by PoW? My understanding is that the PoB difficulty is determined by "nEffectiveBurnCoins". There is only the dependency that between PoB blocks need to be (at least 3?) PoW blocks.

Mh. Must look at it, perhaps you are right and that is the only dependency between PoW and PoB. It sounds logical and in fact I have said the same to primer~ some days ago. Perhaps I wrote complete bullshit there

I'm now fully synced and SLM is running like a charm, thanks again for your help! (The database errors were because of an extraction error from my 7-zip. So your Raspberry blockchain snapshot is fine, too.).

[d5000]

Great work, thanks toshis.guru! Interesting stats.

It would be really cool to have the following statistics too:

- a graph of the balance of the burn address (SfSLMCoinMainNetworkBurnAddr1DeTK5)
- a graph with the value of "Formatted nEffectiveBurntCoins" (from "slimcoind getburndata")
- a graph with the "effective supply": total supply - balance of burn address

Perhaps these stats would be best at the main SLM website or at slimcoin.club, but if an external service sets them up, it would be very cool too. Any chances?

If not, I probably will manually set up a monthly or even weekly report in some days/weeks, as I'm very interested im the PoB dynamics, and post it here in the forum.

[toshis.guru]

Great work, thanks toshis.guru! Interesting stats.

It would be really cool to have the following statistics too:

- a graph of the balance of the burn address (SfSLMCoinMainNetworkBurnAddr1DeTK5)
- a graph with the value of "Formatted nEffectiveBurntCoins" (from "slimcoind getburndata")
- a graph with the "effective supply": total supply - balance of burn address

Perhaps these stats would be best at the main SLM website or at slimcoin.club, but if an external service sets them up, it would be very cool too. Any chances?

If not, I probably will manually set up a monthly or even weekly report in some days/weeks, as I'm very interested im the PoB dynamics, and post it here in the forum.

Hey d5000

I'll talk to our dev if it's possible, i'll keep you updated!

greetings

[d5000]

That would be uber-great. Thanks!

The reason of my interest in these data is that I would like to investigate if there is a link between "coin burn rate" / "burn difficulty", "available supply" and price.

Even for "normal users" without academic interest it would be interesting how the "available supply" changes in time, to see if the coin tends to be inflationary or deflationary.

[Mr E]

If there is a dev (a123 or slimcoin) still reading this thread: There is a interview series about "innovative coins" from the SuperNet initiative:

https://bitcointalk.org/index.php?topic=924275

It could be a great way to spread the word and attract new users and developers.

Also, perhaps it could be possible to try to join SuperNet, as SLM has PoB as an unique feature it's not impossible that they accept it in the mid-term. Only problem I see is the lack of a "main dev" with regular presence in this forum, and the small user base.

Hi all. I am now back from my Christmas break and back to attempting to get a build environment working for Slimcoin. I'm by no means a candidate for a 'main dev' (nor am I really a publicity person either!), but I'm hoping that if a123 or another dev picks up the project again, I can contribute testing and bug/feature patches.

In particular, I want to implement the 'coin control' options that are in the current Bitcoin Core, as I like to be able to select old transactions and merge them into a new single, larger one. (I'm OCD like that  ) Plus, I'm still getting occasional random crashes with 'St9badalloc' in the windows GUI client, which I want to debug.


Still haven't completed a successful build yet, but I'm getting closer -- all the dependencies build except for qt-win32, which I'm in the middle of recompiling right now to see if it works this time...

[masterOfDisaster]

Hi all. I am now back from my Christmas break and back to attempting to get a build environment working for Slimcoin. I'm by no means a candidate for a 'main dev' (nor am I really a publicity person either!), but I'm hoping that if a123 or another dev picks up the project again, I can contribute testing and bug/feature patches.

Hi Mr E!
Nice to have you aboard the development team - unfortunately you are the only member:)
Though you are based on your self-assessment no main dev, it could be tremendously valuable to do bug fixes and testing.
I don't know why, but Slimcoin is not dead yet. The block chain is running. Some nodes are on the network.
Maybe it can be kept alive long enough to arouse interest of somebody capable of being main dev.
It would be a pity to see this Proof of Burn approach to secure a block chain end this way.
So welcome, amongst this bunch who haven't given up hope!

[Mr E]

Hi Mr E!
Nice to have you aboard the development team - unfortunately you are the only member:)
Though you are based on your self-assessment no main dev, it could be tremendously valuable to do bug fixes and testing.
I don't know why, but Slimcoin is not dead yet. The block chain is running. Some nodes are on the network.
Maybe it can be kept alive long enough to arouse interest of somebody capable of being main dev.
It would be a pity to see this Proof of Burn approach to secure a block chain end this way.
So welcome, amongst this bunch who haven't given up hope!

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 think the priority for a new dev - or "slimcoin" or "a123" if they come back - would be to follow closely the development of Peercoin 0.5, which will be based on a newer codebase (the BTC 0.6 base of actual SLM is pretty old, there are a lot of useful commands missing) and merge the new peercoin code with SLM.

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...

[d5000]

Hi Mr E!

I think the priority for a new dev - or "slimcoin" or "a123" if they come back - would be to follow closely the development of Peercoin 0.5, which will be based on a newer codebase (the BTC 0.6 base of actual SLM is pretty old, there are a lot of useful commands missing) and merge the new peercoin code with SLM.

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...

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.

[BitcoinFX]

Hi Mr E!

I think the priority for a new dev - or "slimcoin" or "a123" if they come back - would be to follow closely the development of Peercoin 0.5, which will be based on a newer codebase (the BTC 0.6 base of actual SLM is pretty old, there are a lot of useful commands missing) and merge the new peercoin code with SLM.

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...

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.

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.

[d5000]

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

[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.

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

@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.

I can't help you with that currently, as my build is based on an earlier (21 Oct) fork -- but I'll try merging in the changes and see what happens. I've currently got a successful build working for Windows; I still need to see if it will build for Linux too (and fix it when it doesn't....)

Btw, can you give details on the errors when you tried to compile? There seemed to be a couple of changes along with the new passphrase function, so it would help to know which bit is likely at fault.

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 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? 

[pantheist]

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.

[Mr E]

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.

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:

Code:

slimcoin/src/rpcdump.cpp:
@@ -97,7 +97,7 @@ Value importpassphrase(const Array& params, bool fHelp)
  obj.push_back(Pair("Address",       vchAddress.ToString() ));
  obj.push_back(Pair("Hash",          pass.GetHex()));
  obj.push_back(Pair("Phrase",        strSecret));
- obj.push_back(Pair("Length",        strSecret.length()));
+ obj.push_back(Pair("Length",   (int)strSecret.length()));
  return obj;
  // return Value::null;
}

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!).

[BitcoinFX]

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.

[d5000]

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.

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? 

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.

[masterOfDisaster]

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.[...]

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

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.

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?

[Mr E]

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.

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.)

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?

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!)