Why is this burn address starting to get confirmations?

Question

Can anyone explain why the burn address 1111111111111111111114oLvT2 started receiving confirmations only on 8th June? 1st transaction is 11yrs?

I thought a burn address doesn't get any confirmations, especially all I checked are through OP_return?

Also, the same address gives an error here: https://blockchain.com/btc/address/1111111111111111111114oLvT2 . -I knew that addresses r case sensitive, that's why it originally gave an error, so changed L,T to upper case -Still don't understand (not convinced with) the confirmations issue, and I think the 2016 Transaction presented in the Comment is from another address (if so, then it's out of my Q context) -Finally, adding a more curiosity Q from comments to main: Will all these 133,555 UTXOs (more than 2¹⁷) in this address reside in the system Merkle Tree forever? or No because they appear in OP_Return ?

The written answer does not answer the main point of the Q:

1-it explains that confirmations are to TXs not addresses, well I know that & my Q was that none of the TXs that transferred money to this address got confirmed before 8/6/2021

2-The answer re explains the fact that this is a burn address because it's from key "0", which means yes it should not get confirmations?

3-Followed the answer is a comment showing a confirmation from 2016 to a completely different address?! which is misleading & does not give an answer?

4-The 2016 Comment was divided into 3 consecutive comments by the same person before me replying, which reached the comments limit and I had to write here with the only other option a private chat with that person????

-To be fair, I gained 2 infos from the answer: 1-Addresses r case sensitive 2-The given address is the hash of public key zero

Answer 1

Base58 addresses are case sensitive. With the correct capitalization, the address resolves fine: https://blockchain.com/btc/address/1111111111111111111114oLvT2.

Addresses do not get any confirmations. Confirmations pertain to specific transactions not addresses. When a transaction is included in a block that constitutes the transaction's first confirmation. The transaction's confirmation count increases for every subsequent block thereafter. However, confirmation counts are independent for each transaction, even if they happen to pay to the same address.

The address 1111111111111111111114oLvT2 was first paid to 11 years ago, but has received outputs from a total 96,980 transactions altogether since, with the most recent transaction occurring this week. Your screenshot shows the times of the first and last transactions that involved the address, but the cited information does not indicate that there was no activity between those dates. Other than indicated in comments, none of the address's 133,555 outputs have been spent.

The address 1111111111111111111114oLvT2 encodes the public key hash 0. Given that it was obviously picked via that public key hash, the private key can be presumed to be unknown as it would require someone to break the pre-image resistance of RIPEMD-160 to find a corresponding public key, and then to solve the Elliptic Curve Discrete Logarithm Problem to find the corresponding private key, both of which are considered to be infeasible.

---

Regarding the follow-ups from the edit:

1. All discussed transactions involving 1111111111111111111114oLvT2 were sending funds to the address. None of the funds sent to 1111111111111111111114oLvT2 were ever spent.
2. Yes, all the transaction outputs sent to 1111111111111111111114oLvT2 will remain in the Unspent Transaction Output (UTXO) set forever.
3. The UTXO set is not a Merkle tree.
4. Numerous of the transactions sending funds to 1111111111111111111114oLvT2 have more than one output. Some of the other outputs are OP_RETURN outputs. Outputs cannot both be OP_RETURN and send to an address at the same time, it's one or the other.
5. OP_RETURN outputs are not part of the UTXO set.