i didn't realize that rfc11 is getting included in 0.9. this proposal i have voiced my objection before. it will distablize the pos system as security may swing a lot during the course of a year. in the worse case there will be no pos security

the reasoning regarding timing attack in the rfc is flawed. compound interest is irrelevant there.

to be frank, this is 100x worse than a constant minting that incurres so-called nothing@stake, which would never be a problem in my opinion, unlike rfc-11(edited)

Seriously, this rfc should not be rushed in at all. If this must be considered then you should consider a safer alternative that do not respect the 1% cap

@Nagalim, opinions?

I'm not sure I understand why this would cause pos security to suffer or swing. The average is over the entire year, so fluctuations with a period of 1 year will not affect the reward given.

The reason why compounding interest is mentioned is because a 1% compounding interest is negligible but a 5% compounding interest is certainly not. But the argument does not depend on that.

If the participation is below 20%, the system behaves exactly the same as it currently does, so I'm not sure how you can make the leap to 'no pos security' in the extreme, unless you also believe that the current protocol has no pos security.(edited)

The issue with a constant mint reward is not N@S, it is stake grind. When this is imposed on the Peercoin PoS model, you wind up with what was done in the peershares model, where a particular stake size is chosen and the wallet immediately splits all outputs down to that stake size.

The result is heavy chain bloat anytime a minter moves coins and a minimum limit on how many coins are needed to participate.

If we are not respecting the 1% cap, then I am unsure what the problem we are trying to solve is. The formulation of this solution was based around how to fix the total PoS inflation at a particular % of supply.

“Seriously, this rfc should not be rushed in at all.” The RFC is almost 1.5 years old. No one has provided a good reason during this time why it shouldn’t be done, in fact only mostly good reasons why it should be done, so we started to move forward with it. I don’t see where you think we are rushing it.

If you have a good argument though, now is the time to make it heard.

He expressed concerns and did not feel they were adequately resolved. I can understand that, but it is difficult to resolve concerns without a proper line of communication, or proper documentation of the concerns.

I personally would be minting blocks whether the reward is high or low. I imagine many others would as well. For many, it’s not just about earning rewards, but keeping the network secure. So I fail to see how there would ever be a scenario where there would be no PoS security.

If we assume that sk is making the same argument as otzi, one possible solution would be to use pos difficulty directly. So the MA would be on day weight instead of coindays, and the adjustment would be proportional to the difficulty divided by the MA (I'd have to think a little bit about the exact math)(edited)

This would make the adjustment very responsive to the pos difficulty while still maintaining the MA that results in the 1%/year

The math here is taken from the previous calculations of the number of participating coins that glfv calculated back in 2015

coins = (difficulty * 2^32) / (dayweight * 600)

This would mostly preserve the work backpacker has been doing, because dayweight is simply coinage/coins

This would also somewhat obfuscate the process, and would be harder to game as it would include both a rapid change (difficulty) and a slow change (dayweight MA)

The biggest issue I can come up with here would be if someone were to try to manipulate the pos difficulty to oscillate on a short time scale by minting, holding off, minting, holding off.

This would be possible because the pos difficulty will not change until after the block is found. If it were possible to use the adjusted pos difficulty after the block were found, that would solve that issue

I'm not sure if that is easy or hard. It is a question of whether the difficulty of the tip of the chain is used, or the difficulty on the preceding block.

If the reward is included in the hash for finding the block, then you would have to use the difficulty of the preceding block and intentionally causing difficulty fluctuations could be an attack

@sunnyking i would love to hear that worst-case scenario explained in more detail

@sunnyking rfc11 is made specifically to promote constant minting and not hop on and off whenever it pleases minter, are you saying we shouldn't mint constantly?

@sunnyking do you think that constant mint reward would be more secure than trying to keep inflation in check?

it's clearly not constant mining as far as i understand, it's variable rate capped at 5%. Let's say the rate dropped to 2%. if most minters decide this rate is too low, they stop minting and wait for the rate to increase, then pos security is gone. that's an unacceptable real threat in my opinion.(edited)

iirc, in the original proposal, the reward rate can vary between 1% to 5%, to maintain an overall annual inflation of 1% on money supply. so if 50% hold long term and participate in minting, the rate must at some point drop below 2% to compensate.

under alternatives>'difficulty/dayweight implementation'

this would cause the adjustment to be directly related to the difficulty. If the minters drop out to try to increase the adjustment, it will very quickly rise and the first one that decides to jump back on gets the reward. This essentially punishes everyone else who waits and rewards those that stay in.

As I see it, the issue @sunnyking is referring to is related to the difference in time intervals between the year-long average and the PoS difficulty. This alternative implementation would remove that difference in time intervals by relating the reward directly to the PoS difficulty.

I also edited the drawbacks to remove the bit about compounding interest and replace it with the runaway timing attack that @sunnyking is referencing

so it is capped at 5%?

(it wouldnt go beyond 5% if almost nobody is minting? to keep the annual inflation of the total coinsupply between certain levels)

it follows the same rules as the original proposal, same bounds

it is harder to see, but it is still using the same concept of mintingcoins/supply being the participation rate

so the annual inflation should still be aimed at 1%/year

its essentially the same proposal, but uses a different calculation of 'coins minting', preferring to use the more day-to-day sensitive PoS difficulty as opposed to a year-long average

we are looking for some incentive to make it interesting to mint more, right?

in my opinion, the entire point of rfc11 is to aim the pos interest at 1%/year, instead of having a 1%/year cieling like it currently is

and SK is worried about strategic minters who only mint when it is maximum profitable with this algo?

from, everybody who mints gets 1% annually, to the coin supply increases by 1% every year, divided among all minters? (wich a cap at 5%)

more stable inflation, less stable minting?

it should wind up with more stable minting, if we do it right

if we base it off pos difficulty, it is hard to argue that paying more during lower difficulty times will result in lower difficulty

that is like pow reward, it goes down when difficulty goes up

right, very similar behavior

except this is linear rather than exponential

which makes sense, because pow diff is an exponential concept based on moore's law, while pos is linear(ish) based on inflation

but that's regardless, the idea is that you can calculate the number of coins minting using the PoS difficulty

if you want more minting i think it makes sense to pay more when more are minting , else you make them compete for it until there is some equilibrium

the idea of rfc11 is that the total number of coins up for grabs is constant. with more people minting there are fewer coins per person, but the same total number of coins.

the current paradigm is that each person gets an equal amount, so the total number of coins increases when more people are minting

(only when they mint)

with the ceiling

sunny is saying that there is a lag between the adjustment to the coins being offered and the number of minters, so minters would sit out and wait until the adjustment equilibrates, which is bad for difficulty

if we pin it to difficulty, then that lag is removed, and it becomes essentially impossible to game the system in that way

cant we make it a function of the pos difficulty like a multiplier? say difficulty is very low , the posreward eh inflation number gets multiplied by a low number (near 0), and when almost everybody is minting it would be more close to 1

i guess it would make everything like how it is now

under that paradigm, when the difficulty is low no one has any motivation to mint and so the difficulty goes lower, which gives less motivation to mint

why?

the more minters the higher the reward

that gives motivation

most people, when treating minting like an investment, say something like "I will hold and mint my coins if the reward for me is at least 2%/year"

if the rate goes below that, they drop out and sell their coins

so the rate goes lower, which means more people drop out

so that's the opposite paradigm from what we want

also, the numbers don't work out at all that way

is that logical?

yes, that is how economics of bond yields works

idk if they would drop out and sell their coins(edited)

either the reward matters for pos participation or it doesnt

if the reward matters, then a higher reward draws more participation

if it doesnt, then why even offer a reward at all?

what sunny is saying, is that a changing reward can cause people to wait for the reward to get higher before minting, which is a reasonable action

even if it's higher than what they would normally mint on, they could hold out for an even higher reward, that is logical

i think the reward matters , and saying, you get more when pos difficulty is higher gives incentive to participate methinks, but you think it would make people drop out and sell their coins (when diff is too low)

yes, it would cause a snowball effect

when the difficulty is high, people would buy and mint

when the difficulty is low, people would sell

that is the opposite behavior from what we are going for

we want to reward the ones that stick around more when everyone else walks away

dont forget you need more coins with higher diff

(unless pooled minting)

not really, as long as you can wait till your coins mint you get reward proportional to the number of coins you own

above a certain threshold, the wait time is negligible

well.. you can wait forever at some point

or negligible

if you have 1,000 ppc you can mint within about 60 days

if you have 10,000 ppc you can mint within about 45 days

thats not that big of a difference

anyway, the point is that we want to reward the people that continue minting when difficulty is low

when pos diff is low enough the small wallets start to mint more (if they are online)

the size of the output is neither here nor there because the reward is proportional to the size

the question is if we can motivate minters to participate when the pos difficulty is low

and offering more reward should do that

so how to solve the problem that minters go offline when the reward drops

that is the question also i guess

its ok if minters go offline when the difficulty is high

with the 30 day wait to mint, it is unlikely that minters will respond to fluctuations on a week-to-week basis, which the fluctuations in pos difficulty mostly are

if the difficulty goes up and stays up, some minters might drop out, it's true

but conversely, if the difficulty goes down and stays down, minters will come online

you could think about lowering the 30 day limit (when pos dif is low) to motivate minting

but idk if it is a good idea

eh, i'm not a fan of that

messes with the security model too much

one of the key points here is that the average dayweight and the coinsupply can be used to normalize the pos difficulty

hypothetically the actual pos difficulty number should be increasing with time if we had constant % participation, because the coinsupply goes up with time

we haven't actually seen that, but in the last couple of years it seems as though participation has gone down some

@sunnyking so do you think that variable rate is bad no matter how it is implemented or @Nagalim 's alternative proposal of using difficulty/dayweight is a step in the right direction?

To summarize some discussions had offline, I dont think the difficulty based algorithm will work because of the high amount of non-continuous minters. Essentially, the pos difficulty does not equilibrate fast enough to account for these, so the total inflation would not be properly accounted for. Ultimately, we have about 5-10% minting that contributes to security and 10-40% minting that claims profit and leaves. This makes any attempt to adjust the inflation without a year-long average very difficult/impossible. That same year-long average will always contribute to a snowball effect with opportunistic minters the way sunny describes.

So the original proposal still seems to be the best solution to a constant inflation problem, but it does have the issues that sunny is worried about.

A constant reward solution would require removing coinage and timestamps

A blanket increase of pos reward to something like 3% would achieve something similar to what we want without introducing additional attack vectors, but the messaging would get messed up because technically the maximum reward could be up to 3%

I was thinking about rewarding continues minting but is problematic methinks, because of splits and whatnot

“What sunny is saying, is that a changing reward can cause people to wait for the reward to get higher before minting, which is a reasonable action. Even if it's higher than what they would normally mint on, they could hold out for an even higher reward, that is logical.” So people would be incentivized to stop minting when the reward is low to build up their coinage for a better chance of minting when the reward is high? Do I have that right? Is that the concern here? Is this taking into consideration those who will mint continuously, regardless of the reward changes? That includes myself and others too I’m sure.(edited)

we can't rely on altruism

the solution i will write up tomorrow is a 20:80 split between static reward and variable reward

in short, the static portion punishes people who withhold their stake and the variable reward punishes the stake grind

because they are both normalized to a certain percent of the total supply, they can be implemented together without loss of integrity or the 1% max inflation

the highest expected reward will be achieved when minters keep their clients on continuously and allow the standard split that is already built into the client

Looking forward to reading it.

haven't given it a second over yet, but i think it should be pretty close

I went for 0.75 instead of 0.8, because I thought about it some and that seems like a more appropriate number

basically, 1/4 of the reward is static, while 3/4 is dynamic

hm, maybe i should use the word 'dynamicsubsidy' instead of 'variablesubsidy'

you can explore the thought process that leads to 0.75 in the 'alternatives' section

@sunnyking can you read ?

and comment

I messaged Sunny to check out the updated RFC.

What about a mixture of constant reward plus fixed rate. Maybe that can alleviate some of the concerns with pure constant reward previously. Also I don't see why changing fixed rate need much work, the development should be minimal. However it does encourage continual participation as the constant reward component would turn into very high effective rate (this needs some calculation) when participation drops to very low levels(edited)

As to inflation concerns, I think we can safely raise the fixed rate to 2% while still claiming the annual inflation under 1%

So this solution essentially does that. It combines static with coinday rewards.

I'm glad we came to a similar conclusion on the best direction for the protocol

as far as the development, as far as I understand it is already completed

there are two differences though a) no track moneysupply b) no dynamic rate adjustment

