Slimcoin | First Proof of Burn currency | Decentralized Web

[d5000]

What you are writing would not be Proof of Burn anymore, it would be "deposit-based Proof of Stake" which is already used in many other coins, so it's nothing special. It would have a completely different security/consensus model. I'll be always strictly against a change in that sense. It is also not technically possible to withdraw burnt coins without some kind of rollback which invalidates old transactions, because when you burn coins, they are transfered to an address nobody has control on because there is no known private key.

What one can think about is a mechanism to "lease" burnt coins, like in some Proof of stake cryptocurrencies. Maybe it is possible to adapt Peercoin's "multisig minting" to Proof of Burn. Other possibility to profit from not-decayed PoB coins is a Proof of Burn token, which is already possible with the "AT" token mechanism (once PeerAssets has been ported to SLM).

I hereby make clear that I will only continue to support Slimcoin if it continues to be a real Proof of Burn coin. I'm of course nobody to decide anything, but Slimcoin as a masternode-like or Proof-of-stake-only coin would lose all uniqueness and thus it wouldn't be interesting anymore for me.

[1713584567]

1713584567

[1713584567]

1713584567

[johnwhitestar]

I remember we've spoken about it time ago, maybe not that specifically.
But I wouldn't brainstorm any idea in this sense at the moment, as we don't have even the upgrade yet.
Once we'll have a stable developer(s)/team(s) of developers working with us I'm sure we'll be able to find interesting ideas about how to evolve PoB.

[d5000]

Yep, we've discussed a similar topic.

What obviously is possible is to sell the private keys for the address you've burnt coins with. But in this case the buyer must trust that you won't move the rewards and that you transfer it safely. Maybe he can also pay with delay when he was able to recover his investment.

I can however imagine ways to make this process more secure for the buyer, with a change in the PoB algorithm the seller of the private keys could transfer the right for the rewards from one of his addresses where he burnt from, to an address of the buyer, and so the seller would lose access to the rewards. That would obviously require a hardfork too, but that would be a change I would support. This would basically be a "sale of the decayed coins". But as a difference from a "withdrawal" like in Deposit-PoS, these coins only can be used for PoB minting.

But I think this is too complex for this next update. So yes, we should talk after the update about that. For those that don't follow Discord and Reddit, I recently opened a thread at Reddit about possible PoB improvements, but it still lacks content. I could add this idea there

[johnwhitestar]

I'd like to participate in PoB improvement discussion, but all my spare time is dedicated now to the improvement of SLM communication (site, wiki, bitcointalk, broken links around the internet), then I'd work on the infrastructure (exchanges, paperwallet, brainwallet, maybe electrum wallet, hubzilla, compilation script, PoB on VPS), then I'd begin to work on roadmap and conceptualization of decentralized management.
I'd also like to begin using SlimWeb to publish news about SLM development and adding the titles on the frontpage of the site.
After that we can invest some money into advertising.

Should we be able to go through upgrade and PoD token implementation process successfully we would be able to work on the SLM development as it should be done. Of course if at that moment there were some ideas ready to be coded it would be even better.

I also think we should brainstorm the ideas for SlimWeb at some point. I'm very positive about its potential. For instance because we'll be building it from scratch we can hope to set it up in a way to have a better searchability, maybe using tags and measuring the time of relative permanence on the page after the search of that tag or set of tags so to decide which page is more pertinent for which tag and to present the search results in order of their relevancy.  Another thing I'd like to implement is a coloured text. So when someone writes something he can color what he is saying in order for the reader to be able to understand quickly or even unconsciously whether that passage is a fact (from the point of view of the writer), an opinion, a hypothesis, citation and so on. This approach will help the reader to chose among the writers that are coloring their texts correctly. Maybe any text can be considered a composition of portions of colored information that can have its own existence, own tags and own licence, so the other authors can use those portions to compose their own texts. That has to do with concept of pure information I have in mind that I'd like to develop along with SLM, SlimWeb and PoD token projects.  

