text:
What does this indicator mean in the right bottom cornor of the official Bitcoin wallet?
Circled in red:

When I hover over it I get the message "8 active connections to the Bitcoin network". Should Is this number too low and how do I change it?

That icon indicates the state of your connection with the rest of the Bitcoin network. "8 active connections" mean that you are connected to 8 other clients.
Since you got 3 of the 4 bars with 8 active connections, it is enough. As far as I remember, I always had 3 bars, so I guess it's the default setting. Probably, to get the last bar you will have to manually configure more nodes to connect with.
When you have 1 or 2 bars, there can possibly something wrong. Maybe your firewall blocks the port for Bitcoin (8333).

Under "settings" --> "advanced settings" --> "network" you can change the connection type from UpnP to static (UpnP is default). The static port can be defined in the "bitcoin.conf". Default port for static connection is 8333 if not differently defined in the bitcoin.conf.
In my personal setup i got a bitcoin node in a Virtualbox where the main machine connects through a VPN with all ports blocked. I have forwarded a random port on the VPN and activated UpnP on the bitcoin node, the node connects through the VPN with UpnP.
The other option for this scenario would be to forward port 8333 on all firewalls/switches or whatever port defined in bitcoin.conf .
Please take also into account that nodes need some time to connect. However, 8 connections should be fine for the average user.
Also to note, a running node is visible on the network, take blockchain.info connection log for example, an attacker could target, audit and exploit running nodes.


text:
How to keep Bitcions when reinstalling OS from fresh
I have the official Bitcoin wallet and I would like to do a fresh install of everything on the computer. How can I save my Bitcoins (and hopefully block chain)?

Which OS are you using?

@GregHewgill Windows 7

(I suppose you have the Bitcoin-Qt client.)
Taking a backup of the Bitcoin folder will do it.

Copy the folder to an external hard drive of a different partition.
Reinstall your system.
Install Bitcoin-Qt again.
Move the folder back.

Note that to keep your bitcoins, only the wallet.dat file is required. But when you copy the whole folder, you will probably not need to sync with the network again.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
In Deepbit how do you get the Bitcoins transfered to your wallet?
In Deepbit I've mined a fraction of a Bitcoin. How do I get the money into my wallet? Here it says "Instant payout button is shown when your balance is at least 0.01 BTC and you received less than 3 payments in last 24 hours." does this mean I have to wait until I have mad 0.01BTC?

Yes. Otherwise, the cost to transfer the Bitcoins (when you want to spend them) will wind up equaling or exceeding their value.

As far I know most mining pools require a minimum balance of one bitcent before you can withdraw. The fee for a transaction smaller than this is 0.0005BTC so I assume the pools have decided to block smaller transactions, although small transactions are generally allowed.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
How can I get bitcoins in Canada?
I want to exchange my Canadian dollars for Bitcoins. How can this be done? If it helps I have some American cash.

Vancouver now has an ATM http://www.straight.com/life/742621/vancouvers-newest-bitcoin-atm-pulls-pacific-central-station

These are a few options available to Canadians:

Local Bitcoins
BitBuy
CoinSquare
QuickCoin

There are also a few exchanges that accept CAD deposits larger than $100:

CaVirtEx isn't closed (anymore!)

