Slimcoin | First Proof of Burn currency | Decentralized Web

[muf18]

So I and @ksdme have discussed issue, about "updating" current base, or rebasing it to the newer version.

He has an idea for it:

I meant to say that we can just announce that all the burn transactions will be forged onto the new chain (with maybe a mac cap) and no balances would be forged though. So people who own slm can burn it and keep the burn balance on the new coin. This would cause us to have people who will be invested in us for a long term.

I think it's nice idea, and would actually, be within our main purpose of "burning" coins.
Anyone who, would want to participate, would have to burn coins through client, mined or bought with exchange.

It should be decided of course, with everyone approval. What do you think?

It's just an idea for now, and more for a future, but I think, it's nice idea, to actually make our coin fully useful and up-to-date, with core 0.15.

With this we, could automatically applicate segwit and other new things from Bitcoin code.

I know it's a very demanding job to do, and to have PoB function working, but as Graham said, we can use Navcoin resource and at least bring base to 0.13 with segwit support, and base it on it.

What do you think?

[aIA]

I think it's nice idea, and would actually, be within our main purpose of "burning" coins.
Anyone who, would want to participate, would have to burn coins through client, mined or bought with exchange.

It should be decided of course, with everyone approval. What do you think?

I think it would be a nice workaround for update features quickly. But I think that we will haven’t liquidity to move SLM on exchanges, and get SLM listed over some months.

[muf18]

I hope yobit will list us soon, and then I'll go on spreading the word (because without exchange there isn't much sense, I think).
If yobit would list us, then we are good to go to have at least 5-10BTC daily vol imo.

[d5000]

@muf18:

This seems like a nice idea in theory, but in practice this approach would have a problem: Slimcoin, as we know it now, would have a "death date" and its price would go only down from now on, because the PoB process is not well-known enough in the crypto community . So until the new version is released, it would not really be used - it will stay in a kind of "limbo" - because everybody would know it will "die" eventually.

There is another problem: To be able to benefit from this swap you would need a large balance, because PoB with less than a few thousand coins is not very "profitable." The only way to solve that problem would be a kind of "PoB pool" but there are no experiences with that until now.

So if such a swap is necessary, I would be in favor of a more traditional process: a "Bitcoin Gold"-like snapshot where:

- balances (UTXOs)
- burnt coins
- all inscriptions (web2web etc.)

