Are those non-btc uses of UTXOS still exist?& Also Dust ratio

[Shymaa-Arafat]

I have been reading about kinds & analysis of UTXOS, and since the material is not quite new I'm double checking here if things has changed
1- Non-Btc uses of UTXOS
In here
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012715.html
It's written

timestamping applications often create unspendable outputs due to
ease of implementation, and because doing so is an easy way to make sure that
the data required to reconstruct the timestamp proof won't get lost - all
Bitcoin full nodes are forced to keep a copy of it. Similarly anti-replay
use-cases like using the UTXO set for key rotation piggyback on the uniquely
strong security and decentralization guarantee that Bitcoin provides; it's very
difficult - perhaps impossible - to provide these applications with
alternatives that are equally secure. These non-btc-value-transfer use-cases
can often afford to pay far higher fees per UTXO created than competing
btc-value-transfer use-cases; many users could afford to spend $50 to register

( u can read it more colorful from here https://mobile.twitter.com/ArafatShymaa/status/1411692408501424130)
I have read about MMR (Merkle Mountain Range) before, but I don't recall reading about such uses; or r they part of the "non-standard UTXOS"?
However, the point they're stored and counted in the set that constitute the system status, or not????
.
2-Dust
I found the previous reference in the following paper
https://t.co/99sc8Ov4vd?amp=1
Which states that "dust UTXOS" r about 30-40% of the whole set (it states more at 2019,
https://royalsocietypublishing.org/doi/10.1098/rsos.180817
 but when I use the current recommended fee/byte by Blockchair  83 Satoshi it's about that ratio
https://m.facebook.com/photo.php?fbid=1458225041198606&id=100010333725264&set=a.1394620207559090
)
It's stated some where in the paper that Bitcoin core defines dust value limit ( the curve marked "dust" in their figs), but does this means it's not stored from the beginning????
-Because I remember in one of my questions to the Utreexo team they said the Bitcoin core does not store Unspendable TXOS, at that time I thought they meant whatever appears in OP_Return, now I wonder r those mentioned above included too????
.
-However, since this article specifically mentions Samourai about Dust
https://www.news.com.au/finance/money/investing/what-is-dusting-how-hackers-are-exposing-holes-in-cryptocurrency-privacy/news-story/5a74d5d3a3e677e8111ab0e91927a894
it seems application dependant?

-One more question, does this means any user can mark an UTXO as Unspendable to save some memory? or just in Samourai wallets?


 

[NotATether]

1- Non-Btc uses of UTXOS
~
However, the point they're stored and counted in the set that constitute the system status, or not?

What do you mean by system status?

It's stated some where in the paper that Bitcoin core defines dust value limit ( the curve marked "dust" in their figs), but does this means it's not stored from the beginning?

If I understand correctly, the dust limit is 546 satoshis so transactions lower than that won't even get relayed across nodes let alone stored.

-One more question, does this means any user can mark an UTXO as Unspendable to save some memory? or just in Samourai wallets?

This works for wallets clients that use Bitcoin Core as their data source since Core is the one that saves on memory by not storing the UTXOs, and not the wallet client itself. This also works for wallets that don't deal in UTXOs at all (such as Electrum).

[ranochigo]

I've never looked into that part of the mailing list, can't say anything about that. OP_return are the only outputs that aren't included in the UTXO set.

It's stated some where in the paper that Bitcoin core defines dust value limit ( the curve marked "dust" in their figs), but does this means it's not stored from the beginning?

The dust limit serves as a threshold for the transaction to be considered non-standard, and thus invalid to be relayed. You can of course still create those outputs, they just won't get relayed. You can spend them with no problems but as the paper references, it costs more to consolidate and spend them as the extra input occupies extra space.

-Because I remember in one of my questions to the Utreexo team they said the Bitcoin core does not store Unspendable TXOS, at that time I thought they meant whatever appears in OP_Return, now I wonder r those mentioned above included too?
.

They aren't. Core doesn't exclude dust outputs from the UTXO set.

-One more question, does this means any user can mark an UTXO as Unspendable to save some memory? or just in Samourai wallets?

They cannot, and should not. Excluding any valid UTXO from your client's UTXO set will result in your client not accepting a block if the UTXO happens to be spent in that block. The missing UTXO will make Bitcoin Core invalidate the entire block. You don't mark UTXOs as unspendable, you "freeze" them to ensure they're left alone and never spent in the transactions that you're making. If it were to be spent in the transaction, the linkage will compromise your privacy. They are a cheap way to exploit the privacy.

If I understand correctly, the dust limit is 546 satoshis so transactions lower than that won't even get relayed across nodes let alone stored.

Depends on the type of script it is locked to. Differs between Segwit and Legacy.

[Shymaa-Arafat]

-They say the Bitcoin system Status is defined by the set of all stored UTXOS
»So the non-Btc uses r still ambiguous.
.
-What I understand from both replies that Bitcoin core doesn't allow transactions with total fee/cost less than dust value, but does NOT prevent u from creating dust UTXOS so they will be ( I mean still) stored burdening the system status (because the owner won't spend them) as the paper says.
-Or is the other way round, and Bitcoin core exclude UTXOS with value less than Threshold?

