Proposed changes in the Calibrae forksteemCreated with Sketch.

in #calibrae3 years ago (edited)



away the complexity and nonsense, is a core mission of Calibrae. So, I want to put forward a set of items to discuss amongst users that we have been discussing in the Steempunks Discord Chat and what has been on my mind, and these changes will be made before the public release.

1. Sanitize chain of premine Opt-In for migrating non-preminers

First cab off the rank, of course. The account balances accumulated in the period between the genesis block and the public release of for each account will be totaled, and subtracted from the current balances of these accounts.

This has now been started:

This balance will also remove the simple steem, and SBD, all calculated at the VESTS equivalent at the time of the snapshot. If this happens to make the premined accounts have zero balance, that's just bad luck, I guess. This process will be entirely nonprejudicial except against the not-public nature of these initially mined Steem Power contracts.

The removed premined VESTS will be set as the initial rewards pool so there is rewards to be assigned from day one, instead of the 7 days of accumulating that will happen otherwise. This will of course mean a few weeks of huge payouts. This is of course an incentive to migrate, but also, a way to keep the total amount of currency same across the migration.

2. Remove SBD

This also further simplifies the process of creating the snapshot, and in fact eliminates not just SBD, but the Steem. The way Steem works is there is an underlying primary currency called VESTS.

These are going to be renamed JUICE (as in, like nectar), and the deposit contract, aka Steem Power, will be called, simply, Stake. So, when you come to use your account on the new chain, you will see your vested Stake on one hand, and all the SBD and Steem will be converted to VESTS and that is the number you will see, with the ticker JUICE.

Simplification is both technically better, as well as better for UX (user experience).

Without SBD, witnesses do not need to use their Active key to set a price feed. There is no SBD interest rate or bias to set. It makes this aspect of witness operating so much simpler.

The user experience is also simplified, and users can just see their reward JUICE directly labeled, and there can be a configuration to choose to either see it as Raw JUICE, or converted into other currencies using price feeds, when there is exchanges.

3. Payouts only in Stake, and Power Down simplified

Next, the option to receive liquid rewards is removed. Users can either accept rewards, or refuse them. The field is excessively large, also, so this cuts some crap out of the size of the post data size. It will just be zero or nonzero, meaning yes or no to payout.

Stake is drawn down by a much simpler scheme: at the time one enables power down, 1% every subsequent 24 hours, of the remaining Stake is converted to Juice. This eliminates weekly price cycles and improves the ability to seize trading opportunities. The algorithm also prevents the account from drawing down completely. In 365 days, all else remaining unchanged, the power down gets to 2.5% of the original amount.

This is of great benefit to investors, because they know that rewards cannot be rapidly dumped, which means the price movements cannot have these scissor-sharp slices, which can be especially brutal when traders are on margin. At least, it greatly reduces this possibility, and it also ensures that the market cap will steadily grow, reflecting the valuation against the issuance rate that dilutes the value in paying out rewards.

4. Direct self voting banned, curation split changed to 50%

It is simple to eliminate this possibility, another example of a change that is a simple delete. Many of the proposed changes are just deletes. This will naturally improve the maintainability of the codebase, and improve user understanding of the platform. Yes, of course people can vote for themselves with other accounts, but that was never the point of this. It's just not cool to vote on yourself. Only the premined whales could really fully argue against this, because their whole angle is milking the public pool.

The post itself will be counted as a self vote, and thus, also, the curation reward split thus must be raised to 50/50. In effect, this will likely make little difference to the real split, but it satisfies the issue about self voting - by posting, you vote.

5. Witness voting changes

This one is simple. When an account posts update_witness and becomes active, its witness votes are not counted, and instead a single vote on one's own witness is totaled instead. This eliminates the possibility of collusion between witnesses, and the leverage of large stake accounts that could seek to dictate a mutual vote that can corrupt the witness pool - if one account, or group, can control the actions of more than 10 witnesses, they can arbitrarily veto hardforks.

6. Hardfork policy

Instead of infrequent, many changes at a time hardforks, it will be proposed that once a month, change ideas are collated, then subjected to a vote using comments to signify the options for a given hardfork, and then once the reward payout occurs, the developers implement the single change, and then create a new version tag, and the witnesses then either upgrade, or not.

This will also be facilitated by simplifying the update so that witnesses can just run a single command that compiles the new build automatically, signifying their support for the change, or they do not invoke it. Eventually, it should be possible to have this trigger by a special type of transaction made by the witness, that automatically builds the new version, hands-free, without SSH shennanigans. Witness operation should not be a complex job.

7. Relocation of post data to new store, creation of a 'ledger only' mode.

This is a high priority change, because left unaddressed, this will lead back to the eventual problem with RPC nodes down the track. In fact, it may make sense to even create a new operation mode called 'ledger only' or something like this, so that the RPC node only processes transfers, vesting, and the like, and does not even parse the votes or posts at all.

These two changes will permit Calibrae to not have issues with exchanges like are plaguing steem right now.

8. Make reputation modulate rewards allocation

By taking a total of all account reputation scores, and then scaling them to 0-100% factor on rewards allocation, it would be possible to enable the community to, via downvotes, punish those who use their stake in a negative way, as discussed in @dwinblood's post about bullying. @berniesanders notably provoked a flag-party on his account some months ago, but he could still dish out candy, or sticks, whenever he wanted. If his reputation score had an effect on his reward/punishment behaviour, it would have stopped it very quickly.

I had already been considering this change to be an essential component of how one can use a voting system to monetise development work, but as @valued-customer mentions, the 'stake is all that matters' idea is fundamentally flawed from a social perspective. Rather than eliminate stake in calculations, which I believe would just encourage, amongst other things, bot voting, by causing a modulation of rewards allocation based on reputation, in fact, bots power would be massively reduced, and if they become problematic, they can literally have their Stake silenced.

It is very important to consider, that this is both a financial and social network system. Both factors should equally weigh in everything.

Regarding the alts of the preminers

I think it should be obvious that many of the premined accounts, especially and notably @berniesanders @nextgencrypto @randowhale, and others, have shifted a lot of their premine into new, post-premine accounts.

To deal with these scoundrel (s) I propose that the precise vests that are in question, get tracked through the whole pathway. Not the votes they assign, just the actual original VESTS tied up in that SP.

This may be a complicated algorithtm to process, and may be the biggest hold-up in getting the chain sanitised. Other alternatives, have too much human judgement factor in them. It is not possible to alter the distortion of the distribution that came about from their voting power being (ab)used, however, not all of that voting was bad.

So I will suggest that the sanitisation process will need to include a 'follow the money' process, and I think that it should be simple enough to simply say that the first amount, up to the premined vests, amounts transferred out of those accounts, be subtracted from the destination accounts, and so on, with the flux properly mapped out and before this subtraction is applied, it be put to vote via a post whether the calculations have been correct.

This will suck the air out of all of @bernie's alts as well. We can't be having these people getting away with it so easily. There will be other direct beneficiary accounts that link to these accounts, they will have the fraudulent VESTS removed.


I invite everyone who is interested in being part of this fork, or even just to make your opinion known, to comment on any element of these proposals, and that the results of the non-frivolous, non-malicious commentary will help set the work order.

  1. I can see some difficulties with tracking the pre-mined VESTS, and removing them from recipient accounts, I can't quite imagine the algorithm yet, though I have some ideas. I guess in your view, these accounts are in receipt of stolen goods, and need to return them to the pool, but I'm not sure how this affects balances across the board. Also, having the pre-mined VESTS added to the initial rewards pool is an interesting idea, but if done, the distribution time-frame needs to be extended over around six months in my view, and so the out-flow carefully calibrated. Once you know the balance of these pre-mined VESTS, you'd have a better idea of what to do with them. Would excluding them altogether not be more prudent from the perspective of the SEC (if there's an issue there), or does this lead to some accounting problem I'm missing? I'd like to know the percentage of this pre-mine.
  2. Good change I think, but I don't really understand the purpose of SBD, there may be a reason I don't know.
  3. Great change.
  4. Great change.
  5. Not sure about this, it's a bit confusing. If the voting formula changes once elected, couldn't it cause unstable witness selection (disequilibrium), where elected witnesses would oscillate each time it is recalculated?
  6. Not sure about this. If you're meaning a comment based referendum, there would need to be some alterations to prevent such discussion from being distorted/dominated by the early responders. Also, who would run this, and how would even the wording be decided?
  7. Great change. Perhaps in the short-term, a ledger only mode for the steemd RPC nodes, as that is all the exchanges need.
  8. Complicated one, I'd need to think/read more about it. I don't even currently know how reputations are calculated.

I can see Steem Inc. doing (7) when forced to by the lack of willing RPC node participants, but currently @gtg thinks it can be probably be run with an Amazon EC2 i3.2xlarge 61GB RAM ($313/month). If true, the requirements don't seem to be huge as yet, though obviously this architecture won't scale to Facebook size! @netuoso who has just set up a new RPC node due to recent outages, says full RPC nodes are currently using 70GB+, but as we know this is growing fast. An Amazon EC2 i3.4xlarge has 122GB, costs $625/month, and would probably cope for a few more months I guess. In my mind, one issue is that there's no reward for handling RPC requests (like there is for making blocks). It would probably require too much overhead to do so though.

I am currently on the fence about your fork, but depending on how Steemit handles ongoing structural problems and communication in the next couple of months, and if they don't implement (3), (4) and (7), it could gain traction I think.

If there is a genuine threat from regulators, then I can see how (1) might help, and how it would be popular, and rejuvenate the platform. I just can't quite bring myself, to conclude that the pre-mining was morally wrong though, even though the regulators and many people may disagree.

Very interesting!

one. The tracking of premined vests should not be difficult. They all have a chain of hashes linking them together. Standard double entry ledger blockchain systems have a root, an initial creation of the token, and every spend has a chain that branches into a tree. From a calculation perspective it is easy to just count them for the rewards pool, but to make sure they are removed from the eventual places they end up in their terminals, the whole tree has to be built.

five. Yes, you have a point about how this changes the vote scores, but this only happens when the witness activates and deactivates, and only affects the ranking. It's just another event that triggers a vote rank recalculation, just like any vote change, so it's not a big change. If a witness goes offline, its non-witness vote pattern is returned, same as if it was manually changed. It enforces the impossibility of direct collusion via the use of vote withdrawal as a blackmail method.

six. The timeline on on quorums is naturally created by the reward scheme, and 1 week is plenty of time for people to structure their votes. It could perhaps be simpler to implement it as a special post type, where first a specific user account (like or something similar) automatically makes a regular post at a given date and time, and each comment contains a proposal from a user. The post that gets the highest reward then becomes the mandated next HF proposal, the dev team implements it, and the witnesses update, or not, to the relevant tag, rebuild, restart, replay, and if over 13 switch, it becomes consensus, and any nodes in the top 19 are pushed out of the top 19 until they update.

These proposals don't all need to be implemented, but I think the sanitizing and self-vote rules must be in the fork. I'm pretty much not going to budge on those two issues because they are such simple examples of nPD.

As for rewarding RPC, for service, this requires a proof of service protocol. It may add a little overhead, as I think it would require intermediaries who act as witnesses in the transaction, and there has to be rules about what constitutes a payable service, and what is spam. I have already done a lot of work towards elaborating a protocol for this.

  1. Fully withdrawing the pre-mined SP will probably leave some accounts with negative balances though. If they are only be depleted to zero (or a minimum functional SP), then you haven't fully dealt with the the pre-mining issue as far as possible regulator intervention goes. I guess you may be able to add some amount to all balances to reach zero?
  2. I like this kind of idea, it's just the specifics need to work smoothly.
  3. That makes sense.

I understand the basis of your fork is moral, and respect that.

I'd be interested in what you've done on proof of service and spam identification.

I did a lot of work on Proof of Service mechanisms this back when I was doing Dawn... Mainly it functions by a chain of signatures from each party in the process, eg, client signs query, intermediary signs witness, provider signs certificate, produces result, signs, sends back via intermediary, who signs witness, and back. every party in the circuit gets a payment for doing this, so when the client gets the certificate, they ack and then send a service cert to the witnesses who then calculate the relevant reward for each party in the loop.

The part that does the antispamming function has to do with diminishing rewards when the client and server are known, by the ledger, to have business dealings. The intermediary also must not have dealings with either side aside from intermediation. If they do, the rewards are reduced in accordance with the amount of dealings between them. This prevents collusion, as at least one mechanism for implementing this.

It just reminds me of how bleeding stupid it is to let witnesses vote for each other. This clearly is collusion, no matter how honestly each witness deals, it's still collusion.

It sounds clever. I still haven't quiet got my head around the architectures/flows of these decentralised cryptographic systems. It's quite a leap from the data analysis work I usually do!

I feel like I need to read some books or watch some tutorials/lectures on it to be honest. Any suggestions?

I haven't the faintest idea. I just dreamed it up. Maybe what I need to suggest is you do a bit of study of law. Most of these models are directly cognate to legal procedures. Notaries, witnesses, representative/proxies, etc etc. I did a lot of study of especially the laws of bills and titles, and it's all exactly the same stuff here in crypto-land. The crypto part really is just signatures, sealing, and, sometimes, confidentiality, in digital form.

Well, you, and a few other very smart people ;)

I see what you're saying about the models corresponding to legal processes though - good point. I probably need to familiarise myself with some cryptocurrency systems source code too when I've time.

It's not a simple subject, there is a lot to learn, even just basics to do with getting the build environments working. I'm sitting here at the moment, goddamned if I am setting environment variables to tell the stupid cmake where to find it's precious c++ compiler, and turns out it's only respecting me if I make soft links from the right version to the stupid default old school cc and c++

shakes head

C++ compilers really are retarded. I am gonna do the masochist thing for a good cause here, but I tell ya, once Calibrae is online, other people with more experience and C++ love can work on it, while I build a proper system in Go.

"I'd like to know the percentage of this pre-mine." - To my understanding we're talking about of very big percentages here. For a first few days only select few were mining as the Steemit Inc didn't release any info on how to do it. So select few got majority of the stake for being in the inside, and to add to that, the inflation was 100% or something similarly crazy after that. So these people kept gaining crazy number of Steem for doing literally nothing for a long time. Dan for example, was gaining couple steem every second or so. And this is the problem with Steem.

I think you can find more information about the whole fiasco start from bitcointalk forums.

Thanks for that. I'll have a look at that when I've some more time.

The strange thing is, I bet some of them regret that the process happened in quite that way, but are trapped by it now.

I saw your project, it looks interesting, but the search doesn't seem to work at the moment... is that right?

Who knows what they were thinking but proper and fair distribution had no part in it. Maybe they were only going for short term profits. I just read that the Steem blockchain has grown 50% in size in the last 6 weeks. That can't last very long.

I'm glad you find the project interesting. I started working on it before I even knew of Steemit and it's a "learn by doing" -kind of a thing. The search is not working currently as I don't have "testing sandbox" and make changes directly to the live version and these changes are still somewhat underway. Clicking on tags however does work to some extent at least.

Yeah, how many GB is it now? I'm thinking the problem is in the RPC nodes index to the blockchain, this seems to be unstable unless it's in RAM (as @elfspice says), but does work to some extent using very fast swap with SSDs in RAID 1. I get the feeling it's not too hard to solve though to be honest, but I'm still learning about the infrastructure, and the information is hard to collate.

I've been considering working with Steem Connect soon too, I would have to convince myself the platform has a future, before I put more time into it!

From elfspice - "about 50% growth in under 6 weeks since I last saw the chain was 14gb, it is now 22gb"

