No. It imports your master public key into the wallet which makes it a watch-only wallet and you unable to spend the funds.

I'm not sure how you're generating a watch-only wallet if you're entering the seed, there isn't any type of seed that would specifically give you a watch-only wallet. As for the wallet on your old computer, do you see a germinated seed at the bottom right? If so, can you click on it and see your seed phrase?

Your long term scalability problem doesn't lie with on-chain transactions; you can really only do so much if you don't want to raise the block size. Instead, using 2nd Layer like LN would solve the scalability issue much better without all the politics that goes into making changes to the protocol.

LN is fortunately not a short term solution but the adoption is still fairly low.

Might be a redundant question but is your Bitcoin Core synchronized? My current solomining setup still functions fine and there doesn't seem to be anything wrong with your config.

P2SH, P2WPKH/P2WSH are all different from each other, as defined in BIP141[1]. The link should answer your queries, scroll up to look at P2WPKH as well. P2WPKH and P2WSH have 20 bytes and 32 bytes of data being pushed onto the stack respectively.

The OP codes are defined in the script hash. Hashing the redeem script allows the nodes to correctly hash the redeem script defined in the spending transaction to your address, together with the conditions and thus verifying that your transaction meets the requirements.

[1] https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#P2WSH

---

Multisig is not the only use of P2SH. There are OP_CLTV, anyone can spend and this[2].

[2] https://bitcointalk.org/index.php?topic=293382.0

Depends. If you're talking about transactions without a physical item, it would be fairly easy. I don't think its particularly hard to provide any evidence (if they even ask for it that is) and they almost always tend to side with the consumer instead of the merchant. Having zero risks with chargeback is far better than having to shoulder the losses from something like that.
The criteria for chargeback is just so broad. Unfortunately the reality is that, banks probably won't bother trying to investigate it and just rule in favour of the consumer. I've had an experience with purchasing some computer parts and it arrived with the pins all bent and it was packed terribly, merchant doesn't want to refund or even replace it for me. Called up my bank, said they will investigate and it took a week or so. Never asked for any proof from me and I don't think they needed any proof from the merchant.

Anyhow, unless you're using lightning or any off-chain solution, accepting Bitcoin as an on-chain payment is far too expensive for both the user and the merchant.

Each Bitcoin output (UTXO) has a specific requirement for it to be spent (ie. conditions for a transaction containing that to be valid). For most, the requirement would be a signature that is signed with the appropriate key and without that, it would be an invalid transaction and it cannot be included in the blockchain. Any blocks that contains an invalid transaction will be rejected by the reference client. There are scripthash addresses with different predefined requirements for it to be spent and those might not require any signature at all, just the conditions to be met.

If you can't meet the requirements to spend that output, you cannot create a valid transaction without it. If you've lost your private key, then there is no way to sign it and there is no way for you to recover the funds.

I consider this site's methodology a lot more reliable than other stats: https://cbeci.org/.

PoW is probably one of the most secure systems out there. It functions on the basis that certain resources has to be exchanged and hence it is called proof of work. The game theory behind this makes Bitcoin secure and IMO is quite irreplaceable. I think the environmental concerns are valid but it doesn't mean that the benefits to using this doesn't outweigh the cost in terms of negative externality (namely the environment). As renewable energy are actually more widespread in Bitcoin mining, you can justify that it still helps to offset the cost of the R&D and the cost of building those facilities.

Yes, it is still very much a prevalent issue as it doesn't solve the problem of e-waste among other things. I'd still argue that the tradeoffs is still worth it considering the utility of Bitcoin.

In fact, it happened to ChipMixer recently[1]. I suspect it would be something similar to BGP poisoning in conjunction with a hijacked HTTPS certificate. CAs are responsible for issuing the correct certificates and something like this wouldn't have happened if the certificate wasn't issued; it would either have to be non-SSL site or it'll throw an error. There are mitigation available for these attacks but the onus is on the ISPs to implement them.

[1] https://bitcointalk.org/index.php?topic=1935098.msg56179978#msg56179978

Well, to each their own. I personally don't find that there is any point with purchasing the private key to any addresses. There is really nothing to boast about having access to an address that used to have loads of Bitcoins. Could be useful if you're pretending to be someone who was an early adopter of Bitcoin.

