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
Topic: Slimcoin | First Proof of Burn currency | Decentralized Web - page 63. (Read 137088 times)
It's not quite as straightforward as that - https://minkiz.co/library/a-different-perspective-on-cryptocurrency.html
Cheers
Graham
We are on coinsmarkets, freiexchange and coinhouse.
Happy New Year everyone 
Slimcoin is no longer updated on coinmarketcap. It is removed nova, there is no more market.
Slimcoin is no longer updated on coinmarketcap. It is removed nova, there is no more market.
@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.
@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.
Happy trading, for now there is a wallet synchronization, so wait until, it will be synchronized.
@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!
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!
December 31, 2017, 05:49:35 PM
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
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
December 31, 2017, 07:30:32 AM
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.
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.
December 30, 2017, 10:39:32 PM
@d5000: Thank you for your detailed answer! I really appreciate it.
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.
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.
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?“
Quote from: d5000
- 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.
Quote from: d5000
- 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.
Quote from: d5000
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.
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?“
December 30, 2017, 02:25:13 PM
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.
That's what Kilari told me, about eg. putting wikipedia on Slimweb:
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. Quote
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.
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.
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.
December 30, 2017, 02:07:26 PM
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.
Like I mean - what is even Monacoin or Experiance Points - it's a more of a social phenomenon, than a real tech behind it.
December 30, 2017, 08:58:16 AM
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:
That's what Kilari told me, about eg. putting wikipedia on Slimweb:
Quote
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.
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.
December 29, 2017, 11:26:01 PM
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
December 29, 2017, 11:08:54 PM
@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.
- 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.
December 29, 2017, 07:25:16 PM
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
December 29, 2017, 06:22:35 PM
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"!
December 29, 2017, 05:24:51 PM
It could be possible probably, but if you prune blockchain, how would you retrieve torrent hash?
I like concept of mini-blockchain, as it has quite a few appliances, and could be scalable with a few tricks:
- like 10-20M blocks
- fast txs - I think with our consensus 15-30 sec
- maybe we ocould take mini-blockchain idea with pruning some data in the tx
- segwit
It would make 2K-4K tx/s possible, tho there are a lot of question regarding, is this sustainable, and if nodes would proceed such amount of data.
Probably not, so I think, we don't have for now 'problem'.
Btw I see that every fork of zcash and monero are just skyrocketing. I mean ok, they are privacy coins, but I dont know if someone is even thinking, what's buying into.
I like concept of mini-blockchain, as it has quite a few appliances, and could be scalable with a few tricks:
- like 10-20M blocks
- fast txs - I think with our consensus 15-30 sec
- maybe we ocould take mini-blockchain idea with pruning some data in the tx
- segwit
It would make 2K-4K tx/s possible, tho there are a lot of question regarding, is this sustainable, and if nodes would proceed such amount of data.
Probably not, so I think, we don't have for now 'problem'.
Btw I see that every fork of zcash and monero are just skyrocketing. I mean ok, they are privacy coins, but I dont know if someone is even thinking, what's buying into.
December 29, 2017, 05:11:14 PM
@blockhash7: I mostly agree, also about the "slim" part. But I think we should not switch to the mini-blockchain scheme. The reason is that this scheme doesn't allow contracts with the Script language and "forgets" old blockchain entries - so it couldn't be used anymore for the "decentralized web". Cryptonite is awesome as a cash replacement, but for other purposes its scope is more limited.
Thank you for your answer! Are the concepts of the mini-blockchain scheme and the concept of the decentralized web really mutually exclusive? I thought the web2web service uses the blockchain just as a directory service and the actual website data is stored in a torrent? (maybe I’m mistaken here. Sorry I couldn’t find much information about the web2web publishing part) I think it‘s possible to apply the concept of the account tree of the mini-blockchain scheme to stored key/value pairs in the blockchain. Just like the account tree forgets about old account-states, it could forget about old values of keys. In this way you can store data in the mini-blockchain and minimize its footprint. To keep it „slim“, so to say.
December 29, 2017, 04:28:45 PM
Didn't @gjhiggins started Slimcoin v0.6 branch?
I think he started working on it, tho I don't know where he is now.
And if we want to be used as a real cryptocurrency some payment gateways, would be necessary. As @gjhiggins stated, I think that as a cryptocurrency, SLM failed for now, it can be viewed as a store of value (it somehow, stored valued through these turbulent years), investment (Proof-of-burn consensus) and utility token, as I was talking with Graham. With fully fledged blockchain, and these features developed it's still better than 90%+ of ICOs, code-wise superior advanced to them. I don't say that to be 'proud' or anything, just stating, facts.
@d5000 - sure, thanks, I could done more, but was a little lazy for a few days. Still, what we lack is some community involvement, and I don't mean - there are a few new people now, which is great, but as I would think more, shading light to project. I know it could bring some shillers, trolls and other 'cryptonuts' guys, with fomo and 🚀 gifs, but would also bring some valueable people, who could help us also.
I think he started working on it, tho I don't know where he is now.
And if we want to be used as a real cryptocurrency some payment gateways, would be necessary. As @gjhiggins stated, I think that as a cryptocurrency, SLM failed for now, it can be viewed as a store of value (it somehow, stored valued through these turbulent years), investment (Proof-of-burn consensus) and utility token, as I was talking with Graham. With fully fledged blockchain, and these features developed it's still better than 90%+ of ICOs, code-wise superior advanced to them. I don't say that to be 'proud' or anything, just stating, facts.
@d5000 - sure, thanks, I could done more, but was a little lazy for a few days. Still, what we lack is some community involvement, and I don't mean - there are a few new people now, which is great, but as I would think more, shading light to project. I know it could bring some shillers, trolls and other 'cryptonuts' guys, with fomo and 🚀 gifs, but would also bring some valueable people, who could help us also.
December 29, 2017, 04:18:18 PM
Thanks for the fast response. Good news is: adding the path to the Makefile worked. Bad news: I got a new array of errors related to the class CBigNum
https://ibb.co/eHz1Mb
Uh. I know this problem from Cryptonite ...https://ibb.co/eHz1Mb
It's a well known problem in many altcoins, because OpenSSL 1.1+ isn't compatible with the old code.
If you want a short term workaround, if you can, you could install OpenSSL 1.0.x again, but it's not easy in some distributions. (I wasn't able to do it)
Peercoin has a commit that solved it, but it's from the 0.6 branch: https://github.com/peercoin/peercoin/commit/5b09830e5de0f5105534e69dbf4acffb3255869b
@muf18: I think you're doing an awesome "job" with Twitter, Reddit & Facebook ... so relax a bit, when the decentralized web gets usable, there'll be much work
(If I have time next week I'll do a short introduction about web2web, and compare it to the other solutions, so if you want you can then translate it to Polish)Jump to: