Make Domain mutable after disableMasterKey

[savetoken5]

I updated my Domain after I had disableMasterKey, Now I cannot change the Domain. and XRPL will reference the old Domain for the toml. Even after updating the domain in the toml , it does not reflect on chain because it must be AccountSet. I cannot see any reason this should be permanently locked when blackholed and request that it is allowed to be changed. Thanks for your consideration.

[mvadari]

The point of disabling the master key is that you can no longer do anything on-chain with your master keypair. Allowing the domain to still be updated defeats the purpose.

[savetoken5]

Thanks for the reply. Could you please elaborate how separating the domain from the master key defeats the purpose of preventing the minting of more tokens, clawback, trustline permissions, etc. The domain cannot adversely affected a token holder or illicitly benefit the issuer. I get the idea of locking down all the other things, but I cannot see the harm in allowing the update of the domain. Is it better to have outdated data on chain? Or was it deemed that a domain change should result in a new token issued? Seems crazy to me but I don’t make the rules. Your reasoning would be very appreciated. Related consideration. Sologenic accidentally lets their donation lapse (yes unlikely). Then say someone else buys it and blackmails them for ownership. Seems counter productive to a healthy ecosystem. my2cent.

…

On Thu, Jun 27, 2024 at 2:39 PM Mayukha Vadari ***@***.***> wrote: The point of disabling the master key is that you can no longer do anything on-chain with your master keypair. Allowing the domain to still be updated defeats the purpose. — Reply to this email directly, view it on GitHub <#5051 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BGOOGIFZXRIAEBWRYFII2H3ZJRL43AVCNFSM6AAAAABJU7XGZGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TQOJXGU3DS> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[mvadari]

The norm for blackholing may be to avoid issuing more tokens, but that doesn't mean that's all it is used for. It is intended to be to throw away all access to an account. That should be something that has no exceptions, because exceptions a) mean the chance for bugs are higher and b) make it easier to consider further loosening of restrictions down the line (what if you also want to change the tick size? etc.) All of a sudden blackholing doesn't really mean blackholing.

Personally, I would prefer an approach more akin to XLS-49d that allows you to assign another keypair to change the domain.

[savetoken5]

Thanks for the clarification. Understood. You see a mutable domain a being as bad as the ability to claw back and then it also open the door for people to argue for tick size, etc. Unfortunately assigning another key pair will not help someone who issued a token already and did the “right thing” and black holed it. Not feeling like the right thing anymore. Regardless, thanks for sharing your view. I appreciate it.

…

On Thu, Jun 27, 2024 at 4:43 PM Mayukha Vadari ***@***.***> wrote: The norm for blackholing may be to avoid issuing more tokens, but that doesn't mean that's all it is used for. It is intended to be to throw away all access to an account. That should be something that has no exceptions, because exceptions a) mean the chance for bugs are higher and b) make it easier to consider further loosening of restrictions down the line (what if you also want to change the tick size? etc.) All of a sudden blackholing doesn't really mean blackholing. Personally, I would prefer an approach more akin to XLS-49d <XRPLF/XRPL-Standards#144> that allows you to assign another keypair to change the domain. — Reply to this email directly, view it on GitHub <#5051 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BGOOGIFFR5TUV2EDAV7FEVDZJR2NLAVCNFSM6AAAAABJU7XGZGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TQOJYGM3TO> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[savetoken5]

My recommendation is to have xrplmeta.org update toml data more often and direct projects to use their data. For instance, I added all the correct data to the .../well-known/xrp-ledger.toml on the old domain and the new domain both pointing to the new domain.The toml file standard includes the field DOMAIN. One update could move the site. Might be prudent to make it requests driven for censorship. Is it actually necessary for the domain to be on-chain? The same could be said about the email. They're both descriptive language not token functionality. As is, it does not seem future proof for many project. Trust me. Having the wrong domain on every DEX is a real headache. Thanks to those who consider this proposal.

…

On Thu, Jun 27, 2024 at 4:55 PM SAVE ***@***.***> wrote: Thanks for the clarification. Understood. You see a mutable domain a being as bad as the ability to claw back and then it also open the door for people to argue for tick size, etc. Unfortunately assigning another key pair will not help someone who issued a token already and did the “right thing” and black holed it. Not feeling like the right thing anymore. Regardless, thanks for sharing your view. I appreciate it. On Thu, Jun 27, 2024 at 4:43 PM Mayukha Vadari ***@***.***> wrote: > The norm for blackholing may be to avoid issuing more tokens, but that > doesn't mean that's all it is used for. It is intended to be to throw away > all access to an account. That should be something that has no exceptions, > because exceptions a) mean the chance for bugs are higher and b) make it > easier to consider further loosening of restrictions down the line (what if > you also want to change the tick size? etc.) All of a sudden blackholing > doesn't really mean blackholing. > > Personally, I would prefer an approach more akin to XLS-49d > <XRPLF/XRPL-Standards#144> that allows > you to assign another keypair to change the domain. > > — > Reply to this email directly, view it on GitHub > <#5051 (reply in thread)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/BGOOGIFFR5TUV2EDAV7FEVDZJR2NLAVCNFSM6AAAAABJU7XGZGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TQOJYGM3TO> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

[MarkusTeufelberger]

disableMasterKey is not really intended to blackhole accounts, it can be (ab-?)used that way of course. If a master key gets compromised and disabled in response, then it should not be possible to change anything on that account any more using that key.

[mvadari]

Here's one proposal to address this issue from a different angle: XRPLF/XRPL-Standards#218