Here's a technical look at how the Steem Proposal System (the one created by @blocktrades), which will be added in HF21 will work. There are 2 new operations that can be used to manage SPS proposals, 1 to vote for proposal, a new special account, and new virtual operations.
What is a proposal?
A proposal has an ID, a creator, a receiver, a start date, an end date, a daily SBD pay, a 0-80 character line subject, and a link to a post. The creator and receiver can be the same account, but this isn't necessary. It's entirely possible to propose that a different account receives funds than the creator of the proposal. The post must have been created by the proposal creator, and is mandatory.
Managing proposals
Creating proposals
Proposals can be created with the create_proposal operation. This operation requires all the information described above about propsals, except for an ID. Creating proposal costs 0.01 SBD (the amount could change before the hard fork though). The fee is automatically sent to @steem.dao.
Deleting proposals
The creator of a proposal can delete it at any time with the delete_proposal operation. This operation requires an array of 1-5 proposal IDs, all of which will be deleted. Being able to delete multiple proposals in one go is a pretty useless feature, but I suppose it couldn't hurt. Note that this doesn't immediately remove the proposal. There is a SPS deletion maintenance period every 24 hours, during which all the deletions for the day will be processed.
Voting
The update_proposal_votes operation allows users to specify which proposals they approve of. By default, they disapprove of all proposals. This operation allows users the specify 1-5 proposal IDs, and if they approve or disapprove. There is no limit to the number of proposals you can approve of.
I don't know why, but if you've set a witness voting proxy, your votes don't count.
Getting paid
Once every hour, there is a maintenance block (completely different from the deletion maintenance period I talked about above). First, a sps_fund_operation virtual operation occurs. Then all proposals are sorted from most votes to least votes. Starting from the most voted proposal, each proposal gets 1/24th of their daily pay. The payment is done by a virtual proposal_pay operation. The occurs for each proposal, until @steem.dao runs out of inflation to distribute. The details of the inflation amount haven't yet been programmed. Note that payments are all or nothing: there is no partial payment.
@steem.dao
@steem.dao is a new specical account on the blockchain. The existing special accounts are @temp (which requires no private key to user) @null (which nobody can use), @initminer (which produces blocks if there are less than 21 witnesses), and @miners (which is supposed to be the current witnesses but I think they never got around to programming it, so it's basically the same as @null). Here's what's special about @steem.dao:
- Only SBD can be sent to it, not STEEM
- A soft fork has already been added to prevent STEEM from being transfered, but it's still possible right now almost no witnesses have updated
- When HF21 occurs, it will have no authorities, like @null
- SPS proposals transfers will come out of the account
Got any questions? I might be able to help out, just ask in the comments.
That seems curious indeed, and it's good to know.
Interesting, I didn't know there is a failsafe for this situation, to prevent the blockchain from halting. Has it ever been tested in the early days of Steem?
Yep, the genesis block was produced by @initminer, who received 0.001 SP for producing that block. @initminer went on to mine the first ~1000 blocks.
Ah, ok thanks, so it worked like a kick starter of the chain.
hey - just wondering whether you will be interested to contribute to some of these issues opened in https://github.com/peerplays-network/peerplays/issues