as to development is done, the proposal wasn't in agreement before it gets implemented, that's not a good practice regarding important protocol changes. also, i usually refer to both initial dev cost and long term maintenance cost. if we decide to change things again the complexity needs to be carried in the codebase forever

This had been in the development cycle for about a year, so we had assumed that opinions had been expressed. I understand your desire for something simpler, but I'm still unclear on what the objections to the chosen complexity there are. Let's focus on the money supply tracking. What are your objections to tracking the money supply as an input to the reward calculation?

i think i have mentioned this before. the money supply statistics wasn't considered part of the protocol, it was in the initial release for user convenience as peercoin was the first cryptocurrency without cap. after having proper explorers capable of tracking money supply it is supposedly deprecated and can be removed from core

i do see you accounting this as the proposal's complexity in rfc based on my earlier feedback, which is good

as to variable rate, it's likely more critical, i think it has a good chance to weaken peercoin's security instead of strengthening it

Can you expand on why? With the static portion the concern of discontinuous minting should not be as poignant.

Are your objections to it based on the design or on the added complexity in the protocol?

Maybe, but it's hard to say. The tendency is still there

a) no track moneysupply <- this is complexity concern b) no dynamic rate adjustment <- this is both security concern and complexity concern

What we found by exploring the difficulty vrs the coindays consumed in minting is that there are two kinds of minters, those that mint continuously and those that mint periodically. The periodic minters provide nearly no benefit to the chain security, so the question of security comes down to whether any changes we make will increase or decrease the prevalence of continuous minters.

it seems to me that using 1 coin + 2% coinage rate is a much simplified version of your proposal without it's drawbacks(edited)

We believe that by including the money supply and the adjustment in the calculation, we can keep the static and dynamic portions relevant into the future.

If we fix the static portion to 1 coin, it will eventually become irrelevant as the coin supply grows, and we will need to increase it with time.

Similarly, if we leave out an adjustment then what we choose for the static portion can easily overwhelm the coindays portion and could easily result in mass splitting of outputs, which gives a large benefit to those that do it and forces people who want to be relevant to do the same, thereby bloating the utxo table and making it very difficult to switch between minting and transacting

if that's the concern you can make it 2 coins it should cover many years

If it were 2 coins, I would split all my coins into very small outputs and never transact with them.

This creates a large separation between those that transact and those that mint, separating the users from the validators.

This was seen in peershares, where going from minter to transactor cost huge fees

but see, you could also find 25% to be too high or too low for that matter

so i don't see why that's a problem for the simpler change

we can just set it to 1 coin and forget it for 5 years

If you look at the math, the 25%:75% numbers are fairly well balanced. The only way we can compare them is by making them both proportional to the coin supply

I'd rather not update the reward system every 5 years though, and the numbers you are picking seem somewhat arbitrary

it's not arbitrary, 1 coin kinda fits your 25% choice

But that is with a ~3x modifier on the coindays portion, considering current continuous and periodic minter rats

We dont know how this protocol change will affect participation, so making a code change that is sensitive to those changes is the more thorough way to do it

If making the static reward 2 coins causes continuous participation to increase from 20% to 40%, then we could see an inflation rate of 3 or 4%

You would have to change the protocol based on participation and coin supply discontinuously, creating a lot of little protocol changes instead of one comprehensive one

only consider pos inflation, why 3% or 4%

Coindays would still contribute 0.5%-1% (depending on if we went with the 1% or 2% options) because coinday participation is at around 40 or 50% currently

