It's not just one user, and in any case it's not unusual to ignore thousands of kooks and spammers. It's not like you're the only one here, you know.

Yes.

Because BIP91 requires miners to orphan blocks that do not signal BIP141 (SegWit), with the result that any transactions confirmed in such a block will become unconfirmed again, potentially allowing double-spending. The actual risk depends on how many miners are actually enforcing BIP91 and how many are signalling BIP141, which is difficult to determine with any certainty. As long as a significant number of miners are enforcing BIP91, non-SegWit blocks will probably be orphaned before getting a large number of confirmations, but transactions with a small number of confirmations are at risk of becoming unconfirmed at any time, and should be treated as unconfirmed transactions until they have many more confirmations.

You can withdraw now if you want. You just need to wait for more confirmations than you usually would, that's all.

Then you must withdraw your coins immediately. As far as I know, no exchanges have any plans to ever support any UAHF chain.

EDIT: Typo

The transaction will still exist, it will simply be unconfirmed again after having previously been confirmed. It will confirm again unless double-spent in the meantime, and in that respect is as (un)safe as any other unconfirmed transaction; you just need to treat transactions with a small number of confirmations as being potentially unconfirmed.

Note also that it's always been possible for blocks to be orphaned for a variety of reasons, resulting in previously confirmed transactions becoming unconfirmed; it's just that now there's a much greater risk of it happening due to miners doing it intentionally.

Until SegWit (BIP141) is activated in (I think) about a month.

BIP91 requires miners to orphan blocks that do not signal BIP141. If a transaction you receive is confirmed in such a block, this confirmation will be undone when the block is orphaned, potentially allowing the transaction to be double-spent by the sender. This becomes increasingly unlikely the more confirmations the transaction has, but it is a still a risk you need to be aware of, hence the recommendation to wait for more confirmations than usual.

This risk only affect you if you are receiving coins, not sending them (though if you are sending coins, the person you are sending them to will wait longer before acknowledging your transaction).

(This is also what the warning displayed by Bitcoin Core about "unknown rules" is referring to, though it can only give a generic warning since it doesn't know specifically what the "unknown rules" are.)

Only the last part is correct. OP, you would do well to disregard anyone with an ad in their signature, as they're just getting paid to post on topics they may know nothing about.

EDIT: Typo

No. "Best Bitcoin wallet without transaction fee" is a contradiction in terms. With transaction fees, your transactions are very likely to never confirm, and any wallet that produces transactions that never confirm would not exactly be considered "best".

Thank you kindly, Opposite Oracle. The price has already started to bounce back giving me a nice profit. As always, I am indebted to your anti-guidance.

I don't see it. Google and DuckDuckGo both give similar results in this case. What country are you in?

Because, along with Dutch tulips and the South Sea Company, Beanie Babies are often used as an example of an economic bubble by people ignorant of the fact that the causes of the rise and fall of the value of these assets is well understood, and was predictable (to some extent) even at the time. Furthermore, the circumstances of these cases are all very different from each other and from Bitcoin, and any decent economist would laugh at the suggestion that they're comparable.

Not to me, it isn't. I need to hear it from him. I just bought about BTC50 and I'd like some reassurance from his reverse crystal ball that I've done the right thing.

English site ruined, must use French URL: www.businessinsider.fr/us/bitcoin-price-soar-20000-tom-lee-fundstrat-gold-2017-7

The mempool has nothing to do with it. It doesn't matter how many transactions there are, the current segwit2x code has a default block size limit of 750kB and there are no plans to change it. Miners using the default settings will (and did) refuse to mine the required >1MB block, causing the fork chain to freeze completely. The so-called developers do not consider this to be a problem.

There are many problems with that, but the specific problem that caused this particular failure is that the hardfork block was delayed not by "a couple minutes", but by 29 hours, because that's how long it took the miners to realise that the segwit2x client won't actually produce >1MB blocks by default, and hence rejects its own blocks when the fork happens. (Many probably still haven't realised the default is broken as it only took a single miner with custom settings to mine the fork block, and since the issue was closed without changing the default behaviour, it's likely to happen all over again if they try to fork on mainnet. Get your popcorn ready.)

Not exactly. There's more to it than that. They can't use the hardfork bit because they're trying to trick lite clients into following their fork, thus causing maximum disruption (they don't seem to have any other goal). In that respect, forcing >1MB blocks is a very good idea, or it would be if their code actually produced >1MB blocks. The inherent flaw is that it actually doesn't with the default settings (even if the mempool has more than 1MB of transactions), with the result that all their miners stopped dead as soon as the fork activated, and it took over a day for anyone to figure out what the problem was (and the so-called developers spent most of that time denying that there was any problem at all and insulting anyone who tried to point it out).

It's the typical level of incompetence we've all come to expect from these clowns.

I suppose I should get in on this, just to show I care.

	BIP141	BIP148	BIP149	SegWit2x	Extension Blocks	SegWit Adaptive/BIP106	BU/EC	Bitmaincoin
Foxpup	Prefer	Deficient	Acceptable	No	No	No	ROFL	OMGWTFBBQ

So that He can masturbate to all the suffering that He's caused?

Just kidding; God's not a sexual sadist^{[citation needed]}, He's actually an exhibitionist, and gets off on flashing His privates to His prophets. See Exodus 33:23 (in which God famously moons Moses) and Ezekiel 1:27 and 8:2 (in which Ezekiel actually gets a good look at God's genitals, and describes them as being made of fire, though that just raises further questions).

Ah, yes. Few people today remember the Great Flagmakers' Strike of 1912, in protest of the number of states increasing faster than anyone could keep up. As a result, many people had to make do with outdated flags, with flags showing the correct 48 stars being in very short supply, even for years afterwards.

So it's not just me, then.

The fee you entered is per kilobyte (and it clearly says so), and the option to enter an absolute fee is only available when using coin control, since it's otherwise impossible to know what fee is appropriate. It's not entirely clear to me what else you're expecting.

I'm not the one playing dumb. "Blocksize increase" means the maximum size of blocks is to be increased. SegWit increases the maximum size of blocks from 1MB to 4MB. It's not "equivalent" to 4MB, it is 4MB. Metric megabytes, in case there's any confusion. 4 million bytes, that is, 32 million bits. That's four times as much data to transfer and store forever in the blockchain, and it's understandable that not many people want to spare the bandwidth and disk space for it. That's why it was so controversial when it was first introduced.

Which is false, of course. Of all the Core devs, I think only Luke-jr is in favour of keeping blocks small. I've always been in favour of larger blocks myself, but I have to concede that Luke does have a point. Not everyone can handle bigger blocks, and the increase to 4MB may be problematic. I'm willing to support 1MB SegWit if it turns out nobody wants 4MB blocks after all.