There were some people who bought addresses during the ClamCoin era if they were able to get the ClamCoins from them. Most "airdrops" or anything similar are probably mostly associated with scamcoins and aren't very useful.

The way Electrum generates the seed makes the derivation path and the seed type unambiguous when compared to BIP39's implementation. It wouldn't help to try to derive an address of a different format using the other key. It makes the whole process far more complicated than needed.

Just generating a BIP39 seed (and selecting appropriate derivation methods) would be far better than going through additional loops that could be prone to user errors.

Electrum cannot sign transactions from Coinb.in. Importing the unsigned raw transaction will result in Electrum showing it as signed. Besides, I can't really recommend anyone trying to modify the fees themselves, it is very easy to accidentally include too much fees.

As for OP's issue, I agree with the assessment above. If the transaction is spending funds from your wallet, removing the transaction would result in the wallet showing that it has never been spent and thus you can spend it again. It is just strange that the Bitcoins aren't available to be spent again.

I think you have a slight misunderstanding regarding this issue.

The actual transaction with the overflow is actually this [1]. It is a valid transaction and for every valid transaction, the inputs has to be mapped to another TXID and in this case, 237fe8348fc77ace11049931058abb034c99698c7fe99b1cc022b1365a705d39:0. There is no extra 0.5BTC that was caused by the overflow incident. The transaction in question generated 2 outputs of 90 million Bitcoins each and it was "reversed" subsequently, excluding that transaction and continuing on the correct chain which doesn't contain any TXes affected by the overflow bug. The Wiki is stating that the 0.5BTC used as the input in that transaction has since been left dormant[2] after the overflow transaction was reversed.

[1] 1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9
[2] https://blockchair.com/bitcoin/address/17TASsYPbdLrJo3UDxFfCMu5GXmxFwVZSW

Transaction size are independent of the amount being transacted. It'll depend on your number of inputs and outputs, type of transaction (Segwit or not), etc There should be some utility In C# which is able to interpret the witness discount for the virtual byte. You shouldn't consider actual size as that is not what most of the miners consider when choosing transactions.

There are various formulae available for the calculation, which gives a very close approximation and is not always perfectly accurate. Use this web utility as a guide: https://jlopp.github.io/bitcoin-transaction-size-calculator/.

Paying a high fee rate will.not give you an instant confirmation but it would improve your chances of the transaction getting confirmed within the next few blocks.

Can the mempool.space API[1] help with this? It'll give you a pretty reasonable estimate for Satoshis/vbyte.

[1] https://mempool.space/api

ViaBTC could work but that'll merely be a temporary solution.

Given how small the outputs are (if that is the actual payment), then most of the users spending them would be spending more on fees than the total value of the UTXO. Probably would be worth it to consider the participants as well. Who knows? Perhaps the fee rates would persist over a longer period of time?

If assuming whatever they claim is true, then perhaps it would be unavoidable either ways. MITM attack like these are not that uncommon. If the attacker is able to obtain a signed SSL cert from a trusted CA in the victim's OS, then it would appear as though the connection is normal but the contents could be modified or the traffic could be intercepted.

There is no queue system in mempool. The transaction is most likely not in any node's mempool**. The estimation is based solely on the number of the blocks needed:

1. If there are no new transactions
2. The miner strictly fills the block based on the fee rates.

Neither is true so it is an inaccurate estimation. If it doesn't get purged from a specific node's mempool for some reason, then it would just linger in the mempool until it gets purged for being in the mempool for an extended period of time.

** Which is also why I don't think it has a chance for a confirmation at all.

Not really sure why people would actually care about Bitcoin when there is a war happening. Mining would probably not be possible, if the electrical supply is unstable. I'd imagine that the censorship issue is probably as easy as bypassing the GFW.

There are ways to communicate without the internet, all you need is some medium for the information transfer to occur. Blockstream Satellite is a good example of how it can work.

I've always been under the assumption that the chip was closed source. It was described in the article:

You shouldn't visit the site directly to run it offline. Rather, you should download the codes in its entirety from Github, validate it and run the html files. Directly downloading the webpage alone is not enough, it can easily be modified with a MITM attack and compromise your security.

But yeah, AFAICT, the fact that it salts your entropy with some mouse movement and various factors should mitigate the ramifications of the browser's CSPRNG not working as intended to a certain extent. JS is certainly not suitable to be used for paper wallet generation.