Ok, probably not 4%

But my point is that we would need to change the reward over time based on participation rates and money supply. So why not bake them in and promise a constant total inflation?

see, one of the problems is that we are too fixated on a guaranteed exact 1% overall inflation, that gets you into this variable rate design, while ignoring the security risks with variable rate

I dont think we're ignoring them, I think we are considering their impact on the continuous minter. We are trying to avoid the continuous minter either turning off their node or splitting their outputs to unreasonably small amounts.

It's a balancing act

close to 1% should be alright, no need to be strictly 1% annual inflation

splitting coins is actually a good thing for overall security

Splitting down to dust values is not

dust doesn't help

It causes extreme inertia for the minter vrs transactor

Dust is the best solution if the static reward greatly exceeds the dynamic reward

In peershares, all minters split down to dust values

to reasonable smaller coinbags that gives you better chance of blocking is good to the overall security

Because the reward was 100% static

We want people to use the standard split in the client, which is aimed at minting every 90 days

Which means we need a balance between static and dynamic rewards. If we dont encode a continuous adjustment, then we need to update it on a periodic basis

Which is a nightmare for consensus and maintaining the code

that's an exaggeration, i still think this proposal is unnecessarily expensive

i mean, 1 coin constant can last 5 years no problem, even if the team wants to fine tune it down the road

anyway, i have to leave for today, we can continue this discussion tomorrow

The constant portion is only different by whether or not we use the money supply variable, which I am unconvinced has significant baggage attached

The variable portion is the more dramatic form of keeping the two components balanced, which it seems you object to more

Thank you for your input on this, I would still like to discuss it further

Be well

To give some perspective on this, we could hardcode the current supply and update it every time we release a client, like the hard coded checkpoints.

To me, this seems harder to maintain than a supply calculation, but I am willing to go along with it for arguments sake.

That should satisfy your first concern.

By using a constant in place of the variable even in the dynamic component, it would also approximate the necessary balance between the two components (though the coindays consumption fraction is theoretically continuous, the approximation wouldn't be too bad if we update it every protocol release on 1 or 2 year basis)

There has been a significant decrease in periodic participation since btc-e dropped out, so our modifier is more like 4x (25%) at the moment, with 10% continuous participation (calculated from pos difficulty). These participation numbers are very low, lower than they have ever been, which is part of why we want to increase the reward.

A 2%+1 solution is similar quantitatively to what the proposal would pick (3%+1.24). The coindays portion is lower, however, so it would favor splitting among the current minters, and the overall inflation is lower. I think you can see the issues if we were to go to something like a 3%+1.25 solution (namely that increased participation would overestimate the inflation rate), so I think we can focus on how underestimating the dynamic portion in favor of the static portion causes issues with on-chain velocity.(edited)

I dont know whether you experienced the peershares implementation much, but the static reward made it very infeasible to transition from minter to transactor, specifically because of the splitting function. It became unwieldy to work with individual minting outputs if you had significant stake. What's more, the client splitting function was much more aggressive. These are things we would need deal with in order to avoid destroying the user experience if we went to a model where the dominant portion of the reward were static.

But ultimately, this would greatly increase the boundary between transactor/user (people who would much rather have reasonably sized outputs in order to select their inputs and avoid large fees) and minter (people who need to split their outputs down to small amounts in order to maximize the number of blocks they mint)

Yes, splitting is good for chain security directly because it increases block creation probability. But do you see how it is bad for chain velocity because it greatly separates minter from user? On another level, do you see how separating users from validators leads right back to the issues surrounding third party miners validating transactions on a PoW chain?

One of the great benefits of Peercoin is that people who use the coin can become people who validate the coin just by holding the coin for some time. If we now make it so that in order to be competitive they must split their outputs into very small amounts before waiting 90 days, that will greatly fracture the landscape of who is a minter and who is a user of the coin.

The 3%+1.24 balance makes it so that the ideal output is around 70 ppc. A static-heavy protocol adjustment could decrease that ideal output substantially.(edited)

As a side note, without the 1-year cap on coindays, the absolute best output size to maximize pos rewards is literally dust (0.01 ppc).

(That is, assuming any static component)

The 1-year cap on coindays works with the 3%+1.24 balance to target outputs that mint between 90 and 365 days as the maximal reward solution, which is what we are going for here.(edited)

If we maintain the 1-year coindays cap, I could go for 3%+1.25, which would be around 1% inflation right now, though it could be almost any number between 0 and 3.25% in the future. It would flush down the toilet nearly everything we've said about Peercoin's economic strategy for the last year, as well as our development expenses for the past 3 months, but at least we might be able to agree on it.(edited)

“It would flush down the toilet nearly everything we've said about Peercoin's economic strategy for the last year” That doesn’t sound very pleasant. I still need to read the above discussion though.

From what I read here, @sunnyking still disagrees with the concept and not so much about this specific implementation. In my opinion going with hardcoded reward then chaning it in the future is a hard no.

I am still pro nagalim's proposal.

I dont like that the hard coded version cant adjust. When there are more periodic minters the dynamic reward should decrease and when everyone is splitting excessively the dynamic reward should be more tantalizing. I dont think we can accomplish that paradigm with hard coded values.

a) limit coin age period to max 1 year, makes sense b) you have not fully addressed the security concern regarding dynamic rate adjustment, there is no benefit other than an argument that then this part of the protocol will never need to be adjusted again, which I highly doubt given the complexity of the design and i don't see anyone else claiming to fully understand this design and the arguments that it is somehow optimal other than from Nagalim c) yes you can speed up the built in default split d) I am still of the opinion that we should pick the constants and not worry too much about optimization. even in the proposed dynamic design, there are still many constants picked, for example the 1 year limit, the ratio between fixed reward and rate reward, and so on. if too obsessed with optimization, wouldn't you soon be revisiting these constants anyway, which defeats the only claimed benefit of the dynamic design. even the annual inflation rate is a chosen constant in other coins. For example, v systems has fixed reward currently at around 5% annual inflation. Is 1% more optimal than 5%? I don't think one can make such an argument. There is pros and cons, that's all.

@everyone we want to have a team meeting on Saturday at 2:30 PM UTC to discuss more about RFC 11. Me, Sunny, Peerchemist and Backpacker seem to be good with this time. Is it good for others here?

alright ready when you are

topic is rfc11

* the security concerns about adopting it * explore simplified alternatives which bring the same effect

so far, we have agreed on a 1 year coinday limit, a split between coindays-based reward and static-reward, and even roughly the intended ratio between those two parts

the points of contention are 1. Using a 'moneysupply' index in the reward calculation and 2. Having a dynamic portion of the reward that can be potentially gamed in any way

the first is a question of complexity, the second is about security and complexity

day before yesterday me, sk and backpacker had a meeting

our conclusion was that using moneysupply is fine

so we can drop that point, unless you want to go over it again

so my response to the complexity arguments, if you'll allow me to still make it, is that we can stand a little bit of extra complexity if it gets people talking

i think that part is pretty safe as we are already tracking money supply

if it is something that will be good for the chain, and isn't too outlandish, but generates a lot more interest, I consider it a win

so i think most of the contention, in that case, comes down specifically to the dynamic component

i agree that we shouldn't be scared to go with more complicated solutions as long as it achieves result we are striving for, in my opinion the main reason for rfc11 is increasing minter participation

we should go about the two issues one by one

money supply issue

it's quite different still as it was not part of protocol, can be deprecated before

also i want to bring up another concern here that proof-of-stake used to be verifiable by just looking at the coinstake and it's previous tx(edited)

Is that an issue or a feature?

it's something that needs to be kept in mind

@sunnyking you mean minted value could be verified from looking at time alone

what's the current status of peercoin's light weight solution

> Used to be does not have to limit us

@sunnyking what is a "light weight solution"?

light wallet?

There has been some work on a peerassets wallet, but I'm not sure that's light

well, we can't do SPV with POS, and while we could verify mint value, we still needed to know whether coinstake modifier is correct and that's hard to do without having total knowledge of the chain up to that point

