Yes.

Potentially forever, unless a conflicting transaction is confirmed.

Well that didn't last long. Everybody, stop dancing.

Nobody said anything about your grammar, and your embarrassing mistakes were more than a typo. After all, nobody deletes their post just because they made a typo.

No it's not. I've just explained that.

Just for kicks, I'd like to see you explain this new hole you've dug yourself into, which definitively proves you don't know what you're talking about. Hint: AD is not a block size.

As lonely as the forum would be without kooks continually making low-content posts in idiotic topics, this one's fairly begging to be banned. He really is.

BU supporters' understanding of consensus systems in general is completely wrong, not just decentralised ones. I don't know why; it's a simple concept: it means that several independent implementations of a program given the same input data will give the same output, and those that give different results will automatically be known to be wrong. In the specific case of Bitcoin, it means that given multiple conflicting transaction chains, of which only one of them can be valid, all Bitcoin nodes everywhere will always agree on which chain is valid.

BU's so-called "emergent consensus" is not a consensus system of any kind. It explicitly allows nodes to disagree on which of multiple conflicting chains is valid, and it's trivial for malicious miners to force a chain split among disagreeing nodes to allow double-spending. It's not even fair to call this an "attack" since this catastrophic breakdown of consensus is by design. Anyone supporting BU deserves to lose their coins, and I think they're likely to.

You seem to have snuck in an extra decimal place there:
But there's no inherent "looseness" here; remember that floating points are simply integers multiplied by an integer power of two, eg, the decimal fraction 0.5 is represented as 1x2^-1. Binary scientific notation, in other words. Double-precision floats (which is what you're dealing with) use 11 bits to store the exponent, which leaves only 53 bits bits for the mantissa (including the sign bit). That's just not enough for a number like 1999999999.00000011, so the least significant bits are lost:
This isn't really a problem with floating points per se; you're fundamentally trying to squeeze a too big number into too few bits, which will naturally give erroneous results no matter what method you use. Nothing you can do except use 64-bit integers everywhere (and convince everyone else writing software for your coin to do the same; good luck).

No, but the RPC interface does, and enough programs are still treating bitcoin amounts as floats that floating-point precision is the limit of what numbers are "safe".

In fact, I predict that within a year of fractional satoshis being introduced (by a protocol extension or second layer or whatever), someone will lose a significant amount of money due to a floating-point rounding error in third-party software.

The main limitation is that JSON, being JavaScript-based, interprets numbers as double-precision floating point. The largest value that can be thus represented correct to 8 decimal places is 67,108,863.99999999. But even if nothing in Bitcoin Core used floating points, it's highly likely that other Bitcoin software still would (eg, web wallets using JavaScript), so it's not a simple matter to use larger number formats.

I don't know where you read that, but it is false. It makes no difference when upgrading whether you are fully synced, not synced at all (as would be the case with a fresh installation), or anything in between. The new version should pick up where the old version left off and, since many optimizations have been made in recent versions, it will finish synchronizing much faster.

Yes. You should in any case back up your wallet.dat whether you plan to upgrade or not.

If by "another wallet", you mean "something other than Bitcoin Core", then no, at least not easily. Bitcoin-Qt/Core wallet files are generally not compatible with other programs.

Except they do. One thing which nobody seems to want to mention (likely because Core users don't care and BU users are too incompetent to notice) is that .onion nodes didn't ban anyone. They can't, what with the whole "anonymity" thing and all. My .onion node saw two BU peers relay the invalid block and... that's it. No other BU nodes connected to it until the Core chain overtook the BU chain. That's actually a lot because I usually only have one solitary BU peer connecting via Tor. Is this really the entirety of BU's Tor presence? I like to think that those two BU nodes were the only two still able to connect to Core nodes and were the only thing preventing the network from splitting completely.

Actually, it's only half the recommended fee for next block confirmation*, which is doubtless why it took an entire 2 blocks to confirm.

*The latest version of Core doesn't allow setting the confirmation target that fast, due to how "ridiculous" the fee can get. It's like, up to two dollars for reasonably sized transactions. I'm not sure who decided two dollars was "ridiculous" for an international payment system; gotta have your on-chain coffee, I guess.

No, the Backup Wallet option only copies your wallet.dat file, not the blockchain state, which cannot be safely copied while Bitcoin Core is running. I think achow101 misunderstood the question.

The question is why are you backing up the blockchain state? If you merely want to avoid the bandwidth cost of downloading the blockchain all over again, a workaround is to back up the blocks folder and use the -loadblock parameter to synchronize from that, which should work despite the most recent .blk file likely being corrupt if you copied it while Core was running. It will still take a long time to verify everything. The only way around that is to back up everything while Core isn't running, so that the chainstate data will not be corrupted.

They changed the code that calculates the block size without understanding how it works, and pushed out the change without any review or testing. This is standard practice for Bitcoin Unlimited developers, and nobody is the least bit surprised that it blew up in their faces. It may be the first time Bitcoin Unlimited users have lost money as a direct result of the developers' incompetence, but it's unlikely to be the last.

---

It harms nodes with limited connection slots. Banning misbehaving nodes frees up slots for correctly behaving nodes. Any node that relays an invalid block is either defective or malicious, and there's no point in maintaining a connection to such nodes.

They're already following different data, whether they're communicating or not. By definition, there can be no consensus when one node thinks a block is valid and another does not.

It's certainly interesting, but not for the reason you think. Remember, we're not laughing with you, we're laughing at you.

I already told you, down is the direction a plumb bob points. See, there's this thing called "gravity" that causes massive objects to be pulled "down". Haven't you heard of it?

Who's "we"? Nobody over the age of 8 ever called north "up" either.

Do you also wonder which part of a golf ball is the top and which part is the bottom? Or a die? Or any other object with no defined orientation? Do you spend a lot of your time wondering about concepts so simple that most children have them figured out?

We really don't.

I think in the near future we're going to see a compromise solution, where BU puts it on the testnet and never tests it, like Classic did 6 months ago with BIP109. For those who don't remember, an invalid BIP109 block mined on testnet (by bitcoin.com, if anyone's surprised by that fact) was rejected by Classic but accepted by Core (which doesn't care about BIP109), causing Classic to reject the majority chain. This would have been an unmitigated disaster had it occurred on mainnet, but since it was on testnet, it went completely unnoticed for nearly a month because apparently nobody was running Classic on testnet.

Apples to oranges. For comparison, I've made 2,869 posts and you've started 450 topics.

Quality over quantity.

You're right. Those are terrible topics. I should start a topic on my new favourite method of tying neckties, which has long been covered up by a conspiracy among sartorialists. That would be more in line with the kind of topics you seem to like.

Nobody asked you to post proof. You're announcing what the whole world already knows and children are taught in school and pretending it's some kind of secret or occult knowledge. Everybody already knows about the difference between true north and magnetic north, and that the poles shift positions, and everything else you've said in this thread. Except for the part about up and down being a scam. Nobody knows what that part's all about.

You've never met a pilot or sailor?

You must never have used it then, since it's hard to avoid noticing that it's always at least a few degrees off depending on where in the world you are.

These particular facts are confirmed and provable by Girl Scouts. Next you're going to post your "amazing discovery" that it's possible to start a fire without matches or a lighter.