To what type of address did you send the BCash? A BTC legacy address starting with "1"? A Segwit "bc1" address? A multisig or transitional Segwit address starting with "3"?

If you sent to a legacy "1" address, then the BCH can be recovered. However, this needs the cooperation of Localbitcoins.

You want to leave this at 210000, otherwise it will take over a thousand years to exhaust the mining reward.


If you start at 500 coins, then the halving schedule goes 500, 250, 125, 62.5, ... So, you need three cycles more just to get down to close to 50.

If you really want to ten times more coins, with the same emission schedule, then set artofwarsatoshi to 0.0000001, i.e. ten times bigger. Your starting reward is 5,000,000,000 artofwarsatoshis.

USDT is a token handled by the OMNI network* which rides on top of Bitcoin. OMNI transactions are Bitcoin transactions with a few extra payload bytes. Thus, USDT and OMNI addresses are simply Bitcoin addresses.

It would appear that Huobi and Gate.io are simplifying the management of keys by using the same addresses when possible.

* USDT also now exists on the Ethereum network, but this is a new variant.

I have successfully installed 3.0.6 on two old systems running Windows 7.

I suggest you read some of the threads in the Electrum subforum here for solutions to getting it running on old OSes.

Chase, not BofA, was strong armed by the government into buying WaMu. BofA itself is of course NationsBank who acquired BofA and assumed that name.

0.002 BTC sounds like the 2 factor security fee. This is collected once for every 20 transactions, i.e. the following 19 transactions won't have a fee.

Recently I set up Electrum watch/receive only wallets on a computer and tablet for Point Of Sale use. The lack of a password means that someone could come by and load a different xpub and thus capture our received payments.

It is more important to buy the Trezor direct from the manufacturer. In theory, someone could load compromised firmware into a Trezor, repackage it, and sell it on to an unsuspecting buyer. Trezors come from the factory containing only a bootloader, forcing buyers to load fresh firmware. If the device arrived already loaded, then something is wrong! However, a clever hacker could still get around this protection.

The Ledger apparently performs a validity check with every use. Thus, you can have a higher confidence that the firmware isn't compromised. Plus, Ledger's use of a Secure Element (an I/O limited 2nd microcontroller) makes it a lot harder to hack.

Both devices can fall victim to social engineering. A crook could preload a seed and trick people into using it by including an "updated" manual. To protect against this, a user should spend time on the Trezor and Ledger sites and learn about how the device should work. If the received device acts differently, then something is wrong.

...

The two devices have vastly different approaches to security:

Trezor has security through an open source design. This has allowed "white hats" to discover flaws. Conversely, it also allows "black hats" to create malicious clones.

Ledger has security through obscurity. Nobody outside of Ledger knows fully what is going on inside the Secure Element. But what happens when the secret leaks...

The general Birthday Problem answer applies: For 160 bit addresses, a collision becomes more likely than not when approximately 2^80 addresses have been generated.

How big is 2^80? Presently there are around 2^33 humans. The human lifespan is around 2^31. If every human generated one address every second their entire life, that would be 2^64. There would need to be 65536 earths before the collision chance crosses 50%.

FIFO reporting only applies when you've commingled tranches. As long as they stay separate, then FIFO can't apply.

Scenario: Buy crypto on CB, transfer to a hardware wallet. Later, buy more crypto on CB and transfer to buy alts. The two buys didn't mix, so no FIFO.

Another scenario: Buy crypto on CB and leave it on CB. Later, buy more crypto on CB and transfer that quantity to buy alts. The two purchases mixed, so now you have to use FIFO, LIFO, or whatever else is required.

Yet another scenario: Buy crypto on CB and transfer to a hardware wallet. Later, buy more crypto on CB and again transfer to the same hardware wallet. Unless you intentionally joined the transactions, the two tranches remain identifiable*, even if you used the same address. Thus no FIFO. (* Someone using a blockchain explorer can see the funds move independently.)

You mustn't of lived through the era when all personal computers interfered with TV and radio signals. This is why all computers now need FCC approval. The ASIC miners, being a self imported foreign product, likely lack such certification. Further there's probably been no effort at properly shielding the circuitry.

This appears to be a known bug as discussed in this thread: https://bitcointalk.org/index.php?topic=2829027.0

It should be fixed in the latest 3.0.6 version of Electrum.

Have you contacted rightbtc's support?

Also, are you sure you sent Bitcoin to a Bitcoin (BTC) address? Could you have sent to a Bitcoin Cash (BCH or sometimes BCC) address?

Every wallet can receive from bech32. Legacy wallets will receive at "1" (or "3") addresses, but the payer can have their funds in a bech32 address. In other words, funds formerly in a bech32 address can be received by any wallet. When paying a merchant using legacy addresses, you can still pay them even if your funds are in a bech32 address. The blockchain will record a transaction with a bech32 input, and a legacy output. The merchant's legacy software will be able to collect the legacy output.

Expanding on my previous statement: If you use the Trezor or Ledger with Electrum, then yes, you can send bitcoins to a "bc1" address. Presently, released versions of Trezor and Electrum (and presumably Ledger) limit users to "3" SegWit addresses. However, because Electrum supports sending to bech32, it can send from an "3" address to a "bc1" address.

Edit:

Decided to double check the Electrum + Trezor/Ledger combination for sends. https://en.bitcoin.it/wiki/Bech32_adoption confirms this ability. (But it also claims that these combinations can receive at "bc1" addresses...)

There is only type of Electrum for MacOS. It is distributed as an application in a dmg file. You'll need to Finder drag the icon to your Applications folder. You should be able to Finder drag to the drive icon of your boot drive, and the Finder will take care to route the application "file" to the Applications folder.

The wallet file will be nested inside the (hidden) .electrum folder in your user's home directory.

The blocks are the ledger! The pre-Segwit 1MB block limit meant that the ledger can only grow by 1MB every ~10 minutes. Now with Segwit, the ledger can theoretically grow 4MB in ~10 minutes, though the practical rate is about 2MB/~10min and the current actual rate is only slightly over 1MB/~10 min.

If you use the Trezor or Ledger with Electrum, then yes.

If you try to spend the exact same UTXO's using Trezor's or Ledger's web interface, then likely not yet.

The math does work out:

(3 boards) * (6 ASICs) * (32 RAMs) * (1 gigabit) = 576 gigabits = 72 gigabytes

Example:

You're trying to buy a GPU from EggsRUs. You send BTC. Unbeknownst to you, the big mining pools have changed the rules to give themselves a 2100 BTC block reward every block forever. (Purists are calling the pools' coin MinerCoin.) Eggs, being a merchant, knows about this inflationary change - and doesn't like it. Your transaction quickly confirms on MinerCoin, but Eggs isn't looking for it on that chain. A rag tag collection of miners are still on the legacy chain. Eventually, your transaction does confirm on the legacy chain. With some delay, you get your GPU. At some point, the big pools attempt to cash out their new found riches, but alas, nobody with real money on the line will accept their coins.

TLDR summary: Users transacting real value determine which fork has value.

Yes.


Good!


It will generate the 1st address, and then check if it has been used on the blockchain. It doesn't matter if it contains nothing right now, what's important is whether there was activity at some time or not. Then it moves on to the 2nd address and checks that one. This process continues until it has checked 20 addresses in a row without activity. The count of 20 is called the "gap limit". In some wallets, it is configurable.

Why would there be a gap? Lets say you gave out unique payment addresses to 10 coworkers to pay their share of the lunch tab. Then you gave out addresses to your online customers - and they paid. Now lets say all 10 coworkers stiffed you. You'd have a gap of ten unused addresses.