I'm sorry, my bad. I missed the part where you said it's still in the mempool. If that's the case, you need to use zapwallettxes and your wallet can't be pruned.

If it's pruned, then you'll have to manually craft and sign your own transaction.

You're comparing the value of Bitcoin to different metrics. In the context of Bitcoin, if you solely compare in terms of BTC, there is no way it won't hold true because 1 BTC IS equal to 1BTC. Time cannot be a suitable metric. If the price of Bitcoin is the same from 10 years ago to this day, would you say that 1BTC in 13/1/2011 is equal to 1BTC in 13/1/2021? Yes. Because the price and thus it's utility would be the same (people can still buy BTC at $0.1), even though it has been a decade. You're not measuring Bitcoin in terms of the time but you're measuring it in terms of it's fiat value.

Same as the argument from a business perspective. If I paid 10k BTC for a pizza, I'll contribute millions to their profits instantly but purchasing it back in 2010 would be just a normal day for the company. The only reason is because Bitcoin's main comparison is with fiat. 1 BTC in 2011 is not equal to 1 BTC in 2021, not because of Segwit, not because it has been 10 years but because the utility of having a Bitcoin has increased immensely, which is because it's almost always pegged to fiat which has seen an exponential increase.

Yes and no. Quantum computing is very useful for integer factorization with Shor's algorithm and offers an advantage for asymmetric algorithms to be cracked. This means that any pre-existing technology that uses public key cryptography, such as RSA and ECDSA are susceptible to such attacks. Is it more profitable for governments (presumably because they will have the budget required to operate one) to break TLS encryption or Bitcoin public keys? As of now, we're still quite a few years away from quantum computers with sufficient qubit to be able to crack asymmetric algorithms.

On the other hand, Grover's algorithm offers a quadratic speed up for symmetric algorithms. If your encryption cipher has a large enough key size, you're safe.

Abandontransaction would be more appropriate. It works for pruned nodes as well, zapwallettxes requires a rescan.

---

In the past, Blockchain.info used to have a double spend page which allows the users to test out their double spends. It executes a race attack by broadcasting a transaction to a few peers and the other conflicting transaction to another set of peers. It was an interesting experiment but wouldn't be effective since you'll just have to be well connected to different peers or just get a confirmation.

Just to add, transactions without opt-in RBF flag are still "reversible". Miners get to choose the set of transactions which are included into their block and thus they can easily ignore the legitimate transaction and include another replacement transaction. Ghash.io did it against a gambling site and they said it was done by an employee.[1] Of course, the replacement transaction still has to be signed so it's usually done with the participation of the addresses' owner as well as the mining pool but I haven't seen anything like that since then.


[1] https://bitcointalk.org/index.php?topic=327767.0

Electrum uses base43 encoding for their QR codes. It helps to save the limited space for QR codes and Electrum will decode it when you're using the desktop client to scan the QR code.

If you want to get it in hex format, you can just use this: https://github.com/jacoblyles/base43js. It's the only converter that I'm aware of.

If it still doesn't work, PM me the raw TX and I'll take a look.

You'll find their formula here: https://vanitypool.appspot.com/faq

It's not strictly speaking a mining pool since it doesn't split the rewards among those who works for it. It was very overpriced then and even more overpriced now, if you want any solutions. It's just basically a site for those who are interested in earning from helping others to generate their vanity address with split key generation. It's pretty dead nowadays.

It mirrors Bitcointalk's content. I would never go to such a site, they can easily replace the posts with something else and that includes addresses contained within the post. I'll be wary of such mirror sites. It's poorly formatted, not sure why anyone would use that.

There were several mirror sites but this is interesting as it has it's login disabled.

Depends on the configuration. If all of the signers are aware of the value and the destination of the transaction, then a replacement of the raw transaction would be fairly obvious. If you're doing n-of-m (2-of-3) multisig and the other parties are blind sided to the transaction information with no prior communication, then there could be a scenario whereby someone can craft another transaction that spends to another address and trick the others (2 of them) into signing it. As long as n(2) parties are tricked, the transaction will work.

What I'll do is to use a PGP signature or encryption to transfer the information. Of course, you need to authenticate each other's PGP in person to ensure this is secure. If the users are able to authenticate each others PGP, then you can be sure that the raw transaction is crafted by the legitimate person. Encrypting it would also prevent others from snooping and see which transaction belongs to you.

---

I've described a fairly hypothetical scenario where it's quite unlikely for any party to initiate transactions without any communication. It's still a good practice to have some proof of authentication before signing any transactions.

Your original version. Point to note, the reason why you're downloading this is to ensure that you can open the wallet file to export the seeds/private keys and not to send funds or anything like that. In fact, you should turn your internet connection off before opening your wallet file, those versions were also vulnerable to CORS preflight check vulnerability(unprotected JSONRPC). Absolutely do not trust any dialog that may appear to ask you to upgrade.

