Bitcoin Forum

Does anyone knows if this site statistics & data r true & accurate?
https://m.btc.com/
.
For example how can a single address holds all these "in" values without a single output???
https://m.btc.com/3279PyBGjZTnu1GNSXamReTj98kiYgZdtW

For example how can a single address holds all these "in" values without a single output???

Well, if you have a bank you keep adding coins into, isn't it in the same situation? I.e. a lot of inputs and no outputs?

For example how can a single address holds all these "in" values without a single output???

Banks r similar to account-based cryptocurrencies in this point

But even if it didn't, what the odd with that? In Bitcoin, each time you make a transaction and spend an output, you're locking your funds on some other address(es). They don't have to spend anything. Take a burning address as an example[1]. It'll never have spent outputs.

Ofcourse there is a global Merkle Tree (or Forest according to the implementation) for all still living UTXOs

NO
There is a Merkle Tree of hashes of UTXOs, only not all nodes store the tree
-An accumulated value of all the tree hashes ( the value of the root node) is stored in the block (called the accumulator)

-The complete tree is stored in Full nodes and bridge servers that communicate with stateless nodes( nodes that don't store the tree and ask the bridge server of the complete path, called proof, of the UTXO in hand they need to verify)

as far as I'm aware, they're not actually 'fully' implemented outside of the research project nor are they in common use.

As mentioned, Merkle trees are used in the Blockchain and are described in greater detail in Mastering bitcoin (Chapter 7, “Merkle Trees”).

What I know is Bitcoin uses Merkle Trees, Ethereum uses many Merkle Tries( I think 4), Cardano uses AVL Trees to store the UTXOs, Algorand doesn't have niether Merkle Tree norTrie structure at all.

Ofcourse there is a global Merkle Tree (or Forest according to the implementation) for all still living UTXOs

Something I don't understand here:
all these values still reside in the Bitcoin Merkle Tree as UTXOs, or do not get included?

Take a burning address as an example^[1]. It'll never have spent outputs.

---

[1] 1111111111111111111114oLvT2 (https://blockchair.com/bitcoin/address/1111111111111111111114oLvT2)

Does that mean those bitcoins are lost forever?

Why do people still send coins to those addresses?

It doesn't make sense to me. It's like throwing money down the drain.

Any UTXO, regardless of whether or not it is associated with a "burn" address, will continue to live in the chainstate db of a Bitcoin Core full node

Quote from: Amplify on Today at 11:51:53 AM
It doesn't make sense to me. It's like throwing money down the drain.
If someone promised you that you'll receive some tokens by burning some bitcoins it does. You do throw money down the drain

Proof of Burn
Proof of burn (POB) is an alternative consensus algorithm that tries to address the high energy consumption issue of a POW system.
POB is often called a POW system without energy waste. It operates on the principle of allowing miners to “burn” virtual currency tokens. They are then granted the right to write blocks in proportion to the coins burnt.

That's we do agree about, I think?, What I'm saying is that in addition to the value being stored, a hash of the value is stored in a Merkle Tree until it got spent
https://mobile.twitter.com/ArafatShymaa/status/1398300471505436675
(The slide in min 5:07 in the paper presentation)
Full nodes, bridge nodes store the full tree; stateless nodes store only the proofs.
Look at a simple TX in the testnet for demonstration u'll find proofs/witnesses attached to the TXOs not to the TX (per output not per TX)

it's just a proposal as far as I can tell. It is not detailing how Bitcoin currently works.

Related Work
ByteCoin first proposed including the hash of the current "balance sheet" in each block (i.e., the set of available unspent tx outputs), making it possible to validate transactions without needing to store the entire blockchain. Greg Maxwell later suggested using a Merkle tree in order to query such this set more efficiently. DiThi later made an equivalent proposal. Most recently, etotheipi suggested using a self-balancing Merkle tree so that incremental modification to the structure would be more efficient. I scoured the academic literature, finding a Usenix paper from 1996 by Moni Naor and Kobbi Nissim, suggesting that a RedBlack tree could be augmented with hashes instead of pointers. I wrote a reference implementation of such an "Authenticated Data Structure". To my knowledge, it is the only available (open-source) implementation of a self-balancing hash tree.

Hash trees (of the non-balancing variety) are widely used, for example in Git and in Tahoe-LAFS.

"height": 1,
"version": 536870912,
"merkleroot": "37c2334d0314e11d396b5465e9bc5ec7cf0155c13a47f1af2731174331b3b78d",
"tx": [
"37c2334d0314e11d396b5465e9bc5ec7cf0155c13a47f1af2731174331b3b78d"
],

In the above example, we can see the utxo represented by its txid

Every node in the network verifies and stores the entire state of the system. Each user of the system has a wallet, which tracks at least one UTXO, but generally several. As the number of users of the system increases, the
 UTXO set grows, and the resource cost of running a node increases. This
 has led to a progressively smaller proportion of users running their own
 node as more users rely on light clients or on 3rd party nodes to inform
 them of the state of the network. Light clients, nodes that do not store
the system state and do not validate transactions, can still obtain some assurance about transactions through Simplified Payment Verification (SPV),
which leverages Bitcoin’s Proof-of-Work and block commitment scheme to
 give compact proofs of transaction inclusion into a (not necessarily valid)
 blockchain.
 SPV, while reducing the resource costs of operating a network node,
 comes with a number of security and privacy weaknesses not present in full
nodes. SPV nodes rely on fully validating nodes to enforce the rules of the
 system as they cannot do so themselves. An adversary with sufficient hashing
power can present transactions which SPV nodes will accept as confirmed,
 but which will be rejected by fully validating nodes. While improving the
security and privacy of SPV is a promising area of research, this work focuses
 only on fully validating nodes, and on reducing the resource requirements
 to run one.

Today, right now... my Bitcoin Core node does NOT have a merkle tree of UTXOs... it has a LevelDB database that is stored in the "chainstate" folder of the Bitcoin Core data directory: https://bitcoindev.network/understanding-the-data/

std::vector<CTransactionRef> vtx;

"height": 1,
"version": 536870912,
"merkleroot": "37c2334d0314e11d396b5465e9bc5ec7cf0155c13a47f1af2731174331b3b78d",
"tx": [
"37c2334d0314e11d396b5465e9bc5ec7cf0155c13a47f1af2731174331b3b78d"
],