Completely wrong.

You can't. P2SH addresses are identical to each other and there isn't a way to tell if they're a musig (except taproot but that isn't the point of the question) or a P2WPKH nested in P2SH (for simplicity I refer to this as P2SH-P2PWKH) address/other locking conditions. The only time you can differentiate the kind of address is when they sign and spend any UTXOs, the redeem script will reveal what kind of locking script it has.

You don't have to care if the address that you're sending to is a segwit address or not. It doesn't make a difference. As long as the inputs are segwit, the size discount applies.

---

I've sent two transactions, one to a P2SH-P2PWKH (non-bech32) address and one to a multisig address.
To a P2SH (with multisig) address: efbc21dd2e2a1dc3ff67f853b550b5bab26f3f1a7f7960b0949bd0133f5d9e03
To a P2SH-P2PWKH address: 4a32b0eafad34f5c51c31cde881ecccd5d8a596400abd8b6269608492c6af719

For both, the size is the same at 142vbyte as the conditions are the same except that they're spending to P2SH addresses with different unlocking requirements.
For both, the output script is similar: OP_HASH160 [RIPEMD160(SHA256) hash here]OP_EQUAL

However, when I spend them:
From a P2SH (with multisig) address: 015739847a882dd1d3fb6c1792682cedb0d4155c4f508909cc280d3edf9bfad0
From a P2SH-P2PWKH address: 9dbf5fa4b8b8ffcedceb10ea59be46bb6aeec2b50f817a02a565ed314ea866e2

You can observe that the redeem script contains the requirements to unlock that script and/or the HASH160 of the original address and it's witness.

There are of course a myriad of conditions to be used in a P2SH address but I chose Multisig as the simplest and most common form of it as a demonstration.

It's not a BIP39 seed, the number of words should be in multiples of three.

You can try importing priv_sipa as mentioned in that thread:
1. Install Electrum from https://electrum.org/#download.
2. Install the wallet and initialize it.
3. Import Bitcoin Addresses or Private keys
4. Paste the priv_sipa in.
p2pkh:5...
p2pkh:L
p2pkh:K

I'm not sure whether they're using uncompressed or not but you can just substitute the characters after the semicolon with your private key.

Go to Window>Console and type in this:


I'm not too sure of the result since such message would usually be shown only after that specific block has been invalidated after a user's interaction. Perhaps this would help in your case.

What version are you running?

It is mostly the blocks. Other than that, the chainstate takes a smaller amount and it contains all the UTXOs. What I meant was, transactions are not indexed. This means that you cannot just ask Bitcoin Core what's the raw transaction or the information of TXID X because it won't know where to look for it. That's where txindex comes in to properly index each transaction and gives Bitcoin Core a pointer to know where to look for that specific transaction.

Yes. Bitcoin Core does store the blocks and their transactions, I think you misunderstood what I was saying. The reason why you have to rescan is because Bitcoin Core doesn't maintain an address index.
Bitcoin Core does not organize all of the transactions by their addresses. If a user were to try to get information about an address, like importing a watch-only address, Bitcoin Core will rescan through the whole blockchain to find transactions that is related to that address. Addresses don't exist at a protocol level in the first place.

I don't think you understand how mining works. The difficulty is adjusted every 2016 blocks and it is proportional to the total hashrate of the network. Bitcoin could get way easier to mine then due to the perceived lower block rewards or it could be harder if the transaction fees and the price of Bitcoin outweighs the cost of mining. The cost of mining does not usually affect the market price of Bitcoin, the supply and demand dictates the price movement.

Eh, believe in what you will. You won't be alive to see it. Bitcoin could be replaced by something better for all you know.

Depends on how long your password is. I can't find the exact specification for their seeds generation or encryption for that matter, can't help you there sorry.
Copy the line of numbers that's displayed in the box.

Go to coinb.in/#verify and check that the transaction checks out. If it does, go to coinb.in/#broadcast, paste the same line in and broadcast to the network.

Either reindex or if you prefer, you can try to reindex the chainstate instead. It will help you to avoid downloading the entire blocks over again (also avoiding the time consuming indexing of your blocks) and instead rebuilds your chainstate only.

You can use -reindex-chainstate when starting Bitcoin Core.

You can easily broadcast signed transactions using: coinb.in/#Broadcast.

I assume the transaction is signed? You can also script your own raw transaction, decode and sign them on the same site. I would recommend to do those offline if you have to. It has to be broadcasted online.

Edit: Isn't there a button that lets you broadcast the generated raw transaction?

