Slimcoin | First Proof of Burn currency | Decentralized Web

[blockhash7]

It could be possible probably, but if you prune blockchain, how would you retrieve torrent hash?

Then don't prune the OP_RETURN data. We could extend the mini-blockchain scheme to support key/value storage. The paradigm would be: "Just keep the final states. Forget about the old states." Do we really need to keep all history data in the blockchain? Is that "slim"? I don't think so. If we prune all old status updates we will free up 99% of the obsolete data in the blockchain and give room for the relevant data. So we're reducing the footprint of the wallet, making it more compact and more efficent. That would be "slim"!

[afozzy]

Looking at the code, I think the change to GetProofOfStakeReward(int64 nCoinAge, u32int nTime) in commit 7d4cacc is responsible for this and should probably be reverted.

Absolutely. Great catch. That change is completely spurious. Reverted.

https://github.com/slimcoin-project/Slimcoin/commit/79b206e2a85ae03ae0962c76a6357f7bc419e2a9

Cheers

Graham

Thanks iguanodon1 and gjhiggins, staking is working properly now. 
I had tried gjhiggins previous sugesstion and I thought I had put a repy on this forum but something didn't work at the time

[d5000]

@blockhash7: Apart from what muf18 already mentioned (hashes being stored on the blockchain), I have also some other reservations about the mini-blockchain-scheme in SLM:

- As our community is generally in favour of decentralization in most aspects of the cryptocurrency ecosystem, we would like to implement BIP65-based atomic swaps to minimize dependency on centralized exchanges - but they wouldn't work with the mini-blockchain scheme, because it doesn't use Script and doesn't allow hashed timelock contracts.
- A switch to the mini-blockchain scheme would need much development effort. Pruning only transaction data and not OP_RETURN data would mean that we cannot simply copy from Cryptonite, so it would mean even more effort. Yes, one could store the hashes also as a "final state", but then the nice "versioning" feature would not be possible anymore. That may seem a minor problem, however.
- Slimcoin uses Proof of Stake and Proof of Burn blocks, and thus it is - at least partly - affected by the Nothing-at-stake problem. The mini-blockchain scheme adds a small vulnerability (51% attacks are potentially much worse there), and one should first investigate the consequences and possible effects of both vulnerabilities. For example, Cryptonite uses 1-week-blockchains. If an attacker is able to attack the chain via an still unknown N@S vulnerability and manages to dominate the chain for a full cycle of one week, then the coin would be almost dead (only a hard fork would save it). Ardor has implemented a very similar scheme than Cryptonite and is pure PoS, so one could observe the behaviour there and then decide if it's viable.

I am not against pruning in general - in fact, I would love to have the Bitcoin 0.10+ pruning feature enabled, but the SLM code must still be updated to enable that. Also I'm more a 2nd-layer guy, not so much a Big Blocker, so I would love, for example, see extension blocks or sidechains implemented in Slimcoin, so the main chain can stay "slim".

If for all these questions/problems a solution is found, I would be happy to switch to the mini-blockchain scheme, but it should be a long-term goal at most. A "prunable transaction type" (Ardor has something like that) with lower or zero mandatory fee, for example, would be perhaps a better solution, so contracts and other time-intensive transaction types would not be affected.

[gjhiggins]

having also reorgs in mind

Algorithmically feasible: blocknotify.py checks the notified block's prevhash against the hash of the last-recorded block in the graph. If they differ, it implies that a re-org has occurred and blocknotify flips into “re-org” mode, iterating down from currentheight, checking the recorded nexthash value against the node's nexthash value and, until they match, removing the orphaned blocks from the graph and then finally, when the nexthashes match, catching up from there to current.

I'm mapping the Gapcoin blockchain atm, I changed the catchup procedure so that it cycles in 100K block steps, it's a tad kinder, and seeing as the initial mapping is usually a one-off task, I left the output files of ntriples in place, ready for concatenation and feeding through to Jena's TDB cli.

Point taken about filenames scripts and roles, needs to be clearer. The unit test inclusion is just my perverted interpretation of TDD, by binding the ACME virtualenv python to a SublimeText Build, I can develop the code using a restricted subset of the data and just hitting ^B runs the test, very direct prototyping. When I've got to a suitable stopping point, I release the restrictions and can just run it as a specific test. Just a development foible of mine.

I've also adjusted Fuseki on the server to increase the max JVM heap space to 8Gb, responses seem faster but that may be fond imagining on my part.

Cheers

Graham

[muf18]

It's faster, tho not always (if it's going to load, it's faster than).

That's what Kilari told me, about eg. putting wikipedia on Slimweb:

I just found a way to put the entire Wikipedia on Slimweb (at least almost all of it) in such a way that no one has to seed the entire wikipedia dump.

It works by having a mirror of Wikipedia where it is designed such that every person browsing the page in the normal way also seeds the article he/she is reading.

In fact this system can be extended to put large data stores onto this in a fragmented way while providing a way to actually prove that the content wasn't tampered with.