»»»
(This is again about my research proposal of classifying UTXOS into types, I just find it hard to believe no one did it before & no one is even convinced to do it; here I mean dust like burned not likely to be spent in the near future, why not accumulate their hashes separately?)

- For the mark "Unspendable" maybe the Samourai wallet was doing that in purpose, I mean preventing them from being included in any valid block as they know they're part of a hack?
(I'm just concluding from the article, I don't know for sure)

-About "Freezing" I found that there r 2 ways
1-remove the UTXO burden thru OP_Return from here
https://gist.github.com/dcod3d/90fe6209a0b3ae815a6eaa2aef53524c
https://gist.github.com/sorce/c60dfaac06d19842edfd5b7e2804ddc5
2-Freeze that's discussed in detail ( with the destroy link above) in this thread
https://bitcointalk.org/index.php?topic=5175238.60
https://bitcointalk.org/index.php?topic=5175238.40
3- The "Do NOT Spend" option in the Samourai wallet is probably the same as freeze because they're both reversible, unlike the destroy
https://blog.samouraiwallet.com/post/167306611667/wallet-update-097-coin-control-dust-tx-alerts

Thanks all, it all asserts my point of view; however, I still have to check how the lightning networks handle it since the original authors r doing a lot of research on them (they ended their paper by suggesting to store dust UTXOS separately, so adding more groups for burned, coinbase,...etc would follow naturally from their work)

[NotATether]

-What I understand from both replies that Bitcoin core doesn't allow transactions with total fee/cost less than dust value, but does NOT prevent u from creating dust UTXOS so they will be ( I mean still) stored burdening the system status (because the owner won't spend them) as the paper says.
-Or is the other way round, and Bitcoin core exclude UTXOS with value less than Threshold?

Bitcoin core doesn't exclude any UTXOs, not even dusts, from its UTXO set (as ranochigo already wrote), you can see this for yourself in https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L383-L423 (the function which pulls UTXOs from the mempool and validates them, CCoinsViewCache variables being the representation of a UTXO set).

3- The "Do NOT Spend" option in the Samourai wallet is probably the same as freeze because they're both reversible, unlike the destroy
https://blog.samouraiwallet.com/post/167306611667/wallet-update-097-coin-control-dust-tx-alerts

The bitcoin network doesn't have a feature to "permafrost" coins, except for some unusual circumstances such as sending your bitcoin to the genesis block or to a random "black hole" address nobody has the private keys for.

[Shymaa-Arafat]

I think this could be an example of key rotation non-Btc transfer, although not stated explicitly it works this way
https://support.keys.casa/hc/en-us/articles/360045043572-Key-Rotation
https://support.keys.casa/hc/en-us/articles/360045470891-UTXO-Management
Also described here
https://mobile.twitter.com/williamgrahamiv/status/1249805072135061506

[buwaytress]

A former Counterparty user here, and they got their cryptocurrency started by creating "burn" addresses in Bitcoin (addresses that couldn't spend the utxos, making them unspendable). The idea was, to back Counterparty, you'd need to destroy Bitcoin, so they hoped to reduce speculation driven backing -- that's another story but this was a use case I remember. Their burn address still gets some BTC! 1CounterpartyXXXXXXXXXXXXXXXUWLpVr over 2.1k BTC and counting.

[Shymaa-Arafat]

I'm aware of this specific example,
What I understand, The UTXOS in this address r not destroyed they r still there burdening the system state
https://blockchair.com/bitcoin/address/1CounterpartyXXXXXXXXXXXXXXXUWLpVr

This is one of the cases I'm counting where recognizing the UTXO type & store, hash accordingly in a separate data structure will significantly improve performance ( I claim)

[HCP]

This is one of the cases I'm counting where recognizing the UTXO type & store, hash accordingly in a separate data structure will significantly improve performance ( I claim)

The issue would be that you would absolutely require that the UTXOs are "provably unspendable"... as far as I'm aware, the only way to do this is using OP_RETURN.

While a "burn address" might not have the private keys available today and while it's highly improbable that the private keys could be found, it's technically not impossible that someone that could actually have those keys.

So, if you setup a system that excludes all these UTXOs in the name of performance... and tomorrow someone fronts up with the private key, you've basically broken the system and they'd be unable to spend them. Or would your proposed system still be able to hand this?

[ranochigo]

-What I understand from both replies that Bitcoin core doesn't allow transactions with total fee/cost less than dust value, but does NOT prevent u from creating dust UTXOS so they will be ( I mean still) stored burdening the system status (because the owner won't spend them) as the paper says.

You can't create and push a transaction that contains a dust output with Bitcoin Core. It's just that they're nonstandard and including it in a block almost always involves the participation of a miner.

(This is again about my research proposal of classifying UTXOS into types, I just find it hard to believe no one did it before & no one is even convinced to do it; here I mean dust like burned not likely to be spent in the near future, why not accumulate their hashes separately?)

Dust are sometimes in fact spent by the user to get rid of them from their wallet so they won't spend it inadvertently down the line. You need to keep them in an index in case they get spent for whatever reason. Most of the time, it's spent to an OP_return, whenever it doesn't cost more to spend it.

I don't think it is necessarily a bad idea to exclude them. I'd imagine the actual resource savings would be very low though.  You might have to spend more time validating blocks if they ever get spent; you can't get them from the UTXO set directly.

- For the mark "Unspendable" maybe the Samourai wallet was doing that in purpose, I mean preventing them from being included in any valid block as they know they're part of a hack?
(I'm just concluding from the article, I don't know for sure)

You can't prevent UTXOs from being spent, unless you're the only person that can spend it. It is intentionally marked that way to prevent it from compromising the privacy of their user.

[Shymaa-Arafat]

I don't think it is necessarily a bad idea to exclude them. I'd imagine the actual resource savings would be very low though.  

The significant saving I claim is in the proof sizes, by accumulating their Hashes in separate Merkle Tree ( I mean for Stateless nodes, this way the main Merkle for regular kind will have less path length & consequently proof sizes for all of them; in other words instead of Utreexo forest of alike trees just order I'm having a forest with different trees for different UTXOS types in abstract sense the trees data structure itself could be different to suit the Lifespan/behavior of each UTXO type)
»»» If they got spent, their proofs will be even much smaller (in av. log their no. + no of other roots)

The mentioned paper states that by I think mid 2018 a significant number of UTXOS is considered dust.
https://royalsocietypublishing.org/doi/10.1098/rsos.180817
Probably things have changed since then more attention brought to the problem
However we know 420*10³ out of 76*10⁶ ~0.55% r non standard outputs by new statistics
https://txstats.com/dashboard/db/non-standard-outputs-statistics?
(I admit I haven't read enough yet about non-standard UTXOS, I'm just taking ur word for now they're dust & non-Btc uses)
Similarly burned UTXOs 1 published addresse contain alone 0.177%, ...and more other
kinds

Note that it is nothing more than a few if statements & every proof would be expected to improve by the burden reduction. Caches could execlude them too, dust sending addresses could be marked suspecious in the way to trace origins of possible dust attacks,... etc

[Shymaa-Arafat]

I've never looked into that part of the mailing list, can't say anything about that. OP_return are the only outputs that aren't included in the UTXO set.

I think this lecture explains in detail those "non standard" UTXOS uses
https://youtu.be/CCeq5PChvuk
It talks in detail about Catena and how they do it without keeping unnecessary UTXOS in Bitcoin as compared to 2 other companies, he says they write msgs in place of UTXO value and like burn sign with a random value of public key (no corresponding private key), while Catena signs the msgs with their public key so their TXs is like sending the same UTXO back& forth to themselves
Blockstack
https://www.investopedia.com/terms/b/blockstack.asp
https://www.coindesk.com/company/blockstack

& KeyBase
https://keybase.io/
https://techcrunch.com/2020/05/07/zoom-acquires-keybase-to-get-end-to-end-encryption-expertise/?guccounter=1&guce_referrer=aHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS8&guce_referrer_sig=AQAAAMLzsAYotgrbPm8HkQVequM5OFQETe9wrlVDJsZfvmEqs3ly63a61aDqKZA3HIlPF4T9nareGqsG-lr6D56utNzJPAgALi0cEk_yfnny_lNTBvo45SFIR0hPgTaBaecdIfn4L4GsDgXdD6z2pZ2ierJwlvvORN1aK6-VzioaAZdW
https://en.m.wikipedia.org/wiki/Keybase

However, I only find rare trace of actual activities of the 3 since 2019/2020 at max, even Catena twitter is not active
https://mobile.twitter.com/catenacapital/with_replies?lang=en
.

(I didn't read the article about KeyBase being used in Zoom yet to see if it's still working and with the UTXOS use)