Straight up negligent behavior: Bitcoin Private collaborator gave commit access to a user with no reputation / dev history and later allowed them to merge their own flawed code with no peer review. It seems appropriate that they got rekt by a Klingon. https://t.co/mfkRS7YmIjhttps://t.co/x4Nat6dwAR
Lol, Bitcoin Private now claims the hidden premine was a hack.
Reality is if you're a scammer, you always want to find a plausible explanation that shifts the blame to someone else.
No reason to think this is true without overwhelming evidence. https://t.co/DSZKmaQue2
There is no doubt that this is a calamity, but I'm encouraged by the maturity of the developers' response to this issue. These are great lessons for making the project better in the future. It is a setback, but it has not changed what Bitcoin Private is fundamentally about. The road ahead just got harder, but the destination remains the same.
i still own all the btcp from the fork . i think the the secret pre-mine scheme was probably not legal and could attract the wrong kind of attention . that said, i think do both option 1 and option 2 ... if its even salvageable . this project has a bad reputation at this point .
It was not a 'secret pre-mine scheme'. You somehow allege this was a centralized planned action by some group of people. This was open-source code that contained a bug. Nobody caught this bug, despite the code being open-source and available for everyone (both insiders & outsiders) to check. It so happens that someone exploited this bug, but we have no way of knowing who it is.
yeah.. i get it.. when your btc are secure they can't be hacked. .. but its hard for me to believe a blockchain has no commands to see how many coins are minted. i'm not a blockchain dev though. i don't really care that much about it either. i'm not dumping the coins over it or anything. but the story sounds kinda far-fetched sketchy if u ask me .
The CoinMetrics report does a pretty good job to how these extra coins went unnoticed. All things considered, it's great evidence in how we as individuals are always to verify ourselves.
Even in Bitcoin, a project with a far more thorough development process, there was a huge bug back in September that would have allowed bad actors to use an exploit to mint coins over the 21m supply: https://www.coindesk.com/the-latest-bitcoin-bug-was-so-bad-developers-kept-its-full-details-a-secret
BTCP was unlucky that the bug it had did get exploited.
Since you here aren't being rational about this I'd just like to drop in as an outsider to say that I'm very sorry, but your project is dead. This is not PR that you can recover from. Move on to other things now.
In 2010 it survived because it wasn't practically impacted and there wasn't any competition anyway. More recently it doesn't actually matter what happens to "BTC" at all because it's a dead-end anyway, but that bug was theoretical and the chain is fine as far as that goes. It can fund its dead-end hashes because it has a lot of inertia from how people are confused into thinking it's Bitcoin. BTCP doesn't have even that advantage to sustain it. This bug is practically damaging, looks completely unprofessional, and won't be easy to fix. It will probably die from this very quickly.
what a pile of poo. Seriously all of the options are bad. The only options is doing nothing. Are we really going this way now? An adjustable blockchain? let's change this or go back in time if we don't like it? We just ruined all fundamentals where BTC stood for....
I think it was a well written statement and I applaud the quick action taken! This what was required. Well done!
Now it's only about following it through...
Option 1 is obvious. Nuking all "Z" coins would delete the majority of the fraud coins. It appears that 20k of "innocent" coins will go with it, but maybe they could be compensated somehow (a new pre-mine of 20k coins specifically to fill in the gap of the removed ones?).
Option 2 has been an option mentioned in the white paper already, and frankly it needs to be done, but the thought was to do it gradually over the course of two years. Maybe option 3 would be 1+2, and to implement 192,7 and a 12.5 BTCP block reward now, and then continue working at the re-base in peace thereafter? Not the original plan, I know, but an algo-change is long overdue, the block reward needs to come up, so some housekeeping is inevitable. IMHO a series of 2x365 daily soft forks to burn coins would be a confidence nightmare and maybe unknown vulnerabilities to exploits. Maybe better to do the coin burn in one blow...?
An "Option 2" or "Option 3" would be a tough blow to the market cap, but since the market cap seems to be inflated with more than 12 million dead-weight coins anyway that's not good for anyone or anything and only makes the hash-rate situation impossible, there is no way around a coin burn eventually. It would clean up the block chain by cutting off the dead flesh once and for all in a way that would mark a new beginning. Being in "BTC Era 6" with most coins already mined and an impossible block reward (even though set higher than corresponding Bitcoin Core level) combined with a low price has put Bitcoin Private in an impossible situation with PoW and a sense of hopelessness regarding any chance of future longevity. Option 2 would magically turn that situation completely around by bringing it back to "Era 1" with less than 50% coins mined.
Dipping BTCP in the "fountain of youth" will bring such fundamental changes that it would inevitably lead to a new price-discovery process. If you for the sake of discussion look at a future BTCP circulating supply of only 8,500,000 coins through Zclassis's valuation (market cap USD $6,456,729), that would give a price of $0.76. But on top of that comes fundamental analysis of Bitcoin Private's situation and USP. What speaks in favor of a higher price is the chance of the upcoming re-base. A code base from Bitcoin Core v0.17 with all its bells and whistles (Segwit, Lightning network, HD wallets, atomic swaps, all the latest patches, etc) in combination with latest zkSNARKs from Zcash 2.01 (with Sapling) is still something completely unique. Another thing that speaks in favor of a higher price, is the removal of the hopeless PoW situation that Bitcoin Private is in now (which most certainly has been holding back both trading volume and price development since the founding fork of this coin) thus having a coin that is "suddenly" young (Era 1) with much better longevity conditions on top of the other features. Those things together may even push the price well up and beyond the current BTCP price IMHO.
If Zclassic could be considered the expected floor in a new price-discovery process, maybe Zcash is the ceiling? Both Zclassic and Zcash are young coins in "Era 1". A coin-burnt Bitcoin Private would also be a young Era 1 coin, albeit 3 million minted coins "older". Zcash is far better established, it has better market acceptance and a much better liquidity situation. Looking at a future BTCP circulating supply of 8,500,000 coins through Zcash's valuation (market cap USD $335,630,929) gives a price of $39.49. Technologically, a re-based Bitcoin Private will have everything that's good and interesting about Zcash 2.01 (including Sapling), and also all the contemporary Bitcoin 0.17 stuff on top of it, which Zcash simply doesn't have. But this will of course not be enough to push the price beyond Zcash for now, far from it. But it should also be far from Zclassic. So somewhere in between! ;-)
This external audit of our block chain is in a way welcome in my eyes, although I of course am disheartened by the results. But if the exploits (and fraud) that has been uncovered can be handled in a good way, it will probably mean raised confidence in the end.
Very good analysis.The best is the option 3 being so in Era 1 including the changing of the mining algorithm. But it needs a hard fork b4 the Rebase. Is it technically possible to implement the Rebase in the same procedure ?
The coins are in shielded addresses, which means that you can't target them. It's like a big pool, where only the people with the corresponding private key are able to see what their balance is.
An other problem is that if the coins are sent back to unshielded addresses it is not possible to determine their origin, which means that it is also not possible to just wait and see what's coming out of shielded addresses to target the coins.
I'd like to say that this is a perfect example of how privacy can bring both good and bad things. Sadly it is not possible to target addresses. We will only know that on average about 99 coins of 100 coming out of shielded addresses were created illegitimately.
I also do not like the idea of using a nuke to eliminate the threat, but in this case it happens that the threat is located entirely in a specific area and represents 99% of its total population. In such a case a 1/100 collateral damage is not a bad trade to solve such a problem. We are talking about the survival of BTCP.
I have some coins in shielded addresses, and I will vote to destroy them. For the good of BTCP.
Also such a hardfork could be an opportunity to change the mining algo.
People with coins in shielded addresses in the new chain will lose them, but nobody will prevent them to keep running and using the old chain, like it is done with ETC. If they really want to.
Hi, I got the first part. The solution I proposed was only for 'if' we can indeed find the bad actor. Of which the chances I feel are extremely slim; someone smart enough to exploit is not generally sloppy enough to drop the ball while cashing out.
Perhaps we could find a way where we can see how the 20.000 legit BTCP that would be destroyed can retain some value.
Generally, I'd vote for immutability of the chain, but I understand that 2m coins is just a bit too high of a number to let it slip.
It will survive. The team did not wait to issue a statement and propose realistic solutions.
Also I can understand why the current dev team could not have been aware of this exploit. First it is code that is not currently used. Secondly they are undermanned.