Draft Steem Constitution

in steem •  2 years ago

The purpose of this post is to start the discussion on what elements and language should make up the Steem constitution. This is not a final Constitution but merely a straw man for us to discuss. These are some of the Articles I would like to see in any Steem constitution.

1.0 Immutable Blockchain Data

The blockchain is immutable and its record of events will never be unwound by more than the last irreversible block. The last irreversible block is defined as any block that has at least 51% of active witnesses building on top of it. Generally speaking, after 1 minute your transaction is forever recorded in the blockchain.

This article applies only to the data held in the blockchain, not necessarily to the interpretation of that data.

2.0 Immutable Balances

Steem has a firm commitment to property rights, no hard forking change that reduces a user’s existing account balance of Steem, Steem Dollars, or Steem Power will be allowed. These balances may only be changed as the result of an operation signed by the account holder(s). These balances also include any funds held as open orders on the internal market.

3.0 Reward Funds are Community Property

Until a payout from a community fund is made, the community has the power to review and change who, what, where, when, and why someone gets paid. Changes in payouts happen every time a vote is cast on an article or witness. Given the power of individuals to allocate community property by vote, there shall be no restrictions on how these funds can be redistributed by a future hard fork.

The reward funds include all future issuance of STEEM, Steem Power, or Steem Dollars.

4.0 Capped Inflation Rate

The supply of STEEM shall at most double once per year after the initial issuance. The allocation of the STEEM created among vesting, curation, activity, liquidity, posting, and any future rewards is subject to change by those who vote with their Steem Power. The only exception to this rule is the redemption of Steem Dollars for Steem at the price feed.

5.0 Intent vs Implementation

Software bugs are assumed. The community recognizes that it is impossible for even the most skilled programers to prevent all bugs. The scale of the bug matters. Proof lies in the fact that a bug which earns the discoverer 99% of the market capitalization will render the remaining tokens worthless. Likewise, a bug that earns the discoverer 1% of the market capitalization is unlikely to significantly harm the network. The balance which maximizes market capitalization of Steem lies somewhere in between.

In the event a bug is discovered, no hard fork will retroactively change an account balance unless the exploit involves amounts in excess of 1% of the market capitalization. In this way, the blockchain consensus will offer a continuous bug-bounty and reward those who identify it.

The voters have the ability to reimburse any victim of the bug without punishing the exploiter. The power to reimburse a victim is derived from the general power of spending.

The voters must decide whether the code is executing according the common understanding of intent. We recognize that identifying something as a bug is a subjective loophole that could be abused. The cost of abusing this loophole will likely be extreme punishment in the market.

The effect of helping victims is for the blockchain to self-insure all users against losses due to some bugs. Victims are not entitled to compensation, but voters are not prohibited from approving it.

7.0 Developer Liability

Users of Steem hold developers blameless for any and all bugs, miscommunications, or misrepresentations regarding the code. All users of Steem take full responsibility for any losses as a result of a bug, attack, vote or misunderstanding. This clause merely recognizes that developers cannot be expected to be perfect and that everyone shares responsibility of reviewing code.

8.0 Side Chains

A bug in the implementation of a side chain shall not be considered a bug in Steem. Rules regarding immutable balances apply. If The DAO was implemented as a Steem side-chain then Steem would not hard fork to recover funds withdrawn. Voters may optionally choose to reimburse the victim of a side-chain exploit in part or in full under their general power over community funds and issuance.

9.0 Steem Dollars

The intent of the Steem Dollar is to create a stable unit of value denominated in units normally used in commerce. In the event that the U.S. Dollar is no longer a suitable currency, Steem may convert Steem Dollars into Steem Gold, Steem Silver, or Steem X where X is whatever unit account is widely used in the market.

10.0 Arbitration

