The US is one of few countries where dual citizens must pay dual taxes regardless of their primary residence location.  That is to say that US citizens must pay the same US taxes on their income regardless of where it came from and/or where it resides.  If there is an exception to that, it would likely be one where taxes where higher when money/income were not in the US.  They also have plenty of other ways to track your income, for instance, any US-based exchange and likely any exchange in any in any of the fourteen eyes countries.  Even trading outside of that jurisdiction doesn't guarantee they won't know, for instance, see the btc-e.com takeover landing page, where the IRS logo is present amongst other US LEA logos.

Regarding the concern about using the coins but not updating a private key with a lawyer or safe deposit box, this is not a problem if you have a deterministic wallet.  I believe the latest version of bitcoin core will create a deterministic wallet if you don't already have a non-deterministic wallet.  Several other wallet softwares will as well, and I believe all hardware wallets are deterministic.  To be clear, a deterministic wallet is a wallet where each subsequent change (and/or receiving) address can be unlocked from the same root key/password.  In other words, you only need to store the information once, and anytime a wallet is re-generated from it, the remaining coins will be spendable.

Regarding the concern about involving a bank or lawyer in general, it has been a few years, and I have not had any luck finding the service even though I want to, but I once read about a service that stores whatever information you want (I say information, not data, because I believe they store the data in a secured database vs storing individual files, and the service is really meant for passwords and account information) in an electronically secure manner (supposed to be secure from hackers and disasters) for release to designated persons upon your death.  Obviously this would not be a zero-knowledge service, so there would be some third party risk, but in order to do the same thing with a zero-knowledge service and not still involve a third party to protect a password (something you know in 2FA terminology), it would be necessary to secure that service with something you have instead or as well.  Unfortunately, I don't think I've ever seen anything secured with zero-knowledge using something you have for security.

I agree that it represents progress, but I believe it should have been implemented as a hardfork to fix the very "softfork" security issues it takes advantage of and without the "lighter" "full nodes".  However, my point above was that another of your anti-hardfork arguments isn't holding water.

I don't care enough about ETH to have an opinion here, but I already pointed out that not all hard forks are good in an earlier post, I'm only still commenting because not all hardforks are bad.

1) Satoshi was long gone by the time of the event I am referring to.  In fact, he was long gone before I heard of bitcoin.
2) As in war, the winners will write history, and bitcoin will be what they say it is.
3) The segwit soft fork that core is pushing so hard will allow existing full nodes to function, but they won't truly be functioning as full nodes were meant to anymore since they don't have all of the data to validate.  Moreover, the newer version will support a "lighter" "full node" function that has these same flaws by design, while I'm not implying as much, this could be a false-flag-style attempt to reduce network security, so IMHO, your argument regarding power grabs seems to fall a bit short when you turn around and support core.

The core devs may want to change the definition of a hard fork in order to make this claim, but it has.  If it had never hard forked, you could still run the original client, but IIRC, at some point an alert was sent out about any client older than 0.5.x not validating blocks after a certain block number due to a fork.  At the time, there were months of notice, but multiple pools were still running 0.3.x and not happy about being "forced" to upgrade.  They weren't forced to, and there was no "core" yet, but they were the economic minority, and even then, without fear-mongering, and even though bitcoin had tanked from $40 to $2, they still wanted to stay on the longest chain.  If an old client won't work anymore due to the change, the fork was hard, period.  That having been said:

Yes, bitcoin has had a hard fork in the past.

No, there won't be two relevant chains.

ETA: relevant is a key word in that second point.  There may be a subset of the 25% or 10% or even 5% (depending on what percentage is treated as "consensus" in any intentional hard fork) who continue to work on the old chain intentionally or otherwise, but even if some exchange validated that short insecure chain, nothing would happen but dumping, because there wouldn't be any demand for it.

Now, regarding hard forks being dangerous, unintentional hard forks (or even intentional ones that don't have "consensus") could certainly be dangerous and lead to separate continued chains for a longer period of time, but "because we're core and we said so" doesn't really have much to do with consensus, and if the right set of pools and exchanges got together and decided they wanted to fork, they could likely do so without the support of any other nodes and ram the change through regardless of what anyone on this forum prefers.

So you call yourself a "Free Market Capitalist" but you are afraid of a free market?  Wow, I'm impressed.

FYI, hard forks have occurred in the past.

FYI, the only way both forks would continue on is if a subset of miners kept mining each fork.

FYI, if that happened (it wouldn't), you would still control the same amount of "money" with the same private keys, it would just be divided across two chains.

In my experience, I can't even see the interface until after the on-disk DB is fully loaded.  However, I have an SSD, so the behavior you describe might be normal on a standard HDD.  Additionally, I am assuming you mean until the DB is fully loaded, and taking forever to sync isn't the best term for that if I am correct.  Sync(hronization) is when the blocks on the public network (Internet) are downloaded.  This is why I specifically mentioned the on-disk DB being loaded.  Until that is loaded, it would not make sense for the interface to display any data.  However, once that is loaded it should display balances and recent transactions with a warning that you are not fully synced and they may be inaccurate.

I'm not sure how much risk there really is, but it is recommended to shut down the client before manually copying the walled.dat file in either direction.  It used to be possible to issue a resync command whenever replacing the wallet.dat file to make sure it was up to date, but I believe some things changed in the most recent versions and that may no longer be possible and/or necessary.  Regardless, assuming you only have one wallet.dat file and simply want backups, you can take them while core is running by using the command "bitcoin-cli.exe backupwallet <destination>" from the daemon subdirectory of your Bitcoin Core installation folder.

Finally, while this response may have come pretty quickly, There is a Technical Support section where you should have posted this and might typically get quicker (or at least more informed) responses to these types of questions.

Definitely a biased article.  Writer starts out with "decentralization is sooo important" but then uses that as his argument for supporting segwit and lightning being better solutions than big blocks.  However, segwit encourages pretend decentralization (if you don't have the witness data, you aren't protecting the network's data) and things like lightning require gatekeepers that are even more centralized still.  I'm not saying centralizing microtransactions off-chain is a problem, but the argument that decentralization is so important that we should centralize stuff is not a very good one.  If the concern was really with centralization, the answer would be pruning, but attackers could easily fight against pruning with spam, and even if that wasn't a possibility, years of misuse of the blockchain as permanent data storage has lead to the opinion that pruning isn't an option.

Obvious scam is obvious, not even necessary to go look at the transactions "verified in the blockchain".

Old FUD that actually has nothing to do with what they try to claim is relevant in the same paragraph.

What scam doesn't start with "we can get free money, but we're going to do it for you instead of ourselves?

Even including this makes you look like a part of the scam.

Easily emulated with spoof and you don't even provide link, almost as if this is bait to get people to go to the aforementioned redacted URL, again, makes you look like part of it, edit your post if you aren't.

IOW: Don't test a small amount in this scam, because you won't get a second chance to make money, put it all in now even though it's a scam.

To be clear, when I said supporting, I meant providing development support, not actively peddling.  For instance, in the already discussed incredibly hypothetical scenario, 75% of new blocks would already be on a chain where some blocks are >1MB and a group of core developers refuses to adapt core to accept that chain as valid.  So, at that point the options for a developer who does want to continue supporting that chain and doesn't see a problem with 2MB blocks (since that is what this thread is predicated on, regardless of what any wallet may support) are to try to improve the most popular client on the larger chain (I would predict this to be your decision based on the post I quoted in my previous post), stick with core (presumably this requires the belief that the longer 75% chain can and will fail without turning off most users), or walk away completely (this seems like an unlikely choice, but it is still certainly an option).  That having been said, I failed to acknowledge the possibility of developing for multiple clients at once (sticking with core, but contributing to other projects as well).  Moreover, I can understand why you might not want to answer the question in its hypothetical state with so many people potentially ready to misquote such an answer (or otherwise use it against you), so I will pretend you are undecided for now unless you actually feel so strongly about this that you want to post that you would stick with contributing to core and core alone in said scenario.

I don't agree with everything you post, but refuting FUD that "supports" "core" certainly helps convince me that you do believe what you are posting (vs just being a shill).

I think a far more important question for gmaxwell is this:

So if this rumored hard fork actually occurred, where would you put your effort if the majority of core developers wanted to call it an altcoin and block support for it from being added to core?

This question is important because my belief has always been that if something else wins out, core will adjust and may again become the best client, however, what the best developers do is far more important than what core does.  So as a developer with "nearly a lifetime of relevant experience" that helps to "identify initiatives which are likely to be successful" I'm interested in whether he would jump ship if he had to (supporting classic or unlimited, for instance) and also in whether or not he would believe he had to (vs expecting the ~75%/+ longer fork to die off without confidence in the ~25%/- fork concurrently being so shaken that there is no longer a "successful initiative" on either "side").

You mean like you learned from the history before 2013?  First bubble I saw was $30-40 and burst back down to $3-4.  There were other bubbles after that and before 2013...

Wow, based on my understanding of existing guidance and a few simple questions that don't even mention that guidance being answered by a CPA, it looks to me like the AICPA showed that they are incompetent and can't even do simple web searches to find past guidance instead of using old guidance and common sense to reduce their number of questions from 10 to 4.  I hope this doesn't set the IRS (in even more of a position than they already had) to change things and screw up anyone who has been following the old guidance.

Compare apples to apples and oranges to oranges, the closest your quoted post provides to such a comparison is as follows:
15400tx (blocksize 3.5 mb) @ vs 15840tx (segwit w/ 2mb)
It's not accurate since 3.5 mb < 2mb segwit, but none of the other numbers line up at all.

To be clear, I'm in the hard fork camp.  I'm not 100% pro or anti regarding segwit or blocksize, but I am anti regarding a soft fork for a major change.  However, I'm calling you out because you shouldn't be playing their game.  It isn't right when they're playing it anti blocksize, and playing the same game anti segwit doesn't make it any better.

Assuming the original topic was also on the forum or some other public space, a link to said original topic would be really useful here...

While I agree with you on the unquoted portion of this post to the extent that some strive to destroy the fungibility of bitcoin, I feel it is important to point out two things:
1) Just because there are some threats to fungibility doesn't mean that additional threats such as this should be considered acceptable.
2) We don't know which coins are in Satoshi's stash; anything beyond the genesis block could have been mined by anyone, and we don't know who mined which blocks beyond a few blocks where it was publicly announced by Satoshi that coins were being sent (for instance, the famous transaction to Hal Finney that was publicly announced does tell us that the block the coins came from was awarded to Satoshi's address and the address the coins were sent to went to was Hal Finney's, but we don't know who mined any other given early block unless someone has said something to indicate it was theirs).

