Poll

How much should the hard coded cap on dilution/share issuance be, per year?

0%
5%
10%
20%
40%

Author [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] Topic: How much should the hard coded cap on dilution/share issuance be, per year?  (Read 874 times)

0 Members and 1 Guest are viewing this topic.

Offline stuartcharles

  • Sr. Member
  • ****
  • Posts: 277
    • View Profile

I think this part of the proposal is not being discussed enough.

The proposal is to allow BTS to be diluted by the issuing of more BTS. In the mumble session BM suggested that a cap could be hard coded.

As well as voting on what you think that hard cap should be can we also have a discussion about :-

1. what we would consider it acceptable to spend the raised capital on? Development? Marketing?
2. Who should have control of the raised funds?
3. how will the amount of dilution be decided upon on a call by call basis?
4. Who can make a call for more shares to be issued?
5. Will there be a maximum frequency of share calls hard coded?
6. If X% per year is decided upon as a maximum, will we also have a maximum individual share call hard coded? eg if 10% was decided as the hard coded limit for a year should we have a maximum share call within that year hard coded like 2%?

These are just a few questions to get the ball rolling, I just think that this part of the proposal is not getting the posts is deserves.
 

Offline Pheonike

We will also have to define what is year. Calendar, fiscal, start, end fate.  There's a lot structure that has to be put in place for decision making.

Offline stuartcharles

  • Sr. Member
  • ****
  • Posts: 277
    • View Profile
We will also have to define what is year. Calendar, fiscal, start, end fate.  There's a lot structure that has to be put in place for decision making.

lets just say for now any 365 day period, as long as its the same 365 days i don't think its an issue.

Theres only been a few votes so far but half of them are for 0%. I would like to know from those that don't think there should be any issuance of extra shares, how do you propose we guarantee future development? Dont you think its a flaw in bitcoin that is has no development fund?

Offline Rune

  • Hero Member
  • *****
  • Posts: 1120
    • View Profile
I think this part of the proposal is not being discussed enough.

The proposal is to allow BTS to be diluted by the issuing of more BTS. In the mumble session BM suggested that a cap could be hard coded.

As well as voting on what you think that hard cap should be can we also have a discussion about :-

1. what we would consider it acceptable to spend the raised capital on? Development? Marketing?
2. Who should have control of the raised funds?
3. how will the amount of dilution be decided upon on a call by call basis?
4. Who can make a call for more shares to be issued?
5. Will there be a maximum frequency of share calls hard coded?
6. If X% per year is decided upon as a maximum, will we also have a maximum individual share call hard coded? eg if 10% was decided as the hard coded limit for a year should we have a maximum share call within that year hard coded like 2%?

These are just a few questions to get the ball rolling, I just think that this part of the proposal is not getting the posts is deserves.

You misunderstand how it is going to work. Individual delegates can register as inflating delegates, with a set amount of BTS printed per block. They will have to be voted in as delegates for it to take effect, so stakeholders will always vote on all inflation projects. An example could be a new developer that wants to work full time on making and maintaining an iOS wallet. He would then pitch his project on the forums along the salary he is asking for. The community can then have a dialogue with him and he can amend his project plan after getting feedback. Once his project is ready, he will register a delegate and stakeholders will decide if they want to vote him in or not.

Once he has been voted in, he will have to follow the transparency strategy he had in his original plan, and report his progress and spending weekly or monthly or whatever interval he has committed himself to do on these forums. If he misses a commitment, or it comes apparent from his reports that he isn't doing well enough, stakeholders will vote him out again. There'll probably be a very active "vigilante brigade" that will do everything they can to ensure he gets kicked out if he doesn't follow his commitments fully.

Offline stuartcharles

  • Sr. Member
  • ****
  • Posts: 277
    • View Profile
I think this part of the proposal is not being discussed enough.

The proposal is to allow BTS to be diluted by the issuing of more BTS. In the mumble session BM suggested that a cap could be hard coded.

As well as voting on what you think that hard cap should be can we also have a discussion about :-

1. what we would consider it acceptable to spend the raised capital on? Development? Marketing?
2. Who should have control of the raised funds?
3. how will the amount of dilution be decided upon on a call by call basis?
4. Who can make a call for more shares to be issued?
5. Will there be a maximum frequency of share calls hard coded?
6. If X% per year is decided upon as a maximum, will we also have a maximum individual share call hard coded? eg if 10% was decided as the hard coded limit for a year should we have a maximum share call within that year hard coded like 2%?

