I think it's similar to this? It happened 2 years ago to me LOL.

https://bitcointalk.org/index.php?topic=2997750.msg30830914#msg30830914

Just click [All]. Somehow your post will appear as #21, though #21 in the single page mode is not your post.

For the getbalance, remember to specify minconf=0.

Anyways, is there an issue with doing it after consolidating multiple UTXOs? Monitoring the addresses and consolidating it to the HW wallet introduces an additional step that eats into your fees and the resultant number of UTXOs remains the same.

What I'll do is that I'll set a threshold, ie. 0.1BTC and when I have that amount, I'll get the client to send the funds to the HW wallet. If you are afraid of the risks of being exposed while your funds are being sent to your hot wallet, having automatic transfers doesn't do too much to eliminate the risk of malware attacks anyways. If that's your concern, your focus would be likely to just try to change the addresses to the ones in the HW wallet.

To simplify the process, you could use Tails. A benefit is that if you want to also wipe the wallet in the process, you can use their secure wipe which overwrites the partition so that it is irrecoverable. There's a guide within the Electrum's docs to document the process[1].



[1] https://github.com/spesmilo/electrum-docs/blob/master/tails.rst

---

My take is that, if you have some funds but don't want to splurge on a Hardware wallet yet. You could try getting a Raspberry Pi and setting it up as an airgapped wallet. While it can't offer comparable security to most hardware wallets, it does offer sufficient security for the price and the effort you take to set it up.

I've used mine on a Raspbian Image and it has been working pretty well so far.

I think that is a valid concern and they were definitely lacking in that part as compared to the other companies who do a regular scrubbing of their customer's data. That's why when purchasing a HW wallet, you're recommended to try to use a PO box or an alias which is what I usually do.

Trezor does have an existing SD card seed extraction vulnerability but that requires physical access and the passphrase to be cracked. Not a very big deal but it's definitely something to be concerned about. (If I'm wrong, please correct me. I haven't been following Trezor for awhile).

My question seems pretty trivial but why doesn't ChipMixer adopt Segwit yet? It was activated such a long time ago and even if they had planned to use Legacy from a long time ago, it seems like it would be better to have some mix of bc1 and p2pwsh addresses in the chips?

It would have significantly reduced the fees that I have to spend to move the chips to my wallet.

I don't think deanonymizing dust attacks are extremely common but I doubt there is a surefire way to differentiate pure spam and such attacks.

You can definitely "burn" the dust by sending it to a known burn address like 1CounterpartyXXXXXXXXXXXXXXXUWLpVr, 1111111111111111111114oLvT2 , etc. Or else, you can burn it using OP_return which eliminates the UTXO from the chainstate for everyone and doesn't provide additional bloat.

I think the problem lies with the economics of doing so. For some dust transactions, it'll possibly cost more than the dust itself to send and make sure that it confirms. For certain wallets, there are ways to just isolate the UTXO and ensure that your wallet will never attempt to spend it.

That's true but an expensive VPN doesn't guarantee that they're not collecting logs either. VPN servers are not extremely expensive to set up and when you factor in that cheaper VPNs have a larger userbase, more people are paying for the same number of servers and in turn making the profit margin bigger.

I don't trust VPNs to not keep logs, expensive or not because there is simply no way for anyone to verify that. I do, however appreciate some efforts to display transparency over what they do, like ProtonVPN having a transparency report. I trust them over most of the other VPNs partially because I'm a user of ProtonMail and I find their efforts at preserving privacy pretty commendable.

If OP wants something to preserve privacy with 100% certainty, use Tor. Don't bother looking for VPNs.

It's hard to say how severe his crimes were, given that we won't be able to tell whether the evidence were fabricated. I believe there were incriminating evidence in the laptop with the data that was copied. 

Actively facilitating illicit trades is definitely a pretty severe offence. I believe that he wasn't charged on the basis of hiring hitman but there was evidences of this happening. I don't think that the punishment should be that severe but I definitely think that the latter charges should be reconsidered.

The information contained within the blockchain has to be parsed because it isn't ideal for most block explorer to function. Notably, it doesn't interpret the addresses and your block explorer has to process and tabulate them by yourself. In addition, nodes also do not really take into account transactions that are not pertinent to your wallet, which is also why rescan doesn't work on pruned wallets.

You could try looking into the various open sourced block explorers on github. I tried running a block explorer once but it was quite resource intensive so I gave up. Most would require the txindex for the client to index other transactions as well.

I imagine that looking transactions up using your own node could be slightly difficult. Will have to enable TX index and possibly parse all the transactions into something that's optimized for searching, unless there is a way for the node to arrange them?

Yeah. Should download the dumps that they've curated, it's in SHA1 and NTLM. But again, I didn't find them transmitting the password over, but it's hard to tell in the future.

Bitcoin is designed to be transparent. What you need to do is use a mixer (like the one in my signature) or try using CoinJoin by trying Wasabi wallet to break the link between the coins.

Chipmixer is fairly cheap and efficient at breaking links with fairly little technical knowhows. Wasabi wallet would be more of a long term solution with Tor integration and stuff.

