Slimcoin | First Proof of Burn currency | Decentralized Web

[johnwhitestar]

If there is no one against the swap maybe we can consider it, since it will cost less and apparently will simplify the work of the developer?

My objection is that the older blockchain has a higher intersect value and objectively speaking it will be another coin, but we'll keep the brand.

[1713983236]

1713983236

[1713983236]

1713983236

[1713983236]

1713983236

[d5000]

You are totally right, I also would slightly prefer a regular update, or a soft/hard fork keeping the old blockchain. But I'm aware of the possible complications for the developer, so I would not oppose a swap if it's done the right way (preserving the PoB "power" of every user, and most important: no developer premine).

[gavrilo77]

You are totally right, I also would slightly prefer a regular update, or a soft/hard fork keeping the old blockchain. But I'm aware of the possible complications for the developer, so I would not oppose a swap if it's done the right way (preserving the PoB "power" of every user, and most important: no developer premine).

I agree with you, but still it is hard to believe that developer will do free of cost. I would give for instance 25000 SLM as donation, and if he can make new miner he can always implement some % of dev fee as well.

[johnwhitestar]

You are totally right, I also would slightly prefer a regular update, or a soft/hard fork keeping the old blockchain. But I'm aware of the possible complications for the developer, so I would not oppose a swap if it's done the right way (preserving the PoB "power" of every user, and most important: no developer premine).

I agree with you, but still it is hard to believe that developer will do free of cost. I would give for instance 25000 SLM as donation, and if he can make new miner he can always implement some % of dev fee as well.

He is not making it for free, I'm anticipating the cost hoping to recover it later on using the PoD tokens we were working on in the last months.

If we keep the old blockchain it would cost us 15% more than doing the upgrade on the new blockchain. From my prospective the difference of the cost is not that big as the advantage of being an old coin, but by other hand the potential simplification of the code might be critical for the future survival of SLM
I'd also consider that the old blockchain means usually a time tested code, but I don't know how relevant is it in case of such a heavy upgrade.
Another aspect to consider is the premine. Even when the premine is done for the sake of swap it let a bit of negative impression. In any case SLM is probably on its bottom, so any potentially negative impression can be irrelevant at this point.  

[d5000]

the potential simplification of the code might be critical for the future survival of SLM

I have thought a bit about that.

In reality, we can get rid of most of the old code even preserving the old blockchain. Because all what the developer has to care about is that the protocol works exactly as in the old version.

That means basically: He must care that all constants that are enforced by the old code (e.g. the minimum fee, the structure of a SLM address, the structure of the communication between nodes, etc.) has to be exactly like in the old coin.

It does however not mean that he has to preserve the old code for that. He can use the new Peercoin code, but change or check all these constants if they're still compatible. What he will have to preserve, however, is the Proof of Burn part and other Slimcoin-specific additions, but that would also be the case if a swap is carried out.

Yep, this can be more time-consuming to identify all these constants, but it doesn't mean that Slimcoin has to carry tons of old code with it. And for a dev familiar with Bitcoin code it shouldn't be a problem.

I'd also consider that the old blockchain means usually a time tested code, but I don't know how relevant is it in case of such a heavy upgrade.

I think the value here is mostly symbolic, as it's not really the case that newer blockchains can be attacked easier or something alike. But yes, a blockchain that already is running for 6+ years would certainly add value.

Another aspect to consider is the premine. Even when the premine is done for the sake of swap it let a bit of negative impression. In any case SLM is probably on its bottom, so any potentially negative impression can be irrelevant at this point.  

I tend to agree here. I would certainly prefer the "cleanliness" of the current no-premine distribution. But if the swap is carried out completely transparently then it should not affect this "cleanliness" too much. A coin like ETH doesn't seem to have been really affected by its premine.

Now one thing I remembered in the case we allow a swap or carry out a fork (hard or soft): Peercoin changed the OP_RETURN length (this is basically the quantity of data you can put into a transaction output) from 80 to 256 bytes. Taking into account the PoD token workings, it would be preferrable to follow this change. It would require probably a hard or soft fork or swap however, because that means that a rule would be loosened (this means usually a hard fork, but there may be possibilities to implement that with a soft fork too).

[johnwhitestar]

The developer has let me know that he thinks it makes more sense for us to keep the old blockchain and he is ready to go on working on it.
He told me also that the change of OP_RETURN will be possible to implement.

EDIT: of course we are speaking about a hardfork here.

[d5000]

The developer has let me know that he thinks it makes more sense for us to keep the old blockchain and he is ready to go on working on it.
He told me also that the change of OP_RETURN will be possible to implement.

Fine! I think also that is the better option.

Now it would be interesting if it would be better to first update the new codebase without a fork, and then organize the hard fork changing the parameters that would make the protocol incompatible, or to do both things at the same time?

As I wrote in an earlier post there are some more parameters which would be interesting to change if there is consensus in the community. Mainly the minimum transaction fee and the minimum amount for an output of any type. Maybe it would be useful to discuss them here.

There is also a Hardfork wishlist in the wiki which could be used as a base for that discussion. The problem here is that the item listed as highest priority (change of the PoS/PoB/PoW block proportion) would need a lot of testing to find out the ideal block proportion (I guess that would take at least some months).

So in the case it is better to combine the hardfork with the code update, this change should be done later, while the "easier" changes (OP_RETURN size, minimum fee and minimum output amount, maybe also PoS reward change to 1-2%) should be done together with the code update.

I could set up a thread with a poll about the parameters which could be changed in the hardfork (here or at Reddit - or are polls also possible in Discord?).

[johnwhitestar]

The issue is that we have a very low participation of people in the discussion, so basically we are forced to take decisions by ourselves.
But an attempt to create a discussion should be done.
I think we'll end up with making the small changes you mentioned so once we have a more active community we can discuss something more to implement.
The more active community will mean also more resources for the people's ideas. For the moment I'm taking quite a high risk to finance the upgrade and I'd prefer to keep the cost as it is for the moment. So for me it would be fine if we just make the upgrade in order for us to be able to build the PoD token up it. But probably the "small changes" won't change the cost of upgrade.

[d5000]

I think we'll end up with making the small changes you mentioned so once we have a more active community we can discuss something more to implement.

The small changes can be made by anyone with minimal knowledge of the code, including me. So the developer wouldn't have to bother with that. But if he includes the change for the same money it would be obviously best.

I think the following changes are uncontroversial, as nobody has opposed them so far in any of the discussion channels (they are basically anti-spam features inherited by the old Peercoin code, but spam hasn't been a problem and wouldn't be because a fee market can always develop if there is shortage of space in the blocks):
- Reduce the minimum amount for an output from 0.01 SLM to 1 "slimtoshi" (=> the minimal amount)
- Reduce the mimimum transaction fee from 0.01 SLM to 0.0001 SLM per kB
- The minimum absolute transaction fee which is currently also 0.01 SLM, could be abolished totally, so for a 200 byte transaction you would pay 0.00002 SLM. I am however not sure how this is organized, will have to take a look into the code.
- Increase the length of OP_RETURN messages from 80 to 256 259 bytes (see below).

The PoS reward instead is something which should be discussed in the community as it can be controversial, so this could be saved for a later hard fork, maybe when we decide to implement the "hard cap" for PoS blocks I proposed in the wiki and on Discord.

PS: The variables corresponding to the changes in my list (I highlighted the variables and the values which would correspond to the changes proposed above):

in main.h:
Minimum transaction fee: MIN_TX_FEE and MIN_RELAY_TX_FEE. Both are currently CENT, which is 0.01 SLM or 10000 slimtoshi.

- A minimal fee of 0.0001 per kB would result in a MIN_TX_FEE value of 100.
-MIN_RELAY_TX_FEE is the minimum transaction fee to be relayed, which should be also 100. (Edit: corrected an error in the earlier version of this post)
- Minimum output value: MIN_TXOUT_AMOUNT. Should be changed to 1. (1 "slimtoshi")

