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.

You currently need at least 20sat/vbyte for it to even be broadcasted. The chances of it being confirmed within any reasonable timeframe is still very low even if you were to use 20sat/vbyte.

Some exchange actually has a fixed withdrawal fee. There is thus no difference between withdrawing at 10sat/vbyte or 100sat/vbyte for the user. Since the transactions can always be batched, the TX fees paid by the exchange can still be greater than the TX fee paid by the user to the exchange.

A notable example is Binance which charges 0.0005BTC per withdrawal.

There are also probably a smaller proportion of scheduled payments which cannot be delayed. Given that the high fees has persisted for some time, I imagine that there is no recourse for this.

Yes.

If you've never had a history of any unclean shutdown, there could also be a slight chance of some hardware failure. You can try checking your RAM (memtest86) and disk (crystaldiskmark) for any bad sectors. Bitcoin Core tends to magnify any insignificant hardware faults as well.

For the most parts, the reduction in fees would arise from the transaction being a segwit transaction and that is independent of the output addresses. The way that Bech32 addresses are represented does provide some sort of discount (3bytes per output) due to the different scripts being used, it doesn't translate to noticeable fees savings which is what OP wants.

As the debug.log suggests, there is some corruption with your files.  How did you shut down Bitcoin Core previously? Was it unclean or did you wait until the dialog to disappear?

Unfortunately, you have to build the database again. Try running it with -reindex-chainstate. It would work if your chainstate is corrupted, and is strictly faster than a reindex. If it doesn't work, then you'll have to do a reindex.

It really depends on your wallet behavior. Does you wallet actually check the mempool if its purged? (Perhaps someone who uses Trezor can chime in) If it doesn't, it'll probably be stuck at unconfirmed and it won't be removed automatically.

It is hard to say whether it would get confirmed or not. The transaction is still valid and the miners can still include it in their block if they want. The main difference right now is that if you were to be able to create a transaction spending the same inputs right now, it won't get rejected and have a good propagation, hence a good chance of a confirmation as well. I'd recommend you to try to switch to another wallet instead.

You're talking about altcoins. You need to exchange for them with Bitcoins and that assumes your recipients are willing to accept them as a payment. I don't see any point with sending payment that low, unless you're talking about an off-chain transaction.

You can consider using Lightning network for something like this, but of course your recipient needs to have a channel open first with some inbound capacity.

Purged from the mempool. Note that miners can include any valid transactions that they want and will often include some low fee transaction due to either them being paid or the transactions being their own. Even if the transaction gets purged from the node's mempool, miners who has seen it can still potentially (though very very unlikely) include it in their mined block.
Purged.

Your understanding is on point, you can post the TXID if you want but that'll result in some loss of privacy.

I've never used Trezor's suite but I'll assume that they do not purge the transactions themselves. If you were to use Trezor with some other client, Electrum for example, it should not appear or will appear as a Local transaction and you can remove that and resend again.

Please don't blindly trust anyone here, do your own research. The rank has little to no significance to their trustworthiness, there are plenty of examples of higher ranking members getting involved in scams.

The link to LoyceV's thread documents the proper usage of the trust system fairly well. Note that the Trusted/Untrusted feedback depends on how you structure your Trust list. Do try to modify your Trust List as you go along to include/exclude people whose judgement you find accurate/inaccurate.

It is a mining farm, not a mining pool. There is nothing you can do if the ASICs are offline due to a power cut or any unexpected events. It is simply not possible to transport so many miners within a short period of time.
No safeguards, other than the fact that miners are essentially burning cash this way. The time between blocks would be larger until at least the next difficulty adjustment.

Completely wrong. Any sudden increase in hashpower and consequently a shorter block interval would be offset by the next difficulty adjustment. Any effects would most likely be shortlived.