In the event of any controversy or claim arising out of or relating to the use of Steem, or the breach thereof, the parties hereto agree first to try and settle the dispute by mediation, administered by the International Centre for Dispute Resolution under its Mediation Rules. If settlement is not reached within 60 days after service of a written demand for mediation, any unresolved controversy or claim arising out of or relating to use of Steem shall be settled by arbitration in accordance with the International Arbitration Rules of the International Centre for Dispute Resolution.

Summary

A final draft would probably be short and concise. Detailed explanations and justifications can be documented elsewhere and referenced by the constitution. Once a final version has been drafted, the community members can sign their support of the constitution with an upvote.

Steemit.com can ask all users to review the constitution prior to funding their account. In this way we can get documented evidence of agreement.

Note: The proposed terms are broad so as to prevent us from getting painted into a corner. Voters will likely follow a more restrictive version in their voting habits.

Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!
Sort Order:  

I'm generally supportive of this Constitution idea, but I have a few concerns/thoughts:

As I see it, there are two main reasons to have a Constitution. First, it helps create a culture or a "tribe" of people who share similar ideals, at least in certain limited respects. By requiring each person to "sign" the Constitution before opening an account (can this actually be built into Steem?) we are, essentially, self-selecting the type of people that we want here to a limited degree. That's probably a good thing provided that the tent is sufficiently large to ensure Steem's continued growth.

Second, a Constitution serves as a bit of a "check" on the power of stakeholders. Though (as noted by a previous commenter) stakeholders are not technically bound by the Constitution (in the sense that 51% of the stake has the power to do what it wants), adopting it could serve as a very real deterrent to them using this power in a way that violates the Constitution. Here's why:

The ultimate "check" on the power of the 51% is the markets. It's the market price of the token that actually secures the blockchain. Higher prices equal more security, and vice versa. Stakeholders are incentivized in numerous ways to maximize token value. If all holders have signed the Constitution (meaning, presumably, they that support its principles) and then 51% of them act in violation of those principles, the minority may "opt out" by dumping their state, thereby decreasing token value and punishing the 51%. Thus, the 51% is only likely to violate the Constitution when, in their judgement, there is overwhelming consensus among stakeholders to do so or when the importance of doing so is, in their mind, worth the cost (that is, the decline in market value).

Regardless, I do think that having a Constitution serves as a useful check on the power of the majority.

I'm a little concerned about invoking law and jurisdiction, however. That seems to be a slippery slope. Blockchains are currently (and arguably) a law unto themselves. This is due in large part to the fact that it's virtually impossible for any single court to gain sufficient jurisdiction over a majority of stakeholders/miners to compel them to act or forbear. By invoking law and consenting to jurisdiction, we may be opening Pandora's box. I would think long and hard before including any reference to sovereign laws or jurisdictions in the Constitution, or even mediation/arbitration.

Regarding the specifics of the proposal, here are my thoughts:

A) Do paragraphs 1 and 5 not conflict? 1 suggests that transactions will never be reversed and 5 implies that they can be in order to honor intent when the issue is large enough. This needs clarified.

B) In paragraph 5, I’d suggest setting aside some fixed percentage of the new Steem created with each block as a bug bounty escrow and/or insurance fund to reimburse those who are harmed by bugs when the community agrees to do so.

A concern that I don’t know how to remedy is the perception that reimbursement of losses is more likely to be approved when large stakeholders are harmed by the bug than small ones. This has been an issue of fierce contention in Ethereum (the perception that Ethereum whales are lobbying for a hard fork only because they personally suffered major losses). This issue needs some thought because it could easily divide the tribe.

·

I'm a little concerned about invoking law and jurisdiction

IIRC, the issue TheDAO is facing for not listing a jurisdiction is that people can shop jurisdictions for the best outcome for themselves. See : Legal Ramifications of TheDAO.

·

As you say para.1 and para.5 are in conflict under a plain reading of English. And the whole +1% of marketcap being pivotal to whether a 'bad faith' attack is reversed is open to the lobbying critique you outline.