I'm not that technical that I could provide any input on this issues. They however do make me worried since I care about the decentralization part in a big way.

My little project doesn't really need Steem, it posts all data to its own database and to Steem so it's fine even if it implodes. Sad, but fine.

I've seen his post now... it is pretty crazy!

I strongly support many of these changes. Particularly, if the SEC decides to come after Steem because of the premining issue, Calibrae may well prove immune, because of the changes you intend.

I would, however, not disburse all those vests right off. There has been some fluctuation in rewards due to HF19, and how the pool was drained quickly. I reckon maintaining more of a pool could moderate fluctuations, and people would find that easier to count on.

I was raised in Alaska, and royalties on the oil industry were accumulated in a permanent fund. The interest generated from this fund not only made it possible for Alaska to not tax it's citizens, it actually paid them by disbursing interest accrued on the account that was not required by state government.

When I was a kid, Alaska paid us ~$1,000/year, just for being an Alaskan.

Give this some thought. It's possible that keeping a healthy vest fund, rather than simply expending that fund quickly, may be something beneficial to the platform, and the community.

I also like the idea of one issue per HF. HF19 was difficult to parse, because it did two diametrically opposed things. Did selfvoting dramatically increase because minnow votes were worth more, or because there were far fewer votes being cast?

While I reckon the latter more convincing, I've seen no data that proves either supposition. One issue per HF would make it much easier to understand the difference between what was expected to happen, and what did happen, as a result of the change.

Have you considered removing the weighting of VP by SP, and thus removing the currency from the SEC's jurisdiction? I have posted and commented profusely on other problems that arise from this 'feature' of Steemit.

However, getting the SEC off our backs is pretty damn compelling.

Thanks for your hard work and careful thought that has gone into this post!

I can see the sense in keeping a bigger pool. This also allows more elasticity in the reward calculation scheme. Bear in mind that I do intend to add the self-hosting code down the track, but that will be part of a total re-implementation based on SporeDB. I'm not sure what exactly this would involve, it seems to me like this might be a subject for a post-release hardfork.

I want to specifically point out some points that maybe you didn't connect directly - direct self voting is banned, as now added as item 8, using reputation to modulate rewards allocation. There does have to be an initial pool or the rewards will be horrible to begin with. The distribution will not follow the patterns we see here, if there is no direct self vote, and vote power is reduced by reputation position. It will help ensure, in theory, that the distribution balances properly. I think a slow and gentle path to equilibrium is better - yes, at first there will be a frenzy, but it will take not a very long time for people to realise that the numbers they see mean in reality about 6.9% per week of that reward can be seen a week after, and so on. So, it will mean a lot of high rep, small accounts will power up a lot.

This will help level the playing field sooner, I think.

I have thought a lot about the issue of stake and weight of votes, and I don't see how unbinding them produces a good result. I do, however, think that reputation scores should have an influence on payouts. This way, a big Stake account can be punished in its ability to influence by downvoting from high reputation accounts. If the big stakeholder returns to good behaviour, and maintains it, they regain their influence.

I have discussed this in my proposals for how to monetise code using votes, where the ability to use stake in a negative way is very patently obvious. I don't think it is any less applicable to the forum in general. I might then perhaps make an 8th proposal that reputation becomes a factor in rewards calculation. The current scheme with reputation is only to implement community driven censure, a way of punishing bad behaviour. But bad behaviour includes using one's stake in ways considered negative by the community.

I only commented sparely, because I am all too given to bloviation =p

I do like very much that you intend to mitigate stake with rep. I reckon it's a great step forward, as rep is community vetting (which will matter much more when bots are incapable of influencing it).

I am not a coder, and much of the guts of the system you are making are above my pay grade. I am also mentally incapable of parsing further the rep/stake weighting of VP, at least until I see a particular implementation.

I'll look forward to further development. I am greatly interested!

It will be interesting to see if I am even capable of doing this at all! But I made great progress today, and I will be making daily posts from now on, about this.

Your changes seem sensible, but I'd need to know more about the original intent to be sure.

I'd also take a look at what changes the Russian fork has done (Golos?). AFAIK they have two payouts, one after 24 hrs, and one after 30 days, which makes total sense to me as most earning is usually done before 24 hrs anyway, but 7 days is far too short to be able to discover valuable stuff. Ideally I think it should be possible to earn for longer also.

Another thing to consider is built-in language support. If different languages had been properly supported the Russian fork might have been avoided.

Yeah, the language stuff - that is the fault of the total lack of localisation of Condenser, the interface. That will be high on the agenda to fix, as will amending the post data to include a language, so users can easily filter for language instead of depending on users placing a language tag like cn or ru.

Because that is interface side, that is lower in priority, however, having said that, it would be nothing at all, almost, to add 'preferred language' to the 'settings' configuration (json_data) and have that automatically place and filter for the appropriate language tag. I mean, the tags... sheesh, I remember when it was coded to search for 4 spaces and didn't collapse them automatically (I already wrote scripts that filter and alter inputs, trimming excess whitespace and double spaces, when I wrote a script to generate new passwords for users).

However, now that I have started to get the github organised, with the team starting to develop, I am going to start learning how to work with the team project management tools. This will let me lay out all the issues that need dealing with, and set them in a proper priority order.

