Is Bitcoin data in this site accurate or fake?

[Shymaa-Arafat]

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

[NeuroticFish]

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

Yes. It's a blockchain explorer and the wallet data they display is usually accurate.
Even more, you can get that address 3279PyBGjZTnu1GNSXamReTj98kiYgZdtW and put it in any other block explorer (blockchair.com, mempool.space, chain.so, ... ) and they will all show the same.
Or, if you want, you can add the address (as watch only) in a wallet and you'll see the data again.

Simply, for Bitcoin, all the transactions and the content of any wallet is public information. Of course, it's much more difficult (or even impossible) to know who does the address(es) belong to.
(Edit: it looks like it's the wallet of a pool that was existing til March, called Lubian)

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

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

Edit: I was meant piggy bank, I don't know why I didn't actually typed it.

[Shymaa-Arafat]

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?

Banks r similar to account-based cryptocurrencies in this point

[BlackHatCoiner]

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

It does have a single (spent) output:

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.


[1] 1111111111111111111114oLvT2

[NeuroticFish]

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?

Banks r similar to account-based cryptocurrencies in this point

Sorry, for some reason I've missed one crucial word.
So here we are: I meant piggy bank

[Shymaa-Arafat]

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.

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

[ymgve2]

There is no global Bitcoin Merkle Tree. Merkle trees are just used to organize and verify transactions within a single block.

[Shymaa-Arafat]

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

[BrewMaster]

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

no there is no merkle tree of UTXOs anywhere. there is a database that stores an option UTXO set so that the full node doesn't have to rebuild it on every run.

[Shymaa-Arafat]

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)
- What u r referring to by only a set of them, is probably what some enhancements make by caching (ie make an educated guess of what UTXOs the node will need in the near future and bring them to internal memory to make things faster)

[BrewMaster]

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)

UTXOs are unspent transaction outputs, they are stored in the chainstate.
what is stored in a block header is the merkle root hash of the transaction hashes inside that block not UTXOs.

-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)

full nodes don't store the tree itself (unless you are talking about an altcoin and not bitcoin). only the root hash is calculated to validate the header then discarded. if there is a need for it (like for answering SPV clients) the full node can build it on demand.

[Shymaa-Arafat]

u may watch this video, maybe 1st 5mins is enough, to an explanation demonstrated by graphs & figures
https://youtu.be/HEKtDILPeaI

[HCP]

That video appears to be talking about a proposal for stateless nodes... as far as I'm aware, they're not actually 'fully' implemented outside of the research project nor are they in common use.

In fact, the video even describes how Bitcoin is currently working... with the "chainstate" that is the "set of UTXOs" that is stored by a Full Node... and how "lite nodes" work.

[Shymaa-Arafat]

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

I know the Trie idea in the paper is not implemented, I added the link because (I think) the introduction gives a good graphically demonstrated explaination of where and why Merkle Trees r stored (sometimes the tree is physically stored in a sequential array on memory, but that's not the issue). There is a Merkle Tree, from
https://codetrips.com/2020/08/02/modern-c-implementing-a-merkle-tree/

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

I know, I've seen others (not just this person, but she is the one I could reach to from those who skipped this as a too technical detail) prefer to skip this detail for non specialized listeners in this specific area
https://mobile.twitter.com/sasamilic33/status/1395599263820886025
.
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.

»»»» "Hashes" of the UTXOs
sorry I took it for granted the hash of a  UTXO is what we use to proof it & that's what the tree leaves store (along with a link to the real value ofcourse)

[HCP]

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.

Yes... Bitcoin uses Merkle Trees... but not for storing UTXOs (at least as far as Bitcoin Core is concerned). As noted above, it uses them for mapping transactions in a block... thus arriving at the Merkle Root stored in the Block header. But it doesn't use a Merkle Tree for storing/holding UTXOs... which is what the original point you were trying to make was:

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

So, that just isn't correct with regards to a full node like Bitcoin Core... it has the UTXO set stored in the chain state db... this is not a Merkle Tree.


So, it seems that perhaps there is some confusion to what you're actually referring to... when you asked:

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.

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

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, until such time that it is successfully spent in a transaction.


Whether or not a UTXO exists in any "Merkle Tree" would be wholly dependent on the exact implementation being used by whatever node software you happen to be referencing...

[Amplify]

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


[1] 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.

[BlackHatCoiner]

Does that mean those bitcoins are lost forever?

Yes, they're lost forever, hence the “burning”.

Why do people still send coins to those addresses?

Because it may work as a mechanism for other block chains. It's called Proof of burn and there was a thread talking about it recently: Weird Bitcoin address (1111111111111111111114oLvT2)

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, but hey, if the money you're throwing aren't inflating then they instantly are more valuable than before. 

[Shymaa-Arafat]

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

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)
.

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

-I think in the 1st case u like buying the token or trading it with Btc, ie not throwing anything.⟩» I think if this was the case maybe it's responsible for the price down (it's like selling to buy the token)
-In the 2nd case when sending deliberately to deadend, yes this did even happen in milk very long ago (maybe 20yrs+, don't recall the country), but here it's somehow different like subtracting from the total volume or a country central bank decides to print less money than usual to balance the currency⟩»ie if on the other hand this was the case, then they sacrificed this amount of money to keep the price from going even more down?
I don't know for sure
.
Oh from here
https://www.investopedia.com/terms/p/proof-burn-cryptocurrency.asp

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.

and
https://youtu.be/Q5L8-GJVmZw

[HCP]

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

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)

In that particular stateless node implementation, yes... UTXOs would need to be stored in a Merkle Tree for their proposed system to work. Again, it's just a proposal as far as I can tell. It is not detailing how Bitcoin currently works.

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/

[Shymaa-Arafat]

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

-As the presentation of the paper says, this is like a problem definition of the state co before they or even Utreexo proposed their model. Yes there r many many research projects but these r variations of the tree since 2010
https://bitcointalk.org/index.php?topic=101734.0

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.

...

From ur Bitcoin core

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

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

yes the val of the UTXO is stored in the database, but it's the UTXO that's get stored in the Merkle Tree as stated, only in this example they represented it with it's creating TX id, what if more than 1 UTXO resulted from the same TX?
However, it is their fault they should have clarified that in their example since most TXs (more than 50% I think) have more than one ouput

.
I think this part from the Utreexo paper may also clarify any mis understanding for both of us (as I'm not that familiar with SPV)

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.