[d5000]

I'd like to participate in PoB improvement discussion, but all my spare time is dedicated now to the improvement of SLM communication (site, wiki, bitcointalk, broken links around the internet),

Yep, there is no hurry about that. I also would like to first finish the PoD prototype before doing new serious conceptual work as PoD currently is "eating" most of the free time I can dedicate to SLM. The thread I opened is more to write down ideas which could appear, and we discuss them when we've time.

I also think we should brainstorm the ideas for SlimWeb at some point. I'm very positive about its potential. For instance because we'll be building it from scratch we can hope to set it up in a way to have a better searchability, maybe using tags and measuring the time of relative permanence on the page after the search of that tag or set of tags so to decide which page is more pertinent for which tag and to present the search results in order of their relevancy.

"Semantic Web" tags are definitively a good idea, it's something that was discussed early with Graham. As the technologies like RDFa or Microdata already exist the challenge would be mostly to include them in a meaningful way in the gateway software or a search engine. So we would have to develop a "standard" vocabulary which is orientative for the Slimweb writers.

Another thing I'd like to implement is a coloured text. So when someone writes something he can color what he is saying in order for the reader to be able to understand quickly or even unconsciously whether that passage is a fact (from the point of view of the writer), an opinion, a hypothesis, citation and so on.

This can also be done without problems with RDFa and Microdata.

[johnwhitestar]

Seems like I was trying to re-invent a bicycle which is a good thing, means at least that the bicycle can exist.
 
But maybe the idea of pure information wasn't expressed yet and its development will be the logical consequence of the PoD token.

Would you please provide me some good link to read about Semantic Web, RDFa and Microdata?

[d5000]

Semantic Web technologies were hyped a bit in the 2000s, but they are currently not used in the way they were originally conceived (which is what you wrote - it would make the Web much more "searchable"). Most of these technologies are used, for example, to relate products in online shops to others, or to mark the publication date and author of an article, which isn't really exciting, and obviously a bit it's used in science, medicine etc. but it never had really a breakthrough. So there is definitively a possibility for Slimweb to shine in this area.

I've not learned about Semantic Web tech in English language (instead, in Spanish and German books/pdfs) but I think the RDFa primer is a good way to start, although it's a bit technical: RDFa Primer. You may need to know first a little bit about RDF which is the framework RDFa is based on. You could say RDFa is "RDF for Web (HTML) documents". RDF primer on W3.org is here. Microdata is basically an easier variant (with different "tags") of RDFa, while it's used by Google and other big companies, it has less potential, so I would instead prefer a RDF-based vocabulary for Slimweb.

[johnwhitestar]

Thank you!

[Gash]

I remember we've spoken about it time ago, maybe not that specifically.
But I wouldn't brainstorm any idea in this sense at the moment, as we don't have even the upgrade yet.
Once we'll have a stable developer(s)/team(s) of developers working with us I'm sure we'll be able to find interesting ideas about how to evolve PoB.

I dont remember you speaking about anything. I think u just got here to flirt with a srarter of this topic. U want masculinity in ur life. U look out for people on internet forums wanting the same and willing to share with u their manly vigor. U need a boost. Crypto gives u what u pant for, it fulfills ur life and gives u the boost u always wanted. I want to help this coin become a really budding project for which purpose I allocated the finances to stimulate its growth. I will sell you on the dark web to recoup what I ponied up for helping this coin bulge out.

[johnwhitestar]

I dont remember you speaking about anything.

We have other discussion platforms not only bitcointalk, so probably you missed the discussion.
However others are remembering that discussion as well, have a look into @d5000 answer above:

Yep, we've discussed a similar topic.

I think u just got here to flirt with a srarter of this topic. U want masculinity in ur life. U look out for people on internet forums wanting the same as you and willing to share with u their manly vigor. U need a boost. Crypto gives u what u pant for, it fulfills ur life and gives u the boost u always wanted.

