"Taint" is subjective. The objective viewpoint is to treat every coin equally, just as you would with cash. The ledger provides coin history, but beyond that it's utter guesswork to determine who owns it, what was exchanged etc. But, deeming mixed coins as "tainted", which is known practice by Coinbase, is insane. You cannot even argue the coins have "bad history", because it is completely erased in the first place. Mixed coins are indistinguishable; deeming them "bad", just because there is an x probability of being owned by a criminal is insane.

I did a little bit of a research, and eclipse attacks appear to be concerning. Paper "Eclipse Attacks on Bitcoin’s Peer-to-Peer Network" greatly demonstrates experiments and countermeasures of such attack.

Fortunately, Bitcoin Core has implemented 6 out of the 7 countermeasures (which are described in detail above). You can check it out the pull requests in the official page of the paper's authors: http://web.archive.org/web/20220412122303/http://cs-people.bu.edu/heilman/eclipse/ (I found out the site from the v0.10.1 releasing notes, in which three of them were fixed)

Very correct. If we want to be specific, the block time must be greater or equal with the median time of the previous 11 blocks + 1 second, and less than the adjusted network time + 2 hours.

These are the particular lines in validation.cpp that check it:

- GetMedianTimePast() can be found in chain.h, and it returns the median time of the past 11 blocks.
- MAX_FUTURE_BLOCK_TIME can also be found in chain.h, and it is equal with 7200 seconds (2 * 60 * 60).

Mine received it 2 seconds after yours. You could be the one who sent it to me.  

Depends on the exchange. If you use a truly decentralized, peer-to-peer like Bisq, then the risk is minimized. That means that you only hand over your bank info to some stranger. It's better than a centralized exchange which gathers thousand of clients' data, and much better from KYC-CEX, which gathers even more important data.

It's ignorant to think it that way. But even if it's that the case, the CEO isn't the only person who gets permission to view that data, and it's definitely beyond their permission if their database gets leaked and your data is being at sale for a few bucks in the dark web.

I would strongly recommend you to stay away from any browser-based wallet software. Besides known paper wallet scam-sites, as the ones mentioned, javascript (which is what they all use) is non-recommended by cryptography experts; https://bitcointalk.org/index.php?topic=5324030.msg56590276#msg56590276

I would add that they should verify the binaries using signatures from outside Github: https://bitcointalk.org/index.php?topic=43496.0

Two things.

• Broadcasting the transaction to the public isn't the same as having your real name tied with an address, publicly. Obviously, you send transactions to the public (ergo, broadcast them), because the ledger is public. What they probably meant is the latter.
• Nobody calls an address "public".

It is possible to broadcast any transaction. What's impossible is to "fake" a transaction if it isn't against the protocol rules. Double-spending a transaction doesn't count as "faking" if you redo the work.

There is no "fake longest chain", no matter how much we'd want it. There is the difficultywise-longest chain, and it's always the correct chain. If another one comes up, with more work, that becomes the correct one.

---

What is needed to be emphasized is that an eclipse attack isn't going to be effective if the attacker doesn't spend a significant amount of resources to redo the Proof-of-Work, which in that case, the network would be under threat anyway. The reason is that the attacker must maintain an entire chain themselves. If your node receives no blocks for hours, or days, you can make out you're under an eclipse attack. The attacker must solve blocks every 10 minutes to go unnoticed, which requires to redo a lot of work. They cannot re-create their own, little-worked chain, because node software comes with checkpoints.

That is my understanding as to why an eclipse attack shouldn't be concerning, but please correct me if I'm wrong.

Because it literally publishes itself as evidence that the same entity has been paying you? You should never reuse addresses, unless there is a significant burden with it. (i.e., if you're a signature campaign manager, it's time consuming and provides no tangible difference)

Come on, seriously. I think everyone can acknowledge that several topics are being recycled over and over, but is the privacy one really repeated? Because I mainly observe everything around price, government concerns, satoshi, and countries banning it / adopting it.

You'll have to spend change at some point, and at that point, you'll probably want to consolidate outputs. So what do you do? You mix.

Assume you make 500,000 sat change every month. Consolidate outputs you're confident of revealing common ownership, and send them over to a mixing-only Sparrow wallet. From that point on, you can select any of those spent change and use them in several coinjoins. The alternative, probably more expensive approach is to send change to a mixer.

Any Debian-based distro would be a safe choice. Mine is Ubuntu, but I've tried Mint and Debian. I just find the OS in total to be more comfortable in Ubuntu. That being said, every single of them will work fine for a node-machine.

I'd go with whatever you're used to. If you've used to Fedora, spin up Fedora. Just use an established one. We all end up using stable, large community supporting OSes. Don't install, for example, NixOS or Slackware.