The rewards payout scheme... I think 24 was too short, and 30 was too long. To me, 7 days is just right. However, to be able to edit posts afterwards, and to expose the edit history, that would be very useful. Also, to be able to 'renew' the post, reopening it for a new rewards vote round.

These are very good changes and suggestions, and surely will be on the list for hardforks. I may have to make the first few months of forks include a lot more of these kinds of relatively non-financial related function changes each round.

Most of the changes I have proposed in this post are actually removal of overly complex or stupid elements or bad game mechanics, or both. They will not take so long to implement as the sorts of changes you discuss and I mention here.

Thanks, you've obviously thought about these things. I agree that 30 days is too long default for payout, but that you stop earning money after 7 days is too short in my opinion. Would therefore be interesting to know how it works for Golos. To renew, is an interesting idea, I've thought that perhaps the author could choose length himself, but then he'll also control time for the curation...

BTW: Take a look at @theluke's OpenSteem if you haven't, should be relevant.

I can't figure out what opensteem is trying to do... it sounds like a standards project, which seems in-credible for a single platform...

I think renew is a logical, obvious option. You can just repost, otherwise, but the interface doesn't expose the source code easily for you, so doing this can be a pain in the ass. Like everything, that should not be, in steem.

@elfspice I like the honorable discussion you are posting and sharing.
I support improving and advancing the steem blockchain and the social media experiment.
I've said this a few times, steemit being first doesn't mean it will survive or remain in first place should a competitor enter with structurally focused content creation support.

Anyway, I observed a few problems and posted my observations about steemit in this open letter last month:
Open Letter To Steem and EOS Programmers and Application developers

Now, I am becoming aware of so many more controversial issues that need to be addressed too.
If more posts and resteems go forward this will be more likely to get the attention of executives. That is my wish. The next hard fork is already shaping up for great controversy - thanks again!

no problem, but I'm getting out as soon as I get this fork up and running.

@elfspice I wish you well wherever you go, meanwhile I look forward to your posts with truth bombs and data dumps.
There are other social media platforms coming to a blockchain, I hope they will be more transparent and structurally focused on the ease of quality content creation.
Will you be looking into the other blockchain devs?

I already have a plan that I was going to go forward with before @benjojo kinda made it clear that there is a lot of worthwhile people here who need a more immediate solution to the ongoing and likely very slow to be resolved (if ever) problems on this platform.

Once Calibrae is up and running, it will continue to be run as the steem fork, and with the altered rules and policies, there will be a small developer group who will be tasked with implementing the hard forks that are proposed and voted on in monthly quorums.

But I will be shifting my focus towards reimplementing the platform based on SporeDB, which will be called go-calibrae, and the initial starting point of the fork can be found here:

This will reimplement the state of Calibrae, but with a radically different, and much more performance optimised replication strategy and validation protocol, based on more up to date algorithms than the ones used in most existing blockchains. It will not even be a blockchain, it will more directly, and rapidly be able to replicate, the shared memory files of the database will be shared between nodes with similar strategies as used in Bittorrent, and will have an unchanging format, unlike the Graphene system which every new version increment requires a total regeneration of the database, a task which now entails processing a log that is over 23 gigabytes.

@elfspice I thought the blockchain tech with supercomputers was superior to Torrents but I actually like Torrents and your comment gives me hope it will survive with other peer technologies. BitChute is another hopeful sign.

But back to the subject here, I used the steemit search tool for monthly quorums and didn't find a location.
If you can, please provide info on the quorums - like when and the url.
With the Calibrae fork, what more can we minnows do to assist?

if there is a hummingbird on it, the post is about Calibrae. The one you are looking for is this very post.

Implementing it requires writing a bot, and should be handled by the dev team.

All of the changes in this post must be made before the system goes live, because of various reasons, not least of which such as 8, which will allow bots to be squashed. I am going to go into more details about other ways to limit data rates, memos, for example, need to be limited in size, I have seen too many, posted thousands of times, I see no reason why a) memos should be more than 140 characters, or b) why a person should be able to make more than about 20 transfers a day.

This is what this post is for, to discuss these points. I may suggest that I will later make a post for this that lays these things out in individual comments then people can comment and upvote to indicate things, with decline payout blah blah. Not that it matters if the SS Steem-tanic drops under the waves, anyway, whether I get paid. Besides that, I'm already devoting all my time to this, and that means my living costs are a cost to me to do this.

@elfspice Ha-ha I've been trailing the hummingbird posts and I hope our reposts and upvotes help you.
The idea to remove bad bots is a awesome feature - I was told it was impossible because accounts are permanent.
The hard fork becomes more appealing each time I read the details in the threads - so yes a dedicated post that lays it all all out for a permanent discussion room that allows us to note new comments as they are made or new upvotes - though the upvote feature is lost after a week so that won't work...
Maybe you would support a team- community effort to weekly update the old post that lays it all out and keep a tally of votes on the open issues.
I see the benefit of comments and voting to show what the community wants - but again the weight to votes skews that idea to shreds as a whale vote or downvote wrecks havoc

I don't know - maybe a chatroom would be better rather than steemit?
I'm just thinking out loud - you are too busy to get bogged down with this.
Do what needs to be done and ask the community to assist you when you need it - until then, cheers m8! is the invite to the discord chat of steempunks, where I would very much like ongoing discussions to be made. I also will add a wiki to the calibrd repository where this can be managed as a shared document.