Therefore I think the community needs to make a statement of values on this issue - and I think (we all due respect to @dan) this is presently a fudge. He clearly reckons that due to the likelyhood of bugs arising, the stability and trustworthiness (ironically) of Steem rests on individuals not being able to manipulate the value of Steem in bad faith. But equally like many crypto-evangelists he wishes to maintain the idea of decentralisation and code as law.

I believe the community is better either;

(i)
(a) fully recognise the likelyhood of a future hack (in bad faith) and deciding that the community can reverse such a hack in a limited set of circumstances (have a schedule of bad faith actions in the constitution)
(b) adopt a formal bug-bounty scheme, and adjust the blockchain to payout to a fund for this purpose.
(c) choose to give hacks below 1% the presumption of white-hat status

or

(ii)

(a) commit to the irreversibility and immutability principles
(b) and treat any hack as a bug bounty reward, whether it's 1% or 51% of marketcap
(c) !another solution needed to maintain the integrity of Steem in the face of a high-level hack (I have no answer to this)!

I am so happy we've approached this issue.

There are lots of lessons that Ethereum could learn from BitShares (and from Steem in the future) but it also works the other way round: we can learn a lot from their mistakes.

Steem could be the first blockchain with a formal constitution. If it proves valuable (as I'm sure it will) other blockchains will follow suit. This could be our Magna Carta moment.

The Magna Carta is seen by many as THE founding document for modern western constitutional government.

I'd love to merge whitepaper and constitution finaly

Loading...

4.0 Capped Inflation Rate
The supply of STEEM shall at most double once per year after the initial issuance.

This is not as accurate as current implementation.
In case when STEEM price dropped too much (which is expected), it's possible that much more STEEMs could be created from existed Steem Dollars by conversion (even don't need to convert because "virtual_supply" will increase anyway), and then more STEEMs be created for rewards, which will lead to higher inflation rate.

//Edit: just noticed there is an exception at the end:

The only exception to this rule is the redemption of Steem Dollars for Steem at the price feed.

So the whole paragraph is correct, but the subtitle as well as the first sentence are misleading. The only exception could impact much.

·

I agree.....just improve the wording/prominence of the SD point.

2.0 Immutable Balances
Steem has a firm commitment to property rights, no hard forking change that reduces a user’s existing account balance of Steem, Steem Dollars, or Steem Power will be allowed. These balances may only be changed as the result of an operation signed by the account holder(s). These balances also include any funds held as open orders on the internal market.

What about in the case of a stolen account? The owner should be explicitly defined if we're bringing up property and the rights surrounding it. Is it the entity holding the key? Is it the person who it was stolen from?

Steem is built to incentivize long-term holding, but how does that affect what a thief would do with an account, especially if it's a valuable one? It could be disruptive. What if the account name is used as an identity widely? Would impersonation of this person be tolerated? Hypotheticals like this mean ownership needs to be defined.

·

Same situation: how to prove one is the owner of a coin on the ground?

·
·

Well that's not a good comparison, a coin on the ground doesn't have a name engraved in it, nor does it have a history of its changes in a blockchain.

To the extent possible, we should create scripts that validate these conditions hold for any new release. For example:

  • (A) Check each account to ensure that old and new release report the same balance for each account for any [1] block prior to the date/time the release is published [2].
  • (B) Check new supply to ensure it doesn't exceed the inflation rate limit (this will be complicated somewhat by Steem Dollars however).

[1] We could conceivably check this condition for every block, but in practice a sufficient level of assurance should be attained by checking this condition on a single recent block (along with current levels of code review and testing of course).

[2] The old/new releases may disagree on balances in the future. For example, if the new release uses the authority granted by section 3.0 to implement a hardfork which changes the way community funds will be distributed in the future, the releases will start to disagree about balances once the first distribution under the new rules occurs. This is perfectly constitutional.

Well that's the most solid straw man I've met for a while! Is it even flammable? Great work Dan. I'll give it some more thought but this is a really powerful start.....fantastic.

missing 6.

but I really like the 5(6) approach. upvoted.