These are just a few questions to get the ball rolling, I just think that this part of the proposal is not getting the posts is deserves.

You misunderstand how it is going to work. Individual delegates can register as inflating delegates, with a set amount of BTS printed per block. They will have to be voted in as delegates for it to take effect, so stakeholders will always vote on all inflation projects. An example could be a new developer that wants to work full time on making and maintaining an iOS wallet. He would then pitch his project on the forums along the salary he is asking for. The community can then have a dialogue with him and he can amend his project plan after getting feedback. Once his project is ready, he will register a delegate and stakeholders will decide if they want to vote him in or not.

Once he has been voted in, he will have to follow the transparency strategy he had in his original plan, and report his progress and spending weekly or monthly or whatever interval he has committed himself to do on these forums. If he misses a commitment, or it comes apparent from his reports that he isn't doing well enough, stakeholders will vote him out again. There'll probably be a very active "vigilante brigade" that will do everything they can to ensure he gets kicked out if he doesn't follow his commitments fully.

That seems reasonable, can you point me to the thread where this was discussed. I looked around but couldn't find the debate.

Offline Rune

  • Hero Member
  • *****
  • Posts: 1120
    • View Profile
I think this part of the proposal is not being discussed enough.

The proposal is to allow BTS to be diluted by the issuing of more BTS. In the mumble session BM suggested that a cap could be hard coded.

As well as voting on what you think that hard cap should be can we also have a discussion about :-

1. what we would consider it acceptable to spend the raised capital on? Development? Marketing?
2. Who should have control of the raised funds?
3. how will the amount of dilution be decided upon on a call by call basis?
4. Who can make a call for more shares to be issued?
5. Will there be a maximum frequency of share calls hard coded?
6. If X% per year is decided upon as a maximum, will we also have a maximum individual share call hard coded? eg if 10% was decided as the hard coded limit for a year should we have a maximum share call within that year hard coded like 2%?

These are just a few questions to get the ball rolling, I just think that this part of the proposal is not getting the posts is deserves.

You misunderstand how it is going to work. Individual delegates can register as inflating delegates, with a set amount of BTS printed per block. They will have to be voted in as delegates for it to take effect, so stakeholders will always vote on all inflation projects. An example could be a new developer that wants to work full time on making and maintaining an iOS wallet. He would then pitch his project on the forums along the salary he is asking for. The community can then have a dialogue with him and he can amend his project plan after getting feedback. Once his project is ready, he will register a delegate and stakeholders will decide if they want to vote him in or not.

Once he has been voted in, he will have to follow the transparency strategy he had in his original plan, and report his progress and spending weekly or monthly or whatever interval he has committed himself to do on these forums. If he misses a commitment, or it comes apparent from his reports that he isn't doing well enough, stakeholders will vote him out again. There'll probably be a very active "vigilante brigade" that will do everything they can to ensure he gets kicked out if he doesn't follow his commitments fully.

That seems reasonable, can you point me to the thread where this was discussed. I looked around but couldn't find the debate.

The threads discussing how inflating delegates work are actually quite old, it was primarily back when BM proposed the bitUSD referral bonus that the mechanics of it was discussed.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12057
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BTS: xeroc
  • GitHub: xeroc
@Rune: nice summary
@stuart: Unfortunately, there is no "single spot" where this has been discussed .. what Rune saids is an interpretation of what BM says in the recent 'crisis'-hangout .. and IMHO it should be implemented exactly that way

Quote
The threads discussing how inflating delegates work are actually quite old, it was primarily back when BM proposed the bitUSD referral bonus that the mechanics of it was discussed.
They called those delegates "business delegates"
Give BitShares a try! Use the http://testnet.bitshares.eu provided by http://bitshares.eu powered by ChainSquad GmbH

Offline fuzzy

 +5% for this thread.
BROWNIE==DKP; BitShares is our Community! 
ShareBits Welcome to  the Sharing Economy w/ BeyondBitcoin.org Partners--ShareBits.io & OpenLedger.info
TIP FORMAT: #sharebits "ForumHandleInQuotes" Quanity Token_Name

Offline bytemaster

+5% for this thread.

I think a hard coded cap as a "safety net" on "abuse of voting in the short term".... I think the social consensus should be 'as necessary and agreed upon by shareholders'... the "cap" should be like the bitcoin block size cap... and perhaps set to the same as Bitcoin's dilution schedule. 
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline Xeldal

I would be in favor of a degrading cap.

The purpose of these capitol infusions is to reach network effect. 