for OP_RETURN:
- MAX_OP_RETURN_RELAY in script.h (in the new Peercoin version, it's in scripts/standard.h) . It was recently increased by gjhiggins to 100, so it's not longer 80. I have seen that Peercoin changed it to 259 bytes, not 256, because it seems so after taking into account the opcode itself 256 bytes of data would remain. I think as Slimcoin will use Peerassets heavily it should follow this value, so it should also be set to 259.

Edit: I just saw that Peercoin 0.7+ uses additionally a fee called PERKB_TX_FEE. This seems to be the fee per kB, while the other two (MIN_TX_FEE and MIN_RELAY_TX_FEE) are "absolute" minimum numbers. I have also thought a bit about possible DoS/spam attacks. So perhaps the following values would be good:

PERKB_TX_FEE = 1000
MIN_TX_FEE = 100 (so all transactions with less than 100 bytes would pay this value. Normal transactions are however 120+ bytes large, most 180+)
MIN_RELAY_TX_FEE = 100

[gavrilo77]

I would not wait some more people for discussion. jw and d5 you guys take a lead and everything is better than to stay where we are with SLM.   

[johnwhitestar]

I would not wait some more people for discussion. jw and d5 you guys take a lead and everything is better than to stay where we are with SLM.  

Thank you for you trust!  

The small changes can be made by anyone with minimal knowledge of the code...

So we need:
- PERKB_TX_FEE = 1000
- MIN_TX_FEE = 100
- MIN_RELAY_TX_FEE = 100
-  MAX_OP_RETURN_RELAY in script.h = 259
- minimum amount for an output = 0.00000001 (instead of 0.01 SLM)
Right?

About PoS reward I'd say 10%/y inflation is huge and considering the PoB and PoW the SLM inflation is probably following Zimbabwe model.
So by one hand I'd reduce it even to 1%, as we don't have any Community participation even if we have such a heavy inflation.
By other hand I'm thinking about the goals I have in mind for the PoD token that will require a continuous flow of donations. In this context the 10%/y of PoS may make sense for someone who wants to participate in PoB tokens production and uses the following strategy:
- buying SLMs
- producing SLMs using PoS
- "donating" the minted SLMs using PoD
This approach would give him the possibility to become a donor forever or at least until SLM doesn't reach its hardcap.
Of course the huge inflation would be still there but at least it would make some sense.
What do you think?

[d5000]

So we need:
- PERKB_TX_FEE = 1000
- MIN_TX_FEE = 100
- MIN_RELAY_TX_FEE = 100
-  MAX_OP_RETURN_RELAY in script.h = 259

Yep. Addition: The TX fee variables are in amount.h in Peercoin 0.9, no longer in main.h.

- minimum amount for an output = 0.00000001 (instead of 0.01 SLM)

In Slimcoin, the "Satoshi" is 0.000001 SLM, not 0.00000001 like in Bitcoin. This was also inherited from Peercoin, probably because they feared problems because of the continuous inflation.

However, the variables are all measured in "satoshis". So the minimum possible amount for MIN_TXOUT_AMOUNT is 1. Which was was I proposed above. This would be the same behaviour as in Bitcoin, although Bitcoin doesn't use this variable anymore.

About inflation: I think the 10%/year is still not high enough to be really harmful, so we can leave it in place for a while. To get these 10%, in Slimcoin's current PoS model you must be actively staking, so if not 100% of the coin owners are staking then we'll never see a 10% increase of the coin supply per year. But for the long term I like the low-inflation model of Peercoin more.

What I just remembered, however, is that in Peercoin 0.9 the inflation became more constant because they changed the inflation model in the sense that the rewards are increased when few people stake. This means that if SLM adopts this model, some will be able to get significantly more PoS rewards than 10% per year.

Adopting that model (instead of re-introducing Slimcoin's old "PoSv1" model) would break compatibility with the old blockchain, so it's also a hard-forking change. So it may be an opportunity to lower it if we anyway have to hard fork. Maybe 2%/year or 3%/year could be a good "intermediate" proposal, which would allow to re-invest some PoS coins via donations.

[johnwhitestar]

So the updated list of our requests for this hardfork:

- PERKB_TX_FEE = 1000
- MIN_TX_FEE in amount.h = 100
- MIN_RELAY_TX_FEE = 100
- MAX_OP_RETURN_RELAY in standard.h = 259
- MIN_TXOUT_AMOUNT = 1
- PoS rewards distribution model of PPC 0.9
Is it correct?

What I just remembered, however, is that in Peercoin 0.9 the inflation became more constant because they changed the inflation model in the sense that the rewards are increased when few people stake. This means that if SLM adopts this model, some will be able to get significantly more PoS rewards than 10% per year.

Isn't it a kind of hardcap?  

I've included this model in our upgrade list because I think it's very interesting, but I'd say we need to change from 10% to no more than 3%, maybe 2% would be even better.

EDIT: I'd like to ask you does the PPC model you described mean that the competing wallets will tend to be always on, providing in this way additional nodes for the network?

[gavrilo77]

I've included this model in our upgrade list because I think it's very interesting, but I'd say we need to change from 10% to no more than 3%, maybe 2% would be even better.

I would agree with this. We have likely seen in the past that PoS was overtaking PoB and PoW. Personally, it was frustrating. 

[johnwhitestar]

I've included this model in our upgrade list because I think it's very interesting, but I'd say we need to change from 10% to no more than 3%, maybe 2% would be even better.

I would agree with this. We have likely seen in the past that PoS was overtaking PoB and PoW. Personally, it was frustrating. 

I don't have this experience, so I'd like to ask you, maybe you feel that 1% would even better?

[gavrilo77]

I've included this model in our upgrade list because I think it's very interesting, but I'd say we need to change from 10% to no more than 3%, maybe 2% would be even better.

I would agree with this. We have likely seen in the past that PoS was overtaking PoB and PoW. Personally, it was frustrating. 

I don't have this experience, so I'd like to ask you, maybe you feel that 1% would even better?

Have to be pleased all parties. Many people are attracted with PoS as well, because at the moment very few people experienced PoB. So i think as well 2 or 3% of PoS would be fine. But yes for some period of time most of the blocks went to PoS. So imagine if someone burn SLM (nonreturnable) how will feel if cant get reward. Especially in cases of smaller amount of burnt SLM. People might loose faith  
BTW, somwhere in thread i posted how many SLM i earned in 4 years i think trough PoB. It is more than good   

[johnwhitestar]

 
BTW, somwhere in thread i posted how many SLM i earned in 4 years i think trough PoB. It is more than good  

Yes I remember we did that calculation and the result was quite interesting, but PoB becomes more interesting than Dash-like Masternode only after some year and the Burner needs to have its computer connected all the time, which means costs that probably PoBing is not covering, and the collateral is lost forever, that's probably the reason why PoB hasn't become popular.

[gavrilo77]

 
BTW, somwhere in thread i posted how many SLM i earned in 4 years i think trough PoB. It is more than good  

Yes I remember we did that calculation and the result was quite interesting, but PoB becomes more interesting than Dash-like Masternode only after some year and the Burner needs to have its computer connected all the time, which means costs that probably PoBing is not covering, and the collateral is lost forever, that's probably the reason why PoB hasn't become popular.

If could be possible regarding to PoB to make possibility that people have choice for instance after 80 or 90% of Decayed burnt SLM to withdraw the balance, as with the small amount left, reward will come like never, especially if diif is big. But that would nightmare to implement i believe.

[johnwhitestar]

If could be possible regarding to PoB to make possibility that people have choice for instance after 80 or 90% of Decayed burnt SLM to withdraw the balance, as with the small amount left, reward will come like never, especially if diif is big. But that would nightmare to implement i believe.

I think, it would be super-great if there were a possibility to withdraw not yet decayed coins. In context of the virtual mining metaphor it would be as if the miner is selling his equipment at the market price. It would also help us to compete better with Dash's-like Masternodes.

I remember we've spoken about it on Discord and seems like it would require a lot of effort for the possible developer, so maybe we need to postpone this implementation at least until the PoD token is launched.

[gavrilo77]

If could be possible regarding to PoB to make possibility that people have choice for instance after 80 or 90% of Decayed burnt SLM to withdraw the balance, as with the small amount left, reward will come like never, especially if diif is big. But that would nightmare to implement i believe.

I think, it would be super-great if there were a possibility to withdraw not yet decayed coins. In context of the virtual mining metaphor it would be as if the miner is selling his equipment at the market price. It would also help us to compete better with Dash's-like Masternodes.

I remember we've spoken about it on Discord and seems like it would require a lot of effort for the possible developer, so maybe we need to postpone this implementation at least until the PoD token is launched.

Or to withdraw not decayed coins, with fee of 20% or so, these coins automatically to go to PoD