Harborly is closing down. They recommend Coinbase (which isn't listed here either) and Quadriga.

Depending on how many you want, the fee/convenience structure changes. I'd break it up into three sizes.

Large (over $500, multi-day delivery):
https://CaVirtEx.com - Canadian Virtual Exchange (Biggest Canadian-based exchange)
https://CanadianBitcoins.com - Canadian Bitcoins (smaller Canadian exchange, not self-serve)
https://harbor.ly - Harborly (Buy bitcoins directly with your bank account)

Medium ($100 - $500, within hours):
https://LocalBitcoins.com - Local Bitcoins (classified ads for cash sales in your city)
http://Kijiji.ca - Kijiji (more cash deal listings)
http://Meetup.com - Meetup.com (Find local enthusiast meetups, lots of buy/sell)
http://mycelium.com/ - Mycelium Local Trader (Android App for finding Bitcoin sellers)

Small (Under $200, within minutes):
https://QuickBT.com - QuickBT (Instant, using Interac Debit, higher fee)

Now Closed:
https://www.LibertyBit.com/news - LibertyBit
https://MtGox.com - Mt Gox
https://btcQuick.com - btcQuick

Check out harborly. They let you buy bitcoin and litecoin directly with your Canadian bank account.

Instant exchange service I'm using myself and recommending to everyone else cause they don't store the coins and fiat, had recently expanded to Canada.
Check this out I believe this is exactly what you need: http://www.newswire.ca/news-releases/247exchangecom-covers-canada-with-instant-ways-of-buying-bitcoin-570478861.html

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
How to store arbitrary data in the bitcoin blockchain and how can I differentiate between a transaction an those data?
According to this post, I can store arbitrary data in the blockchain (as the news about "child pornography in the blockchain" tell).
Now I want to store "Hello World" in the blockchain.
Is there a newer website/service that supports me putting data into the blockchain?
And what's the difference between a transaction in the blockchain and such a "message"?
Is the structure different? Why could those researchers even find out that it's inappropriate content instead of a default transaction?

"Is there a newer website/service that supports me putting data into the blockchain? " I know something in the ethereum platform. According to their whitepaper they allow us to store a message in ethereum blockchain. I didn't tried yet. https://lovecoin.online/

I know that it works on the ethereum chain and I do also know how it works there. Solidity makes it easy. But the bitcoin blockchain seems to be different.

Have a look to these data sources:

https://bitcointalk.org/index.php?topic=1023190
https://github.com/petertodd/python-bitcoinlib/blob/master/examples/publish-text.py

And of course the "modern" (and cheapest) way is storing arbitrary data in segwit part of transactions. I do not know is there ready tool for it, but it is not very difficult to write it.

Is there a newer website/service that supports me putting data into the blockchain?

https://cryptograffiti.info/ (based on bitcoin cash blockchain)


text:
Is a BIP required for the removal of SegWit Discount for Inscriptions?
Is a BIP required for the removal of SegWit Discount for Inscriptions?
The rationale of such a change is to standardize the fee structure across all data types included in a block, ensuring that inscription data does not receive preferential treatment over monetary transaction data.

The removal of the witness discount would be a consensus change, specifically a soft fork. Changes to consensus rules have always been standardized as BIPs ever since the BIP process was created and I expect that to remain the case for the foreseeable future, but this is not a rule; anyone is free to try to convince anyone to run any consensus change without a BIP.
However, I'm afraid you won't have much success with convincing people to undo one of the key improvements introduced in SegWit. For the rationale of the witness discount you can check out these questions and answers to them:

Why is the witness data fee discounted by a factor of four?
Why are segwit transactions cheaper than legacy transactions?

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Can coinjoin and payjoin transactions be spotted on the blockchain?
Can coinjoin and payjoin transactions be spotted on the blockchain?
Have centralized exchanges declined to accept these types of transactions?

The primary characteristic of a coinjoin is that multiple users are collaborating in a transaction that pays each at least one output of an amount shared with another output. In other words, a coinjoin transaction must have at least 2 inputs, at least 2 outputs, and at least 2 of those outputs need to have the same amount.
Transactions with outputs of equal amounts stand out. Of the 460,264 transactions made in the last day, 14,463 conformed to these three conditions. However, many of these have equal amounts because they're creating multiple tiny outputs (example). When we only consider outputs larger than 10,000 sats, the transaction count goes down to 2415. This includes small transactions (example) to transactions with hundreds of inputs and outputs (example). Note that even if a transaction looks like a coinjoin, anyone can create such a transaction by themselves, so false positives can never be eliminated.
Payjoins are similar, except since they include a transfer between parties, the outputs no longer need to have equal amounts. There were 63,599 transactions made in the last day that had at least 2 inputs and 2 outputs, and clearly the vast majority of them aren't actually payjoins.
6102bitcoin maintains a list of instances where exchanges have flagged users who had used coinjoin. Consequences have ranged from being questioned over the source of funds to having their account closed.


text:
What are hash functions used for in bitcoin?
What are hash functions used for in bitcoin?
I am looking for a comprehensive list.

In consensus rules:

There are script opcodes that perform hash operations on the stack:

OP_SHA256: SHA256
OP_RIPEMD160: RIPEMD160
OP_SHA1: SHA1
OP_HASH160: SHA256 followed by RIPEMD160 (very commonly used, in P2PKH and P2SH scripts)
OP_HASH256: double SHA256

The signature verification opcodes (OP_CHECKSIG(VERIFY), OP_CHECKMULTISIG(VERIFY), OP_CHECKSIGADD) compute a "sighash" operation on the spending transaction and output being spent.

In pre-segwit scripts, this is a double-SHA256 hash of a modified version of the spending transaction.
In witness v0 scripts, this is a double-SHA256 of a concatenation of specific data, including certain precomputed transaction-wide values (which themselves are double-SHA256 hashes).
In witness v1 (taproot) scripts, this is a tagged single SHA256 hash of a different concatenation of specific data, including certain precomputed transaction-wide values (which themselves are single SHA256 hashes).

In taproot spends, the signature check opcodes perform BIP340 (Schnorr) signature checking, which internally involves a tagged single SHA256 operation.
P2WPKH outputs are a SHA256+RIPEMD160 hash of the public key.
P2WSH outputs are a single SHA256 hash of the script.
In taproot script path spends:

a tagged single SHA256 operation is used to compute the tweak.
a tagged single SHA256 operation is used in each level of the script tree.
a tagged single SHA256 operation is used to compute the script leaf hash.

The transaction id (txid) and witness transaction id (wtxid) are computed as double-SHA256 hashes of the serialized transaction, without and with witness respectively.
The transaction merkle root of a transaction is computed by repeatedly applying double-SHA256 on groups of two txids.
The transaction witness merkle root in the coinbase is computed by repeatedly applying double-SHA256 on groups of two wtxids (excluding the coinbase transaction).
The block hash is the double SHA256 hash of the block header.

In the peer to peer protocol:

Every v1 P2P message has a checksum, which is a truncated double-SHA256 hash of the message's payload.
The encrypted v2 transport protocol introduced in BIP324 has no checksums anymore, but does involve several SHA256 hashes in its handshake and key setup.
The deprecated BIP37 (server side filtering) protocol uses Bloom filters, insertions to which use MurmurHash3.
The BIP158 (client side filtering) filters use a Golomb-coded set (GCS), insertions to which are done using SipHash-2-4.
BIP152 (compact blocks) uses 48-bit short ids for transactions, which are computed using SipHash-2-4, with a key that is computed using truncated SHA256 of the block hash plus a nonce.
Probably several more.

In wallets:

P2PKH and P2SH addresses contain a truncated double-SHA256 checksum, in addition to a SHA256+RIPEMD160 hash of the public key or script, matching the consensus ones.
P2WPKH, P2WSH, and P2TR addresses do not use a hash in their checksum, but do typically involve hashes matching the consensus side (SHA256 of script for P2WSH, SHA256+RIPEMD160 for P2WPKH, tweaks/leafs/script tree for P2TR, though it is possible to construct an untweaked P2TR output without any hashes).
The BIP32 standard for deterministic key derivation involves an HMAC-SHA512 step per tree level, and an HMAC-SHA512 step to go from seed to master key. Its xpub and xprv formats also involve a truncated SHA256+RIPEMD160 fingerprint, and a truncated SHA256 checksum.
The BIP39 standard involves PBKDF2 strengthening, using HMAC-SHA512 as hashing step, to go from mnemonic to seed. A truncated single SHA256 hash is also used as checksum.
Most ECDSA signing implementations use RFC6979 to generate the nonce, which involves several invocations of HMAC-SHA256.
The BIP340 default signing algorithm involves a tagged SHA256 hash to generate the nonce.
Signing involves computing all the hashes that will be relevant at verification time (leaf hashes, script trees, signature hashes, tweaks, script/pubkey hashes, hashes inside signature, ...; see above under consensus rules).

In the Lightning network
I'm not an expert on this matter, so I'll leave this for another answer (or, suggestions welcome).
In node implementations
The details are up to individual implementations, and not part of any protocol. I'm just listing things off the top of my head that are used in Bitcoin Core.

Secure random number generation often involves hashes to maintain an entropy pool, and/or to combine multiple entropy sources. Bitcoin Core uses its own SHA512-based implementation here.
Bloom filters are extensively used to remember what information peers already have, which involve hash functions. Bitcoin Core uses MurmurHash3 here.
Hash tables for various data structures inherently involve hash functions. Bitcoin Core uses SipHash-2-4 for most non-trivial hash tables.

Thanks for the detailed insight on how hash functions are integral to Bitcoin. Their versatility is truly impressive, from securing transactions to enabling the mining process. It’s remarkable how they ensure integrity and security in Bitcoin’s network, making the system robust and trustworthy. Hash functions are indeed a cornerstone of Bitcoin’s innovative architecture. Need to read more about it.


text:
Why is initial block download slow on Raspberry Pi 4 with SSD?
Ran benchmarks using sysbench and CPU, memory and networking performance is very similar on Pi 4 vs Lenovo ThinkCentre M92p (both quad-core with 4GB of memory).
Which benchmarks reveal why IBD is considerably slower on Pi (weeks vs days)?

My best guess is:

The RPi4 CPU is just way slower than the laptop CPU. They're both old designs (the RPi4 CPU from 2015, the laptop CPU from 2013), but the RPi4 one is significantly lower-power, and less performance-oriented. It wasn't until the Apple M1 CPU in 2020 that ARM systems appeared with performance that is competitive with desktop/laptop x86 CPUs.

Disk. Especially if for example the RPi is using an internal SD card for holding the Bitcoin Core database, it will suffer tremendously from the latency compared to typical SSD/HDDs on desktop/laptop systems.

I can think of two possible reasons:

One, the CPU in the PI is much slower. The M92p uses an x86_64 CPU architecture, while the Pi uses an ARM CPU. CISC processors use more power, but are much faster for some applications than RISC processors. I believe there have been some optimizations for ARM recently for Bitcoin Core, but I don't know how much of a difference it makes.

Two, there are quite a few reads and writes to the hard drive during the synchronization. I would guess that your Pi's hard drive is connected via USB, while the hard drive in the M92p is connected via SATA. SATA is much faster than USB.

AES acceleration does not matter (AES is only used for wallet encryption, not for synchronization), and Bitcoin Core has no support for making use of it. It does have support for SHA256 acceleration on some CPUs, but the laptop CPU doesn't support it, and support for ARM acceleration will only be available in the 23.0 release.

Interesting! Would you happen to know how to benchmark computer simulating IBD workload? The only idea I have so far is openssl speed -multi $(nproc) -seconds 600 sha256 (10 minutes of multi-core hashing).


text:
How do we create funny segwit v1 taproot bech32m addresses?
Look at what this user has broadcasted, destination addresses are interesting:

bc1pjjjkkkklllllmmmmmmnnnnnnnpppppppqqqqqqqqqrrrrrrrrraq663x0t
bc1pttttuuuuuvvvvvvwwwwwwwxxxxxxxxyyyyyyyyys8888888888sqhaesl3
bc1paaacccdddddeeeeeefffffffgggggggghhhhhhhhhhh77777777q890057
...

How fun?
Care to explain this wizardry, anyone?

These outputs are not spent, so quite possibly, they're addresses that nobody has the private key (and/or scripts) to.
If so, that's trivial: put whatever string you like in the non-checksum part of the address, and compute the corresponding checksum.

And they burnt ~2 m₿ on that [0.o]


text:
How can I get the wtxid and its corresponding merkle proof of the said wtxid?
Are there any available block explorers that will supply a transaction's wtxid and its corresponding merkle proof of the said wtxid?
If not, how would I retrieve this if i'm running bitcoind?

There is the gettxoutproof RPC that retrieves merkle proof in Bitcoin Knots.
There is the public server which can be used for the gettxoutproof RPC: https://bitcoinexplorer.org/rpc-terminal.
The gettxoutproof RPC result could also be obtained from: https://blockstream.info/api/tx/86639c0c9bdb83f467f2c07910367929171196c8907743a5915d555de5bc27eb/merkleblock-proof (replace 86639c0c9bdb83f467f2c07910367929171196c8907743a5915d555de5bc27eb with your txid in the URL).
More info at https://bitcointalk.org/index.php?topic=5335699.msg64441291

Those are txid proofs, not wtxid proofs.


text:
Signing a Bitcoin SegWit transaction using bitcoinj
I’m working on a SegWit Bitcoin transaction, and I'm encountering an error when trying to broadcast it:

Code: -26, Error: mandatory-script-verify-flag-failed (Signature must
be zero for failed CHECK(MULTI)SIG operation)

Here’s the code I’m using to sign the transaction:
private static void signInputsOfTransaction(Address sourceAddress, Transaction tx, ECKey key) {
    for (int i = 0; i < tx.getInputs().size(); i++) {
        Script scriptPubKey = ScriptBuilder.createP2WPKHOutputScript(key);

        Coin inputValue = tx.getInput(i).getValue();

        Sha256Hash hash = tx.hashForWitnessSignature(
            i, scriptPubKey, inputValue, Transaction.SigHash.ALL, false
        );

        ECKey.ECDSASignature ecdsaSignature = key.sign(hash);
        TransactionSignature txSignature = new TransactionSignature(ecdsaSignature, Transaction.SigHash.ALL, false);

        TransactionWitness witness = new TransactionWitness(2);
        witness.setPush(0, txSignature.encodeToBitcoin());
        witness.setPush(1, key.getPubKey());
        tx.getInput(i).setWitness(witness);

        tx.getInput(i).setScriptSig(ScriptBuilder.createEmpty());
    }
}

Here’s the raw transaction hex I’m trying to broadcast:

010000000001011a34c12133e07aceb6b0cd254e2d9e12fde095b5a3afece4907945e36254e0d40100000000ffffffff02e803000000000000160014c9bf27c413655f5894a6a095ccfb5f1d291123f185170000000000001600146edda921d055dece3a894e39fd91a0c50faf675c02473044022000e9341c7c137529db50f706bc2bc1c1057674cda3bc33be5c559a45731b9c2802201a0f435a70e0f3a89d272efa407e0817e964f4c14ee9f9e3e4b5961fa658fc1d01210336069ac77986a9de47f0c371b682906149e43c2f51853b30d31132d1ec33b76900000000

I’ve decoded it using a Bitcoin transaction API (BlockCypher), and here’s the output:
{
    "outputs": [
        {
            "addresses": ["bc1qexlj03qnv404399x5z2ue76lr553zgl3kfx7va"],
            "script_type": "pay-to-witness-pubkey-hash",
            "value": 1000,
            "script": "0014c9bf27c413655f5894a6a095ccfb5f1d291123f1"
        },
        {
            "addresses": ["bc1qdmw6jgws2h0vuw5ffculmydqc5867e6ulzzm97"],
            "script_type": "pay-to-witness-pubkey-hash",
            "value": 6021,
            "script": "00146edda921d055dece3a894e39fd91a0c50faf675c"
        }
    ],
    "addresses": [
        "bc1qdmw6jgws2h0vuw5ffculmydqc5867e6ulzzm97",
        "bc1qexlj03qnv404399x5z2ue76lr553zgl3kfx7va"
    ],
    "fees": 1130,
    "ver": 1,
    "vsize": 141,
    "inputs": [{
        "sequence": 4294967295,
        "witness": [
            "3044022000e9341c7c137529db50f706bc2bc1c1057674cda3bc33be5c559a45731b9c2802201a0f435a70e0f3a89d272efa407e0817e964f4c14ee9f9e3e4b5961fa658fc1d01",
            "0336069ac77986a9de47f0c371b682906149e43c2f51853b30d31132d1ec33b769"
        ],
        "addresses": ["bc1qdmw6jgws2h0vuw5ffculmydqc5867e6ulzzm97"],
        "prev_hash": "d4e05462e3457990e4ecafa3b595e0fd129e2d4e25cdb0b6ce7ae03321c1341a",
        "output_value": 8151,
        "script_type": "pay-to-witness-pubkey-hash",
        "output_index": 1,
        "age": 698646
    }],
    "preference": "low",
    "received": "2024-11-28T15:26:00.690177102Z",
    "block_height": -1,
    "confirmations": 0,
    "relayed_by": "189.37.69.88",
    "total": 7021,
    "size": 222,
    "block_index": -1,
    "double_spend": false,
    "vin_sz": 1,
    "hash": "0cafb57866d9a412e6cd0f806e03363baab1bdbf6434181ea5a927aa62930f77",
    "vout_sz": 2
}

Is there something wrong with the way I’m signing or setting up the TransactionWitness?

For P2WPKH inputs, the scriptCode accepted by ScriptBuilder.hashForWitnessSignature is not the scriptPubKey but a P2PKH script with the hash of your public key. You can generate it using ScriptBuilder.createP2PKHOutputScript.
See BIP143 for more information on signature verification in SegWit inputs.


text:
Why are undo files needed in Bitcoin Core?
Undo files contain data needed to disconnect a block from the blockchain. It basically contains instances of CBlockUndo:
/** Undo information for a CBlock */
class CBlockUndo
{
public:
    std::vector<CTxUndo> vtxundo; // for all but the coinbase

    SERIALIZE_METHODS(CBlockUndo, obj) { READWRITE(obj.vtxundo); }
};

CTxUndo:
/** Undo information for a CTransaction */
class CTxUndo
{
public:
    // undo information for all txins
    std::vector<Coin> vprevout;

    SERIALIZE_METHODS(CTxUndo, obj) { READWRITE(Using<VectorFormatter<TxInUndoFormatter>>(obj.vprevout)); }
};

From my understanding, it's only a wrapper over the spent coins and it has no extra information regarding to the actual block.
On the other hand, as far as I can see, undoing a block needs undoing all transactions the block contains. And to undo a transaction we need to perform two thing:

Removing the transaction outputs from the UTXO set
Restoring the inputs as UTXO (restoring the UTXOs that are spent in the transaction)

If I'm correct, I can't understand the need behind having undo files.

The problem is that a transaction input only identifies which TXO is spent per their outpoint, but does not repeat the details of the TXO. Therefore, the information in the block is insufficient to reinstate the UTXOs that got consumed by the transactions in the block—we’d have to go back and find each transaction that created UTXOs to rediscover the amount and output script of the UTXOs to be recreated, just so we can consume most of them moments later when we apply the transactions included in the new best chaintip. In the case of a pruned node, we might not even have those transactions anymore, but even for nodes with a full blockchain these lookups would be quite expensive (I assume it would require either scanning the whole blockchain for all of the transactions, or having a txindex to be able to look them up in the appropriate block files).
Either way, having a copy of the pertinent TXO data is way more efficient in the case of a reorg.

Also, in the case of a pruning node, the spent UTXO data may just not exist anymore, if the block that created the output was before the prune point, but the spending happened after.


text:
Transaction broadcasts and block synchronization
In the original publication about bitcoin, in section 5 it states that

If two nodes broadcast different versions of the next block
  simultaneously , some nodes may receive one or the other first. In
  that case, they work on the first one they received but save the other
  branch in case it becomes longer. The tie will be broken when the next
  proof-of-work is found and one branch becomes longer;

the author then states

New transaction broadcasts do not necessarily need to reach all nodes.
  As long as they reach many nodes, they will get into a block before
  long.

My question is: How do lost transactions "get into a block before long"? Are they constantly re-transmitted until they are 6 blocks deep and the proof of work has been completed? Is it possible that a transaction could be re-transmitted indefinitely, and it might never be put into a block that is fully synchronized?

While implementation specific, transactions are only re-broadcasted by the bitcoin-qt client after every x minutes (30?) and only if it's not in the main chain yet. Once a block comes in that has the transaction, it'll stop transmitting. If a new chain is accepted later that doesn't have the transaction, it will start broadcasting again.
About transactions getting lost, I already wrote an answer about that once :

Most clients on the network have a transaction pool in their memory. The same basically applies to miners: they just dump the top 500KB (or some other value) transactions into a block, sorted by transaction fee (descending, of course). When there aren't many transactions, maybe because of a series of block in a short amount of time, it will be confirmed anyway.
But to answer your actual question: yes, transactions (sort of) expire. When you send a transaction, it sends a tx frame to all connected peers. These peers store the transaction in their memory pools and tell all their connections that they have a new transaction. When those connections don't have it yet, they ask for it, and that's how a transaction spreads over the network.
At some point every node in the network will have the transaction in their memory pool, and at that point it will no longer be sent over the network. Now when a user restarts their client, the memory pool is wiped, and the transaction is deleted from that computer. (Plus a few other ways to delete transactions from the pool)
Because of that it's very unlikely for the transaction to be gone from the entire network, but in case it does happen: the reference client will automatically re-send the transaction every x hours(/minutes?) when it's still not confirmed.
Oh, and I forgot the most important part: transactions on Bitcoin (tx frames in the protocol) don't have a 'time' field, which means that transaction expiration can't be a feature of Bitcoin.
To summarize: yes, the transaction can expire, but that is really unlikely.

blockchain.info has some interesting information regarding unconfirmed transactions (Transactions waiting to be included in a block), and orphaned blocks (Valid blocks not part of the main bitcoin chain).


text:
How to read the transaction of a block?
Given this example block (it's the genesis block by the way):

0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c0101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000

I split it up as described here:
01000000                                                          // Version
0000000000000000000000000000000000000000000000000000000000000000  // Hash Previous Block
3ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a  // Merkle Root
29ab5f49                                                          // Time
ffff001d                                                          // Difficulty
1dac2b7c                                                          // Nonce
01                                                                // Number of Transactions
 Tx1:
 01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000

But how is the transaction Tx1 (in this case) readable? Obviously, it's not a default english clear text. How can I decode it so that I recognize that Satoshi Nakamoto sent 50 BTC as a coin base transaction in this transaction Tx1 for example?

Related: https://bitcoin.stackexchange.com/questions/20721/what-is-the-format-of-the-coinbase-transaction

The transaction, like the block, is in a serialized format. A description of the format is available on bitcoin.org

I have got this resource for you may be this could be useful: https://bitfalls.com/2017/10/03/read-bitcoin-blockchain-data-blockexplorer/

Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference. This is to avoid the link going down and the answer becoming useless :)

I decomposed the tx to make it more visible, the raw tx is this:

01000000010000000000000000000000000000000000000000000000000000000000000000FFFFFFFF4D04FFFF001D0104455468652054696D65732030332F4A616E2F32303039204368616E63656C6C6F72206F6E206272696E6B206F66207365636F6E64206261696C6F757420666F722062616E6B73FFFFFFFF0100F2052A01000000434104678AFDB0FE5548271967F1A67130B7105CD6A828E03909A67962E0EA1F61DEB649F6BC3F4CEF38C4F35504E51EC112DE5C384DF7BA0B8D578A4C702B6BF11D5FAC00000000

VERSION
 01000000

TX_IN COUNT [var_int]: hex=01, decimal=1
 TX_IN[0]
  TX_IN[0] OutPoint hash (char[32])
  0000000000000000000000000000000000000000000000000000000000000000
  TX_IN[0] OutPoint index (uint32_t)
  hex=FFFFFFFF, reversed=FFFFFFFF, decimal=4294967295
  TX_IN[0] Script Length (var_int)
  hex=4D, decimal=77
  TX_IN[0] Coinbase and Sequence
  04FFFF001D0104455468652054696D...
  TX_IN[0] Sequence (uint32_t)
  FFFFFFFF

TX_OUT COUNT, hex=01, decimal=1
 TX_OUT[0]
  TX_OUT[0] Value (uint64_t)
  hex=00F2052A01000000, reversed_hex=000000012A05F200, dec=5000000000, bitcoin=50.00000000
  TX_OUT[0] PK_Script Length (var_int)
  hex=43, dec=67
  TX_OUT[0] pk_script (uchar[])
  4104678AFDB0FE5548271967F1A67130B7105CD6A828E03909A67962E0EA1F61DEB649F6BC3F4CEF38C4F35504E51EC112DE5C384DF7BA0B8D578A4C702B6BF11D5FAC

 LOCK_TIME
00000000

The field for the previous tx (OutPoint Hash) is set to all zeros, and the next field to  "FFFFFFFF" (where you normally have a value to the previous tx outpoint). So nothing to spent "from". In tx_out the payment goes to a public key, which translates to: 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa


text:
Coinbase & Hardware wallet relationship
Aside from learning about all of bitcoin just for fun (mathematician with spare time), I currently own some bitcoin IOU's via Robinhood, but I would like to actually own my bitcoin (my keys, my coins! As they say).
I have been investigating Coinbase and hardware wallets like Nano Ledger S.
My understanding is that Coinbase is an exchange or market place where BTC can be bought and sold, but also offers wallet services.
My understanding of a hardware wallet like Nano Ledger S is that it is a very secure hardware device (cold storage, meaning completely offline) that will store the public and private key to my BTC wallet - and the private key to my wallet is synonymous with the bitcoin I hold. It has a 20 word mnemonic so if I hypothetically lost the device, I could buy a new one and access my wallet using the 20 word mnemonic. (I would also like to understand how buying a new Nano Ledger S and entering my mnemonic allows it to essentially restore to my old wallet, it seems like this would require the information to be stored somewhere. But I'll save that for a different question later on)
If my understanding above is correct, I would like to now understand the way transactions take place between the two concepts listed above.

I purchase X BTC on coinbase and it goes to my "hosted wallet" on Coinbase (X used as a variable representing the amount of BTC)
I can send the X BTC I purchased to my hardware wallet by giving the public key to my hardware wallet and specifying perhaps .99X BTC go to that wallet and the remaining .01 BTC is left as the transaction fee.
Coinbase broadcasts the transaction in the P2P network, sent around through full nodes in the network.
When this transaction gets grouped into a block and is mined, my wallet now contains .99X BTC meaning my public key shows up somewhere on the blockchain ledger that I have .99X unspent BTC associated to my public key.

I can repeat this process as many times as I like, continuing to accumulate more BTC in exchange for USD via Coinbase.

Eventually, maybe I want to liquidate some BTC in exchange for USD.
I can do this by using Ledger Live as described on the
ledger website here. Is this still "offline"? even when I "unlock and connect" my ledger device?
I use ledger live to send BTC to my Coinbase "hosted wallet" public key. When the transaction is processed I can sell my BTC on Coinbase market at the market value.

Is my understanding correct? And if so, how is my private key being used when I send BTC using ledger live? I think it is used to "sign" the transaction? So in some way is my private key vulnerable to nano ledger programming or software when sending?
I understand this is very amateur material, I have tried hard to learn on my own without asking here, but the quality of answers on this site, so far, have proven better than anything I have found on my own.

Your understanding is largely correct. I'll nitpick a few points for clarity, but overall I would say you have a decent grasp of whats going on here.

I can send the X BTC I purchased to my hardware wallet by giving the public key to my hardware wallet and specifying perhaps .99X BTC go to that wallet and the remaining .01 BTC is left as the transaction fee.

You will copy your bitcoin address to coinbase, not your public key. (In most cases, they 'pay-to-public-key-hash' (P2PKH) address is, as the name suggests, a hash of the public key). Your wallet will display bitcoin addresses, not public keys, so this is just a matter of terminology.
I am not familiar with Coinbase's interface, but there should be some sort of 'withdraw all' function. You will likely not need to specify a fee (in reality, Coinbase will likely just present you with a fee, which could include both a network transaction fee portion, and a Coinbase service fee portion).

When this transaction gets grouped into a block and is mined, my wallet now contains .99X BTC meaning my public key shows up somewhere on the blockchain ledger that I have .99X unspent BTC associated to my public key.

Wallets do not contain BTC. Wallets contain private keys, which can be used to sign transactions that spend coins which are locked to their associated bitcoin address. Once the transaction confirms, nodes on the network will be aware of an 'unspent transaction output' (UTXO), that is locked to an address that is derived from a private key, which your wallet holds.

I can repeat this process as many times as I like, continuing to accumulate more BTC in exchange for USD via Coinbase.

Yes, though when you eventually want to spend the coins, remember that it is more expensive to create a transaction which includes many small inputs, rather than just one or two larger inputs. See this question for info on fee calculations, and this one for fee info related to segwit transactions.

I can do this by using Ledger Live as described on the ledger website here. Is this still "offline"? even when I "unlock and connect" my ledger device?

The device connects to your computer via USB, and has a very restricted protocol for talking over the USB cable. Your private keys exist on the Ledger, and never leave the Ledger, so this is a more safe way of transacting, then just keeping the private keys on a device which is connected to the internet itself. The transaction can be created using software on your computer, and then that transaction is transmitted to the Ledger, signed, and the signed transaction is then transmitted back to your computer. Some other hardware wallets use different methods of communicating this data back and forth (eg SD card, QR codes, etc), but the general workflow will be the same.

I use ledger live to send BTC to my Coinbase "hosted wallet" public key. When the transaction is processed I can sell my BTC on Coinbase market at the market value.

Again, you'll send to a bitcoin address, but otherwise, this is correct. Note that when sending to coinbase, you will have more control over the transaction fee (and there will be no service fee, like there may be when you withdraw from an exchange).

how is my private key being used when I send BTC using ledger live? I think it is used to "sign" the transaction? So in some way is my private key vulnerable to nano ledger programming or software when sending?

Your private key will remain on the Ledger device, so you need to confirm the transaction looks correct, via the prompts on the device's screen. You should follow the hardware wallet manufacturer's instructions to ensure that you have received an authentic device from a legitimate retailer, and that it is running legitimate and up to date firmware.
Hope that helps!

Thanks, I was hoping someone would nitpick my explanations. I didn't know about the fee for many inputs vs few inputs. Lastly, would it be correct to say my "wallet" is synonymous with the ECDSA public/private key pair, but all of my "bitcoin" is also associated to private keys?

A wallet will contain many keypairs, but I would not call the two ‘synonymous’. I think that saying your bitcoin is ‘associated to your private keys’ is maybe a little strange, but not incorrect. Note that only you will be aware of this association though, of course. The rest of the network could perhaps be said to associate your coins with the addresses they are locked to.

Then what do people mean “not your keys, not your coins”? Which keys are they referring to

That does refer to private keys. If you aren’t holding your private keys, then you are depending on someone else to spend your coins for you, when you want to spend them. I mentioned that saying the coins are ‘associated’ with a private key is a little strange, just because only you should be aware of that association, and that private key. So from the viewpoint of an unrelated third party, they would not have any knowledge of which private key a certain coin (output) might be associated with.

2 thoughts on your understandings,

custodial sites such as Coinbase use a pre-configured transaction fee, when using the Ledger it will probably give you a few options to choose from (i've never used a Ledger).
there are multiple public address types (P2PKH, P2SH, and bech32 - see invoice address link below), and not all exchanges support all types.

https://en.bitcoin.it/wiki/Invoice_address

Thanks for your answer!


text:
LSP best practices
The problem of getting inbound liquidity on the Lightning Network has given rise to Lightning Service Providers, essentially node operators on the Lightning Network, that provide new nodes with inbound liquidity, by opening channels to them.
Since this concept has gained a lot of popularity and there are already multiple companies innovating on this topic, I was wondering whether there is already distilled information about the best practices for operating LSPs out there.
I'm particularly looking for this information:

Rough estimation about recommended channel size to open to customers (granted, this is heavily dependend on use cases, resp. the usage of an indiviudal user)
How and when to deal with potential capacity increases/decreases (--> multiple channel support?)
How to deal with dormant channels (inactive for a prolonged time frame)
How to deal with channel reserves in a UX-friendly way

Any input is appreciated.


text:
How To Get a New Bitcoin Payment Address
I have one bitcoin ewallet and this has one bitcoin payment address.  I have read we should change our bitcoin payment address frequently for security reasons.  How do we do that?

It depends ... which wallet are you using ? Like a blockchain wallet ?

How are you planning to take payments? Do you want a solution aimed at taking payments on the web automatically, or one aimed at retail businesses?

Most online wallets will create for you a new address each time you indicate that you want to receive a transaction, or give the option of creating a new address. Some enforce this by never showing an address twice and simply handle amalgamation  on the backend.
Creating a new address for each transaction is a fool-proof way of ensuring that someone has paid you, because you've given that address to only that person and no one else. There are also some privacy benefits, as using a new address makes it more difficult to trace the bitcoin trail.


text:
Could the target become unreachable?
As far as I understand it, the target T is a floating point number that is adjusted based on the moving average of the difficulty of some previous transactions. Mining a block happens when somebody is able to find a block x so that H(x) < T (by varying the nonce and/or block contents by brute force). Please correct me if I'm wrong.
Now, due to the structure of a hash function, there is basicaly no way to know if for a given y, there exists a x so that H(X) = y, meaning that there are some "unreachable" hashes. These unreachable hashes are supposed to be distributed randomly (as are all hash outputs), which would mean that there can also be continuous ranges of unreachable hash outputs.
Is there anything that prevents the target from becoming so small that no valid blocks can be found that match the target requirement, because all of the hashes close enough to the target are unreachable?
I realize that the difficulty would have to rise more than we can currently imagine, but I wonder if there is any way to deterministically rule out that possibility, in addition to it being very, very, very unlikely?

int(H(X)) < int(y) is the mining task

@cdecker wow, that anwers it completely. didn't catch that answer, thanks!


text:
Would a transition to a different signature scheme be feasible?
The recent problem with Android's SecureRandom PRNG once again shows that using (EC)DSA can go horribly wrong if the signature nonce is ever reused.
There is an elliptic curve signature scheme that doesn't share this property: Ed25519.
Is there a mechanism in the Bitcoin protocol to allow transition to a new address/signature format? Would there have to be a new opcode, or does OP_CHECKSIG already support different key types?
What would happen to clients that don't support a new key format, but receive transactions from such a new address/key? Would SPV clients trust a transaction that they can't verify themselves, or reject the block containing it as invalid?
In any case, the new format can only be used once (nearly) all clients support it, but could this be implemented at some point, and enabled some time later?

Well, for starters I must say that the problem with ECDSA nonce can be avoided even when using ECDSA via the same method used in Ed25519, and indeed this method is not even novel to Ed25519. But, let's assume we need to change the signature algorithm for some reason.
OP_CHECKSIG does not support different key types per se. The public key given as input is either an uncompressed or compressed EC point, starting with 0x04, 0x03 or 0x02. Any other starting byte could be used for different transaction types, if desired. However, a separate opcode would (IMHO) be cleaner.
The only required changes are on the script side, either modifications to OP_CHECKSIG opcode or the introduction of a new opcode. And after this, miners need to start accepting transactions containing the new style signatures as "standard" scripts.
All "full" bitcoin clients verify all transactions that are present in a block (run all scripts). This means that they will refuse to accept a block that can not be verified (even if it only has one transaction failing verification). This means that if such a change is incorporated, the block chain will fork for the clients that do not support such transactions.
Nearly all clients will need to support the new signatures and the clients that do not will become unusable when encountering the first block that has a transaction with a new signature.

You're right, a message-derived nonce seems like a very good solution for the problem. I've just learned about http://tools.ietf.org/html/rfc6979, which seems to fix the problem for Bitcoin in a completely backwards-compatible way. Thanks for still explaining how an algorithm change would work!

Also, do note that if randomness generation is broken, then all new addresses are bad as well. With the nature of bitcoin being what it is, new addresses are generated almost as often as signatures - so making signatures deterministic just hides the bad randomness problem longer...

That's definitely true for bitcoind/bitcoin-qt. Seems like deterministic wallets would be unaffected, though.


text:
How does the lightning network handle changing IPs?
What happens if suddenly my IP/Onion address changes? Will that be a problem for the lightning network? Or could my node just simply update the network graph as long as its public key stays the same?

If your IP address changes, you reconnect to the network and broadcast a new node_announcement message containing the set of your node's reachable addresses and an updated timestamp. The node's public key identifies the node  and all of its channels and may not change. All other information in the node_announcement message can be changed.


text:
Does the 25th password make the wallet harder to crack?
Lets say you have a 24 word seed bitcoin wallet.
And then you add a password that's 96 characters long. Does that make it twice as hard to geuss?
Is this new private/public key generated completely unique to one that might be generated only via using 12/18/24 keywords? or is it possible to get the same public/private address via a 24 keyword seed & a 24 keyword seed w/ a 25th word password

Adding a passphrase to a seed phrase does make it harder to guess the combination but that isn't really relevant. The seed phrase alone is hard enough.
I think people would add a paraphrase for plausible deniability or similar reasons. For example you could create several wallets with the same seed phrase, one with no passphrase and at least one with a passphrase. Then put a plausible amount of money into the first wallet  and build up some plausible history there.
The other part of your question rests on the ratio of the range of possible outputs to the bits of entropy fed to the prng. You need a mathematician to answer that with precision. I suspect that the coverage  is a statistical process and so coverage will increase quickly at first and drop off. Whether the coverage converges to a set of results that is smaller in size than the full set from the expected output range is a question for a mathematician. Maybe one will answer. Maybe there's a maths stackexchange?
My mathematically worthless intuition suggests to me that the answer is yes, there is overlap in the reachable results with vs without passphrase.

Yeah, im no mathematician either but i assume there must be some overlap since as far as I can tell the 25th password doesn't have a limit....or if it does, it's very large.

Mastering Bitcoin. A highly recommended read if you want to have a deep dive.

Generating mnemonic words

Create a random sequence (entropy) of 128 to 256 bits.
Create a checksum of the random sequence by taking the first (entropy-
length/32) bits of its SHA256 hash.
Add the checksum to the end of the random sequence.
Divide the sequence into sections of 11 bits.
Map each 11-bit value to a word from the predefined dictionary of 2048 words.
The mnemonic code is the sequence of words.

The mnemonic words represent entropy with a length of 128 to 256 bits. The entropy
is then used to derive a longer (512-bit) seed through the use of the key-stretching
function PBKDF2. The seed produced is then used to build a deterministic wallet and
derive its keys.

The key-stretching function takes two parameters: the mnemonic and a salt. The pur.
pose of a salt in a key-stretching function is to make it difficult to build a lookup table
enabling a brute-force attack. In the BIP-39 standard, the salt has another purpose-it
allows the introduction of a passphrase that serves as an additional security factor
protecting the seed, as we will describe in more detail in
"Optional passphrase in
BIP-39" on page 104.

The first parameter to the PBKDF2 key-stretching function is the mnemonic pro-
duced from step 6.
The second parameter to the PBKDF2 key-stretching function is a salt. The salt is
composed of the string constant "nnemonic" concatenated with an optional user-
supplied passphrase string.
PBKDF2 stretches the mnemonic and salt parameters using 2048 rounds of hash-
ing with the HMAC-SHA512 algorithm, producing a 512-bit value as its final
output. That 512-bit value is the seed.

The key-stretching function, with its 2048 rounds of hashing, is a
very effective protection against brute-force attacks against the
mnemonic or the passphrase. It makes it extremely costly (in com-
putation) to try more than a few thousand passphrase and
mnemonic combinations, while the number of possible derived
seeds is vast (2512).

Optional passphrase in BIP-39
The BIP-39 standard allows the use of an optional passphrase in the derivation of the
seed. If no passphrase is used, the mnemonic is stretched with a salt consisting of the
constant string
"mnemonic", producing a specific 512-bit seed from any given
mnemonic. If a passphrase is used, the stretching function produces a different seed
from that same mnemonic. In fact, given a single mnemonic, every possible pass-
phrase leads to a different seed. Essentially, there is no
"wrong" passphrase. All pass-
phrases are valid and they all lead to different seeds, forming a vast set of possible
uninitialized wallets. The set of possible wallets is so large (2512) that there is no prac-
tical possibility of brute-forcing or accidentally guessing one that is in use.

The optional passphrase creates two important features:
• A second factor (something memorized) that makes a mnemonic useless on its
own, protecting mnemonic backups from compromise by a thief.
A form of plausible deniability or "duress wallet," where a chosen passphrase
leads to a wallet with a small amount of funds used to distract an attacker from
the "real" wallet that contains the majority of funds.
However, it is important to note that the use of a passphrase also introduces the risk
ofloss:
. If the wallet owner is incapacitated or dead and no one else knows the pass-
phrase, the seed is useless and all the funds stored in the wallet are lost forever.
Conversely, if the owner backs up the passphrase in the same place as the seed, it
defeats the purpose of a second factor.
While passphrases are very useful, they should only be used in combination with a
carefully planned process for backup and recovery, considering the possibility of sur-
viving the owner and allowing his or her family to recover the cryptocurrency estate.

Summary: From what I understand it doesn’t make it any easier or harder to “brute-force” your wallet. The real purpose of the 25th phrase is to protect your 12/24 word seed phrase from those who get access to it.
Edit: To correct myself - whether or not 25th word (salt) makes it more difficult to brute-force your wallet depends on the technique the hackers use to do it. Practically impossible anyways. But it's a good idea to add this word if you are sure you can mitigate the risks associated with keeping it safe and accessible by you or your loved ones when needed.


text:
Why is explorers shows different difficulty values?
Just take a random block for example, for block 506068, blockchain.info shows difficulty as 2,603,077,300,218.59, while blockcypher shows 392,962,374, do the explorers use a different way to calculate them, why are they different?

Blockcypher is not showing difficulty but difficulty target. You can see blockchain.info also show this under 'bits'.

Read more: https://en.bitcoin.it/wiki/Difficulty#What_is_the_formula_for_difficulty.3F


text:
Are satoshis private keys easier to find than modern ones (given proper security in both cases)?
I read that back then, you had entropies of 128 bit instead of 256. Like 12 vs 24 word mnemonic seed phrases. Are their wallets easier to brute force than other ones?

The secp256k1 curve provides 128 bits of security, so as long as your source of entropy is good (indinsintguishable from uniformly random), anything over 128 bits gives you no benefit at all. I don't know which CSPRNGs were used back in the day and how they were seeded, but the fact that Satoshi's coins remain untouched to this day would indicate that the keys were in fact generated securely.
Side note, 24-word mnemonics aren't more secure that 12-word mnemonics either. As far as I'm aware, the reason for their existence is that you can safely type them into an untrusted device in a random order (as determined by a connected hardware wallet which itself has limited input capabilities). There are about 279 permutations of 24 words, which is a markedly lower security level than 128 bits, but still out of reach in the foreseeable future for all but the most dedicated attackers, and can be further improved by typing in a few words not part of the original mnemonic. Compare that with 12 words which only have 479,001,600 (about 229) permutations, trivially crackable on any modern PC.

This is correct, 24 word would only be more difficult to crack if you actually had to crack the words. The attack is to find a private key given a public key, and the public key as you suggested provides 128bit security on the 256k curve. https://bitcoin.stackexchange.com/questions/110145/using-more-than-a-12-word-mnemonic-phrase https://bitcoin.stackexchange.com/questions/117348/12-or-24-words-for-menomonic/117366#117366

Thanks for this answer. I don't really understand it thoug. It sounds like you could rather just go with 12 words. I thought it had something to do with anyone knowing your public key, having it easier to get to your private key (brute force, but with less tries). Why 279? I understand 204824 (BIP 39).

24! ≈ 2^79 (the number of permutations of 24 words).

Why 24!? You can have words twice in a BIP39 seed phrase.

Yes, for a seed phrase with repeated words the number of distinct permutations of its words will be lower.


text:
Are there any Bitcoin wallets with native I2P integration?
Tor usage seems to be fairly common with Bitcoin, but I have heard less about efforts of integrating with the I2P efforts.
Tor and I2P both have their pros and cons, but I am curious to here about what I2P efforts have been made to this point and why more attention has so far focused on tor.

C++ may be viewed by some as more suitable for Bitcoin use than Java which I2P currently heavily relies upon
https://github.com/monero-project/kovri
Kovri:

To cover, veil, wrap (Esperanto).
A secure, private, untraceable C++ implementation of the I2P anonymous network.

Once complete this project should ease of integrating Bitcoin in both a private and secure manner.

As of now, there is no such wallet. But there is bounty for it
More information here

Since 2021, Bitcoin Core supports finding and connecting to other nodes over I2P.
See the documentation for that feature: https://github.com/bitcoin/bitcoin/blob/master/doc/i2p.md


text:
Is there a good blockchain explorer like blockchain.info available for bitcoin cash?
I usually use www.blockchain.info for bitcoin if I want to get information about:

a specific address (transactions, balance...)
a specific transaction (source and target address, amount, fees, etc.)
number of unconfirmed transactions on the network

Is there a similar site for bitcoin cash? Google was not very helpful because it gave me lots of results applicable only  to bitcoin and not bitcoin cash. Thanks!

Try Blockchair. It is a blockchain explorer for both Bitcoin and Bitcoin Cash.

Thanks. This covers the first two of my points, cant find unconfirmed transactions though. Do you have an idea?

Isn't this what you're looking for?

I am not sure. https://blockchain.info/de/unconfirmed-transactions shows me conveniently the exact number of unconfirmed transactions at the current time. On your link I do not see it, but maybe I am just unable to look properly?

However, I just found this: https://jochen-hoenicke.de/queue/uahf/#24h
So, together with your link above, I have everything I need now. Thank you!

authors: влад раковец


text:
How Much Bitcoin Does Satoshi Have?
How can we calculate all Satoshi Bitcoin holdings?
I know about the genesis address 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa and then there are lots of mining addreses
When did he stopped mining, sending and receiving money?

How Much Bitcoin Does Satoshi Have?

From CoinCodex

Although we can’t know exactly how much BTC Satoshi was able to mine, the commonly accepted estimate is that he mined approximately 1.1 million BTC.

That is over $51 billion at today's exchange rate.

How can we calculate all Satoshi Bitcoin holdings?

You have to guess which addresses Satoshi Nakamoto created. This is difficult. Some estmate 20000 addresses.
According to BitKan

Satoshi Nakamoto is believed to hold almost 1.1 million Bitcoins. It's important to keep in mind that this number is just an estimate. Due to the incomplete identity of the public wallet addresses used by the entity, it is challenging to trace the Bitcoin that Satoshi owns .
The Satoshi Nakamoto Bitcoin wallet value of 1.1 million is based on a trend that was discovered in the first two years of the Bitcoin mining trend. The Patoshi pattern, which was discovered by Sergio Demian Lerner, a chain analyst at RSK Labs, is the most Well-known example of this pattern.
A research published in 2013 shows that a single person mined the great bulk of the first batch of Bitcoins. According to ***'s estimates, a single miner may have processed around 22,000 blocks in the first year of Bitcoin, and may have gathered 1.8 million Bitcoin in total, 1.1 million of which has not been spent.

The Patoshi Pattern


text:
When does OpenCoin Inc intend to make the Ripple server code public?
Is there a definite timeline or not? Thank you.

I suspect that the timeline is being kept a secret - quoting from bitcoin talk - it is also in their best interests not to release the source code at first. They need to wait until Ripple has critical mass so that it will be impractical for a hard fork to divest the owners of their 100 billion XRP premine. I don't work for OpenCoin, so I don't really know.

Fair enough - though how is it supposed to reach critical mass if the server is being run on a handful of sites so far? Also, unless the entire source code is open for inspection, there's a cold chance in hell it will be widely adopted.

You state the obvious sir. Critical mass means enough gateways and users who will use them to actually do payments.

Server is at minimum an order of magnitude more complex than the client and client was (or still is) pretty buggy. It seems it takes them months to fix relatively simple bugs. Server is probably a year away IMO.

It is the obvious we miss most often Alex, as it is too close to our noses.

We have publicly stated that we don't expect the code to be made publicly available in less than two months and that we would consider it a failure if we didn't make the code publicly available before the end of the year.
Right now, we've received a lot of public feedback and are trying to make changes responsive to that feedback. See this github issue for an example. It will be very hard to make significant changes after the source code is public.
(I'm an employee of Opencoin and one of the designers of the Ripple payment network. I'm speaking only for myself.)

I would appreciate a description of how it works, encryption,etc.  My request via twitter to attend the conference hasn't been replied to by your marketing department, so I (as a developer) will not be able to design products and solutions around your product.

@makerofthings7 You can just show up and we'll let you in.

OpenCoin (now called Ripple Labs Inc.) open sourced the Ripple server code on Sept 25th 2013.
Announcement: https://ripple.com/forum/viewtopic.php?f=2&t=3718
Source: https://github.com/ripple/

There's no timeline, but they say it's "top priority".

That being said... personally until they go open ripple is no longer interesting to me.

There is no fixed open-sourcing date, there is certain large enhancements that OC wants to be in the initial release. My best guesstimate is that there is an 80% chance of the release before the end of the year and 50% chance before September.

My personal opinion is that the server code isn't ready yet. Nor is the client. Ripple is a very complex and ambituous piece of software. I think they need more programmers and a lot more polish and bugfixing before it is released. I consider myself at least of average intelligence and quite frankly, the order book in the client confuses the shit out of me. And I'm a huge fan of Ripple!


text:
Proof of work: comparing computed hash with target hash
According to the source code here is where the hash computed by a miner is compared with the target hash:
bool CheckProofOfWork(uint256 hash, unsigned int nBits, const Consensus::Params& params)
{
    bool fNegative;
    bool fOverflow;
    arith_uint256 bnTarget;

    bnTarget.SetCompact(nBits, &fNegative, &fOverflow);

    // Check range
    if (fNegative || bnTarget == 0 || fOverflow || bnTarget > UintToArith256(params.powLimit))
        return false;

    // Check proof of work matches claimed amount
    if (UintToArith256(hash) > bnTarget)
        return false;

    return true;
}

Can you fill the code above with comments to make me to understand what is the role of every variable used in this function?
About the hashes comparing I have read this, anyway, can you make another example printing hash strings to show to me the output of every line of the code?

hash is the SHA256 hash value (a large integer) calculated by the miner for the block. If the hash is less than or equal to the Bitcoin network target, the miner succeeded and the hash is a valid proof of work. Conversely, if the hash value is greater than the Bitcoin network target, the miner failed and the hash is not a valid proof of work.
bnTarget is the current Bitcoin network target (inverse of difficulty). In the network packets it is sent in a Bitcoin specific compact form (nbits) but you need it expanded to an integer for use in numeric comparisons with calculated hashes.
fNegative and fOverflow are error flag values returned by the SetCompact() method. They indicate if the conversion from the nbits value resulted in a negative number (bad) or an arithmetic overflow (bad)
params.powlimit is the maximum possible value of a hash value representing proof of work (hence pow). This is less than the actual max value of the data type being used here. The value of powLimit is 0x00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff, the value corresponding to difficulty 1.

What is uint256 hash and what does it do? I assumed it is the hash generated by a miner but then why the comparation is > against the bnTarget instead of <?

You are right, hash is the value calculated by the miner. Note that if (hash > bnTarget) FAIL is the same as if (hash <= bnTarget) SUCCEED.


text:
Discrepancy Between Nonce for Single Block
I'm looking at nonce data from blockchain.info for block #1 ( https://blockchain.info/block/00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048 ) and it shows a nonce value of 2573394689 However when I take a look at blockcypher.com ( https://api.blockcypher.com/v1/btc/main/blocks/1 ) they report a nonce value of 2083236893 for the first block.
Is this a mistake? Is it possible for there to be a conflict in the true nonce? When I check block #2 both sites show the exact same nonce.

The block presented with the second link (api.blockcypher.com/v1/btc/main/blocks/1) is not the same as the one presented with blockchain.info.
"api.blockcypher.com" says block 1 (Height=1) has a "previous block" of all zeroes:

but that is the block with Height=0, not with Height=1 !.
One could argue that "api.blockcypher.com" starts counting (oddly) on "1", but the problem is that their next block (block 2) has a "previous block" of "00000000839a8..." (correct) which in fact is not their block 1...
That is, there is a gap in their API, and the block with a "previous block"="000000000019d66..." or block with Height=1, is not accessible using block count:

"api.blockcypher.com" block 1 is really the block 0 (Height=0), and
their block 2 is the correct block 2 (Height=2), and so
the block 1 that you are trying to see is unreachable in that API (!).

That also means that Nonce=2573394689 for block 1 from blockchain.info is the correct value.


text:
What stops an attacker from crippling the Bitcoin network?
An individual (or government) who wants to bring down the Bitcoin network could conceivably broadcast a ton of junk/illegitimate transactions to the network thereby consuming the bandwidth and processing power necessary for the network to deal with legitimate transactions.
I understand Bitcoin has two protocols in place to address this vector of attack:
1) First and foremost it has each node verify all information received before relaying it to its peers. As such, an attacker would barley get past first base (i.e, legitimate node 1) to be able to cause catastrophic damage to the network at large
2) banscore (which effectively computes how bad a node is behaving. Once it reaches a certain critical threshold a neighboring node will stop receiving connections from that node/IP for a period of time)
My main question is: considering the fact that the government (or a government run entity) controls IP allocation isn't this solution completely reliant/dependent on a centralized entity to work effectively?

...could conceivably broadcast a ton of junk/illegitimate transactions to the network thereby consuming the necessary bandwidth and processing power for the network to deal with legitimate ones.

If the transactions are invalid, then they would not be relayed by the network's nodes, making the attack somewhat ineffective. At best, the attacker could consume computational resources of peers they are directly connected to, though if they are spamming invalid transactions then they would probably be banned by their peers soon.
If the transactions are valid, then the attack becomes expensive, which is a disincentive over the long term. It would be extremely expensive to fill every block with 'spam' transactions, and there will still be other users that will compete (in terms of fees) to have their transactions confirmed first.
If some entity attacked bitcoin via IP/DNS blocks, this would not entirely shut down the network, though it would likely cause disruptions to some nodes. I believe that nodes which connect through Tor, or through other methods (such as by satellite) would still function without issue.

Attackers are financially disincentivized to do this.

They have to produce enough transactions, frequently enough to fill up blocks and keep them full
The transaction fee has to be large enough so they cause an actual clog instead of other users outbidding them with higher fees

To keep the above two points going for any meaningful amount of time costs a lot of money. It would only be temporary and only costs the attacker money. UTXOs still belong to their rightful owners and users on the network can start transacting again once the attacker loses interest and money.


text:
Merkle Root and Merkle Proofs
This is one of those questions that everyone seems to write about but the same bad explanations are just plagiarized from site to site.

Edit: The heart of my question is why Merkle trees are claimed to be efficient when determining if a leaf node is present or tampered with when only the root node hash and a leaf node hash value is known and when the Merkle hashes are not cached somewhere (which they appear not to be in the case of Bitcoin's transactions stored in a block)... I so far see only claims of efficiency not any credible demonstrations or explanations of same. The whole point, I understand, of the Merkle "proof" is that the hashes are stored and then the binary feature of the Merkle tree can be leveraged to "walk the tree" from leaf to root with only a fraction of hash calculations required; without the cached hashes, I submit that all hashes in the entire tree would need to be recalculated, as I explain below...

I understand how to build Merkle trees. What I don't understand are two key points about Merkle trees and one key point about Bitcoin's Merkle trees for transactions. For the sake of my questions below, consider this cited Merkle tree from investopedia.com:

Merkle Trees in General
People say that given the Merkle root hash and the hash to H(D), you can quickly determine:
A. Whether the H(D) leaf is in the Merkle tree.
B. Whether the H(D) leaf has been tampered with or whether it changed positions.
With respect to A: To do this, wouldn't you just look at the list of leaf hashes to determine whether H(D) is there? Why do anything with the Merkle root?
With respect to B: If you have the H(D) hash value and you know that its leaf pair is H(C), you can calculate H(CD). But at that point, if H(D) has changed and you know the old value for H(CD), wouldn't you immediately be able to short-circuit your investigation because the new H(CD) value would not equal the old H(CD) value? If you say to me that you don't have the old H(CD) value then I would ask you: How do I get the value to H(AB) then? It would seem that I need to recalculate the hash for H(AB). And if that's true, I also would need to recalculate the hash to H(EFGH), which means recalculating the entire right half of the Merkle tree starting at the leaf nodes. There isn't much efficiency in that.
My final question:
C. Does Bitcoin persist the Merkle tree hashes for not only the leaf nodes but for the entire tree all the way to the root? Where exactly and how exactly does it store this information? All I ever see is the Merkle root in the block... I think I once saw a Merkle value for a transaction node but I never saw any meta data related to non-tree Merkle nodes in the Bitcoin blockchain...
Thanks!

Reading your question, I suspect the cause for your confusion is around the setting in which Merkle trees are used. I think you are right that in the Bitcoin world, the setting is taken for granted and is not usually explained clearly.
Here's my two cents. To understand the efficiency aspect of Merkle trees, consider the two parties that are actually involved in the protocol:

A Bitcoin full node who has full blocks.
A Bitcoin thin node who has headers but wants to verify that a transaction is in one of the full blocks.
(It might be worth mentioning that the current Bitcoin protocol does not allow a thin node to efficiently verify that a transaction is not in any of the blocks.)

First, recall that when receiving a new block B with block header H and transactions T, the full node does the following:

computes h = SHA256(H), verifies the proof-of-work in h and checks the timestamp in H, etc.
for each transaction t \in T, verifies t's signature(s), verifies t does not double spend, and appends t as the rightmost leaf of the current block's Merkle tree. (Recall that a different Merkle tree is computed for each block. Of course, appending the transaction has to be done in a canonical order, so as to obtain the same root hash as in the block header H.)
after all t \in T have been verified and appended, computes and stores the Merkle tree, of course computing all interior node hashes and the root hash r (as depicted in your Merkle tree figure).
Crucially, verifies that the computed root hash r equals the root hash in the block header H.

Moral of the story: Yes, you are right that to prove membership of a leaf with respect to a Merkle root r, the prover (in this case, the full node) needs the interior node hashes: he can cache them or recompute them (there's some literature on trade-offs here). (I think) Bitcoin full nodes simply cache all hashes, as detailed in Step 3. Importantly, the interior hashes are not part of the 1MB block B: it would be a waste of space, since full nodes can simply recompute them from the leafs (i.e., the TXNs) and match the recomputed root hash with the one in the block header. Note that this prevents network adversaries from tampering with the transactions.
Second, recall that when receiving a new block header H, a thin node just does step (1) from above.
Now, here's the setting in Bitcoin:

The full node has all the blocks, including the interior node hashes computed in Step 3 above.
The thin node has all block headers. Recall that each header includes the Merkle root.
The full node wants to convince the thin node that some transaction t is in some block B with block header H (which of course the thin node has)

Thesis: Merkle trees allow the full node to convince the thin nodes of this efficiently, preventing the full node from changing t into t' (which would allow a full node to trick a thin node into thinking it got paid).
Proof: Let r denote the Merkle root in H. The thin node has that same H and r. The full node has the interior nodes "under" r cached (recall Step 3 from the full node). The full node fetches the (already cached) sibling path starting at the leaf containing the transaction t and going all the way up to the root r, sending it to the thin node. The thin node recursively hashes up t with the received siblings, obtaining a root hash r' (hand-waving here, assuming you understand Merkle proofs). The thin node checks that r == r'.
Efficiency: The full node (i.e., prover) only has to send O(\log{n}) siblings in a Merkle tree of n leafs to the thin node (i.e., the verifier), who only has a 256-bit root hash r. (Of course, the prover needs to have all the leafs and all the interior nodes, as discussed before.)
Naturally, this protocol guarantees the full node cannot "lie" about any transaction "under" the root r. Informally, if a transaction is there, the full node cannot change it to a different transaction and forge a proof for it (i.e., a sibling path). Also informally, if a transaction is not there at all, the full node cannot forge a proof for it being there.
To answer your questions:
Question A seems to be about how membership of a transaction t works. You say,

To do this, wouldn't you just look at the list of leaf hashes to determine whether H(D) is there? Why do anything with the Merkle root?

I think you're misunderstanding the setting. Keep in mind, that when discussing cryptographic protocols, it's quite necessary to refer to the parties by name, rather than using ambiguous pronouns like "you" and "I." "Prover" and "verifier" can be terse and boring, but is precise.
The thin node cannot "just look at the list of leaf hashes" because it only has the root hash and no leafs but wants to be sure that a leaf is there. The full node could send the thin node all the leafs and have the thin node hash them, obtaining the same root hash. However, that would be inefficient: O(n) bandwidth for n leafs. In contrast, a Merkle proof for a leaf under a root hash is much more efficient: only O(\log{n}) hashes + the leaf itself.
Question B should be answered by now: the full node has all interior node hashes. It sends the sibling path to the thin node, who simply recursively hashes up from the leaf being checked. The thin node verifies the root it obtained matches the root in the block header.
Question C:

Does Bitcoin persist the Merkle tree hashes for not only the leaf nodes but for the entire tree all the way to the root?

Not in the blocks themselves: it would be a waste of space as mentioned before. Full nodes compute the interior hashes and the root hash and cache everything locally on disk (presumably, I haven't actually looked at the source code). Then, they are ready to serve proofs for any transaction in any block to any thin node.

Where exactly and how exactly does it store this information? All I ever see is the Merkle root in the block...

Presumably, on disk in the database of the full node. But not in the block: they are redundant info because blocks contains leafs => can compute hashes of interior nodes and root node.

I think I once saw a Merkle value for a transaction node but I never saw any meta data related to non-tree Merkle nodes in the Bitcoin blockchain...

Ugh, I want to say "Yes, because it would be a waste of space to store interior node hashes in the blocks." but reading closer I don't actually know what you mean by "Merkle value for a transaction node" and "metadata related to non-tree Merkle nodes."
Hope this helps!

In regards to 'wouldn't you just look at the list of leaf hashes to determine whether H(D) is there?', in doing so you miss proof that the transaction is in the block and that the block is unaltered. The computation steps are necessary for proof.

Of course! @Jazimov, if you find your reply to be too long, you might want to simply ask one or more new, concise questions?

@Alin: Great answers: Just one comment (please revised/append your answer if you agree that this point was unclear)... With respect to you answer to my Question A: [[The thin node cannot "just look at the list of leaf hashes"]] I understand that. But if thin node wants to verify that transaction 12345 is there, why not just ask the full node to look at its full-node leaf Tx values for transaction 12345 (or a hash of 12345)? That's enough to prove the Tx is in the block, no? Computing the Merkle root, though, guarantees that's it's there AND in the same position. Is that the real point?

@Jazimov, I will edit my answer to clarify. The quick answer I can give you now is that no, it is not enough. Just ask yourself: What's to prevent a full node from showing one thin node TXN 1235 sending coins from A to B while showing another thin node TXN 12345' (not part of the block) sending coins from A to C and thereby double spending? The answer is the Merkle membership proof + miners preventing double spends. It is important to note Merkle trees are sufficient, but not necessary here, as I discussed in a previous answer you linked to.

@Jazimov, I realized I am bit confused by your question. You said "But if thin node wants to verify that transaction 12345 is there, why not just ask the full node to look at its full-node leaf Tx values for transaction 12345 (or a hash of 12345)?" What would the full node looking at a TXN in some leaf achieve? The thin node needs to be convinced with a cryptographic proof from the full node. The full node can look wherever it wants, but that won't convince the thin node of anything. Position in the tree of a TXN doesn't matter AFAICT. (Why would it?) Am I misunderstanding your question?

If a thin node wants to verify that TXN 12345 (say it has hash of "123AABBC") is in full node, I am wondering why the full node can't just inspect its list of TXNs for a hash = "123AABBC"? That could be sped-up using an index of hashes for full-node TXNs. My comment relates to why a Merkle proof would need to be part of that full-node verification that TXN 12345 (via it's hash) is in fact in the full node...

First, the thin node wants to verify that TXN 12345 is in a block. Not sure what you mean by "in a full node." The full node is merely helping relay data that convinces the thin node, specifically, the Merkle sibling path. This Merkle proof is sufficient to convince the thin node that TXN 12345 is in the block. However, other techniques can be used as well: it's just that their proof size will be bigger or they come at a higher computation overhead! If you understood the setting (i.e., full node tries to convince thin node that TXN is in block), you need to understand Merkle security.

To understand the security of Merkle proofs, it's probably best to ask a separate question or see what's out there. Keep in mind that the prover can lie to a verifier. Commiting to the data using a Merkle tree and giving the root hash to the verifier before the verifier queries, prevents the prover from lying to the verifier about the data if the verifier correctly checks the Merkle membership proof.

OK, "in the block" (I said full node because all transaction data rather than header only is in a full node only).Meanwhile, I think you and I agree that a Merkle proof composed of a sibling path is sufficient to prove that a TX is in a block. I still don't understand why the sibling has to be involved. Why not just hash TX 12345 and check if its hash is a leaf node? As I already said, an index containing hashes of leaf nodes will speed that look-up. Why get a sibling involved?

Let's take the simplest example and make sure we understand each other. Suppose the prover has tx_1 and tx_2 with hashes h_0 and h_1 respectively. Suppose the prover computes a Merkle tree over these two leafs so the root hash is r = H(h_0, h_1). (This is a really small tree.) Suppose the verifier has r and prover gives it just tx_1 and h_1 as a (insecure) membership proof? I'm assuming this is what you're proposing. Is this correct so far? If so, you tell me how the verifier should check this (insecure) proof... :)

Say a block consisting of these 10 transactions, noted by their txids at indexes 0 to 9:
E1AF205960AE338A37174B407EE71067C3CD7F04D48A5CEC7E13F6ECCB61DCBC
A314970CD7C647D1CC0A477E1A2122B98205B6924B73001B8DAB20EE81C2F4F7
B08EB9DCE0452A1B1970C4D29E88BDEE07669A2A5D1B08586D7FFA17B2E3F6B5
958B9E94AEA9A485BA494C50FB3192558057F7CAED9705D4B11369F071F10642
3D278CA01CC527D4C7D577B668E0B976FBBCB94E6A9BA89664C721F36FADA6A1
95AFFA405501498EF6F4E4B6CDDC1F1B24B9D2E534584B31A9142C453920C889
D97A21CF46FD5AFB0BF9EA4237BC4BF5C84E8B47D38D1EEE2BBEB5C0F8A1C625
AE1E670BDBF8AB984F412E6102C369AECA2CED933A1DE74712CCDA5EDAF4EE57
90E03319DDC9D48DA38AB39B2F37C0A5AF5AFC736F6FF2A9D8B8653E0FEB308D
84251842A4C0F0E188E1C2BF643EC37A1402DD86A25A9AB5004633467D16E313

With a merkle root that we both agree on (it's in the blockchain):
B152ECA4364850F3424C7AC2B337D606C5CA0A3F96F1554F8DB33D2F6F130BBE

And say you want me to prove to you that the transaction D97A21CF46FD5AFB0BF9EA4237BC4BF5C84E8B47D38D1EEE2BBEB5C0F8A1C625 is in this block.
I give you this proof :
AE1E670BDBF8AB984F412E6102C369AECA2CED933A1DE74712CCDA5EDAF4EE57,
EFC2B3DB87FF4F00C79DFA8F732A23C0E18587A73A839B7710234583CDD03DB9,
F1B6FE8FC2AB800E6D76EE975A002D3E67A60B51A62085A07289505B8D03F149,
E827331B1FE7A2689FBC23D14CD21317C699596CBCA222182A489322ECE1FA74

And tell you that this transaction is at index 6, and that this is a tree of depth 4.
(2^4) + 6 = 22, and that is 10110 in base 2.
This representation in base 2 is the path we need to take from the first txid for which we want to prove the inclusion to the root.
Now all you're left with is to walk the path from the txid to the root, and if proof is correct, then you should get the block's merkle root.
We start the path from right to left, so with the 0 bit of of the base 2 number (the left most 1 is not used (it is the root really)).
Since this is a 0, we should place "our" hash (the txid) on the left side :
hash256 D97A21CF46FD5AFB0BF9EA4237BC4BF5C84E8B47D38D1EEE2BBEB5C0F8A1C625|AE1E670BDBF8AB984F412E6102C369AECA2CED933A1DE74712CCDA5EDAF4EE57
=
066AD6D9939EC0C90B7F3B775122785BD8ACA2A2C5857205AF7E0615E9AF9796

The next is a 1, "our" hash is on the right :
hash256 EFC2B3DB87FF4F00C79DFA8F732A23C0E18587A73A839B7710234583CDD03DB9|066AD6D9939EC0C90B7F3B775122785BD8ACA2A2C5857205AF7E0615E9AF9796
=
8BE15FC2AB11EF3E079568D43B2B09ED5A5690FB13ECB1032F7AAB99238A1847

Next is a 1 again, so again we're on the right :
hash256 F1B6FE8FC2AB800E6D76EE975A002D3E67A60B51A62085A07289505B8D03F149|8BE15FC2AB11EF3E079568D43B2B09ED5A5690FB13ECB1032F7AAB99238A1847
=
8D9D737B484E96EED701C4B3728AEA80AA7F2A7F57125790ED9998F9050A1BEF

Next is a 0, we're on the left :
hash256 8D9D737B484E96EED701C4B3728AEA80AA7F2A7F57125790ED9998F9050A1BEF|E827331B1FE7A2689FBC23D14CD21317C699596CBCA222182A489322ECE1FA74
=
B152ECA4364850F3424C7AC2B337D606C5CA0A3F96F1554F8DB33D2F6F130BBE

And this is the block's merkle root.  The proof is correct.
The txid exists in a block on chain in this specific index, and the block has the correct depth.
For a very large tree, the effect is even more dramatic.  The quantity of steps it takes to prove an element is in a tree is logarithmic to the size of the tree, so proof stays small.
Hopefully this is what you were asking.
These transactions are from block 0000000000000a3290f20e75860d505ce0e948a1d1d846bec7e39015d242884b by the way.

I followed the above. But after you offer the proof, it's unclear where you get these values from:
AE1E670BDBF8AB984F412E6102C369AECA2CED933A1DE74712CCDA5EDAF4EE57, EFC2B3DB87FF4F00C79DFA8F732A23C0E18587A73A839B7710234583CDD03DB9,
F1B6FE8FC2AB800E6D76EE975A002D3E67A60B51A62085A07289505B8D03F149,
E827331B1FE7A2689FBC23D14CD21317C699596CBCA222182A489322ECE1FA74. According to what other people have written, the hash values for everything in the Merkle treet (OTHER THAN the Merkle root) is not stored anywhere in the blockchain...

These four values correspond to the yellow elements in the tree in your example (you have a tree with depth 3, so only 3 of these yellow elements).
Anyone with the full list of transactions in a block can generate them for someone else asking to see proof that a transaction is included in some block, or when encountering such proof themselves, it is easily verifiable (only about log(n) steps) without going through the whole transaction list.

Wrong, you cannot generate just the yellow element hashes without recomputing the entire tree and that doesn't save any computations.

"My question is why Merkle trees are an efficient way for blockchains to determine whether transactions are present in the Merkle tree given the Merkle root hash value and the leaf hash value.
I don't see how it's possible to execute a Merkle proof without recalculating the entire Merkle tree."
It's not an efficient way for "blockchains" to do anything.  Merkle proofs are an efficient way to prove membership of an element in a set.
This is used by lite-wallets and their servers.  Not by the actual bitcoin protocol.

Then what's the point of using a Merkle root? Why not just calculate a single hash from every transaction in transaction sequence? That also would generate a unique hash that detects transaction-sequence changes as well as transaction data changes. Why go with Merkle at all???

Because it's very useful to be able to prove membership of a transaction in a block using only log2(tree size) hashes instead of using the entire transaction list (which is the tree size itself).  SPV has been an intended feature since the beginning, and while we're not using the same SPV talked about in the white paper, the merkle tree construction still applies.
Consider that proving a txid exists in a set of 2000~ txids will take 11 hashes using a merkle tree construction, versus the entire 2000~ transactions given in a linear list.

How can I "ask" to full node, please check this D97A21CF46FD5AFB0BF9EA4237BC4BF5C84E8B47D38D1EEE2BBEB5C0F8A1C625 and return 4 txid to check manually like your example? thanks

+1 for this much better answer than the accepted one...

There are two kinds of efficiencies:

Computation: Merkle tree is as efficient as any other binary search tree in terms of computation and searching.
Storage: This is where the magic happens.

Merkle root: HABCDEFGH
Hash to verify: HD
Process:
1. HCD       = Hash( HC , HD)
2. HABCD     = Hash( HCD, HAB)
3. HABCDEFGH = Hash( HABCD, HEFGH)
In the whole process of verification of HD(of total 8), we only need to store extra 3 hashes (HC, HAB, HEFGH).
Storage complexity: log2n = log28 = 3
When n = 1024: log2n = log21024 = 10
When n = 1048576: log2n = log21048576 = 20
In this sense, Merkle trees are efficient compared to other data structures.

For a bitcoin block to be valid, the block's header must hash to an output that is within a certain range of values (defined by the current network difficulty).
The merkle root is one component of the block header, so in effect the merkle root is a cryptographic commitment to the transactions included in the block. Changing any single transaction (or the order of transactions) would alter the merkle root, and thus alter the block's hash (which, by overwhelming probabilty, would make the block invalid).

With respect to A: To do this, wouldn't you just look at the list of leaf hashes to determine whether H(D) is there? Why do anything with the Merkle root?

The leaf hashes are not explicitly contained in the block, but it is trivial for any node to verify that a given transaction is properly included in the block (and therefore included in the merkle root). This is done by hashing the transaction [in your example, H(D)], and then combing H(D) with H(C) to get H(CD), and so on, until the merkle root is reached (and found to be correct against the merkle root of the block).
Full node clients download the entire blockchain, and are thus capable of performing this validation on their own. 'Litewallet' clients just download the block headers, and can use simplified payment verification (SPV) to perform a cryptographic check for transaction validity in a less intensive manner. SPV involves requesting just the hashes in the relevant branch of the tree, working from the transaction in question up to the root. Any attempt by the wallet's peers to lie about the transactions/hashes in a block will result in an invalid merkle root, so it is impossible for a peer to lie and say a transaction is included in a block, when it is in fact not.

With respct to B: If you have the H(D) hash value and you know that its leaf pair is H(C), you can calculate H(CD). But at that point, if H(D) has changed and you know the old value for H(CD), wouldn't you immediately be able to short-circuit your investigation because the new H(CD) value would not equal the old H(CD) value?

It is not a matter of knowing a 'new' or 'old' H(CD), there is simply the H(CD) that was an intermediate step in calculating the merkle root of the relevant block. Once the block is accepted as valid by the network, there is no ability to change a transaction in it (and thus change the higher level hashes in the tree). Changing anything would change the merkle root, and thus the block's hash, so the network would no longer accept that block as valid.

C. Does Bitcoin persist the Merkle tree hashes for not only the leaf nodes but for the entire tree all the way to the root? Where exactly and how exactly does it store this information?

Each block contains the merkle root, as well as all of the transactional data. The leaf / intermediate level hashes are not explicitly included, instead they can be calculated by nodes to verify and validate the block's transactional data. (There are some other bits of data included in a block, but it is the merkle root and transaction data that is relevant to your question)
You may be interested in reading over the top answers to this question, they are great explanations of the function of the merkle root.

Answer appreciated but you totally missed the point of my questions. You say that "it is trivial for any node to verify that a given transaction is properly included in the block" and cite calculating H(D) hashes back to the root. But as my question articulated, you cannot calculate the Merkle root from H(D) without reconstructing the ENTIRE Merkle tree hashes. I realize this can be done, but there is no efficiency in doing that because all leaf nodes must be rehashed to calculate the root. Merkle proofs speak of the "efficiency" of the Merkle structure in proving a node exists.

My issue is not that I do not understand how to create a Merkle tree and the root hash--which is what you explained--but why this structure is EFFICIENT especially if non-leaf hashes en route to the Merkle root are not retained in a Bitcoin block. Please re-read question B to see my specific example. Thanks!

In that case, the ‘efficiency’ comes from being able to cryptographically commit to a huge number of transactions being in a given block. Having to include all of the txs in the header explicitly would be much less efficient. So yes, a node must perform these validating computations, but the ‘efficiency gains’ talked about do not relate to this specifically (at least as far as I’ve ever read/understood).

Related: Consider also that having a Merkle root in the block header (instead of an explicit list of transactions) means that a miner must perform the same computation for a block with 5 txs as a block with 500 txs. So there is no incentive for a miner to include less txs, in order to perform POW computations more quickly.

You're still missing my point. Read Alin Tomescu's answer in https://bitcoin.stackexchange.com/questions/48928/why-does-each-block-store-a-merkle-root. He says "Merkle roots are stored in Bitcoin block headers so as to enable efficient membership proofs for transactions in a block, which are necessary for Simple Verified Payment verification (SPV) nodes that only store block headers and not block contents" but doesn't explain. My question is about "efficient membership proofs" and you're not addressing that in any of your responses.

I think I understand better now. Rather than download and hash through every transaction in the entire tree, an SPV wallet can just request the sibling hashes. So in your example, after calculating H(AB), a wallet can just request H(CD), rather than requesting T(C) and T(D) to calculate H(CD) locally. An SPV wallet can trust it has been provided with valid info as long as the Merkle root is reached. So a transaction’s membership in a block can be verified more easily than if every transaction in the block had to be hashed. The Q I linked to has a little more info on this.

comment to B: wouldn't SPV nodes read the six blocks from the first occurance of the tx in a block, and then with the six'th block do the final check? a peer would send the requested block with the block header and the merkle path (for the tx). The SPV node uses this path to calculate up to the block header. That is, what speeds up the verification time....

Let's start with understanding the fact that BlockChain(Bitcoin's ledger) is distributed across multiple nodes. So, nodes cannot trust each other as they are not managed by some trusted party. Whenever a thin node(non-miner) P request's a full node(miner) Q to verify the presence of a txn t in a block B the full node Q has to convince the node P that it(Q) is saying the truth. Merkle trees come into play here.
So, the thin node P has the root-hash of block B and the hash of the txn t. The one thing the full node cannot wrongly convince the thin node about the block B is its root-hash. So as proof to "the full node is telling the truth about the presence of txn t in block B" it also sends the hash values of the sibling nodes of the nodes in the path from the root to the txn t in the Merkle tree. The thin node then backtracks the hash values along the path from txn t to the root of the Merkle tree using the sibling's hashes sent by the full node. If the resulting root-hash is equal to the one in block B's header then the full node is telling the truth.
Now assume I'm a full node and I want to falsely convince a thin node that a txn t is in block B. I can simply say that I've checked all the leaf's hashes and found hash of txn t in the list. But who can tell if I'm lying. Now the leaf node might request me to send the list of txns to check the list by itself, but I can always add the txn t to the list and send over the altered list.
Now if the thin node asks me to provide the hash value of the parent node of the txn t so that it can verify itself by hashing txn t's sibling and t together and compare the result with the parent's hash I just sent over. Now I can just send a wrong hash value of the parent to misguide the thin node. So the thin node has to verify that this parent-hash is infact the actual hash in the Merkle tree. This process of verification is recursive until I reach a point where the parent node is the root node. This time the thin node has the hash of the parent node and can verify itself. So whenever the thin node can backtrack the root-hash to the one in the block's header the full node is not lying/misguiding.
Now all of this is possible because of the one-way/non-invertible nature of the hash functions used. As we cannot predict inputs to be given according to the desired hash, I cannot adjust sibling hashes I sent to the thin node to make sure that the backtracking ends up giving the correct hash value of the root node.

One of the previous answers directly answers your question about efficiency. It is certainly not necessary to communicate or store every hash.
One great efficiency of using a Merkle Tree is:

https://en.bitcoin.it/wiki/Block_hashing_algorithm
  The body of the block contains the transactions. These are hashed only indirectly through the Merkle root. Because transactions aren't hashed directly, hashing a block with 1 transaction takes exactly the same amount of effort as hashing a block with 10,000 transactions.