@sunnyking like SPV, it cant work with our PoS(edited)

so new functionality that we have implemented does not really change the fact that you still need to know everything up to that block in order to verify blocks(edited)

but let's focus on the issue at hand

this is the issue at hand

in order to allow SPV we have to change the POS to not require transaction table

that can be done by either making a reward completely static

the exact SPV of bitcoin of course can't work

it doesn't mean it can't work in a modified form

we have no strict need for SPV and lightwallets are being worked on so I dont see this is as a topic for today

it's related topic

what lightwallets are being worked on

none that i know of

I find this insulting

That is being worked on by Saeveritt and Buckkets.

correct

ok, let me rephrase my answer, none of the wallets that i know of actually do ANY validation of blocks nor receive data about blockchain from anything but an explorer api

please correct me if i am wrong

i'd love to be wrong about it too

correct

otherwise you could name cointoolkit a light wallet

which i am pretty sure isn't

but polling from API is industry standard way of doing this so I see no problems with it(edited)

the most popular "light" wallets out there like myetherwallet is handling it like that so why can't we

why cant you poll it straight from some node?(edited)

we'll get SPV when we figure out how to do PoS in a better way

well, I think that's where @sunnyking was getting us to

if we are to go directly to fully static rewards, we won't have a need for transaction table to verify blocks

that's what blackcoin/qtum do

static block rewards

and no coinage

well, there's that issue with ticket validation in QTUM which is not SPV compatible afaik

not sure what blackcoin do, whether it has SPV

it's dead so it does not have SPV

but I think it can be done over there

once money supply is put into the protocol, it seems to me that SPV variation is no longer possible or will have major security holes

light wallet can still have a copy of the utxo table

and know the money supply

it won't be very light if it has to store 1m of utxos

light(er) wallet

do we really need SPV clients anyway, in a world where LN exists?

that seems to me like a perfect mobile ready solution anyway

aren't we dead coin until we have SPV client?

we're dead coin anyway But why is this related to SPV clients?

we can do SPV client which does no verification, many out there do it like that

qtum, navcoin, stratis, pivx...

anyway can we get back on topic

SPV is not the topic

it's something you need to weigh against choices

yes, it's definitely an argument against using money supply in validation of pos rewards

but we can't do SPV anyway

it's not like we're culling SPV here, we already can't do SPV

we can't do as light as bitcoin does, that is

yes

how come? so, it isnt just like polling data from random nodes?

no, it's based on header chain and merkle proofs

i mean, it does pull data from a set of peers, but much more advanced than just that

can we get to topic please I can't stay here forever

here is the thing, the complaint about having a fixed reward component of say 1 coin, is that we need to periodically change it as money supply keeps growing

but my view has been that it's acceptable as peercoin is a low inflation coin now, we won't need to touch it again for 5 years

which we won't do as it's not proper code of conduct. p2p decentralized network must be set in a way that their behaviour is deterministic

and it has to be able to live on should something happen to all of us at once, ie if all of us here just dissapear right now peercoin must live on

I'm concerned with the future of consensus If we select random numbers for protocol behavior

that's not convincing, 1% was a 'random number'

the behavior should be reliable/predictable imo

it can be made predictable

1% is a random constant number

It is completely different if you intend on changing it periodically

1% is not a random number, it may have been random for you but every economist will tell you that 1-3% is a "golden" inflation rate

it's a really good inflation number and for sake of peercoin as sound money / store of value I'd keep it(edited)

When we increase the reward discontinuously and periodically, it will eventually encourage rational actors to withhold stake before forks to get the most blocks minter right after the fork

so long as you have a policy limit about changing constant reward, it should be fine. the policy is still based on a target of 1% overall pos inflation

I cant accept that, I put veto on this idea

so, it has to be fixed reward for some reason, it cant be a function?

@sunnyking following from what Peerchemist said above about golden inflation, this text is ripped straight from our Peercoin Primer economics video... “Bitcoin is sometimes referred to as “digital gold” because its total supply cannot be controlled by centralized institutions. But in contrast to actual gold, Bitcoin has a predetermined fixed-supply of 21 million coins, so it doesn’t fully represent the asset it is being compared to. Gold produces a little inflation from the small amount that is mined each year and history shows that a moderate inflation rate helps to discourage hoarding and incentivise use of a currency. The fundamental problem that cryptocurrency seeks to fix, therefore, is not inflation itself, but inflation that is excessive, centrally controlled, and open to manipulation. The solution is not zero inflation, but inflation that is limited and decentralized. This is the principle at the heart of Peercoin’s economic model, which allows for a 1% annual inflation of the coin supply, with no hard cap, through its proof of stake minting.”

function is what @Nagalim proposes @Irritant

Just to backup the idea that 1% is not a random number to us.

yes, so what is the problem with a function

1. Security, 2. Conplexity

Security is that if people think they can get more reward tomorrow than today, they will halt their minter

The static portion is designed specifically to make that not worth the attempt

Complexity is a similar argument to the nmoneysupply argument, which is that people need to track variables on the chain

from my point of view, constant reward component is to provide variable effective apy for minters, and it's not limited to 5%, it can go up high depending on participation

that is, with constant reward component provides for variable rate already, you don't need the variable part which brings in security issues

it can be considered a random reward compared to their stake, tho large minters still get more blocks

i also favored an all constant reward proposal before

i think eventually the team may find out that all constant is even better

could you base the constant on a function still? so it gets automatically renewed every x years?

based on the average inflation and target inflation

probably could be gamed, idk

all constant without any coinage consideration?

All constant will clearly result in 100% stake grind

There will be a giant barrier to entry for minters, and a horribly bloated utxo table

As everyone will split outputs down to 0.01 ppc

It's exactly what happened in Nu

i know ppl may be of this opinion right now. but splitting to 0.01 does not give further advantage, you only gain advantage to the 10's

inflation doesnt come from PoS now does it? there are 52K blocks a year approximately, you would need to give every block at least 5 PPC to reach 1% inflation

if my calculations are correct

If I have 10 coins, if I split into 1000 utxo's I will increase the number of blocks I find in a year

no, that's not true

The 90 day ramp up is what makes it true

With a single output, once I mint I am down for about 90 days

With many outputs, that 90 day wait is fractionalized

i am not here today to push all constant reward alternative

i am only saying that have an initial constant reward component is better than before

I think it is very important to understand the dangers of an all constant reward

Indeed, it is at the heart of understanding why a dynamic and static portion in tandem and in relatable amounts is vital

you should demonstrate how splitting to 0.01 give you advantage. give numbers to expected blocking interval

if only coin days are counted and not amount of coins...(edited)

if it were an issue, it's already here, attackers won't care how much reward they get out of it

If a single 10ppc output mints x%/year after waiting 90 days, then it will mint approximately every (90+year/(x*numblocks)) days

A minter with 1000 0.01 outputs will mint an output x/1000 chance

So they mint every year/x instead of (90+year/x)

If there is no penalty at all for splitting (because the year limit on coinage doesnt matter at all with a constant reward), then there is reward for splitting down to dust but no penalty

Which means a rational minter will split down to dust

if that's an issue, you can limit the coinstake inputs to only those 90 days old

The solution peershares used was to greatly reduce the 90 day limit, impose automatic wallet software to auto split down to dust, and to greatly raise what is considered minting dust

Limiting coinstake inputs to 90 days does nothing to prevent this, and in fact exacerbates it

The issue is that when one dust output mints, the other dust outputs are still over 90 days and maintain their mint probability

With a single output, it is reset every time you find a block

that's assuming you can find a second block

The proposed rfc11 balances these concerns in a comprehensive way to aim for an ideal behavior where the minters outputs are such a size as to mint once a year

You have eternity to try, so we are talking statistical analysis

but once you are down to 10's you are not supposed to find blocks that frequent

If you have a thousand of outputs that are 0.01, then you have the same snapshot chance to find a block as a single output with 10

But when the single output finds a block, it loses 90 days ramping back up, while the stake grinder has no such limitation

