|
Title: Blockchain split of 4 July 2015 Post by: jl2012 on July 04, 2015, 02:52:54 AM F2Pool is building on a wrong side and there is fake confirmation since block 363731. (EDIT: the bogus chain of 363731 is already orphaned and not relevant to normal users)
If you use light weight wallet or old version of Bitcoin Core, you should stop accepting bitcoin for a moment EDIT: For people looking for latest advice, please see the header of the forum. If you see no warning in the forum header, you may assume business back to normal EDIT: More details: https://bitcoin.org/en/alert/2015-07-04-spv-mining Title: Re: WARNING: blockchain split Post by: jonald_fyookball on July 04, 2015, 03:04:45 AM interesting,let's see how deep the reorg will be.
Title: Re: WARNING: blockchain split Post by: jonald_fyookball on July 04, 2015, 03:09:16 AM Is this for real? A fork would be a big deal. why is it a big deal? don't orphan chains happen regularly and get resolved ? Title: Re: WARNING: blockchain split Post by: Quantus on July 04, 2015, 03:09:20 AM More info plz
Edit: what do you mean by fake confirmations? Title: Re: WARNING: blockchain split Post by: chalkboard17 on July 04, 2015, 03:13:27 AM Meanwhile 1mb in transaction on queue https://blockchain.info/unconfirmed-transactions
Title: Re: WARNING: blockchain split Post by: Shogen on July 04, 2015, 03:16:30 AM So it is not just F2Pool, but also AntPool. Considering that they have roughly 36% of total network hashrate (data from https://blockchain.info/pools), it shouldn't be hard for the "correct chain" to win. Title: Re: WARNING: blockchain split Post by: Slark on July 04, 2015, 03:17:15 AM F2Pool is building on a wrong side and there is fake confirmation since block 363731. I am using Bitcoin Core (old version, yes I am lazy and paranoid). So basically you are saying if I start my wallet now and it update blockchain it will be corrupted and I will lose access to my coins?If you use light weight wallet or with old version of Bitcoin Core, you should stop accept bitcoin for a moment Title: Re: WARNING: blockchain split Post by: BitUsher on July 04, 2015, 03:18:38 AM https://www.reddit.com/r/Bitcoin/comments/3c2cfd/psa_f2pool_is_mining_invalid_blocks/
Quote from: Peter Todd tl;dr: of what's going on: A large % of the hashing power is "SPV mining" where they mine on top of headers from blocks that they haven't actually verified. They're do this because in most cases you earn more money doing it - latency matters a lot and even 1MB blocks take long enough to propagate that you lose a significant amount of money by waiting for full propagation. However, this also means they're not checking the new BIP66 rule, and are now mining invalid blocks because of it. (another miner happened to create an invalid, non-BIP66 respecting block) If you're not using Bitcoin Core, you might be accepting transactions that won't be on the longest valid chain when all this is fixed. Bitcoin Core (after 0.10.0) rejects these invalid blocks, but a lot of other stuff doesn't. SPV Bitcoinj wallets do no validation what-so-ever, blindly following the longest chain. blockchain.info doesn't appear to do validation as well; who knows what else? edit: FWIW, this isn't a BIP66-specific issue: any miner producing an invalid block for any reason would have triggered this issue. Title: Re: WARNING: blockchain split Post by: jonald_fyookball on July 04, 2015, 03:19:21 AM Is this for real? A fork would be a big deal. why is it a big deal? don't orphan chains happen regularly and get resolved ? No direct evidence of that yet though, could be something else. where are you getting your data that it's not common? blockchain.info charts show thousands of orphan blocks each day. sure most of them are probably single blocks, but show me your data please. Title: Re: WARNING: blockchain split Post by: Shogen on July 04, 2015, 03:20:41 AM More info plz Check http://www.reddit.com/r/Bitcoin/comments/3c2cfd/psa_f2pool_is_mining_invalid_blocks/ to get a rough idea of what happened. BTW, did something like this happen when the BIP 34 soft fork was done? F2Pool is building on a wrong side and there is fake confirmation since block 363731. I am using Bitcoin Core (old version, yes I am lazy and paranoid). So basically you are saying if I start my wallet now and it update blockchain it will be corrupted and I will lose access to my coins?If you use light weight wallet or with old version of Bitcoin Core, you should stop accept bitcoin for a moment No. All the transaction confirmed before the fork happened (in block 363731) is safe. Title: Re: WARNING: blockchain split Post by: BitUsher on July 04, 2015, 03:23:13 AM I am using Bitcoin Core (old version, yes I am lazy and paranoid). So basically you are saying if I start my wallet now and it update blockchain it will be corrupted and I will lose access to my coins? You run a risk of losing your coins if you perform a transaction at the moment on anything but Bitcoin Core 0.10.0 or newer. Starting up your wallet is fine though. If you are using Bitcoin Core 0.10.0 or newer you will be safe for performing txs at the momment Title: Re: WARNING: blockchain split Post by: OROBTC on July 04, 2015, 03:27:01 AM ...
Just saw that myself at blockchain.info and came over here for an explanation, right place! Chinese miners ought to take care not to screw the pooch through selfishness or whatever. Very unusual things happening are often a bad sign. I will not do ANY transactions until we get some clarity. Title: Re: WARNING: blockchain split Post by: Quantus on July 04, 2015, 03:34:24 AM So the Chines miners are creating invalid blocks but smart phone wallets and even website wallets can't tell they are invalid?
Title: Re: WARNING: blockchain split Post by: BitUsher on July 04, 2015, 03:35:58 AM Interesting test case for alert being sent out to older version of Bitcoin Core to warn users.(Prior to 0.10). I have various cores installed on different computers and do not see the alert on any of them.
As far as I am aware 3 people have alert keys - Gavin, Satoshi, and Theymos. Why isn't an alert being sent out? Title: Re: WARNING: blockchain split Post by: jl2012 on July 04, 2015, 03:37:20 AM So the Chines miners are creating invalid blocks but smart phone wallets and even website wallets can't tell they are invalid? Yes Title: Re: WARNING: blockchain split Post by: Quantus on July 04, 2015, 03:37:27 AM So many people are going to get scammed tonight with fake transactions.
Title: Re: WARNING: blockchain split Post by: OROBTC on July 04, 2015, 03:38:45 AM ...
Been over 30 minutes since the 5 suspicious blocks... Um, an interesting way to spend a Friday night? * * * turtlehurricane, a PM for you. That phone number of yours seems to place you near me. :) EDIT: Has anyone checked the other blockchain tools? blockexplorer appears to be down / not working. Title: Re: WARNING: blockchain split Post by: Quantus on July 04, 2015, 03:39:43 AM We are so fucked
Edit: someone tell me its all going to be ok. Title: Re: WARNING: blockchain split Post by: tokeweed on July 04, 2015, 03:40:23 AM Title: Re: WARNING: blockchain split Post by: Shogen on July 04, 2015, 03:44:59 AM blockchain.info and blocktrail.com are on different chains, this may be proof we really do have a fork. http://i.gyazo.com/64ea0ab8fec4fba3740a0206797e93ae.png http://i.gyazo.com/ccd81382dc41ee1986ee5442b2ee1197.png BIP66 is enforced in block 363275, and since then v2 block should be considered invalid. BTC Nuggets created a v2 block 363731, but Antpool, F2Pool, and bc.i doesn't not reject it and hence they are now on the wrong fork. Title: Re: WARNING: blockchain split Post by: Gleb Gamow on July 04, 2015, 03:47:59 AM We are so fucked Edit: someone tell me its all going to be ok. It's all goin' be... http://usercontent2.hubimg.com/4158435_f260.jpg Title: Re: WARNING: blockchain split Post by: Shogen on July 04, 2015, 03:52:23 AM The correct fork now gets to block 363737 and the problem is solved for now. But if another v2 block is created while Antpool and F2Pool failing to reject it, we could have another fork then.
Title: Re: WARNING: blockchain split Post by: HerbPean on July 04, 2015, 03:53:19 AM F2Pool blocks are now all Orphaned.
Title: Re: WARNING: blockchain split Post by: jonald_fyookball on July 04, 2015, 03:53:53 AM The correct fork now gets to block 363737 and the problem is solved for now. But if another v2 block is created while Antpool and F2Pool failing to reject it, we could have another fork then. so it was a 6 block orphan chain Title: Re: WARNING: blockchain split Post by: coinableS on July 04, 2015, 03:55:38 AM Is there something us users can do to help this issue? If I launched my full node and started validating transactions would this help, not help this issue? This seems serious.
Title: Re: WARNING: blockchain split Post by: OROBTC on July 04, 2015, 03:56:06 AM ...
And WHAT has happened to all the transactions that occurred during that time frame? Do they all get recorded in new blocks? Block 363737 only has some 166 trx listed. Maybe other tools are better than blockchain.info? Is there a way to see recently orphaned blocks? Title: Re: WARNING: blockchain split Post by: Quantus on July 04, 2015, 03:58:11 AM If 1 MB blocks are already to big for mining farms to validate properly won't 8mb blocks just slow down the network even more?
Title: Re: WARNING: blockchain split Post by: jonald_fyookball on July 04, 2015, 03:59:07 AM If 1 MB blocks are already to big for mining farms to validate properly won't 8mb blocks just slow down the network even more? It wasn't the size that was the issue here. The pool wasn't keeping updated with all the BIPs. Title: Re: WARNING: blockchain split Post by: Shogen on July 04, 2015, 04:02:01 AM Is there something us users can do to help this issue? If I launched my full node and started validating transactions would this help, not help this issue? This seems serious. If you are using bitcoin core older than 0.9 or older, you should upgrade to 0.10 or newer. If you have contacts with miners still mining v2 blocks or not rejecting v2 blocks, you could ask them to upgrade as well. ... And WHAT has happened to all the transactions that occurred during that time frame? Do they all get recorded in new blocks? Block 363737 only has some 166 trx listed. Maybe other tools are better than blockchain.info? Is there a way to see recently orphaned blocks? You could use blocktrail.com or btc.blockr.io. They are correctly rejecting v2 blocks AFAIK. Title: Re: WARNING: blockchain split Post by: ajareselde on July 04, 2015, 04:02:23 AM Both blockchain and blocktrail are now reporting identical blocks from block 363737, and transactions seam to be passing through.
I'm interested to know what will happen to the transactions from few block before that? cheers Title: Re: WARNING: blockchain split Post by: BitUsher on July 04, 2015, 04:11:01 AM If 1 MB blocks are already to big for mining farms to validate properly won't 8mb blocks just slow down the network even more? It wasn't the size that was the issue here. The pool wasn't keeping updated with all the BIPs. You are both right. One Mining pool which mined an invalid block was picked up by other pools who do not verify as they are "SPV mining" . The reason f2Pool and Antpool among others SPV mine instead of fully validate is for a slight~1% edge in latency which does indicate that larger blocks do have an impact upon the economics of mining. Title: Re: WARNING: blockchain split Post by: OROBTC on July 04, 2015, 04:11:36 AM ...
AntPool just put up another "bad one", selfish bastids... Block 363741. Whee... (?) Penalty box for miners who do that? But with everything so de-centralized, how would THAT work? EDIT: Thanks, BitUsher, that explains something for me. :) Title: Re: WARNING: blockchain split Post by: jonald_fyookball on July 04, 2015, 04:13:22 AM ... AntPool just put up another "bad one", selfish bastids... Block 363741. Whee... (?) Penalty box for miners who do that? But with everything so de-centralized, how would THAT work? people will start leaving the pool if they keep up those shenanigans. Title: Re: WARNING: blockchain split Post by: BitUsher on July 04, 2015, 04:24:28 AM Current status: F2Pool still broken; Antpool fixed (but no promise they won't intentionally re-break in the future).
Title: Re: WARNING: blockchain split Post by: ajareselde on July 04, 2015, 04:26:44 AM Current status: F2Pool still broken; Antpool fixed (but no promise they won't intentionally re-break in the future). How is it fixed when they just had another bad one? https://blockchain.info/block/00000000000000000b9d7006b0a893302e02becbc2faf78e79e000bb51721db0 Since thhere are no transactions in these blocks, it should be easier to fix the problem. cheers Title: Re: WARNING: blockchain split Post by: BitUsher on July 04, 2015, 04:31:04 AM Current status: F2Pool still broken; Antpool fixed (but no promise they won't intentionally re-break in the future). How is it fixed when they just had another bad one? https://blockchain.info/block/00000000000000000b9d7006b0a893302e02becbc2faf78e79e000bb51721db0 Since thhere are no transactions in these blocks, it should be easier to fix the problem. cheers That is actually on the correct chain... Take a look. Antpool appear to have a safeguard to not include transactions under certain conditions as well. Title: Re: WARNING: blockchain split Post by: OROBTC on July 04, 2015, 04:35:37 AM ...
BitAmigos :) Well, this has been perhaps my most exciting Friday night looking at BTC transactions. But, maybe the excitement is over, for now. I have seen unflattering references to AntPool landing a lot of blocks with just their win as the only transaction. This kind of thing why I (as a non-tekkie) have no interest in trying to mine BTC, too complicated. * * * OK, back to my Lee Child book... Title: Re: WARNING: blockchain split Post by: BitUsher on July 04, 2015, 04:38:21 AM Nice... I just got the warning in core from the Alert Key. May have been Theymos responding to my IM, or Gavin noticing.
"Your node software is out of date and may accept an invalid blockchain fork. Do not trust confirmations. " The odd thing is that I received this message on 0.10.0rc1 which is supposed to be safe In this instance. I'm going to update and see if the alert is removed. edit **** warning was just changed to -- " Warning: This version is obsolete, upgrade required!" Title: Re: WARNING: blockchain split Post by: BitUsher on July 04, 2015, 04:44:00 AM Someone just used the alert key. "Your node software is out of date and may accept an invalid blockchain fork. Do not trust confirmations" I have 0.10.1, how can that be right ??? Latest version is 0.10.2. I don't know if that has anything to do with it or not. I'm guessing its a blanket statement for all old versions, even though 0.10.0 is technically safe Title: Re: WARNING: blockchain split Post by: BitUsher on July 04, 2015, 05:05:31 AM Another update from Peter Todd:
"The majority of hashing power is now mining only valid blocks. However, SPV wallets are still vulnerable as they do no validation, and ~4% or so of hashing power is still mining invalid blocks. Don't trust txs in SPV wallets w/o >= 2 confirmations right now." FYI-- no alert message with 0.10.2 now that I upgraded to test this node. Title: Re: WARNING: blockchain split Post by: Pony789 on July 04, 2015, 05:11:29 AM According to https://getaddr.bitnodes.io/nodes/, only 62% of full nodes are using bitcoin core 0.10.0, 0.10.1 and 0.10.2. Hopefully the alert message will make the remaining users to upgrade.
Title: Re: WARNING: blockchain split Post by: zvs on July 04, 2015, 05:11:46 AM So many people are going to get scammed tonight with fake transactions. from what? all those 1 transaction (the 25btc) blocks? nobody is going to get scammed with fake transactions, it's obv not intentional.. if it was, they'd be including a lot of their (own) transactions, instead they are including zero also, re: blockchain has 'thousands of orphan blocks a day', huh? more like 1 or 2 on average ed: the only 'scamming' from transactions that could possible happen were with the original f'cked up block @ https://blockchain.info/block/0000000000000000009cc829aa25b40b2cd4eb83dd498c12ad0d26d90c439d99 Title: Re: WARNING: blockchain split Post by: scarsbergholden on July 04, 2015, 05:13:36 AM whats the deal now in days everyone is calling about forks like this wasn't happening before, why are miners so hard headed when it comes to an update.
Title: Re: WARNING: blockchain split Post by: BitUsher on July 04, 2015, 05:16:09 AM According to https://getaddr.bitnodes.io/nodes/, only 62% of full nodes are using bitcoin core 0.10.0, 0.10.1 and 0.10.2. Hopefully the alert message will make the remaining users to upgrade. Except most are using SPV wallets and wont see the alert message. BTC Nuggets (the trigger in this case) still has 2.2Ph/s and could start this fork again with F2Pool picking up the wrong block and not validating. ed: the only 'scamming' from transactions that could possible happen were with the original f'cked up block @ https://blockchain.info/block/0000000000000000009cc829aa25b40b2cd4eb83dd498c12ad0d26d90c439d99 It is doubtful that a scammer could have reacted quick enough but during the fork double spending could have occurred, especially with SPV wallets for any transactions spent in BTC Nuggets block that triggered this. Title: Re: WARNING: blockchain split Post by: gmaxwell on July 04, 2015, 05:27:04 AM from what? all those 1 transaction (the 25btc) blocks? There was about 4% of the hashrate remaining mining old invalid blocks; these SPV miners would extend them-- effectively boosting the invalid-block mining portion of the hashrate to 50% the moment one of those 4% miners produced an invalid block.nobody is going to get scammed with fake transactions, it's obv not intentional.. if it was, they'd be including a lot of their (own) transactions, instead they are including zero also, re: blockchain has 'thousands of orphan blocks a day', huh? more like 1 or 2 on average ed: the only 'scamming' from transactions that could possible happen were with the original f'cked up block @ https://blockchain.info/block/0000000000000000009cc829aa25b40b2cd4eb83dd498c12ad0d26d90c439d99 Miners that do not verify, even if they don't include transactions, are a huge amplifier on anyone who mines an invalid or malicious block for whatever reason; and are obviously a grave risk to the system. More of these forks may still happen-- if these large hashrate miners leave the SPV mining code in place, there still is a few percent mining invalid blocks--- I know for the deployment of the P2SH softfork "50 BTC" continued mining invalid blocks for roughly a month. Title: Re: WARNING: blockchain split Post by: BitUsher on July 04, 2015, 05:33:09 AM There was about 4% of the hashrate remaining mining old invalid blocks; these SPV miners would extend them-- effectively boosting the invalid-block mining portion of the hashrate to 50% the moment one of those 4% miners produced an invalid block. Miners that do not verify, even if they don't include transactions, are a huge amplifier on anyone who mines an invalid or malicious block for whatever reason; and are obviously a grave risk to the system. More of these forks may still happen-- if these large hashrate miners leave the SPV mining code in place, there still is a few percent mining invalid blocks--- I know for the deployment of the P2SH softfork "50 BTC" continued mining invalid blocks for roughly a month. My concerns exactly and stated more elegantly than I could have. Perhaps there needs to be a change to the protocol to prevent this practice? Title: Re: WARNING: blockchain split Post by: gmaxwell on July 04, 2015, 05:44:39 AM My concerns exactly and stated more elegantly than I could have. Perhaps there needs to be a change to the protocol to prevent this practice? It's possible to do, prior proposals were dismissed as paranoia. I expect that even the evidence now won't be enough since this expirenced will be discounted as "sure, they were doing that before, but they won't do it again".And now, you know why chinese pools thought they could survive with 8MB blocks. Ultimately any proposal to inhibit SPV mining is going to interact in politically complex ways with the block size discussion. :( Title: Re: WARNING: blockchain split Post by: Mikestang on July 04, 2015, 06:22:53 AM Someone just used the alert key. "Your node software is out of date and may accept an invalid blockchain fork. Do not trust confirmations" I have 0.10.1, how can that be right ??? Latest version is 0.10.2. I don't know if that has anything to do with it or not. I'm guessing its a blanket statement for all old versions, even though 0.10.0 is technically safe I'm using 0.10.2 and still got the message, it's not a version specific announcement. Title: Re: WARNING: blockchain split Post by: gmaxwell on July 04, 2015, 06:43:34 AM 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.Title: Re: WARNING: blockchain split Post by: Panthers52 on July 04, 2015, 06:53:45 AM The correct fork now gets to block 363737 and the problem is solved for now. But if another v2 block is created while Antpool and F2Pool failing to reject it, we could have another fork then. so it was a 6 block orphan chain I also noticed that f2pool was mining an unusually large number of 1 tx blocks (only the coinbase tx).....this is obviously speculation, but maybe they were trying to do something malicious. IMO this is very interesting. I don't think I have been around since we have seen a reorg of this magnitude. Title: Re: WARNING: blockchain split Post by: Amph on July 04, 2015, 07:15:16 AM this one of the reason why bitcoin is not accepted everywhere, people feel unsecure with all that shitty fork that can happen..randomly
Someone just used the alert key. "Your node software is out of date and may accept an invalid blockchain fork. Do not trust confirmations" I have 0.10.1, how can that be right ??? Latest version is 0.10.2. I don't know if that has anything to do with it or not. well i'm not getting any warning with the last version also rc1 is not even a final a complete version Title: Re: WARNING: blockchain split Post by: turvarya on July 04, 2015, 07:24:54 AM Can someone explain me like i am five. Thanks. How I understand it:There is a fork, because some Chinese miners are using an old version. If you use a newer version of Bitcoin Core, it just ignores the invalid fork: No problem there. But there doesn't seem to be any info about SPV(e.g. Smartphone) wallets. A fork means, that when you see a transaction confirmed on the invalid chain, it doesn't mean it is confirmed on the valid chain. But: Nobody can steal your Bitcoin, it is just about, if you can trust, if a transaction is really confirmed. Title: Re: WARNING: blockchain split Post by: Amitabh S on July 04, 2015, 07:29:41 AM What about Bitcoinj. I am using version 0.11-SNAPSHOT. Which fork will this follow? Any help appreciated.
Title: Re: WARNING: blockchain split Post by: LiteCoinGuy on July 04, 2015, 07:29:50 AM we are doomed. :o
--- If you're using Bitcoin Core 0.10.0 or newer you are fine! The majority of hashing power is mining an invalid chain - it's not going to "win" - they're just wasting their effort. by the way, the problem is already solved Title: Re: WARNING: blockchain split Post by: RappelzReborn on July 04, 2015, 07:32:25 AM What the hell does that means ? :o
How it's possible to make fake transaction , isn't that only possible when you do 51% attack or whatever it's name is . I guess I'am safe since I'am using the latest version of Bitcoin core however knowing more about this would be nice . Title: Re: WARNING: blockchain split Post by: turvarya on July 04, 2015, 07:33:10 AM What about bitcoinj. I am using version 0.11-SNAPSHOT. As far as I know, bitcoinj is just a java library. The problem described here is, if the blockchain you have downloaded is valid. So, which blockchain are you using? On your PC or an external node?Title: Re: WARNING: blockchain split Post by: johoe on July 04, 2015, 07:36:54 AM Can someone explain me like i am five. Thanks. ELI5 is difficult :). I try for a higher age... The developers designed a soft fork BIP66 that does not allow some malformed bitcoin transaction (that have a strange signature that may not be accepted by newer versions of openssl). To make sure that there is only minimal forking, they had some rules accompanied with the fork.
The latter should have produced a few orphans for the 5 % that didn't update. However, it looks like f2pool and antpool just voted by setting version 3 but did not implement the rules of the fork, at least not the last one. They built a fork on top of a block from a miner that didn't update. Since they have a lot of hashing power they managed to produce a longer fork that was alive for some time before being overtaken by the miners implementing the soft fork correctly. The effect is that we may see transactions with 6 confirmations that are later double spend. Also f2pool will loose a lot of blocks since they are orphaned later. If you have a full node that is updated, you have nothing to worry. It will just ignore the invalid forks. If you have a SPV client, it will trust the miners to not do something stupid like this and thus it may be on the wrong side of a fork. There is a small chance that you see a transaction with a few confirmations that doesn't make it to the 0.10.x chain. Title: Re: WARNING: blockchain split Post by: coinmaster222 on July 04, 2015, 07:37:26 AM Whats going to happen with coins merge mining with Bitcoin the likes of Unobtanium ?
Title: Re: WARNING: blockchain split Post by: The Bitcoin Co-op on July 04, 2015, 07:42:12 AM I love how the problem was essentially fixed by the time I found this thread. The tech community is so efficient
Title: Re: WARNING: blockchain split Post by: RustyNomad on July 04, 2015, 07:42:56 AM Thanks for the early warning on this.
Making use of a 'light' client and was going to send off a couple of transactions (+-14) today. All on hold for now. Title: Re: WARNING: blockchain split Post by: n2004al on July 04, 2015, 07:47:44 AM I use a coinbase wallet. is this wallet affected by this problem? Thanks.
Title: Re: WARNING: blockchain split Post by: Amitabh S on July 04, 2015, 07:49:31 AM What about bitcoinj. I am using version 0.11-SNAPSHOT. As far as I know, bitcoinj is just a java library. The problem described here is, if the blockchain you have downloaded is valid. So, which blockchain are you using? On your PC or an external node?Using the above version in spv mode. Title: Re: WARNING: blockchain split Post by: Amph on July 04, 2015, 07:52:46 AM I use a coinbase wallet. is this wallet affected by this problem? Thanks. you can try to send one transaction with a very small amount, to see if it is affected, but if they have the last version it should be not Title: Re: WARNING: blockchain split Post by: turvarya on July 04, 2015, 07:56:34 AM What about bitcoinj. I am using version 0.11-SNAPSHOT. As far as I know, bitcoinj is just a java library. The problem described here is, if the blockchain you have downloaded is valid. So, which blockchain are you using? On your PC or an external node?Using the above version in spv mode. If you somehow get the ip-address, you could look it up here: https://blockchain.info/connected-nodes Title: Re: WARNING: blockchain split Post by: max2000irc on July 04, 2015, 07:57:15 AM If I use electrum will be any problem?
Thanks Title: Re: WARNING: blockchain split Post by: n2004al on July 04, 2015, 07:57:22 AM I use a coinbase wallet. is this wallet affected by this problem? Thanks. you can try to send one transaction with a very small amount, to see if it is affected, but if they have the last version it should be not Thank you! And if I will receive btc it is the same problem? Depends everything from the version of they who send btc? If they have not the last version what happen? I must wait to have 30 confirmations? And if these 30 confirmations don't arrive what happen to btc sent? To many questions but I wait btc from a cloud mining site and must know how to act. Thanks. Title: Re: WARNING: blockchain split Post by: CohibAA on July 04, 2015, 07:59:34 AM If I use electrum will be any problem? Thanks I am curious about this as well. I know the electrum servers are connected directly to bitcoin core nodes, so I imagine it would depend on whether the core version on the individual electrum server is properly updated. Title: Re: WARNING: blockchain split Post by: theymos on July 04, 2015, 08:03:13 AM I am curious about this as well. I know the electrum servers are connected directly to bitcoin core nodes, so I imagine it would depend on whether the core version on the individual electrum server is properly updated. Right, with Electrum it depends on which version of Bitcoin Core your Stratum server is using. AFAIK by default Electrum chooses a random untrusted Stratum server from IRC, so you probably can't (ever) trust that you're getting accurate info. Title: Re: WARNING: blockchain split Post by: turvarya on July 04, 2015, 08:04:40 AM I use a coinbase wallet. is this wallet affected by this problem? Thanks. you can try to send one transaction with a very small amount, to see if it is affected, but if they have the last version it should be not Thank you! And if I will receive btc it is the same problem? Depends everything from the version of they who send btc? If they have not the last version what happen? I must wait to have 30 confirmations? And if these 30 confirmations don't arrive what happen to btc sent? To many questions but I wait btc from a cloud mining site and must know how to act. Thanks. Nobody can steal your Bitcoin, somebody could just try to trick you into thinking, he sent you Bitcoin. So, as long, as you are not planing to sell something for BTC, there isn't any problem for you. Title: Re: WARNING: blockchain split Post by: theymos on July 04, 2015, 08:06:04 AM Somebody correct me, if I am wrong, but you just have to look on blockchain.info, if your transaction is confirmed. blockchain.info has a history of being grossly inaccurate, including in this case. Title: Re: WARNING: blockchain split Post by: n2004al on July 04, 2015, 08:08:05 AM Somebody correct me, if I am wrong, but you just have to look on blockchain.info, if your transaction is confirmed. blockchain.info has a history of being grossly inaccurate, including in this case. Then is there any solution to understand if the btc sent to me are safe? Title: Re: WARNING: blockchain split Post by: theymos on July 04, 2015, 08:11:11 AM Then is there any solution to understand if the btc sent to me are safe? To know for sure, you'd have to run Bitcoin Core... As a rough approximation, you can compare the results of several block explorer sites. insight.bitpay.com and chain.com are apparently on the correct chain in this case. Title: Re: WARNING: blockchain split Post by: amiryaqot on July 04, 2015, 08:14:52 AM that is worrying situation if somebody received coins and sent them to other address after 1 confirmation than what will happen to that transaction if that is from wrong side of block, mostly i use blockchain's online wallet for instant transaction should i have to wait for 30 confirmations for this wallet too?
Title: Re: WARNING: blockchain split Post by: n2004al on July 04, 2015, 08:20:53 AM Then is there any solution to understand if the btc sent to me are safe? To know for sure, you'd have to run Bitcoin Core... As a rough approximation, you can compare the results of several block explorer sites. insight.bitpay.com and chain.com are apparently on the correct chain in this case. Thank you. :) Title: Re: WARNING: blockchain split Post by: Kprawn on July 04, 2015, 08:23:33 AM Well this is a big deal, and the timing for this is strange. We have this whole Core vs XT discussion going on and the miners from China just flexed their muscles.
I see this as a small test run for things to come in the future, and we should take this as a serious threat. Where are all the counter measures, everyone was talking about, when Ghash pushed for the 51% attack? The alert should have gone out, before this happened. Just more ammunition for the damn shills. >:( >:( Title: Re: WARNING: blockchain split Post by: Lauda on July 04, 2015, 08:25:46 AM This is quite unfortunate. We've just started seeing a small positive trend and now this happens. However, it seems that there has been no effect on the price yet. The majority probably don't even know.
My question is, if this has been resolved (or at least partially)? At whom should we point our fingers of shame? https://i.imgur.com/OkkkVSb.png Title: Re: WARNING: blockchain split Post by: hl5460 on July 04, 2015, 08:27:46 AM Drama should be over
比特币疑似分叉，还能不能愉快地玩耍下去？ http://8btc.com/thread-20275-1-1.html (出处: 巴比特论坛) http://8btc.com/data/attachment/forum/201507/04/123351psx03ia0kid6u3i0.jpg http://8btc.com/data/attachment/forum/201507/04/123352ary51jrpfqyp51vq.jpg Title: Re: WARNING: blockchain split Post by: Xenoph0bia on July 04, 2015, 08:30:07 AM Update your wallets to Bitcoin Core 0.10.x or 0.9.5 and import your private keys there.
Title: Re: WARNING: blockchain split Post by: Jeremycoin on July 04, 2015, 08:34:54 AM So, we have to wait 30 confirmations to make sure that it's a real transaction? ???
Title: Re: WARNING: blockchain split Post by: hl5460 on July 04, 2015, 08:35:22 AM Drama should be over 比特币疑似分叉，还能不能愉快地玩耍下去？ http://8btc.com/thread-20275-1-1.html (出处: 巴比特论坛) http://8btc.com/data/attachment/forum/201507/04/123351psx03ia0kid6u3i0.jpg http://8btc.com/data/attachment/forum/201507/04/123352ary51jrpfqyp51vq.jpg Detailed explanation(in Chinese) http://www.8btc.com/bitcoinfork Title: Re: WARNING: blockchain split Post by: Lauda on July 04, 2015, 08:37:18 AM Detailed explanation(in Chinese) How about you copy the text here or at least the important part of it. I can rarely access that website from my location.http://www.8btc.com/bitcoinfork So, we have to wait 30 confirmations to make sure that it's a real transaction? ??? Just make sure you're using version 0.10.x. Although you should wait a day or two just to be sure.Title: Re: WARNING: blockchain split Post by: S4VV4S on July 04, 2015, 08:39:41 AM Did anybody else notice that (at the time of writing this) the 3 biggest pools have exactly 51% of the total hashrate between them?
I do not think it is relevant. Just an observation. Title: Re: WARNING: blockchain split Post by: CohibAA on July 04, 2015, 08:40:04 AM Detailed explanation(in Chinese) http://www.8btc.com/bitcoinfork Google Translated to English (https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fwww.8btc.com%2Fbitcoinfork&edit-text=&act=url) Quote July 4 bitcoin block chain bifurcation Comments I think Bitcoin 2015-07-04 16:09 Posted in Bitcoin 1 139 Today Bitcoin block start diverging from 363,731 Beijing time, to 363,737 returned to normal, the bifurcation five blocks, which lasted one hour or so, most people do not know, and thus did not cause a big impact. Bifurcation 1 block is a normal thing, on a daily basis. But bifurcation five blocks on is not normal, it is necessary to analyze them, in order to avoid this from happening again. 1, mainly due to: block version upgrade from 2 to 3 Today happens to be the block version upgrade from 2 to 3 times, but this time is not scheduled in advance, but is automatically controlled by the program. Upgrade Rules: recent 1000 version blocks 950 blocks of 3, then refused to release the blocks 2 to 3 whole blocks chain upgrading. Version 2 and version 3 of the difference between: BIP66, namely defining signature DER encoded, no longer accept derive DER encoded, DER accept only standard coding; BIP66 into force method: a recent version 750 block of 3 1 000 blocks, the rules are in effect; Thus, the upgrade is upgraded in three stages: (1) When the [0-75%) of the blocks with a version 3, the beginning is compatible with all DER encoding formats, as well as version 2 and 3; (2) When the> = 75% of the blocks with a version 3, then began to enable BIP66, but is also compatible with version 2; (3) When the> = 95% of the blocks with a version 3, version 2 is no longer compatible, allowing only 3 version exists. BTC Nuggets have not been upgraded bitcoind, July 1 and 2, it dug two blocks, then it should not reach the 95% ratio. 9:56 GMT today BTC Nuggets out of the block a version 2 363 726, causing bifurcation, but is bifurcated handling mechanism program resolved. 10:09 BTC Nuggets then a block of 363 731 version 2, which is a fish pond and failed to properly handle ant pool, causing split ends. 2, after the mining bifurcation After bifurcation within one hour, followed by a fish pond and ants pool of V2 block BTC Nuggets continue dug five blocks, Slush, BitFury and another unknown mineral pool in the main chain dug up four blocks, No other mineral pools dug blocks. Seeing a growing bifurcation, pond and pool ant to BitFury this chain dig, dig the branched five blocks aside, ants dig two pools and BitFury, currency dig a network so that the network is restored normal. Ponds and pools where ants at BTC Nuggets version 2 block mining, this is confusing. I consulted the fish god, God said that the ants fish tank to the distribution network central node (Note: 5 large ore mine pool after pool conference jointly established a block distribution network designed to block rapid access to the latest, in order to accelerate the mining machine Task Update, improve mining efficiency) Error submitted BTC Nuggets of 363,731 blocks, pond and pool without ant blocks verification in the 363,731 block dug five blocks in a row. Then I contacted pool 潘志彪 ant, ant pool Panzhi Biao confirmed errors are caused, ants have a node to report the BTC Nuggets version 2 blocks, so that the pond and pool ants are in the wrong block mining. In short ponds and pools ant task generation process is not to verify the legitimacy of the blocks, resulting in this big fork. Bitcoin bifurcation mechanism can not handle, can only be resolved through a fallback, pond and pool ant rapid rollback, go to the main chain of mining, solved a big problem bifurcation. 3. Summary Suggestions: (1) bifurcation is not terrible, the most important fast processing (2) Block distribution network is a good thing, but the code to scrutiny (3) the mine pool to make money at the same time, we want more for bitcoin block chain security reasons, do long-term business. Title: Re: WARNING: blockchain split Post by: jwcastle on July 04, 2015, 08:50:12 AM This is actually a good thing. I bet people who were resistant on upgrading were terrified that they would lose their bitcoins. I'm sure a large percentage of them have upgraded now.
Title: Re: WARNING: blockchain split Post by: Borisz on July 04, 2015, 08:50:21 AM I'm using multibit, so I assume I should also wait approx. 30 confirmations just to be safe, right?
(waiting for updates here on how long this "glitch" will last) Title: Re: WARNING: blockchain split Post by: favdesu on July 04, 2015, 08:53:34 AM so two chinese pools went unintentionally rogue and forked bitcoin. however, they made a rollback and fixed the problem, does that summarize the issue?
Title: Re: WARNING: blockchain split Post by: uvt9 on July 04, 2015, 08:56:37 AM wasn't the problem fixed shortly ?
those pools went back to valid chain so what are we worrying about ? Title: Re: WARNING: blockchain split Post by: eerygarden on July 04, 2015, 09:19:56 AM Flipping technology
https://youtu.be/WeBS-dNo0Bk Keep calm and carry on hodling Title: Re: WARNING: blockchain split Post by: Limx Dev on July 04, 2015, 09:21:39 AM https://bchain.info/BTC/
Problem solved? Title: Re: WARNING: blockchain split Post by: RealBitcoin on July 04, 2015, 09:24:32 AM OMG WTF guys? I`m getting scared.
So if i just send now a transaction, then i lose my bitcoins and it doesnt get to the other end? Also what if i buy now bitcoin with € do i get fake bitcoin if the merchant is on wrong chain? This could be a serious problem. No FUD intended but seriously, i`m starting to panic/ ??? Title: Re: WARNING: blockchain split Post by: uvt9 on July 04, 2015, 09:27:38 AM OMG WTF guys? I`m getting scared. So if i just send now a transaction, then i lose my bitcoins and it doesnt get to the other end? Also what if i buy now bitcoin with € do i get fake bitcoin if the merchant is on wrong chain? This could be a serious problem. No FUD intended but seriously, i`m starting to panic/ ??? OMG WTF please read carefully before getting panic. Everything is settled, those who using Bitcoin core older than 0.10 and was receiving payment during fork period should wait at least 30 confirmations. Title: Re: WARNING: blockchain split Post by: Lauda on July 04, 2015, 09:28:02 AM OMG WTF guys? I`m getting scared. Just relax. Why would you panic at all? Obviously you're that kind of person, so how about you just pause everything related to Bitcoin for a day or two?So if i just send now a transaction, then i lose my bitcoins and it doesnt get to the other end? Also what if i buy now bitcoin with € do i get fake bitcoin if the merchant is on wrong chain? This could be a serious problem. No FUD intended but seriously, i`m starting to panic/ ??? You don't buy Bitcoin from merchants, but rather on exchanges. Even if something does go wrong I'm pretty sure that Bitstamp would reimburse you. https://bchain.info/BTC/ We just need someone to confirm this. I think that everything is fine now, however I can't be sure. Problem solved? Title: Re: WARNING: blockchain split Post by: yohanip on July 04, 2015, 09:29:22 AM so two chinese pools went unintentionally rogue and forked bitcoin. however, they made a rollback and fixed the problem, does that summarize the issue? i think bitcoin system made it's own back choosing for the valid chain Title: Re: WARNING: blockchain split Post by: uvt9 on July 04, 2015, 09:31:33 AM i think bitcoin system made it's own back choosing for the valid chain No the system didn't correct itself. It required those pools updating their software in order to mine blocks properly. Title: Re: WARNING: blockchain split Post by: BoikaColor on July 04, 2015, 09:34:28 AM Oh, shit !
Title: Re: WARNING: blockchain split Post by: Geremia on July 04, 2015, 09:37:24 AM Bitcoin-Qt gave me some warning/alert I'd never seen before. Was it related to this blockchain split?
Title: Re: WARNING: blockchain split Post by: trasla on July 04, 2015, 09:38:13 AM Even though double spending is for sure easier during a fork, remember that the transaction you receive is probably fine for both chains. So even if the confirmations people see from the wrong chain are not valid, its not like every tx sent will just be rolled back or disappear, the miners on the right chain will have heard about your tx as well and even if its not included yet they will likely reject conflicting transactions.
Title: Re: WARNING: blockchain split Post by: trasla on July 04, 2015, 09:39:26 AM i think bitcoin system made it's own back choosing for the valid chain No the system didn't correct itself. It required those pools updating their software in order to mine blocks properly. Of course the system corrected itself, after 6 blocks the wrong chain was overtaken by the correct one. The fixing and updating of old miners is not needed for bitcoin to work, but for them to still be able to earn money. Title: Re: WARNING: blockchain split Post by: trasla on July 04, 2015, 09:40:35 AM Bitcoin-Qt gave me some warning/alert I'd never seen before. Was it related to this blockchain split? Yes - Gavin used the alert key to put out a warning for all old versions of bitcoin core. This happens rarely, because its only used for serious situations, and you can get rid of it by updating to the newest version. Title: Re: WARNING: blockchain split Post by: Geremia on July 04, 2015, 09:44:33 AM Bitcoin-Qt gave me some warning/alert I'd never seen before. Was it related to this blockchain split? Yes - Gavin used the alert key to put out a warning for all old versions of bitcoin core. This happens rarely, because its only used for serious situations, and you can get rid of it by updating to the newest version. I saw someone else mentioned it on this thread: "Your node software is out of date and may accept an invalid blockchain fork. Do not trust confirmations" That's what I saw, too.Title: Re: WARNING: blockchain split Post by: Quantus on July 04, 2015, 09:48:00 AM Every one calm the fuck down. The problem is not fixed but right now its not a problem.
Here are the events leading up to this. This is what happened; large mining pools in china found out many months/years ago that they could make more money if they didn't wast any time adding transactions to the blocks they mined. You see adding transactions to blocks takes extra time, time they could have been mining. This allowed them to broadcast their found blocks just a little bit faster. Giving them a slight 1% edge over other miners the same size. But then to save even more time they stopped checking the authenticity of blocks coming in from other miners they felt were trusted. Now do you remember the whole Bitcoin transaction malleability scare? The one Mount' Gox said caused them to lose all there bitcoins? That event was fixed with a patch but this patch would only be implemented if 75% of the network agreed to it. Tonight one of the mining farms in china got a bad block that didn't meet the requirements in that patch but broadcast that block saying that it did. Other Chines mining farms took the block without checking to see it was in fact au8thentic and started building/mining with it/off it/on top of it... Causing a very large orphaned chain. Could it happen again? yes unless something changes. It fixed itself tonight but in the future with fewer and fewer full nodes around the world and larger and larger blocks this will only get worse. The larger the blocks the slower the network. Title: Re: WARNING: blockchain split Post by: AleCrypt0 on July 04, 2015, 09:50:32 AM So, after all this discussion, are the SPV wallets (i.e. MultiBit) safe for now?
Title: Re: WARNING: blockchain split Post by: Jeremycoin on July 04, 2015, 09:51:26 AM So, we have to wait 30 confirmations to make sure that it's a real transaction? ??? Just make sure you're using version 0.10.x. Although you should wait a day or two just to be sure.I just curious about this issue 8) Title: Re: WARNING: blockchain split Post by: turvarya on July 04, 2015, 09:52:36 AM [snip] You obviously don't have any idea, what you are talking about. Mt. Gox didn't lose all their Bitcoin because of transaction malleability.Now do you remember the whole Bitcoin transaction malleability scare? The one Mount' Gox said caused them to lose all there bitcoins? [/snip] Title: Re: WARNING: blockchain split Post by: Quantus on July 04, 2015, 09:53:55 AM [snip] You obviously don't have any idea, what you are talking about. Mt. Gox didn't lose all their Bitcoin because of transaction malleability.Now do you remember the whole Bitcoin transaction malleability scare? The one Mount' Gox said caused them to lose all there bitcoins? [/snip] never said they did Title: Re: WARNING: blockchain split Post by: AleCrypt0 on July 04, 2015, 10:01:55 AM Anyone on SPV wallet question?
ARE SPV wallets (i.e. Multibit) safe? Title: Re: WARNING: blockchain split Post by: Quantus on July 04, 2015, 10:04:05 AM Anyone on SPV wallet question? ARE SPV wallets (i.e. Multibit) safe? From this day forward I would say all web based wallets and smart phone wallets are NOT safe. Title: Re: WARNING: blockchain split Post by: rich93 on July 04, 2015, 10:05:41 AM I have skimmed through all the posts in tis thread so far and cannot find much information to help those using multibit wallets. The two posts below are all I could find.
If I start my multibit wallet will it corrupt it if it connects to a node mining invalid blocks? Will I have to download all the headers again if it gets corrupted? Most normal Bitcoin users will be using light weight wallets like multibit, not Bitcoin core, so it's important we get some knowledgeable advice posted for light weight wallet users. ...If you have a SPV client, it will trust the miners to not do something stupid like this and thus it may be on the wrong side of a fork. There is a small chance that you see a transaction with a few confirmations that doesn't make it to the 0.10.x chain. Another update from Peter Todd: "The majority of hashing power is now mining only valid blocks. However, SPV wallets are still vulnerable as they do no validation, and ~4% or so of hashing power is still mining invalid blocks. Don't trust txs in SPV wallets w/o >= 2 confirmations right now." FYI-- no alert message with 0.10.2 now that I upgraded to test this node. Title: Re: WARNING: blockchain split Post by: trasla on July 04, 2015, 10:11:38 AM Anyone on SPV wallet question? ARE SPV wallets (i.e. Multibit) safe? From this day forward I would say all web based wallets and smart phone wallets are NOT safe. Unless, of course, the smartphone wallet is not a spv wallet. All of myceliums server run updated bitcoin core versions :) Title: Re: WARNING: blockchain split Post by: Quantus on July 04, 2015, 10:13:55 AM If your running any web based wallet I would not trust any incoming transactions with less then 20 confirmations. Because they could be orphaned by the network. Chines farms are spitting out a lot of trash these days in the hope they will make more money. They don't have the bandwidth to send out even 1mb blocks. Title: Re: WARNING: blockchain split Post by: favdesu on July 04, 2015, 10:17:53 AM I have skimmed through all the posts in tis thread so far and cannot find much information to help those using multibit wallets. The two posts below are all I could find. If I start my multibit wallet will it corrupt it if it connects to a node mining invalid blocks? Will I have to download all the headers again if it gets corrupted? Most normal Bitcoin users will be using light weight wallets like multibit, not Bitcoin core, so it's important we get some knowledgeable advice posted for light weight wallet users. ...If you have a SPV client, it will trust the miners to not do something stupid like this and thus it may be on the wrong side of a fork. There is a small chance that you see a transaction with a few confirmations that doesn't make it to the 0.10.x chain. Another update from Peter Todd: "The majority of hashing power is now mining only valid blocks. However, SPV wallets are still vulnerable as they do no validation, and ~4% or so of hashing power is still mining invalid blocks. Don't trust txs in SPV wallets w/o >= 2 confirmations right now." FYI-- no alert message with 0.10.2 now that I upgraded to test this node. Thanks for the updates informations. what are SPV wallets? multibit and other light desktop wallets? what about blockchain.info and other online services? Title: Re: WARNING: blockchain split Post by: SISAR on July 04, 2015, 10:19:25 AM Anyone on SPV wallet question? ARE SPV wallets (i.e. Multibit) safe? Using anything other than official Bitcoin-Qt wallet (full node) is playing with fire. For the sake of saving 40GB of HDD space and to have a bit faster syncing you have massively increased a chance for all sort of troubles and you are actualy not contributing to network at all, just draining resources off of it and using up others' connection slots. As far as I know, SPV wallets are not relaying transactions or blocks, they are just like people on Torrent who download stuff but not share anything. Title: Re: WARNING: blockchain split Post by: Quantus on July 04, 2015, 10:19:44 AM even blockchain.info didn't detect these were bad blocks. You can't even trust them!
Title: Re: WARNING: blockchain split Post by: redsn0w on July 04, 2015, 10:22:43 AM even blockchain.info didn't detect these were bad blocks. You can't even trust them! You should trust only 'yourself' and build/run your bitcoin client with the complete blockchain (and after compare the data). Title: Re: WARNING: blockchain split Post by: Meuh6879 on July 04, 2015, 10:26:16 AM so two chinese pools went unintentionally rogue and forked bitcoin. however, they made a rollback and fixed the problem, does that summarize the issue? No. They don't have upgraded our server for the BIP66 ... Title: Re: WARNING: blockchain split Post by: rich93 on July 04, 2015, 10:31:29 AM Anyone on SPV wallet question? ARE SPV wallets (i.e. Multibit) safe? Using anything other than official Bitcoin-Qt wallet (full node) is playing with fire. For the sake of saving 40GB of HDD space and to have a bit faster syncing you have massively increased a chance for all sort of troubles and you are actualy not contributing to network at all, just draining resources off of it and using up others' connection slots. As far as I know, SPV wallets are not relaying transactions or blocks, they are just like people on Torrent who download stuff but not share anything. SPV wallets were Satoshi's idea. He knew they would be needed by people with low spec computers and metered internet connections. People have complained the Bitcoin core wallet can take a week to sync on a low power computer with a slow connection. They say if anything goes wrong whole it's syncing and the database gets corrupted you have to start the whole process again. My computer is too low power and has too little free memory to consider using the Bitcoin core wallet. Not everyone has the choice to use the Bitcoin core wallet, some people have no option but to use SPV wallets. Title: Re: WARNING: blockchain split Post by: SISAR on July 04, 2015, 10:36:45 AM Anyone on SPV wallet question? ARE SPV wallets (i.e. Multibit) safe? Using anything other than official Bitcoin-Qt wallet (full node) is playing with fire. For the sake of saving 40GB of HDD space and to have a bit faster syncing you have massively increased a chance for all sort of troubles and you are actualy not contributing to network at all, just draining resources off of it and using up others' connection slots. As far as I know, SPV wallets are not relaying transactions or blocks, they are just like people on Torrent who download stuff but not share anything. SPV wallets were Satoshi's idea. He knew they would be needed by people with low spec computers and metered internet connections. People have complained the Bitcoin core wallet can take a week to sync on a low power computer with a slow connection. They say if anything goes wrong whole it's syncing and the database gets corrupted you have to start the whole process again. My computer is too low power and has too little free memory to consider using the Bitcoin core wallet. Not everyone has the choice to use the Bitcoin core wallet, some people have no option but to use SPV wallets. "Here I have 100,000 USD and I'll put them at insecure and problematic bank because I have no money for better one". ??? Title: Re: WARNING: blockchain split Post by: Quantus on July 04, 2015, 10:36:53 AM Anyone on SPV wallet question? ARE SPV wallets (i.e. Multibit) safe? Using anything other than official Bitcoin-Qt wallet (full node) is playing with fire. For the sake of saving 40GB of HDD space and to have a bit faster syncing you have massively increased a chance for all sort of troubles and you are actualy not contributing to network at all, just draining resources off of it and using up others' connection slots. As far as I know, SPV wallets are not relaying transactions or blocks, they are just like people on Torrent who download stuff but not share anything. SPV wallets were Satoshi's idea. He knew they would be needed by people with low spec computers and metered internet connections. People have complained the Bitcoin core wallet can take a week to sync on a low power computer with a slow connection. They say if anything goes wrong whole it's syncing and the database gets corrupted you have to start the whole process again. My computer is too low power and has too little free memory to consider using the Bitcoin core wallet. Not everyone has the choice to use the Bitcoin core wallet, some people have no option but to use SPV wallets. With any luck the chinese miners will start to properly authenticate incoming blocks before they start to mine on them. Title: Re: WARNING: blockchain split Post by: favdesu on July 04, 2015, 10:38:46 AM Anyone on SPV wallet question? ARE SPV wallets (i.e. Multibit) safe? Using anything other than official Bitcoin-Qt wallet (full node) is playing with fire. For the sake of saving 40GB of HDD space and to have a bit faster syncing you have massively increased a chance for all sort of troubles and you are actualy not contributing to network at all, just draining resources off of it and using up others' connection slots. As far as I know, SPV wallets are not relaying transactions or blocks, they are just like people on Torrent who download stuff but not share anything. SPV wallets were Satoshi's idea. He knew they would be needed by people with low spec computers and metered internet connections. People have complained the Bitcoin core wallet can take a week to sync on a low power computer with a slow connection. They say if anything goes wrong whole it's syncing and the database gets corrupted you have to start the whole process again. My computer is too low power and has too little free memory to consider using the Bitcoin core wallet. Not everyone has the choice to use the Bitcoin core wallet, some people have no option but to use SPV wallets. "Here I have 100,000 USD and I'll put them in lowest-security bank because I have no money for better one". ??? I use blockchain.info/mycelium as hot wallet and that's absolutely fine and needed in my opinion. however, I would never store a significant amount on them Title: Re: WARNING: blockchain split Post by: Amph on July 04, 2015, 10:43:19 AM there is also a warning on the forum(not for everyone) that is telling you to wait for 30 conf, before trusting a transaction, for those that are worried it is better to leave bitcoin alone for the moment, or upgrade to the last core version, if you're not using a light wallet
Title: Re: WARNING: blockchain split Post by: Quantus on July 04, 2015, 10:45:01 AM Whats really fucked up is that these chinese miners don't even want to use 1MB blocks and people are pushing for a 8MB hard fork.
Upping the max block size will not force these large pools into including more transactions, it could in fact have the opposite affect. Title: Re: WARNING: blockchain split Post by: RealMalatesta on July 04, 2015, 10:47:42 AM Anyone on SPV wallet question? ARE SPV wallets (i.e. Multibit) safe? Using anything other than official Bitcoin-Qt wallet (full node) is playing with fire. For the sake of saving 40GB of HDD space and to have a bit faster syncing you have massively increased a chance for all sort of troubles and you are actualy not contributing to network at all, just draining resources off of it and using up others' connection slots. As far as I know, SPV wallets are not relaying transactions or blocks, they are just like people on Torrent who download stuff but not share anything. SPV wallets were Satoshi's idea. He knew they would be needed by people with low spec computers and metered internet connections. People have complained the Bitcoin core wallet can take a week to sync on a low power computer with a slow connection. They say if anything goes wrong whole it's syncing and the database gets corrupted you have to start the whole process again. My computer is too low power and has too little free memory to consider using the Bitcoin core wallet. Not everyone has the choice to use the Bitcoin core wallet, some people have no option but to use SPV wallets. "Here I have 100,000 USD and I'll put them at insecure and problematic bank because I have no money for better one". ??? Not everybody has 100'000 USD on its wallet (I wish I had, though). Especially if you want to have some petty money on the laptop, mobile or tablet, SPV wallets are pretty handy. I, for example, have one mobile phone which I use about five times a year. SPV is best for it... Title: Re: WARNING: blockchain split Post by: JerryCurlzzz on July 04, 2015, 10:53:23 AM Just saw the warning. Glad I did. I use Electrum for my hot wallet. (Not that I keep much in it anyway)
Is there any news on this? I've looked through the end of the thread -- this is where the warning points -- and it appears unresolved. Am I crazy or shouldn't this be an easy fix for these pools? Title: Re: WARNING: blockchain split Post by: rich93 on July 04, 2015, 10:54:05 AM Anyone on SPV wallet question? ARE SPV wallets (i.e. Multibit) safe? Using anything other than official Bitcoin-Qt wallet (full node) is playing with fire. For the sake of saving 40GB of HDD space and to have a bit faster syncing you have massively increased a chance for all sort of troubles and you are actualy not contributing to network at all, just draining resources off of it and using up others' connection slots. As far as I know, SPV wallets are not relaying transactions or blocks, they are just like people on Torrent who download stuff but not share anything. SPV wallets were Satoshi's idea. He knew they would be needed by people with low spec computers and metered internet connections. People have complained the Bitcoin core wallet can take a week to sync on a low power computer with a slow connection. They say if anything goes wrong whole it's syncing and the database gets corrupted you have to start the whole process again. My computer is too low power and has too little free memory to consider using the Bitcoin core wallet. Not everyone has the choice to use the Bitcoin core wallet, some people have no option but to use SPV wallets. "Here I have 100,000 USD and I'll put them at insecure and problematic bank because I have no money for better one". ??? Not everybody has 100'000 USD on its wallet (I wish I had, though). Especially if you want to have some petty money on the laptop, mobile or tablet, SPV wallets are pretty handy. I, for example, have one mobile phone which I use about five times a year. SPV is best for it... There have been attempts to get the unbanked in third world countries to use Bitcoin. they would be lucky if they could afford the most basic Android phone there is. SPV wallets are the only option for them. You cannot tell them they should only use Bitcoin core because they probably don't own computers. What we might consider petty money on a mobile phone might be a lot of money to them. Title: Re: WARNING: blockchain split Post by: JorgeStolfi on July 04, 2015, 10:58:17 AM I love how the problem was essentially fixed by the time I found this thread. The tech community is so efficient It was solved promptly because Greg Maxwell (@nullc) and perhaps other devs were awake and carefully watching the blockchain for the BIP66 activation. They spotted the problem right away and promptly warned the SPV miners. Had the devs been sleeping or busy at the time, the accident would have been nastier. Title: Re: WARNING: blockchain split Post by: favdesu on July 04, 2015, 10:58:42 AM Just saw the warning. Glad I did. I use Electrum for my hot wallet. (Not that I keep much in it anyway) Is there any news on this? I've looked through the end of the thread -- this is where the warning points -- and it appears unresolved. Am I crazy or shouldn't this be an easy fix for these pools? electrum uses nodes. go to console and check the status "This node is running bitcoind 0.10.0 with no scheduled restarts." < means you're good to go Title: Re: WARNING: blockchain split Post by: JorgeStolfi on July 04, 2015, 10:59:23 AM Did anybody else notice that (at the time of writing this) the 3 biggest pools have exactly 51% of the total hashrate between them? I do not think it is relevant. Just an observation. The top 4-5 Chinese pools have a lot more than 50%. Title: Re: WARNING: blockchain split Post by: btc_enigma on July 04, 2015, 11:02:13 AM Can someone explain why 0.9 bitcoind are not safe to use ? Won't they also catch up to the longest chain later ?
Title: Re: WARNING: blockchain split Post by: RealMalatesta on July 04, 2015, 11:04:58 AM Anyone on SPV wallet question? ARE SPV wallets (i.e. Multibit) safe? Using anything other than official Bitcoin-Qt wallet (full node) is playing with fire. For the sake of saving 40GB of HDD space and to have a bit faster syncing you have massively increased a chance for all sort of troubles and you are actualy not contributing to network at all, just draining resources off of it and using up others' connection slots. As far as I know, SPV wallets are not relaying transactions or blocks, they are just like people on Torrent who download stuff but not share anything. SPV wallets were Satoshi's idea. He knew they would be needed by people with low spec computers and metered internet connections. People have complained the Bitcoin core wallet can take a week to sync on a low power computer with a slow connection. They say if anything goes wrong whole it's syncing and the database gets corrupted you have to start the whole process again. My computer is too low power and has too little free memory to consider using the Bitcoin core wallet. Not everyone has the choice to use the Bitcoin core wallet, some people have no option but to use SPV wallets. "Here I have 100,000 USD and I'll put them at insecure and problematic bank because I have no money for better one". ??? Not everybody has 100'000 USD on its wallet (I wish I had, though). Especially if you want to have some petty money on the laptop, mobile or tablet, SPV wallets are pretty handy. I, for example, have one mobile phone which I use about five times a year. SPV is best for it... There have been attempts to get the unbanked in third world countries to use Bitcoin. they would be lucky if they could afford the most basic Android phone there is. SPV wallets are the only option for them. You cannot tell them they should only use Bitcoin core because they probably don't own computers. What we might consider petty money on a mobile phone might be a lot of money to them. I absolutely agree. I run a couple of core wallets and a node,, though, but I just have to look at my family and see that they want - and need - a quicker solution which makes it easy for them. Here we are again discussing mass adaption... Title: Re: WARNING: blockchain split Post by: SISAR on July 04, 2015, 11:05:13 AM Anyone on SPV wallet question? ARE SPV wallets (i.e. Multibit) safe? Using anything other than official Bitcoin-Qt wallet (full node) is playing with fire. For the sake of saving 40GB of HDD space and to have a bit faster syncing you have massively increased a chance for all sort of troubles and you are actualy not contributing to network at all, just draining resources off of it and using up others' connection slots. As far as I know, SPV wallets are not relaying transactions or blocks, they are just like people on Torrent who download stuff but not share anything. SPV wallets were Satoshi's idea. He knew they would be needed by people with low spec computers and metered internet connections. People have complained the Bitcoin core wallet can take a week to sync on a low power computer with a slow connection. They say if anything goes wrong whole it's syncing and the database gets corrupted you have to start the whole process again. My computer is too low power and has too little free memory to consider using the Bitcoin core wallet. Not everyone has the choice to use the Bitcoin core wallet, some people have no option but to use SPV wallets. "Here I have 100,000 USD and I'll put them at insecure and problematic bank because I have no money for better one". ??? Not everybody has 100'000 USD on its wallet (I wish I had, though). Especially if you want to have some petty money on the laptop, mobile or tablet, SPV wallets are pretty handy. I, for example, have one mobile phone which I use about five times a year. SPV is best for it... Well, this whole thread and many others are proof SPV wallets suck balls. Title: Re: WARNING: blockchain split Post by: turvarya on July 04, 2015, 11:06:27 AM Can someone explain why 0.9 bitcoind are not safe to use ? Won't they also catch up to the longest chain later ? They allow invalid blocks.So, if you have 2 chains one with invalid blocks and one without. Bitcoin Core 0.9 would chose the longest block as the right one. Bitcoin Core 0.10.2 would just ignore the chain with the invalid blocks. Title: Re: WARNING: blockchain split Post by: Meuh6879 on July 04, 2015, 11:06:55 AM If PEOPLE use Bitcoin Core 0.10.2 or 0.11.0 RC3, they don't have problem.
On bottom, the complet LOG of the blockversion error (v2) ... and the correction of the network (bitcoin !) after this (v3) with 12 blocks in row to invalidate the v2 ORPHAN blocks. No problem here, the blockchain is true ... and Bitcoin Core do the job. Code: 2015-07-04 01:56:19 ERROR: ContextualCheckBlockHeader : rejected nVersion=2 block Title: Re: WARNING: blockchain split Post by: Sorros on July 04, 2015, 11:07:40 AM Just saw the warning. Glad I did. I use Electrum for my hot wallet. (Not that I keep much in it anyway) Is there any news on this? I've looked through the end of the thread -- this is where the warning points -- and it appears unresolved. Am I crazy or shouldn't this be an easy fix for these pools? electrum uses nodes. go to console and check the status "This node is running bitcoind 0.10.0 with no scheduled restarts." < means you're good to go Which is command for status check? Title: Re: WARNING: blockchain split Post by: cakir on July 04, 2015, 11:08:03 AM This situation looks like my "catastrophe scenario" on Bitcoin Network. https://bitcointalk.org/index.php?topic=1087583
There were 2 major chains (1 was legit, the other one wasn't by Chinese miners). For now "miners" integrated into Main chain, But what would happen if they insisted on their chain? Title: Re: WARNING: blockchain split Post by: SISAR on July 04, 2015, 11:10:34 AM Can someone explain why 0.9 bitcoind are not safe to use ? Won't they also catch up to the longest chain later ? They allow invalid blocks.So, if you have 2 chains one with invalid blocks and one without. Bitcoin Core 0.9 would chose the longest block as the right one. Bitcoin Core 0.10.2 would just ignore the chain with the invalid blocks. Bitcoin always choses blockchain with the most work done (sum of all hashes that were used to create blocks, since genesis block) which is not neccessarily the longest blockchain. Title: Re: WARNING: blockchain split Post by: Herbert2020 on July 04, 2015, 11:11:45 AM Just saw the warning. Glad I did. I use Electrum for my hot wallet. (Not that I keep much in it anyway) Is there any news on this? I've looked through the end of the thread -- this is where the warning points -- and it appears unresolved. Am I crazy or shouldn't this be an easy fix for these pools? electrum uses nodes. go to console and check the status "This node is running bitcoind 0.10.0 with no scheduled restarts." < means you're good to go Which is command for status check? on the last tab (console) some of the nodes mention what version of bitcoind they are using. i think that is enough. EDIT: for example this one: "erbium1.sytes.net" says "bitcoind 0.10.0 (full node)" Title: Re: WARNING: blockchain split Post by: turvarya on July 04, 2015, 11:17:54 AM Can someone explain why 0.9 bitcoind are not safe to use ? Won't they also catch up to the longest chain later ? They allow invalid blocks.So, if you have 2 chains one with invalid blocks and one without. Bitcoin Core 0.9 would chose the longest block as the right one. Bitcoin Core 0.10.2 would just ignore the chain with the invalid blocks. Bitcoin always choses blockchain with the most work done (sum of all hashes that were used to create blocks, since genesis block) which is not neccessarily the longest blockchain. Bitcoin chooses the valid blockchain, with the most work in it. Huge difference. Title: Re: WARNING: blockchain split Post by: turvarya on July 04, 2015, 11:21:03 AM This situation looks like my "catastrophe scenario" on Bitcoin Network. https://bitcointalk.org/index.php?topic=1087583 You have to differ between miners and pools. If pools would go rough, the miners would most probably go to another pool. Miners would suffer the most from such a blockchain war, since they have all this expensive hardware, which is worthless without Bitcoin.There were 2 major chains (1 was legit, the other one wasn't by Chinese miners). For now "miners" integrated into Main chain, But what would happen if they insisted on their chain? Title: Re: WARNING: blockchain split Post by: randy8777 on July 04, 2015, 11:30:00 AM glad i use the latest version of bitcoin core, not sure why people still use older versions as it doesn't require more than 1 minute to update the wallet.
Title: Re: WARNING: blockchain split Post by: NUFCrichard on July 04, 2015, 11:33:31 AM This situation looks like my "catastrophe scenario" on Bitcoin Network. https://bitcointalk.org/index.php?topic=1087583 You have to differ between miners and pools. If pools would go rough, the miners would most probably go to another pool. Miners would suffer the most from such a blockchain war, since they have all this expensive hardware, which is worthless without Bitcoin.There were 2 major chains (1 was legit, the other one wasn't by Chinese miners). For now "miners" integrated into Main chain, But what would happen if they insisted on their chain? It does sound quite a worrying situation that some pools can so easily and accidently go rogue and basically make all transactions questionable. Imagine if they or someone else decided to try to mess up the network, 30 confirmations is a very long time to wait. I have updated my qt and will wait a while before using electrum, I won't be spending any BTC until this evening anyway. Title: Re: WARNING: blockchain split Post by: unamis76 on July 04, 2015, 11:34:29 AM So, I was AFK and only noticed this now... Sent 2 transactions from an SPV wallet 2 hours ago, I hope they confirm normally. At least the forking issue seems to be no more...
And there we have it, folks SPV mining. Amazing ::) I hope everyone starts taking this seriously and start validating blocks. It's of everyone's best interest to keep the blockchain healthy. I thought miners were aware of that, but apparently not. Quickly relaying blocks isn't going to give them profit, validating blocks and keeping the blockchain running smoothly is, I hope they learned it this time. Title: Re: WARNING: blockchain split Post by: RealBitcoin on July 04, 2015, 11:41:38 AM OMG WTF guys? I`m getting scared. So if i just send now a transaction, then i lose my bitcoins and it doesnt get to the other end? Also what if i buy now bitcoin with € do i get fake bitcoin if the merchant is on wrong chain? This could be a serious problem. No FUD intended but seriously, i`m starting to panic/ ??? OMG WTF please read carefully before getting panic. Everything is settled, those who using Bitcoin core older than 0.10 and was receiving payment during fork period should wait at least 30 confirmations. OMG WTF guys? I`m getting scared. Just relax. Why would you panic at all? Obviously you're that kind of person, so how about you just pause everything related to Bitcoin for a day or two?So if i just send now a transaction, then i lose my bitcoins and it doesnt get to the other end? Also what if i buy now bitcoin with € do i get fake bitcoin if the merchant is on wrong chain? This could be a serious problem. No FUD intended but seriously, i`m starting to panic/ ??? You don't buy Bitcoin from merchants, but rather on exchanges. Even if something does go wrong I'm pretty sure that Bitstamp would reimburse you. https://bchain.info/BTC/ We just need someone to confirm this. I think that everything is fine now, however I can't be sure. Problem solved? Ok so for example i got an older bitcoin core version, way before the header stuff was included. So if i download the latest version, do i have to redownload the blockchain too? Because the blocks got corrupted? Also i use blockchain.info as a secondary online wallet, do i have to worry when i send or when i receive bitcoins? Title: Re: WARNING: blockchain split Post by: n2004al on July 04, 2015, 11:44:22 AM Also i use blockchain.info as a secondary online wallet, do i have to worry when i send or when i receive bitcoins? Read the previous posts in this thread. You will find an answer. Title: Re: WARNING: blockchain split Post by: Triple on July 04, 2015, 11:47:35 AM This seems to be only a minor problem for now. The problem will get updated and it should be fixed fairly quickly.
Title: Re: WARNING: blockchain split Post by: chupatolas on July 04, 2015, 11:55:28 AM did the problem keeps ? i saw several reply but no one said yet that is all ok,soo fake transactions sounds a bad way hope blockhains just fix those mistake
Title: Re: WARNING: blockchain split Post by: favdesu on July 04, 2015, 11:56:10 AM Ok so for example i got an older bitcoin core version, way before the header stuff was included. So if i download the latest version, do i have to redownload the blockchain too? Because the blocks got corrupted? Also i use blockchain.info as a secondary online wallet, do i have to worry when i send or when i receive bitcoins? If you run the latest core version you're fine. as for blockchain.info - they did not even identify this issue (read up in this thread) - so it's not save to use them at the moment. Title: Re: WARNING: blockchain split Post by: n2004al on July 04, 2015, 11:57:56 AM did the problem keeps ? i saw several reply but no one said yet that is all ok,soo fake transactions sounds a bad way hope blockhains just fix those mistake I think the answer is that that is written in the news of this forum: "If you are using any wallet other than Bitcoin Core 0.10.x or 0.9.5, then you should not trust incoming transactions until they have ~30 confirmations." Title: Re: WARNING: blockchain split Post by: Mr.Money on July 04, 2015, 12:11:06 PM Hi your mine about bicoin core is about program ? or website ? i always use of website and have good job
Title: Re: WARNING: blockchain split Post by: shorena on July 04, 2015, 12:25:56 PM Hi your mine about bicoin core is about program ? or website ? i always use of website and have good job It depends which version of bitcoin core the website uses. Contact their support and ask. Title: Re: WARNING: blockchain split Post by: BitUsher on July 04, 2015, 12:41:06 PM Note from Gregory Maxwell on reasons why the alert was delayed--
Quote from: nullc I made a conscious decision to delay sending out a warning since there were no transaction conflicts and most of the hashpower on the invalid chain was not mining transactions. This was discussed, in public, with the rest of the technical crew that was minding the issue. Without any conflicts at play yet the fork was harmless, and I thought it was better to gather more information before acting and the rest of the active tech folks seemed to agree. Had conflicts shown up the alert would have gone out immediately. It was also the case that all versions of Bitcoin Core who would have been on the invalid fork would have been displaying an automatically generated alert due to the presence of 'future' version blocks. Official Status and recommendations-- https://bitcoin.org/en/alert/2015-07-04-spv-mining ome Miners Generating Invalid Blocks 4 July 2015 This document is being updated as new information arrives. Last update: 2015-07-04 09:30 UTC Summary Your bitcoins are safe if you received them in transactions confirmed before 2015-07-04 08:00 UTC. However, there has been a problem with a planned upgrade. For bitcoins received later than the time above, confirmation scores are significantly less reliable then they usually are for users of certain software: Lightweight (SPV) wallet users should wait an additional 30 confirmations more than you would normally wait. Bitcoin Core 0.9.4 or earlier users should wait an additional 30 confirmations more than you would normally wait or upgrade to Bitcoin Core 0.10.2. Web wallet users should wait an additional 30 confirmations more than you would normally wait, unless you know for sure that your wallet is secured by Bitcoin Core 0.9.5 or later. Bitcoin Core 0.9.5 or later users are unaffected. Miners If you pool mine, please switch to a pool that properly validates blocks. (If you solo mine, please switch to Bitcoin Core 0.10.2.) Bad pools: these pools are not correctly validating, and are losing money. BTC Nuggets Good pools: these pools properly validate blocks. Please switch to them, at least until the bad pools have fixed their systems. Eligius kano/ckpool P2Pool F2Pool When Will Things Go Back To Normal? The problem is miners creating invalid blocks. Some software can detect that those blocks are invalid and reject them; other software can't detect that blocks are invalid, so they show confirmations that aren't real. Bitcoin Core 0.9.5 and later never had any problems because it could detect which blocks were invalid. Bitcoin Core 0.9.4 and earlier will never provide as much security as later versions of Bitcoin Core because it doesn't know about the additional BIP66 consensus rules. Upgrade is recommended to return to full node security. Lightweight (SPV) wallets are not safe for less than 30 confirmations until all the major pools switch to full validation. Web wallets are very diverse in what infrastructure they run and how they handle double spends, so unless you know for sure that they use Bitcoin Core 0.9.5 or later for full validation, you should assume they have the same security as the lightweight wallets described above. What's Happening Summary: Some miners are currently generating invalid blocks. Almost all software (besides Bitcoin Core 0.9.5 and later) will accept these invalid blocks under certain conditions. The paragraphs that follow explain the cause more throughly. For several months, an increasing amount of mining hash rate has been signaling its intent to begin enforcing BIP66 strict DER signatures. As part of the BIP66 rules, once 950 of the last 1,000 blocks were version 3 (v3) blocks, all upgraded miners would reject version 2 (v2) blocks. Early morning UTC on 4 July 2015, the 950/1000 (95%) threshold was reached. Shortly thereafter, a small miner (part of the non-upgraded 5%) mined an invalid block--as was an expected occurrence. Unfortunately, it turned out that roughly half the network hash rate was mining without fully validating blocks (called SPV mining), and built new blocks on top of that invalid block. Note that the roughly 50% of the network that was SPV mining had explicitly indicated that they would enforce the BIP66 rules. By not doing so, several large miners have lost over $50,000 dollars worth of mining income so far. All software that assumes blocks are valid (because invalid blocks cost miners money) is at risk of showing transactions as confirmed when they really aren't. This particularly affects lightweight (SPV) wallets and software such as old versions of Bitcoin Core which have been downgraded to SPV-level security by the new BIP66 consensus rules. The immediate fix, which is well underway as of this writing, is to get all miners off of SPV mining and back to full validation (at least temporarily). As this progresses, we will reduce our current recommendation of waiting 30 extra confirmations to a lower number. Title: Re: WARNING: blockchain split Post by: thebenjamincode on July 04, 2015, 12:53:45 PM what is the meaning of this?
does it mean that bitcoin may have a bug or something? how did this happen? is it a flaw on bitcoin system? well i hope its not because i think it will be a serious problem if many things like this occurs in the future Title: Re: WARNING: blockchain split Post by: jl2012 on July 04, 2015, 01:00:58 PM what is the meaning of this? does it mean that bitcoin may have a bug or something? how did this happen? is it a flaw on bitcoin system? well i hope its not because i think it will be a serious problem if many things like this occurs in the future In short: some miners are not doing their job properly. As far as I know, this is the first incident of this kind. However, if many miners keep their sub-optimal practice, we may have similar problem again. Title: Re: WARNING: blockchain split Post by: LFC_Bitcoin on July 04, 2015, 01:01:51 PM So this will only potentially effect people who are making transaction, sending & receiving coins atm?
If I'm a simple HODLER & haven't & won't be buying any coins this weekend I'm safe & ok yes? My BTC's in several wallets & paper wallets are ok & I can totally ignore this? Thanks in advance to anybody who responds. Title: Re: WARNING: blockchain split Post by: QuestionAuthority on July 04, 2015, 01:04:28 PM http://www.spatch.net/woon/snlcredits-notready.jpg
http://www.blogcdn.com/www.aoltv.com/media/2010/10/snlnewcast300.jpghttps://i.imgur.com/bTafdrx.png Title: Re: WARNING: blockchain split Post by: EvilDave on July 04, 2015, 01:08:08 PM Quote Summary: Some miners are currently generating invalid blocks. Almost all software (besides Bitcoin Core 0.9.5 and later) will accept these invalid blocks under certain conditions. The paragraphs that follow explain the cause more throughly. For several months, an increasing amount of mining hash rate has been signaling its intent to begin enforcing BIP66 strict DER signatures. As part of the BIP66 rules, once 950 of the last 1,000 blocks were version 3 (v3) blocks, all upgraded miners would reject version 2 (v2) blocks. Early morning UTC on 4 July 2015, the 950/1000 (95%) threshold was reached. Shortly thereafter, a small miner (part of the non-upgraded 5%) mined an invalid block--as was an expected occurrence. Unfortunately, it turned out that roughly half the network hash rate was mining without fully validating blocks (called SPV mining), and built new blocks on top of that invalid block. Note that the roughly 50% of the network that was SPV mining had explicitly indicated that they would enforce the BIP66 rules. By not doing so, several large miners have lost over $50,000 dollars worth of mining income so far. All software that assumes blocks are valid (because invalid blocks cost miners money) is at risk of showing transactions as confirmed when they really aren't. This particularly affects lightweight (SPV) wallets and software such as old versions of Bitcoin Core which have been downgraded to SPV-level security by the new BIP66 consensus rules. The immediate fix, which is well underway as of this writing, is to get all miners off of SPV mining and back to full validation (at least temporarily). As this progresses, we will reduce our current recommendation of waiting 30 extra confirmations to a lower number. Just for some extra clarity.......... For consumer level users: make sure that you (or your wallet provider) are on Bitcoin 0.9.5 or later, and wait for 30 confirmations on your transfers. For miners: stop SPV mining, validate everything or lose income. (and, obviously, transfer all your BTC into nice stable NXT....... ;D ) Title: Re: WARNING: blockchain split Post by: MarkCara on July 04, 2015, 01:09:02 PM Does it affect coinbase and btc-e ?
Title: Re: WARNING: blockchain split Post by: jl2012 on July 04, 2015, 01:10:30 PM So this will only potentially effect people who are making transaction, sending & receiving coins atm? If I'm a simple HODLER & haven't & won't be buying any coins this weekend I'm safe & ok yes? Thanks in advance to anybody who responds. Hodlers are unaffected Payers, technically speaking, are unaffected, despite that your payees may require more confirmations than usual Payees, with Bitcoin core 0.9.5 or above, are unaffected. Payees, with anything else, please follow the instructions in the header of the forum Title: Re: WARNING: blockchain split Post by: jl2012 on July 04, 2015, 01:11:41 PM Does it affect coinbase and btc-e ? I guess not affected but only they could confirm. Anyone using Bitcoin Core 0.9.5 or above is safe Title: Re: WARNING: blockchain split Post by: Altcoin4life on July 04, 2015, 01:15:07 PM Is there a way to force those spv mining to have their work count as less to discourage it?
Title: Re: WARNING: blockchain split Post by: Scamalert on July 04, 2015, 01:18:11 PM Wonderful to see how quick the community take action and got this problem under control.
Also great to see that the bitcoin exhange rate is pretty much unaffected. Just show that everything is under control. Pretty amature of those pools who did not support the BIP66, I well guess they paid the price with all the orphan blocks they mined, hope they learned a leasson. Title: Re: WARNING: blockchain split Post by: favdesu on July 04, 2015, 01:19:45 PM Is there a way to force those spv mining to have their work count as less to discourage it? if I understand it correctly, they are losing a lot of money at the moment due to mining on an obsolete fork... so that's punishment Title: Re: WARNING: blockchain split Post by: BitUsher on July 04, 2015, 01:23:32 PM Just for some extra clarity.......... For consumer level users: make sure that you (or your wallet provider) (and, obviously, transfer all your BTC into nice stable NXT....... ;D ) Consumers on 0.9.5 or later are safe an do not have to wait for 30 confirmations. This recommendation is for SPV/web wallet wallet users who are unaware which version they are connected to. Most web wallets and SPV wallets are safe in reality but users should either check or wait 30 confirmations. This is a large warning to users to not only be careful and skeptical about bitcoin but be that more careful with using any alt as they have a small fraction of developers debugging , testing and warning users compared to bitcoin. So this will only potentially effect people who are making transaction, sending & receiving coins atm? If I'm a simple HODLER & haven't & won't be buying any coins this weekend I'm safe & ok yes? My BTC's in several wallets & paper wallets are ok & I can totally ignore this? Thanks in advance to anybody who responds. This only effect Bitcoin users using a node that is 0.9.4 or earlier whether directly or through an SPV /web wallet. The only risk they have is if a malicious attacker tries to double spend with them. To avoid this check with your connected node to make sure you are up to date, use an up to date bitcoin core node, or wait 30 confirmations. There was never any risks to you losing your coins in paper wallets or cold storage even if you started up an old version of core. Title: Re: WARNING: blockchain split Post by: dooglus on July 04, 2015, 01:30:57 PM As part of the BIP66 rules, once 950 of the last 1,000 blocks were version 3 (v3) blocks, all upgraded miners would reject version 2 (v2) blocks. Early morning UTC on 4 July 2015, the 950/1000 (95%) threshold was reached. Shortly thereafter, a small miner (part of the non-upgraded 5%) mined an invalid block--as was an expected occurrence. Unfortunately, it turned out that roughly half the network hash rate was mining without fully validating blocks (called SPV mining), and built new blocks on top of that invalid block. Note that the roughly 50% of the network that was SPV mining had explicitly indicated that they would enforce the BIP66 rules. By not doing so, several large miners have lost over $50,000 dollars worth of mining income so far. The bolded points: 95% of the network was claiming to be mining v3 blocks, 50% of the network was SPV mining, but only 50% of the SPV miners were claiming to be mining v3 blocks? Doesn't that mean that 50% of the SPV miners, and so 25% of the network wasn't claiming to be mining v3 blocks? If so, how did we reach the 95% trigger? Title: Re: WARNING: blockchain split Post by: S4VV4S on July 04, 2015, 01:36:23 PM As part of the BIP66 rules, once 950 of the last 1,000 blocks were version 3 (v3) blocks, all upgraded miners would reject version 2 (v2) blocks. Early morning UTC on 4 July 2015, the 950/1000 (95%) threshold was reached. Shortly thereafter, a small miner (part of the non-upgraded 5%) mined an invalid block--as was an expected occurrence. Unfortunately, it turned out that roughly half the network hash rate was mining without fully validating blocks (called SPV mining), and built new blocks on top of that invalid block. Note that the roughly 50% of the network that was SPV mining had explicitly indicated that they would enforce the BIP66 rules. By not doing so, several large miners have lost over $50,000 dollars worth of mining income so far. The bolded points: 95% of the network was claiming to be mining v3 blocks, 50% of the network was SPV mining, but only 50% of the SPV miners were claiming to be mining v3 blocks? Doesn't that mean that 50% of the SPV miners, and so 25% of the network wasn't claiming to be mining v3 blocks? If so, how did we reach the 95% trigger? Perhaps they were only claiming to be mining v3 blocks but not actually doing so... ? Title: Re: WARNING: blockchain split Post by: BitUsher on July 04, 2015, 01:38:58 PM As part of the BIP66 rules, once 950 of the last 1,000 blocks were version 3 (v3) blocks, all upgraded miners would reject version 2 (v2) blocks. Early morning UTC on 4 July 2015, the 950/1000 (95%) threshold was reached. Shortly thereafter, a small miner (part of the non-upgraded 5%) mined an invalid block--as was an expected occurrence. Unfortunately, it turned out that roughly half the network hash rate was mining without fully validating blocks (called SPV mining), and built new blocks on top of that invalid block. Note that the roughly 50% of the network that was SPV mining had explicitly indicated that they would enforce the BIP66 rules. By not doing so, several large miners have lost over $50,000 dollars worth of mining income so far. The bolded points: 95% of the network was claiming to be mining v3 blocks, 50% of the network was SPV mining, but only 50% of the SPV miners were claiming to be mining v3 blocks? Doesn't that mean that 50% of the SPV miners, and so 25% of the network wasn't claiming to be mining v3 blocks? If so, how did we reach the 95% trigger? I has nothing directly to do with BIP66 (although this is what was the case this time) as this scenario would have existed for any invalid block being picked up by SPV miners. F2Pool and Antpool who were SPV mining actually did adopt v3 blocks/ BIP 66 but due to not validating BTC Nuggets block (to gain a slight latency advantage) they began mining on the wrong chain. Thus it was BTC Nuggets who was part of the 5% who didn't upgrade to the newest v3 blocks. Perhaps they were only claiming to be mining v3 blocks but not actually doing so... ? It is not possible unless they quickly switched back to v2 blocks after updating to v3 and the 95% thresh-hold was reached. All evidence points to a risk they undertook by the process of SPV mining itself where they picked up on BTC Nuggets invalid block without validating it. Title: Re: WARNING: blockchain split Post by: scarsbergholden on July 04, 2015, 01:39:30 PM As part of the BIP66 rules, once 950 of the last 1,000 blocks were version 3 (v3) blocks, all upgraded miners would reject version 2 (v2) blocks. Early morning UTC on 4 July 2015, the 950/1000 (95%) threshold was reached. Shortly thereafter, a small miner (part of the non-upgraded 5%) mined an invalid block--as was an expected occurrence. Unfortunately, it turned out that roughly half the network hash rate was mining without fully validating blocks (called SPV mining), and built new blocks on top of that invalid block. Note that the roughly 50% of the network that was SPV mining had explicitly indicated that they would enforce the BIP66 rules. By not doing so, several large miners have lost over $50,000 dollars worth of mining income so far. The bolded points: 95% of the network was claiming to be mining v3 blocks, 50% of the network was SPV mining, but only 50% of the SPV miners were claiming to be mining v3 blocks? Doesn't that mean that 50% of the SPV miners, and so 25% of the network wasn't claiming to be mining v3 blocks? If so, how did we reach the 95% trigger? Perhaps they were only claiming to be mining v3 blocks but not actually doing so... ? Is there a explorer we could see on this fork, because it would be good to compare block times and since what block has this started from their claims. Title: Re: WARNING: blockchain split Post by: dooglus on July 04, 2015, 01:42:10 PM As part of the BIP66 rules, once 950 of the last 1,000 blocks were version 3 (v3) blocks, all upgraded miners would reject version 2 (v2) blocks. Early morning UTC on 4 July 2015, the 950/1000 (95%) threshold was reached. Shortly thereafter, a small miner (part of the non-upgraded 5%) mined an invalid block--as was an expected occurrence. Unfortunately, it turned out that roughly half the network hash rate was mining without fully validating blocks (called SPV mining), and built new blocks on top of that invalid block. Note that the roughly 50% of the network that was SPV mining had explicitly indicated that they would enforce the BIP66 rules. By not doing so, several large miners have lost over $50,000 dollars worth of mining income so far. The bolded points: 95% of the network was claiming to be mining v3 blocks, 50% of the network was SPV mining, but only 50% of the SPV miners were claiming to be mining v3 blocks? Doesn't that mean that 50% of the SPV miners, and so 25% of the network wasn't claiming to be mining v3 blocks? If so, how did we reach the 95% trigger? Perhaps they were only claiming to be mining v3 blocks but not actually doing so... ? I think you missed my point. Title: Re: WARNING: blockchain split Post by: monbux on July 04, 2015, 01:45:43 PM So this will only potentially effect people who are making transaction, sending & receiving coins atm? If I'm a simple HODLER & haven't & won't be buying any coins this weekend I'm safe & ok yes? Thanks in advance to anybody who responds. Hodlers are unaffected Payers, technically speaking, are unaffected, despite that your payees may require more confirmations than usual Payees, with Bitcoin core 0.9.5 or above, are unaffected. Payees, with anything else, please follow the instructions in the header of the forum I'm using blockchain.info as my day to day use wallet. Title: Re: WARNING: blockchain split Post by: Quickseller on July 04, 2015, 01:49:36 PM As part of the BIP66 rules, once 950 of the last 1,000 blocks were version 3 (v3) blocks, all upgraded miners would reject version 2 (v2) blocks. Early morning UTC on 4 July 2015, the 950/1000 (95%) threshold was reached. Shortly thereafter, a small miner (part of the non-upgraded 5%) mined an invalid block--as was an expected occurrence. Unfortunately, it turned out that roughly half the network hash rate was mining without fully validating blocks (called SPV mining), and built new blocks on top of that invalid block. Note that the roughly 50% of the network that was SPV mining had explicitly indicated that they would enforce the BIP66 rules. By not doing so, several large miners have lost over $50,000 dollars worth of mining income so far. The bolded points: 95% of the network was claiming to be mining v3 blocks, 50% of the network was SPV mining, but only 50% of the SPV miners were claiming to be mining v3 blocks? Doesn't that mean that 50% of the SPV miners, and so 25% of the network wasn't claiming to be mining v3 blocks? If so, how did we reach the 95% trigger? Perhaps they were only claiming to be mining v3 blocks but not actually doing so... ? I think you missed my point. The miners should have started to implement the new rules of the soft fork as soon as they showed the new headers, however some were not doing this, and voted yes but did not implement the new rules Title: Re: WARNING: blockchain split Post by: BitUsher on July 04, 2015, 01:52:26 PM So, just to confirm, you ARE able to send and receive transactions on bitcoin wallets that aren't 0.9.5 and up, as long as you wait for an extra 30 confirmations? I'm using blockchain.info as my day to day use wallet. All users on any wallet can send and receive Tx just fine. The Tx were being picked up on both chains. The risk and reason you would need to wait 30 confirmations had to deal with someone attempting to create a double spend attack where you are using a wallet on 0.9.4 and before that is vulnerable and possibly may be on the wrong chain. In other words : Someone pays you 100 dollars to your SPV wallet which is connected to a node on 0.9.4 or before. That node just so happens to be on the wrong chain. You start to receive confirmations coming in and assume the transaction is good. The attacker is aware of the forked chain and respends the same BTC on the other chain. When your node makes the correction and jumps on the correct chain it invalidates your BTC that was previously confirmed on the wrong chain. Title: Re: WARNING: blockchain split Post by: jl2012 on July 04, 2015, 02:04:24 PM So this will only potentially effect people who are making transaction, sending & receiving coins atm? If I'm a simple HODLER & haven't & won't be buying any coins this weekend I'm safe & ok yes? Thanks in advance to anybody who responds. Hodlers are unaffected Payers, technically speaking, are unaffected, despite that your payees may require more confirmations than usual Payees, with Bitcoin core 0.9.5 or above, are unaffected. Payees, with anything else, please follow the instructions in the header of the forum I'm using blockchain.info as my day to day use wallet. Yes, all wallets are working but you should wait longer if you are not using Bitcoin Core 0.9.5 or above I believe blockchain.info wallet is vulnerable Title: Re: WARNING: blockchain split Post by: yayayo on July 04, 2015, 02:05:25 PM A very serious event for sure - but seems to have been mostly fixed already.
It shows, that relying on SPV wallets is not a good idea at all. Only full nodes offer full security. That's why excessive increases in blocksize are dangerous: The number of full nodes will decline further, because the average user doesn't have the resources to run them. In turn, the system as a whole will become less secure and more vulnerable to events like this. ya.ya.yo! Title: Re: WARNING: blockchain split Post by: Vaccomondus on July 04, 2015, 02:13:15 PM So this will only potentially effect people who are making transaction, sending & receiving coins atm? If I'm a simple HODLER & haven't & won't be buying any coins this weekend I'm safe & ok yes? Thanks in advance to anybody who responds. Hodlers are unaffected Payers, technically speaking, are unaffected, despite that your payees may require more confirmations than usual Payees, with Bitcoin core 0.9.5 or above, are unaffected. Payees, with anything else, please follow the instructions in the header of the forum https://i.imgur.com/9YUxIuw.jpg Title: Re: WARNING: blockchain split Post by: Slark on July 04, 2015, 02:47:50 PM A very serious event for sure - but seems to have been mostly fixed already. What kind of resource are you talkin about? The only thing you need really is disc space (for now blockchain info is about 42GB big) every stationary PC or laptop is capable of storing more.It shows, that relying on SPV wallets is not a good idea at all. Only full nodes offer full security. That's why excessive increases in blocksize are dangerous: The number of full nodes will decline further, because the average user doesn't have the resources to run them. In turn, the system as a whole will become less secure and more vulnerable to events like this. ya.ya.yo! It is not resources we lack, it is that people are lazy is the problem. Title: Re: WARNING: blockchain split Post by: loshia on July 04, 2015, 02:50:37 PM Chinese are famous with their skils ;D
Title: Re: WARNING: blockchain split Post by: Sakarias-Corporation on July 04, 2015, 02:51:21 PM A very serious event for sure - but seems to have been mostly fixed already. What kind of resource are you talkin about? The only thing you need really is disc space (for now blockchain info is about 42GB big) every stationary PC or laptop is capable of storing more.It shows, that relying on SPV wallets is not a good idea at all. Only full nodes offer full security. That's why excessive increases in blocksize are dangerous: The number of full nodes will decline further, because the average user doesn't have the resources to run them. In turn, the system as a whole will become less secure and more vulnerable to events like this. ya.ya.yo! It is not resources we lack, it is that people are lazy is the problem. I don't think you understand.... For some people it will take weeks or worst case a month+ to download the QT... Title: Re: WARNING: blockchain split Post by: neurotypical on July 04, 2015, 02:51:43 PM Cool, i almost had a heart attack as I came really relax after a workout and swimming in the pool. This sounded pretty fucking catastrophic. Glad im paranoid and never went outside Bitcoin QT and always keep it updated. It shows how you can't trust anything that doesn't download the entire blockchain locally. This is a huge problem since in the future maybe it will be impossible for a lot of people to deal with huge ass blockchains. It's also impractical for mass adoption, most people will not deal with full nodes like us nerds do.
Title: Re: WARNING: blockchain split Post by: RustyNomad on July 04, 2015, 02:58:35 PM A very serious event for sure - but seems to have been mostly fixed already. What kind of resource are you talkin about? The only thing you need really is disc space (for now blockchain info is about 42GB big) every stationary PC or laptop is capable of storing more.It shows, that relying on SPV wallets is not a good idea at all. Only full nodes offer full security. That's why excessive increases in blocksize are dangerous: The number of full nodes will decline further, because the average user doesn't have the resources to run them. In turn, the system as a whole will become less secure and more vulnerable to events like this. ya.ya.yo! It is not resources we lack, it is that people are lazy is the problem. I don't think you understand.... For some people it will take weeks or worst case a month+ to download the QT... Plus the bandwidth consumed everyday in staying updated. Not everybody is sitting on a 'no-limits' connection. Title: Re: Blockchain split of 4 July 2015 Post by: chiguireitor on July 04, 2015, 03:05:48 PM Problem solved: switch to a smaller but more dedicated dev's pool (kano, slush, etc) and don't give crap about variance.
Title: Re: WARNING: blockchain split Post by: jonald_fyookball on July 04, 2015, 03:06:06 PM A very serious event for sure - but seems to have been mostly fixed already. It shows, that relying on SPV wallets is not a good idea at all. ya.ya.yo! I don't agree. SPV is fine for everyday and small transactions. Plus you can verify large received transactions on several places if you dont have a full node. Title: Re: Blockchain split of 4 July 2015 Post by: wlefever on July 04, 2015, 03:25:15 PM Well that wasn't something I expected to wake up, and read. Looks like it is mostly fixed at this point, and hopefully can be prevented in the future?
Title: Re: Blockchain split of 4 July 2015 Post by: luthermarcus on July 04, 2015, 03:39:15 PM Here's some more info I found for people interested in what has happened and may happen again.
Block Versions Version 1 was introduced in the genesis block (January 2009). Version 2 was introduced in Bitcoin Core 0.7.0 (September 2012) as a soft fork. As described in BIP34, valid version 2 blocks require a block height parameter in the coinbase. Also described in BIP34 are rules for rejecting certain blocks; based on those rules, Bitcoin Core 0.7.0 and later versions began to reject version 2 blocks without the block height in coinbase at block height 224,412 (March 2013) and began to reject new version 1 blocks three weeks later at block height 227,930. We are here at Version 3 blocks will be introduced when sufficient numbers of miners switch to using Bitcoin Core 0.10.0 and other versions that create version 3 blocks. As described in draft BIP66, this soft fork change requires strict DER encoding for all ECDSA signatures used in transactions appearing in version 3 or later blocks. Transactions that do not use strict DER encoding have been non-standard since Bitcoin Core 0.8.0. Version 4 blocks will likely be introduced in the near-future as specified in draft BIP62. Possible changes include: Reject version 4 blocks that include any version 2 transactions that don’t adhere to any of the version 2 transaction rules. These rules are not yet described in this documentation; see BIP62 for details. A soft fork rollout of version 4 blocks identical to the rollout used for version 3 blocks (described briefly in BIP62 and in more detail in BIP34). https://bitcoin.org/en/developer-reference#block-headers (https://bitcoin.org/en/developer-reference#block-headers) Make sure to stay up to date and if mining make sure your mining pool stays up to date. For what i read this effects you if could get invalid transactions that look "real" because they were considered "real" by "outdated" software. (wallets not update with latest QT) This could be bad in a business transaction say you sent someone money and they said it was invalid bad situation. If your mining you could loss a great portion of blocks which were mined if your pool is on the wrong side or mining the wrong version. Meaning your blocks mined could be nullified. It helps if you have an up-to-date qt wallet to know if those are the blocks from the wrong version but you still loose those blocks meaning pressure your pool to upgrade or switch to one that did. Thank you forrestv for keeping an eye out for P2Pool and continuing to support development Title: Re: Blockchain split of 4 July 2015 Post by: Sitarow on July 04, 2015, 03:44:42 PM Bitcoin version 0.2 is here! Download links: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-win32-setup.exe/download http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-win32.zip/download http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-linux.tar.gz/download New Features Martti Malmi - Minimize to system tray option - Autostart on boot option so you can keep it running in the background automatically - New options dialog layout for future expansion - Setup program for Windows - Linux version (tested on Ubuntu) Satoshi Nakamoto - Multi-processor support for coin generation - Proxy support for use with TOR - Fixed some slowdowns in the initial block download Major thanks to Martti Malmi (sirius-m) for all his coding work and for hosting the new site and this forum, and New Liberty Standard for his help with testing the Linux version. Major thanks was once given to those coding, it may seem today (5+ years on) with all the uncertainty this work has become a thankless endeavor. Lets not forget the principles of what bitcoin is. Title: Re: WARNING: blockchain split Post by: QuestionAuthority on July 04, 2015, 03:56:10 PM A very serious event for sure - but seems to have been mostly fixed already. It shows, that relying on SPV wallets is not a good idea at all. ya.ya.yo! I don't agree. SPV is fine for everyday and small transactions. Plus you can verify large received transactions on several places if you dont have a full node. You're right. I won't use anything but an SPV for everyday use. Soon there will come a time when I won't download the full block chain anymore (that time is almost here). I turn on my desktop computer maybe every few days and use it for a couple of hours. My desktop hasn't caught up with the current block in the last two or three times I've turned it on because I wasn't on it long enough. iPads and phones are making my desktop obsolete. I haven't used anything other than a phone to access this forum in over a year. Title: Re: Blockchain split of 4 July 2015 Post by: sloopy on July 04, 2015, 04:03:52 PM Problem solved: switch to a smaller but more dedicated dev's pool (kano, slush, etc) and don't give crap about variance. Slush isn't listed as one of the "trusted" pools. Why? Title: Re: Blockchain split of 4 July 2015 Post by: Amitabh S on July 04, 2015, 04:19:27 PM Here is some more info on BIP66 from a mailing list that I found useful:
http://sourceforge.net/p/bitcoin/mailman/message/34199290/ Title: Re: Blockchain split of 4 July 2015 Post by: anderson00673 on July 04, 2015, 04:34:29 PM Woah, glad I checked in the forums this morning. Thanks so much for the heads up!
Title: Re: Blockchain split of 4 July 2015 Post by: NorrisK on July 04, 2015, 04:43:22 PM Woah, glad I checked in the forums this morning. Thanks so much for the heads up! This forum is still one of the best places for getting fast heads up on stuff like this! Also good that they highlight it at the top of the forums. Title: Re: Blockchain split of 4 July 2015 Post by: Syke on July 04, 2015, 04:56:27 PM I'm looking forward to the day when mining income is derived mostly from including transactions. Miners/pools who create empty blocks on purpose are bad for the blockchain.
Title: Re: Blockchain split of 4 July 2015 Post by: Sakarias-Corporation on July 04, 2015, 05:03:41 PM I'm looking forward to the day when mining income is derived mostly from including transactions. Miners/pools who create empty blocks on purpose are bad for the blockchain. Won't that be tons of years into the future ? Title: Re: Blockchain split of 4 July 2015 Post by: iCEBREAKER on July 04, 2015, 05:06:13 PM I'm looking forward to the day when mining income is derived mostly from including transactions. Miners/pools who create empty blocks on purpose are bad for the blockchain. By creating problematic 0tx blocks (and reminding us that scaling Bitcoin isn't as simple as bloating a sanity-check constant), miners force the devs to invent better solutions. Et voilà, anti-fragile! Title: Re: WARNING: blockchain split Post by: Scamc0p on July 04, 2015, 05:07:20 PM So the Chines miners are creating invalid blocks but smart phone wallets and even website wallets can't tell they are invalid? Knew the chins would ruin this somehow. Over doing it on mining now, like spoiled fruit.Title: Re: Blockchain split of 4 July 2015 Post by: Scamc0p on July 04, 2015, 05:09:16 PM Woah, glad I checked in the forums this morning. Thanks so much for the heads up! This forum is still one of the best places for getting fast heads up on stuff like this! Also good that they highlight it at the top of the forums. Noticed that today too. But what would happen if forum goes down like last month? That is the reason I had to change my password because of this notice(highlighted) at the top too. Title: Re: Blockchain split of 4 July 2015 Post by: RealBitcoin on July 04, 2015, 05:21:27 PM Did blockchain.info updated their stuff? If not then please PM me when they do i need to send a transaction, but i`m scared to do it at the moment.
Also do bitcoin in safe storage compromized? I mean do i have to create a new address, are private keys compromized because of this? Title: Re: Blockchain split of 4 July 2015 Post by: wpalczynski on July 04, 2015, 05:22:30 PM Did blockchain.info updated their stuff? If not then please PM me when they do i need to send a transaction, but i`m scared to do it at the moment. Also do bitcoin in safe storage compromized? I mean do i have to create a new address, are private keys compromized because of this? Its safe to send. If anything its the receiver that needs to wait for 30+ confirmations to ensure that he will retain the bitcoin. Title: Re: Blockchain split of 4 July 2015 Post by: Amitabh S on July 04, 2015, 05:23:22 PM I'm looking forward to the day when mining income is derived mostly from including transactions. Miners/pools who create empty blocks on purpose are bad for the blockchain. I'm looking forward to the day when income can be made by running a full node. Title: Re: Blockchain split of 4 July 2015 Post by: RealBitcoin on July 04, 2015, 05:25:56 PM Did blockchain.info updated their stuff? If not then please PM me when they do i need to send a transaction, but i`m scared to do it at the moment. Also do bitcoin in safe storage compromized? I mean do i have to create a new address, are private keys compromized because of this? Its safe to send. If anything its the receiver that needs to wait for 30+ confirmations to ensure that he will retain the bitcoin. Only the guy who controls the private keys of the address can double spend right? Also excuse me for my noobness, but i`m not a tech person. How is it safe to send when blockchain.info hasnt updated their client, what if they send that bitcoin to the wrong blockchain, those coins are lost then arent they? ;D Title: Re: Blockchain split of 4 July 2015 Post by: scarsbergholden on July 04, 2015, 05:27:31 PM so the spilt of fork is happening today, good away to celebrate independes day well for those in the U.S actually, it would be so nice to actually make some income from a node one day yea, time frame wise a decade .
Title: Re: Blockchain split of 4 July 2015 Post by: Sakarias-Corporation on July 04, 2015, 05:29:35 PM How long until we only need to wait for 1-6 Confirmations instead of 30 ? (i'm using a Trezor)
Title: Re: Blockchain split of 4 July 2015 Post by: turvarya on July 04, 2015, 05:35:10 PM Did blockchain.info updated their stuff? If not then please PM me when they do i need to send a transaction, but i`m scared to do it at the moment. Also do bitcoin in safe storage compromized? I mean do i have to create a new address, are private keys compromized because of this? Its safe to send. If anything its the receiver that needs to wait for 30+ confirmations to ensure that he will retain the bitcoin. Only the guy who controls the private keys of the address can double spend right? Also excuse me for my noobness, but i`m not a tech person. How is it safe to send when blockchain.info hasnt updated their client, what if they send that bitcoin to the wrong blockchain, those coins are lost then arent they? ;D Title: Re: Blockchain split of 4 July 2015 Post by: Syke on July 04, 2015, 05:59:25 PM Won't that be tons of years into the future ? I think it'll just take another 2-3 halvings before miners won't be able to ignore the value of including transactions. Unfortunately, the days of the hobbyist miner are over. Large mining farms value short-term profit over blockchain health. Satoshi's halving schedule was a little too conservative. Title: Re: Blockchain split of 4 July 2015 Post by: CroMiner on July 04, 2015, 06:06:03 PM Hi there,
Can someone tell me is it safe to accept and send BTC now, I am purchasing on localBitcoins now, and need to send them later today as a payment to another person..Is it safe to buy now and send to another person, what is this notice I have in my client "node software out of date"..Is it safe to trade now ? Title: Re: Blockchain split of 4 July 2015 Post by: wpalczynski on July 04, 2015, 06:08:45 PM Its safe as long as you wait for 30 confirmations on the BTC you are buying just in case. When buying, don't give the guy the money until 30 confirmations.
Title: Re: Blockchain split of 4 July 2015 Post by: foxbitcoin on July 04, 2015, 06:09:41 PM Can you explain what happened to transactions that were recorded in the unintentional hard fork, which failed?
Title: Re: Blockchain split of 4 July 2015 Post by: redsn0w on July 04, 2015, 06:10:24 PM Won't that be tons of years into the future ? I think it'll just take another 2-3 halvings before miners won't be able to ignore the value of including transactions. Unfortunately, the days of the hobbyist miner are over. Large mining farms value short-term profit over blockchain health. Satoshi's halving schedule was a little too conservative. 2-3 halvings? I think that as early as next halving 50 BTC >> 25 BTC the 'miners' will change their actual tactic and start to accept everything without any insane rules http://www.hwupgrade.it/forum/images_hwu/smilies/asd.gif. Title: Re: Blockchain split of 4 July 2015 Post by: wpalczynski on July 04, 2015, 06:11:26 PM Can you explain what happened to transactions that were recorded in the unintentional hard fork, which failed? Invalid, went back to original address. Title: Re: Blockchain split of 4 July 2015 Post by: CroMiner on July 04, 2015, 06:13:41 PM Its safe as long as you wait for 30 confirmations on the BTC you are buying just in case. When buying, don't give the guy the money until 30 confirmations. Thanks for the reply, I am buying on local bitcoins, so I need to send money first ( to escrow ) they keep it there for like 70min's and I get the coins, hope everthing will go well.. Title: Re: Blockchain split of 4 July 2015 Post by: jl2012 on July 04, 2015, 06:33:43 PM Can you explain what happened to transactions that were recorded in the unintentional hard fork, which failed? Invalid, went back to original address. Only if they are not in the correct fork Title: Re: Blockchain split of 4 July 2015 Post by: trafficolaa on July 04, 2015, 06:42:09 PM Is online web wallet are safe for transaction as i am using coinbase web wallet so i have to wait for that 30 confirmations, how can we know that incoming transaction is from the right fork and cant be double spend?
Title: Re: WARNING: blockchain split Post by: Soros Shorts on July 04, 2015, 06:44:57 PM A very serious event for sure - but seems to have been mostly fixed already. What kind of resource are you talkin about? The only thing you need really is disc space (for now blockchain info is about 42GB big) every stationary PC or laptop is capable of storing more.It shows, that relying on SPV wallets is not a good idea at all. Only full nodes offer full security. That's why excessive increases in blocksize are dangerous: The number of full nodes will decline further, because the average user doesn't have the resources to run them. In turn, the system as a whole will become less secure and more vulnerable to events like this. ya.ya.yo! It is not resources we lack, it is that people are lazy is the problem. I have run my own pool (p2pool) on crap hardware which was a quad-core i5 with 8GB RAM. When my node received a new block, it took 5 seconds for bitcoind on my quad-core i5 to validate the < 1MB block. That is 5 full seconds when my miners could not do any useful work work. So you see it is not just the disk space that is used up when block go bigger - pools and mining nodes would have to invest in faster processors as well or they will lose the edge. Title: Re: Blockchain split of 4 July 2015 Post by: Syke on July 04, 2015, 06:50:07 PM 2-3 halvings? I think that as early as next halving 50 BTC >> 25 BTC the 'miners' will change their actual tactic and start to accept everything without any insane rules http://www.hwupgrade.it/forum/images_hwu/smilies/asd.gif. That could be as soon as next year, which would be great. Fees are still under 1% of the block value, but after the next halving they could be over 1%. That might be enough. Title: Re: Blockchain split of 4 July 2015 Post by: notbatman on July 04, 2015, 06:51:24 PM Fail at breaking Bitcoin.
My records indicate the "issue" started on June 16 and lasted until the 23rd when transactions from the 17th and 22nd showed up. blockchain.info's database corruption also starts on the 16th and is corrupt/wrong chain until the 26th. I upgraded p2pool to v14 on the 28th. Everything has been hunky dory since the 23rd with the only issue being a minor decrease in payout rate for a few days due to me not noticing the push for a some hours and, possibly a bit of mining on the wrong chain until the v14 update. This is a very minor hiccup if you've mined in the alt-coin mining space, where things go very wrong sometimes. Where are you guys getting this 4th of July date from? Title: Re: Blockchain split of 4 July 2015 Post by: jl2012 on July 04, 2015, 06:53:52 PM Fail at breaking Bitcoin. My records indicate the "issue" started on June 16 and lasted until the 23rd when transactions from the 17th and 22nd showed up. blockchain.info's database corruption also starts on the 16th and is corrupt/wrong chain until the 26th. I upgraded p2pool to v14 on the 28th. Everything has been hunky dory since the 23rd with the only issue being a minor decrease in payout rate for a few days due to me not noticing the push for a some hours and, possibly a bit of mining on the wrong chain until the v14 update. This is a very minor hiccup if you've mined in the alt-coin mining space, where things go very wrong sometimes. Where are you guys getting this 4th of July date from? https://bitcoin.org/en/alert/2015-07-04-spv-mining Title: Re: Blockchain split of 4 July 2015 Post by: cyberpinoy on July 04, 2015, 06:54:46 PM Where are you guys getting this 4th of July date from? https://bitcoin.org/en/alert/2015-07-04-spv-mining oops someone beat me to it, however to sum it up in a sarcastic way we got the info by completely reading the whole OP including his edits and reading the links he provided. Title: Re: Blockchain split of 4 July 2015 Post by: notbatman on July 04, 2015, 07:11:59 PM Oh, the 4th is the point v3 threshhold hit 95%, it looks to me like the bad blocks started on June 16th as that's when blockchain.info got corrupted. I use p2pool so this SPV business is something I'm oblivious to and it looks like it caused more bad chains.
Title: Re: Blockchain split of 4 July 2015 Post by: luthermarcus on July 04, 2015, 07:33:19 PM I have yet to hear from someone who was negatively affected by this other than the large centralized pools.
This was preplanned and v4 is the next step but there is not set date just set requirements. Title: Re: Blockchain split of 4 July 2015 Post by: oniromancia on July 04, 2015, 07:43:26 PM So it appears like f2pool is not validating blocks according to v3 rule and there we got a fork at 363731 followed by a massive amount of orphans coming from f2p and antpool. Personally i had no trouble with running SPV client. But seems like there is no much concern since both pools are now fixed.
Title: Re: Blockchain split of 4 July 2015 Post by: notbatman on July 04, 2015, 07:52:35 PM You can mine the correct chain with the pools listed here (the chain the exchanges use ::)):
http://p2pool.jir.dk/bitcoin/?allnodes=1 Title: Re: Blockchain split of 4 July 2015 Post by: Exodus3322111 on July 04, 2015, 07:56:38 PM If any wallet does not allow older version blocks, will that be a considered "fix"?
Title: Re: Blockchain split of 4 July 2015 Post by: luthermarcus on July 04, 2015, 07:59:24 PM You can mine the correct chain with the pools listed here (the chain the exchanges use ::)): ok most of those havent upgraded to 14.0 which p2pool should be on. I wouldn't recommend mine on those.http://p2pool.jir.dk/bitcoin/?allnodes=1 Below is a better scanner use only ones that are on version 14.0 http://nodes.p2pool.co/ (http://nodes.p2pool.co/) Title: Re: Blockchain split of 4 July 2015 Post by: ElectricMucus on July 04, 2015, 08:35:17 PM anti-fragile my ass
Title: Re: WARNING: blockchain split Post by: matt4054 on July 04, 2015, 08:37:00 PM OMG WTF guys? I`m getting scared. So if i just send now a transaction, then i lose my bitcoins and it doesnt get to the other end? Also what if i buy now bitcoin with € do i get fake bitcoin if the merchant is on wrong chain? This could be a serious problem. No FUD intended but seriously, i`m starting to panic/ ??? Is it just me or is the impact of this non-event severely exaggerated? Title: Re: WARNING: blockchain split Post by: jonald_fyookball on July 04, 2015, 08:42:44 PM OMG WTF guys? I`m getting scared. So if i just send now a transaction, then i lose my bitcoins and it doesnt get to the other end? Also what if i buy now bitcoin with € do i get fake bitcoin if the merchant is on wrong chain? This could be a serious problem. No FUD intended but seriously, i`m starting to panic/ ??? Is it just me or is the impact of this non-event severely exaggerated? It didn't have much direct impact this time... however, I think there is reason to be concerned. Imagine if 48% of the hashing power was on the 'wrong' fork instead of 35% or whatever it was. You start running into the possibility of a real split network that won't converge on its own. It behooves the community to examine the process by which pools and nodes stay updated. Honestly, a pool watchdog would be a good thing, to make sure all major pools are operating on the same codebase. Or if someone has better ideas, pls share. Title: Re: Blockchain split of 4 July 2015 Post by: Quickseller on July 04, 2015, 08:49:36 PM OMG WTF guys? I`m getting scared. So if i just send now a transaction, then i lose my bitcoins and it doesnt get to the other end? Also what if i buy now bitcoin with € do i get fake bitcoin if the merchant is on wrong chain? This could be a serious problem. No FUD intended but seriously, i`m starting to panic/ ??? Is it just me or is the impact of this non-event severely exaggerated? It didn't have much direct impact this time... however, I think there is reason to be concerned. Imagine if 48% of the hashing power was on the 'wrong' fork instead of 35% or whatever it was. You start running into the possibility of a real split network that won't converge on its own. It behooves the community to examine the process by which pools and nodes stay updated. Honestly, a pool watchdog would be a good thing, to make sure all major pools are operating on the same codebase. Or if someone has better ideas, pls share. This is why people shouldn't have relied on any transaction as being confirmed except those that were showing as confirmed by something that got its info from Bitcoin core. Title: Re: Blockchain split of 4 July 2015 Post by: Brangdon on July 04, 2015, 08:51:29 PM Can you explain what happened to transactions that were recorded in the unintentional hard fork, which failed? Invalid, went back to original address. Title: Re: Blockchain split of 4 July 2015 Post by: Bitcoin_BOy$ on July 04, 2015, 09:09:11 PM Hello when should this be resolved and even can it e resolved ?? I hope no ones loose his trust in Bitcoin and leave it just like
that ! Bitcoin Boy. Title: Re: Blockchain split of 4 July 2015 Post by: Quickseller on July 04, 2015, 10:15:19 PM it would never be valid. I know where you're coming from but the bold is untrue. In theory and practice the longest blockchain becomes dominant. This is why people shouldn't have relied on any transaction as being confirmed except those that were showing as confirmed by something that got its info from Bitcoin core. Since most of the world's nodes and miners use the newest Bitcoin Core there was no problem this time, but if China decided to fire up a bunch of miners using the old protocol then Bitcoin Core users would've been the ones on the wrong chain. This is one of the inherent dangers of forks and why they need to be used as little as possible. Pretty remarkable our community was almost entirely unaware of this fork, I guess considering the XT backlash the devs didn't want to make it well known publicly until it was already done. I could (somewhat) easily create a blockchain that is 400,000 blocks long (roughy 37,000 blocks longer then the current blockchain) however in order for me to do this I would need to adjust the timestamps of my found blocks so that the current difficulty would be significantly lower then it is today. This would result in a longer blockchain, but one with less total work then the current blockchain. The chain with the greatest total work is the valid Bitcoin blockchain - this is usually going to also be the longest one, however in my example it would not be. If miners are mining invalid blocks, then they would be mining on an alt coin's blockchain, and it would not be Bitcoin's blockchain....if this altcoin would have any value would be a separate question. Title: Re: Blockchain split of 4 July 2015 Post by: jonald_fyookball on July 04, 2015, 10:20:26 PM it would never be valid. I know where you're coming from but the bold is untrue. In theory and practice the longest blockchain becomes dominant. This is why people shouldn't have relied on any transaction as being confirmed except those that were showing as confirmed by something that got its info from Bitcoin core. Since most of the world's nodes and miners use the newest Bitcoin Core there was no problem this time, but if China decided to fire up a bunch of miners using the old protocol then Bitcoin Core users would've been the ones on the wrong chain. This is one of the inherent dangers of forks and why they need to be used as little as possible. Pretty remarkable our community was almost entirely unaware of this fork, I guess considering the XT backlash the devs didn't want to make it well known publicly until it was already done. I could (somewhat) easily create a blockchain that is 400,000 blocks long (roughy 37,000 blocks longer then the current blockchain) however in order for me to do this I would need to adjust the timestamps of my found blocks so that the current difficulty would be significantly lower then it is today. This would result in a longer blockchain, but one with less total work then the current blockchain. The chain with the greatest total work is the valid Bitcoin blockchain - this is usually going to also be the longest one, however in my example it would not be. If miners are mining invalid blocks, then they would be mining on an alt coin's blockchain, and it would not be Bitcoin's blockchain....if this altcoin would have any value would be a separate question. I think you are right from the point of the view that assuming the miners EVENTUALLY all switch to the 'correct' version, then THAT will become the longest chain. However, I think turtlehurricane could be correct in the situation where a long chain is built that ignores, say a certain BIP, and then the community decides to throw that out for now and just keep mining on the main chain that has been built. Either way, its going to boil down to the consensus of the community and which version they ultimately choose. However, it will be damaging to Bitcoin if at any point there is a long reorg. Title: Re: Blockchain split of 4 July 2015 Post by: Xialla on July 04, 2015, 10:21:47 PM I just checked the blockchain (because again waiting dozens of minutes for confirmation) and this is related, right?
https://i.imgur.com/FwCNfE9.png Title: Re: Blockchain split of 4 July 2015 Post by: ShamrockHannah on July 04, 2015, 11:55:06 PM My wallet is with blockchain.Info. if I am expecting an incoming transaction does this still apply?
Are you talking about certain types of transactions from unknown sources? Title: Re: Blockchain split of 4 July 2015 Post by: JorgeStolfi on July 05, 2015, 12:57:48 AM As far as I understand, the incident had some consequences:
* several miners lost the rewards that they mined (at least 6 blocks, maybe more). * there was a signficant risk of double-spends, since many ciients were watching the bad chain. * at least one transaction (the one that triggered the fork) was undone after >6 confirms. * a warning was broadcast telling everybody to wait for 30 confirmations (5 hours). The incident was not as bad as it could have been because Greg Maxwell and other ore devs were carefully watching the blockchain as the BIP66 triggered the switch from version v2 to version v3 of the protocol, and they immediately spotted the fork. They soon contacted the mining pools that were mining on the wrong chain. The fork was started by miner BTCNuggets, that was still running v2 and issued a block N with a transaction that was invalid under version v3. Miner F2Pool, that was already running v3, saw that block and successfully mined another block N+1 on top of it, not realizing that N was invalid. Other v3 miners like AntPool added N+2, N+3, etc. on top of F2Pool's block N+1. Meanwhile some v3 miners did not see the block N issued by BTCNuggets, or noticed that it was invalid under v3 rules and rejected it; so they created their own block N and kept mining that branch. Until the miners were alerted, the bad branch was longer, so it was accepted by all v2 clients and maybe by v3 clients that did not check all blocks. Blame is being thrown at the miners, especially F2Pool for mining block N+1 on top of a block N that was produced by a v2 miner, without checking the validity of that block. The blame may be partly deserved if F2Pool got the block directly from BRCNuggets or from any intermediate relay node still running v2. However, methinks that the blame should fall on the developers. After the BIP66 change went into effect, every v3 player (client, node, or miner) should have dropped all links to other v2 players. Letting v2 and v3 players communicate was begging for this accident to happen. If F2pool got that block through an intermediate v3 node, the blame should fall on that node. Miners should not be required to validate the blocks that they receive. It is their right to decide whether to validate them, or to trust that the sender did so. Note that the miner that started mining block N+3 on top of N+2 would have had to check also blocks N+1 and N to discover that N+2 was invalid. Was the incident serious? Suppose that a trash basket caught fire in a gunpowder factory, but it was quickly put out. was that incident serious? Title: Re: Blockchain split of 4 July 2015 Post by: Searing on July 05, 2015, 01:01:13 AM this may have already been posted these links (op feel free to remove this post if you wish) https://bitcoin.org/en/alert/2015-07-04-spv-mining (https://bitcoin.org/en/alert/2015-07-04-spv-mining) https://en.bitcoin.it/wiki/Comparison_of_mining_pools#SPV_Mining_.2F_Old_Bitcoin_Core (https://en.bitcoin.it/wiki/Comparison_of_mining_pools#SPV_Mining_.2F_Old_Bitcoin_Core) hope it helps ...again if a repeat of previous info feel free to move/delete or whatever Title: Re: Blockchain split of 4 July 2015 Post by: mark coins on July 05, 2015, 01:09:16 AM Is this going to be a major problem ? are blockchain.info wallets safe in the moment? thanks a lot
Title: Re: Blockchain split of 4 July 2015 Post by: Jeremycoin on July 05, 2015, 01:11:29 AM Is this going to be a major problem ? are blockchain.info wallets safe in the moment? thanks a lot I think... this is just for Bitcoin core, as written on the News above 8)Title: Re: Blockchain split of 4 July 2015 Post by: STT on July 05, 2015, 01:14:03 AM Quote So it is not just F2Pool, but also AntPool. Considering that they have roughly 36% of total network hashrate 36% is too centralised, seems like its a problem even when not apparent that BTC has become too much about bigger is better. Will it converge with traditional banking on the same basis, maybe its meant to be Its a mistake to me, if you want to represent capitalism then the capital value and/or means of production should be within the population ideally Title: Re: Blockchain split of 4 July 2015 Post by: Superhitech on July 05, 2015, 01:14:31 AM Are blockchain.info web wallets running Bitcoin Core 0.9.5 and later? Just want to know if I should wait for 30 confirmations.
Is this going to be a major problem ? are blockchain.info wallets safe in the moment? thanks a lot I think... this is just for Bitcoin core, as written on the News above 8)No, this issue concerns web wallets too. Title: Re: Blockchain split of 4 July 2015 Post by: tss on July 05, 2015, 01:14:38 AM Hi, guys I'v just registered on this forum. I just wondering...... Does anybody have any info about this Social Community http://mmmglobal.org/ Huh I've just joined and i see that they are based on Bitcoin. They operates with this currency. Any advise??? looks interesting..... Their FB page https://www.facebook.com/mmmglobal.org looks like a ponzi made to look like multi level marketing pretending to facilitate person to person money transfer. im skeptical. also your post is off topic here and may be spammy but i will reply if it stops you from losing any money. Title: Re: Blockchain split of 4 July 2015 Post by: Colonel Crouton on July 05, 2015, 01:22:28 AM How do we know if electrum and mycelium servers have been updated?
Title: Re: Blockchain split of 4 July 2015 Post by: Hazir on July 05, 2015, 01:36:18 AM How do we know if electrum and mycelium servers have been updated? I imagine we don't know nothing about their servers status. Unless wallets providers will tell us directly that the crisis is averted. That is the problem with the online wallets or like in this case simplified validation wallets, if you don't have copy of blockchain on your machine, things like that could happen and you can't do anything about it. Power in the hands of wallet provider.Title: Re: Blockchain split of 4 July 2015 Post by: jorgelugra on July 05, 2015, 01:52:07 AM Are blockchain.info web wallets running Bitcoin Core 0.9.5 and later? Just want to know if I should wait for 30 confirmations. but its affect only the transactions incoming from a user with bitcoin core? or between webwallets too? thank uIs this going to be a major problem ? are blockchain.info wallets safe in the moment? thanks a lot I think... this is just for Bitcoin core, as written on the News above 8)No, this issue concerns web wallets too. Title: Re: Blockchain split of 4 July 2015 Post by: Quickseller on July 05, 2015, 01:55:21 AM How do we know if electrum and mycelium servers have been updated? Some SPV servers were relying on 0.10.x so they were unaffected by the issue, and others were not and were effected. My personal experience with electrum on this incident is that I had a transaction that was sent to me that was showing as unconfirmed for a long time, then all of a sudden it had in excess of 6 confirmations. I am not sure what exact conclusions that I can draw from this except that the particular electrum server that I was connected to at the time was not relying on core 0.10.x as of prior to this indecent. I also believe that by default, the electrum server that you connect to is random, so it is hard to make the determination if your server is running a "good" version of core or not. My personal solution is to start a full node, and once the blockchain is downloaded, to run an electrum server that relies on the most recent version of Bitcoin core Title: Re: Blockchain split of 4 July 2015 Post by: pooya87 on July 05, 2015, 02:20:24 AM Title: Re: Blockchain split of 4 July 2015 Post by: Funny on July 05, 2015, 03:14:34 AM Are blockchain.info web wallets running Bitcoin Core 0.9.5 and later? Just want to know if I should wait for 30 confirmations. but its affect only the transactions incoming from a user with bitcoin core? or between webwallets too? thank uIs this going to be a major problem ? are blockchain.info wallets safe in the moment? thanks a lot I think... this is just for Bitcoin core, as written on the News above 8)No, this issue concerns web wallets too. Title: Re: Blockchain split of 4 July 2015 Post by: JerryCurlzzz on July 05, 2015, 03:51:42 AM Any word on whether Blockchain.info wallets are relying on Core, or something else? Silence from their Twitter for the last couple days. I was hoping to see something on their homepage. I have a small hot wallet there.... only use it to hold a couple coins at any time.
Downloading the blockchain as we speak.... (sigh) Title: Re: Blockchain split of 4 July 2015 Post by: stingers on July 05, 2015, 04:33:57 AM Can someone advice me if this split would affect the price of bitcoin anyhow? If yes how?
Title: Re: Blockchain split of 4 July 2015 Post by: Cryddit on July 05, 2015, 06:02:50 AM One way to think of this is that a group of Chinese miners just gave over $50K away to other miners, to reward those other miners for checking the block versions before building new blocks.
Terribly nice of them, really. Though I'm sure they'd prefer to've collected the prize themselves, it's nice of them to "support" those who are doing a better job than they are. So, for a few hours, if you were mining and actually checking blocks for validity, you were getting about double your usual rate of return. "SPV mining" is one of those silly ideas like "virtual memory" or "virtual sex" - the real thing is always better. Title: Re: Blockchain split of 4 July 2015 Post by: ajareselde on July 05, 2015, 06:07:20 AM Can someone advice me if this split would affect the price of bitcoin anyhow? If yes how? As you can see, the price wasn't affected by it at all. Can someone advice me if this split would affect the price of bitcoin anyhow? If yes how? The "split" like you call it, was resolved by the network 6 blocks after it happened - which shows how resilient (or anti-fragile) the Bitcoin network has become. Regarding the price of bitcoin, please go to the speculation section of the forum. On the other hand, it also shows that the system still has errors that can happen. Don't get me wrong,i am glad that the "issue" was resolved, but i find that it shouldn't have happened in the first place. cheers Title: Re: Blockchain split of 4 July 2015 Post by: Quickseller on July 05, 2015, 06:54:01 AM How do we know if electrum and mycelium servers have been updated? Some SPV servers were relying on 0.10.x so they were unaffected by the issue, and others were not and were effected. My personal experience with electrum on this incident is that I had a transaction that was sent to me that was showing as unconfirmed for a long time, then all of a sudden it had in excess of 6 confirmations. I am not sure what exact conclusions that I can draw from this except that the particular electrum server that I was connected to at the time was not relying on core 0.10.x as of prior to this indecent. I also believe that by default, the electrum server that you connect to is random, so it is hard to make the determination if your server is running a "good" version of core or not. My personal solution is to start a full node, and once the blockchain is downloaded, to run an electrum server that relies on the most recent version of Bitcoin core The Electrum clients connect to Electrum Servers at random. However, if you have a favorite you can also default to it. I do. I personally like electrum.dragonzone.net and electrum.drollette.com. Why? They are always present, and they maintain a limit of 10 000 UTXOs (UTXO = Unspent Transactions Outputs)- which implies they are serious about being reliable Electrum-Servers (requires more computing power, memory and bandwidth to maintain a 10 000 limit, compared to a 100 limit). Electrum-Servers are operating on pure voluntarily will - they have no incentives to do so. Higher limits show how committed they are to the SPV Electrum cause. Please support them by sending them a donation (their BTC donation addresses are usually listed in the console tab). You can select your favorite server by clicking on the Green dot (bottom right) of your Electrum window - uncheck the automatic selection, and select your favorite server. Electrum-Servers also have to operate a full Bitcoin-core node - it would be great if they would advertise in their console msg the Bitcoin-core version they are using! If you have a Trezor, SatoshiLabs already indicated that their backend node was already updated to the latest version 0.10.2 if you are using their mytrezor.com (http://mytrezor.com) Chrome interface - see here (https://bitcointalk.org/index.php?topic=122438.msg11790087#msg11790087) Title: Re: Blockchain split of 4 July 2015 Post by: EternalWingsofGod on July 05, 2015, 07:05:27 AM Can someone advice me if this split would affect the price of bitcoin anyhow? If yes how? The "split" like you call it, was resolved by the network 6 blocks after it happened - which shows how resilient (or anti-fragile) the Bitcoin network has become. Regarding the price of bitcoin, please go to the speculation section of the forum. That's good to hear I read July 4 Fork and was a bit concerned that something happened there I'm glad to hear its been sorted out. Title: Re: Blockchain split of 4 July 2015 Post by: Possum577 on July 05, 2015, 07:13:36 AM Is it possible that a successful fork could increase confidence in the Bitcoin infrastructure, thereby causing incentive to buy more?
Title: Re: Blockchain split of 4 July 2015 Post by: Amph on July 05, 2015, 07:18:54 AM My wallet is with blockchain.Info. if I am expecting an incoming transaction does this still apply? Are you talking about certain types of transactions from unknown sources? every transaction was affected, but was regarding old version of core, 0.1 should be safe, blockchain info should be reliable like it was said if you do not trust any source simply wait 30 confs Title: Re: Blockchain split of 4 July 2015 Post by: Borisz on July 05, 2015, 07:48:32 AM Is it possible that a successful fork could increase confidence in the Bitcoin infrastructure, thereby causing incentive to buy more? You mean that despite a glitch, fork, the network continued on the right chain? I don't think this would matter too much. For the media to explain this it would be too complicated and for existing bitcoin users only matters a little. Maybe gives a bit of confidence, but also points out issues. Title: Re: Blockchain split of 4 July 2015 Post by: RealBitcoin on July 05, 2015, 08:46:33 AM Is it possible that a successful fork could increase confidence in the Bitcoin infrastructure, thereby causing incentive to buy more? You mean that despite a glitch, fork, the network continued on the right chain? I don't think this would matter too much. For the media to explain this it would be too complicated and for existing bitcoin users only matters a little. Maybe gives a bit of confidence, but also points out issues. Yep i agree the media always spins things, but this time this is way above the laymen terms, they cant even do a report on this because its so tech-savy that the average tv watcher person will just switch to another channel watching soap operas instead. Title: Re: Blockchain split of 4 July 2015 Post by: turvarya on July 05, 2015, 09:05:34 AM How do we know if electrum and mycelium servers have been updated? Some SPV servers were relying on 0.10.x so they were unaffected by the issue, and others were not and were effected. My personal experience with electrum on this incident is that I had a transaction that was sent to me that was showing as unconfirmed for a long time, then all of a sudden it had in excess of 6 confirmations. I am not sure what exact conclusions that I can draw from this except that the particular electrum server that I was connected to at the time was not relying on core 0.10.x as of prior to this indecent. I also believe that by default, the electrum server that you connect to is random, so it is hard to make the determination if your server is running a "good" version of core or not. My personal solution is to start a full node, and once the blockchain is downloaded, to run an electrum server that relies on the most recent version of Bitcoin core The Electrum clients connect to Electrum Servers at random. However, if you have a favorite you can also default to it. I do. I personally like electrum.dragonzone.net and electrum.drollette.com. Why? They are always present, and they maintain a limit of 10 000 UTXOs (UTXO = Unspent Transactions Outputs)- which implies they are serious about being reliable Electrum-Servers (requires more computing power, memory and bandwidth to maintain a 10 000 limit, compared to a 100 limit). Electrum-Servers are operating on pure voluntarily will - they have no incentives to do so. Higher limits show how committed they are to the SPV Electrum cause. Please support them by sending them a donation (their BTC donation addresses are usually listed in the console tab). You can select your favorite server by clicking on the Green dot (bottom right) of your Electrum window - uncheck the automatic selection, and select your favorite server. Electrum-Servers also have to operate a full Bitcoin-core node - it would be great if they would advertise in their console msg the Bitcoin-core version they are using! If you have a Trezor, SatoshiLabs already indicated that their backend node was already updated to the latest version 0.10.2 if you are using their mytrezor.com (http://mytrezor.com) Chrome interface - see here (https://bitcointalk.org/index.php?topic=122438.msg11790087#msg11790087) Title: Re: Blockchain split of 4 July 2015 Post by: drakoin on July 05, 2015, 10:03:50 AM Is it conceivable to add a service network which announces "block XYZ was invalid"?
A service that miners could subscribe to; or organize themselves, even on one of their machines only? Could make sense if those instances are rare. Then SPV miners start hashing with what they assume (but not check) is a valid block, and when a few seconds later an "invalid block" alert is broadcast, they simply restart. Possible? Wrong approach? Then sorry - I do not understand enough of this yet. But the other thing ... miners deliberately mining empty blocks, that sounds ruthless, no? Title: Re: Blockchain split of 4 July 2015 Post by: stingers on July 05, 2015, 10:27:59 AM Can someone advice me if this split would affect the price of bitcoin anyhow? If yes how? As you can see, the price wasn't affected by it at all. Can someone advice me if this split would affect the price of bitcoin anyhow? If yes how? The "split" like you call it, was resolved by the network 6 blocks after it happened - which shows how resilient (or anti-fragile) the Bitcoin network has become. Regarding the price of bitcoin, please go to the speculation section of the forum. On the other hand, it also shows that the system still has errors that can happen. Don't get me wrong,i am glad that the "issue" was resolved, but i find that it shouldn't have happened in the first place. cheers Also, in this kinda tech, issues will surely arise, you cannot expect them not to happen. Title: Re: Blockchain split of 4 July 2015 Post by: turvarya on July 05, 2015, 10:44:21 AM Can someone advice me if this split would affect the price of bitcoin anyhow? If yes how? The "split" like you call it, was resolved by the network 6 blocks after it happened - which shows how resilient (or anti-fragile) the Bitcoin network has become. Regarding the price of bitcoin, please go to the speculation section of the forum. It requires manual intervention, so anti fragile my ass! Also where is the 6 blocks figure from? Your ass? It's like having a website and complain to be hacked, just because you didn't install security patches. Do you also want the dev team to wipe your ass? Title: Re: Blockchain split of 4 July 2015 Post by: redsn0w on July 05, 2015, 10:47:22 AM Can someone advice me if this split would affect the price of bitcoin anyhow? If yes how? As you can see, the price wasn't affected by it at all. Can someone advice me if this split would affect the price of bitcoin anyhow? If yes how? The "split" like you call it, was resolved by the network 6 blocks after it happened - which shows how resilient (or anti-fragile) the Bitcoin network has become. Regarding the price of bitcoin, please go to the speculation section of the forum. On the other hand, it also shows that the system still has errors that can happen. Don't get me wrong,i am glad that the "issue" was resolved, but i find that it shouldn't have happened in the first place. cheers Also, in this kinda tech, issues will surely arise, you cannot expect them not to happen. Why the price should be affected? The 'era' of bug or forked chain(s) that can affect the price doesn't exist anymore... it is only a pure speculation ;). Title: Re: Blockchain split of 4 July 2015 Post by: notbatman on July 05, 2015, 11:14:12 AM Can somebody from blockchain.info explain what happened between June 16th and the 23rd, there's a .06 difference between my mycelium hot wallet and what blockchain.info says my address has. The payout amounts and date/times are also different.
I'm running core 0.10 and mycelium's servers are running 0.10 On the 28th I saw the notice that 51% of users were running v14 of p2pool and switched. v14 has had the top link to blockchain.info removed so I'm not the only one seeing this. did somebody mine a v3 block on the 16th before the 4th of July? My payout was 200% of normal as my miner was being especially lucky. After I upgraded to v14 it had dropped to 50%. (It's back to normal now) The conspiracy part of my brain thinks the 1% group forced my luck down but the only option to do that was by screwing everybody else in the process. Use the test-net next time, black hat FUDsters. Title: Re: Blockchain split of 4 July 2015 Post by: freedoge.co on July 05, 2015, 11:28:33 AM hey, i'd like to help bitcoin and setup electrum full node, i have 4GB-RAM 4GBvRAM VPS is it capable to run full node with 10k history limit?
Any guide or help welcome for ubuntu 12.04 Title: Re: Blockchain split of 4 July 2015 Post by: turvarya on July 05, 2015, 11:52:45 AM hey, i'd like to help bitcoin and setup electrum full node, i have 4GB-RAM 4GBvRAM VPS is it capable to run full node with 10k history limit? That should helpAny guide or help welcome for ubuntu 12.04 https://github.com/spesmilo/electrum-server/blob/master/HOWTO.md How much disk space to you have? Title: Re: Blockchain split of 4 July 2015 Post by: ElectricMucus on July 05, 2015, 11:52:59 AM Can someone advice me if this split would affect the price of bitcoin anyhow? If yes how? The "split" like you call it, was resolved by the network 6 blocks after it happened - which shows how resilient (or anti-fragile) the Bitcoin network has become. Regarding the price of bitcoin, please go to the speculation section of the forum. It requires manual intervention, so anti fragile my ass! Also where is the 6 blocks figure from? Your ass? It's like having a website and complain to be hacked, just because you didn't install security patches. Do you also want the dev team to wipe your ass? No supporter of a website, web-server software or any other type of Internet appliance makes stupid claims like being "anti-fragile", "backed my math" or "secured by the laws of the universe" though. Title: Re: Blockchain split of 4 July 2015 Post by: DooMAD on July 05, 2015, 12:12:56 PM Can someone advice me if this split would affect the price of bitcoin anyhow? If yes how? The "split" like you call it, was resolved by the network 6 blocks after it happened - which shows how resilient (or anti-fragile) the Bitcoin network has become. Regarding the price of bitcoin, please go to the speculation section of the forum. It requires manual intervention, so anti fragile my ass! Also where is the 6 blocks figure from? Your ass? It's like having a website and complain to be hacked, just because you didn't install security patches. Do you also want the dev team to wipe your ass? No supporter of a website, web-server software or any other type of Internet appliance makes stupid claims like being "anti-fragile", "backed my math" or "secured by the laws of the universe" though. Maybe some of those claims are stretched a little far, but in fairness, they're only said in response to the myth that Bitcoin isn't backed by anything. In truth, it's backed by human beings and human beings have a natural propensity to be able to screw up anything at any time. There's really no such thing as "anti-fragile" where people are involved. Some miners screwed up here, paid the price for it and hopefully it's a lesson learned, but we'll have to wait and see. Title: Re: Blockchain split of 4 July 2015 Post by: RealBitcoin on July 05, 2015, 12:20:30 PM How do we know if electrum and mycelium servers have been updated? Some SPV servers were relying on 0.10.x so they were unaffected by the issue, and others were not and were effected. My personal experience with electrum on this incident is that I had a transaction that was sent to me that was showing as unconfirmed for a long time, then all of a sudden it had in excess of 6 confirmations. I am not sure what exact conclusions that I can draw from this except that the particular electrum server that I was connected to at the time was not relying on core 0.10.x as of prior to this indecent. I also believe that by default, the electrum server that you connect to is random, so it is hard to make the determination if your server is running a "good" version of core or not. My personal solution is to start a full node, and once the blockchain is downloaded, to run an electrum server that relies on the most recent version of Bitcoin core The Electrum clients connect to Electrum Servers at random. However, if you have a favorite you can also default to it. I do. I personally like electrum.dragonzone.net and electrum.drollette.com. Why? They are always present, and they maintain a limit of 10 000 UTXOs (UTXO = Unspent Transactions Outputs)- which implies they are serious about being reliable Electrum-Servers (requires more computing power, memory and bandwidth to maintain a 10 000 limit, compared to a 100 limit). Electrum-Servers are operating on pure voluntarily will - they have no incentives to do so. Higher limits show how committed they are to the SPV Electrum cause. Please support them by sending them a donation (their BTC donation addresses are usually listed in the console tab). You can select your favorite server by clicking on the Green dot (bottom right) of your Electrum window - uncheck the automatic selection, and select your favorite server. Electrum-Servers also have to operate a full Bitcoin-core node - it would be great if they would advertise in their console msg the Bitcoin-core version they are using! If you have a Trezor, SatoshiLabs already indicated that their backend node was already updated to the latest version 0.10.2 if you are using their mytrezor.com (http://mytrezor.com) Chrome interface - see here (https://bitcointalk.org/index.php?topic=122438.msg11790087#msg11790087) Most likely not, my full node with armory and the core is over 100 GB, so its getting intolerably big. We need reputable, quick acting (no bureocracy) full node people who store the blockchain. So if a problem like this happens, they can respond in less than 1 day, and fix it. If blockhain.info already fixed their stuff, which is great, they are very quick and anti-bureocratic, i love that :) Title: Re: Blockchain split of 4 July 2015 Post by: QuestionAuthority on July 05, 2015, 12:23:58 PM Can someone advice me if this split would affect the price of bitcoin anyhow? If yes how? The "split" like you call it, was resolved by the network 6 blocks after it happened - which shows how resilient (or anti-fragile) the Bitcoin network has become. Regarding the price of bitcoin, please go to the speculation section of the forum. It requires manual intervention, so anti fragile my ass! Also where is the 6 blocks figure from? Your ass? It's like having a website and complain to be hacked, just because you didn't install security patches. Do you also want the dev team to wipe your ass? ElectricMucus is right, it's not anti-fragile at all unless you think the Bitcoin fairies are magically keeping everything patched and updated for your downloading enjoyment. Someone has to monitor the system like a 24hr a day security guard. Nothing is automated. Every version of Bitcoin core after 0.9.5 can detect invalid blocks. Web wallets, SPV wallets and core 0.9.4 and earlier are still vulnerable to double spending. They need to wait 30 confirmations to be safe. That's the complete opposite of anti-fragile. That's more like fucked-in-a-hand-basket. I can't go to a store that uses SPV devices and buy something because I'll need to sleep there overnight to wait for my money to clear. What would you do if you were in a restaurant with family and pulled out your debit card to pay and the cashier told you to wait for a few hours because your bank is having a problem. I'd shit bricks. I'd close every account I had at that bank immediately and talk shit about them to anyone that would listen for the rest of my life. Title: Re: Blockchain split of 4 July 2015 Post by: freedoge.co on July 05, 2015, 12:29:01 PM hey, i'd like to help bitcoin and setup electrum full node, i have 4GB-RAM 4GBvRAM VPS is it capable to run full node with 10k history limit? That should helpAny guide or help welcome for ubuntu 12.04 https://github.com/spesmilo/electrum-server/blob/master/HOWTO.md How much disk space to you have? i have currently 50 GB free out of 100, is it enough? edit. i can free up or request more space anytime Title: Re: Blockchain split of 4 July 2015 Post by: notbatman on July 05, 2015, 12:35:58 PM How do we know if electrum and mycelium servers have been updated? Some SPV servers were relying on 0.10.x so they were unaffected by the issue, and others were not and were effected. My personal experience with electrum on this incident is that I had a transaction that was sent to me that was showing as unconfirmed for a long time, then all of a sudden it had in excess of 6 confirmations. I am not sure what exact conclusions that I can draw from this except that the particular electrum server that I was connected to at the time was not relying on core 0.10.x as of prior to this indecent. I also believe that by default, the electrum server that you connect to is random, so it is hard to make the determination if your server is running a "good" version of core or not. My personal solution is to start a full node, and once the blockchain is downloaded, to run an electrum server that relies on the most recent version of Bitcoin core The Electrum clients connect to Electrum Servers at random. However, if you have a favorite you can also default to it. I do. I personally like electrum.dragonzone.net and electrum.drollette.com. Why? They are always present, and they maintain a limit of 10 000 UTXOs (UTXO = Unspent Transactions Outputs)- which implies they are serious about being reliable Electrum-Servers (requires more computing power, memory and bandwidth to maintain a 10 000 limit, compared to a 100 limit). Electrum-Servers are operating on pure voluntarily will - they have no incentives to do so. Higher limits show how committed they are to the SPV Electrum cause. Please support them by sending them a donation (their BTC donation addresses are usually listed in the console tab). You can select your favorite server by clicking on the Green dot (bottom right) of your Electrum window - uncheck the automatic selection, and select your favorite server. Electrum-Servers also have to operate a full Bitcoin-core node - it would be great if they would advertise in their console msg the Bitcoin-core version they are using! If you have a Trezor, SatoshiLabs already indicated that their backend node was already updated to the latest version 0.10.2 if you are using their mytrezor.com (http://mytrezor.com) Chrome interface - see here (https://bitcointalk.org/index.php?topic=122438.msg11790087#msg11790087) Most likely not, my full node with armory and the core is over 100 GB, so its getting intolerably big. We need reputable, quick acting (no bureocracy) full node people who store the blockchain. So if a problem like this happens, they can respond in less than 1 day, and fix it. If blockhain.info already fixed their stuff, which is great, they are very quick and anti-bureocratic, i love that :) I'm still seeing a discrepancy of .06 btc, so I'm guessing blockchain.info is still working on fixing the database between June 16-23. Title: Re: Blockchain split of 4 July 2015 Post by: jl2012 on July 05, 2015, 12:39:53 PM How do we know if electrum and mycelium servers have been updated? Some SPV servers were relying on 0.10.x so they were unaffected by the issue, and others were not and were effected. My personal experience with electrum on this incident is that I had a transaction that was sent to me that was showing as unconfirmed for a long time, then all of a sudden it had in excess of 6 confirmations. I am not sure what exact conclusions that I can draw from this except that the particular electrum server that I was connected to at the time was not relying on core 0.10.x as of prior to this indecent. I also believe that by default, the electrum server that you connect to is random, so it is hard to make the determination if your server is running a "good" version of core or not. My personal solution is to start a full node, and once the blockchain is downloaded, to run an electrum server that relies on the most recent version of Bitcoin core The Electrum clients connect to Electrum Servers at random. However, if you have a favorite you can also default to it. I do. I personally like electrum.dragonzone.net and electrum.drollette.com. Why? They are always present, and they maintain a limit of 10 000 UTXOs (UTXO = Unspent Transactions Outputs)- which implies they are serious about being reliable Electrum-Servers (requires more computing power, memory and bandwidth to maintain a 10 000 limit, compared to a 100 limit). Electrum-Servers are operating on pure voluntarily will - they have no incentives to do so. Higher limits show how committed they are to the SPV Electrum cause. Please support them by sending them a donation (their BTC donation addresses are usually listed in the console tab). You can select your favorite server by clicking on the Green dot (bottom right) of your Electrum window - uncheck the automatic selection, and select your favorite server. Electrum-Servers also have to operate a full Bitcoin-core node - it would be great if they would advertise in their console msg the Bitcoin-core version they are using! If you have a Trezor, SatoshiLabs already indicated that their backend node was already updated to the latest version 0.10.2 if you are using their mytrezor.com (http://mytrezor.com) Chrome interface - see here (https://bitcointalk.org/index.php?topic=122438.msg11790087#msg11790087) Most likely not, my full node with armory and the core is over 100 GB, so its getting intolerably big. We need reputable, quick acting (no bureocracy) full node people who store the blockchain. So if a problem like this happens, they can respond in less than 1 day, and fix it. If blockhain.info already fixed their stuff, which is great, they are very quick and anti-bureocratic, i love that :) I'm still seeing discrepancy of .06 btc, so I'm guessing blockchain.info is still working on fixing the database between June 16-23. This thread is about the bitcoin blockchain, not technical support for blockchain.info wallet. By the way, it is not uncommon for bc.i to provide inaccurate info Title: Re: Blockchain split of 4 July 2015 Post by: bitnanigans on July 05, 2015, 12:49:57 PM So what exactly was responsible for this error?
Title: Re: Blockchain split of 4 July 2015 Post by: redsn0w on July 05, 2015, 12:55:06 PM So what exactly was responsible for this error? The miners, not all the miners but some of them.... Title: Re: Blockchain split of 4 July 2015 Post by: notbatman on July 05, 2015, 01:03:43 PM How do we know if electrum and mycelium servers have been updated? Some SPV servers were relying on 0.10.x so they were unaffected by the issue, and others were not and were effected. My personal experience with electrum on this incident is that I had a transaction that was sent to me that was showing as unconfirmed for a long time, then all of a sudden it had in excess of 6 confirmations. I am not sure what exact conclusions that I can draw from this except that the particular electrum server that I was connected to at the time was not relying on core 0.10.x as of prior to this indecent. I also believe that by default, the electrum server that you connect to is random, so it is hard to make the determination if your server is running a "good" version of core or not. My personal solution is to start a full node, and once the blockchain is downloaded, to run an electrum server that relies on the most recent version of Bitcoin core The Electrum clients connect to Electrum Servers at random. However, if you have a favorite you can also default to it. I do. I personally like electrum.dragonzone.net and electrum.drollette.com. Why? They are always present, and they maintain a limit of 10 000 UTXOs (UTXO = Unspent Transactions Outputs)- which implies they are serious about being reliable Electrum-Servers (requires more computing power, memory and bandwidth to maintain a 10 000 limit, compared to a 100 limit). Electrum-Servers are operating on pure voluntarily will - they have no incentives to do so. Higher limits show how committed they are to the SPV Electrum cause. Please support them by sending them a donation (their BTC donation addresses are usually listed in the console tab). You can select your favorite server by clicking on the Green dot (bottom right) of your Electrum window - uncheck the automatic selection, and select your favorite server. Electrum-Servers also have to operate a full Bitcoin-core node - it would be great if they would advertise in their console msg the Bitcoin-core version they are using! If you have a Trezor, SatoshiLabs already indicated that their backend node was already updated to the latest version 0.10.2 if you are using their mytrezor.com (http://mytrezor.com) Chrome interface - see here (https://bitcointalk.org/index.php?topic=122438.msg11790087#msg11790087) Most likely not, my full node with armory and the core is over 100 GB, so its getting intolerably big. We need reputable, quick acting (no bureocracy) full node people who store the blockchain. So if a problem like this happens, they can respond in less than 1 day, and fix it. If blockhain.info already fixed their stuff, which is great, they are very quick and anti-bureocratic, i love that :) I'm still seeing discrepancy of .06 btc, so I'm guessing blockchain.info is still working on fixing the database between June 16-23. This thread is about the bitcoin blockchain, not technical support for blockchain.info wallet. By the way, it is not uncommon for bc.i to provide inaccurate info I use blockchain.info as a block explorer as p2pool links directly to it.... their problem is most definitely related to the v2/v3 upgrade being discussed here. Title: Re: Blockchain split of 4 July 2015 Post by: shorena on July 05, 2015, 01:10:54 PM So what exactly was responsible for this error? The miners, not all the miners but some of them.... To elaborate this a bit further: My understanding of the situation is that some miners use a mining technique called SPV mining that relies on the assumption that the rest of the network produces valid blocks to mine a tiny bit faster. Those miners using SPV mining essentially have a few seconds advantage over those that completly verify the block first. What happend is that a big pool using said technique received an "invalid" block, a block version 2. These have recently been declared invalid as over 950 out of 1000 blocks mined are version 3. The pool tried to build the chain on top of the now invalid version 2 block, causing the fork. Because of the way bitcoin works we had two chains competing over which is the correct one. Those running nodes 0.10.x or 0.9.5 would not accept the invalid blocks and those following it, while other nodes would still accept them as valid and thus accept a different chain as the longest and currently valid chain. This resulted in wasted hash power for the miners and confusion as different services and wallets that rely on bitcoin core in the background showed different information / statuses depending on the version of bitcoin core running in said background. Disclaimer: this attempt of a tl;dr version might be flawed, please correct me if you find any. Title: Re: Blockchain split of 4 July 2015 Post by: Mac Gates15 on July 05, 2015, 01:17:25 PM How long until we only need to wait for 1-6 Confirmations instead of 30 ? (i'm using a Trezor) until problem with major pools like p2pool and antpool solved and they start mining on correct blockchainand another duplicate blockchain issue fixed, if you are using latest versions then it shouldn't have any problem, as they have inbuilt header verification in code Title: Re: Blockchain split of 4 July 2015 Post by: Quickseller on July 05, 2015, 01:21:47 PM How do we know if electrum and mycelium servers have been updated? Some SPV servers were relying on 0.10.x so they were unaffected by the issue, and others were not and were effected. My personal experience with electrum on this incident is that I had a transaction that was sent to me that was showing as unconfirmed for a long time, then all of a sudden it had in excess of 6 confirmations. I am not sure what exact conclusions that I can draw from this except that the particular electrum server that I was connected to at the time was not relying on core 0.10.x as of prior to this indecent. I also believe that by default, the electrum server that you connect to is random, so it is hard to make the determination if your server is running a "good" version of core or not. My personal solution is to start a full node, and once the blockchain is downloaded, to run an electrum server that relies on the most recent version of Bitcoin core The Electrum clients connect to Electrum Servers at random. However, if you have a favorite you can also default to it. I do. I personally like electrum.dragonzone.net and electrum.drollette.com. Why? They are always present, and they maintain a limit of 10 000 UTXOs (UTXO = Unspent Transactions Outputs)- which implies they are serious about being reliable Electrum-Servers (requires more computing power, memory and bandwidth to maintain a 10 000 limit, compared to a 100 limit). Electrum-Servers are operating on pure voluntarily will - they have no incentives to do so. Higher limits show how committed they are to the SPV Electrum cause. Please support them by sending them a donation (their BTC donation addresses are usually listed in the console tab). You can select your favorite server by clicking on the Green dot (bottom right) of your Electrum window - uncheck the automatic selection, and select your favorite server. Electrum-Servers also have to operate a full Bitcoin-core node - it would be great if they would advertise in their console msg the Bitcoin-core version they are using! If you have a Trezor, SatoshiLabs already indicated that their backend node was already updated to the latest version 0.10.2 if you are using their mytrezor.com (http://mytrezor.com) Chrome interface - see here (https://bitcointalk.org/index.php?topic=122438.msg11790087#msg11790087) Bitcoin users want to be able to spend (and receive) bitcoin with ease, and without large amounts of effort on their part, and rightfully so. It probably took me a good two hours to shop around for a cheap VPS, find one I thought was good (including cost efficient), figure out how to use ubuntu and get core installed. Plus I am spending my own money for my node, and seriously doubt that I will be able to monetize it, or be able to receive enough "donations" to cover it's costs. Title: Re: Blockchain split of 4 July 2015 Post by: monbux on July 05, 2015, 01:33:18 PM I'm not very technologically advanced myself when it comes to the blockchain, so I am wondering, how does this affect wallets like the trezor and its webwallet?
Title: Re: Blockchain split of 4 July 2015 Post by: redsn0w on July 05, 2015, 01:43:53 PM So what exactly was responsible for this error? The miners, not all the miners but some of them.... To elaborate this a bit further: My understanding of the situation is that some miners use a mining technique called SPV mining that relies on the assumption that the rest of the network produces valid blocks to mine a tiny bit faster. Those miners using SPV mining essentially have a few seconds advantage over those that completly verify the block first. What happend is that a big pool using said technique received an "invalid" block, a block version 2. These have recently been declared invalid as over 950 out of 1000 blocks mined are version 3. The pool tried to build the chain on top of the now invalid version 2 block, causing the fork. Because of the way bitcoin works we had two chains competing over which is the correct one. Those running nodes 0.10.x or 0.9.5 would not accept the invalid blocks and those following it, while other nodes would still accept them as valid and thus accept a different chain as the longest and currently valid chain. This resulted in wasted hash power for the miners and confusion as different services and wallets that rely on bitcoin core in the background showed different information / statuses depending on the version of bitcoin core running in said background. Disclaimer: this attempt of a tl;dr version might be flawed, please correct me if you find any. maybe... I didn't follow the whole situation. I'm not very technologically advanced myself when it comes to the blockchain, so I am wondering, how does this affect wallets like the trezor and its webwallet? it affected the bitcoin blockchain, the various wallets 'validate' the blockchain.... Title: Re: Blockchain split of 4 July 2015 Post by: RealBitcoin on July 05, 2015, 03:09:34 PM Isnt this causing a systematic problem. I mean if the pool this error originated from now gains less trust, and the miners leave the pool due to lack of trust.
Now the pool can go bankrupt, and the other pools consolidate. Isnt this increase the risk of 51% attack? I think this is the main concern mostly. As if the mining pools get sabogaged by these things, it can become very easy for 1 pool to gain monopoly and then face 51% attack? Title: Re: Blockchain split of 4 July 2015 Post by: tspacepilot on July 05, 2015, 03:50:37 PM 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?
Title: Re: Blockchain split of 4 July 2015 Post by: achow101 on July 05, 2015, 04:14:34 PM 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.Title: Re: Blockchain split of 4 July 2015 Post by: TooDumbForBitcoin on July 05, 2015, 05:18:21 PM anti-fragile my ass Do it yourself. Preparation H usually works. Title: Re: Blockchain split of 4 July 2015 Post by: TooDumbForBitcoin on July 05, 2015, 05:22:31 PM Can someone advice me if this split would affect the price of bitcoin anyhow? If yes how? The "split" like you call it, was resolved by the network 6 blocks after it happened - which shows how resilient (or anti-fragile) the Bitcoin network has become. Regarding the price of bitcoin, please go to the speculation section of the forum. It requires manual intervention, so anti fragile my ass! Also where is the 6 blocks figure from? Your ass? It's like having a website and complain to be hacked, just because you didn't install security patches. Do you also want the dev team to wipe your ass? No supporter of a website, web-server software or any other type of Internet appliance makes stupid claims like being "anti-fragile", "backed my math" or "secured by the laws of the universe" though. out of ass? Title: Re: Blockchain split of 4 July 2015 Post by: SebastianJu on July 05, 2015, 05:39:38 PM So they did not want to verify the blocks with 1MB because of the size and now 8MB blocks come. ::) At least they have a hard lesson that its risky to not verify. I mean they lost quite some, mining on the wrong fork. On top they are depending on users that might leave them now.
Title: Re: Blockchain split of 4 July 2015 Post by: jonald_fyookball on July 05, 2015, 05:45:04 PM So they did not want to verify the blocks with 1MB because of the size and now 8MB blocks come. ::) At least they have a hard lesson that its risky to not verify. I mean they lost quite some, mining on the wrong fork. On top they are depending on users that might leave them now. Can anyone explain why a miner wouldn't simply verify the last block in parallel with their mining computations? Let their ASICS hash while another machine double checks the last block. What's wrong with that? Title: Re: Blockchain split of 4 July 2015 Post by: AtheistAKASaneBrain on July 05, 2015, 05:51:12 PM Can someone advice me if this split would affect the price of bitcoin anyhow? If yes how? The "split" like you call it, was resolved by the network 6 blocks after it happened - which shows how resilient (or anti-fragile) the Bitcoin network has become. Regarding the price of bitcoin, please go to the speculation section of the forum. This is great news and bad news at the same time. I mean sure, the network is solid, but we now know unless you are using core, you may be prone to be a victim of accidents like that. Imagine you sent a big transaction through Electrum or were supposed to receive one... who would give your your money back? every victim is a potential bitcoin user that may get frustrated and never use it again, so this needs to be addressed so it never happens again, specially before we go fully mainstream, and Electrum type wallets will be most of the % of what people will be using, full node runners will remain a minority. Title: Re: Blockchain split of 4 July 2015 Post by: turvarya on July 05, 2015, 06:12:36 PM hey, i'd like to help bitcoin and setup electrum full node, i have 4GB-RAM 4GBvRAM VPS is it capable to run full node with 10k history limit? That should helpAny guide or help welcome for ubuntu 12.04 https://github.com/spesmilo/electrum-server/blob/master/HOWTO.md How much disk space to you have? i have currently 50 GB free out of 100, is it enough? edit. i can free up or request more space anytime Title: Re: Blockchain split of 4 July 2015 Post by: monbux on July 05, 2015, 06:19:24 PM So what exactly was responsible for this error? The miners, not all the miners but some of them.... To elaborate this a bit further: My understanding of the situation is that some miners use a mining technique called SPV mining that relies on the assumption that the rest of the network produces valid blocks to mine a tiny bit faster. Those miners using SPV mining essentially have a few seconds advantage over those that completly verify the block first. What happend is that a big pool using said technique received an "invalid" block, a block version 2. These have recently been declared invalid as over 950 out of 1000 blocks mined are version 3. The pool tried to build the chain on top of the now invalid version 2 block, causing the fork. Because of the way bitcoin works we had two chains competing over which is the correct one. Those running nodes 0.10.x or 0.9.5 would not accept the invalid blocks and those following it, while other nodes would still accept them as valid and thus accept a different chain as the longest and currently valid chain. This resulted in wasted hash power for the miners and confusion as different services and wallets that rely on bitcoin core in the background showed different information / statuses depending on the version of bitcoin core running in said background. Disclaimer: this attempt of a tl;dr version might be flawed, please correct me if you find any. maybe... I didn't follow the whole situation. I'm not very technologically advanced myself when it comes to the blockchain, so I am wondering, how does this affect wallets like the trezor and its webwallet? it affected the bitcoin blockchain, the various wallets 'validate' the blockchain.... Title: Re: Blockchain split of 4 July 2015 Post by: turvarya on July 05, 2015, 06:23:26 PM Can someone advice me if this split would affect the price of bitcoin anyhow? If yes how? The "split" like you call it, was resolved by the network 6 blocks after it happened - which shows how resilient (or anti-fragile) the Bitcoin network has become. Regarding the price of bitcoin, please go to the speculation section of the forum. It requires manual intervention, so anti fragile my ass! Also where is the 6 blocks figure from? Your ass? It's like having a website and complain to be hacked, just because you didn't install security patches. Do you also want the dev team to wipe your ass? ElectricMucus is right, it's not anti-fragile at all unless you think the Bitcoin fairies are magically keeping everything patched and updated for your downloading enjoyment. Someone has to monitor the system like a 24hr a day security guard. Nothing is automated. Every version of Bitcoin core after 0.9.5 can detect invalid blocks. Web wallets, SPV wallets and core 0.9.4 and earlier are still vulnerable to double spending. They need to wait 30 confirmations to be safe. That's the complete opposite of anti-fragile. That's more like fucked-in-a-hand-basket. I can't go to a store that uses SPV devices and buy something because I'll need to sleep there overnight to wait for my money to clear. What would you do if you were in a restaurant with family and pulled out your debit card to pay and the cashier told you to wait for a few hours because your bank is having a problem. I'd shit bricks. I'd close every account I had at that bank immediately and talk shit about them to anyone that would listen for the rest of my life. If your web-wallet provider wasn't up-to-date. Sure, close your account there. Find one, who takes his job more serious. (I actually changed my bank half a year ago, because my former bank's online banking sucked) If you use a SPV-wallet, make sure to connect to an up-to-date node. And yes, there is no Bitcoin fairy doing that for you. I can agree on that. Title: Re: Blockchain split of 4 July 2015 Post by: ElectricMucus on July 05, 2015, 06:24:02 PM No supporter of a website, web-server software or any other type of Internet appliance makes stupid claims like being "anti-fragile", "backed my math" or "secured by the laws of the universe" though. out of ass? Well, here is what /r/buttcoin has to say. http://www.reddit.com/r/Buttcoin/comments/3c76ng/why_yesterdays_bip66_accidental_hard_fork/ Quote And in general, actually verifying the transactions - the precise thing miners are paid the block reward for - is too much overhead when you could be mining the next block. Sooo the miners just ... assumed other miners' blocks were okay! As in: multiple miners, amounting to roughly half the hashrate. 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. Title: Re: Blockchain split of 4 July 2015 Post by: achow101 on July 05, 2015, 06:31:25 PM 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.Title: Re: Blockchain split of 4 July 2015 Post by: ElectricMucus on July 05, 2015, 06:47:50 PM 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.That's not the premise Bitcoin is being advertised to be built upon. The whole "protocol" rhetoric states that Bitcoin is supposed to enforce proper behavior on it's own. We both know and agree that's not how it works in practice, yet some people, those who came up with that anti-fragile bullshit will try to spin it in a different way. So the current premise: Bitcoin requires honest participation of the vast majority of it's participants in order to function, and that doesn't mean rational self interest but altruistic action for the good of the network. ANTI FRAGILE MY ASS Title: Re: Blockchain split of 4 July 2015 Post by: Cryddit on July 05, 2015, 07:04:58 PM The situation sort of reminds me of what happens when I'm trying to use a genetic algorithm or other heuristic-search algorithm to solve a problem, and it turns out that my reward function stated the problem slightly wrong.
The symptom is that you then get "pseudosolutions" - meaning, proposed solutions that exploit the flaw in the reward function, but which don't actually do anything useful. In this case we have a reward function that is supposed to pay miners for checking blocks and affirming that they are correct - but what it actually pays them for is agreeing with other miners about whether the blocks have been checked, and asserting that they are correct. The miners evolved a pseudosolution that allows them to collect the reward without actually checking the blocks. So how can we correct the reward function? Is there some key the miners can't possibly know, some test they cannot pass, unless they have REALLY checked the blocks? Title: Re: Blockchain split of 4 July 2015 Post by: SebastianJu on July 05, 2015, 07:27:21 PM I only now realized that the split happened on july the fourth. Knowing the movie indepence day i wont forget this date. And its a big thing in the US. If this somehow could have been made up to happen then i would assume now that it is part of the other forking discussion. A fork happening exactly on indepence day? Really?
Title: Re: Blockchain split of 4 July 2015 Post by: edonkey on July 05, 2015, 07:45:38 PM How long until we only need to wait for 1-6 Confirmations instead of 30 ? (i'm using a Trezor) until problem with major pools like p2pool and antpool solved and they start mining on correct blockchainand another duplicate blockchain issue fixed, if you are using latest versions then it shouldn't have any problem, as they have inbuilt header verification in code I think you mean F2Pool, not p2pool. It's an easy typo to make. Title: Re: Blockchain split of 4 July 2015 Post by: jonald_fyookball on July 05, 2015, 08:47:07 PM The situation sort of reminds me of what happens when I'm trying to use a genetic algorithm or other heuristic-search algorithm to solve a problem, and it turns out that my reward function stated the problem slightly wrong. The symptom is that you then get "pseudosolutions" - meaning, proposed solutions that exploit the flaw in the reward function, but which don't actually do anything useful. In this case we have a reward function that is supposed to pay miners for checking blocks and affirming that they are correct - but what it actually pays them for is agreeing with other miners about whether the blocks have been checked, and asserting that they are correct. The miners evolved a pseudosolution that allows them to collect the reward without actually checking the blocks. So how can we correct the reward function? Is there some key the miners can't possibly know, some test they cannot pass, unless they have REALLY checked the blocks? Interesting question , perhaps by requiring some kind of checksum be calculated and inserted into the next block? Title: Re: Blockchain split of 4 July 2015 Post by: shrekster on July 05, 2015, 09:11:35 PM I hope this is dealt with quick. Drama doesnt look good for new users even if its not that bad in reality.
Title: Re: Blockchain split of 4 July 2015 Post by: alberthendriks on July 05, 2015, 09:24:53 PM Interesting discussion on this page actually. How is it decided that a block is "wrong"? I understand that the block is not according to specs, but well yeah, you know what I mean.
Title: Re: Blockchain split of 4 July 2015 Post by: BADecker on July 05, 2015, 10:14:54 PM So that's why the price of Bitcoin has been going up this last week. Once people realize that there is this fork, the price will come down. Then people will realize that Bitcoin has stabilized, and there will be a buying frenzy again. The price will go back up for a while, until it stabilizes at some higher price.
We might be looking at Bitcoin under $100, but then in a few months, Bitcoin above $500. Can't wait. :) EDIT: If this doesn't happen, that is, if the price keeps on going up amidst this fork, and if the fork levels out and dissolves itself, then Bitcoin is here to stay. Title: Re: Blockchain split of 4 July 2015 Post by: JorgeStolfi on July 05, 2015, 10:19:53 PM 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? 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? * 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? * 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.) * 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? * In the standard version of the v3 core software, do miners get the whole parent node and verify its validity? * 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? * 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? * 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? * 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? The devs and others have been quick to blame F2Pool, and even AntPool, for the incident. But, depending on the answers to the above questions, other players may be to blame too. 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.) EDIT: Such a delay would have also reduced the risk of a fork being triggered by off-by-one bugs and network delays. 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. BTCNuggets deserved their slice of the blame for not upgrading to v3. EDIT: repaced some "v3 rules" by "BIP66 rules" Title: Re: Blockchain split of 4 July 2015 Post by: ElectricMucus on July 05, 2015, 10:42:41 PM And that's just the miners, we both know (it's a favorite jab of yours IIRC) what the actual users are capable of doing! I don't know if Bitcoin is as anti-fragile as many of us bitcoiners hope it to be, but it certainly stands up to a LOT of bullshit from the participants, and I think you are honest enough to admit that. No argument about what bullshit miners and the rest of the Bitcoiners are capable of. Most of it hasn't affected the software because it was in the social realm. My beef here is with the randroid/"objectivist" corner here, which is quite large (or perhaps just very visible). I see this event as an excellent debunking of their ideology. I have chosen to bring up "anti-fragile" because it has played into their childish belief that they can be as self-centered and anti-social as they want, and Bitcoin would continue to function. Now we've all seen that's not the case. Title: Re: Blockchain split of 4 July 2015 Post by: achow101 on July 05, 2015, 10:43:06 PM I am still trying to understand what actually happened. Pretty much.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? Some of the many questions that remain: 6 or 7 * How many blocks were actually mined on the bad branch (starting form B'(N)) before it was abandoned? * 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.) SPV Mining* 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? * 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.Title: Re: Blockchain split of 4 July 2015 Post by: Bitcoininspace on July 05, 2015, 11:30:23 PM I just wanna say good job to the OP above me for those awesome answers and for taking the time to reply to them, really made this thread make some more sense for us that aren't as techsavvy. :P
Title: Re: Blockchain split of 4 July 2015 Post by: cryptonit on July 05, 2015, 11:31:26 PM so much for the security advantage of bitcoin
because of massive hashrate compared to altcoins..... another urban legend to make bitcoin look superior busted Title: Re: Blockchain split of 4 July 2015 Post by: MicroGuy on July 05, 2015, 11:37:06 PM I just wanna say good job to the OP above me for those awesome answers and for taking the time to reply to them, really made this thread make some more sense for us that aren't as techsavvy. :P I second that....this guy is good. :) Title: Re: Blockchain split of 4 July 2015 Post by: JorgeStolfi on July 06, 2015, 12:12:47 AM 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. 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. 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 known 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... And, AFAIK, "SPV mining" is only the most likely theory, not confirmed or proved yet. Title: Re: Blockchain split of 4 July 2015 Post by: achow101 on July 06, 2015, 12:30:46 AM Thanks for the replies, @knightdk. You write: 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.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. 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. 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.Title: Re: Blockchain split of 4 July 2015 Post by: Cryddit on July 06, 2015, 12:56:48 AM I am still trying to understand what actually happened. Okay, I'll try to help. 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. Yes. The software doing the block version upgrade to V3 was watching and had counted 950 of the last 1000 blocks having contained headers that said "block version=3". Once that happened, any further blocks whose header said "block version = 2" were supposed to be rejected. And at precisely that moment, at absolutely the first block where a "version = 2" block ought to have been rejected, BTCNuggets mined a block whose blockchain header said "block version = 2." 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. Slight edit here: F2Pool and AntPool were not running correct software. They had taken correct software and then deliberately modified it to make it wrong. They stripped out the functionality of actually checking the block they were building on, because time spent checking a block for validity is not time spent mining, and - ASSUMING the block you've received is correct - spending more time mining makes you more money. So F2Pool took this "version= 2" block from BTCNuggets, failed to check it, and built a "version = 3" block as the next block in the chain. This version-3 block was not valid because it was built on a block that ought to've been rejected, but they'd never checked. F2Pool and Antpool then built further on this new invalid block, never actually checking the original block from BTCNuggets. If they had checked that block, they'd have known that the blocks they were building were invalid because that parent/grandparent/etc block originally built by BTCNuggets was invalid by the v3 rules. When they did this, they built a chain that every full node checking the block chain and running correct software for block-version-3 would immediately reject no matter how long it got. 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. Yes. Miners that had not deliberately introduced this bug into their software, simply ignored the bad chain because its blocks are invalid, and continued to do as they always do - to work to extend the longest valid chain. Likewise all v3-enabled clients were also ignoring the bad chain and would not regard a transaction as "real" unless it were included in a valid chain. 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. Regardless of how far ahead the bad branch had gotten, nobody running correct V3-checking software would ever have been using its blocks as a criterion of whether a transaction were successful, because those were invalid blocks. The bad fork could still be adding blocks today, and people running up-to-date software would be in absolutely no danger of being fooled. As far as a full node is concerned, your transaction is not confirmed until it is in a VALID block. The only reason people were in danger of thinking a transaction was confirmed when it in fact was not, is because a lot of them are subject to exactly the same bug that F2Pool and AntPool deliberately added to their otherwise-correct code - they are not fully checking blocks for validity. In some cases this is because they are running lightweight phone clients or SPV wallets. Some of those check most of the requirements for validity, but there is one condition that they cannot check without downloading the entire block chain, and that is that in order to be valid a block must be built on a valid parent block. In other cases this is because they are using web wallets at places like blockchain.io, and have no idea whether or not the people holding their keys are checking the validity of blocks according to the v.3 rules. - in which case it's best to assume that they are not, otherwise you're going to get "confirmed" transactions which later disappear. Is this a correct summary of the events? Approximately. * How many blocks were actually mined on the bad branch (starting form B'(N)) before it was abandoned? Six. Assuming nobody decides to mine another one. * 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? Yes. They had deliberately introduced a bug into their code to avoid "wasting" time checking the validity of blocks. * 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.) Perhaps they knew BIP66 had gone into effect, but they weren't checking validity, so clearly they didn't care. * 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? Pretty sure it doesn't matter; given what they'd done to their mining software it would have done the same thing regardless.* In the standard version of the v3 core software, do miners get the whole parent node and verify its validity? Yes, absolutely.* 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.) Nope, I checked. There is no off-by-one error in the functionality that they cut out of their client.* 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? Because of not being willing to spend one-tenth of a second checking a block when that tenth of a second could be spent mining. * 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? ALL OF THEM. The blocks between the current block and the genesis block. When you receive one block you need to check one block. And if you keep doing so, then at any given moment you're going to have complete proof of the validity of EVERY BLOCK from genesis to the current block. * 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? Clearly not at issue here; in more than one case, the previous block was more than ten seconds old before the next block came out, meaning there is absolutely no way that any attempt to check it was made. Any such check would have failed WELL before then. Title: Re: Blockchain split of 4 July 2015 Post by: dKingston on July 06, 2015, 01:03:49 AM did anyone LOSE BITCOINS as a result of this issue ?? That's what really matters ..
Title: Re: Blockchain split of 4 July 2015 Post by: achow101 on July 06, 2015, 01:05:39 AM 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.Title: Re: Blockchain split of 4 July 2015 Post by: Cryddit on July 06, 2015, 01:11:55 AM 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.To clarify: All the transactions in the BTCNuggets block, EXCEPT for the coinbase, which was an invalid transaction, were later included and confirmed in the valid chain. The other blocks in this fork did not contain any valid transactions; only their coinbases, which were invalid. Title: Re: Blockchain split of 4 July 2015 Post by: almightyruler on July 06, 2015, 01:59:52 AM So they did not want to verify the blocks with 1MB because of the size and now 8MB blocks come. ::) At least they have a hard lesson that its risky to not verify. I mean they lost quite some, mining on the wrong fork. On top they are depending on users that might leave them now. Can anyone explain why a miner wouldn't simply verify the last block in parallel with their mining computations? Let their ASICS hash while another machine double checks the last block. What's wrong with that? This is what I'm wondering too. The client probably isn't optimised for mining, but surely with custom software it would be possible to save state when a block is received from a peer, then immediately begin work on the new block. At the same time, verify the block that has just been received; if it turns out to be invalid, restore state and continue work on the "old" block. This way you still get the speed advantage, but with the added safety of consistency checks. Title: Re: Blockchain split of 4 July 2015 Post by: achow101 on July 06, 2015, 02:05:23 AM So they did not want to verify the blocks with 1MB because of the size and now 8MB blocks come. ::) At least they have a hard lesson that its risky to not verify. I mean they lost quite some, mining on the wrong fork. On top they are depending on users that might leave them now. Can anyone explain why a miner wouldn't simply verify the last block in parallel with their mining computations? Let their ASICS hash while another machine double checks the last block. What's wrong with that? This is what I'm wondering too. The client probably isn't optimised for mining, but surely with custom software it would be possible to save state when a block is received from a peer, then immediately begin work on the new block. At the same time, verify the block that has just been received; if it turns out to be invalid, restore state and continue work on the "old" block. This way you still get the speed advantage, but with the added safety of consistency checks. Source: First, we are not a pure SPV mining operation. We only do that within seconds after a new block is found on the network. We did have a safe guard in the beginning which falls back to the verified block template if after one or two minutes the local bitcoind still not able to catch up with the udp notification. But the safe guard was disabled due to bug when we lost an orphan race a few months ago. We have already implemented a quick fix. It should be ok now. And we will further refine the code in the next few days. Title: Re: Blockchain split of 4 July 2015 Post by: wayayo on July 06, 2015, 02:31:38 AM The problem is solved now?
Title: Re: Blockchain split of 4 July 2015 Post by: JorgeStolfi on July 06, 2015, 03:06:23 AM so much for the security advantage of bitcoin because of massive hashrate compared to altcoins..... another urban legend to make bitcoin look superior busted No matter how big the army, it cannot defend the country from an internal war. Title: Re: Blockchain split of 4 July 2015 Post by: JorgeStolfi on July 06, 2015, 03:15:49 AM Thanks @knightdk again for the reply. You write:
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. [ ... ] As I said above, [ rejecting connections from outdated players ] 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. In understand that clients don't need to update if a soft fork only makes the rules for blocks more restrictive. However, if it makes the rules for transactions more restrictive too, then the clients must update anyway, otherwise their transactions will be rejected (except by nodes and miners who are still running the old version, which may cause those transactions to be confirmed and then unconfirmed). isn't that so? Isn't that the case of BIP66? I believe that [ the "SPV mining hypothesis ] has been both confirmed and proved by F2Pool and AntPool. Indeed, I see the quote in other posts. Title: Re: Blockchain split of 4 July 2015 Post by: JorgeStolfi on July 06, 2015, 03:54:48 AM Thanks @Cryddit for the replies! You write:
F2Pool and AntPool were not running correct software. They had taken correct software and then deliberately modified it to make it wrong. Well, it is debatable whether it can be called "wrong". It is more risky for the miner, and not what the bitcoin devs think that the miner should do, and not as helpful to the system as the others would think. But miners have no obligation to behave in any particular way. Each miner has the right to run whatever software he wants and output any blocks he wants. The economic incentives are supposed to lead him, through self-interest, to behave in a way that is best for the system. If the incentives are right but the miner doesn't act in his best interests, it is his problem, not anyone else's. But if the incentives actually encourage a behavior that is bad for the system, it is a flaw of the protocol. When they opted for "SPV mining", it was because they thought it would increase their revenue. In this case it didn't, but maybe it paid off overall. Perhaps they overreacted to that incident that made them disable the verification code (when they lost ~6000 USD in an orphaned block because of a few seconds of delay); or perhaps "SPV mining" indeed saved them from several other incidents. Anyway, it should be their problem to figure that out and do what they think is best for them. Their losses in that chain should not be of concert to anyone... except that there were many v2 nodes and clients out there that got confused because, by their criteria, the 'bad' chain was fully valid and was the longest chain. So, I insist that the devs deserve a fat slice of the blame: for not having a delay after the "95% majority" event, and because they choose to do a riskier manoeuver (allow v3 nodes and miners interact with v2 clients) for PR reasons (to keep clients unaware of the change, and let them run the v2 version even after it went into effect). Title: Re: Blockchain split of 4 July 2015 Post by: cyberarmy786 on July 06, 2015, 04:00:08 AM i m using btc e so here ill be same as this post?
Title: Re: Blockchain split of 4 July 2015 Post by: tspacepilot on July 06, 2015, 05:02:00 AM so much for the security advantage of bitcoin because of massive hashrate compared to altcoins..... another urban legend to make bitcoin look superior busted Well, maybe you're correct that a solid hashrate to defend against 51% attacks is just an urban legend. Or maybe it also has to do with the idea that having a massive hashrate means massive interest in using a given coin. I'll be sure to double-check that with the devs of the 1001 altcoins that have gone down the tubes over the past year for not having a single miner. With respect to security, though, there's this: 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.So, I dunno, you're probably right bitcoin's usefullness and popularity are also just "urban legends". But I'll have to double check that tomorrow after I buy some stuff for my house on overstock.com using bitcoin. Title: Re: Blockchain split of 4 July 2015 Post by: JorgeStolfi on July 06, 2015, 05:06:51 AM So, I dunno, you're probably right bitcoin's usefullness and popularity are also just "urban legends". But I'll have to double check that tomorrow after I buy some stuff for my house on overstock.com using bitcoin. You mean: after you sell some of your bitcoins for dollars through BitPay, and buy some stuff on overstock.com using those dollars. ;) Title: Re: Blockchain split of 4 July 2015 Post by: Amitabh S on July 06, 2015, 05:32:42 AM In this event, it is Blockchain.info that I blame the most! They are the ones that created confusion within the community. They didn't do their job (again?). They have an official wallet and they are (were?) the source of blockchain statistic that people came to trust. They should have validated blocks for their users - they didn't. Didn't they also had a bug, a few months ago, on bitcoin addresses generation, related to entropy? bc.i should have insured that the correct blockchain (v3) was displayed on their stat page - not the (v2) fork - they know better! I agree with this partly. While bc.i has been providing an invaluable service, they seem to be having a lot of bugs lately. However, its not their fault if people start conflating bitcoin with bc.i. BTW, from what I gleaned from their error messages over the months, they are using (possibly modded) bitcoinj. In SPV mode this also would not validate BIP66. On a different note, here's one proposed solution for SPV nodes that does not require us to wait for 30 confirmations. Please comment on its correctness. Let us assume that an "invalid chain" cannot be more than 50 blocks. Step 1. We boot our SPV node "now", several days after the July 4 fork. Step 2. We receive the mth block, say b_m. We ensure that b_m is version 3 block. Step 3. We need to ensure that at least 50 previous blocks before b_m were also correct. We download those blocks (not just the headers). That is blocks b_{m-50}, b_{m-49}... b_{m-1}. Then we ensure that all were version 3, have correct signatures, etc, and correctly validate the next block (via the prevBlockHash). Step 4. We can start counting b_m as a block of a valid chain if above checks pass. Step 5. For any further received blocks, we follow steps 2, 4, 5 (skipping steps 1 and 3), since we have already validated 50 blocks before the "boot" block. Hence we validating only with block b_{m-1} is sufficient. Title: Re: Blockchain split of 4 July 2015 Post by: intrader on July 06, 2015, 07:30:20 AM I sent btc to yobit but its weird that my btc did not show up on account instead auto withdrawal to another btc address,i never encounter such thing before,does this blockchain problem or what i dont know,i only know i lost my bitcoin
Title: Re: Blockchain split of 4 July 2015 Post by: Amph on July 06, 2015, 07:36:55 AM I sent btc to yobit but its weird that my btc did not show up on account instead auto withdrawal to another btc address,i never encounter such thing before,does this blockchain problem or what i dont know,i only know i lost my bitcoin that btc address to who belongs, it is your? because it sounds like your account there is hacked(your pc is infected maybe) or something, and this has nothing to do with the blockchain split Title: Re: Blockchain split of 4 July 2015 Post by: intrader on July 06, 2015, 07:45:55 AM I sent btc to yobit but its weird that my btc did not show up on account instead auto withdrawal to another btc address,i never encounter such thing before,does this blockchain problem or what i dont know,i only know i lost my bitcoin that btc address to who belongs, it is your? because it sounds like your account there is hacked(your pc is infected maybe) or something, and this has nothing to do with the blockchain split Title: Re: Blockchain split of 4 July 2015 Post by: Amph on July 06, 2015, 07:51:32 AM I sent btc to yobit but its weird that my btc did not show up on account instead auto withdrawal to another btc address,i never encounter such thing before,does this blockchain problem or what i dont know,i only know i lost my bitcoin that btc address to who belongs, it is your? because it sounds like your account there is hacked(your pc is infected maybe) or something, and this has nothing to do with the blockchain split 2fact with email or phone? because it looks more and more like a steal and not a related issue of the blockchain split, that will not cause such a thing btw but i'm curious can you post the address? Title: Re: Blockchain split of 4 July 2015 Post by: intrader on July 06, 2015, 08:13:40 AM I sent btc to yobit but its weird that my btc did not show up on account instead auto withdrawal to another btc address,i never encounter such thing before,does this blockchain problem or what i dont know,i only know i lost my bitcoin that btc address to who belongs, it is your? because it sounds like your account there is hacked(your pc is infected maybe) or something, and this has nothing to do with the blockchain split 2fact with email or phone? because it looks more and more like a steal and not a related issue of the blockchain split, that will not cause such a thing btw but i'm curious can you post the address? You can see there are a withdrawal at 18:48:30,i dont know why my bitcoin will sent to there Title: Re: Blockchain split of 4 July 2015 Post by: intrader on July 06, 2015, 08:32:24 AM I sent btc to yobit but its weird that my btc did not show up on account instead auto withdrawal to another btc address,i never encounter such thing before,does this blockchain problem or what i dont know,i only know i lost my bitcoin that btc address to who belongs, it is your? because it sounds like your account there is hacked(your pc is infected maybe) or something, and this has nothing to do with the blockchain split 2fact with email or phone? because it looks more and more like a steal and not a related issue of the blockchain split, that will not cause such a thing btw but i'm curious can you post the address? You can see there are a withdrawal at 18:48:30,i dont know why my bitcoin will sent to there Title: Re: Blockchain split of 4 July 2015 Post by: turvarya on July 06, 2015, 08:41:54 AM I sent btc to yobit but its weird that my btc did not show up on account instead auto withdrawal to another btc address,i never encounter such thing before,does this blockchain problem or what i dont know,i only know i lost my bitcoin that btc address to who belongs, it is your? because it sounds like your account there is hacked(your pc is infected maybe) or something, and this has nothing to do with the blockchain split 2fact with email or phone? because it looks more and more like a steal and not a related issue of the blockchain split, that will not cause such a thing btw but i'm curious can you post the address? You can see there are a withdrawal at 18:48:30,i dont know why my bitcoin will sent to there I think, most services you sent Bitcoin to, don't keep it in the address you sent it do, but forward it to another address where they accumulate all inputs. But I seriously have never checked, if that is really true. Looking at the blockchain is not an easy way to get any information. You should just do that, as a last resort. Title: Re: Blockchain split of 4 July 2015 Post by: intrader on July 06, 2015, 08:47:25 AM I sent btc to yobit but its weird that my btc did not show up on account instead auto withdrawal to another btc address,i never encounter such thing before,does this blockchain problem or what i dont know,i only know i lost my bitcoin that btc address to who belongs, it is your? because it sounds like your account there is hacked(your pc is infected maybe) or something, and this has nothing to do with the blockchain split 2fact with email or phone? because it looks more and more like a steal and not a related issue of the blockchain split, that will not cause such a thing btw but i'm curious can you post the address? You can see there are a withdrawal at 18:48:30,i dont know why my bitcoin will sent to there I think, most services you sent Bitcoin to, don't keep it in the address you sent it do, but forward it to another address where they accumulate all inputs. But I seriously have never checked, if that is really true. Looking at the blockchain is not an easy way to get any information. You should just do that, as a last resort. Title: Re: Blockchain split of 4 July 2015 Post by: newb4now on July 06, 2015, 08:48:40 AM I have a hard time believing that F2pool and AntPool did this by accident.
However I also cant see their profit motive in this case since everyone knew what was happening. It seems they just wasted time/money on the wrong chain with no benefit. What am I missing? Title: Re: Blockchain split of 4 July 2015 Post by: Mayer Amschel on July 06, 2015, 09:09:11 AM So are we back to normal ???
Title: Re: Blockchain split of 4 July 2015 Post by: DooMAD on July 06, 2015, 09:14:53 AM I have a hard time believing that F2pool and AntPool did this by accident. However I also cant see their profit motive in this case since everyone knew what was happening. It seems they just wasted time/money on the wrong chain with no benefit. What am I missing? Deliberate actions can lead to an accident, which is what happened here. It's like knowing the route to get somewhere, but making a decision to take a shortcut and then getting hopelessly lost as a result. Their intention was to cut corners by only doing part of the job they're supposed to be doing. As a result they went heading off in the wrong direction and paid the consequences. If they had done their job properly, they wouldn't have got "lost". If blockchain.info had reported the correct blockchain all along, everyone would be laughing at those two Chinese pools who decided to (unsuccessfully) form their own version of the "blockchain" on the same day as the USA Independence celebrations... Priceless! Blockchain.info are the ones I blame the most for this incident! They are the ones that created confusion within the community. They didn't do their job (again?). They have an official wallet and they are (were?) the source of blockchain statistics that people came to trust. They should have validated blocks for their users - they didn't. Didn't they also had a bug, a few months ago, on bitcoin addresses generation, related to entropy? bc.i should have insured that the correct blockchain (v3) was displayed on their stat page - not the (v2-based) fork - they knew better! (and if they didn't, they do now...) I'd be a little more cautious about placing such trust in third parties. Saying that Blockchain.info have an "official" wallet is the same as saying that Gox had an "official" wallet because the community trusted them at one point. It's the same mistake people make with the traditional banking sector and we should be wary about repeating it here. At the end of the day, they're just a company and you have to decide whether to rely on them or not. Thankfully, there were enough users who noticed the problem because they weren't trusting a third party to provide the information for them. If everyone was relying on a third party, the mess could have been much worse. Title: Re: Blockchain split of 4 July 2015 Post by: thebigtalk on July 06, 2015, 09:28:06 AM I'm experiencing delays when this happened. Good thing the transactions went through. Although Ive seen the notice, I still continued with the cash out and didn't wait for things to go back to normal. Now I learned my lesson and wouldn't proceed when this thing happens again.
Title: Re: Blockchain split of 4 July 2015 Post by: SebastianJu on July 06, 2015, 09:58:13 AM So does this mean we were 11% away from winning the wrong fork? Thats actually some feary news that could be created out of it.
What i dont understand... i can understand using SPV, but whats hindering the miner to mine on the new block and verify the actual block in the meanwhile. Only the miners are time sensitive, the computer controlling it most probably has spare cpu time. They could have saved quite some damage. I think they wont disable SPV but at least implement a fix that verifies the blocks later. Title: Re: Blockchain split of 4 July 2015 Post by: JorgeStolfi on July 06, 2015, 11:59:24 AM On a different note, here's one proposed solution for SPV nodes that does not require us to wait for 30 confirmations. Please comment on its correctness. Let us assume that an "invalid chain" cannot be more than 50 blocks. Step 1. We boot our SPV node "now", several days after the July 4 fork. Step 2. We receive the mth block, say b_m. We ensure that b_m is version 3 block. Step 3. We need to ensure that at least 50 previous blocks before b_m were also correct. We download those blocks (not just the headers). That is blocks b_{m-50}, b_{m-49}... b_{m-1}. Then we ensure that all were version 3, have correct signatures, etc, and correctly validate the next block (via the prevBlockHash). Step 4. We can start counting b_m as a block of a valid chain if above checks pass. Step 5. For any further received blocks, we follow steps 2, 4, 5 (skipping steps 1 and 3), since we have already validated 50 blocks before the "boot" block. Hence we validating only with block b_{m-1} is sufficient. You are proposing is to modify the client so that it would do what a full node would do, only truncated to that last 50 nodes. Just checking the version tag is not enough. This hacked client app must also know that the BIP66 rule became active at a certain block b_{n}. Otherwise it would have to keep fetching blocks until it finds a "95% majority" event, or reaches a block before the v3 software was published. Title: Re: Blockchain split of 4 July 2015 Post by: JorgeStolfi on July 06, 2015, 12:07:07 PM I have a hard time believing that F2pool and AntPool did this by accident. However I also cant see their profit motive in this case since everyone knew what was happening. It seems they just wasted time/money on the wrong chain with no benefit. What am I missing? According to this reddit comment (https://www.reddit.com/r/Bitcoin/comments/3c8tq2/questions_about_the_july_4th_bip66_fork/cstil28), F2Pool did not even have the header of the invalid block B when they started mining on top of it. The big pools monitor the instructions that other pools send to their members, to catch the hash of a recently mined block even before that block gets to the relay nodes. They just did not notice (or had no way of knowing) that the hash came from a pool in the 5% that was still running v2, and therefore was likely to be invalid. Title: Re: Blockchain split of 4 July 2015 Post by: QuestionAuthority on July 06, 2015, 12:58:43 PM They were cheating the system. Bitcoin has one variable that can't be predicted - human behavior. The system will always be flawed as long as someone sees an advantage in doing the wrong thing. Bitcoin isn't a worldwide corporation but it's players must act as if it were. Independent global actors must each do their part correctly and for the good of the whole except all of them are motivated differently. The problem with a system controlled by no one and everyone is the old adage, what's best for me is what's best.
Title: Re: Blockchain split of 4 July 2015 Post by: S4VV4S on July 06, 2015, 01:01:38 PM I have a hard time believing that F2pool and AntPool did this by accident. However I also cant see their profit motive in this case since everyone knew what was happening. It seems they just wasted time/money on the wrong chain with no benefit. What am I missing? It was an accident, or more like their speed "cheat" cost them a few thousands of dollars. If it was intentional then there was going to be transactions included in the blocks they found. And there were no transactions in their blocks. Title: Re: Blockchain split of 4 July 2015 Post by: Brangdon on July 06, 2015, 01:09:05 PM So does this mean we were 11% away from winning the wrong fork? No. The invalid chain would never have been accepted by up to date full nodes, regardless of how long it got, because it was invalid.Quote What i dont understand... i can understand using SPV, but whats hindering the miner to mine on the new block and verify the actual block in the meanwhile. It sounds like they had code to do that, but disabled it because of a bug, and never got around to re-enabling it.Title: Re: Blockchain split of 4 July 2015 Post by: Amitabh S on July 06, 2015, 01:09:49 PM On a different note, here's one proposed solution for SPV nodes that does not require us to wait for 30 confirmations. Please comment on its correctness. Let us assume that an "invalid chain" cannot be more than 50 blocks. Step 1. We boot our SPV node "now", several days after the July 4 fork. Step 2. We receive the mth block, say b_m. We ensure that b_m is version 3 block. Step 3. We need to ensure that at least 50 previous blocks before b_m were also correct. We download those blocks (not just the headers). That is blocks b_{m-50}, b_{m-49}... b_{m-1}. Then we ensure that all were version 3, have correct signatures, etc, and correctly validate the next block (via the prevBlockHash). Step 4. We can start counting b_m as a block of a valid chain if above checks pass. Step 5. For any further received blocks, we follow steps 2, 4, 5 (skipping steps 1 and 3), since we have already validated 50 blocks before the "boot" block. Hence we validating only with block b_{m-1} is sufficient. You are proposing is to modify the client so that it would do what a full node would do, only truncated to that last 50 nodes. Just checking the version tag is not enough. This hacked client app must also know that the BIP66 rule became active at a certain block b_{n}. Otherwise it would have to keep fetching blocks until it finds a "95% majority" event, or reaches a block before the v3 software was published. I agree, we need a timestamp. Version 3 started from orphaned block 363731 onwards. That block was generated at 2015-07-04 02:09:40. which turns out to be 1435955980000 in Unix time. We ensure that any block with timestamp greater than above is checked using the above logic with appropriate modification (example, v3 check in previous blocks stops at block 363730). This is still cheaper than running a full node. I don't think we would need to hack bitcoinj because it gives us hooks (onBlock, etc) where we can add this logic. Title: Re: Blockchain split of 4 July 2015 Post by: QuestionAuthority on July 06, 2015, 01:19:13 PM I have a hard time believing that F2pool and AntPool did this by accident. However I also cant see their profit motive in this case since everyone knew what was happening. It seems they just wasted time/money on the wrong chain with no benefit. What am I missing? It was an accident, or more like their speed "cheat" cost them a few thousands of dollars. If it was intentional then there was going to be transactions included in the blocks they found. And there were no transactions in their blocks. See this thread: https://bitcointalk.org/index.php?topic=700411.msg11790734#msg11790734 Miners will very much be impacted by the incident. Maybe you pay for this time, but you cannot continue to cover such a large loss. What about confidence? Do you think people should have confidence to mine with F2pool and no shady actions will occur? There is no impact on miners at all, and our PPS fee is very low if you consider all those merged coins we are giving out: 7 NMC/IXC/I0C is about 0.019 BTC or 1.9% of your earning. The loss is also trivial to us. Our Bitcoin reserve is more than 10000 BTC and we also have many altcoins. I do mine with F2pool at times, currently as a backup, and I think we deserve to hear more about how this does not impact us. Care to comment on 'SPV mining' explanations being provided by the bitcoin folks? The short version is they state you and antpool caused most of this because you were not validating blocks. Do you have a response, or is this the way you plan to run your pool in the future? We will continue do SPV mining despite the incident, and I think so will AntPool and BTC China. We will do it more carefully in the future however. Today's incident was caused by one of AntPool's outdated bitcoinds. BTC China and us simply followed AntPool's block announcement, only they have worse luck, so they did not generate as many blocks as us. We will continue do SPV mining despite the incident, and I think so will AntPool and BTC China. Another very good reason people should not mine on Chinese pools. This is EXTREMELY bad for the Bitcoin network. Title: Re: Blockchain split of 4 July 2015 Post by: JorgeStolfi on July 06, 2015, 01:22:42 PM They were cheating the system. Bitcoin has one variable that can't be predicted - human behavior. The system will always be flawed as long as someone sees an advantage in doing the wrong thing. Bitcoin isn't a worldwide corporation but it's players must act as if it were. Independent global actors must each do their part correctly and for the good of the whole except all of them are motivated differently. The problem with a system controlled by no one and everyone is the old adage, what's best for me is what's best. Sorry, that was not the idea. Players were supposed to behave in certain ways because of the economic incentives built into the protocol, not because of "the good of the whole". If players find that it is more advantageous to them to behave in ways that are bad for the system, that is a flaw of the protocol, not a fault of the players. Title: Re: Blockchain split of 4 July 2015 Post by: QuestionAuthority on July 06, 2015, 01:25:47 PM They were cheating the system. Bitcoin has one variable that can't be predicted - human behavior. The system will always be flawed as long as someone sees an advantage in doing the wrong thing. Bitcoin isn't a worldwide corporation but it's players must act as if it were. Independent global actors must each do their part correctly and for the good of the whole except all of them are motivated differently. The problem with a system controlled by no one and everyone is the old adage, what's best for me is what's best. Sorry, that was not the idea. Players were supposed to behave in certain ways because of the economic incentives built into the protocol, not because of "the good of the whole". If players find that it is more advantageous to them to behave in ways that are bad for the system, that is a flaw of the protocol, not a fault of the players. I agree with what your saying with the exception that I see the system as organic. The players are the system. Bitcoin can't function alone as some sort of AI. We are Bitcoin. Title: Re: Blockchain split of 4 July 2015 Post by: Zeroxal on July 06, 2015, 01:29:58 PM So basically, we should wait for the transactions to get a confirmation other than from Antpool or f2pool to safely get the bitcoins in the wallet?
If Antpool and/or f2pool finds blocks in a chain its not safe anymore? Did someone actually get a loss from this incident? Title: Re: Blockchain split of 4 July 2015 Post by: RealBitcoin on July 06, 2015, 01:42:20 PM Isnt this causing a systematic problem. I mean if the pool this error originated from now gains less trust, and the miners leave the pool due to lack of trust. Now the pool can go bankrupt, and the other pools consolidate. Isnt this increase the risk of 51% attack? I think this is the main concern mostly. As if the mining pools get sabogaged by these things, it can become very easy for 1 pool to gain monopoly and then face 51% attack? Does anyone have an answer to this? I am more worried of centralization than rather blockchain split :( Title: Re: Blockchain split of 4 July 2015 Post by: drakoin on July 06, 2015, 01:50:09 PM Is it conceivable to add a service network which announces "block XYZ was invalid"? A service that miners could subscribe to; or organize themselves, even on one of their machines only? Could make sense if those instances are rare. Then SPV miners start hashing with what they assume (but not check) is a valid block, and when a few seconds later an "invalid block" alert is broadcast, they simply restart. Possible? Wrong approach? Then sorry - I do not understand enough of this yet. But the other thing ... miners deliberately mining empty blocks, that sounds ruthless, no? No answer. So I am probably wrong? What I was thinking is: This "two-phases SPV / full" mining could give them their headstart for the first seconds phase after they receive a block on top of which they want to build. Then in "phase 2": If this questionable block is really valid, they just continue. If invalid, they immediately drop it, and restart. Could that approach reduce the harm that SPV miners are causing? Title: Re: Blockchain split of 4 July 2015 Post by: avatar_kiyoshi on July 06, 2015, 01:52:43 PM So for now is risky to make a transaction? Without use core wallet?
I used electrum wallet. Title: Re: Blockchain split of 4 July 2015 Post by: RealBitcoin on July 06, 2015, 01:54:50 PM So for now is risky to make a transaction? Without use core wallet? I used electrum wallet. I think only incoming transactions are risky, because they can be double spent easily. But outgoing transactions should be fine i guess :) Some1 please confirm this! Title: Re: Blockchain split of 4 July 2015 Post by: achow101 on July 06, 2015, 02:26:26 PM In understand that clients don't need to update if a soft fork only makes the rules for blocks more restrictive. However, if it makes the rules for transactions more restrictive too, then the clients must update anyway, otherwise their transactions will be rejected (except by nodes and miners who are still running the old version, which may cause those transactions to be confirmed and then unconfirmed). isn't that so? Isn't that the case of BIP66? This was considered by the developers when they wrote the BIP. Essentially, these transactions have been around since version 0.8.0 and this soft-fork simply makes said transactions a protocol rule.From the BIP itself: Quote Compatibility The requirement to have signatures that comply strictly with DER has been enforced as a relay policy by the reference client since v0.8.0, and very few transactions violating it are being added to the chain as of January 2015. In addition, every non-compliant signature can trivially be converted into a compliant one, so there is no loss of functionality by this requirement. This proposal has the added benefit of reducing transaction malleability (see BIP 62). Title: Re: Blockchain split of 4 July 2015 Post by: tspacepilot on July 06, 2015, 02:30:06 PM So for now is risky to make a transaction? Without use core wallet? I used electrum wallet. I think only incoming transactions are risky, because they can be double spent easily. But outgoing transactions should be fine i guess :) Some1 please confirm this! I know the thread has been growing fast, but this has already been asked and answered, post 169: So this will only potentially effect people who are making transaction, sending & receiving coins atm? If I'm a simple HODLER & haven't & won't be buying any coins this weekend I'm safe & ok yes? Thanks in advance to anybody who responds. Hodlers are unaffected Payers, technically speaking, are unaffected, despite that your payees may require more confirmations than usual Payees, with Bitcoin core 0.9.5 or above, are unaffected. Payees, with anything else, please follow the instructions in the header of the forum Title: Re: Blockchain split of 4 July 2015 Post by: achow101 on July 06, 2015, 02:33:43 PM Is it conceivable to add a service network which announces "block XYZ was invalid"? A service that miners could subscribe to; or organize themselves, even on one of their machines only? Could make sense if those instances are rare. Then SPV miners start hashing with what they assume (but not check) is a valid block, and when a few seconds later an "invalid block" alert is broadcast, they simply restart. Possible? Wrong approach? Then sorry - I do not understand enough of this yet. But the other thing ... miners deliberately mining empty blocks, that sounds ruthless, no? No answer. So I am probably wrong? What I was thinking is: This "two-phases SPV / full" mining could give them their headstart for the first seconds phase after they receive a block on top of which they want to build. Then in "phase 2": If this questionable block is really valid, they just continue. If invalid, they immediately drop it, and restart. Could that approach reduce the harm that SPV miners are causing? Title: Re: Blockchain split of 4 July 2015 Post by: Friki Verax on July 06, 2015, 02:38:08 PM So for now is risky to make a transaction? Without use core wallet? I used electrum wallet. I think only incoming transactions are risky, because they can be double spent easily. Double-spending transactions won't work because transaction included in the blocks in question are invalid blocks and will be rejected in Bitcoin Core 0.10.x or 0.9.5 and Bitcoin Core <0.10.x switches to longer chain(main chain) which will also make those blocks useless. So the transaction you got earlier won't be there when those blocks are rejected. That's why, you should wait for ~30 confirmations or near to it for making sure the transaction you received is included in longer chain(main chain). But outgoing transactions should be fine i guess :) No, its not. Like in the above case, if your transaction is included in invalid block but not in valid block, your Bitcoins returns to your address when that chain or block is rejected. You will have to make sure your transaction gets enough confirmation. Some1 please confirm this! In other words, wait for more confirmations than usual. - snip - Payers, technically speaking, are unaffected, despite that your payees may require more confirmations than usual - snip - Title: Re: Blockchain split of 4 July 2015 Post by: drakoin on July 06, 2015, 03:08:19 PM Is it conceivable to add a service network which announces "block XYZ was invalid"? A service that miners could subscribe to; or organize themselves, even on one of their machines only? ... Could that approach reduce the harm that SPV miners are causing? Let us hope they do. A "should" is a "could" plus some ethics. *lol* The "... validating blocks that they receive while they are ..." is exactly what I was suggesting, indeed. And it would be enough to be done on only one of their thousands of machines. The issue with these validations is what happens if they mined the block before they finish validating the previous? I see a question mark there. What were the blocktimes between those 6 invalid blocks? And the last of those 6 blocks, how many seconds after the 1st invalid block was that? Title: Re: Blockchain split of 4 July 2015 Post by: achow101 on July 06, 2015, 03:19:10 PM Is it conceivable to add a service network which announces "block XYZ was invalid"? A service that miners could subscribe to; or organize themselves, even on one of their machines only? ... Could that approach reduce the harm that SPV miners are causing? Let us hope they do. A "should" is a "could" plus some ethics. *lol* The "... validating blocks that they receive while they are ..." is exactly what I was suggesting, indeed. The issue with these validations is what happens if they mined the block before they finish validating the previous? I see a question mark there. What were the blocktimes between those 6 invalid blocks? And the last of those 6 blocks, how many seconds after the 1st invalid block was that? The problem with simultaneous validation and a service alerting miners of invalid blocks is that there is nothing forcing miners to use the service or validate. The only way that they are forced to do any of these is if there are financial incentives. Title: Re: Blockchain split of 4 July 2015 Post by: drakoin on July 06, 2015, 03:30:59 PM The only way that they are forced to do any of these is if there are financial incentives. So it is truely great that they lost money in this. Title: Re: Blockchain split of 4 July 2015 Post by: drakoin on July 06, 2015, 03:32:38 PM there is nothing forcing miners to use the service or validate. add a PoV = Proof of Validation? Title: Re: Blockchain split of 4 July 2015 Post by: RealBitcoin on July 06, 2015, 04:13:28 PM Isnt this causing a systematic problem. I mean if the pool this error originated from now gains less trust, and the miners leave the pool due to lack of trust. Now the pool can go bankrupt, and the other pools consolidate. Isnt this increase the risk of 51% attack? I think this is the main concern mostly. As if the mining pools get sabogaged by these things, it can become very easy for 1 pool to gain monopoly and then face 51% attack? Does anyone have an answer to this? I am more worried of centralization than rather blockchain split :( I know that this thread grows fast but please can some1 answer to my question, its really important. I am really concerned about mining pool consolidations. How big risk does this pose? Title: Re: Blockchain split of 4 July 2015 Post by: jonald_fyookball on July 06, 2015, 04:16:30 PM Isnt this causing a systematic problem. I mean if the pool this error originated from now gains less trust, and the miners leave the pool due to lack of trust. Now the pool can go bankrupt, and the other pools consolidate. Isnt this increase the risk of 51% attack? I think this is the main concern mostly. As if the mining pools get sabogaged by these things, it can become very easy for 1 pool to gain monopoly and then face 51% attack? Does anyone have an answer to this? I am more worried of centralization than rather blockchain split :( I know that this thread grows fast but please can some1 answer to my question, its really important. I am really concerned about mining pool consolidations. How big risk does this pose? The market has proven to be self correcting. When GHash got 49%, action was taken, now its down to 10% or something. So if for some reason a pool died because it couldnt follow proper procedures, yes other pools would grow, but if no single pool would get to 50% because it wouldn't be in the miner's best interests to allow that to happen, at least for long. Title: Re: Blockchain split of 4 July 2015 Post by: Friki Verax on July 06, 2015, 04:22:56 PM Isnt this causing a systematic problem. I mean if the pool this error originated from now gains less trust, and the miners leave the pool due to lack of trust. Now the pool can go bankrupt, and the other pools consolidate. Isnt this increase the risk of 51% attack? I think this is the main concern mostly. As if the mining pools get sabogaged by these things, it can become very easy for 1 pool to gain monopoly and then face 51% attack? Does anyone have an answer to this? I am more worried of centralization than rather blockchain split :( I know that this thread grows fast but please can some1 answer to my question, its really important. I am really concerned about mining pool consolidations. How big risk does this pose? Almost all pools don't do this because they will loose their block rewards. So there is an incentive for miners to not to do this which will prevent >50% attack. Besides, miners moves their hash power to another pool if this happens like they did when Ghash.io had nearly 50% of total hash power. This is not a big concern unless if more pools start closing down. Title: Re: Blockchain split of 4 July 2015 Post by: manselr on July 06, 2015, 04:31:59 PM I wonder why miners don't pay more attention to this. Im assuming they want the best for Bitcoin, so why can't they just predict this from happening and take action? I can't be that difficult to pay attention to the hashrate distribution.
Title: Re: Blockchain split of 4 July 2015 Post by: achow101 on July 06, 2015, 04:42:43 PM I wonder why miners don't pay more attention to this. Im assuming they want the best for Bitcoin, so why can't they just predict this from happening and take action? I can't be that difficult to pay attention to the hashrate distribution. That is a pretty bad assumption. You should assume that miners are in it for the money. Sure there are some miners that mine to help the network, but really, right now the largest miners exist because of the financial incentives. They do everything they can to make the most money, which includes cutting corners. And sometimes cutting corners has big risks and can cause problems for other people.Title: Re: Blockchain split of 4 July 2015 Post by: dooglus on July 06, 2015, 05:19:37 PM So how can we correct the reward function? Is there some key the miners can't possibly know, some test they cannot pass, unless they have REALLY checked the blocks? Interesting question , perhaps by requiring some kind of checksum be calculated and inserted into the next block? As I understand it, f2pool didn't even have a copy of the block they were mining on top of. All they had was the bare minimum needed to build on top of it. If validating a block produces a checksum that is needed to be included in the next block then whoever is giving them the details they need will just add that checksum to the list of details they provide. f2pool still won't have to validate anything. I don't see a way of checking that the miners even have a copy of the parent block let alone checking that they have verified it without breaking compatibility with all existing mining hardware. Title: Re: Blockchain split of 4 July 2015 Post by: MarketNeutral on July 06, 2015, 05:22:58 PM I'm looking forward to the day when mining income is derived mostly from including transactions. Miners/pools who create empty blocks on purpose are bad for the blockchain. By creating problematic 0tx blocks (and reminding us that scaling Bitcoin isn't as simple as bloating a sanity-check constant), miners force the devs to invent better solutions. Et voilà, anti-fragile! Well put. I love anti-fragile technology. Title: Re: Blockchain split of 4 July 2015 Post by: eneilwex on July 06, 2015, 05:23:54 PM They were cheating the system. Bitcoin has one variable that can't be predicted - human behavior. The system will always be flawed as long as someone sees an advantage in doing the wrong thing. Bitcoin isn't a worldwide corporation but it's players must act as if it were. Independent global actors must each do their part correctly and for the good of the whole except all of them are motivated differently. The problem with a system controlled by no one and everyone is the old adage, what's best for me is what's best. This! Mannotkind is the biggest threat to the system. And so it will always be vulnerable. Title: Re: Blockchain split of 4 July 2015 Post by: oblivi on July 06, 2015, 05:44:51 PM I wonder why miners don't pay more attention to this. Im assuming they want the best for Bitcoin, so why can't they just predict this from happening and take action? I can't be that difficult to pay attention to the hashrate distribution. That is a pretty bad assumption. You should assume that miners are in it for the money. Sure there are some miners that mine to help the network, but really, right now the largest miners exist because of the financial incentives. They do everything they can to make the most money, which includes cutting corners. And sometimes cutting corners has big risks and can cause problems for other people.Everyone knows miners are in for the money, but if they don't act right, soon they could be mining a valueless coin because they fucked up, something no one here wants, not if you are a dev, not if you are a miner, and not if you are a regular user. Title: Re: Blockchain split of 4 July 2015 Post by: JorgeStolfi on July 06, 2015, 06:49:11 PM So basically, we should wait for the transactions to get a confirmation other than from Antpool or f2pool to safely get the bitcoins in the wallet? If Antpool and/or f2pool finds blocks in a chain its not safe anymore? Did someone actually get a loss from this incident? Some pools apparently monitor other pools and "steal" the hash of their last mined block even before the block has propagated to the relay nodes. Since they don't have the block, not even the header, they cannot validate it immediately as they start mining on top of it. I have read that those two pools and also BTC-China use this trick. I don't know whether others do the same, but since it gives them several seconds of advantage in the race for the next block, we must assume that every miner will do it if they can. And the shortcut usually works; it failed this time only because of the version switch. Therefore, the miners will not stop doing that, in spite of having lost 9 block rewards altogether (half of which they would have lost anyway). Title: Re: Blockchain split of 4 July 2015 Post by: JorgeStolfi on July 06, 2015, 06:53:35 PM The market has proven to be self correcting. When GHash got 49%, action was taken, now its down to 10% or something. IIRC, GHash actually got more than 50%. The community can be sure that they got down to 10% by turning off 80% of their equipment, all for the good of the community. They would never think of moving that equipment to other pools. [/sarcasm] Title: Re: Blockchain split of 4 July 2015 Post by: tl121 on July 06, 2015, 07:10:45 PM Let's see if the miscreant pool operators are suitably punished for their incompetent and/or dishonest behavior. A suitable punishment would be for minors to remove sufficient hash power from these pools that they cease to be major players.
Title: Re: Blockchain split of 4 July 2015 Post by: acid_rain on July 06, 2015, 07:19:47 PM This is ridiculous. I think people are ignoring the fact that 30 confirmations is freakin 12 hours. What a coincidence right? So everyone was talking about forks last week, and now there are rogues and new chains being built.
People make stuff up, and then someone takes the hint and makes it reality. People are so oblivious to what's happening right under their noses. Title: Re: Blockchain split of 4 July 2015 Post by: adaseb on July 06, 2015, 07:21:27 PM For some reason I didn't get my Westhash mining payout today? Was suppose to get it 3 hours ago and I check the trans IX and it says 0 confirmations in the last 3 hours. What is going on?
Title: Re: Blockchain split of 4 July 2015 Post by: acid_rain on July 06, 2015, 07:22:34 PM BTC has gone rogue. CFR has taken over biatch. '
While this will only inflate the price even more, legit businesses are hurting man. Title: Re: Blockchain split of 4 July 2015 Post by: Cryddit on July 06, 2015, 07:46:35 PM On a different note, here's one proposed solution for SPV nodes that does not require us to wait for 30 confirmations. Please comment on its correctness. You are proposing is to modify the client so that it would do what a full node would do, only truncated to that last 50 nodes. Just checking the version tag is not enough. This hacked client app must also know that the BIP66 rule became active at a certain block b_{n}. Otherwise it would have to keep fetching blocks until it finds a "95% majority" event, or reaches a block before the v3 software was published. It's true. To determine the place in the last-thousand-blocks rule, you need to download and check the last thousand blocks (not just the last 50). A different consensus-rule could be used that would be amenable to checking over shorter sequences. For example, each block could publish a "current block version" as it does now, _and_ a logarithmic average - with the changeover to occur when the logarithmic average gets within 0.05 of the higher integer version. A logarithmic average at block n would (as an example) be 999/1000 of the logarithmic average at the previous block, plus 1/1000 of the current block version. Using a logarithmic average rather than a computed-over-the-last-thousand average would mean you could check and make sure the logarithmic average is right without looking more than one block into the past. Title: Re: Blockchain split of 4 July 2015 Post by: Cryddit on July 06, 2015, 07:49:30 PM I don't see a way of checking that the miners even have a copy of the parent block let alone checking that they have verified it without breaking compatibility with all existing mining hardware. Fuck all existing mining hardware. If miners can do this then clearly it isn't correct and needs to be thrown out anyway. Title: Re: Blockchain split of 4 July 2015 Post by: MCHouston on July 06, 2015, 08:11:06 PM This is ridiculous. I think people are ignoring the fact that 30 confirmations is freakin 12 hours. What a coincidence right? So everyone was talking about forks last week, and now there are rogues and new chains being built. People make stuff up, and then someone takes the hint and makes it reality. People are so oblivious to what's happening right under their noses. 5 Hours but close. Title: Re: Blockchain split of 4 July 2015 Post by: l1m3st0n3 on July 06, 2015, 09:56:59 PM This is ridiculous. I think people are ignoring the fact that 30 confirmations is freakin 12 hours. What a coincidence right? So everyone was talking about forks last week, and now there are rogues and new chains being built. People make stuff up, and then someone takes the hint and makes it reality. People are so oblivious to what's happening right under their noses. 5 Hours but close. lol @ 12 hrs. Title: Re: Blockchain split of 4 July 2015 Post by: Mikestang on July 06, 2015, 10:05:57 PM This is ridiculous. I think people are ignoring the fact that 30 confirmations is freakin 12 hours. What a coincidence right? So everyone was talking about forks last week, and now there are rogues and new chains being built. 30 tx (x) ~10 min/tx (/) 60min/hour = 5 hours What coincidence are you alluding to? Sounds to me like you're some sort of conspiracy nut who's bad at math. If you talk bitcoin/blockchain, you talk forks. People have been talking about them since the network first came on line. Back to topic, latest Coindesk article on the fork: http://www.coindesk.com/double-spending-risk-bitcoin-network-fork/ Title: Re: Blockchain split of 4 July 2015 Post by: edonkey on July 07, 2015, 01:34:57 AM The only way to get rid of un-ethical pools, is to vote with your hash (the mining hash ::) ). Already F2pool has lost about 5% of its network hashing power since the fork. If you are a miner, mining on F2pool and looking for an alternative pool, why not consider Slush pool (https://mining.bitcoin.cz/home/). Slush was the first mining pool in 2011, and he is also the creator of SatoshiLabs - the manufacturer of the Trezor hardware wallet. His pool is about 3% of the bitcoin network, why not give him a boost, and some support for the innovations he brought to bitcoin since 2011 ! As a bonus, you will receive a discount for the purchase of a Trezor, just to mine there! +1 for Slush's pool! I bailed on Antpool after the "Fork of July" (just made that up, but I'm probably not the first) and went back to Slush. It's a great pool. Although since it's a little on the small side you have to be OK with some variance. Title: Re: Blockchain split of 4 July 2015 Post by: almightyruler on July 07, 2015, 03:20:49 AM As I understand it, f2pool didn't even have a copy of the block they were mining on top of. All they had was the bare minimum needed to build on top of it. I believe cgminer (and probably others) have supported this trick for some time: if a backup pool (that you otherwise never send any work to) signals new block data before your primary, the miner starts work on the new block, even though the primary has not yet acknowledged the block. The implementation of detecting this from one pool to another would differ to that of an end miner, but I guess it's effectively the same thing. Title: Re: Blockchain split of 4 July 2015 Post by: Amitabh S on July 07, 2015, 03:43:05 AM On a different note, here's one proposed solution for SPV nodes that does not require us to wait for 30 confirmations. Please comment on its correctness. You are proposing is to modify the client so that it would do what a full node would do, only truncated to that last 50 nodes. Just checking the version tag is not enough. This hacked client app must also know that the BIP66 rule became active at a certain block b_{n}. Otherwise it would have to keep fetching blocks until it finds a "95% majority" event, or reaches a block before the v3 software was published. It's true. To determine the place in the last-thousand-blocks rule, you need to download and check the last thousand blocks (not just the last 50). A different consensus-rule could be used that would be amenable to checking over shorter sequences. For example, each block could publish a "current block version" as it does now, _and_ a logarithmic average - with the changeover to occur when the logarithmic average gets within 0.05 of the higher integer version. A logarithmic average at block n would (as an example) be 999/1000 of the logarithmic average at the previous block, plus 1/1000 of the current block version. Using a logarithmic average rather than a computed-over-the-last-thousand average would mean you could check and make sure the logarithmic average is right without looking more than one block into the past. That is too complex. I believe a shortcut is as follows (quoted from another post): On a different note, here's one proposed solution for SPV nodes that does not require us to wait for 30 confirmations. Please comment on its correctness. Let us assume that an "invalid chain" cannot be more than 50 blocks. Step 1. We boot our SPV node "now", several days after the July 4 fork. Step 2. We receive the mth block, say b_m. We ensure that b_m is version 3 block. Step 3. We need to ensure that at least 50 previous blocks before b_m were also correct. We download those blocks (not just the headers). That is blocks b_{m-50}, b_{m-49}... b_{m-1}. Then we ensure that all were version 3, have correct signatures, etc, and correctly validate the next block (via the prevBlockHash). Step 4. We can start counting b_m as a block of a valid chain if above checks pass. Step 5. For any further received blocks, we follow steps 2, 4, 5 (skipping steps 1 and 3), since we have already validated 50 blocks before the "boot" block. Hence we validating only with block b_{m-1} is sufficient. You are proposing is to modify the client so that it would do what a full node would do, only truncated to that last 50 nodes. Just checking the version tag is not enough. This hacked client app must also know that the BIP66 rule became active at a certain block b_{n}. Otherwise it would have to keep fetching blocks until it finds a "95% majority" event, or reaches a block before the v3 software was published. I agree, we need a timestamp. Version 3 started from orphaned block 363731 onwards. That block was generated at 2015-07-04 02:09:40. which turns out to be 1435955980000 in Unix time. We ensure that any block with timestamp greater than above is checked using the above logic with appropriate modification (example, v3 check in previous blocks stops at block 363730). This is still cheaper than running a full node. This is "mixed mode" operating as SPV but bootstrapping using the previous 50 blocks (stopping at block 363730). Title: Re: Blockchain split of 4 July 2015 Post by: yeponlyone on July 07, 2015, 04:48:43 AM Is something up today also....?
I made two outgoing transactions some two hours ago, and not a single confirmation. Here's one of them https://blockchain.info/tx/a7605fd21983365f62eee7bc547f4d25c4dfdb7e172866d639665a883439a587 (https://blockchain.info/tx/a7605fd21983365f62eee7bc547f4d25c4dfdb7e172866d639665a883439a587) Title: Re: Blockchain split of 4 July 2015 Post by: Mikestang on July 07, 2015, 05:00:08 AM Is something up today also....? I made two outgoing transactions some two hours ago, and not a single confirmation. Here's one of them https://blockchain.info/tx/a7605fd21983365f62eee7bc547f4d25c4dfdb7e172866d639665a883439a587 (https://blockchain.info/tx/a7605fd21983365f62eee7bc547f4d25c4dfdb7e172866d639665a883439a587) Lower fee tx are getting pushed to the back of the line, but regular fee are moving along just fine. All the backlogged tx are low fee. https://bitcointalk.org/index.php?topic=1111811.0 Title: Re: Blockchain split of 4 July 2015 Post by: yeponlyone on July 07, 2015, 05:13:46 AM Thanks for the swift replies. :) Both transactions are getting confirmations now.
Title: Re: WARNING: blockchain split Post by: goku90504 on July 07, 2015, 05:40:06 AM If your running any web based wallet I would not trust any incoming transactions with less then 20 confirmations. Because they could be orphaned by the network. Chines farms are spitting out a lot of trash these days in the hope they will make more money. They don't have the bandwidth to send out even 1mb blocks. what is Chines farms do you mean Chinese? Title: Re: WARNING: blockchain split Post by: goku90504 on July 07, 2015, 05:54:28 AM Can someone explain why 0.9 bitcoind are not safe to use ? Won't they also catch up to the longest chain later ? They allow invalid blocks.So, if you have 2 chains one with invalid blocks and one without. Bitcoin Core 0.9 would chose the longest block as the right one. Bitcoin Core 0.10.2 would just ignore the chain with the invalid blocks. Bitcoin always choses blockchain with the most work done (sum of all hashes that were used to create blocks, since genesis block) which is not neccessarily the longest blockchain. Title: Re: WARNING: blockchain split Post by: goku90504 on July 07, 2015, 06:16:20 AM Is there a way to force those spv mining to have their work count as less to discourage it? sort of their work is invalidated if they build on a bad block meaning for that case it counts as 0 nada zip zilch if they build on a good block then there is no way to tell the difference between spv mining and regular mining from the outside Title: Re: Blockchain split of 4 July 2015 Post by: goku90504 on July 07, 2015, 06:39:41 AM Did blockchain.info updated their stuff? If not then please PM me when they do i need to send a transaction, but i`m scared to do it at the moment. Also do bitcoin in safe storage compromized? I mean do i have to create a new address, are private keys compromized because of this? no no no there is no stolen information the problems are all for people receiving BTC on older or light security wallets and it doesn't even say that it compromises the wallet it might compromise the individual transaction you received Title: Re: Blockchain split of 4 July 2015 Post by: goku90504 on July 07, 2015, 06:47:32 AM Did blockchain.info updated their stuff? If not then please PM me when they do i need to send a transaction, but i`m scared to do it at the moment. Also do bitcoin in safe storage compromized? I mean do i have to create a new address, are private keys compromized because of this? Its safe to send. If anything its the receiver that needs to wait for 30+ confirmations to ensure that he will retain the bitcoin. Only the guy who controls the private keys of the address can double spend right? Also excuse me for my noobness, but i`m not a tech person. How is it safe to send when blockchain.info hasnt updated their client, what if they send that bitcoin to the wrong blockchain, those coins are lost then arent they? ;D no the coins are not a physical object that land on one side of the other that can be lost when one side takes the dump they are a logical object the chain only records change in ownership so if its sent to the wrong chain the coin comes back to the sender when that chain takes a dump Title: Re: Blockchain split of 4 July 2015 Post by: S4VV4S on July 07, 2015, 06:50:28 AM Did blockchain.info updated their stuff? If not then please PM me when they do i need to send a transaction, but i`m scared to do it at the moment. Also do bitcoin in safe storage compromized? I mean do i have to create a new address, are private keys compromized because of this? no no no there is no stolen information the problems are all for people receiving BTC on older or light security wallets and it doesn't even say that it compromises the wallet it might compromise the individual transaction you received I am a Bitcoin Core user myself, never needed something "lighter", however I need to ask: Do (any) SPV wallets have an alert system similar to Bitcoin Core to warn users? And if not, then why not? Also, edit all your posts in one, otherwise you might get banned by a mod. Just a heads up ;) Title: Re: Blockchain split of 4 July 2015 Post by: SebastianJu on July 07, 2015, 08:02:58 AM Is something up today also....? I made two outgoing transactions some two hours ago, and not a single confirmation. Here's one of them https://blockchain.info/tx/a7605fd21983365f62eee7bc547f4d25c4dfdb7e172866d639665a883439a587 (https://blockchain.info/tx/a7605fd21983365f62eee7bc547f4d25c4dfdb7e172866d639665a883439a587) As you can see from Blockchain.info - their is a stress test going on - most blocks are close to 1MB in size. You put only 0.0001 BTC as fees - so just wait until your cheap transaction gets selected by the miners... These stress tests are annoying. They will proceed until they showed what they wanted to show it seems. ::) Title: Re: Blockchain split of 4 July 2015 Post by: S4VV4S on July 07, 2015, 08:13:41 AM Is something up today also....? I made two outgoing transactions some two hours ago, and not a single confirmation. Here's one of them https://blockchain.info/tx/a7605fd21983365f62eee7bc547f4d25c4dfdb7e172866d639665a883439a587 (https://blockchain.info/tx/a7605fd21983365f62eee7bc547f4d25c4dfdb7e172866d639665a883439a587) As you can see from Blockchain.info - their is a stress test going on - most blocks are close to 1MB in size. You put only 0.0001 BTC as fees - so just wait until your cheap transaction gets selected by the miners... These stress tests are annoying. They will proceed until they showed what they wanted to show it seems. ::) Yes, but as mentioned before they are useful as to know how much the network can handle. Obviously it needs more stressing than that ;) But it's good to know the "limits". Don't you think? On another note, I think the "fork of July" was more stressing than the stress test. Title: Re: Blockchain split of 4 July 2015 Post by: SebastianJu on July 07, 2015, 08:28:22 AM Is something up today also....? I made two outgoing transactions some two hours ago, and not a single confirmation. Here's one of them https://blockchain.info/tx/a7605fd21983365f62eee7bc547f4d25c4dfdb7e172866d639665a883439a587 (https://blockchain.info/tx/a7605fd21983365f62eee7bc547f4d25c4dfdb7e172866d639665a883439a587) As you can see from Blockchain.info - their is a stress test going on - most blocks are close to 1MB in size. You put only 0.0001 BTC as fees - so just wait until your cheap transaction gets selected by the miners... These stress tests are annoying. They will proceed until they showed what they wanted to show it seems. ::) Yes, but as mentioned before they are useful as to know how much the network can handle. Obviously it needs more stressing than that ;) But it's good to know the "limits". Don't you think? On another note, I think the "fork of July" was more stressing than the stress test. Im not so sure if the fork was more stressing since there were no real bad results from it. I guess most bitcoiners didnt even notice the fork. Though the stresstest holds off the innerts of a currency. The free flow. I think its an interesting thing happening but they test it on THE currency. Not on testnet or something. (Yeah, testnet is not far enough developed.) Title: Re: Blockchain split of 4 July 2015 Post by: relativo on July 07, 2015, 09:46:03 AM Be careful
Title: Re: Blockchain split of 4 July 2015 Post by: Bonio on July 07, 2015, 10:00:33 AM Why is this taking so long to resolve?
Surely it is in the mining pools interest to fall into line? Or is there something more sinister going on? Re stress testing I suppose it needs to be done isnt bitcoin still classed as beta or am I missing the point? Title: Re: Blockchain split of 4 July 2015 Post by: turvarya on July 07, 2015, 10:16:21 AM Why is this taking so long to resolve? It actually was resolved pretty fast. (6 blocks ~ 1h)Surely it is in the mining pools interest to fall into line? Or is there something more sinister going on? Re stress testing I suppose it needs to be done isnt bitcoin still classed as beta or am I missing the point? I guess the news at the top of the forum, is just a reminder that you should update your client. Theoretically this could happen again(I highlty doubt it, since pools/miners already lost money) and the only prevention is to use a up-to-date client(or connect to an up-to-date node) Title: Re: Blockchain split of 4 July 2015 Post by: Bonio on July 07, 2015, 10:42:21 AM Ah right thanks for the info, I just presumed as it was on the forum and still mentioned at Redit that it was ongoing ;D
Title: Re: Blockchain split of 4 July 2015 Post by: turvarya on July 07, 2015, 10:56:55 AM Ah right thanks for the info, I just presumed as it was on the forum and still mentioned at Redit that it was ongoing ;D Could you give me a link to Reddit, where people claiming, that it is still ongoing(I am hardly ever on Reddit, I don't even have an account there)?Maybe I am missing something. Title: Re: Blockchain split of 4 July 2015 Post by: Amitabh S on July 07, 2015, 10:57:20 AM Why is this taking so long to resolve? It actually was resolved pretty fast. (6 blocks ~ 1h)Surely it is in the mining pools interest to fall into line? Or is there something more sinister going on? Re stress testing I suppose it needs to be done isnt bitcoin still classed as beta or am I missing the point? I guess the news at the top of the forum, is just a reminder that you should update your client. Theoretically this could happen again(I highlty doubt it, since pools/miners already lost money) and the only prevention is to use a up-to-date client(or connect to an up-to-date node) It is clearly not resolved. Look at the forum header and you will see. Things are not "back to normal" if you have to wait for ~30 confirmation on many clients. This is ongoing as of now until the above warning is removed. Title: Re: Blockchain split of 4 July 2015 Post by: RealBitcoin on July 07, 2015, 11:04:41 AM Why is this taking so long to resolve? It actually was resolved pretty fast. (6 blocks ~ 1h)Surely it is in the mining pools interest to fall into line? Or is there something more sinister going on? Re stress testing I suppose it needs to be done isnt bitcoin still classed as beta or am I missing the point? I guess the news at the top of the forum, is just a reminder that you should update your client. Theoretically this could happen again(I highlty doubt it, since pools/miners already lost money) and the only prevention is to use a up-to-date client(or connect to an up-to-date node) It is clearly not resolved. Look at the forum header and you will see. Things are not "back to normal" if you have to wait for ~30 confirmation on many clients. This is ongoing as of now until the above warning is removed. Ok but this only is concerning to p2p transactions isnt it? I mean if i get bitcoins from a trusted source, then what does it matter if they have 3 confirm or 30 confirm. For example if i buy bitcoin from coinbase, then obviously then wont double spend me neither with 2 confirm nor with 10 or 30 confirm. This is only if i am doing business with a stranger right? So if i trade face to face with a stranger on the streets, for example 1 kilogram of lemons in exchange for 0.05 BTC, then if i go away after 10 confirm, he can still double-cross me and double spend the TX. So i guess this entire "crisis" is only concerning to face-2-face trading and transactions, but not if you get your coins from trusted source right? Title: Re: Blockchain split of 4 July 2015 Post by: turvarya on July 07, 2015, 11:13:06 AM Why is this taking so long to resolve? It actually was resolved pretty fast. (6 blocks ~ 1h)Surely it is in the mining pools interest to fall into line? Or is there something more sinister going on? Re stress testing I suppose it needs to be done isnt bitcoin still classed as beta or am I missing the point? I guess the news at the top of the forum, is just a reminder that you should update your client. Theoretically this could happen again(I highlty doubt it, since pools/miners already lost money) and the only prevention is to use a up-to-date client(or connect to an up-to-date node) It is clearly not resolved. Look at the forum header and you will see. Things are not "back to normal" if you have to wait for ~30 confirmation on many clients. This is ongoing as of now until the above warning is removed. So, miners are stupid enough to still lose money. Sorry, I assumed, they were smarter. @RealBitcoin There is no reported double-spend. From the way, I understand Bitcoin a double spend is still very hard to execute. So, no lemon merchant has the resources to do that. And yes, I would trust coinbase. Title: Re: Blockchain split of 4 July 2015 Post by: RealBitcoin on July 07, 2015, 11:22:55 AM Why is this taking so long to resolve? It actually was resolved pretty fast. (6 blocks ~ 1h)Surely it is in the mining pools interest to fall into line? Or is there something more sinister going on? Re stress testing I suppose it needs to be done isnt bitcoin still classed as beta or am I missing the point? I guess the news at the top of the forum, is just a reminder that you should update your client. Theoretically this could happen again(I highlty doubt it, since pools/miners already lost money) and the only prevention is to use a up-to-date client(or connect to an up-to-date node) It is clearly not resolved. Look at the forum header and you will see. Things are not "back to normal" if you have to wait for ~30 confirmation on many clients. This is ongoing as of now until the above warning is removed. So, miners are stupid enough to still lose money. Sorry, I assumed, they were smarter. @RealBitcoin There is no reported double-spend. From the way, I understand Bitcoin a double spend is still very hard to execute. So, no lemon merchant has the resources to do that. And yes, I would trust coinbase. Yes its obvious that its not the merchant is the one that will scam people here. But it was a bit exxagerated in my view, because nothing is affected except trading with strangers. So if the 99% of the bitcoin users only use trustable companies to trade bitcoin with then nothing happens. Of course when you do an escrow deal or similar with a stranger, then you need to wait that 30 confirm, but other than that, this crisis doesnt look serious at all. I hope that the current core client is stable, i`ll wait a few more weeks until i upgrade :) Title: Re: Blockchain split of 4 July 2015 Post by: SebastianJu on July 07, 2015, 12:00:27 PM Why is this taking so long to resolve? It actually was resolved pretty fast. (6 blocks ~ 1h)Surely it is in the mining pools interest to fall into line? Or is there something more sinister going on? Re stress testing I suppose it needs to be done isnt bitcoin still classed as beta or am I missing the point? I guess the news at the top of the forum, is just a reminder that you should update your client. Theoretically this could happen again(I highlty doubt it, since pools/miners already lost money) and the only prevention is to use a up-to-date client(or connect to an up-to-date node) It is clearly not resolved. Look at the forum header and you will see. Things are not "back to normal" if you have to wait for ~30 confirmation on many clients. This is ongoing as of now until the above warning is removed. So, miners are stupid enough to still lose money. Sorry, I assumed, they were smarter. So this happened twice now in a row? Oo When what is said is correct in this thread then couldnt that be used to attack bitcoin and lower the price of bitcoin? I mean presenting wrong hashes to these pools and letting them create a fork? I guess there is some failsaife built in as to which pools they watch but most probably they watch small ones too and someone could decide that he could earn some coins by shorting them with leverage and then starting the next fork? Title: Re: Blockchain split of 4 July 2015 Post by: Darkmatter12 on July 07, 2015, 06:26:26 PM Is blockchain web wallet safe?
Title: Re: Blockchain split of 4 July 2015 Post by: pereira4 on July 07, 2015, 09:01:20 PM Why is this taking so long to resolve? It actually was resolved pretty fast. (6 blocks ~ 1h)Surely it is in the mining pools interest to fall into line? Or is there something more sinister going on? Re stress testing I suppose it needs to be done isnt bitcoin still classed as beta or am I missing the point? I guess the news at the top of the forum, is just a reminder that you should update your client. Theoretically this could happen again(I highlty doubt it, since pools/miners already lost money) and the only prevention is to use a up-to-date client(or connect to an up-to-date node) It is clearly not resolved. Look at the forum header and you will see. Things are not "back to normal" if you have to wait for ~30 confirmation on many clients. This is ongoing as of now until the above warning is removed. So, miners are stupid enough to still lose money. Sorry, I assumed, they were smarter. So this happened twice now in a row? Oo When what is said is correct in this thread then couldnt that be used to attack bitcoin and lower the price of bitcoin? I mean presenting wrong hashes to these pools and letting them create a fork? I guess there is some failsaife built in as to which pools they watch but most probably they watch small ones too and someone could decide that he could earn some coins by shorting them with leverage and then starting the next fork? Further proof that we aren't ready for mass adoption. Glad I always stuck with Core, but feel really bad for anyone affected by this. 30 confirmations is a ton of time. I hope no one lost money somehow with this if you can lose money in this situation (some transaction getting stuck or something, or being precessed into the other blockchain). This sounds pretty messy to me. Title: Re: Blockchain split of 4 July 2015 Post by: SebastianJu on July 07, 2015, 09:41:07 PM Why is this taking so long to resolve? It actually was resolved pretty fast. (6 blocks ~ 1h)Surely it is in the mining pools interest to fall into line? Or is there something more sinister going on? Re stress testing I suppose it needs to be done isnt bitcoin still classed as beta or am I missing the point? I guess the news at the top of the forum, is just a reminder that you should update your client. Theoretically this could happen again(I highlty doubt it, since pools/miners already lost money) and the only prevention is to use a up-to-date client(or connect to an up-to-date node) It is clearly not resolved. Look at the forum header and you will see. Things are not "back to normal" if you have to wait for ~30 confirmation on many clients. This is ongoing as of now until the above warning is removed. So, miners are stupid enough to still lose money. Sorry, I assumed, they were smarter. So this happened twice now in a row? Oo When what is said is correct in this thread then couldnt that be used to attack bitcoin and lower the price of bitcoin? I mean presenting wrong hashes to these pools and letting them create a fork? I guess there is some failsaife built in as to which pools they watch but most probably they watch small ones too and someone could decide that he could earn some coins by shorting them with leverage and then starting the next fork? Further proof that we aren't ready for mass adoption. Glad I always stuck with Core, but feel really bad for anyone affected by this. 30 confirmations is a ton of time. I hope no one lost money somehow with this if you can lose money in this situation (some transaction getting stuck or something, or being precessed into the other blockchain). This sounds pretty messy to me. Still. Im impressed that happened 2 times in a couple days. And the first time on the worldwide known independence day in america? Im not into conspiracy theories but the randomness is interesting at least. Nothing for years and then, at this day. Oo Title: Re: Blockchain split of 4 July 2015 Post by: JorgeStolfi on July 07, 2015, 09:49:58 PM Why is this taking so long to resolve? It actually was resolved pretty fast. (6 blocks ~ 1h)There was a second incident on July 5th, with a 3-block orphan branch. There are still v2 miners out there, and the v3 miners are still accepting recent block hashes from them, and mining new blocks on top of them before they have time to validate (or even see) those parent. The fork was blotched. Title: Re: Blockchain split of 4 July 2015 Post by: luthermarcus on July 07, 2015, 11:21:48 PM Why is this taking so long to resolve? It actually was resolved pretty fast. (6 blocks ~ 1h)There was a second incident on July 5th, with a 3-block orphan branch. There are still v2 miners out there, and the v3 miners are still accepting recent block hashes from them, and mining new blocks on top of them before they have time to validate (or even see) those parent. The fork was blotched. Could you explain this further, I thought bitcoin 10 or above would block v2 blocks from being accepted. So what your saying those blocks are still finding a way on this side of the forked blockchain. Like f2pool i know they fucked up and did something like that but i thought it was isolated event which was fixed. Would this bog bitcoin core down it's been stalling a lot from what miners are saying. I think bitcoin core should be more efficient at blocking those left behind without the extra resources (cpu and ram) to effectively block them. Please criticize my recollection of what is happening that's the only way i will learn about this in more depth. Title: Re: Blockchain split of 4 July 2015 Post by: hokus_pokus on July 07, 2015, 11:35:02 PM Happy backlog day! :-X
https://bitcoinmagazine.com/21125/bitcoin-network-still-backlogged-tens-thousands-unconfirmed-transactions-causing-delays/ Title: Re: Blockchain split of 4 July 2015 Post by: notbatman on July 07, 2015, 11:40:51 PM I made a couple of transactions yesterday, they both confirmed in about 5 min. I'd say make sure you include a healthy transaction fee.
As far as mining goes I had some issues between June 16th and 28th but no problems after that (upgraded p2pool to v14). I didn't even know there was an issue on the 4th until I read the posts here. Title: Re: Blockchain split of 4 July 2015 Post by: J.Socal on July 08, 2015, 12:02:27 AM using .10.2 btc core.Been 4hrs and not 1 confirmation yet..Normally takes 10min max for a confirmation.
Title: Re: Blockchain split of 4 July 2015 Post by: newIndia on July 08, 2015, 12:05:27 AM using .10.2 btc core.Been 4hrs and not 1 confirmation yet..Normally takes 10min max for a confirmation. It is not about what version you are using. It is about how much mining fee you are offering against what size of the Tx. If you could share the Tx ID, we can see more details into it. Title: Re: Blockchain split of 4 July 2015 Post by: luthermarcus on July 08, 2015, 12:14:06 AM using .10.2 btc core.Been 4hrs and not 1 confirmation yet..Normally takes 10min max for a confirmation. It is not about what version you are using. It is about how much mining fee you are offering against what size of the Tx. If you could share the Tx ID, we can see more details into it. The whole system is going through a stress test so it's bogged down but sure offering higher fee will git it priority wow exchanges with there high traffic are definitely feeling the impact. Title: Re: Blockchain split of 4 July 2015 Post by: JorgeStolfi on July 08, 2015, 12:21:17 AM Why is this taking so long to resolve? It actually was resolved pretty fast. (6 blocks ~ 1h)There was a second incident on July 5th, with a 3-block orphan branch. There are still v2 miners out there, and the v3 miners are still accepting recent block hashes from them, and mining new blocks on top of them before they have time to validate (or even see) those parent. The fork was blotched. Could you explain this further I am not an expert, I am just learning from what is posted on forums, too. But basically mining pools have a way to "steal" the hash of newly mined blocks from each other, even before those blocks get out to the relay nodes. They must immediately start to mine a new block Y with the stolen block X as the parent, without waiting for X to propagate out to the relay nodes, otherwise the pool that mined X will have many seconds of head start. If they are lucky, they will solve block Y even before the block X has finished propagating to the nodes and the nodes have validated it. Those miners do validate the transactions that they put into block Y (in parallel with mining it), but they cannot start validating block X, or even check whether it was mined by a v3 miner, because they only have the hash of block X, nothing else. Apparently they used to fetch and check block X, also in parallel with mining, once it became available; but F2Pool had stopped doing so, because (they said) it had cost them a block reward once (perhaps by using up some of their internet bandwidth). Usually this shortcut works, because the block X was verified by its miner, and is valid 99.99% of the time. Hoever, just after the BIP66 rule became active, the miner BTCNuggets, that was still running v2 software, happened to mine the next block X. The BTC-China pool stole its hash from BTCNuggets, and F2Pool stole it from BTC-China. F2Pool (who had upgraded to v3) mined a new block Y on top of X, without realizing that X was invalid because it was mined with v2 rules. Then F2Pool mined another block Z on top of it, and AntPool mined another one on top of Z, and so on -- all without realizing that X was invalid. Title: Re: Blockchain split of 4 July 2015 Post by: luthermarcus on July 08, 2015, 12:51:36 AM Why is this taking so long to resolve? It actually was resolved pretty fast. (6 blocks ~ 1h)There was a second incident on July 5th, with a 3-block orphan branch. There are still v2 miners out there, and the v3 miners are still accepting recent block hashes from them, and mining new blocks on top of them before they have time to validate (or even see) those parent. The fork was blotched. Could you explain this further I am not an expert, I am just learning from what is posted on forums, too. But basically mining pools have a way to "steal" the hash of newly mined blocks from each other, even before those blocks get out to the relay nodes. They must immediately start to mine a new block Y with the stolen block X as the parent, without waiting for X to propagate out to the relay nodes, otherwise the pool that mined X will have many seconds of head start. If they are lucky, they will solve block Y even before the block X has finished propagating to the nodes and the nodes have validated it. Those miners do validate the transactions that they put into block Y (in parallel with mining it), but they cannot start validating block X, or even check whether it was mined by a v3 miner, because they only have the hash of block X, nothing else. Apparently they used to fetch and check block X, also in parallel with mining, once it became available; but F2Pool had stopped doing so, because (they said) it had cost them a block reward once (perhaps by using up some of their internet bandwidth). Usually this shortcut works, because the block X was verified by its miner, and is valid 99.99% of the time. Hoever, just after the BIP66 rule became active, the miner BTCNuggets, that was still running v2 software, happened to mine the next block X. The BTC-China pool stole its hash from BTCNuggets, and F2Pool stole it from BTC-China. F2Pool (who had upgraded to v3) mined a new block Y on top of X, without realizing that X was invalid because it was mined with v2 rules. Then F2Pool mined another block Z on top of it, and AntPool mined another one on top of Z, and so on -- all without realizing that X was invalid. I pretty much understand that instead of using bitcoin core they used an alternative SPV nodes which doesnt check the whole block chain, were not denying v2 blocks invalid when BIPP66 protocol went into effect but is faster to run to give them an edge. Doing so they were mining v2 and v3 blocks and accepting both because it took a while for them to get denied by the network. They should have know that they were going to loss the v2 blocks so it could have been greed even thought it meant bogging down the whole network. Even thought it was counter productive becuase v2 blocks were worthless. The current issues people are having are with the stress test and some transactions that are still kicking around from people who haven't upgraded there nodes or pools that haven't upgraded. All together it's having a bogged down effect felt with transactions being slow as well as miners processing worthless transactions from the test and maybe from invalid v2 blocks kicking around.The problem will resolve itself it just will take time to clear up all the junk and while miners and pool and node owners update. It's really not that big of a problem just it was last minute which they should have warned miners and pool owners in advance because they took profit hits. Big pools like f2pool and ant-pool are at fault themselves because they should be aware of stuff like this because the centralize and made a business out of it unlike small miners who have a full time job and do it as a hobby. http://www.p2pool.org/ (http://www.p2pool.org/) P2pool and forestv were on top of things for there community releasing updates ahead of time and not getting paid to do so if he could do that there is no excuse for big time pools. Support decentralized and get paid more no fees and no one taking a cut of your hashpower. But you have to make sure you stay up to date with your node. Easiest way to get started on windows and linux https://bitcointalk.org/index.php?topic=18313.0 (https://bitcointalk.org/index.php?topic=18313.0) Title: Re: Blockchain split of 4 July 2015 Post by: J.Socal on July 08, 2015, 02:36:23 AM 7 hrs still on 0..I made about the same amount transaction yesterday and got a confirmation in 10-15 mins.So I doubt its the fee..
Title: Re: Blockchain split of 4 July 2015 Post by: goku90504 on July 08, 2015, 04:04:50 AM One way to think of this is that a group of Chinese miners just gave over $50K away to other miners, to reward those other miners for checking the block versions before building new blocks. that's not what happened the 50k he Chinese miners made wasn't given to anyone else they were unmade while the other miners got exactly their normal prize with less competition because the Chinese were mining invalid blocks Terribly nice of them, really. Though I'm sure they'd prefer to've collected the prize themselves, it's nice of them to "support" those who are doing a better job than they are. So, for a few hours, if you were mining and actually checking blocks for validity, you were getting about double your usual rate of return. "SPV mining" is one of those silly ideas like "virtual memory" or "virtual sex" - the real thing is always better. Title: Re: Blockchain split of 4 July 2015 Post by: J.Socal on July 08, 2015, 05:45:57 AM Good news, finally got confirmation..Hopefully gets back to normal soon.
Title: Re: Blockchain split of 4 July 2015 Post by: cesmak on July 08, 2015, 05:55:56 AM I have a stuck transaction too from my bitcoin core 10.2 wallet by more than 13 hours....
I've used the sugested bitcoin core fees, but no confirmations.... https://blockchain.info/tx/718f24fcc03cd5ccaed7f316e40101c53fcc6609775864b1b624df69d9f4b96e?show_adv=true Someone expert can help me ? Title: Re: Blockchain split of 4 July 2015 Post by: BIT-Sharon on July 08, 2015, 06:18:54 AM Does it mean that the safety of Bitcoin chain is not good again?
Title: Re: Blockchain split of 4 July 2015 Post by: Mayer Amschel on July 08, 2015, 06:41:25 AM Fuck this Blockchain man, i choose Blocktrail over this crap.
:-[ Title: Re: Blockchain split of 4 July 2015 Post by: orryde on July 08, 2015, 06:49:39 AM My wallet https://blockchain.info/address/15B9e7LeCTdKhRdjtTroi12DmamYgYWino still get "Unconfirmed Transaction" a few hours ago there is any problem with Blockhain?
Title: Re: Blockchain split of 4 July 2015 Post by: Jeremycoin on July 08, 2015, 07:21:18 AM My wallet https://blockchain.info/address/15B9e7LeCTdKhRdjtTroi12DmamYgYWino still get "Unconfirmed Transaction" a few hours ago there is any problem with Blockhain? It also happens to some people, so I think there is a problem with te Blockchain.But I hope it'll be fixed ASAP Title: Re: Blockchain split of 4 July 2015 Post by: Borisz on July 08, 2015, 09:45:16 AM My wallet https://blockchain.info/address/15B9e7LeCTdKhRdjtTroi12DmamYgYWino still get "Unconfirmed Transaction" a few hours ago there is any problem with Blockhain? It also happens to some people, so I think there is a problem with te Blockchain.But I hope it'll be fixed ASAP I have a stuck transaction too from my bitcoin core 10.2 wallet by more than 13 hours.... I've used the sugested bitcoin core fees, but no confirmations.... https://blockchain.info/tx/718f24fcc03cd5ccaed7f316e40101c53fcc6609775864b1b624df69d9f4b96e?show_adv=true Someone expert can help me ? Could both of these issues have something to do with the unusually large number of transactions per blocks in the last few days? https://blockchain.info/charts/n-transactions-per-block (https://blockchain.info/charts/n-transactions-per-block) Title: Re: Blockchain split of 4 July 2015 Post by: cesmak on July 08, 2015, 09:50:09 AM My wallet https://blockchain.info/address/15B9e7LeCTdKhRdjtTroi12DmamYgYWino still get "Unconfirmed Transaction" a few hours ago there is any problem with Blockhain? It also happens to some people, so I think there is a problem with te Blockchain.But I hope it'll be fixed ASAP I have a stuck transaction too from my bitcoin core 10.2 wallet by more than 13 hours.... I've used the sugested bitcoin core fees, but no confirmations.... https://blockchain.info/tx/718f24fcc03cd5ccaed7f316e40101c53fcc6609775864b1b624df69d9f4b96e?show_adv=true Someone expert can help me ? Could both of these issues have something to do with the unusually large number of transactions per blocks in the last few days? https://blockchain.info/charts/n-transactions-per-block (https://blockchain.info/charts/n-transactions-per-block) Ok a big jump in number of transactions, but, my transaction, now, is stuck with no confirmation by 18 hours, i think it's a huge ammount of time.... too much.... Title: Re: Blockchain split of 4 July 2015 Post by: cesmak on July 08, 2015, 10:21:14 AM My wallet https://blockchain.info/address/15B9e7LeCTdKhRdjtTroi12DmamYgYWino still get "Unconfirmed Transaction" a few hours ago there is any problem with Blockhain? It also happens to some people, so I think there is a problem with te Blockchain.But I hope it'll be fixed ASAP I have a stuck transaction too from my bitcoin core 10.2 wallet by more than 13 hours.... I've used the sugested bitcoin core fees, but no confirmations.... https://blockchain.info/tx/718f24fcc03cd5ccaed7f316e40101c53fcc6609775864b1b624df69d9f4b96e?show_adv=true Someone expert can help me ? Could both of these issues have something to do with the unusually large number of transactions per blocks in the last few days? https://blockchain.info/charts/n-transactions-per-block (https://blockchain.info/charts/n-transactions-per-block) Ok a big jump in number of transactions, but, my transaction, now, is stuck with no confirmation by 18 hours, i think it's a huge ammount of time.... too much.... Just found in the configuration of my wallet that it wasn't active the function to use "the reccomended ammount of fees" but the minimal ammount, so could be that the transaction is low on priority and need more time to be considered in the blockchain.... i will see what happens in the next hours.... Someone know if there is a timeout in the time a transaction is acquired or not ? And in the eventualy case of a timeout if it turn back to my wallet ? I know that bitcoin transaction are irreversible, but if the transaction will never be acquired by the blockchain what happens ? Title: Re: Blockchain split of 4 July 2015 Post by: turvarya on July 08, 2015, 10:32:36 AM My wallet https://blockchain.info/address/15B9e7LeCTdKhRdjtTroi12DmamYgYWino still get "Unconfirmed Transaction" a few hours ago there is any problem with Blockhain? It also happens to some people, so I think there is a problem with te Blockchain.But I hope it'll be fixed ASAP I have a stuck transaction too from my bitcoin core 10.2 wallet by more than 13 hours.... I've used the sugested bitcoin core fees, but no confirmations.... https://blockchain.info/tx/718f24fcc03cd5ccaed7f316e40101c53fcc6609775864b1b624df69d9f4b96e?show_adv=true Someone expert can help me ? Could both of these issues have something to do with the unusually large number of transactions per blocks in the last few days? https://blockchain.info/charts/n-transactions-per-block (https://blockchain.info/charts/n-transactions-per-block) Ok a big jump in number of transactions, but, my transaction, now, is stuck with no confirmation by 18 hours, i think it's a huge ammount of time.... too much.... Just found in the configuration of my wallet that it wasn't active the function to use "the reccomended ammount of fees" but the minimal ammount, so could be that the transaction is low on priority and need more time to be considered in the blockchain.... i will see what happens in the next hours.... Someone know if there is a timeout in the time a transaction is acquired or not ? And in the eventualy case of a timeout if it turn back to my wallet ? I know that bitcoin transaction are irreversible, but if the transaction will never be acquired by the blockchain what happens ? But I am not sure, how much time it needs before a unconfirmed transaction gets deleted. Title: Re: Blockchain split of 4 July 2015 Post by: RealBitcoin on July 08, 2015, 10:54:58 AM My wallet https://blockchain.info/address/15B9e7LeCTdKhRdjtTroi12DmamYgYWino still get "Unconfirmed Transaction" a few hours ago there is any problem with Blockhain? It also happens to some people, so I think there is a problem with te Blockchain.But I hope it'll be fixed ASAP I have a stuck transaction too from my bitcoin core 10.2 wallet by more than 13 hours.... I've used the sugested bitcoin core fees, but no confirmations.... https://blockchain.info/tx/718f24fcc03cd5ccaed7f316e40101c53fcc6609775864b1b624df69d9f4b96e?show_adv=true Someone expert can help me ? Could both of these issues have something to do with the unusually large number of transactions per blocks in the last few days? https://blockchain.info/charts/n-transactions-per-block (https://blockchain.info/charts/n-transactions-per-block) Ok a big jump in number of transactions, but, my transaction, now, is stuck with no confirmation by 18 hours, i think it's a huge ammount of time.... too much.... Just found in the configuration of my wallet that it wasn't active the function to use "the reccomended ammount of fees" but the minimal ammount, so could be that the transaction is low on priority and need more time to be considered in the blockchain.... i will see what happens in the next hours.... Someone know if there is a timeout in the time a transaction is acquired or not ? And in the eventualy case of a timeout if it turn back to my wallet ? I know that bitcoin transaction are irreversible, but if the transaction will never be acquired by the blockchain what happens ? But I am not sure, how much time it needs before a unconfirmed transaction gets deleted. 1 or worst case 2 days. So tell me is it safe to use blockchain.info at the moment? I am just wanting to send a transaction, so please tell me if it is safe Title: Re: Blockchain split of 4 July 2015 Post by: Borisz on July 08, 2015, 11:09:16 AM My wallet https://blockchain.info/address/15B9e7LeCTdKhRdjtTroi12DmamYgYWino still get "Unconfirmed Transaction" a few hours ago there is any problem with Blockhain? It also happens to some people, so I think there is a problem with te Blockchain.But I hope it'll be fixed ASAP I have a stuck transaction too from my bitcoin core 10.2 wallet by more than 13 hours.... I've used the sugested bitcoin core fees, but no confirmations.... https://blockchain.info/tx/718f24fcc03cd5ccaed7f316e40101c53fcc6609775864b1b624df69d9f4b96e?show_adv=true Someone expert can help me ? Could both of these issues have something to do with the unusually large number of transactions per blocks in the last few days? https://blockchain.info/charts/n-transactions-per-block (https://blockchain.info/charts/n-transactions-per-block) Ok a big jump in number of transactions, but, my transaction, now, is stuck with no confirmation by 18 hours, i think it's a huge ammount of time.... too much.... The last time I purchased something a few months ago with BTC I did pay a tx fee, however it still took almost 24 hours for the transaction. It was only a few $ in total. Title: Re: Blockchain split of 4 July 2015 Post by: cesmak on July 08, 2015, 12:00:34 PM My wallet https://blockchain.info/address/15B9e7LeCTdKhRdjtTroi12DmamYgYWino still get "Unconfirmed Transaction" a few hours ago there is any problem with Blockhain? It also happens to some people, so I think there is a problem with te Blockchain.But I hope it'll be fixed ASAP I have a stuck transaction too from my bitcoin core 10.2 wallet by more than 13 hours.... I've used the sugested bitcoin core fees, but no confirmations.... https://blockchain.info/tx/718f24fcc03cd5ccaed7f316e40101c53fcc6609775864b1b624df69d9f4b96e?show_adv=true Someone expert can help me ? Could both of these issues have something to do with the unusually large number of transactions per blocks in the last few days? https://blockchain.info/charts/n-transactions-per-block (https://blockchain.info/charts/n-transactions-per-block) Ok a big jump in number of transactions, but, my transaction, now, is stuck with no confirmation by 18 hours, i think it's a huge ammount of time.... too much.... The last time I purchased something a few months ago with BTC I did pay a tx fee, however it still took almost 24 hours for the transaction. It was only a few $ in total. for me it's the first time a transaction, is in this situation i ever used bitcoin core, from the begin of my adventure in bitcoin, more than two years ago, always paid tx fees, and this is the first time i wait so much time. @realbitcoin (post above...) I can't help you because i had never used blockchain.info wallet service, so i don't know how is the situation for this service... the recomendation written here at the top of this thread is, to wait almost 30 cofirmation if you don't know what wallet orignates a transactions you will receive, for transaction you send, the problem ( to veify that your tx is ok) is to be done by the receiver of the transaction. I can't say any more... Title: Re: Blockchain split of 4 July 2015 Post by: Amitabh S on July 08, 2015, 12:26:47 PM This thread ("blockchain split") has nothing to do with tx confirmation delays. Why is everyone posting it here? There is another thread about tx delays. Use that.
Title: Re: Blockchain split of 4 July 2015 Post by: cesmak on July 08, 2015, 12:44:54 PM This thread ("blockchain split") has nothing to do with tx confirmation delays. Why is everyone posting it here? There is another thread about tx delays. Use that. I started to post here for the tx realy asking if could be related to the fork happened in this days, sorry to perpetuate answering with others posts..... Title: Re: Blockchain split of 4 July 2015 Post by: ZappaLlamaGamma on July 08, 2015, 04:00:05 PM Being relatively new, but very technically proficient, I've learned all that I can. I was mining with AntPool since I bought my first miner, the U3. After knowing about the last fork from reading Digital Gold and knowing now about the three Chinese guys' pools, including the 80s group Wang Chung, I've since moved to a much more reputable pool. The Chinese business model of screw everyone else is not congruent with what Bitcoin is about. Sigh.
Title: Re: Blockchain split of 4 July 2015 Post by: luthermarcus on July 08, 2015, 05:19:36 PM Being relatively new, but very technically proficient, I've learned all that I can. I was mining with AntPool since I bought my first miner, the U3. After knowing about the last fork from reading Digital Gold and knowing now about the three Chinese guys' pools, including the 80s group Wang Chung, I've since moved to a much more reputable pool. The Chinese business model of screw everyone else is not congruent with what Bitcoin is about. Sigh. There should be more people like you antpool (Bitmain) screws it's customers over and has the worst customer service because it doesn't stand by it's word nor it's products 100%. They said they were going to help p2pool, set up a node and implement there miners to be more compatible but it was all hype to get the good graces of some buyers. Title: Re: Blockchain split of 4 July 2015 Post by: luthermarcus on July 08, 2015, 05:23:34 PM This thread ("blockchain split") has nothing to do with tx confirmation delays. Why is everyone posting it here? There is another thread about tx delays. Use that. You should explain why when you make a statement. Above guy means because the current delays are not due 100% to the fork there is a so called "stress test" which is happening which is slowing down transactions.Title: Re: Blockchain split of 4 July 2015 Post by: Mikestang on July 08, 2015, 06:10:45 PM This thread ("blockchain split") has nothing to do with tx confirmation delays. Why is everyone posting it here? There is another thread about tx delays. Use that. You should explain why when you make a statement. Above guy means because the current delays are not due 100% to the fork there is a so called "stress test" which is happening which is slowing down transactions.None of the delays were due to the fork, people posting here about tx fees and delays are posting in the wrong place. Fork is done and over, don't know why this thread still persists. There have been forks in the past, there will be more in the future. Carry on. Title: Re: Blockchain split of 4 July 2015 Post by: achow101 on July 09, 2015, 12:50:18 AM This thread ("blockchain split") has nothing to do with tx confirmation delays. Why is everyone posting it here? There is another thread about tx delays. Use that. You should explain why when you make a statement. Above guy means because the current delays are not due 100% to the fork there is a so called "stress test" which is happening which is slowing down transactions.None of the delays were due to the fork, people posting here about tx fees and delays are posting in the wrong place. Fork is done and over, don't know why this thread still persists. There have been forks in the past, there will be more in the future. Carry on. The delays aren't due to the fork, but since they happened so close together, people are thinking they are the related, when they are actually not related at all. Title: Re: Blockchain split of 4 July 2015 Post by: Cryddit on July 09, 2015, 01:09:04 AM I hesitate to bring this up because people are mistaken about how, but the forks do in fact contribute to delays.
When you've got 50% of the hashing power working on a bad fork, you've only got 50% of the hashing power working on a good fork. While this situation is in effect, you can only form about 50% of the "nominal" number of blocks in the good fork. That leaves only room for 50% of the normal number of transactions and the remainder do in fact start to pile up when they come in faster than the reduced-capacity good block chain can handle. Title: Re: Blockchain split of 4 July 2015 Post by: achow101 on July 09, 2015, 01:31:33 AM I hesitate to bring this up because people are mistaken about how, but the forks do in fact contribute to delays. They do, but right now there is no active fork. There was also no active fork when the delays began, so the fork and the delays are unrelated.When you've got 50% of the hashing power working on a bad fork, you've only got 50% of the hashing power working on a good fork. While this situation is in effect, you can only form about 50% of the "nominal" number of blocks in the good fork. That leaves only room for 50% of the normal number of transactions and the remainder do in fact start to pile up when they come in faster than the reduced-capacity good block chain can handle. Title: Re: Blockchain split of 4 July 2015 Post by: JorgeStolfi on July 09, 2015, 04:16:02 AM I don't think the SPV Miners have confirmed whether they have patched their software to do full validation so the alert remains and the situation persists. I saw a quote by F2Pool - perhaps on this same thread - confirming that they will not do full validation of the parent before mining on top of it. They will however re-enable validation of the parent in parallel, if and when they receive the full block from the relay nodes. What the pools do (probably all of them, because they will be at a clear disadvantage if they didn't) is more radical than "SPV mining". They subscribe incognito as members of other open pools. When some other member of some other pool X mines a block B(N), it will usually tell all its members to start mining B(N+1) on top of B(N), even before sending B(N) out to the relay nodes. To do that, it has to send to all its members the header template of block B(N+1), that includes the hash of block B(N). The pool Y that is spying on X will then take that hash and start mining its own block B'(N+1) on top of B(N). This shortcut is usually quite safe, because pool X must validate the contents of block B(N), and cannot afford to send a false hash to its members, even though it knows that some of them must be spies for the competition. But this trick failed in the "fork of july" because pool X (BTCNuggets) was still running the v2 version of the software, so the block B(N) was invalid under v3 rules. The hash of B(N) was stolen from BTCNuggets by BTC-China, that was running v3 but did not realize that BTCNuggets was v2. Then F2Pool stole the hash of B(N) from BTC-China, and won the race to B(N+1); and the mistake continued for another 4 blocks more. A similar incident happened again on the 5th of July. The pools obviously will not give up on this shortcut, unless some way is found to make it unprofitable. Moreover, whenever pool Y starts mining on top of the stolen hash of a block B(N), it must start mining an empty block B(N+1). Pool Y cannot include any transaction from the queue in B(N+1), because it cannot check whether that transaction was already included in B(N), or tries to spend some UTXO that was spent by another transaction in B(N). Pool Y must wait until it gets the whole of B(N) from the relay nodes, before it can safely add more transactions to B(N+1). But often pool Y solves B(N+1) before that time. That may be the cause of the empty blocks that are often seen after a short interblock interval. Title: Re: Blockchain split of 4 July 2015 Post by: Cryddit on July 09, 2015, 05:50:30 AM The behavior of a normal client when confronted with an invalid block, is to ignore it. It will not relay that block. Therefore, when BTCNuggets comes up with its version=2 block at a moment when the rest of the network is ready to reject version=2 blocks, the 'incognito' node that steals the hash by pretending to be a member of BTCNuggets will hear about it - but the block itself WON'T be relayed through the network to BTC-China, because other network nodes will notice it's invalid and drop it on the floor rather than relaying it. So here's the situation. They want to check "in parallel when the block arrives" but the block won't arrive at all unless the same check, as performed by the relaying node, succeeded! Every second you don't get that block, it becomes more likely that the reason you haven't is because it's invalid. So mining on a hash while waiting for a block is not a plan to maximize profits if it goes on for more than about ten seconds. If you haven't seen the block by about ten seconds after getting the hash, then it's most likely because that block was the Pravda, not the Truth. Nodes that would otherwise have relayed it to you (and everybody else) had a look at it and laughed at the funny joke instead of finding news worth passing along. And what that means is that if you treat the hash as True rather than Pravda, you're going to get taken in along with the other optimists who believed in it - and like them, you will believe you are wealthier than you'll actually be. Title: Re: Blockchain split of 4 July 2015 Post by: JorgeStolfi on July 09, 2015, 07:16:11 AM So here's the situation. They want to check "in parallel when the block arrives" but the block won't arrive at all unless the same check, as performed by the relaying node, succeeded! Every second you don't get that block, it becomes more likely that the reason you haven't is because it's invalid. So mining on a hash while waiting for a block is not a plan to maximize profits if it goes on for more than about ten seconds. If you haven't seen the block by about ten seconds after getting the hash, then it's most likely because that block was the Pravda, not the Truth. Makes sense, and hopefully the miners will improve their strategy as you suggest. Consider telling that to your favorite miner... However, until now that the chance of the parent block being invalid was very small, like 0.01% or less. That must be the reason why they did not bother to check the parent at all... Also, are you sure that the delay is only "seconds"? even when the nodes are struggling with 150'000 transactions in the queue, or 4 x the maximum transaction rate... Title: Re: Blockchain split of 4 July 2015 Post by: birr on July 09, 2015, 02:30:19 PM The current delay in the transactions is due to a spammer (attack) on the Bitcoin network, who sends peaks of 150 transactions per seconds on a network that can handle about 7 only. Title: Re: Blockchain split of 4 July 2015 Post by: lemipawa on July 09, 2015, 02:39:06 PM The current delay in the transactions is due to a spammer (attack) on the Bitcoin network, who sends peaks of 150 transactions per seconds on a network that can handle about 7 only. Title: Re: Blockchain split of 4 July 2015 Post by: BillyBobZorton on July 09, 2015, 02:39:56 PM The current delay in the transactions is due to a spammer (attack) on the Bitcoin network, who sends peaks of 150 transactions per seconds on a network that can handle about 7 only. What did you expect? and why do you think the blocksize debate is a huge one? We need to do something about it, 7 tx per second has been a tiny amount for a while. This was meant to happen sooner or later. Better now than later on when more people would be on board. Hopefully this makes people realize we need changes asap. Title: Re: Blockchain split of 4 July 2015 Post by: turvarya on July 09, 2015, 02:42:24 PM The current delay in the transactions is due to a spammer (attack) on the Bitcoin network, who sends peaks of 150 transactions per seconds on a network that can handle about 7 only. There was someone(it is not know, if it was the same person) trying that some weeks ago and he failed pretty hard. Then he tried it again and failed again and now we have this from maybe the same person or a copycat. So, there is a lot of preparation to that and you need some servers. The whole thing is also not cheap, when it comes to transaction fees. Also keep in mind, that some people are already working on counter-measures. Title: Re: Blockchain split of 4 July 2015 Post by: Arnault59 on July 09, 2015, 04:24:00 PM yes very strange , 59 confirmations but transaction not confirmed yet, never see that.
Title: Re: Blockchain split of 4 July 2015 Post by: SebastianJu on July 09, 2015, 04:58:44 PM yes very strange , 59 confirmations but transaction not confirmed yet, never see that. Confirmations are "confirmed". What do you mean? As long as one confirmation is there then the transaction is confirmed. Title: Re: Blockchain split of 4 July 2015 Post by: Arnault59 on July 09, 2015, 05:34:23 PM yes very strange , 59 confirmations but transaction not confirmed yet, never see that. Confirmations are "confirmed". What do you mean? As long as one confirmation is there then the transaction is confirmed. Sorry I mean "seen by 59 peers", not confirmed edit : seen by 91 peers now, not confirmed Title: Re: Blockchain split of 4 July 2015 Post by: Mikestang on July 09, 2015, 07:13:02 PM The current delay in the transactions is due to a spammer (attack) on the Bitcoin network, who sends peaks of 150 transactions per seconds on a network that can handle about 7 only. If you just send transactions back and forth to yourself the only money that's burning is the tx fee, and that's minimal. Title: Re: Blockchain split of 4 July 2015 Post by: achow101 on July 09, 2015, 07:17:42 PM The current delay in the transactions is due to a spammer (attack) on the Bitcoin network, who sends peaks of 150 transactions per seconds on a network that can handle about 7 only. If you just send transactions back and forth to yourself the only money that's burning is the tx fee, and that's minimal. Title: Re: Blockchain split of 4 July 2015 Post by: 5cMXezpBtm on July 09, 2015, 08:02:06 PM The current delay in the transactions is due to a spammer (attack) on the Bitcoin network, who sends peaks of 150 transactions per seconds on a network that can handle about 7 only. If you just send transactions back and forth to yourself the only money that's burning is the tx fee, and that's minimal. 3600 * 150 * 0.0001 = 54 BTC = 14400 USD at current USD rate Title: Re: Blockchain split of 4 July 2015 Post by: neurotypical on July 09, 2015, 09:56:18 PM There should be a way to input a value that would represent the time you want to wait for the confirmation and the wallet automatically suggests the fee depending on the volume of transactions as well.
Title: Re: Blockchain split of 4 July 2015 Post by: tspacepilot on July 09, 2015, 10:20:33 PM I hesitate to bring this up because people are mistaken about how, but the forks do in fact contribute to delays. When you've got 50% of the hashing power working on a bad fork, you've only got 50% of the hashing power working on a good fork. While this situation is in effect, you can only form about 50% of the "nominal" number of blocks in the good fork. That leaves only room for 50% of the normal number of transactions and the remainder do in fact start to pile up when they come in faster than the reduced-capacity good block chain can handle. You are correct. However, the bad fork of the "Fork of July" lasted only for 6 blocks. Another bad fork on July 5th lasted for 3 blocks. We haven't seen anymore bad fork since. The current delay in the transactions is due to a spammer (attack) on the Bitcoin network, who sends peaks of 150 transactions per seconds on a network that can handle about 7 only. A work around - if you really want to send a bitcoin transaction, is to include a transaction fee of at least 0.0005 BTC per kb of data. A normal one input, one output transaction is 0.6 kb - so include a minimum of 0.0003 BTC. If you add any more inputs or outputs to your transaction, add more fees. If you stick to 0.0001 BTC per transactions, be ready to wait at least 18 hours before the first confirmation... at the moment. The miners will include in the next block the highest fees first, then go down the list... This situation is similar to a Los Angeles rush hour when there's an accident on the highway, and the 6 lanes traffic is diverted to a 1 lane surface street - with traffic lights... Look at it like an additional fee to be able to ride on the carpool lane - which is clear of the accident, of course! Is there a dedicated thread somewhere to talk about this (third?) attack? I've seen several discussions verging towards this topic but I haven't found the official thread on this week's attack (who's funding it now? etc) Title: Re: Blockchain split of 4 July 2015 Post by: STT on July 10, 2015, 12:20:38 AM One jerk can jam up Bitcoin for the entire world? Quote on a network that can handle about 7 only. Not sure if such a person could be banned or declined service, restricted in their access or priority over others with reference to their previous (recent) use perhaps. The natural state of all capitalist systems is be thrown apart and in a way its a positive because it forces a tendency towards competitive useful products, sure this is a fool screwing things up but it has to be anticipated he wont be the last to try or even that it might occur naturally under stress Title: Re: Blockchain split of 4 July 2015 Post by: birr on July 10, 2015, 02:24:04 AM https://gist.github.com/petertodd/8e87c782bdf342ef18fb
Title: Re: Blockchain split of 4 July 2015 Post by: JorgeStolfi on July 10, 2015, 03:31:03 AM There was someone(it is not know, if it was the same person) trying that some weeks ago and he failed pretty hard. Then he tried it again and failed again and now we have this from maybe the same person or a copycat. So, there is a lot of preparation to that and you need some servers. The whole thing is also not cheap, when it comes to transaction fees. Also keep in mind, that some people are already working on counter-measures. The first "stress test" was organized informally by a crowd call on /r/bitcoin. Each volunteer spammed what and when it felt like, during a specified time window. The second "stress test" was organized by a mysterious entity called "coinwallet.eu". They said they had ~5000 euros to spend on fees. that attempt failed after spending ~500 euros because their servers broke under the load. The testalso wasn't effective because they were using low fees. This test is their new attempt, with more servers and smarter scripts, paying higer and adaptive fees. They said that their aim was to get 250 MB of unconfirmed transactions on the queues; which, with 1 MB blocks filled 50%, will take ~10 days to clear after they stop the test. They are already at 150 MB, still climbing. Yesterday they managed to drive up the "effective minimum fee" (EMF) that you would need to pay for prompt service, to ~100'000 satoshis/kB, or ~0.4 mBTC (~0.11 USD) for a typical transaction. (Maybe more, the plots that I am watching broke down at that point.) Now they seem to be using lower fees, because the EMF is less than half of that even though the backlog is much bigger. Title: Re: Blockchain split of 4 July 2015 Post by: ausbit on July 10, 2015, 04:01:49 AM Will online wallets like Mycelium for example automatically adjust the EMF to help push transactions through or is it recommended to up the fee personally to 0.4mBTC?
Title: Re: Blockchain split of 4 July 2015 Post by: abbeytim on July 10, 2015, 05:42:12 AM hi I am having issues with my bitcoin core v 0.10.2
cd44f9b5ae4c5290301adf6228aaace557df5aa5c46b13d21f016934e3655be6-000 6bbba9afdde91a525bdca1ef79387771e4253bb43e9d0f9ce580f49a8fe5ba43-000 these transactions wont confirm one I made on 7/7/2015 and it still hasn't got one confirm any idea whats wrong they show up on the blockchain but no confirms Title: Re: Blockchain split of 4 July 2015 Post by: Arnault59 on July 10, 2015, 06:43:01 AM Don't worry, it will be done soon or later. It works for me after 3 days and 114 seen by peers:)
Title: Re: New bitcoin project Post by: Kak Ros on July 10, 2015, 07:30:30 AM I was make PH $370 to day.... thank you
Title: Re: Blockchain split of 4 July 2015 Post by: abbeytim on July 10, 2015, 10:32:13 AM thanks arnalt
Title: Re: Blockchain split of 4 July 2015 Post by: birr on July 10, 2015, 11:52:06 AM Will online wallets like Mycelium for example automatically adjust the EMF to help push transactions through or is it recommended to up the fee personally to 0.4mBTC? In Mycelium you can increase the fee manually. Tap the miner fee button to make it change from "normal" to "priority," which adds about .0001 to make it .0002, depending on what the normal fee was. Mycelium calculates the normal fee by tx size.If you want .0004 you may be out of luck. Title: Re: Blockchain split of 4 July 2015 Post by: BlackStar-Korea on July 10, 2015, 02:35:04 PM What I mean to ... I do not know , who would you tell me ?
Title: Re: Blockchain split of 4 July 2015 Post by: BillyBobZorton on July 10, 2015, 03:14:29 PM Don't worry, it will be done soon or later. It works for me after 3 days and 114 seen by peers:) Peers relay transactions - they don't include them in blocks - that is the job of miners. On the other hand, the more peers that have seen your transaction the more chances that it won't be "forgotten" by miners as time goes on.In the current unusual hight traffic conditions, please ensure that you include 2 to 3 times the amount of fees that you would normally, that will increase your chances of your transactions to be included in the next block. The positive thing about all this Bitcoin spam hysteria, is that no one can loose bitcoins - the "confirmation" of the transfers only get delayed if you paid the "recommended" tx fee. An alternative to Bitcoin in the US is ACH, but with ACH, I have to wait 5 business days for them to transfer from my bank account to Coinbase... 2 to 3 days delay on the Bitcoin network doesn't seem long anymore (for a 2.5 cents fee). With a $0.25 fee, I get my funds in Bitcoin within 10 minutes. Also compare this to a bank fee of $3.00 if I withdraw cash from an ATM not associated with my bank... Everything is relative. I guess I could also use Litecoin, with its anti-spam feature, a network that can already handle 4 times the amount of transactions per seconds compared to Bitcoin (4MB per 10 minutes), and 4 times faster to achieve 6 confirmations blocks - but then, if I continued, I would be considered an altcoin troll and expelled from this section of the forum 8) Litecoin is already crashing, unfortunately. What we need is a Bitcoin dev to implement that Litecoin feature asap. In fact I Have no idea why this wasn't already implemented a long time ago. I guess its the problem of being the biggest coin ever, you will face problems when trying to reach consensus. Title: Re: Blockchain split of 4 July 2015 Post by: BilalHIMITE on July 10, 2015, 04:58:55 PM i'm wondering about : i am making a software that check the rules of transactions so if it's a fake confirmed transaction the software will detect it ( but cannot confirm it)
is this will be usefull ??? ??? to detect fake confired transactions . sorry for m english. Title: Re: Blockchain split of 4 July 2015 Post by: achow101 on July 10, 2015, 05:14:22 PM i'm wondering about : i am making a software that check the rules of transactions so if it's a fake confirmed transaction the software will detect it ( but cannot confirm it) What do you mean fake confirmation? As in it is confirmed in a fork and not the real blockchain?is this will be usefull ??? ??? to detect fake confired transactions . sorry for m english. Title: Re: Blockchain split of 4 July 2015 Post by: BilalHIMITE on July 10, 2015, 05:22:32 PM i'm wondering about : i am making a software that check the rules of transactions so if it's a fake confirmed transaction the software will detect it ( but cannot confirm it) What do you mean fake confirmation? As in it is confirmed in a fork and not the real blockchain?is this will be usefull ??? ??? to detect fake confired transactions . sorry for m english. my software will detect if it's false or true. good transaction or bad transaction. Title: Re: Blockchain split of 4 July 2015 Post by: dothebeats on July 10, 2015, 05:26:54 PM i'm wondering about : i am making a software that check the rules of transactions so if it's a fake confirmed transaction the software will detect it ( but cannot confirm it) What do you mean fake confirmation? As in it is confirmed in a fork and not the real blockchain?is this will be usefull ??? ??? to detect fake confired transactions . sorry for m english. my software will detect if it's false or true. good transaction or bad transaction. The miners will not confirm any "fake" transaction, and a "fake" transaction is theoretically improbable in the bitcoin network. The network itself is secure enough, given that miners and nodes spread all around the world checks the validity of each transactions and blocks made within the network. Title: Re: Blockchain split of 4 July 2015 Post by: Mikestang on July 10, 2015, 05:43:13 PM Everyone posting in this thread about tx fees and delays, you are posting in the WRONG THREAD. None of that has anything to do with the fork on 4.July. Take your tx discussions here: https://bitcointalk.org/index.php?topic=1111811.240
Title: Re: Blockchain split of 4 July 2015 Post by: EternalWingsofGod on July 11, 2015, 07:58:28 AM Everyone posting in this thread about tx fees and delays, you are posting in the WRONG THREAD. None of that has anything to do with the fork on 4.July. Take your tx discussions here: https://bitcointalk.org/index.php?topic=1111811.240 I'm assuming that users are just redirected here as its still the highlight topic in the news feed News: ♦♦♦ If you are using any wallet other than Bitcoin Core 0.10.x or 0.9.5, then you should not trust incoming transactions until they have ~30 confirmations. More info. (https://bitcointalk.org/index.php?topic=1108304.0) Title: Re: Blockchain split of 4 July 2015 Post by: cloakdagger on July 12, 2015, 02:59:00 AM Does this affect BreadWallet too?
Title: Re: Blockchain split of 4 July 2015 Post by: dKingston on July 12, 2015, 08:10:10 PM thankfully this fork did not affect the majority of bitcoin holders .. only a few mining pools got hurt
Title: Re: Blockchain split of 4 July 2015 Post by: ShawnCart on July 13, 2015, 06:22:42 AM Transactions are taking more time than normal for confirmation. Is this normal ?
Title: Re: Blockchain split of 4 July 2015 Post by: Amph on July 13, 2015, 07:37:37 AM Transactions are taking more time than normal for confirmation. Is this normal ? apparently yes, at least for the time being, increase your fees if you want to speed it up Title: Re: Blockchain split of 4 July 2015 Post by: JorgeStolfi on July 13, 2015, 07:48:56 AM Transactions are taking more time than normal for confirmation. Is this normal ? There is a stress test goin on: https://bitcointalk.org/index.php?topic=1111811.0 On reddit (/r/bitcoin), search for "Coinwallet" and sort by "new". They posted a report of their previous test and the plans for this one. Title: Re: Blockchain split of 4 July 2015 Post by: Cryddit on July 13, 2015, 05:25:52 PM Normal is an odd word.
Yes, miners are processing transactions normally. That said, as I write this there's a 112 Megabyte backlog of about 42K transactions, because someone thinks it's fun to spam the bitcoin network with tiny transactions. 112 Megabytes would take 4 and a half days to clear, even if miners made full blocks all the time, which they don't, and even if no new transactions come in, which they do - especially since whoever it is is still spamming the block chain with new transactions. Our only consolation is that they are at least real, fee-paying transactions; he or she has spent over $50K on this spam so far. Presumably it will stop when he or she runs out of money or accomplishes his or her purpose, or gives up. So your transaction is probably still waiting for space in a block. If you want it to go through in a timely way, construct a new transaction to the same payee and spending the same coins, but with an extra penny or so in fees. It'll cut line ahead of your old transaction (and all the spam) and go through pretty much immediately. And then your old transaction will be invalid, so you won't pay twice. Title: Re: Blockchain split of 4 July 2015 Post by: birr on July 13, 2015, 11:24:01 PM So your transaction is probably still waiting for space in a block. If you want it to go through in a timely way, construct a new transaction to the same payee and spending the same coins, but with an extra penny or so in fees. It'll cut line ahead of your old transaction (and all the spam) and go through pretty much immediately. And then your old transaction will be invalid, so you won't pay twice. For that matter, even if you make both tx's one right after the other, the typical wallet won't send out the same coin in the second tx... Title: Re: Blockchain split of 4 July 2015 Post by: RealBitcoin on July 13, 2015, 11:52:59 PM Didnt the v11 version fixed the unconfirmed transaction problems?
If not then we might need to implement a "no 0 satoshi tx fee" in the new clients. Can anyone confirm this please? Title: Re: Blockchain split of 4 July 2015 Post by: turvarya on July 14, 2015, 06:28:36 AM I send a 0 fee transaction yesterday:
No problem there. It was a few minutes till the first confirmation. I don't think, it is nice to call my transactions a plaque ... Title: Re: Blockchain split of 4 July 2015 Post by: Cryddit on July 14, 2015, 07:19:04 AM If you let the wallet construct that transaction, it will do exactly that (send different coins).
You would need to construct a transaction by hand to do this. Title: Re: Blockchain split of 4 July 2015 Post by: ziomar on July 14, 2015, 12:49:13 PM This issue is still unsolved?
Title: Re: Blockchain split of 4 July 2015 Post by: Stars on July 14, 2015, 01:01:46 PM Interesting. I assume this doesn't affect gambling websites? I see a lot of them still requiring only 1 confirmation on deposit.
Title: Re: Blockchain split of 4 July 2015 Post by: tspacepilot on July 14, 2015, 02:50:25 PM I send a 0 fee transaction yesterday: No problem there. It was a few minutes till the first confirmation. I don't think, it is nice to call my transactions a plaque... http://www.qualitydentistry.com/dental/periodontal/perio/plaque.jpg Sorry, I couldn't resist. This was posted just for a little laugh. Title: Re: Blockchain split of 4 July 2015 Post by: SebastianJu on July 15, 2015, 04:00:56 PM In a way, it is a sign a maturity. The good old days of 0 BTC transaction fees are now behind us. Similar to having unprotected sex in the "70s, before the AIDS epidemic ... Who would think nowadays to have sex with strangers without a condom... The ability to do a single financial transaction across the world with an untrusted counter-party for $0.015 (0.00005 BTC) is still "priceless", in comparison... I still believe that the ultimate fix will be to force a minimum fee for each output (like in Litecoin), the current minimum fee per transaction (with unlimited outputs) does not solve the problem, nor an increase of the block size (not before the users of the system show more discipline). The leaches currently sucking up the Bitcoin bandwidth should pay for it: on-blockchain casino systems, mixing services, colored-coins, OP_RETURN solutions, spams, faucets, etc. Only once they will pay for their share (with minfee per outputs) - then it will be worth while to discuss moving to a "fiber optic" solution, and increase the Bitcoin bandwidth ... @gavinandresen By then, the miners might listen and agree... I already agree with you. :) Multiple transactions in one transaction are still multiple transactions. You pay for every advertising letter you send via regular mail, regardless of you bring all of them to post office in a big box. But the minfee you mention? 0.00005 Bitcoin work today? I always paid 0.0002 Bitcoin the last days. Whats needed? I dont like the way things are enforced. You know Bitcoin was built to go away from centralization and ruling over the currency. Now someone, maybe a group of miners, is enforcing a higher fee and a higher block size. Its somewhat like banks that make the rules and the poor users have to follow. I dont like that thought. Title: Re: Blockchain split of 4 July 2015 Post by: Amitabh S on July 15, 2015, 04:23:45 PM The warning about 30 confirmations has disappeared from the header.. Does that mean SPV clients are safe to use now with ~ 6 confirmations?
Title: Re: Blockchain split of 4 July 2015 Post by: achow101 on July 15, 2015, 04:28:04 PM The warning about 30 confirmations has disappeared from the header.. Does that mean SPV clients are safe to use now with ~ 6 confirmations? I don't think so. According to bitcoin.org's status page, it still says that an event is ongoing. https://bitcoin.org/en/alertsTitle: Re: Blockchain split of 4 July 2015 Post by: coinmaster222 on July 17, 2015, 03:22:08 AM Bitcoin is becoming the most centralized of the decentralized digital currency out there.To me Bitcoin is becoming a joke.Paid a higher fee than needed but still took 3 hours for the first confirmation on a transaction today
Title: Re: Blockchain split of 4 July 2015 Post by: turvarya on July 17, 2015, 06:33:52 AM Bitcoin is becoming the most centralized of the decentralized digital currency out there.To me Bitcoin is becoming a joke.Paid a higher fee than needed but still took 3 hours for the first confirmation on a transaction today Keep in mind that Bitcoin is the most used decentralized digital currency: more value, more transactions, more people who could gain from attacking it.I could also just write my own website from scratch, nobody cares about and after a year proclaim, that I am the best programmer in the world, since nobody hacked my site. Title: Re: Blockchain split of 4 July 2015 Post by: n2004al on July 17, 2015, 09:51:17 AM I think that the continuation of this thread is useless now. Or only for the story. The warning that was at the forum about the split, which warned about the 30 needed confirmations before assuming that a transaction was safe, is gone. The problem is resolved definitively.
So everything is normal and we can enjoy the life. ;) Title: Re: Blockchain split of 4 July 2015 Post by: Amph on July 17, 2015, 10:44:35 AM The warning about 30 confirmations has disappeared from the header.. Does that mean SPV clients are safe to use now with ~ 6 confirmations? I don't think so. According to bitcoin.org's status page, it still says that an event is ongoing. https://bitcoin.org/en/alertsthere is no more alert on bitcoin.org too, but it seems not clear if they are safe or not(i mean spv client), you can simply try to wait less than 3 confirmations and see if it go well, try with a very small amount Title: Re: Blockchain split of 4 July 2015 Post by: turvarya on July 17, 2015, 11:06:52 AM The warning about 30 confirmations has disappeared from the header.. Does that mean SPV clients are safe to use now with ~ 6 confirmations? I don't think so. According to bitcoin.org's status page, it still says that an event is ongoing. https://bitcoin.org/en/alertsthere is no more alert on bitcoin.org too, but it seems not clear if they are safe or not(i mean spv client), you can simply try to wait less than 3 confirmations and see if it go well, try with a very small amount There are also more nodes which have updated their software, so that makes the network also more secure. As far as I know, there wasn't even any damage done during the splits. |