I know you know better, but when suggesting we know which coins are Satoshi's, I can only assume you fell back to the poorly chosen and inaccurate title of this thread (and the article on which it was based).

The quote above absolutely SHOULD be true, and I hope it is, but what do you read into the quote below?It seems to start out cocky and almost imply that it doesn't matter what the early adopters / true believers think because the core developers have their own agenda, but then it ends looking like double-speak when also mentioning a hard fork.  Does this mean the only way to prevent a soft fork is with enough support for a hard fork against it?  Do you really think ideology will beat greed in that scenario?  Don't get me wrong, I understand that if the greedy side won, they would likely actually be shooting the collective in the foot and we'd technically all lose, but how much say does Theymos really have in Core development?  How true to the founding values of bitcoin is the current core development team?  This all makes me very nervous and reaffirms my belief that we need multiple implementations (even if XT and Classic had their flaws, at least they could theoretically keep development decentralized).  I actually ran XT even though I had a problem with many of Hearn's ideas long before it was created, but I understood that I could switch away after big blocks happened so that I wouldn't support the other more evil aspects of that particular implementation.    I've been running Unlimited since XT died, but more recently I've been considering switching back to Core even though I only support segwit as a hard fork with other fixes to prevent drastic soft forks.  Right now I'm thinking I shouldn't switch back after all...

ETA:  To be clear, I'm really looking for input here.  I've re-read that post many times.  My comments above are based on it sounding like:
"You can't stop the destruction of those coins, because we can force it with a soft fork and you can't get enough support to undo that with a risky hard fork"
However, other times, even though I would be against the potentially supportable hard fork, it sounds like a much more even keeled:
"We should prevent soft forks that would allow destroying coins, but even then there will probably be sufficient support for a risky hard fork to destroy them"

You are far from the first person to suggest this, but this replaces decentralization with authority and pseudonymity with deferment to said authority.  While some might actually believe this is OK it doesn't change the fact that no one can definitively prove that they mined any given coins except by way of a signature from the private key of the address the coins were mined to.  Moving the coins doesn't protect them from a bad actor if the proof of ownership is a signature from the private key that can be compromised, and there is no other way to prove ownership.  However, otherwise destroying or rendering the coins inoperable does break fungibility and arguably causes more harm than the theft that can't otherwise be prevented.

First off, if I am keeping up, ebliever has changed his position from "Theymos is wrong" to "Theymos is right" and back to "Theymos is wrong" before you ever quoted this post from the middle position.

Secondly, taken out of context, "and then everyone else with bitcoin suffers as the market collapses from the shock of such stupidity in allowing this to happen" summarizes both arguments.  One argument is that allowing the coins to be stolen = bitcoin is worthless.  The other argument is that manipulating the coins even though not in possession of the keys = bitcoin is worthless.  The problem with both of these arguments is that they come from people worried about the value of their stash instead of being worried about the roots from and purpose for which bitcoin was created.  When considering those principles, the only way the coins should ever move is when a rightful owner or bad actor uses the keys to move them.

I hear what you're saying and I'm intrigued, because it implies my somewhat simplistic understanding of encryption technologies may be wrong here.  However, if it were so simple, then why would there even be a discussion about earlier coins being more vulnerable?  If any existing (or technically non-existing) private keys could be used to match up to existing bitcoin addresses using a different DSA, then the only addresses that would ever be vulnerable are addresses that have been used as outputs or signed against using the old DSA.  In that case, the majority of the coins being discussed here that were mined and never touched would be safe unless blocks were once generated including a signature for the address the reward was mined to and that was subsequently changed some time ago.  So, what gives?