This is the same argument if we talk about a single 1000 ppc output vrs 100,000 0.01 ppc outputs, except that the 30 day vrs 90 day ramp up actually helps the matter a little

But it's still better to split down to dust even if you have 10million ppc, assuming constant reward

The goal behavior is to have output sizes that are reasonable

that's not the right argument, we are comparing 10 coin output and 0.01 coin

if you have a million coins, you split to 10 coin output, i think it's enough

10 coins vrs 1000x 0.01 coins gives favor to the splitter, I've shown that

further split has no advantage

It has a 90 day advantage every block found

If the 10 pcc output would find a block every 3 years, that is almost 10% advantage

we should ask for a tx fee for staking transactions

No

I mean we could, I suppose

coinstake does have tx fee

But it causes splitting stakes to have a cost

We want stake splits, just not excessively

@Nagalim if we limit mint reward to one year it won't be advantage, right?

Not if we eliminate coindays and use a static reward

tx fee would protect against the dust methinks

There is no real cost to taking 3 years to mint, aside from compounding interest

We want splitting down to the level where they mint each output once a year

That is what rfc11 achieves

can you say 1% is a static number?

A dynamic/constant split with a maximum coinage of 1 year achieves what we want, but it is best to automate the protocol to maintain a constant ratio

if you make the ramp 365 days and the reward 1%

If the reward is %, then it is coindays based and my argument goes a different way

A constant reward is not coindays based

ok

so @sunnyking was saying in previous meeting that rfc11's idea of static+dynamic reward can be simplified to static+current reward, so we add, let's say 1ppc as static + current coinage based reward(edited)

Yes, that is ok, but it implies we need to update it on a semi-regular manner

not current, i am fine with limiting coinage to 1 year and raise reward rate to 2%(edited)

only if you want to maintain that mythical 1% inflation target of pos component

Because the ratio of constant minters to periodic minters matters in this

well, current with minor(er) adjustments

If there is a large amount of periodic minters vrs continuous minters, we should lower the coinage reward, and vice versa.

That is what the dynamic portion seeks to do

Periodic minters tend to be opportunistic, continuous minters tend to split as much as is profitable. That's the situation I working with

question boils down to do we want to try to maintain this 1% target for POS part, considering that pow rewards have 3-4 % inflation?

I think it's more than that. That is part of it, but the periodic vrs continuous argument is also part of it

Ideally we want those two behaviors to converge

So if what is opportunistically profitable is to continuous mint with a reasonable splitting, then we have done our job

I dont care so much about the total inflation as I do the ratio between static and dynamic components

Using the total inflation to normalize the two components just has an added benefit of easily being normalized to a total inflation rate

In fact, I'd rather 1.25 ppc + 3% at the current protocol numbers. Though 1 ppc+2% is also fine

But my issue is with whether it will be fine a year from now

If this protocol change causes more people to continuous mint over periodic, then my evaluation will change

i thought your ratio was a fixed 25%-75%, now you claim that this is dynamic too?

That's my problem with proposals like this, I want it to run without intervention just like present system ran without intervention for years

The 25/75 is fixed. The dynamic portion is the coindays part

So the coindays part responds to periodic minters

While the static portion has the greatest effect on the continuous minters

then how can you claim that you can deal with changing behavior of minters

If minters switch from periodic to continuous, the difficulty will go up and they will get fewer static rewards comparatively

If minters drop out of periodic, the dynamic portion will increase

If minters drop out of continuous or switch to periodic, the static reward will be more attractive

If minters join as periodic, the dynamic rewards will decrease

Ideally, by pushing on all sides, the periodic and continuous behaviors merge into an ideal continuous client behavior. In reality, without cold minting there will always be periodic minters

that's what i was saying, the constant reward component already does it, you don't need to make rate part dynamic to have it

If you dont have the dynamic part, then the coindays component will not change if a periodic minter is added to the system

So there will be no pressure to switch from periodic to continuous

constant reward component pressures minter to be continuous

Yes, but the system was already in equilibrium and we take someone from 'not minting' to 'periodic minting'. When that happens, we want to put economic pressure on all the other periodic minters to switch to continuous

what you were saying is not continuous, but a behavior that turns the minter on and off based on the rate reward component

The static component incentivizes continuous minting, not on-off behavior

and that's exactly why it's a security concern

The protocol is a balance, it would behave very similarly to your 2%+1 proposal, but would adjust with the times

yes that's my point. you are using it to cover up the security issue but you can't prove it's now completely gone

I am not trying to prove there isnt an issue, I am trying to prove that it is mitigated

i have been saying this for a while, there is no good argument in favor of dynamic rate reward component, other than tracking an exact 1% overall inflation

The argument is for an automatically adjusting consensus protocol

One that responds to the network on a faster time scale than client updates

i think ppl tends to mix up the 2 issues at hand

Right now, we want a high coindays component

In a year, we may want a lower one

But we cant really lower people's rewards, it's not politically tenable

what do you say about a fixed 2% rate component and a constant reward component tracking money supply

So we will increase the fixed portion more to get back in line

This will ultimately cause inflation

If we agree that we can change the static portion with client updates but the 2% is fixed, then we will be responding to temporary network variables with permanent reward increases

no to hotpatching economics

Linking the static component to the money supply is better, if we decide to pick something and stick with it

How about 3%+0.25×moneysupply

I believe your proposal came out to something around 2%+0.2xmoneysupply

you don't have to track money supply in that case, you can track the 365-day total of rate reward component

this would also solve the SPV trouble

Can you explain more?

divide the 365-day sum of past rate reward by 50000

Would that average the moneysupply out over the last year?

no, it doesn't need money supply. only look at all coinstakes, not blocks

So that's the total PoS reward over the last year?

sort, but needs to transit to only the rated component

We are doing something very similar to that for the dynamic component

not similar in terms of security

Rated component is the static portion?

no, the 2% or 3% portion

Very similar in terms of complexity, I think

So we are adding up all the input coindays and comparing it to the money supply for the rated component

tracking that is much better than tracking money supply

You want to add up the rewards instead

you don't have to add up, you can have a moving sum and subtract from it

We initially used the rewards, but using a feedback loop on the rewards causes a lot of complicated convergence issues

so two data sets, one for rate reward, one for moving sum

you can't just look at coinstake to determine reward, you also need to look into previous transaction to find out how much was created(edited)

yes but protocol already does that in validation

what i mean is that when you sum the outputs it's not the mint amount

I'm not sure how your solution avoids the same issues of security

how to figure out how much was minted?

without looking up nvalue of input

when you do validation you already does the calculation, just keep it in an index

fixed rate we know no security issue

But arent you changing the rate?

Is your proposal something like: 2%+f(sumoverrewards)

no, it doesn't change the reward rate. effective rate is not the same as reward rate

it's that you are changing reward rate that is dangerous

What's the effective rate?

@sunnyking i was referring to that part

of course full blown client can do all this stuff

both fixed reward rate and fixed reward have been reasonable demonstrated to be secure in my opinion

but variable reward rate has not

What does the variable you are calculating by summing rewards over the last year do?

effective rate is the minter's APY

the sum replaces money supply as the anchor for the constant reward component, so it keeps up with inflation

So the constant now responds to network conditions

not network condition per se, it only responds to the rated reward component

Wouldn't that measure active minters, not the full supply?

Right

So if the number of periodic minters goes down, the reward for continuous minting goes down

That might cause a snowball effect in times of low pos difficukty

that's why you want to average over 1 year

It seems to have the opposite effect from what you want though

snowball is an exageration, has peercoin pos difficulty ever dropped precipitously

We want to increase it a lot ideally, so we could see a precipitous return to current behavior under certain conditions

Also, this type of feedback still has the same issue you are avoiding

Because if people think they can get a better deal on the static component tomorrow than today, they will turn off and wait for tomorrow

Especially with big outputs below the 90 day mark

The security behavior is completely different from your current proposal

I don't think it's really comparable

I'm seeing exactly the same security flaw, that it becomes speculative

if you miss this one you lose it

