Obvious question but have you tried changing your circuit? I've noticed that my connection can be quite slow at times. Changing the circuit a few times has always solved it.

@LoyceV, wrong topic perhaps?

Firstly, it would require a hard fork. You know that doesn't resonate well with some people and it would inevitable lead to parties supporting/opposing it.

Anyways, I would expect botnets to have tailored malwares if that would ever occur. It's also quite a problem to determine if a node is truly helping the network or just collecting the incentives. It's not possible/resource intensive to make sure everyone is actually running a node (ie. not just serving the block when asked or just broadcasting their useragent without having any blocks in reality, etc). I don't expect to see this happening at all; Bitcoin works fine as it is now and centralisation is not the greatest problem that we have in terms of having people run validating node (pruned or not).

That is correct. Satoshi actually briefly mentioned the fact that a miner would gain more by being honest than if they were to attack the network. I doubt it would be easy to solve it on a technical level without compromising the trustless and decentralised part of Bitcoin. I would love to read up on solutions that could potentially do it without compromising them but I've yet to come across any.

I don't think there is a reliable way to check. Recaptcha is notorious for being secretive with their algorithm and I doubt they would reveal the actual probability this easily. The general rule of the thumb is that; if your IP is listed as a Tor exit node and/or a lot of spammed has passed through that IP, you're going to get ReCaptcha'd.

It does. It counter intuitive if you were to log into your own Google account. It's likely to ask you for a phone verification which isn't difficult to circumvent but is troublesome.

Electrum runs its own proprietary server and you'll need to install their software to be able to use it. I would recommend you to install and configure your own Electrum Personal Server [1] and use it from there.

If not, there's an alternative[2]. It connects directly to your Bitcoin Core RPC but it hasn't been tested extensively yet.

[1] https://github.com/chris-belcher/electrum-personal-server
[2] https://github.com/shesek/bwt

We've had quite a few discussions on the forum on this. Unfortunately, without 2FA I think captchas are imperative to try to prevent brute force attempts given the nature of Bitcoin talk accounts.

Tbf, the most annoying part is probably the creation of the account and you can use the log in link after that.

It's not possible to do so. Bitcoin doesn't exist as a physical commodity and there is no way for them to search your house and find your private keys (using methods like steganography). Gold is much easier to find, in comparison.

The decentralised nature of Bitcoin makes it incredibly hard for the governments to ban Bitcoin by restricting the internet. Use of VPN and/or Tor would easily defeat it. In any case, the only viable option is to try to reduce the use of Bitcoin but there are ways to circumvent that too.

No it isn't. You're quoting the user "noorammak" and for some reason, his subject on the topic's reply was changed to Vietnamese (?).

The browser and the forum is completely fine. Your reply's subject is Vietnamese because you're quoting and replying to that post specifically.

There are a ton of factors that has to be considered for this scenario. Assuming everything remains constant, then the fees would increase.

However, that is not the case. Electrical fees would decrease overtime with sustainable energy, ASICs will become more efficient, transaction capacity would increase allowing for more TX/block, difficulty could drop, etc. The transaction fees market works as with any other free market and adjusts itself into an equilibrium in tandem with the difficulty. It's pretty well thought of, if you'd ask me.

It definitely is. This scheme would stand to benefit from Schnorr as well. I was exploring the option whereby it doesn't necessarily have to follow a conventional method.

---

Thank you all for the reply. The purpose of this topic was mainly for me to explore the script used for that specific transaction scheme and not exactly to discuss the viability of the solution. Its great to see the discussion stemmed from it though.

It wasn't. The first transaction was between Hal Finney and Satoshi and the amount was 10BTC only. It was a test transaction and not for any monetary value. Satoshi never (to my knowledge) actually sold Bitcoin for fiat.

The exchange for fiat was between different users.

IIRC, yes. They will send an email to tell you that they're closing your account and for you to withdraw.
I would say that what the services are postulating for the closure of accounts is toxic for the development of Bitcoin. That is also the reason why  I prefer having zero central authority when dealing with stuff like that. Some point in the future, most of the coins would've been tainted and it would only serve as alternate reasons for the exchange to avoid dealing with you. Until the regulatory pressure on Bitcoin eases, I doubt this would stop happening for major exchanges.

I vaguely recall years ago, I stumbled upon a topic for a discussion on how Multisig could be scripted such that:

There are 3 keys for 2 of 3 multisig, A, B and C. A is the master key and its signature is required such that the transaction is invalid without its signature. (or something similar)

I was pretty intrigued by the scripting of the redeem script at that time but I lost the link to it. I've been trying to find that topic for the past week but I can't seem to find it anywhere. Can someone direct me to it?

I believe he is referring to the Open Wallet option in the file tab at the top. It allows the user to choose between the wallets within the data directory itself.

OP, as long as the wallet.dat is put into the data directory correctly, there is no reason why you would need to touch the Open Wallet dropdown box.

It was more of an issue in ~2013-ish when on-chain gambling was more prevalent. Agreed, it would not make sense for the miners economically. Barring the miners collectively having the same agenda (unlikely) or a 51% attack (very unlikely), I can't see censorship being implemented effectively besides perhaps a minor inconvenience from certain miners refusing to mine some transactions.

Depends on what you mean by censored.

There was once a patch on Bitcoin Core that could be used to filter and refuse to mine known gambling addresses (those of satoshidice and on-chain gambling). This wasn't particularly effective as a lot of miners and users didn't run this.

Exchanges has been and are still closing accounts if the origins of the coin has been tainted (either through a gambling site or illicit activities). They are still actively doing so, Binance and Coinbase are good examples.

Miners ultimately decide which transactions should be included. If they want, they can collectively refuse to mine certain coins though that has never been the case.

Yes. It'll be the best for you to go ahead and synchronize your Bitcoin Core again. It's quite tedious to export all the keys and import into Electrum manually. Using Bitcoin Core is the only way for you to guarantee that you get all the Bitcoins in the wallet.

Block header, which is a small part of the data of Bitcoin blocks.

The website for Electrum is electrum.org, do note to verify the authenticity of the download before running it. Follow the guides given by ETFbitcoin to export your addresses. I assume you know which of the addresses have the funds?

That is unfortunately the cold hard truth by all means. It's definitely a basic courtesy to thank someone for their hardwork and spamming up the forum is definitely not the way to do so. If you'd like, PM them or give them a merit to show them your appreciation.

Bitcointalk is a forum with a spamming problem. If we were to allow this, you'll just see spammers going around saying thanks to everything. I don't think this is a good precedent to set and that is the moderator's stance, like it or not. Also note that we're not banning you from saying thanks; you'll have to show your appreciation and add something to the discussion as well.