In a way it is like all the people with free internet access are collectively helping people with limited internet access by simply minding their own bussiness.

[muf18]

Btw. we must find someone, who can use Japanese, there is a big community out there, who are very likely to join.

Like I mean - what is even Monacoin or Experiance Points - it's a more of a social phenomenon, than a real tech behind it.

[d5000]

Algorithmically feasible: blocknotify.py checks the notified block's prevhash against the hash of the last-recorded block in the graph. If they differ, it implies that a re-org has occurred and blocknotify flips into “re-org” mode, iterating down from currentheight, checking the recorded nexthash value against the node's nexthash value and, until they match, removing the orphaned blocks from the graph and then finally, when the nexthashes match, catching up from there to current.

Looks like a good idea! Have you already wrote some code for it? Otherwise, I can try to implement it myself - also as a coding exercise for me.

feeding through to Jena's TDB cli.

Yes, that's maybe the best way for the initial block sync. I missed it initially (and so my local node took weeks to catchup), but then for the public node I recurred to this technique.

The unit test inclusion is just my perverted interpretation of TDD

I had suspected something like that - that's still far away for a noob like me. Well, I'll for now will to continue to use my "blocknotify-cli" fork without unittest. I haven't really changed the code, only reorganized it a bit, so loops and command line arguments are possible.

BTW: Are you OK with the name "Slimweb" or do you have a better proposal? Your opinion would be important, as you had the web2web idea initially.

That's what Kilari told me, about eg. putting wikipedia on Slimweb:

I just found a way to put the entire Wikipedia on Slimweb (at least almost all of it) in such a way that no one has to seed the entire wikipedia dump.

It works by having a mirror of Wikipedia where it is designed such that every person browsing the page in the normal way also seeds the article he/she is reading.

How would the versions of articles be stored on the blockchain? If every article had a Slimcoin address for the torrent hash, that would lead to significant blockchain bloat.

I had already thought a bit about that problem - one could develop a kind of standard for multi-page torrent hashes.  In that model, there is only one Slimcoin address used for the whole site (e.g. Wikipedia) and the hash leads to a "start page" that contains the updated hashes to the single articles. But even then, a million-subpage-site like Wikipedia would be a challenge and a "sub-structure" would be needed. If you have found a solution for that issue, that would be a huge advance ...

There is already a similar project that uses IPFS to seed Wikipedia - maybe one can learn from it, although they use a whole snapshot. IPFS is a much more complex system than web2web, but as nearly all other similar projects, it has the disadvantage that the end user has to user a "non-standard" software to access it, so a web2web version would have advantages.

[blockhash7]

@d5000: Thank you for your detailed answer! I really appreciate it.

- As our community is generally in favour of decentralization in most aspects of the cryptocurrency ecosystem, we would like to implement BIP65-based atomic swaps to minimize dependency on centralized exchanges - but they wouldn't work with the mini-blockchain scheme, because it doesn't use Script and doesn't allow hashed timelock contracts.

That‘s a valid point. I didn‘t realize that Cryptonite‘s mini-blockchain scheme has no scripting ability at all. I agree that it’s important to have scripting. I also agree that Slimcoin will benefit from supporting atomic swaps.

- A switch to the mini-blockchain scheme would need much development effort. Pruning only transaction data and not OP_RETURN data would mean that we cannot simply copy from Cryptonite, so it would mean even more effort. Yes, one could store the hashes also as a "final state", but then the nice "versioning" feature would not be possible anymore. That may seem a minor problem, however.

I‘d like to emphasize that a small efficient blockchain is more important than the versioning feature. After all a small blockchain is the basis for decentralization. And that‘s what cryptocurrencies are all about!

But I understand that improving Cryptonites mini-blockchain scheme is too much effort.

I am not against pruning in general - in fact, I would love to have the Bitcoin 0.10+ pruning feature enabled, but the SLM code must still be updated to enable that. Also I'm more a 2nd-layer guy, not so much a Big Blocker, so I would love, for example, see extension blocks or sidechains implemented in Slimcoin, so the main chain can stay "slim".

If for all these questions/problems a solution is found, I would be happy to switch to the mini-blockchain scheme, but it should be a long-term goal at most. A "prunable transaction type" (Ardor has something like that) with lower or zero mandatory fee, for example, would be perhaps a better solution, so contracts and other time-intensive transaction types would not be affected.

These are good proposals! I really would like to see more effort to make Slimcoin really slim. As the name suggests Slimcoin should have a small footprint. Let‘s make its blockchain as small as possible! Let‘s make the synchronization as fast as possible! Any step towards these goals would be great. I think more important than adding to funtionality is improving performance and efficiency.

Having „Slimness“ as a long term goal would be great! It would give the whole project a direction and a core volue. We could evaluete new features by asking the question: „does it make Slimcoin slimmer?“

[muf18]

First of all these, we should make client load faster imo, and/or make electrum-like wallet. It would be good to upgrade base, but as Graham told me, that's easier to make new cryptocurrency with PoB, and Bitcoin v0.1x base, then make such an upgrade.

