Developer Wietse Wind clarified the point with simple «flag».
Developer Wietse Wind on twitter clarified the point with simple «flag». He noted:
An explainer on the recent finding that a simple ‘flag’ (setting) on minted NFT’s can be abused, causing NFT issuers to get all their XRP locked up due to actions of third parties.
Because of this finding, I have removed the “yay” vote of the @XRPLLabs validator. Temporarily.
He also added:
So: this is about the ‘lsfTrustLine’ flag. It allows NFT issuers (minters) to accept issued currencies (IOU’s, tokens) for NFT’s with a < transfer fee >. This means that the issuer (minter) of an NFT would be payed a percentage when the NFT is traded.
A percentage of whatever asset is used to trade the NFT. Now imagine a minted NFT is sent/sold to John Doe, and John Doe sells it for WietseCoin (issued token) to someone else. The original minter receives a percentage of WietseCoin.
But: the XRP Ledger requires the minter to have a Trust Line for that. A Trust Line for “WietseCoin”. And it’s great that the XRPL requires that Trust Line, because it means you cannot be spammed with a coin you did not want to receive in the first place: hence <TRUST> Line.
This is where the ‘lsfTrustLine’ flag comes in. If the flag is set on an NFT, as per XLS20 spec, the TL would be automatically created for the NFT issuer. However: the sale may happen without the issuer being aware, and it would still lock up account reserve (2 XRP).
This can be abused. A once minted and sent/sold NFT with the lsfTrustLine + Transfer Fee could then be sold back and forth between two or more accounts from an attacker, causing more and more Trust Lines to be created for random shitcoins issued by the attacker.
This goes against the idea that a Trust Line should never be created without explicit consent to < Trust > the issuer and asset. Even a Check cashed or DEX trade made resulting in a TL, is an action < you yourself execute > on your account. With lsfTrustLine this isn’t the case.
The community owes@xTokenize a big fat thank you for finding this & reporting this. Now: what does this mean? It means support for the < current implementation > of XLS20 may lose majority. I hope it will, because I feel this issue needs addressing (the flag must go, imo).
If XLS20 (the ‘NonFungibleTokensV1_1’ amendment) loses >80% Yay votes, it will not activate ~one day from now. A shame for all eagerly waiting for XLS20 to go live, but letting it go live would be a bigger shame if it results in issuers (minters) get affected down the road.
So now what should happen? 1. Fix 2. All relevant operators: update to a new Rippled version containing the fixed NFT amendment 3. Test & vote again, for the fixed version of the amendment 4. Get majority (>80%): 2 week amendment go live counter restarts
This is obviously not something to rush. But unlike previous times, it’s now well established that XLS20 had >80% support. I am confident a fixed version of XLS20 will quickly gain support again. This is not “XLS20 Goodbye”: this is “XLS20 See you later”.