if you have a next block, then you could have earned on both blocks

Not with the same output. If you have only one output and a choice between a block today or one tomorrow, and think the reward is higher tomorrow, why wouldn't you hold back?

I think it is a step in the right direction conceptually, as it is the same basic construct, but I'm not sold on the behavior of what you've proposed

ok, then how about just adjust it every year in the protocol

based on the previous year rated reward

I would rather the moneysupply-based one

no to economics hotpatches

it's automatic, like bitcoin's halving

it's not hotpatches

It's hard to think that far ahead, especially with PoW inflation variable the way it is

PoW will certanly continue grinding to zero

but we cant know how fast

Also depends on price

and I like the poW mechanics, I would not touch them

ok, how about this, not exactly moneysupply, we don't count destruction in the anchored money supply

Does that help implementation a lot?

it helps with the SPV situation

By destruction you mean burned PPC?

Yah

yeah the fee destruction

I think I could roll with that

Ok, so we are ok with: %+moneysupplywithoutfees

How does not counting burned PPC help avoid future compatibility problems with SPV wallets?

So is everyone ok with using the moneysupply without the fees?

It will result in a little higher overall inflation, but probably not significantly

I dont think there is a way to abuse it, because attacking it involve burning all your coins

Without the fees?

without counting fee destruction that is

Using money supply without fees included

Itll end up being slightly higher than the real moneysupply

How is there a different number for total coins in supply, isn't it just all the coins

@Nagalim I did not read the full transcript, can you tell me where does this number come from?

where to source it from?

Sunny, can you answer sentinels question?(edited)

counting fee destruction requires processing all tx

that will preclude any light weight protocol

Without fee destruction, you can just process the coinbase and coinstake txns of each block

With fee destruction, you have to look deeper into the txns in the block

true, ok

but you still have to process all txns to know what's spent

Isn't it just the final number of coins what is left in the address?

otherwise you can't verify that this pos block is not built on spent utxo

not sure i understand what you solve by ignoring fees destroyed

but i had to interrupt to take care of childrens dinner

so i might have missed something

The spv client is trying to validate new blocks without downloading the chain?

Is that the situation?

spv client verifies pow blocks without getting the data using header info and merkleroots

so it essentially maintains a chain of pow headers

without transaction data

yes SPV only need headers of blocks

bitcoin SPV anyway

not sure if there is alternative

And you're saying that building blocks off of outputs in pos means you have to look into the blocks to avoid spent outputs

Paperwallet that checks blockexplorer plus cointoolkit

So spv is untenable

@backpacker yeah SPV might have been a lost cause

as we've said at the start

it's not worth chasing

unfortunately i can't think of making it work in current POS implementation

Do SPV wallets have a future anyway? Peerchemist mentioned earlier that Lightning wallets may become the standard, or something similar to that.

i've been trying to solve this problem for quite some time )

let's just kick that bucket down the road until we get a brand new PoS idea

and focus on LN as mobile solution for now as god intended

So we're back to moneysupply tracking

so, to summarise, do we all agree that mixture of static/dynamic rewards is a way forward(edited)

in that case i can concede that money supply to be used as baseline for constant reward component

Ok, cool, can we get a concession from peerchemist to drop the dynamic portion and stick with a constant rate?

not dynamic, constant + (fixed) rated reward

Right

yes, defining dynamic as being current coinage based

I am looking to peerchemist for that

but limited to 1 year

Right

So something like 2%+0.2×supply or 3%+0.25xsupply

so how much of difference will this actually make for the minters?

The 3% option is very close to the current dynamics

The 2% favors a higher continuous minting, but lower overall rewards and smaller splitting

Also, you have to consider that people will look at the biggest possible number, which is the %

They will see 3% or 2% as the inflation rate

They won't be right, of course, but such is marketing

Sorry, it is confusing to me. We are still tracking 1% annual POS inflation in this proposal or no?

No, we are talking about abandoning the dynamic adjustment

@Nagalim that's my fear

Which would allow inflation to fluctuate

people will read this as "peercoin is going for 3%" inflation

That's one of the benefits of the 2% number

but ok we'll think on how to give them this number later on

On the other hand, the 3% number looks better on profits

And we can just show the total coin inflation using our tools

so this proposal vs the original rfc11: * somewhat simpler to implement * less rewards for established minter base * no dynamics at all, so security aspect is happy * overall we don't change much from what how it already is

and we still have dynamic PoS inflation

The individual economics are changed a lot

Promotes pos diff

Some will see a 400% increase in rewards

But yes, still dynamic overall inflation

And more of it

But still regulated within ~1-3%

with PoW that could sometime go over 5%

Does this make it possible for larger minters to earn a higher percentage than others? Whereas now that is impossible?

actually it will always be at about 5%

Sentinel, it's better for that than current protocol

PC, it will likely be ~1% pos inflation at current network numbers

So large minters won’t be able to pull ahead of smaller ones, in terms of percentage of ownership?

The opposite, continuous minting is rewarded

If they are both continuous, it's a wash

i do like the simplicity of this, even though it would ruin the testnet again

And our branding a little, but watever

There was mention of ending fee destruction earlier, is that the case, or are we keeping fee destruction?

I like the rfc11 as it simply says that "network gives out 1% inflation a year (on all coins), go mint to get your share of it"(edited)

Robert, we are keeping fee distruction, that wasnt it and we moved away from the that idea(edited)

well, we could always explain that we are adjusting the parameters to stay true to peercoin %1 target

thats a very simple message and it blends well with all our PR

I'm fine with either at this point. As long as moneysupply is the anchor for the constant portion, I'm fine with either constant or adjusted rate portion(edited)

ok I have a proposition

So peerchemist, you are most concerned about the PR aspect of the higher inflation?

Ok, let's hear it

We get a new RFC, about limiting coinage to 1y

as that kinda seems detached and established from this now

and should go in new release anyway

second, we get a new RFC about this proposal so the public can read it

and yes, I do not like possibility of having a higher inflation

Ok, can we settle on a set of numbers?

There are two proposals on the table, one with 2%+0.2supply and one with 3%+0.25supply

I am for the one that does not make drastic periodic increases on the inflation

They both wont

One is smaller, and will likely be below 1% total when rolled out

The other has a bigger max but will work with current network numbers better. Note that current network participation is historically low

that is because we are at the bottom of bear cycle, which will turn around real soon

and we'll go back to some historic average

have that in mind

i prefer 3% + 0.25 supply

PoS systems have a problem with this, bear cycles are as much as boosted as bull cycles

The best we've done is 50% participation, which works with the 2% option

in bear stakers drop out as PoS reward cant keep up with actual price decline

so price goes further down, snowballs

in bull stakers pile on as they can get both PoS reward and the actual price increase

so price snowballs up

couldnt we make some kind of wave function that adjusts between 1% and 5%

No, that kind of thing is what sunny doesnt like

oh okay

many things are dynamic in peercoin tho

So we have 2 votes for 3% and 1 vote for 2%

Are we only abandoning dynamic because Sunny doesn’t agree, or because you were convinced it won’t work? Or there is a lack of evidence dynamic works like Sunny said earlier?(edited)

Me and backpacker for 3%, sunny for 2%. Please note that I am fine with either as long as we pick one and stick with it

I am in camp 2% as well

Sunny has a point about dynamic, though I think it is mitigated. Still, it is best to achieve consensus

And as pc says, we are making an alternative rfc

i am actually fine with either 2% or 3%. if the overall inflation overshoots past 1% i am ok with it

Ok, sentinel and irritant?

the number is less important than that it stays that way for ever

I am afraid of the inflation not matching all the marketing we just created. That was a lot of work.

Ok, backpacker and peerchemist, can you present arguments for either side?

So if we are afraid about the PR, the 2% option is probably better

@Sentinelrv if that's a big concern, go for 2%

i think changing something needs to have impact, leaving it at 2% is so miniscule I'm not sure it's worth the effort

our pow rewards are so much more

I am also in the 3% camp for the big change in pos difficulty

@Nagalim perhaps run us some simulations