The situation SLM is in right now doesn't let to have too much boost at the moment. Of course I need to believe strongly in the project in order to go on with it dedicating each single day my life to. So if it seems like I'm showing off, I beg humbly pardon to each member of the Community.

I want to help this coin become a really budding project for which purpose I allocated the finances to stimulate its growth.

I strongly doubt you will really do anything to help this project, but if you prove I'm wrong I'd be more than happy.

I will sell you on the dark web to recoup what I ponied up for helping this coin bulge out.

Someone can be unconformable with the idea I'll be trying to recover my expenses if this project begin to grow, but I believe that projects that are based on pure enthusiasm can't survive for a long time in the more and more competitive crypto-world.

And for your reference my data was already sold and resold many times, unfortunately, so you won't make too much money with it.

PS. It's possible you are not interested in my answer, but maybe the other members of Community are, so I've decided to answer your post in detail.

[johnwhitestar]

The developer has reached the first step we've agreed with him upon and released the document in which he is analyzing SLM code. Please let me know what do you think. Here is the document.

[gjhiggins]

The developer has reached the first step we've agreed with him upon and released the document in which he is analyzing SLM code. Please let me know what do you think. Here is the document.

It seems Slimcolin derived from Peercoin v0.4.0ppc and partially patched from v0.5Xppc.

Slimcoin is originally derived from Peercoin 3.0, here is the specific repos commit from which it was cloned: https://github.com/peercoin/peercoin/tree/154b52acaad8acb37a6f5e6f107ce0bfeca68229, as evidenced here: https://github.com/slimcoin/slimcoin/blob/master/src/version.cpp#L39

Protocol switch time ... These values are using to check whether the given transaction is subject to the specified protocol.

This is Peercoin-only code and refers to switches in Peercoin protocol for 0.4/0.5, these were changes not considered appropriate for Slimcoin but the switch was retained in case the community changed its collective mind on the relevance of the changes.

One change that doesn't seem to have been covered is the addition of running totals of moneysupply and totalburnt to the index - https://github.com/slimcoin-project/Slimcoin/commit/43e7af0a84f419ab1a1168189f95e193bb26be7#diff-e8db9b851adc2422aadfffca88f14c91 (something of a scrappy commit but I was still getting to grips with it all at that point) - this was implemented to satisfy exchange requirements of the time.

The RPC commands dumpbootstrap, linearizehashes, getinscription, importpassphrase, encryptmessage, decryptmessage, encryptdata, decryptdata and makekeypair were all added by me and are not relevant to Slimcoin core functionality, the same holds true for the GUI additions of block browser, chat window, mining page and inscription page.

fwiw, I made a diff of the first changes:

Code:

diff -uNr peercoin-0.3.2/src/base58.h slimcoin-0.3.2/src/base58.h
--- peercoin-0.3.2/src/base58.h	2020-04-10 16:58:34.017203905 +0100
+++ slimcoin-0.3.2/src/base58.h	2020-04-19 10:56:57.319392515 +0100
@@ -264,8 +264,8 @@
 public:
     enum
     {
-        PUBKEY_ADDRESS = 55,  // ppcoin: addresses begin with 'P'
-        SCRIPT_ADDRESS = 117, // ppcoin: addresses begin with 'p'
+        PUBKEY_ADDRESS = 63,  // slimcoin: addresses begin with 'S'
+        SCRIPT_ADDRESS = 125, // slimcoin: addresses begin with 's'
         PUBKEY_ADDRESS_TEST = 111,
         SCRIPT_ADDRESS_TEST = 196,
     };
diff -uNr peercoin-0.3.2/src/main.cpp slimcoin-0.3.2/src/main.cpp
--- peercoin-0.3.2/src/main.cpp	2020-04-19 11:31:32.605751015 +0100
+++ slimcoin-0.3.2/src/main.cpp	2020-04-19 12:04:09.529593253 +0100
@@ -868,8 +868,8 @@
     return nSubsidy;
 }
 
