{"action":"created","issue":{"url":"https://api.github.com/repos/bitcoin/bitcoin/issues/6995","labels_url":"https://api.github.com/repos/bitcoin/bitcoin/issues/6995/labels{/name}","comments_url":"https://api.github.com/repos/bitcoin/bitcoin/issues/6995/comments","events_url":"https://api.github.com/repos/bitcoin/bitcoin/issues/6995/events","html_url":"https://github.com/bitcoin/bitcoin/issues/6995","id":116508383,"number":6995,"title":"the RPC should have commands to specify the side of a fork considered 'current'","user":{"login":"kanoi","id":1059166,"avatar_url":"https://avatars.githubusercontent.com/u/1059166?v=3","gravatar_id":"","url":"https://api.github.com/users/kanoi","html_url":"https://github.com/kanoi","followers_url":"https://api.github.com/users/kanoi/followers","following_url":"https://api.github.com/users/kanoi/following{/other_user}","gists_url":"https://api.github.com/users/kanoi/gists{/gist_id}","starred_url":"https://api.github.com/users/kanoi/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kanoi/subscriptions","organizations_url":"https://api.github.com/users/kanoi/orgs","repos_url":"https://api.github.com/users/kanoi/repos","events_url":"https://api.github.com/users/kanoi/events{/privacy}","received_events_url":"https://api.github.com/users/kanoi/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/bitcoin/bitcoin/labels/RPC","name":"RPC","color":"0052cc"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":12,"created_at":"2015-11-12T09:18:33Z","updated_at":"2015-11-12T11:24:43Z","closed_at":null,"body":"As bitcoin stands at the moment, a standard orphan race is decided simply by the first block received above the 'current' height - of course this process can continue if both forks grow at the same rate, but the concept and the solution are the same for multi-block forks up to a point\r\nWhen the orphan is resolved by the 'higher' block found, if that block is on a different valid fork to the what bitcoin considers the current fork, it will simply switch to the other fork.\r\n\r\nIt would be very useful to have an RPC command to switch which fork bitcoin considers is the current fork - probably by choosing the block hash at the top of the fork, if bitcoin knows multiple forks at the same height\r\nIn the case of network issues about choosing a fork, this would provide a very simple method to resolve which side of the fork a miner using bitcoin is mining on.\r\nThis would of course add complexity and require a different command if the fork chosen was at a lower level, but that could also be handled by being able to state that a specific block (in a fork) is invalid and should be ignored - and thus give a method to effectively invalidate the fork.\r\n\r\nI'm not sure what the RPC submitblock does with a block when it receives one, on or creating a different fork, but of course it would need to accept a block on a different fork if it doesn't already."},"comment":{"url":"https://api.github.com/repos/bitcoin/bitcoin/issues/comments/156078612","html_url":"https://github.com/bitcoin/bitcoin/issues/6995#issuecomment-156078612","issue_url":"https://api.github.com/repos/bitcoin/bitcoin/issues/6995","id":156078612,"user":{"login":"gmaxwell","id":858454,"avatar_url":"https://avatars.githubusercontent.com/u/858454?v=3","gravatar_id":"","url":"https://api.github.com/users/gmaxwell","html_url":"https://github.com/gmaxwell","followers_url":"https://api.github.com/users/gmaxwell/followers","following_url":"https://api.github.com/users/gmaxwell/following{/other_user}","gists_url":"https://api.github.com/users/gmaxwell/gists{/gist_id}","starred_url":"https://api.github.com/users/gmaxwell/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gmaxwell/subscriptions","organizations_url":"https://api.github.com/users/gmaxwell/orgs","repos_url":"https://api.github.com/users/gmaxwell/repos","events_url":"https://api.github.com/users/gmaxwell/events{/privacy}","received_events_url":"https://api.github.com/users/gmaxwell/received_events","type":"User","site_admin":false},"created_at":"2015-11-12T11:24:43Z","updated_at":"2015-11-12T11:24:43Z","body":"PPC is some altcoin based on the bitcoin core codebase; and like most others hasn't kept up with fixes.\r\n\r\nIf miners prefer their own blocks over earlier received ones, then for many combinations of network topology and miner latency this results in significant increases in moderate depth to long reorgs. This is because in a near tie the winning block doesn't just have to win early enough to overcome network and validation latency and be heard uniformly before a competitor, it has to to that by more than the mining stack latency (which can be rather large). When that doesn't happen the fork persists when it otherwise would have resolved, and the result is a longer reorg. The effect is as big as it is, due to the exponential distribution of times between blocks means that a lot of blocks are 'fast'.\r\n\r\nThe comment here was not on that but that now that breaking ties with invalidation was suggested I think we really need to provide a better interface or get rid of the dangerous one---- we probably should have all along but it hadn't come up; even though it hurts convergence people will do it anyways and they might as well do it safely.  Though possible to do via invalidateblock it is quite tricky to get that right, and the result will be miners that refuse to mine on the longest chain even once theirs has fallen behind (e.g. due to state management and details like if they've invalidated they won't even see the longer extension, so they won't know they've fallen behind and will continue to try to mine a fork), which will leave lite clients more vulnerable to double spending and create other issues.  Since it sounds like people are going to do that we should provide an option (preferblock) which is less likely to shoot miners (and the network as a whole) in the foot and completely break things. :)\r\n"}}