if we want to increase pos diff which we need to improve security, we need bigger numbers

so now that 3% will yield benefits to existing pool of stakers right

Do you need simulations? It's a pretty simple adjustment

and lift to inflation to ... what?

i missed why did we move away from 1%

@backpacker bigger numbers are road to hell as they just make the PnD worse

The 3% option comes out to about 1% current pos inflation

The 2% currently would be about 0.7%

no, pow inflation being 4 times more than pos is road to hell

pos minters are less likely to dump

PoW is fine, without PoW being the way it is this thing would be long forgotten

@sunnyking have you had a chance to look at pow change(edited)

@Nagalim 0.7% now is still better than what we do currently

Yes, of course it is

This is a straight increase in reward

we want people to mint, giving them incentive is what we wanted to achieve

it's more than % in protocol

it's liquidity, it's "number go up" on exchange too

dont forget that

it's balance of all these things

my opinion is that current rfc11 does not go far enough with cap of 5%

just voicing my opinion for the record

I'll go ahead and write it as 2% with a 3% alternative.

so we should base the posreward also on the difficulty?

I know it may seem trivial, but I think it's a big difference between 2 and 3%

I dont like the difficulty-based reward option

I have explained why in the alternatives section of rfc11

@Nagalim can I go over this one more time, just so you have it in mind when thinking about proposals like this

Sure

in bear stakers drop out as PoS reward cant keep up with actual price decline so price goes further down, snowballs in bull stakers pile on as they can get both PoS reward and the actual price increase, so price snowballs up

so now, we have deficit of stakers as price went down for far too long

those who are just getting on train now will reap most of rewards

eventually supply will dry up and we'll have a bubble

I totally understand that we are on the low end of the curve. I think its instructive to think about both the trough and the peak

now I wonder how will this proposal play out in bubble conditions

I still would prefer higher inflation for higher pos difficulty

in bubble you have: 1) more participation 2) less PoW inflation

I was thinking about aiming rfc11 at 2% instead of 1%

in bear: 1) less participation 2) more PoW inflation

we did make some conclusions today

and we can sleep on it(edited)

I'm gonna need some help in the forum explaining the change of course

We can say it is undecided, but I dont want to look unilateral

@Nagalim ok we handle community after new rfc drafts

let have that 1y coinage cutoff first

that goes into v0.9 for sure

You want 2 new RFCs then?

yes

Ok

what date should we pick for hardfork

changes proposed are trivial compared what i had to do for current rfc11

@backpacker I'd stay with 21st

28th maybe

but def May

As I follow it, the two RFCs proposals will be: one with 2% + 0.2 supply - and one with 3% + 0.25 supply. Is that right?

No, sorry, the two proposals are one to settle on the 1-year coinage limitation

And one to propose 2%+0.2 with the 3%+0.25 as an alternative in the text(edited)

ok

may I leave

I'll be on phone, just @ me if you need me

I'm concerned about how we come to a conclusion in that timeframe

im making borsjtsj for the kids

@Nagalim before the HF?

Yah

it's imperative we HF in May and first half of June latest

What's your read on how much you'll resist the new rfc as compared to the current one?

I can answer you on that once I think on it a bit, but yes I am maybe your biggest showstopper

The new one takes rfc11 and removes the adjustment parameter

That's pretty much it

It fixes it to 2%

Technically, it corresponds with approx. a 2.67 or a 2.13 adjustment parameter, depending on what you are measuring

That's like a 40% participation

If we ended up going with the original thinking the risks are mitigated, but it turns out Sunny was right, do you believe it would be difficult to fork away to this newer version you’re talking about? Of course it would be better if we didn’t have to do that, but I’m just wondering if it would be possible to easily switch if we determined that the dynamic portion did cause gaming after seeing it operate for a time in the wild.(edited)

now it is like this: if 100% minter participation, than 1% inflation , right?

Right

It shouldnt be too hard forking from the new rfc to rfc11

But the other direction is very hard

That's what sunny is saying about complexity, in some ways

I'm still not clear on the expected new inflation rate. Up above, it was said that the 2%+0.2 option comes to 0.7% POS inflation - and one with 3%+0.25 comes to 1% POS inflation. Is that still the case?

That is the case for current network numbers

Hmm, so we definitely have to be sure then if it’s not easy to revert.

But in the hypothetical future, it can be up to its maximum

Which is 2.2% and 3.25%

testing on testnet

Those numbers would require 100% continuous minter participation though, so unlikely

100% from here is not much really

relatively speaking

100% of everyone minting I mean

100% is utopia

testnet needed adjustment of 15 afair

So a practical impossibility

yes that is impossible

as we've lost like half of all peercoins already

Which is more of an argument for the 3%

Still, it is difficult to predict how minter participation will change in the future. If it increases, annual PoS Inflation could still end up being beyond 1%. That ruins our messaging.(edited)

The 2%+0.2 model basically will never be above 1% practically speaking(edited)

now it will never reach 1%

the pos inflation is supposed to be counterd by txfee burning wasnt it?

That wasnt a real argument, just a happenstance coincidence

ah

Txfee has always been much less than inflation

will go up

Anything is possible

Is a 1% inflation (for the whole supply) still going to be a minimum?

(if peercoin succeeds)

no, i think we are moving to 2% or 3%

No, we were aiming for constant inflation, but sunny blocked consensus for that

and it is already more because of the powreward inflation

the 1% was the posinflation only

So we are talking about relaxing the total inflation rules to best pick protocol behavior

btw i am not sure that money supply was tracked as solidly as protocol parameter before. it needs to be made sure that it gets handled correctly during reorganizations

it's been too long, though if it goes with each block like modifier does, it should be fine

@sunnyking its stored as part of each block on the disk afaik

@Nagalim I think you said with current participation, if you chose 3% + 0.25 that comes to around 1% PoS inflation. When you say 1% here you are saying 1% of our total supply, so around 261k PPC. Is that correct? Not an exact amount, but it comes near it?

Yah, but that changes if minters join because of the change in reward

Also, like pc said, we're at the bottom of the curve

So if minter participation drops further it will go below 1% and if it increases it could go as high as 3%, which is impossible because 100% of coins can’t be minted with, utopia as was said earlier.

Yah, the 3% model would be between 1 and 2% mostly

The 2% model is between 0.75% and 1.25%

Those are very approx numbers

So, 2.2% and 3.25% are the theoretical maximum POS inflation rates, and the minimum POS inflation rates are the 0.7% and 1% referred to, earlier? But because, a fraction of PPC has been lost, all figures might be lower. Is that it in a nutshell?(edited)

The minimums are technically 0.2% and 0.25%

Not only is a fraction lost, but most coin holders dont mint

To get 0.2%, you'd have to have literally no one minting, again a technical impossibility

Maybe we could make that work in our messaging. I guess total annual inflation doesn’t have to be exactly 1% to be considered limited inflation , but somewhere in the range between 1% and 3%. However problem is this doesn’t take into account annual PoW inflation, which will drive the total even higher.

Right, the marketing gets a bit more abstract, but doesnt completely get thrown away

I don't mind the POW inflation, as that is treated separately, and will decline. But the original idea was to ensure we allow for 1% POS inflation. It sounds like it might dip beneath this.(edited)

Oh, it is definitely a relaxation of a key parameter, which is why it will get a separate rfc

But sunny brought up concerns over any protocol using coinage that changes rewards in a predictable manner

Such a restriction casts a wide net over protocols that attempt to fix inflation while still using coinage(edited)

We could go farther, 10%+1xsupply

But I think that would be a hard sell

A great discussion. I need to step away from the keyboard shortly, but look foward to reading the RFC.

@Nagalim i agree with this

that would definitely increase minter participation

and considering that less than quarter of coins are minting, would result in numbers still less than pow inflation

I think it makes sense to start with something smaller first and see how minter participation reacts to it. It can then be adjusted higher if necessary, based on the results. We also have to keep in mind as Peerchemist said that participation is lower in bear markets and higher in bull markets. So we don't want to make the mistake of setting a higher percentage because participation is currently low, but then we drastically overshoot our target inflation range once the market turns around and participation increases.(edited)

