Ravencoin — Proof of Market: An Asset Issuance Cost Alternative

9/5/2018 — In response to “Ravencoin — Asset Issuance Cost” by Tron Black

Opening Statements

1. First and foremost I would like to state I appreciate the hard work of everyone who has contributed to the development of this project. I do not seek to undermine their decisions and expertise which has lead us thus far. I am only speaking out in an attempt to further strengthen the Ravencoin project. This paper is a direct response to Tron Black’s “Ravencoin — Asset Issuance Cost”, which should be read prior to reading this paper.

2. Personally I am only a non-coding engineer with no background in cryptography or blockchain technology. If in your eyes, this disqualifies me in critiquing someone as qualified as Tron; feel free to stop reading here.

3. I have been following and mining Ravencoin since January on my single card gaming PC. I have purchased RVN but am yet to sell any. I have done so because the project interests me and I consider it a hobby, but do not deny the potential for economic gains of RVN does well. I have taken an increased interest during the discussions of difficulty algorithms and was motivated to speak out after the responses to the DGW implementation.

4. I will make many statements in this paper. Some will have supporting information and others will not. This does not make statements with supporting information inherently true, and in turn does not make statements without supporting information inherently false. Inform yourself and form your own opinions as this is ultimately a collection of my opinions.

Time

This paper was written in response to Tron Black’s “Ravencoin — Asset Issuance Cost” posted on medium.com. Recent discussions on the Ravencoin Discord and Ravencointalk forum have resulted in Tron taking valuable time away from the development of Ravencoin to address some community concerns. I feel as if he has failed to make any concrete statements addressing concerns and thus definitely wasted his time by constructing this article.

This article was rushed and feels as a hollow attempt to ease the community into submission and acceptance that 500 RVN is going to happen because it’s the best, without making it clear why it’s the best. Vague surface level comments are made and there are many contradictions throughout. Therefore this has guaranteed the waste of Tron’s time, which was previously used by the core team as to why the community had not previously been addressed, as he was working on this article versus working on the development of Ravencoin. At a time in Ravencoin’s history where the centralization of the project is being called into question this does not bode well. This combined with the knowledge of the strict development timeline, raises concerns over the un-willingness to explore more difficult, potentially better options on this subject. Intentions need to be made clear, is this an experiment to create the best possible system? Or is this a product which must meet a delivery deadline.

This topic is extremely urgent as the community has “technically” already agreed to burn 500 RVN for asset creation, which in theory makes all of this discussion pointless. “Technically” because this fixed creation cost has been pushed and accepted in the main net with the DGW hard fork update. Given the massive difficulty swings caused by the previous algo, it was nearly impossible for this hard fork to fail, thus firmly securing the 500 RVN asset creation system as well.

Now one could say, “Well the test net has been out for over a month using the 500 RVN cost, why didn’t you push for testing there?” My response is, you’re right I or someone else, should have. Once assets go live, we are stuck with whatever is implemented and there is no turning back. However, we are not past the point of no return…. yet, so it is our duty to assure without a reasonable doubt Ravencoin is moving in the optimal direction.

Contradictions/Rebuttal

This section will quote statements, point out contradictions, provide counter arguments, and cover points of agreeance from Tron’s most recent article. Italicied sections are directly pulled from his writings in order to not twist his words. Again, Tron’s paper should be read prior to this one.

“Burning RVN is beneficial to the token economics. It solves three problems. First, it increases the value of existing RVN because the circulating supply goes down. Second, it limits the number of assets that can be created which is good because a blockchain is a limited data store. Third, the cost to create assets increases as the value of RVN increases, which is tightly correlated to the security of the blockchain indicated by mining hash power cost.”

Burning RVN solves 2 problem. One Tron hits well “it limits the number of assets that can be created which is good because a blockchain is a limited data store. “ (The latter portion of this sentence is underlined as it will be important later). A second, which is not mentioned, is that it prevents spamming the system. A malicious party could instantly claim all available assets if there was no economic deterrent to prevent them from doing so. This is the single largest benefit of having a burn cost upon asset creation. The other ‘solved problems’ stated are “Increasing the value of existing RVN because circulating supply goes down” and “the cost to create assets increases as the value of RVN increases, which is tightly correlated to the security of the blockchain indicated by mining hash power cost.” (Again underlined as it will be important later). This is redundant, and it isn’t an example of a problem being solved. If anything this is a feature. As more assets are created, the community at large benefits financially.

Next Tron covers the some undeniable priorities of Ravencoin. They are simply:

1. Easy to use

2. Easy to understand and easy to plan your project

3. Not dependent on human or organizational intervention

4. Not tied to an external fiat price

Number 4 is where we first see contradictions (2nd underlined section). In the stated reasons for burning RVN it was mentioned that the value of existing RVN would increase and that the cost to create assets would increase. Relative to what? 1 RVN is still 1 RVN, therefore asset creation cost of 500 RVN is just that and in 10 years it is still 500 RVN in the proposed system. This value increase and cost increase must then be in relation to either fiat or BTC since the RVN values are fixed. The lack of flexibility in the fixed asset cost forces users to look to other currencies to quantify asset creation cost. 500 RVN will always be 500 RVN, so users can/will wait until this is a favorable transaction in terms of USD or BTC ultimately undermining RVN’s ability to stand on its own.

“Other than the nodes holding the name of the assets, there isn’t much additional space used in the chain for issuing an asset. It is about ~350 bytes for an issuance (depends on asset name length), when a normal send transaction is about ~250 bytes.”

It was stated earlier a RVN burn was beneficial in order to limit asset creation due to blockchains having a limited data store (1st underlined section). This section seems to counter this previous concern/solution by essentially bragging about the efficacy of the asset system. A firm answer needs to be provided on the taxation of the blockchain caused by asset creation. Honestly, this sounds amazing. The idea that the asset system will be this light and hopefully will result in limited scaling issues is nothing but good news.

“Benefit of burning RVN is to mop up some of the RVN being issued. With 21 billion RVN being issued, it is beneficial to holders, and miners, that some of the RVN is burned to decrease the circulating supply.”

This is irrelevant and misleading. This is candy for the community and appeals to everyone’s economic bias. A 500 RVN burn provides a theoretical max of 42,000,000 full assets. This number increases if extensive sub asset usage occurs. The NASDAQ has ~3,300 companies on it. For reference and understanding this means if the NASDAQ completely converts all its companies to RVN, the total RVN burned will be….. ~1,650,000 or roughly 22% of the total RVN mined daily (until halving). Therefore, the amount of RVN burned will unlikely have any effect on the value of RVN if the proposed system is allowed to pass.

Proposed Option

Listed here are the statements previously made and some further expansions. Non italic pros/cons are additions to Tron’s original lists.

Fixed 500 RVN Burn for asset issuance

Pro: It is consistent with the roadmap.

Agreed, the idea and roadmap were written by the same group of people so it should be.

Pro: It is simple and easy to understand.

Agreed, this is by far the simplest and assures RVN priorities #1 & #2

Pro: It automatically puts limits on the number of assets

Agreed, however is this an issue? It was stated previously that assets had a limited space usage

Pro: As mining hash power and price increase, the cost of asset issuance should increase.

Relative to what? The price is fixed at 500 how will the price increase? Unless this is reference to a price increase in fiat or BTC. If so see previous statements.

Pro: If 500 RVN too high, then market for 100 RVN sub-assets under premium top-level will materialize.

This may be the single best point in the entire paper, however it is not exclusively a “Pro” to any one system. For those who don’t understand, think NASDAQ creates the NASDAQ token for 500 RVN. Now any company can create a subtoken under the NASDAQ umbrella for 100 RVN. The new token would then be NASDAQ.SallysLemonadeStand

Pro: A fixed asset creation cost allows validation of asset creation.

This is an important point that was overlooked. By setting a fixed asset creation cost, the validity of an asset can always be confirmed via observing the amount of RVN burned for its creation. An asset which was maliciously created at incorrect prices will (should) be clearly visible.

Con: It may price out some use cases as the cost per RVN increases.

I agree, by hard setting the price the chain will be completely unaware of asset creation demand. This could spiral out of control in both directions. If RVN value approaches 0, asset creation follows this. This would likely result in remaining assets being snatched up, potentially preventing or inhibiting any attempt recovery via utilization. In the inverse if RVN value approaches extremely high values, this could force out smaller market use cases such as concert tickets or unique id’s applied to individual pieces of art.

Con: This concept is in direct violation of Ravencoin priority #3 and this is the main issue.

There is zero/little documentation as to how exactly the number 500 was determined for the burn by the core development team. When requesting further information as to why this solution was chosen, the document of which this paper focuses on was provided. This is not enough information as to why and how this was decided.

This value of 500 and fixed system was decided by the core team of developers and the code base was added in with DGW. Let it be clear, in the wallets required to currently run the live version Ravencoin; asset creation is going live on 10/30 and the asset burn will be a fixed 500 RVN. I have been told delaying the asset system this is not an option as it would cause more issues than solutions (in addition to community up rise UNLESS a full explanation was given as to the delay being a result of exploring potentially alternative solutions to strengthen the project). This addition is against the core philosophy of the project and the community was forced into an ultimatum; continue to fight the difficulty swings and move away from the core on your own or accept the executive decision by the core team to solve the difficulty swings AND the asset creation cost. These two updates should have been independent as they are not related and both massively important to the future of the project.

Alternative Options

My proposal which was posted on discord and Ravencoin talk was not directly addressed. I have been assured my proposal has been seen by the development team, light feedback that it looked interesting was received by both community members and developers, and its emittance is the driving force behind this response. In no way can it be perfect, but it can be better than the fixed asset cost system.

However, this is the closest proposal of which Tron provided Pros/Cons for. Additionally, Tron’s statements have been reorganized to group together all Pros and Cons. The inconsistent listing inhibits the thought process of the reader.

Adaptive RVN based on number of asset issuances in X blocks

Pro: If no assets are being created, the cost (in RVN) lowers.

Incorrect, will be addressed in the proposal below

