Electrum. Their 2FA TrustedCoin as well as their multisig wallet supports P2WSH but you can choose P2SH as well.

P2SH-P2WSH is quite rare I think, I haven't found a wallet that supports that as of yet. Its like a P2SH-P2WPKH but with P2WSH instead.

It's capped at the price of the copper membership which is currently 0.0006BTC.
No. It only unblocks the account. Units of evil decrease with time.

They use both.


The device itself is safe to use. It's more of a leak than a hack. User's shipping information were leaked because of their point of sale interface which was breached. The device and it's private keys/seeds are still safe.

Blockchain.com is ridiculously incompetent and I would steer far away from them.

As you've mentioned, you were hacked 3 years ago, why are you still trying to reach them? You probably won't gain a single clue by asking them anyways, they probably won't keep logs for so long. I doubt that they would compensate you for your loss or anything. Were you using Tor at the time of the hack? Is your computer infected with malware?

Won't do. Some of the new users that I've seen were urgently seeking some technical help with their transactions and would probably won't come back if they're made to wait. It is very easy to circumvent log in requirements or address verification. It is not tedious for them to farm large number of accounts at once.

On the contrary, with every trial of finding a clean IP, they need to solve the annoying captcha, register and see the warning. While they can probably shorten their time by using different IP range per trial, it would still be more tedious than buying a bunch of IPs and automate those tasks that you mentioned.

Disconnecting your internet when using Electrum is not sufficient. If you want to be foolproof, you have to set up a dedicated computer that doesn't go online and handles all your transaction signing. It is also known as an airgapped wallet. Those are slightly fussy to maintain and use but are fairly safe for most use cases.

If you want to have the convenience and not worry about leaking your sensitive information, you should be looking at hardware wallets. They can be used with any online computers as the seeds are kept within the device and it won't be leaked to the online computer. For newbies, it'd be far more convenient to use a hardware wallet instead of a cold storage. Both can be used with Electrum but it depends on which route you want to go.

The trick is to produce a block with your CPU pool. My ASIC would outpace probably thousands if not millions of actual PCs. A pool wouldn't pay out unless they generate a block that is why PPS is usually for more established pools because they can afford to pay out the funds in advance while smaller pools pays out in PPLNS.

---

Most cloud mining websites, or at least those legit ones takes in deposits for contracts to cover the running costs of their ASIC farms. If the funds gets locked in the multisig, then there is no way for them to pay off their expenses in the short turn and they might as well just mine for themselves. There is a reason why they sell their hashpower and that is to eliminate the possibility of profitability loss due to exchange rate or difficulty changes. Locking them in a 2-of-2 multisig with no mediator is dangerous. Either party could refuse to sign a transaction and effectively holding one another hostage over the funds.

I don't think trustless cloud mining will ever exist. The nature of cloud mining requires the payment to be done upfront.

Your wallet.dat should be located in your data directory which should be in /Library/Application Support/Bitcoin/ by default.

Find your wallet.dat and back it up to somewhere safe. After that, you can install the latest version of Bitcoin Core and wait for it to synchronize.

I'm having the same problem as well. I think that it is because of the use of v3 addresses. The gossiping protocol was updated to support v3 addresses only in this release, if I'm not wrong via BIP155. Older clients wouldn't be able to receive and see your node as they are not able to receive ADDRv2 messages, which is also why peers.dat for this version is incompatible with the previous. Are any of your peers 0.21.0?

You can try replacing the information in onion_v3_private_key with onion_private_key and it should revert back to v2 address and should solve your problem, if you want.

They don't understand addrv2 address type and thus won't connect to your node automatically.

There shouldn't be a problem if you're specifically connecting to that specific node using addnode/connect as long as your Tor version supports it, regardless of Core version. It doesn't check what kind of onion address type it is.

After reading the merged commits, there's more than the implementation of BIP155 and older nodes can't connect to v3 addresses as it won't recognize it though it doesn't throw an error when using connect=.

It sucks that dynamic IPs are abused so easily and that behavior lies with your ISP. The ease of changing IP just makes spamming a lot easier.

Unfortunately, the best way to deter spammers is through some financial penalty. The measures that you describe would probably put off most newbies when you subject them to such a long wait and the second wouldn't do anything to prevent spamming.
Not much, but presumably some if they are low enough. Residential IPs are not as blacklisted as VPNs and Tor IPs, unless those IP in the same range happens to be spamming the forum. I would think that it would be reasonable to allow those with higher evil units to purchase a copper membership from the beginning. After all, they could get something in return for paying the evil fees.

The evil fees decay with time and it's dependent on how many people abused that range of IP.

Do you need an account to see the posts? Most newbies that only seeks to use Bitcoin probably won't bother to use the forum at all.