Blockchain teams sometimes do this constitution thing. I really don't see the point of it. In short: since you can't test code changes against a constitution without lawyering about it, it has little practical value.

A Contrived Example

A contrived example, using this paragraph:

In the event a bug is discovered, no hard fork will retroactively change an account balance unless the exploit involves amounts in excess of 1% of the market capitalization. In this way, the blockchain consensus will offer a continuous bug-bounty and reward those who identify it.

Let's say that a bug leads to an exploit that involves ~1% of the market capitalization. Affected shareholders would call for a hard fork and feel justified in doing so. But that's not technically in excess of 1% if its 0.9999% (even exactly 1% wouldn't technically be in excess of 1%). I would guess that the majority would choose not to be pedantic about it and allow the hard fork to happen.

However, in an equally-defensible view, you've broken the contract that the Constitution serves as by implementing that hard fork. The rest of the Constitution should be considered null and void. Some other arbitrary point would be that if the exploit involved a value slightly in excess of 1% of the market capitalization, then inflation would soon render that amount less than 1%. Should the percentage of market capitalization be considered final as of when the exploit occurs?

Lawyering

There's just no winning. There are people whose entire careers revolve around making a favorable interpretation of words that somebody else wrote. In the end, whatever binary is downloadable from the website and whatever code is in the official repo is what will be used. If there's a dispute over it, I doubt that the majority of people will hesitate to use the official source/executables.

·

The purpose isn't to create something that is enforceable, but to signal values held by various parties.

The purpose of putting a lock on your front door is not to keep bad guys out, but to keep honest people out. Bad guys will find another way in, pick the lock (lawyering) or simply kicking the door down (ignoring).

·
·

I think that this constitution is an idea with good intentions. It won't hurt anything, but I don't see any practical value to it. So I'm indifferent to it; that which floats your boat, as the saying goes.

·

God's green earth and humanity has absolutely NO "practical" value whatsoever.

It's merely an expression of art. Emotion.

2.0 Immutable Balances

This can be abused / exploited by for example issuing 1000x tokens to others but not to one special holder.

·

What you are talking about is an unequal stock split. Theft by inflation.

This is already prevented by the inflation cap which already accounts for the maximum inflation rate. Voters are already completely sovereign over how this inflation is allocated.

  1. [...] Voter’s may [...]

Dan, seriously! That's a plural! They're voters.
Seen that happening to you a few times in the past, now the grammar nazi came through :P

·

Thanks for the catch. After hours of staring at text it just disappears.

Thank you very much for such a detailed information on Steem.

Can any one explain me when can one get their pending payout into his account (time frame)?

@dan, where are we on this? Will you be circulating another draft soon?

Ha, I like 8.0. Is this the first user agreement to have such a clause in it? Historic!

·

"In the event a bug is discovered, no hard fork will retroactively change an account balance unless the exploit involves amounts in excess of 1% of the market capitalization. In this way, the blockchain consensus will offer a continuous bug-bounty and reward those who identify it."
I think this is exceptionally genius and it solves perhaps half of the issue of hackers. It goes further to even include hackers as an integral and necessary part of the ecosystem by viewing their activities as a job which the system rewards. Is this the first time a crypto constitution has been structured in this exact way?previsualizing a hack and setting in place measures like this could prevent Steemit from crumbling from future hacks.
The amount of thought that went into this is impressive. Although I don't yet grasp every point in its entirety, I would say you've tackled one of the toughest realities with measured thought.
The possibility of becoming a victim in this Steemit world would indicate even a greater necessity of individuals to serve others as a type of survival insurance. Meaning: the more useful and value-laden one becomes in here, the less vulnerable you are to being victimized. If one was victimized, then the value (non-economic and economic) you have deposited within others will naturally flow back towards you if a victimization has occurred. This is a natural flow of energy and follows basic laws that are contained both in the natural forces as well as within communities. In order for it to truly work though, community members cannot be wealth hoarders. In a community that contains a majority of wealth hoarders, the natural flow of energy is cut off, paralyzed.
Well done, Dan.