-static const int64 nTargetTimespan = 7 * 24 * 60 * 60;  // one week
-static const int64 nTargetSpacingWorkMax = 12 * STAKE_TARGET_SPACING; // 2-hour
+static const int64 nTargetTimespan = 30 * 60;  // retargets every 30 minutes
+static const int64 nTargetSpacingWorkMax = 10 * STAKE_TARGET_SPACING; // 15 minutes
 
 //
 // minimum amount of work that could possibly be required nTime after
@@ -2241,9 +2241,9 @@
         //   vMerkleTree: 4a5e1e
 
         // Genesis block
-        const char* pszTimestamp = "Matonis 07-AUG-2012 Parallel Currencies And The Roadmap To Monetary Freedom";
+        const char* pszTimestamp = "RT: Non-denying denial? RSA aims to distance itself from NSA scandal";
         CTransaction txNew;
-        txNew.nTime = 1345083810;
+        txNew.nTime = 1388098028;
         txNew.vin.resize(1);
         txNew.vout.resize(1);
         txNew.vin[0].scriptSig = CScript() << 486604799 << CBigNum(9999) << vector<unsigned char>((const unsigned char*)pszTimestamp, (const unsigned char*)pszTimestamp + strlen(pszTimestamp));
@@ -2259,15 +2259,15 @@
 
         if (fTestNet)
         {
-            block.nTime    = 1345090000;
-            block.nNonce   = 122894938;
+            block.nTime    = 1388098028;
+            block.nNonce   = 865766467;
         }
 
         //// debug print
         printf("%s\n", block.GetHash().ToString().c_str());
         printf("%s\n", hashGenesisBlock.ToString().c_str());
         printf("%s\n", block.hashMerkleRoot.ToString().c_str());
-        assert(block.hashMerkleRoot == uint256("0x3c2d8f85fab4d17aac558cc648a1a58acff0de6deb890c29985690052c5993c2"));
+        assert(block.hashMerkleRoot == uint256("0x6561fdf42da044631a835cad31128929d8b95fde6ce3e4f89cff8d710d8af927"));
         block.print();
         assert(block.GetHash() == hashGenesisBlock);
         assert(block.CheckBlock());
diff -uNr peercoin-0.3.2/src/main.h slimcoin-0.3.2/src/main.h
--- peercoin-0.3.2/src/main.h	2020-04-19 11:09:01.953785469 +0100
+++ slimcoin-0.3.2/src/main.h	2020-04-19 11:35:48.904010014 +0100
@@ -41,7 +41,7 @@
 static const int COINBASE_MATURITY = 500;
 // Threshold for nLockTime: below this value it is interpreted as block number, otherwise as UNIX timestamp.
 static const int LOCKTIME_THRESHOLD = 500000000; // Tue Nov  5 00:53:20 1985 UTC
-static const int STAKE_TARGET_SPACING = 10 * 60; // 10-minute block spacing 
+static const int STAKE_TARGET_SPACING = 90; // 90 second block spacing 
 static const int STAKE_MIN_AGE = 60 * 60 * 24 * 30; // minimum age for coin age
 static const int STAKE_MAX_AGE = 60 * 60 * 24 * 90; // stake age of full weight
 
@@ -52,7 +52,7 @@
 #endif
 
 static const uint256 hashGenesisBlockOfficial("0x0000000032fe677166d54963b62a4677d8957e87c508eaa4fd7eb1c880cd27e3");
-static const uint256 hashGenesisBlockTestNet("0x00000001f757bb737f6596503e17cd17b0658ce630cc727c0cca81aec47c9f06");
+static const uint256 hashGenesisBlockTestNet("0x0000000a8ecef22cc3af763a952750f70c958e7812b4df332a13ea18aa478bb1");
 
 static const int64 nMaxClockDrift = 2 * 60 * 60;        // two hours
 
@@ -586,7 +586,7 @@
     {
         // Large (in bytes) low-priority (new, small-coin) transactions
         // need a fee.
-        return dPriority > COIN * 144 / 250;
+        return dPriority > COIN * 960 / 250; //960 blocks per day
     }
 
     int64 GetMinFee(unsigned int nBlockSize=1, bool fAllowFree=false, enum GetMinFee_mode mode=GMF_BLOCK) const