That's unfortunately one of the tradeoffs associated when you have to actively try to fight spammers. If you were to take away evil score, it would be way easier for the forum to be filled with SEO spams since you don't have the need to rotate the IPs when creating an account. It's not possible for them to hide a newbie's post because it would be tedious for mods to be sifting through the numerous posts every single day on top of the normal spams. Newbie jails or any sort of it's derivatives does not serve useful in the long term; limiting newbie's discussions to a section will inevitably result in a single section having way lower quality posts than the rest and wouldn't result in most of the normal forum users to be engaging in discussions in that section. What's the use if you were to create a ringfence around them and not letting them discuss on the other parts of the forum?

Evil score is probably here to stay. Most users shouldn't be facing too much of an issue when joining unless their IP range has been infested with spammers and/or their ISPs assigns a very small IP range and you happen to be in the same IP range as the spammers. Here's a visualization of the evil score situation back in 2018: https://bitcointalk.org/index.php?topic=4101785.0.

---

Spammers.

---

The evil score is calculated with regards to how much spam has originated from that IP block. As such, the nature of most Tor and VPNs will result in some form of evil score. It's quite rare to be able to get an IP without any evil score on it when using Tor from my own experience but paid VPNs tends to be abused less. Having a newbie jail, or anything similar that you've described isn't an option, as theymos has mentioned. The problem is not with the scams but the problem is with the spams they would bring.

The way around this is to use your actual IP or go to a local coffee shop to register. You can continue using tor after that if you want.

You can lock the thread if you don't want any replies, though I'm not sure why you would want to do that.

I'm not going to suggest anything to help you synchronize quicker since you said so in the OP. Bitcoin Core's P2P protocol is fairly well established and I've always had an abundance of nodes to connect to after my client retrieves it from the DNS seeds. How do you think we can improve on that? Could you make a pull request on that topic if you have any good ideas?

I can supply you with a pre-validated data directory which would pretty much cut down your bottleneck to your I/O and also the download speed. The question lies with, are you willing to trust me? I'm just a stranger on the internet and you wouldn't know if I edited the chainstate to include transactions that wouldn't exist.

Ps. Just because you're having some problems doesn't mean the whole system is problematic.

Your transaction has replace by fee flag.

In Electrum, select and right click your transaction then there should be an option called Cancel (Double Spend) and it should show you your new fee rate. The new fees must be higher than the current fee by at least 1 satoshi/byte though to guarantee a faster confirmation will incur a larger fees/vbyte. You should be given an option with the floating fees slider.

If you can spot their mistakes, then you're probably not the person they're looking to scam. With most spam mails, they tend to have obvious tell tale signs but some are done intentionally. This filters the target audience and only targets those who are less meticulous and more gullible. Of course, this may not always be the case but it has happened often enough.

It isn't. The script hash format is defined here: https://electrumx-spesmilo.readthedocs.io/en/latest/protocol-basics.html#status. You can't reverse the SHA256 hash, you cannot get the inputs of that specific hash. This command merely indicates that there has been some changes to the address, ie getting confirmed or having new transactions. If you want, then you can call getaddresshistory whenever the status changes.

That's an altcoin.

When people talk about creating a Bitcoin with fundamentally different principles from Bitcoin for which the general consensus isn't reached, it is an altcoin. A fixed market cap is possibly one of the few things that Bitcoin shouldn't have to change as it doesn't necessarily pose a problem to Bitcoin as a currency. I don't believe you should adjust the block reward based on the difficulty as this will result in the price instability when compared to other cryptos or fiat. When the crypto isn't valued in terms of some other currency, it could make sense. Steady inflation isn't impossible and it has been done. It's viability as a currency remains to be seen.

It's not. If you look at the addresses in the transaction, the first few addresses are unique and forms a sentence if you put them together. It's a typical advertisement spam. Some bots usually parse the addresses that were in the earlier Bitcoin block's coinbase and sends funds to them with a specially crafted address as a form of advertisment, in hopes that they are of sufficient interest and people would notice them. It's only indicative of something when funds are sent from the address, not when funds are sent to it.

The method got changed to blockchain.scripthash.subscribe. You can't. The hash orders the transactions in specific order together with their confirmations, -1 for unconfirmed and 0 for confirmed. The way this works is for scripts to monitor and compare the hashes between different calls and they will know that there is either a new transaction or an unconfirmed transaction has gotten a confirmation, this allows for a quick and easy way to determine the status of transactions without much hassle. It's a one way function so you can't get the list from the hash alone.

If you want to get the list of transaction and it's information, you should be looking at blockchain.scripthash.get_history.

Doesn't have to be.

P2SH addresses (AKA those starting with 3) are defined in BIP16. It defines addresses which has a specific condition within the redeem script that has to be fulfilled for the transaction to be vallid. Multisig addresses do not necessarily have to be a Segwit; there are also bech32 script addresses (P2WSH) which allows you to have scripts in bech32 or P2SH-P2WSH which would yield a P2SH address but those are for a different topic. OP is specifically asking about P2SH addresses and they are versatile in the sense that you can put complicated scripts and conditions for the UTXOs to be spent. Most of the multisig that most services uses are not P2SH-P2WSH but are actually just a P2SH by itself without any witness scripts.

So, it'll be incorrect to say that all P2SH addresses are nested Segwit. Nested segwit is just a very small subset of P2SH scripting.