no we should adjust as little times as possible imo(edited)

we cant keep messing with it

I would rather not adjust either, but it seems difficult to predict what will happen to the participation level and how it will affect annual PoS inflation. What if we guess wrong and we're way too low or too high?

if we can do it in a way people wont think that we will adjust whenever we feel like it would be better

The goal is to only do it once

No hotpatching economics, as pc says

Yeah, I agree with that. Still, I think it will be difficult to predict what will happen, especially with market prices affecting the motivation level of minters to participate or not.(edited)

Right, that was a lot to digest. Took an hour to get through this Anyway problem to solve is increasing minter participating and making it more fair. Given the loss of coins to date and inflation I would support the 3% option. Better fix it once and good (no hot patching indeed) . Risk on high inflation on POS seems low given that it would be very unlikely we would have more than 50% of all coins minting at the same time in the foreseeable future. So PoS inflation would stay below 2% which on itself is ok.

PoW inflation which comes on top of that appears to be less controlled and more of a concern imo. May not be an immediate risk with low uptake at the moment, but pump and dump behaviour with increasing uptake may increase this from what I understand from the protocol. That would result in a relative high inflationary coin as difficulty can not always keep up with it.

Perhaps good for another topic.

Anyway, it is good to see these discussions. Good thinking. Unfortunately they are happening in the middle of the night for me, joys of being on the other side of the world. Not that I would have been able to actively contribute to it anyway.

I do also think 3% might be the better number to choose.

think about effects of picking that number in 10 years(edited)

@peerchemist Good point, but that is not easy. We might be in a world with strong deflation as a standard. I think you can at best look ahead a few years. I would rather reduce or even stop PoW or increase the transaction cost in a few years to reduce inflation if that continues to be an issue.(edited)

Just some quick thoughts

https://www.linkedin.com/pulse/money-credit-debt-ray-dalio/?published=t Onrelated to the discussion, this article describes why currencies never last(inflation) and a new bretton woods event will come to announce a new world currency

also https://github.com/Nagalim/rfcs/blob/master/text/0017-coinage-limit/0017-coinage-limit.md

RFC17 is fine, you can ask for merge

i would prefer not to use fractional numbers as constants

I'm just using what was used previously in Peercoin code

We can change that if you'd prefer

I'm pretty sure it is used to account for leap years

((365 * 33) + 8)/33 days = ‭365,2424242424242‬

should we add correction for the earth rotation slowdown?

I'm just using what we've been using in Peercoin since the start

it seems to be correct, since we have every 4 years a leap year

(this is because one day is 23 hours, 56 minutes)

so we have 1460 minutes too much a year, 24,333 hrs .. err doesnt this mean we need a leap year every year , idk if my calculations are correct(edited)

nevermind

MoneySupply, is that currently at ~26,176,357.40 PPC if I understand it correctly?

bitinfocharts says 25,875,909 PPC cmc says 26,177,839 PPC

i think we passed 26M so i think you're right

dont have access to my node now

cryptoid has good numbers, over 26M yea

0.2x is about 1 ppc/block, 0.25x is about 1.25 ppc/block

I'm curious what people thing about the logic of 1:10 that I mention in the alternatives section

A ratio of 0.1 to 0.2 implies keeping between 1:10 and 1:5

This was one of the more interesting realizations I had. It doesnt apply to rfc11 because that one adjusts with participation. So it is somewhat of a unique paradigm to the fixed value choices.

i very much doubt that we'll get more minters in terms of absolute amounts, considering the btce fiasco

so i am worried about chosen numbers as they are way too low

we'll get more minters as in number of people minting, but never the same amount as before

argument that we are at the bottom does not cut it, lost peercoins will not be recovered

Why is that an argument to increase reward? If it cannot stimulate additional minting, then what is the goal of increasing it?

we can and will stimulate additional minters, but we can't expect to return to previous amounts minting

unless we increase pos rewards to the point where still active coins increase their stake

To be fair, the 3%+0.25 option would be extremely similar to what rfc11 would roll out with

So you are making the argument that we should go for it and increase pos inflation well above 1% target

i am of the opinion that pos minters are more important than pow miners and economics should reflect that

and matching inflation rate of pos to pow is the minimum we can do, better even to reverse it make pos rewards 4 times more than pow

but that's my personal opinion

i have strange ideas, like changing pow algo to primecoins

I did reflect that opinion in the alternatives section

I am still for the 3%+.25 option

pow miners can become pos minters potentially

@Nagalim @backpacker thing is we exepect PoW reward to be reduced drastically in next couple of years. We'll get a flood of old bitcoin hardware as early as next month.

I finally get it now, I think the formula is a brilliant concept, and this come from me who hates anything progressive

ELI5 plz

every minter gets ~1 ppc + 2% annually per block. Which means the whales gets less and yet the pos inflation rises to ~1%. Took some time to get it. Am not a good numbers guy

The whales will get more, but the continuous minters get even more. In total, this will increase inflation and reward for all minters, but will also stimulate continuous minting.

@Nagalim PR the RFC17

ok so what about the reward RFC

we dont really have concensus here I see

I think we can say we have consensus for the reward rfc except for the exact numbers used

The reason I am imposing that is based on the fact that we can upgrade to rfc11 at a later date if we manage to get consensus on that later

As far as the numbers, I think most of us are fine with either 2 or 3% and that you and backpacker are the most diametrically at odds, so you two should debate it.

yeah it's about two of us

should this debate be public or behind closed doors

wherever you want

Im with 2% as I think 3% will result in too much inflation down the road

what minting participation is required to make 3% "too much" in absolute numbers?

50%+

let's consider the minting participation curve that i've posted on the forum

Is there something like "too much minting participation"?

@Nagalim Can you put the updated proposal(s) on the Forum? Thanks.

notice where btce stopped minting

now, my point is that, unless it returns (which would be horrible horrible turn of events) we'll never see 50% of money supply participation in near or far future considering pow rewards will drop off

33% is the most we can strive towards by my calculations

with 33% participation, 3% is little under 1% total inflation

I guess whe shouldn't do something like with pow reward, more participation lower inflation?

Because we want to attract minters, altho when participation is low, they do get attracted

no we are not doing dynamic adjustments of this nor should we touch it in future

thing is we'll get millions of fresh peercoins in coming years

and those might as well join the minting process

Millions?

yes we get about 1M new ppc a year

we won't after v9

current pow difficulty adjustment was open to gaming

we won't be having these new POW coins anymore

so unless you want me to have a "told you so" moment few years down the track, i really see no point of setting the numbers as low as you guys propose

i mean even 33% minting participation is too optimistic

with number of coins lost

what is your projection on how much new PoW coins we'll be getting?

200k

that's without new miners

and less with increased hash rate

4% is about 1 million

hashrate will certanly increase this year, likely double

should inflation be steady, or should it drop off?

PoW will grind to zero

i imagine the pow inlfation getting lower and lower and pos inflation stays at what we do with it ?

PoS should be steady

but what is good practice for coins from economic pov

@peerchemist so with this in mind, how do you imagine we reach this 50% participation

without burning lost coins

it wont grind to zero next monday

but in like 10y

or 20

ok, let's imagine that we'll keep having these 200k coins per year, how soon do you think these coins bring the minting up to 50%

with current being 6.25mln

something like 25 years?

10+ def

ok so you count on 33% of coins minting

as the maximum obtainable goal in foreseeable future

but again, if we switch pow algorithm to something unasicable, we can reach that goal much faster

what is minimum

maybe we should not aim for most participation, but enough participation

we have enough now

I am not at all for PoW algo change

Id like to not keep that as an option on the table at all

mention it one more time and you're fired

(insert funny trump gif)

changing PoW is a death sentence, unless we attain 500M mktcap before

to do that we could just release code from previous rc and mint ourselves 5bn new peercoins

there, we have 500m mktcap

nice

did we come to any conclusion in our debate?

I am more acceptive of 3%