diff -uNr peercoin-0.3.2/src/protocol.cpp slimcoin-0.3.2/src/protocol.cpp
--- peercoin-0.3.2/src/protocol.cpp	2020-04-19 11:40:42.762597925 +0100
+++ slimcoin-0.3.2/src/protocol.cpp	2020-04-19 11:40:39.782571688 +0100
@@ -17,14 +17,14 @@
 
 // Public testnet message start
 // unsigned char pchMessageStartTestBitcoin[4] = { 0xfa, 0xbf, 0xb5, 0xda };
-static unsigned char pchMessageStartTestOld[4] = { 0xdb, 0xe1, 0xf2, 0xf6 };
-static unsigned char pchMessageStartTestNew[4] = { 0xcb, 0xf2, 0xc0, 0xef };
-static unsigned int nMessageStartTestSwitchTime = 1346200000;
+static unsigned char pchMessageStartTestOld[4] = { 0xbd, 0x1e, 0x2f, 0xa3 };
+static unsigned char pchMessageStartTestNew[4] = { 0x4d, 0x2a, 0xe1, 0xab };
+static unsigned int nMessageStartTestSwitchTime = 1389000000;
 
 // Message start (switch from Bitcoin's in v0.2)
-static unsigned char pchMessageStartBitcoin[4] = { 0xf9, 0xbe, 0xb4, 0xd9 };
-static unsigned char pchMessageStartCoin[4] = { 0xe6, 0xe8, 0xe9, 0xe5 };
-static unsigned int nMessageStartSwitchTime = 1347300000;
+static unsigned char pchMessageStartBitcoin[4] = { 0x9f, 0xeb, 0x1b, 0x8a };
+static unsigned char pchMessageStartCoin[4] = { 0x6e, 0x8b, 0x92, 0xa5 };
+static unsigned int nMessageStartSwitchTime = 1400000000;
 
 void GetMessageStart(unsigned char pchMessageStart[], bool fPersistent)
 {
diff -uNr peercoin-0.3.2/src/protocol.h slimcoin-0.3.2/src/protocol.h
--- peercoin-0.3.2/src/protocol.h	2020-04-19 11:41:10.118838763 +0100
+++ slimcoin-0.3.2/src/protocol.h	2020-04-19 11:41:12.642860983 +0100
@@ -15,9 +15,9 @@
 #include <string>
 #include "uint256.h"
 
-#define COIN_PORT  9901
-#define RPC_PORT     9902
-#define TESTNET_PORT 9903
+#define COIN_PORT  41682
+#define RPC_PORT     41683
+#define TESTNET_PORT 41684
 
 extern bool fTestNet;
 
diff -uNr peercoin-0.3.2/src/version.cpp slimcoin-0.3.2/src/version.cpp
--- peercoin-0.3.2/src/version.cpp	2020-04-10 16:58:34.033204087 +0100
+++ slimcoin-0.3.2/src/version.cpp	2020-04-19 11:47:33.806259732 +0100
@@ -33,9 +33,10 @@
 #    include "build.h"
 #endif
 
-// git will put "#define GIT_ARCHIVE 1" on the next line inside archives. $Format:%n#define GIT_ARCHIVE 1$
+// git will put "#define GIT_ARCHIVE 1" on the next line inside archives. 
+#define GIT_ARCHIVE 1
 #ifdef GIT_ARCHIVE
-#    define GIT_COMMIT_ID "$Format:%h$"
+#    define GIT_COMMIT_ID "154b52a"
 #    define GIT_COMMIT_DATE "$Format:%cD"
 #endif
 

Cheers

Graham

[johnwhitestar]

The developer is suggesting us to make the upgrade directly to PPC v.0.10, what do you think?

[gjhiggins]

The developer is suggesting us to make the upgrade directly to PPC v.0.10, what do you think?

Sensible suggestion. Not only is the new PoSTemperature mechanism worth having but migrating to an older version of PPC would be suboptimal - basically kicking the can down the road - because an eventual upgrade to PPC v10 is inevitable, surely?

Cheers

Graham

[d5000]

From me also support. The changelog says that it rebases to Bitcoin 0.20 and removes centralized checkpoint support (we already removed). See here. This would basically mean that we'd have really modern code and would immensely facilitate later upgrades.

However, afaik it's still in RC state. So maybe he should wait until the final release is out?

[johnwhitestar]

The developer is suggesting us to make the upgrade directly to PPC v.0.10, what do you think?

Sensible suggestion. Not only is the new PoSTemperature mechanism worth having but migrating to an older version of PPC would be suboptimal - basically kicking the can down the road - because an eventual upgrade to PPC v10 is inevitable, surely?

Cheers

Graham

My only concern is that the v0.10 is still in pre-release phase, so or we need them to reach the "Stable" status before we go on with upgrade or we can release our rc version and then go on implementing their updates later.

What I don't like about waiting for their stable release is that I need the PoD token to be launched as soon as possible and I prefer to go on paying the developer in order for him to get paid for the whole work as soon as he is able to deliver the code (in order to avoid for him the indefinite time of final payment).

What I don't like in case we decide to go on applying the PPC updates later is that it makes our investment undefined as I'll need to ask the developer to go on with the patches and so I don't know in advance what will be the final cost.

[d5000]

Protocol switch time ... These values are using to check whether the given transaction is subject to the specified protocol.

This is Peercoin-only code and refers to switches in Peercoin protocol for 0.4/0.5, these were changes not considered appropriate for Slimcoin but the switch was retained in case the community changed its collective mind on the relevance of the changes.

Basically, this means these switches can be deleted completely? I've looked a bit into the code but I lack proper understanding what changes in the Peercoin protocol they're referring to. 

My only concern is that the v0.10 is still in pre-release phase, so or we need them to reach the "Stable" status before we go on with upgrade or we can release our rc version and then go on implementing their updates later.

Yep, is understandable. I have looked at the Peercoin repo and from the first RC version to the final release there are generally between 1 and 5 months of time (0.5 took 6 months). However, the 0.10 change, as far as I understand it, is much less complicated than the previous 0.8 and 0.9 changes. 0.8 was the "big update" from BTC 0.8 to 0.16 and took 5 months from RC1 to the final release, and 0.9 introduced the protocol changes like the new PoS and took 3 months.

0.10 RC1 is now 17 days old so I guess 2-3 months from now would be the time one would have to expect, but maybe not much more.

[johnwhitestar]

0.10 RC1 is now 17 days old so I guess 2-3 months from now would be the time one would have to expect, but maybe not much more.

Considering we are already using a kind of pre-release version maybe beginning from a more modern pre-release version would make sense.


EDIT: We've just agreed with the developer, that he'll release the RC version based on PPC 0.10 and then he'll go on patching it until PPC releases the stable version. Then we'll have an additional 2 month of assistance included just in case any bug or issue occurs.

[gjhiggins]

Basically, this means these switches can be deleted completely? I've looked a bit into the code but I lack proper understanding what changes in the Peercoin protocol they're referring to. 

Yes, pretty much so, they pertain to serial changes to the Peercoin ledger contents, tx validations/limits/fees mainly, so will be irrelevant to the Slimcoin ledger legacy.

Cheers

Graham

[gjhiggins]

The developer has reached the first step we've agreed with him upon and released the document in which he is analyzing SLM code. Please let me know what do you think.

One other thing that might be useful, pre-computed EXT/bip32 keys for Slimcoin - as committed to Ian Coleman's BIP39 repos: https://github.com/iancoleman/bip39/blob/863eee8ed754e4aebd5059b712deb4fca8709c27/src/js/bitcoinjs-extensions.js#L153

Cheers

Graham