The leak affected the privacy of their user. It does not directly affect the security of their devices. The post I replied to was to ask if it's secure to continue storing the funds within Ledger.

I won't discuss how they operate as a company because that wouldn't be related to their data leak. Objectively speaking, yes. The loss of privacy could to some extent lead to them being more vulnerable to spear phishing, targeted attack and stuff like that. But how would it affect the security of their devices? Can you obtain the private keys and/or the seeds from the devices with that information alone? If you could, that would be in conjunction with some forms of social engineering attack and/or $5 wrench attack (though I heavily dispute that but I don't live in the same region as most of these users).

All the addresses displayed are generated with your 12 word seed. Pressing receive would just generate an invoice that's tied to your wallet. You should still be able to see and spend the funds sent to that address.

Transactions cannot bounce as there is no system to record whether a button is pressed or not. The reason why the receive tab exist is to have an UI for the user to create an invoice. If you were to check the addresses tab, you should still be able to see the address in the list.

That's alright. Just upgrade your wallet after you're done extracting the keys.

I assume it didn't have to go through any customs? I had quite a few package being sliced open and checked when they went through the custom in my country.

For Amazon.com, it appears to be fulfilled by Amazon so it'll be stored within one of their facilities and it brings about an additional layer of middleman that could pose a security risk. I wouldn't be too surprised if it was returned and they didn't sort it out properly and it got resold again.

Can you decode the transaction on any websites and/or wallets? Try https://coinb.in/#verify.

I had difficulties pushing through blockchain.info so that's not a very good website. If you don't mind, you can PM me the raw TX and I'll see if anything is wrong. It's hard to see the problem and I can't reproduce it.

Having the transaction appear in block explorers doesn't mean that it is necessarily valid, when it comes to the timestamp. The network consensus with BIP113 is that the timestamp has to be the median of the last 11 block which means that it can deviate from the actual time by 1 hour, and that explains why your transaction couldn't broadcast at 7PM and you could at 8PM. If you're looking to do nLocktime, you should set it an hour in advance.

The fact that the blockexplorer threw a non-final error basically shows that the transaction is still behind the unix time. I'm not sure why Blockcypher accepted it but if it didn't get propagated, then their timestamps logic could be wrong.

Yes. Out of sync clients are not exactly great for sending transaction as there'll be a chance that you'll be creating invalid transactions (a transaction that selects UTXOs which are already spent), which is AFAICT is your case.

The address that you've provided doesn't seem to have 0.01BTC and it appears to only have 0.0026BTC, unless you're spending in conjunction with other change addresses. Until you synchronize your client, you cannot tell the actual balance.

The problem here isn't with your fees (though it could be). I suspect your client created an invalid transaction which spends coins that has already been spent.

You can try exporting the private keys of the relevant addresses and importing them in Electrum if you can't wait.

The leaks doesn't affect the security of your Ledger. Ledger should not store any information about the individual wallets that would otherwise compromise your security. Hardware wallets should not record these kinds of information anyways. The leak in question specifically impacted the privacy of the customers through the reveal of personal information.

Your transaction cannot be broadcast as the service cannot find the UTXO or the TXID that was referenced in your raw transaction. The transaction that created the UTXO was either replaced by another transaction or dropped from the mempool. If it's the latter, you have to get the raw transaction of the referenced TXID and rebroadcast it. If it's the former, then you have to contact whoever sent you the BTC.

The minimum amount of fees would be 1 satoshi/byte. Are you using the recommended fees or the custom fees? If you could, you can possibly set it to the lowest amount but it probably won't be confirmed anytime soon.

You might have quite a few small UTXOs and the size of your transaction could've been relatively big. How many transactions have you received using that specific wallet file? The transaction fee rates has been fairly high recently as well.

The UPNP library included with certain versions of Bitcoin Core were susceptible to buffer overflow. This potentially means that an adversary executing an attack against you could take advantage of that to do a remote code execution.

You just have to disable UPNP in the settings, turn your internet connection off and it should be fine. It's not that easy to exploit.

You're right. Wrong choice of word, price should be adjusted for inflation. The rest of the argument should hold true still.

You're still measuring Bitcoin in terms of it's utility as a currency. 100 USD in 2010 is the same as 100 USD now. Sure, you can't get the same amount of marginal utility but it doesn't change the fact that the numerical value is the same.

The main argument surrounding those who are arguing that that doesn't hold true in the thread is about how spending a smaller amount of Bitcoins would've probably made no difference in the campaign. It'd be wrong to say that they were arguing from the POV of how much 1BTC can bring. Of course you'll reap more benefit from 1BTC now than 1BTC 10 years ago.