In my humble opinion, as a self-proclaimed Bitcoiner, HODL means "no return back". When you HODL, you expect that the rest of the populace will follow on a Bitcoin standard, sooner or later. HODLing isn't to merely keep a bitcoin for a couple of years, just to sell it back for fiat (which is considered long-term for many).

I don't want to be called a toxic maxi, but it's just the way it is. If you don't think the people will treat Bitcoin seriously, then you don't either.

No. Just copy the application data to linux and run Bitcoin Core there.

Backup your application data, which is located in %APPDATA%\Bitcoin IIRC, to some external drive. Open up linux, install Bitcoin Core, let it run for a couple of minutes to start downloading blocks. Close it, replace the backed up Bitcoin app data to ~/.bitcoin, and restart Bitcoin Core. It will continue from where you left it at Windows.

Define me "timelocked". There's the "You cannot mine this until block x" timelocked (AKA, locktime). There's the "You cannot spend this until block x" timelocked. There's the "You cannot spend this after block x" timelocked*. All do lock to the future, though, yes.

No, it will be mined in 10 minutes, but the new UTXO cannot be spent until 2025.

Both of you refer to the locktime field. I was referring to OP_CHECKLOCKTIMEVERIFY. They are completely different. The former is checked when you attempt to include its transaction to a block. The latter is checked when you attempt to spend an output.

---

*This one doesn't really exist, but it exists in concept. It was called OP_BLOCKNUMBER, but the founder warned for security implications: https://bitcointalk.org/index.php?topic=1786.msg22119#msg22119

Does filling the post quota cross your mind?  

The easiest way to make abundant amount of topics, is to continuously praise Bitcoin. Bitcoin does this, bitcoin does that, and suddenly an endless page of meaningless posts is taking shape, because it is much easier to agree with someone, than to disagree (as the latter would require counter-arguments). It really doesn't matter if the author is correct; they have won, because of the Cunningham's law.

Kakmakr, don't take this as an offense (it really isn't!). But, I just have noticed lots of forum users doing this, hopefully unconsciously.

What you're really asking is if you can broadcast a transaction, have it mined, but lock its outputs until a specified time. This is "saving it temporarily", but "broadcasting it later". And there exists. It's called OP_CHECKLOCKTIMEVERIFY. Spending such locktime outputs before the specified nLockTime will cause the script to fail.

The particular feature you mentioned would be bad, because it lacks the spam protection from OP_CHECKLOCKTIMEVERIFY. TX A is unconfirmed, you bloat the network with "not-yet-mineable" transactions. Before TX A becomes confirmed, you double-spend it with B and now all the other transactions are invalid.

You could also not depend on that feature. What if most nodes' mempools are clogged, and they only keep transactions paying an x sat/vb, which is higher than yours? The transaction will not be broadcasted at the time you'd have scheduled it.

These are the steps, as I understand them.

• Node has 900 out of the 1000 transactions of a block.
• Mining pool, which runs a regular node, sends block announcements (via cmpctblock). These types of messages include a list of structures, containing the compacted block, like short transactions IDs and other useful info.
• When the node receives the compacted block, it requests via getblocktxn to get the 100 missing transactions from the other peer.
• Mining pool responds back with those transactions.
• Node verifies that the new transactions are indeed included in the block, by constructing and verifying the block using information from step 2.

That is brand new information for me. Kudos to cygan. There's just always something you don't know about Bitcoin.

I believe so, but there aren't any public data to verify that claim. It could be verified though. If you spin up a full node and recursively attempt to send compact blocks to the nodes that request it, similar as to getaddr by bitnodes.io, you can analyze their transaction requests and approach what is each node's mempool.

Yes, just don't. They're ridiculously expensive. In my place, they take a 7% commission when you're selling bitcoin. You become a target for criminals, and in case these two aren't discouraging enough, you're forced to submit KYC if you're going to cash out more than an upper limit. (in my place, that's about 500 EUR IIRC)

If the restaurant accepts bitcoin, then pay with bitcoin. But, obviously carry some real cash and electronic debit in case that won't work.

I think that the OS is what protects the user in the case that someone steals their phone. There is a timeout setting, wherein the user has to authenticate the transaction. I'm a Google Pay user, and I've noticed that if I leave my phone open for a couple of minutes, I cannot make a payment. I'll have to turn off and on.

Do we have data on thefts with stolen smartphones? I have never heard of such case once, and I'm pretty sure you can call your bank and reverse it before it's too late. Nevertheless, this means the merchant bears the financial burden once again.

Yeah, that seems like a couple of decades old.

I recommend you try out Kleopatra. It's for PGP newbies, and comes with a pretty neat GUI. It's the same software used in this Electrum verification tutorial. If you're already in Linux, just hit the following:

In Windows, it's a little bit more of a task, download the installer in here: https://gpg4win.org/download.html. Follow the instructions and tick Kleopatra if shown.