Ideally. Yes, as mentioned based on the heuristic used, you can possibly fool certain algorithm which determines the link based on the specific aspect.  I imagine you can fool the algorithm if the wallet were to allow the change address to be a different type (bc1 to p2wsh and vice versa) but it does have a very limited use case, as compared to a mixer which could destroy the link completely, albeit with some fees.
Yes. It was discussed earlier. It would be a service or could even be sent to an address which could be used for coinjoin afterward.

Well, I'm not sure about Armory but as o_e_l_e_o described, you can replace the amount with ! for which the client would adjust to spend all of the remainder after fees to the mixer.

A big advantage to this method would be the ability to select inputs using Coin control as well.

It only stores the block as defined in your size for the pruning. It does however, store all the transactions related to the wallet (and it's addresses) that you've synchronized with. Since it discards all the blocks prior to your pruning limit, it cannot retrieve any information about imported addresses/wallets.
Yes. The only disadvantage is the one you mentioned and that it is less useful as it is able to serve lesser blocks to it's peers.

I think you answered your own question. It isn't necessary for nodes to store the blocks once they are verified.

You have to preserve the history and that is done through the full non-pruned nodes like we have now. Synchronization is relied on those nodes to supply the full blockchain history.

I think the main issue of your question is the time and the bandwidth needed to synchronize the blockchain? I think having full nodes to not synchronize from the genesis block is out of the question; they will have to trust someone to provide the accurate and correct information which is not what Bitcoin is designed to do. Starting from n-100 block requires the node to obtain the accurate information about the state of Bitcoin before that and that is fairly difficult to do.

Bitcoin works by the concept of UTXOs and the synchronization process builds the chainstate as it validates all the block. The current pruning gives a suitable cushioning in case of a long block reorg.

---

I don't think having snapshots is the answer to the question of reducing the Blockchain. At least all the attempts I see so far compromises the ability of the client being independent and trustless.

The fake one has the exact same UI but it's embedded with malicious code which are not visible to the naked eye. To be sure that you're downloading the real one, don't do it from Play Store. You can download it from the site and sideload it into your phone using the apk file and I recommend doing a PGP verification before that.

MyCelium is okay for Android. Please don't use Blockchain.com's wallet. They have a bad track record of being competent in managing their user's funds and have been involved in quite a few blunders. If history is any indication, I can't recommend Blockchain wallet with their terrible fees estimation and deceptive user's freedom.

Hardware wallets are devices designed specifically to store Bitcoins and they cannot be downloaded. If you want to store Bitcoin, you're looking at a Bitcoin cold storage. It'll be better to have an airgapped wallet than simply a cold storage though.

That's the reason why most tracing methodology assumes that the change address is always the same type as the "origin" address. Most users won't think of using it to their benefits as it's always done automatically.

If your software doesn't give you the liberty to have multiple outputs, then it's probably not ideal. What I would do with Electrum is that I would send the funds to the recipient and specify the mixer address as well with a random amount as a placeholder, go to the transaction preview, see how much of the amount I'm left with after the fees and adjust accordingly such that the change is not sent back to anywhere else. Or else, script your own raw transaction.

This is a unique way of approaching the problem and none of the wallets, AFAIK will allow you to set a change address that is not generated from the seeds. They do have a good reason of course and I think this method is quite unconventional.

I think if we were to ignore the privacy part, since both Electrum and TrustedCoin would compromise privacy anyways.

Would it be better for TrustedCoin to be able to send a message containing the address to the user's 2FA app? Something like this[1] so it becomes more like a push notification. It eliminates the risks of having a malware, unless both the user's device and the computer are compromised. The main caveat that I can see from this is that it involves giving another party the transaction information which actually eliminates the privacy aspect completely at this point. At the same time, you can probably trust that the malware cannot modify whatever is displayed on the phone and that Authy or whichever provider is as trustworthy as TrustedCoin.

[1] https://gemini.com/blog/introducing-authy-push

There's pretty much no benefits to using static. It depends on the user preferences and is independent of any of the mempool conditions. If you were to use this, you can set whichever fee you desire. I don't recommend this at all, unless you're able to wait for long periods of time.
 
ETA and mempool are both dependent on the mempool conditions. ETA takes into account the general mempool trends which gives the user a less conservative estimate and you tend to overpay more for the fees but it'll ensure that your transaction will be confirmed within a reasonable timeframe (not far of a deviation from the numbers of blocks that you've set).

Mempool just takes into conditions of the current mempool conditions. It places your transaction within the x mb from tip. 1 mb from tip should give you a fair chance of getting into a block if a block is found immediately when the transaction is sent. It could be misleading if several blocks were to be mined in succession. Your transaction could take quite a while to confirm if so. I wouldn't recommend using this unless you understand what you're doing.

Specifically which period?

As you said, the difficulty adjustment is done every 2016 blocks. In the earlier days of Bitcoin, there were few miners mining and they were using CPU miners which is extremely slow. The period between each block was sporadic and it took much longer than 2 weeks to reach 2016 blocks. The first difficulty adjustment was in February 2010.

Since the lowest difficulty was 1, the difficulty(target) couldn't have adjusted to get the block interval to 10 minutes and thus it persisted for quite a while.