I would very much appreciate it if I can have the participation of a few good people to help manage the Calibrae team, if you have a github account, or make one, I can create a Calibrae team on github, and add you to it, and add you as a contributor to the repositories, and you can help as well.

Right now, I need a nap. I was up until 2am last night doing communications and getting the repositories in order, but as soon as I'm refreshed (the dawn woke me up, of course) I will get on it. Gimme a few hours...

I don't have a problem with any of the 7 at first glance. I'll come back and see what others may be discussing, and take that into account.

What do you call a user? Calibraen? Gotta get the t-shirts printed.


Sorta sounds a bit like Gallifrey...

Theyll be caled a Calibrator! and hey man i am scared, i posted a steemit poost about how a steemit user came over to my house and gifted me a ledger nano S ! and i went on to show how i posted a CRAIGHLSIt ad for steemit! but my ppst only got 30 cents and my posst NEVER do that theyre all always like at $10 immeidtaly after iu post sosiopmethinsg wrong :( maybe my followers all powered down? I notcie ur up to 100 k ,an, can u plz help me out with my latst post. I just upvoted all ur recent commenst!

hey man 5 days was ur last one, where u ben?
we need u back hre full time!

I noted that @berniesanders commented on @dwinblood's post about investigating flagging that there was no premining.

I don't agree, and wonder if denial may figure into some of the reason for that comment.

Just thought I'd mention it to you, as you may have relevant comment.

yeah, I can show you him contradicting that in response to a comment I made. just give me a minute (and if he redacted it, i'll find the previous version where he admitted it).

it says this was edited, but I can't seem to find the initial version, but that's what I saw anyway

I did see that conversation, and it is largely why I find the recent denial that there was any premining to be incorrect.

I recall linking you to a source on the initial formation of Steem(it), and that included a reset which wiped out competing mining interests, while leaving that particular party's mining efforts intact.

Due to the fact that Steem became publicly traded, I reckon that's not a good and lawful position to be in, should the SEC decide to concern themselves about it.

I just want the good features of Steemit to no longer be held back by financial shenanigans. I hope you can pull it off!

I'll be doing my best. I made good progress today, and I'll be making daily reports.

Initial vests should be started from some initial amount, suppose 1, like a new account on Steemit.
Otherwise the accumulative effects of votes by premind accounts remain.
Being one of the earliest users is a big enough advantage.
There should be no snapshot of existing accounts and posts.
Rewarding of posts must not be limited by time.
This is dailymotion's and youtube's biggest advantage over Steemit in terms of financial rewards and fairness.
The currency should have a fixed amount, but this may be the biggest problem to implement and require the most fundamental changes.
Powering down should be immediate, to give people control over their property.
Like in Steemit, the initial free voting power must not be for sale, and this way an account is guaranteed to always have a positive voting power, and people do not get free currency just by joining.
Multiple accounts are not a lesser problem than premined accounts and self voting.
Self voting by a different account of the same user is not any worse than self voting of 1 account.

I have been talking to pfunk about the history of the initial mine, and it was quite enlightening. What I decided to do, was basically, any account that has had any substantial amount of VESTS transferred to it, or used to create it, that trace back to those original 800,000 or so Steem tokens (which split, by the way, by 1000x or maybe more), will simply be deleted.

We do not want these people to easily be able to come back on, they will have to buy accounts to join. New users will have to pay also, and it will be a priority to implement a 'freemium' account that cannot have stake delegated to it until it reaches some amount of Stake. It would be nice to have this ready before going live, to be honest.

The deleted accounts current balances at the snapshot block, will be expressed in VESTS and this is the new JUICE currency. and become the initial rewards pool.

I am not aiming to do anything for the initial launch beyond simply removing things that don't belong or have no use. You can see that virtually every change is a removal of something. The sanitizing of the chain is going to be a 100% removal. But I think that putting that into the rewards pool is a big incentive and a mechanism that will help equilibriate, quickly, the true social-reputation tree, since, as I mentioned. This will be constrained by these following factors:

  1. reputation scores, based on network total, divided into a range, reduce rewards allocation (thus zero or negative accounts cannot assign rewards until other users recover their reputation, by posting and being upvoted).

  2. users cannot vote on their own posts directly

  3. accounts will not activate without authorisation from a Captcha to unlock them. This will slow down botfarmers from being able to flood the network quickly with bot transactions

The whole purpose of having a powerdown liquidity limitation is precisely about restricting the change in in- versus out-flows of assets. Cryptocurrencies all tend to be too fast at this, and it makes margin trading impossible. Volatility is a bad thing in any currency.

A system like Steem depends on ongoing issuance rates, and it is a cost to holders of the tokens. Unlike simple currencies, there actually is a reason to keep issuing tokens indefinitely. Without this allocation, there cannot be rewards, and this is the very foundation of the concept. This is how it will, in the future, pay hosters of media and other files, this is how the providers of database query services will get paid.

I would suggest that your idea of what this kind of system is about, is not very clear or consistent, and probably tainted by what you know about non-digital and blockchain currencies, and perhaps also by a lack of knowledge about law/finance concepts like bills of exchange and property registries.

Like you say, a currency does not need additional issuance over time, at all. This is just a mechanism for exploitation by the issuers who have control over where it goes. This is controlled in a platform like this, by the collective will, the sum of everyone's votes, so this takes away the negative side of this, and makes it also, very important, that the rules governing the granting of this, by the regulators of the network (the witnesses, and indirectly, the developers, and in my scheme, this is driven by user demand, what these rules are), are strictly enforced, and consensual.

It is precisely the fact that there is so many rules in Steem, and so many of them are not consensual. You may contend that such rules cannot be consensual. I beg to differ. Except for maybe two or 3, the 10 commandments are axiomatically consensual. Thus, so shall it be for Calibrae. The rules will be as simple as possible, and as far as possible, enforced directly by the summation of the actions of users.

By this answer I concur that the worst of Steemit and STEEM's flaws are expected to remain in calibrae.
If an account got upvotes from a preminer, one of its proxies or one of its recursive benefactors, the effects of premining stay in tact in your platform.
If you charge people to join, you kill your platform before it is born.
Growing your community will be nearly impossible if you kept it free as in Steemit.
I could not find where you replied about Steemit's and's reward system having timeout on rewards, as opposed to dailymotion's and youtube's.
Why should a potential owner of a stake care about margin trading so much that he will agree to freeze his own's control over his stake?

The preminer accounts are going to be DELETED.

If the preminer ever sent any substantial amount of Steem or SBD to this account you speak of, it will be DELETED.

People will be able to join, with accounts that cannot have delegation added until they reach the Stake equivalent of 500SP (about 12,000 Stake, on an estimate), for zero cost.

I used to play WoW. I remember that was how they stopped spammy signups. You could work your way up to a full account, in time, but you couldn't have another account boost you, without paying, basically (powering up the account is paying).

The 7 day reward schedule. It was decided upon for some very good reasons. 1 day and 30 days were both very wrong.

Rewarding content for being viewed requires a system to certify non abusive viewing, to reward the content. This is a future goal that I have already got a fairly comprehensive model about how to implement and prevent abuse. I don't think I have finished designing that yet, but I know what I have designed will work to a fairly good degree.

Margin trading is a very valuable part of a financial ecosystem. It is how you get interest bearing deposits, that have zero risk of default. Thats' what 'term deposits' are, at least, in theory, they can be, when operated by an exchange. Go have a look at Bitfinex's margin lending facilities. You can make money by locking up your Bitcoins to lend to margin traders there. I know it intimately because I was trading on margin. I should have been lending for margin traders but I was desperate to increase my capital.

I did not claim should reward posts upon viewing, nor does youtube works this way, and about dailymotion IDK enough regarding this aspect.
Youtube rewards upon ad viewed for longer than 15 seconds.
An upvote based system should rewards upon upvotes, which is fine, but there should be no time limit on rewarding upvotes.
This is what I meant before.
Regarding your joining stipulations, I failed to comprehend them.
Regarding what a substantial amount of rewards from a preminer, I disagree, since by doing so you both complicate matters and retain some of the problem you seem to be obsessed about.
Regarding margin, you do not convince me, since I do not believe that comfortability for margin traders should be a matter of highest regard when designing a currency system.

Where do you get this idea that Youtube and Daily motion do not reward based on viewings?

You contradict yourself in the second paragraph.

Oh, so, upvotes on content that is old, should be rewarded, in your opinion?

Ok, so, propose a mechanism by which this cannot be abused. Every rewards system has to have antiabuse measures. Each different mechanism requires a different measure.

I have thought not that deeply about how to reward ongoing upvotes, but, I think you also just stated that subsequent upvotes do not assign rewards, only advertising. The advertising is a mechanism of proof of service. So that comes back to what I said: that the ongoing rewards mechanism for content has to be based on proof of service, not voting. A voting mechanism for rewards has entirely different constraints, and it is not for nothing that Steem has settled on 7 days.

You will have to do a lot more creative thinking to offer a substantial potential solution, and your attitude of adversary will also have to change if you want to gain access to your ability to think creatively.

Youtube pays upon # of ads viewed for more than 15 secs, not on immediate views of the content itself.
Where is the contradiction?
So is youtube wrong when an uploader of an ATG video keeps ripping the rewards of his great work?
Limiting to 7 days and even 2 months incentives the spirit of spam that ruined Steemit and
There must be no time limit on rewards.
Choosing votes over the youtube criteria might still be fine, but must not be limited with time.
Youtube is a means of passive income while Steemit is a means of frequent creation of spam.
Obviously there is spam content on youtube and quality content on Steemit, but their corresponding part out of the wholes differ because of the difference in the rewarding systems.
Youtube will keep beating Steemit and everything similar to steemit or tsu because of it.
Your proposals are farther from abuse prevention than mine are, and I never claimed that my proposals are perfect against abuse, just better than Steemit and your proposals which are too similar to Steemit in most of its faults and even add a new fault or 2 and then some complication.

Not sure how the removal of pre-mining related accounts will remain objective, but I trust you'll publish the algorithm. I like the idea of preventing the receipt of delegation until an SP threshold is reached.

Yes, I will be publishing the algorithm well before it generates the genesis database, and I will also make sure that anyone with even a little technical skills will be able to download, compile, and replicate my results. That reminds me, actually, this is why I had to create this simplified build system that I have just almost done today, that let me run steemd on ubuntu 17.04, but it bugged out on 16.04 >_<

It may take longer than I anticipate to do all of this stuff, and maybe Stinc will take some lessons from my lectern, but I don't care. I'm doing this for the community, they just will have to make sure I get enough rewards that I can keep doing it, or it will be on them why I had to quit.

I really think you're providing a very valuable service whichever way it goes. Even if your progress only goads them into taking the appropriate steps for addressing the long-term good of the platform it will beneficial, and your work possibly of historical significance.

I just thought, when you can, it would be interesting to see what the distribution would look like after removal of the pre-mine accounts you propose.
I've always found this graphic to be a bit depressing, and wondered how much it would change.

The long tail is normal in this kind of distribution. But I'd hazard a guess that all 45 of those Legend accounts are preminers, and maybe 10 of Superheroes, and probably 20k+ of those Newbie accounts are preminer's alts.
Oh, just cover up the 'legend' part of the graph, and notice how the brackets scale out. Still about 65% is Superhero, out of superhero and lower. And the hero, same distribution.

I think that removing them will just remove that top section. That value is not real, and they won't be able to realise it, in truth. It's a typical newbie trader mistake to think you can control that much stake and milk it. If they all sold at once, the price would be under a cent.

The preminers are incompetent at managing their shit, and burn their power most especially with bad behaviour that is slowly destroying their reputation scores. They think they are being clever spamming the network with hlow reputation bots but they perhaps have not looked at the reputation calculation formulas, and the fact that they basically, work.

Right that many? If you are pushing ahead with this, you'd get the support of the wealthiest non-pre-miners I presume, as they'd become the new (albeit weaker) oligarchy?

Yeah, I know what you mean. I think the biggest problem with the reputation scores is how self-voting raises them. Take away self-voting, and it's less of an issue.

I didn't even think about how self voting boosts reputation. Now that is a clear example of a bug, if I ever saw one.

Yup, the purpose of The Purge, as I am going to call it, is precisely to propel the real stakeholders to the whale positions. They all got there mostly by risking their money for the platform, and they, also, are the ones whose assets have been stripped the most by the preminers. When The Purge is successful, and 99+% of the preminer's crap has been removed and placed into the rewards pool, and everyone has 2 weeks warning to know it's coming, so they can be on the new platform the minute it goes live, these legit whales will be distributing the premined stake back to the users. This will also further reinforce the structure against the remnant premined, laundered accounts that may remain.

There you go, my latest edition:

You already rejected most of it, but acted as if you agree with other parts of it, praising a moderated, centralized platform for being what it is.
If you want calibrae to be better than steemit, this is what you should do.
To win you need to accept my solution.

You think I haven't been campaigning to improve this platform since I arrived last year? You don't think I have already got to know very well exactly what their SOP is?

I resisted making a fork for a very long time, once the licence was changed to MIT. A very long time I was just going to leave and build something from scratch. But I am a big believer in code reuse, and I know that I can make something better out of it, so I am.

Good luck with your campaign. When Calibrae is ready, you will be no less welcome than anyone else to come along and put in your 2 cents on anything and everything. When the second phase, with the total rewrite is done, the code itself will be like the forum, where programmers can earn by making contributions to it.

The fork is just phase 1 of the process. Phase two will be forking SporeDB to make it technically far more robust, SporeDB can remain functional down to only one non-byzantine node (in theory, according to the whitepaper), whereas only 12 of the top 19 witness nodes have to be compromised here and you can completely control the chain.

If you think that Calibrae is going to be a centralised platform, you obviously haven't read enough about what is being proposed to really have a valid basis to comment.

There is more than a few things in the design of Steem that make it so liable to become centralised, the witness election, with its multiplicative 30 votes per account (each vote counts with 100% of stake), combined with the huge stakes that the developers and a little band of outsiders have built, and this is also why the platform is constantly wracked with paranoia, distrust, and anger. The developers don't have quite as much control as they would like, but they are fighting with the outsiders.

Have a look at the witness leaderboard now. For the first time since the beginning, furion and smooth are out of the top 19. I would expect that this is for a reason, as Smooth caused a big problem that led to HF19, and furion just let the cat out of the bag about how incredibly resource hungry steem RPC nodes are. By my commenting on the proposal post about how they are going to multithread the RPC function, I won myself some more flags, even though I am right - it is now impossible for anyone without a big budget to run a Steem RPC node, and we are all expected to trust and rely on Gandalf or Steemit's RPC nodes. Some decentralised platform... not even 15 months old and it's impossible to run your own RPC to develop apps unless you got hundreds of dollars a month to run the thing, or can afford to spend over $3000 on a server with over 128Gb (and growing requirements) of memory.

The guys at the top have no concept of how far out of touch they have got with the userbase, and you have no idea just how far gone this thing is. I give the platform 3 months at best. The only way they can save themselves from failure due to engineering error, is to plough probably at least $200,000 bux into development and paying a lot of coders. They are probably now doing that, but I'm abandoning a platform that gives lip service to decentralisation.

It was vindication to have furion confirm that I was not incompetent, but rather that the platform has grown so humongous that my 50gb memory 10 core SSD VPS cannot replay the chain. I have had just such a VPS running the replay for over a week now, and it's still nowhere near to finished.

Coin Marketplace

STEEM 0.17
TRX 0.03
JST 0.021
BTC 17032.02
ETH 515.95
SBD 1.13