Similar to how a Rocket has stages for attaining escape velocity.  The capital infusion stage should be curtailed and ultimately dropped or near 0%.

Once safely outside the earths strong gravitational forces there should be little need for massive infusion.  Any necessary funding can come from delegate pay at that point.

So how long a window is safe to say we should be well on our way to mars?

10 years?

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12057
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BTS: xeroc
  • GitHub: xeroc
+5% for this thread.

I think a hard coded cap as a "safety net" on "abuse of voting in the short term".... I think the social consensus should be 'as necessary and agreed upon by shareholders'... the "cap" should be like the bitcoin block size cap... and perhaps set to the same as Bitcoin's dilution schedule.
wouldn't the result in the same $600M per year as in bitcoin? I didn't do the numbers .. but is THAT much money really necessary?

//edit: I can answer to my self now: $600M can be split among several 'business delegates' and as such could be a good starting point

BTW. @BM, you are approaching your 7k-th post .. congratulation and thanks for being sooo active in the forum
Give BitShares a try! Use the http://testnet.bitshares.eu provided by http://bitshares.eu powered by ChainSquad GmbH

Offline Method-X

  • Hero Member
  • *****
  • Posts: 1120
  • VIRAL
    • View Profile
    • Learn to code
  • BTS: methodx
+5% for this thread.

I think a hard coded cap as a "safety net" on "abuse of voting in the short term".... I think the social consensus should be 'as necessary and agreed upon by shareholders'... the "cap" should be like the bitcoin block size cap... and perhaps set to the same as Bitcoin's dilution schedule.

Bitcoins dilution schedule may limit us in the distant future. Maybe we will at some point need capital infusion 30 years from now and because of a hard cap, it can't be done. A limit of X% dilution per 1,000,000 blocks may make more sense. I'm neutral either way.

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile
+5% for this thread.

I think a hard coded cap as a "safety net" on "abuse of voting in the short term".... I think the social consensus should be 'as necessary and agreed upon by shareholders'... the "cap" should be like the bitcoin block size cap... and perhaps set to the same as Bitcoin's dilution schedule.

Bitcoins dilution schedule may limit us in the distant future. Maybe we will at some point need capital infusion 30 years from now and because of a hard cap, it can't be done. A limit of X% dilution per 1,000,000 blocks may make more sense. I'm neutral either way.

I wouldn't worry about it too much.  Think about what a hard cap really means and how it is enforced. 


Others -
Think about keeping it capped at bitcoin's rate.  People are quick to dismiss that idea, but it becomes a lot easier sell externally when we can now point to this huge distinction that we don't dilute as much as bitcoin AND all the money goes into productivity and not needless energy consumption. 

I speak for myself and only myself.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12057
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BTS: xeroc
  • GitHub: xeroc
Others -
Think about keeping it capped at bitcoin's rate.  People are quick to dismiss that idea, but it becomes a lot easier sell externally when we can now point to this huge distinction that we don't dilute as much as bitcoin AND all the money goes into productivity and not needless energy consumption.
Here you go: BAM!
Give BitShares a try! Use the http://testnet.bitshares.eu provided by http://bitshares.eu powered by ChainSquad GmbH

Offline Method-X

  • Hero Member
  • *****
  • Posts: 1120
  • VIRAL
    • View Profile
    • Learn to code
  • BTS: methodx
+5% for this thread.

I think a hard coded cap as a "safety net" on "abuse of voting in the short term".... I think the social consensus should be 'as necessary and agreed upon by shareholders'... the "cap" should be like the bitcoin block size cap... and perhaps set to the same as Bitcoin's dilution schedule.

Bitcoins dilution schedule may limit us in the distant future. Maybe we will at some point need capital infusion 30 years from now and because of a hard cap, it can't be done. A limit of X% dilution per 1,000,000 blocks may make more sense. I'm neutral either way.

I wouldn't worry about it too much.  Think about what a hard cap really means and how it is enforced. 


Others -
Think about keeping it capped at bitcoin's rate.  People are quick to dismiss that idea, but it becomes a lot easier sell externally when we can now point to this huge distinction that we don't dilute as much as bitcoin AND all the money goes into productivity and not needless energy consumption.

I agree it is a fantastic way to frame the conversation. We're taking a "negative" and turning it into a positive. "Bitshares is just as inflationary as Bitcoin but our inflation gets spent on growth and infrastructure."

I guess the question we should be asking is, what is the most optimal inflationary model? Is it exactly Bitcoins? We should put lots of thought and discussion into this before coming to any hard conclusions.

 

Google+