That's why we stopped giving estimates. We don't know what we don't know. When our conventional mining solution for PTS pointed out that mining was centralizing and unprofitable, a new invention was necessary. Our supporters have watched (and helped) us make that invention in real time - with access to every chin-scratching twist and turn of our thinking. Is that not being treated like adults?
Here's the list of R&D progress we've made pursuing that invention, as summarized by bytemaster a week or so ago. None of it could be anticipated until we did the work, thought the thoughts, listened to input from this forum, scratched our chins and engineered the required breakthroughs:
Yes, I released a white paper on DPOS last week and have implemented a large part of it and will be testing it in the days ahead. Resolving the security model in a way that one can thoroughly understand and prove is secure was a major challenge. You can follow discussions on this forum where about a half dozen variations / iterations where vetted and found wanting... Let me list the evolution:
1) Mining with Momentum... tossed due to centralization and non profitability
2) Transactions as Proof of Stake white paper (Nov 28th, 2013) adjusted mining difficulty by stake. Suffered from weakness on deciding who should produce the next block.
3) Ripple Consensus + TaPOS was the concept in January at the Miami event through Feb, but after attempted implementation we realized it had several deal breakers:
a) the unique node list was an invite-only group and a point of trust
b) the UNL was not compensated in any way
c) the bandwidth requirements / scalability were an issue
4) Fall back on a simple mining + TaPOS and various variations on equations for option 2. All of these variations suffered from many potential attacks and would require many confirmations. It became too complex to analyze. (Feb through March)
5) Single trustee which could be fired... the process was too manual but otherwise sound.
6) Delegated POS this solution has been reviewed, found to be decentralized, fast, and secure without ambiguity. We have finally resolved the issue.
In that time we also identified problems and found solutions to several market manipulation attacks. These need to be implemented, but then we should be good to go.
As you can see R&D is not predictable when you are at the bleeding edge of innovation and solving problems as they are discovered.
We are now much, much stronger than we were then and the total industry value proposition is bigger than ever.
I have been lurking through the forums; this statement just made me register on the forum. If I am reading it correctly, your solution to incorrect estimates (not only BTSX but keyhotee too) is not to provide an estimate any more. So basically, what you are saying is "we will never try to make a correct estimate, so yeah lets leave it?" I am just dumbfounded by this way of thinking.
While I also appreciate the amount of work BM has put in compiling the list. The question really is - why weren't they tried before the snapshot or March dates? Is it going to be I3's policy to make a commitment, generate an interest from the public and then say this doesn't work so trust us for some more time? I guess you might think there is a whole new value proposition here so, I3 can get away with its tardiness.
I also work in the IT industry. Whenever I am asked for an estimate, my efforts are always padded with 30% of rework, rethink and general avoidance of being rushed. So if I need 10, I say 13.
In worst case, if I do cross 13 and there is 14/15th day, I am answerable to my end users. I certainly don't take a stance saying "well, as my estimates have proven wrong, so no estimate from here on."
That said, I understand there must be a lot of stress on BM. So if you can't give a day-wise estimate, how about a week/month estimate. Say we are looking at end of June or Q2 end or Q3 , that allays some nerves and certainly better than "we don't know when we will be ready (will it ever be?)"
Show Posts
a playlist of their DAPs:
