RE: Proposed changes in the Calibrae fork
- 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.
- Good change I think, but I don't really understand the purpose of SBD, there may be a reason I don't know.
- Great change.
- Great change.
- 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?
- 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?
- Great change. Perhaps in the short-term, a ledger only mode for the steemd RPC nodes, as that is all the exchanges need.
- 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 @calibr.ae 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.
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
ccandc++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'm sure your sacrifice will pay off one way or another! I've only ever worked in C++ to do computer vision work when the Python bindings weren't fast enough... not pleasant!
"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 www.folderall.net 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!