Pro: If “too many” assets are being created, the cost (in RVN) increases.

Incorrect, will be addressed in the proposal below

Con: Requires more constant values to be guessed, and estimation on the “right” amount of asset issuance

Agree, asset creation cost would fluctuate with every asset created and every block mined.

Con: Complexities like asset issuances failing because cost went up between asset creation tx and confirmation in a block.

Agree, given price fluctuating with every block mined AND asset created this adds further complexity

Con: Mempool holding asset creation creates a potential time lag.

Disagree, as stated earlier.

Proof of Market for Asset Issuance

I propose a new system which will provide flexibility in the asset creation cost. This will help guard against the need to update the creation cost for potentially unforeseen usage of the Ravencoin network. Remember the original Bitcoin developers though everything was ok given its current environment at the time of creation; yet Bitcoin Cash and many other forks are still a thing. This should be prevented at all cost.

As stated in the Ravencoin white paper, this project is an experiment and regardless of asset issuance burn cost, the economics revolving around Ravencoin will be one of if not the first of its kind. Therefore, I propose 2 variables be hard-set in the Ravencoin code for asset creation. These values will need further testing and tuning by individuals with greater understanding of economics. These variables will be applied to adaptive parameters which should not require extensive tracking to populate in the code base.

Current RVN supply — The total amount of RVN rewarded thus far, currently his would be block * 5000.

Total Burned RVN — This is the only new variable which would require tracking. This is the total amount of RVN burned in total due to asset, subasset, and unique asset creation.

Using these parameters, 2 variables are applied to determine asset cost.

Max % Burn — This is the maximum percentage of RVN which can be burned at any time.

Burnable RVN — This is the amount RVN currently available to be burned. (Current RVN supply * Max % Burn) — Total Burned RVN

Burnable % Cost — This is the percentage of burnable RVN which determines asset cost (Burnable RVN * Burnable RVN % Cost = Asset Creation Cost)

This results in a moving price of asset creation cost not controlled by any person or group. Once initiated the asset creation cost is free to move up and down completely freely. For analysis sake, set Max % Burn to 50% and the Burnable % Cost to 0.00005%. We know based on 1 minute block time that roughly 2,000,000,000 RVN will be in circulation once asset creation goes live. These numbers will be used in the follow analysis.

Given 2,000,000,000 RVN available and zero assets created we know Burnable RVN = 1,000,000,000. Applying the Burnable % Cost of 0.00005%, this gives an initial asset cost of 500 RVN. Assuming (incorrectly) that all mining rewards magically stop yet asset creation continues, as the burnable RVN amount lowers the cost to create an asset will lower directly. In this hypothetical situation, the 2nd asset creation cost would equal 499.99975 RVN, the 3rd 499.9995 RVN and so on.

However, with every new block mined, the burnable RVN amount would increase by (Block reward * Max % Burn) resulting in the price of asset creation increasing. Assume a block is mined following the 3rd asset as stated prior, the 4th asset would cost 500.0005 RVN. This would be a constant battle of RVN being created, increasing the price of asset creation; as well as RVN being burned resulting in the price of asset creation lowering.

With the system in place and using the variables stated above, if zero assets are created in a day the cost to create an asset will increase by 1.8 RVN. This is fixed assuming blocktime is fixed at 1 minute. This value stems from the block reward 5000*24hr*60min= 7,200,000 RVN minted daily. Thus Burnable RVN increases at a maximum rate of 7,200,000 * Max % Burn, or +3,600,000 RVN/day. Knowing the theoretical max rate, we can apply the Burnable % Cost to give the RVN/day increase or (+3,600,000 RVN/Day * 0.00005% = 1.8 RVN/Day). As the block reward halves, the maximum RVN price increase lowest. Additionally, 3,600,000 RVN/day is the value of RVN which would need to be burned to stabilize the price. At the initial conditions of 500 RVN this is 7,200 assets per day. However, assets/day should not be used nor is this value useful given asset creation cost will fluctuate. The RVN required to burn per day to stabilize (and move in any direction) the price will remain constant.

What if greater than 3,600,000 RVN/day are burned via asset creation? How will this affect asset creation price? Slightly altering the formula above can give the daily price change for any situation:

(Burnable RVN Creation Rate — RVN Burned Rate) (RVN/Day) * Burnable % Cost = Asset price change (RVN/Day)

At current block rewards this results in the following:

Therefore, the system is meant to self-regulate. Further study at later block rewards, base formulas, examples, comments, and considerations have been added to the following Google Doc sheet. Please review, critique, and frankly rip apart everything presented here. Ultimately the best solution should be chosen for the project as a whole.

Conclusion

As a member of the Ravencoin community I felt compelled to share what I believe is a better option. Pros and Cons have purposely been omitted as they will be biased if created by someone so close to the source. If requested, I could attempt to compile pros/cons from Ravencointalk and discord, as well as expand where possible. Additional testing, analysis, and critique of this proposal is highly encouraged and ultimately required. If any further explanations are required please reach out and I will answer questions as best I can. Nothing is ever perfect; that doesn’t mean we can’t build something better, together