Bitcoin Core does not index all of the transactions by default. That is why Bitcoin Core needs to rescan the entire blockchain every time you import an address and also why you can't import used addresses without having to reindex pruned nodes. Bitcoin Core also does not parse the blockchain into the addresses format which is why you can't search up addresses to find the TXes related to them.

Importing an address forces Bitcoin Core to use some computing power to scan the blockchain for transactions related to your address.

You'll have some inaccuracy when using unix time as nlocktime, that is by design. nLocktime uses the median time past of the 11 blocks prior to the block that includes your transaction. As such, you might have to wait up to an hour before it can be relayed. Exact timing will not be possible.

---

Your transaction appears to be rejected with non-final. Is the nlocktime specified smaller than the current block height? The nlocktime specifies that the current block height must be strictly greater than the nlocktime. As for the decoding on transaction, I'm aware that Blockchain.com appears to be bugged and can't process the raw transaction.

That's noticeable as well. If you want to effectively censor a transaction(s), you need to be able to mine every single block since other mining pools would probably be incentivised to mine those transactions if they aren't mined. It'll be apparent once the other mining pool realizes that they cannot mine any blocks and the same thing will happen. It'll be far more effectively to just execute a massive doublespend attack and massively devaluate Bitcoin at one go, at least they stand to gain something from that.

The vision that Satoshi had with mining died once ASICs were introduced. The use of specialized equipment to mine basically removes the possibility of the average user to mine with their PC and expecting any profits. One CPU One Vote was built on the idea that every computer has somewhat equal chance to mine a block and expect a profit at the end. This doesn't hold true once Bitcoin took off and arguably POW schemes are not ideal for such assumptions, is there really any that would've worked?

The profit margin depends on the expenses incurred and the type of equipment used. Mining farms are great at it because they can afford to rent a huge space and have access to cheaper ASICs in bulk. Everyone can still validate transactions/blocks on their PC, that doesn't change with the difficulty of mining.

Hardware wallets are not the same as offline, air gapped wallets. You're likely going to connect to an online computer with a wallet software to make transactions, unless of course you do it offline which isn't very reasonable when you've shelled out so much money for an online wallet.

Conversely, if you're comparing the price of a printer (dumb and cheap as mentioned by o_e_l_e_o), you'll be probably looking at something similar to a Raspberry Pi, at least for where I'm from. The creation and the spending of the paper wallet should ideally involve an offline computer that's wiped clean. Using an airgapped wallet and writing the seeds down would probably be better than printing and using a paper wallet, given that it would simplify the generation of different addresses and spending of the funds.

They won't. Bitcoin is a speculative assets and tends to have a very large fluctuation in price. The total market cap, or if we consider the actual market cap of Bitcoin is very low as compared to the markets of precious metals and other reserve assets. Governments can at best have a tiny percentage of it in Bitcoins and it is not practical.
Bitcoin is created as an alternative to government controlled currencies, no? Why would we care what government prefers.
Bitcoin can be divisible even further, it's just a matter of protocol change. The day 1 Bitcoin = 1 Million dollars isn't going to happen anytime soon, don't worry.

---

I don't see the practicality of on-chain transactions solely for the fact that merchants can barely accept unconfirmed transactions and having a huge fees with most transactions. I see a future with lightning network and other similar offchain solutions taking the role of daily microtransactions and stuff.

Using Chrome. Yeah, doesn't look to be affecting Firefox.

If you were to convert the private keys to another format, then there is no point for you to get a vanity address because you'll be generating a totally different address. You can use uncompressed keys with bech32 addresses but they are non-standard, so you shouldn't do it. If the vanity gen produced uncompressed bech32 addresses, then you shouldn't use that specific vanitygen.

---

AFAIK, vanitysearch does standard bech32 addresses so it's fine.

Oh I see. I didn't notice that. Yep, that's probably it.
Only happens when you're opening the link in a new tab. Refreshing the new tab solves the problem.

---

Broke the merit extension that I'm using too but it's no big deal.

I've been getting a bunch of error 403 when opening the pages in a new tab. I've tried clearing cache and it still persists. Is it a forum-wide issue or is it just me?

Do you read and review the source code?

Don't get me wrong. I also prefer open source codes over closed source ones but its a stretch to assume that just because something is open source that means it's completely safe. That's the same sense of security that phishing attacks has evolved to exploit. Some users were tricked to install fake versions of Electrum that were hosted on github. Some users assume that just because it's hosted on github and having the source code visible (albeit modified with small malicious codes), it is safe.

The point I'm trying to make here is that just because something is open source doesn't mean it is superior over another that is closed source. Ledger has a NDA which means their secure element cannot be open source. Some prefer Ledger and some prefer Trezor but most don't consider the fact that Ledger doesn't have an open source secure element firmware. Hardware wallets are for-profit companies and they have to keep certain proprietary contents secret.