LNURL: Atomic lightning address transfer#829
Conversation
JssDWt
left a comment
JssDWt
left a comment
There was a problem hiding this comment.
Yep that will work! I like how both parties agree on the transfer this way.
| _ => return Err(LnurlRepositoryError::SourceNotOwner), | ||
| } | ||
|
|
||
| sqlx::query("DELETE FROM users WHERE domain = $1 AND pubkey = $2") |
There was a problem hiding this comment.
DELETE has a RETURNING option. We could do RETURNING name, use that as the source_name, and error if source not owner. It will work because the tx is not committed then.
|
|
||
| The flow has two steps, run on two different SDKs: | ||
|
|
||
| **Step 1 — current owner (pubkey A):** produce a transfer authorization by signing a fixed message of the form `transfer:{pubkey_a}-{username}-{pubkey_b}`. Use {{#name sign_message}} on the SDK that currently owns the username. `pubkey_b` is the {{#name identity_pubkey}} of the receiving pubkey (available via {{#name get_info}}). The `username` must be the sanitized (lowercased and trimmed) form. |
There was a problem hiding this comment.
Should we add an sdk function accept_lightning_address_transfer, returning the needed info for the transfer field? This is not the worst DX, but not the best either.
|
|
||
| {{#tabs lightning_address:get-lightning-address}} | ||
|
|
||
| ### Transferring a Lightning address |
There was a problem hiding this comment.
I think it's worth a note that your existing payments are not transferred to the new owner. Only the address.
dangeross
force-pushed
the
savage-lnurl-transfer
branch
from
2fa8bff to
45263f1
Compare
Isn't it an SSP error? |
Ah yes it is |
dangeross
force-pushed
the
savage-lnurl-transfer
branch
from
45263f1 to
0c01658
Compare
dangeross
force-pushed
the
savage-lnurl-transfer
branch
from
0c01658 to
ea8eb1f
Compare
2 participants
Adds atomic Lightning address username transfer between pubkeys. A user can now hand a registered username from one pubkey to another in a single server-side transaction — closing the race window where today's delete-then-reregister flow could let a third party snipe the name.
How it works
accept_lightning_address_transferwith the new owner'sidentity_pubkey. The method returns aLightningAddressTransfercontainingpubkeyandsignature, which is the authorization that grants B the right to take over the username.register_lightning_addresswith the new optionaltransfer: Some({ pubkey, signature })field populated. The SDK routes to the server's newPOST /lnurlpay/{to_pubkey}/transferendpoint, which verifies both signatures and swaps ownership in one DB transaction (SELECT … FOR UPDATE→DELETEsource →INSERT … ON CONFLICT DO UPDATEtarget).