did anyone LOSE BITCOINS as a result of this issue ?? That's what really matters ..
I don't think so besides BTCNuggets, F2Pool, and Antpool for 6 block rewards and wasted time and effort. There were no transactions in the fork except for the first invalid block from BTCNuggets which I believe got confirmed in the correct chain. |
|
|
|
Thanks for the replies, @knightdk. You write: The devs deserve a fat slice of the blame for not programming a reasonable delay (say, 2 weeks) between the "95% majority" event and the activation of the BIP66 rule. That delay would have given a chance for the remaining v2 miners and nodes, as well as more v2 clients, to upgrade to v3. (Using blockchain voting to trigger protocol changes also seems a terrible idea, but that is another discussion.)
I don't think that a delay would have made a difference. BIP66 has been public for months, and so has the clients supporting it. Really the only way I think that the remaining miners would switch is after they realize that their v2 blocks are no longer being accepted because who likes change? I doubt that 1% of the bitcoiners out there know what a BIP is. I doubt that 0.1% of the bitcoiners out there knew that a soft fork due to BIP66 was due to happen this year. A 2-week delay would have allowed the devs to send an alert to all nodes and miners still runing v2 to upgrade immediately or risk being cut off from the network and having their feet eaten by the boogeyman while they sleep. A 2-week delay would also allow any v3 nodes that were turned off to catch up with the blockchain, and determine whether BIP66 was already in force of not. Well forcing everyone to upgrade defeats the purpose of a soft-fork. The idea behind a soft-fork is that the new rules are still valid under the old rules. This makes soft-forks much easier to carry out and they are backwards compatible. What you are suggesting would be to make every soft-fork a hard-fork, which requires that everyone must upgrade otherwise they will be left off of the network. This is much more difficulty to carry out and I think such hard-forks have and will have the delay, alerts sent out, and monitoring of the situation before and after the fork. Also, I would assume that all of the developers of Bitcoin stuff would be on the Bitcoin Development Mailing List (pretty big assumption). This mailing list discusses all of these changes when they come out and anyone following it would know that the BIP66 soft-fork was coming soon. The core devs or F2Pool's own devs may also deserve another fat slice of the blame, for the v3 software allowing v3 miners and nodes to receive blocks from v2-running miners and nodes after BIP66 was activated.
Can't really stop the reception of blocks, but F2Pool's own devs do deserve a lot of the blame for having SPV Mining that did not validate the blocks at all. After BIP66 became active, any v3-running miner, node, or client should have ignored (or have disconnected from) any nodes that it knew were still running version v2. As I said above, this makes it a hard-fork, which is much more dangerous than a soft-fork and much more difficult to do. Also, disconnecting and alienating all nodes running v2 would disconnect more than 1/6 of the network. According to getaddr.bitnodes.io, it appears that more than 1000 nodes out of 6000-ish nodes are running old software, be it Core 0.9.5 or earlier or other old software. This would lose a significant portion of the network, and probably break Bitcoin's credibility. More generally, the core devs approach to protocol changes seems to be like that of an airline that lets a plane take off with a know engine malfunction, and tries to fix it during flight -- because it does not want to alarm or inconvenience the passengers, or get bad exposure in the news...
Maybe... They want to avoid hard-forks because those can more negatively affect Bitcoin than soft-forks do. In situations where a soft-fork is not required, then a soft-fork will be done. And, AFAIK, "SPV mining" is only the most likely theory, not confirmed or proved yet.
I believe that it has been both confirmed and proved by F2Pool and AntPool. |
|
|
|
I am still trying to understand what actually happened.
What I have read is that BTCNuggets, a miner that was still running v2 software, mined a block B'(N) that was valid by v2 criteria but invalid by v3 criteria. Somehow F2Pool, a miner that was running v3 software, received the header of this block and successfully mined a block B'(N+1) that was valid under v3 rules (empty, in fact) except for having an invalid parent. As luck would have it, they also mined another (empty) block B'(N+2) with B'(N+1) as parent. Then AntPool, who was running v3 software too, mined B'(N+3) on top of B'(N+2). And so on; this was the 'bad' branch.
Meanwhile, other miners running v3 software either did not see block B'(N), or saw it and detected that it was not v3-valid; so they ignored it and eventually mined a block B''(N) that was v3-valid. Several v3 miners solved additional v3-valid blocks B''(N+1), B''(N+2), etc. on top B''(N). This was the 'good' branch.
For a while, the bad branch was ahead of the good one, in terms of total work. Fortunately the devs and other bitcoin hackers were watching the blockchain to monitor the onset of BIP66, spotted the problem immediately, alerted F2Pool and AntPool that they were mining a v3-invalid chain, and sent out an alert recommending a 30-confirmation (5 hour) wait for important transactions.
Is this a correct summary of the events?
Pretty much. Some of the many questions that remain:
* How many blocks were actually mined on the bad branch (starting form B'(N)) before it was abandoned?
6 or 7 * Were F2Pool, AntPool, and the other pools that mined on the bad chain running modified versions of the v3 core? If so, what were the modifications?
I believe that they were using custom software for SPV Mining. SPV Mining means that the miner does not validate the block before beginning to mine on it. Thus, when F2Pool and AntPool received the v2 block, they did not verify the block but simply assumed that it was valid. * Did F2Pool realize that the BIP66 rules had already started to apply when they received B'(N) from BTCNuggets? (Say, perhaps it had counted only 949 v3 blocks, or had its counter reset recently, etc.)
Yes, However, as I said above, they were SPV Mining so they did not validate the block which was in fact invalid by the new rules. * How did F2Pool get the header of the invalid block B'(N): directly from BTCNuggets, from a v2-running relay node, or from a v3-running relay node?
Probably from a node that still considered v2 valid such as Core 0.9.3 or lower. * In the standard version of the v3 core software, do miners get the whole parent node and verify its validity?
Yes * Could there be an off-by-one bug in the v3 core software, that would have resulted in F2Pool verifying B'(N) with pre-BIP66 rules instead of BIP66 rules? (Note that a v3-valid node *can* have a v3-invalid parent, if the parent was mined before BIP66 went into effect.)
* If F2Pool knew that BIP66 had kicked in, and got B'(N) from a v2-running miner or node: why was it still accepting transactions, blocks, and block headers from v2-running players, without checking whether such data was v3-valid?
SPV Mining * If F2Pool knew that BIP66 had kicked in, and got B'(N) from a v3-running node: which node was that, and why did it forward the v3-invalid node B'(N) to F2Pool?
It most likely did not come from a v3 node. * If a miner receives a block B(M), how many blocks B(M), B(M-1), B(M-2) etc. should it validate on its own before daring to mine B(M+1) on top of it?
I think it is B(M-6) because that is what the hard fork detection in Bitcoin Core looks for (I think, could be wrong) * Suppose that a miner receives block B(M) and starts validating it, while in parallel mining a new block B(M+1) on top of it; and happens to solve B(M+1) before the validation of B(M) is complete. Should it broadcast B(M+1), or wait until the verification of B(M) is complete?
Ideally they should wait for the verification of B(M), but, we all know that miners are greedy little bastards, and they will most likely not wait for the verification to complete because it could mean the difference between having their block win or having it lose. The devs deserve a fat slice of the blame for not programming a reasonable delay (say, 2 weeks) between the "95% majority" event and the activation of the BIP66 rule. That delay would have given a chance for the remaining v2 miners and nodes, as well as more v2 clients, to upgrade to v3. (Using blockchain voting to trigger protocol changes also seems a terrible idea, but that is another discussion.)
I don't think that a delay would have made a difference. BIP66 has been public for months, and so has the clients supporting it. Really the only way I think that the remaining miners would switch is after they realize that their v2 blocks are no longer being accepted because who likes change? The core devs or F2Pool's own devs may also deserve another fat slice of the blame, for the v3 software allowing v3 miners and nodes to receive blocks from v2-running miners and nodes after BIP66 was activated.
Can't really stop the reception of blocks, but F2Pool's own devs do deserve a lot of the blame for having SPV Mining that did not validate the blocks at all. |
|
|
|
I went to the link for their store, and it is selling all their miners for really cheap. Seems super scammy. Another thing I noticed, Raspberry Pi B+ normally sold for $25 is being sold for $39! What a great deal  |
|
|
|
This is completely right, the whole point of mining is verifying transactions, that it was possible for even some of the miners to circumvent that requirement and then reap the rewards is a tremendous fail of the bitcoin software and as such it's developers.
It is not the Bitcoin Core devs' faults, rather it is the developer who wrote the pool's own software. It is the pool and their developer's faults and their fail because they were selfish and did not write their code to validate the blocks before mining on it began. This is made possible due to the open source nature of Bitcoin. The pool developers are free to write whatever software they want and as long as it conforms to the Bitcoin protocol. |
|
|
|
|
Are you still selling? I need a vcc for google and azure.
|
|
|
|
In this case I see something strange:
1. Execute command bitcoin-cli listunspent take a 5 second and return 107 unspent outputs;
2. After this command bitcoin-cli sendfrom <fromaccount> <tobitcoinaddress> <amount> nevertheless take 40 seconds.
knightdk if you are right, why so much difference in time?
That is interesting. I thought that searching through everything and finding all of the unspent outputs would take up most of the time. The remaining 35 seconds could be from needing to sign each unspent output from a different address if they all went to different addresses and just the creation of the transaction. I'm not quite sure then. |
|
|
|
|
It would be difficult to tamper with the hardware, but not impossible. I suppose you could monitor the network data of your computer. You could watch for anything strange such as your hardware wallet sending data over the internet when it shouldn't.
|
|
|
|
|
How would it work? You could send it through PMs, but not everyone checks PMs, and the PM system already can send to everyone. It is just a fast way to get banned. You could send it through email, but not everyone's email is public, working, or even there.
|
|
|
|
I guess this would mean that whomever owns the domain bitcoin.org is the ruling controller of Bitcoin.
Nope. The code for bitcoin.org is open source and has multiple committers just like Bitcoin does. It is also hosted from github. Actually, I don't think Gavin has commit access to Bitcoin.org, but I'm not sure. See this page: https://bitcoin.org/en/about-us |
|
|
|
He may have sent most, but I don't think he has sent all of the alerts he could also send out an override making that failsafe a double-edged sword. Didn't Gavin send out the alert yesterday?
He cannot override the failsafe. The alert key compromised alert has a fixed message and cannot be canceled. The message is specifically "URGENT: Alert key compromised, upgrade required" From this code block at line 178 in alert.cpp // alert.nID=max is reserved for if the alert key is
// compromised. It must have a pre-defined message,
// must never expire, must apply to all versions,
// and must cancel all previous
// alerts or it will be ignored (so an attacker can't
// send an "everything is OK, don't panic" version that
// cannot be overridden):
int maxInt = std::numeric_limits<int>::max();
if (nID == maxInt)
{
if (!(
nExpiration == maxInt &&
nCancel == (maxInt-1) &&
nMinVer == 0 &&
nMaxVer == maxInt &&
setSubVer.empty() &&
nPriority == maxInt &&
strStatusBar == "URGENT: Alert key compromised, upgrade required"
))
return false;
} Even if he did send out this failsafe alert, it wouldn't do him any good. People would check the bitcoin.org website where they got the client and not go to Gavin for the client. If Gavin committed code to change the alert key and put the new client on the bitcoin.org website, other committers can revert that change and remove his commit privileges thus preventing Gavin from changing the alert key to something that only he has. The other core devs can then change the alert key, put up the message about alert key compromised on the network status page (don't need to send the message, Gavin already did it) and put up the new client on bitcoin.org without Gavin's interference. |
|
|
|
What was the new rule from BIP66 that v3 blocks now follow? I understood that SPV miners were ignored the validation step so they were building blocks on an invalid chain but what was the specific difference in block structure b/t v2 and v3?
v3 requires that all transactions use strict DER signatures. However, it is not bip66 that caused the problem, it is the fact that the 950 out 1000 block threshold had been passed and that a v2 block was found. The SPV miners did not validate that (I guess they didn't check the threshold or version) and began mining on this now invalid block. |
|
|
|
it must search through every single unspent output for every single address in the wallet. Since there are thousands of addresses and thousands of unspent outputs for each address, it can take a long time to search through everything in order to create your transaction.
Does really wallet.dat has no indexes for unspent outputs? Well known that in Relational-DB we can find 1 record from 1 million records less than for 1 second using indexes. I'm not sure. It isn't the wallet.dat but rather the levelDB databases that Bitcoin Core uses for everything. You should lookup some stuff about levelDB. |
|
|
|
If that were to happen, then as gmaxwell said, there would be a new alert that cannot be canceled and cancels all previous alerts that states "Alert Key Compromised" ...
Since no current member of core has been reported to have this key, that could become an awkward and most troublesome task. And, to the best of my knowledge, there is no override option that makes an alert cancel proof. Your knowledge is quite wrong. There are most certainly people on the core dev team that have the key. I'm pretty sure that gmaxwell has the alert key because he said this I'm using 0.10.2 and still got the message, it's not a version specific announcement.
The message was briefly up for 0.10.2 because 0.10 had failed to increment the protocol version and I failed to account for that. The there are two alerts which are active right now covering everything prior to 0.9 plus the specific subversion strings for 0.9.0-0.9.5. about the recent blockchain fork. He is referring to the alert sent out. Note the "I" There is in fact an override option that makes an alert cancel proof. Go look in the code. alert.cpp, line 178 https://github.com/bitcoin/bitcoin/blob/master/src/alert.cppgmaxwell said it too. More or less incorrect on both counts. Yes, someone can send a message-- but that message can be disabled, locked out, and replaced with a key compromised method by anyone with the alert key. For security reasons everyone who has the alertkey is not enumerated (so that someone can't attempt to suppress use of the alert key by targeting multiple people). Multiple people currently active in the project have the key, and there are also other security measures in place.
|
|
|
|
You should include the links to those threads. They aren't linked. 1: If the solution were to randomize what chain to work on in a tie, why wouldn't the selfish pool
try to create multiple chains by having subpools work on finding hashes for separate blocks?
These can then be flooded to the network increasing the odds in favor of the selfish pool even
with the randomizing.
Of course, the processing power in N times the amount to do a single block ahead, where N is the
number of simultaneous blocks being hashed. Also the probability of even finding two blocks
against the entire network is very low and probably cost prohibitive.
What good would that do? It would cost a lot of processing power and there would be little profit. There would be N times the amount of processing power in order to flood the network with their blocks, but each one different. With that much processing power, it would be more effective and more profitable to mine normally. Instead of finding two blocks simultaneously and getting only a 25 BTC reward, with the same hashrate, they could find two blocks one after each other and get a 50 BTC reward. 2: In general, holding on to a block for some period after finding it, looks like a potential advantage
is working on the next block. Why not have all the nodes do this as normal operation?
The longer a node holds onto the block, the higher the risk of getting into a competitive fork situation,
but also increases the opportunity to win the race to the next block. Seems like this could create
some "safe" gambling type behavior, while nullifying the overall effect of the selfish mining algorithm.
The longer a node holds onto a block, the higher the risk of someone else finding that same block and thus orphaning the miner. Unless the miner held a significant portion of the network, he will not be able to mine faster than the rest of the network can and produce a longer chain. Still, the miner that finds a block has a slight advantage over the remaining miners since he has the block before everyone else. Due to network latency and the verification of blocks, the miner who found a block has a slight time advantage over everyone else, but not by much. |
|
|
|
So if Gavin would go rogue his alerts would simply be disabled by someone else holding the keys? What if the submits the alert again? Will it end up in an endless childish 'submit and disable' war between Gavin and other people holding keys?
If that were to happen, then as gmaxwell said, there would be a new alert that cannot be canceled and cancels all previous alerts that states "Alert Key Compromised" At that point, I would assume that the dev team would change the client to have a new alert key and simply not distribute that key to Gavin, thus solving the problem. However, that is not needed right now and is much more hassle to do because some people would have clients with the old key and some with the new. This means that if an alert was needed such as in the yesterday's problem, the same alert must be sent twice with both key's signatures in order to reach everyone. Well if Gavin keeps holding alertkeys then the whole alert system looses a lot of credibility because right now i can't trust the alerts since i don't trust Gavin but that only as a note on the sideline.
What alerts would you not trust? Use your own brain. Obviously an alert such as "URGENT: Upgrade to Bitcoin XT NOW" should probably be ignored. Every legitimate alert sent out links to a page from here: https://bitcoin.org/en/alerts. |
|
|
|
|
The problem is the size. If your <fromaccount> is all of your addresses, then it must search through every single unspent output for every single address in the wallet. Since there are thousands of addresses and thousands of unspent outputs for each address, it can take a long time to search through everything in order to create your transaction.
Unfortunately, I don't know how you can speed this up, and I'm pretty sure that you can't speed it up. I would advise consolidating all of your Bitcoin into one address and create a new account in Bitcoin Core with only that address. It should be faster that way since it will only have to search through I address and a few unspent outputs.
|
|
|
|
Do I have to reindex the whole Blockchain or is opening the wallet and syncing the rest of the blockchain enough? I opened it and now it is syncing with the blockchain and all seems normal.
EDIT: I didn´t even close the bitcoin qt or the computer, it shut down itself?!
Just run Bitcoin Core and it will do everything it needs. However, if it constantly shuts itself down, that means that it is detecting an error and you should check the debug.log. Also, that points to a larger problem than with Bitcoin Core itself. This usually means that there is something that is messing with the databases. It could be other software or your hardware. Perhaps disable your antivirus and check your hardware. Such issues could be indications of hardware failures. |
|
|
|
The list of people with access to the alert key is listed here: https://en.bitcoin.it/wiki/AlertsNone of the current active core developers is on that list. I think these issues are relevant and worthy of discussion. For example, why should someone what vanished 5 years ago still have that all-powerful access yet at the same time no current core member apparently does? Seems like a valid concern. That is not a full list of everyone who has an alert key. If you actually read the whole thing, you would notice this: The known private key holders are Satoshi Nakamoto, Gavin Andresen and theymos. There are other people able to issue alerts in the event of the incapacitation of the aforementioned The keyholders are not publicly known for their own safety. If everyone knew who held the alert keys, then people could pressure them and coerce them into sending alerts. However, the alert system is not all-powerful. It is in fact rather weak. It does not force anyone to do anything nor does it force the software to do anything. Anyone with the alert key can only send messages that are up to the people to decide whether to use or not. |
|
|
|
This is the first time the alert system has been used since April, 2014. Gavin’s recent departure left Bitcoin’s core team without a working key.
There's 3 keys right? So whose key was it? There is only one alert key and it is held by multiple people, not just Gavin, and I wouldn't be surprised if more core devs had them. I know that Theymos has a key as well as Gavin. I'm fairly certain that waldimir has one too and probably more if not all of the core devs. |
|
|
|
|
Show Posts