Everybody out there are now chasing "moon-missions", I hope, that we don't do that.
It's nice to see appreciation of value, but basing it on fundamentals, not on cryptomania-speculation.

As there is a lot of incentives to hold SLM (PoS reward, PoB reward after burning, controlling supply), I think that W2W, will make it into usable token, with real value attached, to published content.
As we know, content is valueable in the world, and having it around the world, always online is something worth while.

It's different to others, and we are in final stages, to implement it.

Then some good marketing team, we could make, and we are good to go imo.

[d5000]

I've just published the latest website updates and fixed the image error, should work now. Thank you @ksdme!

One thing that still needs to be added is Freiexchange. I think another "exchange card" would not break the design, am I right? For now I left it out, but it can be added easily changing only the _config.yml file thanks to ksdme's update.

Other thing I would like to change is the location of the slimcoin-qt Windows client - it should better not be located directly in the website repository. The cleanest way would be to create a new Release in the Slimcoin repository, but I'd still no time to figure out how that's done. In the new year (I'm still in 2017 for some hours) I can look at that.

----

@blockchain7: I've thought, as a long-term goal, that Slimcoin could aim for a two-layer structure: a consensus layer and a pegged child-chain or side-chain for low-fee payments. One could use the Drivechain model or a structure like in Ardor/Ignis - the latter would be more secure for a relatively small currency, but as far as I know it hasn't been implemented in Bitcoin-based code.

To add my thoughts to the update discussion: I think we should aim, once we have enough developer-power, to do an update to modern Bitcoin code as a mid-term goal. It must not be necessarily in 2018 (we maybe better follow Peercoin's update path) but the Bignum problem and the 0.4.8 Berkeley database portability issue, for example, show that the code is slowly getting outdated. There are some other communities that were able to upgrade from 0.6-0.8 to 0.11+, so one could slowly look how they have done it and follow that path closely. Maybe a hard fork can help (that would be essentially the same than "creating a new cryptocurrency with PoB from 0.10 code",) but it would be better without one ...

I'm slowly introducing myself into "cryptocurrency programming", and while I'm far from being able to contribute to the "heart" (consensus layer) of the Slimcoin client, maybe in some months I'll be able to do minor fixes in the "easier" fields like in the GUI section, or easy-to implement patches.

Happy 2018 to all Slimcoiners

[blockhash7]

@d5000: I think we have to decide on one of two routes for Slimcoin:

1. developing Slimcoin closely tied to another Cryptocurrency. In that case Slimcoin should probably only be different to this Cryptocurrency in a few points, e.g. proof of burn and web2web. It would be like Litecoin, which is tied to Bitcoin. Since Slimcoin is a fork of Peercoin, one could tie Slimcoin to Peercoin. The big advantage of this is the low programming effort involved. The disadvantage is less flexibility and a much weaker USP.

2. developing Slimcoin indepently from other Cryptocurrencies. In that case we can implement whatever the Slimcoin community wants. However the programming effort will be huge, because we cannot benefit from developments in the original forked code.

So this leads me to following question: how big is Slimcoin’s development team anyway? How many people are there? And what share of their time are they investing to Slimcoin?

Thank you for your insights!

[kingkongcorp]

Happy trading, for now there is a wallet synchronization, so wait until, it will be synchronized.

[muf18]

@blockhash7 - as I know, mainly developing Slimcoin are Graham, @d5000, and @ksdme.

@kingkongcorp - do you mean than Slimcoin is going to be added to this exchange - https://globitex.com ?

New Slimcoin Client AIO:https://mega.nz/#!YrxlDABb!nXCZD_9ZDc0TLgKzbKNhg3BJ-iYiD8yax_y4XBV2dhM

As always install on Windows OS.

[Cbx.Bet]

Happy New Year everyone 

Slimcoin is no longer updated on coinmarketcap. It is removed nova, there is no more market.

[muf18]

We are on coinsmarkets, freiexchange and coinhouse.

[gjhiggins]

Thank you for your insights!

It's not quite as straightforward as that - https://minkiz.co/library/a-different-perspective-on-cryptocurrency.html

Cheers

Graham

[bobitza202]

Slimcoin is no longer updated on coinmarketcap. It is removed nova, there is no more market.

In the last days, Slimcoin was traded for about 0.06$ on coinsmarkets, hopefully coinmarketcap will update the data  

[Cbx.Bet]

In the last days, Slimcoin was traded for about 0.06$ on coinsmarkets, hopefully coinmarketcap will update the data  

I tried to send a request to coinmarketcap but it does not update if the markets have not at least $1000 USD equivalent of daily trading volume.

[muf18]

I think, if everything will go well, we will be added to yobit.

[blockhash7]

I tried to send a request to coinmarketcap but it does not update if the markets have not at least $1000 USD equivalent of daily trading volume.

Hm, but there are many coins with less than $1000 daily trading volume:

https://coinmarketcap.com/exchanges/coinsmarkets/

Doesn't make sense to me.