would be transferred to the new chain. The snapshot should not be more than ~1 week before the launch date (ideally, it would be the same day, so there should be almost no "limbo".

In reality I would like a "gradual" process more (e.g. following Peercoin's schedule), but I know that a hard fork to a really new version is not easy. However, there are communities that have experience with that, like Litecoin (if I remember right they went straight from 0.6 to 0.11) and also some smaller coins like Vertcoin.

[coin2.0]

it seems there have no exchanges can use  to trade slim.

[muf18]

@muf18:

This seems like a nice idea in theory, but in practice this approach would have a problem: Slimcoin, as we know it now, would have a "death date" and its price would go only down from now on, because the PoB process is not well-known enough in the crypto community . So until the new version is released, it would not really be used - it will stay in a kind of "limbo" - because everybody would know it will "die" eventually.

There is another problem: To be able to benefit from this swap you would need a large balance, because PoB with less than a few thousand coins is not very "profitable." The only way to solve that problem would be a kind of "PoB pool" but there are no experiences with that until now.

So if such a swap is necessary, I would be in favor of a more traditional process: a "Bitcoin Gold"-like snapshot where:

- balances (UTXOs)
- burnt coins
- all inscriptions (web2web etc.)

would be transferred to the new chain. The snapshot should not be more than ~1 week before the launch date (ideally, it would be the same day, so there should be almost no "limbo".

In reality I would like a "gradual" process more (e.g. following Peercoin's schedule), but I know that a hard fork to a really new version is not easy. However, there are communities that have experience with that, like Litecoin (if I remember right they went straight from 0.6 to 0.11) and also some smaller coins like Vertcoin.

So because of it, there would be guide for burning coins, thus making it possible to preserve funds.
It wouldn't make a death date, cause there would be a new branch.
Preserving all funds like these blocked from BTER, doesn't make much sense especially, that probably they dont have keys for it (because they would dump it otherwise, there was a demand for such amount).
It would also make somewhat bad assumption on market valuation. As of now, in circulation there are about only half of coins there are in reality.
It would also show how much people are really intetested in SLM.
I know that at some point, somebody can be left holding unmaintained branch, but to prevent we could reserve a lot of time (like 3-4 months), and announce it in several media outlets.
We can also make snapshot, of balances, it's a possibility too of course.

@coin2.0 - wait for yobit or try freiexchange.

[d5000]

An idea to get rid of these "blocked" funds of BTER etc. could be to require an "activity proof" - e.g. that before the snapshot, only funds that were moved at least once since a certain date (e.g. early 2017, because it was then that the "new era" of Slimcoin started) would be transferred to the new chain. And, of course, the burnt coins.

If we don't transfer balance at all, then we can forget about adoption from now on until the new coin comes out, and that could be the whole next year or more (it would be even "the faster the better").

We can however do the following to encourage burning:
- All coins that were moved since 2017-1-1 (or another date) are transfered
- Coins that were not moved since 2017-1-1 are added, proportionally, to the burn balance of the rest of the funds. (e.g. if half of the funds were not moved since then, then everybody that burnt coins would get a 50% bonus to his burnt balance). That would, surely, be a nice incentive to burn.

What do you think?  Would that be an acceptable proposal?

[gavrilo77]

We can however do the following to encourage burning:
- All coins that were moved since 2017-1-1 (or another date) are transfered
- Coins that were not moved since 2017-1-1 are added, proportionally, to the burn balance of the rest of the funds. (e.g. if half of the funds were not moved since then, then everybody that burnt coins would get a 50% bonus to his burnt balance). That would, surely, be a nice incentive to burn.

What do you think?  Would that be an acceptable proposal?

Sorry, i did not get: Moved where? What balance?

[d5000]

Sorry, i did not get: Moved where? What balance?

That's a hypothetical scenario if the community decided to do a "snapshot" to update cleanly to a modern Bitcoin version, adding the typical Slimcoin features (PoB) directly (look at muf18's posts). That would mean that the Slimcoin blockchain would be re-started with modern code, and SLM balances would have to be transferred to the new chain.

muf18/ksdme proposed initially to transfer only burnt coins (so if you wanted your balance to be transferred then you would have to burn it), but that seems to me a too radical solution - at least balances that have been moved recently should be transferred.

Nothing is decided yet, and I would still prefer a path with more continuity.

[gavrilo77]

Sorry, i did not get: Moved where? What balance?

That's a hypothetical scenario if the community decided to do a "snapshot" to update cleanly to a modern Bitcoin version, adding the typical Slimcoin features (PoB) directly (look at muf18's posts). That would mean that the Slimcoin blockchain would be re-started with modern code, and SLM balances would have to be transferred to the new chain.

muf18/ksdme proposed initially to transfer only burnt coins (so if you wanted your balance to be transferred then you would have to burn it), but that seems to me a too radical solution - at least balances that have been moved recently should be transferred.

Nothing is decided yet, and I would still prefer a path with more continuity.

What would be possible damage or benefit of it?

[d5000]

What would be possible damage or benefit of it?

It's a possible, relatively easy solution for an upgrade to modern code.

The benefit of a snapshot-based upgrade is that it's easier to update this way. If Slimcoin used a regular hardfork, one would have to test the "switch of protocols" thoroughly, and the client software would have to support both protocols (old and new) just before the fork. A soft-fork path from old to modern is even more challenging.

The downside of a "snapshot" is the loss of continuity; it would not be avoidable that at least for some hours (in the best of the cases, it would be more likely to be several days) the Slimcoin chain would not be working (after the snapshot is done, the old chain would be functional but practically worthless).

[metare]

I recently went through the whitepaper of Gulden, which I found very interesting because of two reasons.
Find it here
First I learned quite a lot about blockchain technology and second I wondered if some of the development for the PoW2 could be used for Slimcoin too.

I'm just playing with ideas but I assumed that maybe Gulden in case of a snapshot scenario would be a lot closer to what Slimcoin aims to.

[d5000]

I recently went through the whitepaper of Gulden, which I found very interesting because of two reasons.
Find it here
First I learned quite a lot about blockchain technology and second I wondered if some of the development for the PoW2 could be used for Slimcoin too.
I'm just playing with ideas but I assumed that maybe Gulden in case of a snapshot scenario would be a lot closer to what Slimcoin aims to.

Do you mean this "PoW2" as a replacement for DCrypt?

I just quick-read the page, and the following phrase seems unbelievable:

Finally a blockchain that is not just "mostly safe" but is completely out of practical reach of attack by even the most wealthy and determined attacker.

Reading the other paragraphs and a part of the whitepaper, it seems that they are using a hybrid PoW/PoS system ("currency holding witnesses") where blocks are "found" by miners and then signed by stakers, who must "lock" their coins to be able to get rewards. This reminds me of some of the proposals I have read on the Ethereum blog (e.g. Slasher).
It seems to be a modern algorithm and yes, it could improve the security of the PoW/PoS part of Slimcoin. It would be interesting how PoB could be integrated in that model.

[metare]

Do you mean this "PoW2" as a replacement for DCrypt?

Well I have no idea how far partial implementation would be possible, since I'm not a developer at all.
Since the discussion also went about a possible leap to a newer bitcoin based code with a snapshot, I thought this would probably be a feasible alternative to base slimcoin on. Also in the other cases it might provide concepts for further development.

[d5000]

Do you mean this "PoW2" as a replacement for DCrypt?

Well I have no idea how far partial implementation would be possible, since I'm not a developer at all.
Since the discussion also went about a possible leap to a newer bitcoin based code with a snapshot, I thought this would probably be a feasible alternative to base slimcoin on. Also in the other cases it might provide concepts for further development.

Well, the "tri-hybrid" structure - to include PoW, PoS and, above all, PoB in the "consensus structure" - is Slimcoins "basic unique selling point". I would never support to change to another structure, above all never accept that Proof of Burn is abandoned. But yes, the particular PoW or/and PoS algorithm could be changed or improved - while maintaining the reward structure, so the "value" proposition isn't changed (for example, for me there should be no change to a much more "inflationary" reward schedule).

So if "PoW2" as a hybrid PoW/PoS algorithm can be integrated with Proof of Burn and is relatively easy to implement with Bitcoin code, I would not rule out to make it a part of Slimcoin's consensus system.

[muf18]

Daily update: I still didn't receive any word from yobit.
It's now a week from application, so I hope they will respond soon.

[sluggo]

Looking to buy alot of slim PM me fam

[muf18]

Btw. Vote for us on Next.exchange

https://nextexchange.featureupvote.com/suggestions/3080/slimcoin-slm-the-original-proofofburn-cryptocurrency

[eddycurrent]

Hello all,

New armel(V5) binarys are up. Sorry I can't get the aarch64(V8) binarys up this week like I said.

On another topic, I have had another issue with running the code on Arch Linux. Boost was recently updated to version 1.66.0, and I have the following error when compiling:

Code:

src/bitcoinrpc.cpp: In function ‘void ThreadRPCServer2(void*)’:
src/bitcoinrpc.cpp:4473:58: error: no matching function for call to ‘boost::asio::ssl::context::context(boost::asio::io_service&, boost::asio::ssl::context_base::method)’
     ssl::context context(io_service, ssl::context::sslv23);
                                                          ^
In file included from /usr/include/boost/asio/ssl/context.hpp:757:0,
                 from /usr/include/boost/asio/ssl.hpp:18,
                 from src/bitcoinrpc.cpp:28:
/usr/include/boost/asio/ssl/impl/context.ipp:326:1: note: candidate: boost::asio::ssl::context::context(boost::asio::ssl::context&&)
 context::context(context&& other)
 ^~~~~~~
/usr/include/boost/asio/ssl/impl/context.ipp:326:1: note:   candidate expects 1 argument, 2 provided
/usr/include/boost/asio/ssl/impl/context.ipp:63:1: note: candidate: boost::asio::ssl::context::context(boost::asio::ssl::context_base::method)
 context::context(context::method m)
 ^~~~~~~
/usr/include/boost/asio/ssl/impl/context.ipp:63:1: note:   candidate expects 1 argument, 2 provided
src/bitcoinrpc.cpp:4489:41: error: ‘class boost::asio::ssl::context’ has no member named ‘impl’
         SSL_CTX_set_cipher_list(context.impl(), strCiphers.c_str());
                                         ^~~~
src/bitcoinrpc.cpp: In function ‘json_spirit::Object CallRPC(const string&, const Array&)’:
src/bitcoinrpc.cpp:4643:58: error: no matching function for call to ‘boost::asio::ssl::context::context(boost::asio::io_service&, boost::asio::ssl::context_base::method)’
     ssl::context context(io_service, ssl::context::sslv23);
                                                          ^
In file included from /usr/include/boost/asio/ssl/context.hpp:757:0,
                 from /usr/include/boost/asio/ssl.hpp:18,
                 from src/bitcoinrpc.cpp:28:
/usr/include/boost/asio/ssl/impl/context.ipp:326:1: note: candidate: boost::asio::ssl::context::context(boost::asio::ssl::context&&)
 context::context(context&& other)
 ^~~~~~~
/usr/include/boost/asio/ssl/impl/context.ipp:326:1: note:   candidate expects 1 argument, 2 provided
/usr/include/boost/asio/ssl/impl/context.ipp:63:1: note: candidate: boost::asio::ssl::context::context(boost::asio::ssl::context_base::method)
 context::context(context::method m)
 ^~~~~~~
/usr/include/boost/asio/ssl/impl/context.ipp:63:1: note:   candidate expects 1 argument, 2 provided

This appears to be somewhat similar to this (same boost version): https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224131

I have had a bit of a look but cannot see any solutions. Has anyone else got any suggestions of where to look or what to do?

Regards

[muf18]

I have probably messed up big.
In yobit there is new code section, and you must then activate it.
I don't understand why, but when you create it, you can't activate automatically.
So probably I just activate it, and sent request again.
Sorry, for this mistake, it was really stupid.

Btw. they have written me again 0.1BTC, even tho they should charge me.
I don't really understand this.

Btw. 2 - can someone merge addnodes, from this into master branch ?
https://justpaste.it/1bcq1

They said that nodes should be included in source code.