Transfer of a space to a sptr fails

[randomlogin]

I was trying to transfer spaces to sptrs and it doesn't work sometimes, instead it revokes a delegation.
More precisely, I have a name delegated to a sptr, then I transfer it to another sptr, then I transfer it back and on the last step the transfer doesn't work.

Steps to reproduce:

1. own a space
2. create a new sptr (which you own)
3. transfer the space to a new sptr
4. transfer the space back to the original sptr

Expected behaviour is that the space we've used has correct delegation to the original (which is equal to the last used) sptr.

List of steps:

1. Initial state

$ space-cli listspaces
✓ WINNING (1 spaces):
╭────────┬──────┬──────────┬────────────────╮
│ SPACE  │ BID  │ CLAIM AT │ DAYS LEFT      │
├────────┼──────┼──────────┼────────────────┤
│ @fifth │ 1000 │ 1729     │ Ready to claim │
╰────────┴──────┴──────────┴────────────────╯
🔑 OWNED (4 spaces): 
╭─────────┬───────────┬───────────┬────────────────────────────────────────────────────────────────────╮
│ SPACE   │ EXPIRE AT │ DAYS LEFT │ UTXO                                                               │
├─────────┼───────────┼───────────┼────────────────────────────────────────────────────────────────────┤
│ @second │ 54554     │ 364.97    │ 9796637756aea4518b1c8ec764e2cf8723f4fdc2165b3bea57f48d9cada89e94:1 │
├─────────┼───────────┼───────────┼────────────────────────────────────────────────────────────────────┤
│ @third  │ 54554     │ 364.97    │ 3dd6d4142cf5a3e4fa8b0b83bfffbb24f2413232fd4619a27222fbd01e59e72a:1 │
├─────────┼───────────┼───────────┼────────────────────────────────────────────────────────────────────┤
│ @fourth │ 54554     │ 364.97    │ 328aaaa0b9c1ab25bdaee4ee79b94333f489edf728252356d825da2ab0226edf:1 │
├─────────┼───────────┼───────────┼────────────────────────────────────────────────────────────────────┤
│ @first  │ 54559     │ 365.00    │ c67e892101806a74de104ca52a9e0fc287abae61563146a4ba6072bc2c9b0647:1 │
╰─────────┴───────────┴───────────┴────────────────────────────────────────────────────────────────────╯

2. Verify the sptr for the space "@second"

$ space-cli getdelegation @second
"sptr156e38rzvw9r769epp0mftp4404mnqlw5jjt8tml60gnjuj068skqxq3fdm"
$ space-cli getdelegator sptr156e38rzvw9r769epp0mftp4404mnqlw5jjt8tml60gnjuj068skqxq3fdm
"@second"

3. Create a new sptr (the used script_pubkey belongs to the wallet being used)

$ space-cli getnewspaceaddress
bcrts1p9mt2jd0m5cne8ed5r3a30qf80mq25vz3fdrlkqtvg4ktj78kamns75c4xj
$ space-cli createptr 51202ed6a935fba62793e5b41c7b1781277ec0aa30514b47fb016c456cb978f6eee7  --fee-rate 1
Creating sptr: sptr1zmpf6anfshkrdwna0qahceq5ds3jp5t9r0y8qq3yzl99tcjggznqqqmc03

4. The newly created sptr has no delegation

$ space-cli getdelegator sptr1zmpf6anfshkrdwna0qahceq5ds3jp5t9r0y8qq3yzl99tcjggznqqqmc03
null

5. We transfer "@second" to the generated sptr

$ space-cli transfer @second --to sptr1zmpf6anfshkrdwna0qahceq5ds3jp5t9r0y8qq3yzl99tcjggznqqqmc03 --fee-rate=1
✓ Transaction dbea50eb0a48c583baca4034b5329a487f1b4691f283d2bc989d97128ac72268
 - Renew @second

6. Verify it is correctly transferred

$ space-cli getdelegator sptr1zmpf6anfshkrdwna0qahceq5ds3jp5t9r0y8qq3yzl99tcjggznqqqmc03
"@second"
$ space-cli getdelegation @second
"sptr1zmpf6anfshkrdwna0qahceq5ds3jp5t9r0y8qq3yzl99tcjggznqqqmc03"

7. Transfer "@second" back

$ space-cli transfer @second --to sptr156e38rzvw9r769epp0mftp4404mnqlw5jjt8tml60gnjuj068skqxq3fdm --fee-rate=1
✓ Transaction 14255b63829d2124fc581509a8cb898e16f1c5acc68c92f70505604f5f85a30c
 - Renew @second

8. Observe the absence of delegation

$ space-cli getdelegation @second
null
$ space-cli getdelegator sptr156e38rzvw9r769epp0mftp4404mnqlw5jjt8tml60gnjuj068skqxq3fdm
null
$ space-cli getdelegator sptr1zmpf6anfshkrdwna0qahceq5ds3jp5t9r0y8qq3yzl99tcjggznqqqmc03
null

The delegation was simply revoked, a new one wasn't created.
If it is the intended behaviour, I'd suggest to forbid the user to make such a transfer, or at least to warn him.

Space pointers are supposed to be reusable, right (at least in theory)?

UPD: it is getting weirder after I made another transfer — it was transferred to a wrong sptr

$ space-cli transfer @second --to sptr156e38rzvw9r769epp0mftp4404mnqlw5jjt8tml60gnjuj068skqxq3fdm --fee-rate=1
✓ Transaction e6ec34b427fdfbd75ec1d1fb81cc6fc068cb60a45529ef726d3c3836518016da
 - Renew @second
$ space-cli getdelegation @second
"sptr1pyp2astz7fhn7kstz4nz6wsk4g0s53lynz7jjzy4c4s63lsr409qqh88m7"

And the getptrblockmeta has the following response, which feels not the way it should be:

                "revoked_delegations": [
                    {
                        "space": "@second",
                        "sptr": "sptr1pyp2astz7fhn7kstz4nz6wsk4g0s53lynz7jjzy4c4s63lsr409qqh88m7"
                    }
                ],
                "new_delegations": [
                    {
                        "space": "@second",
                        "sptr": "sptr1pyp2astz7fhn7kstz4nz6wsk4g0s53lynz7jjzy4c4s63lsr409qqh88m7"
                    }
                ],

[buffrr]

I think there's a misconception about how delegations and SPTRs work. An SPTR is just another handle. When you transfer to an SPTR, the wallet resolves it to its current address and sends there. Like any handle, an SPTR can move to other addresses.

Delegation is more specific. It only exists when a space's script_pubkey matches the genesis spk of some SPTR.

@second -> script_pubkey_a
That means @second is delegated to SPTR_A.

So this command:

space-cli transfer @second --to sptr156e38r...

...doesn't necessarily delegate @second to sptr156e38r.... It just transfers to wherever the SPTR currently is. If the SPTR moved to a different address, the delegation breaks.

To create a true delegation, transfer the space to the SPTR's genesis script_pubkey (the address where it was created).

BUT: transferring a space to a different SPTR then transferring it back to the old SPTR should still work if and only if the old sptr still lives at the genesis spk and hasn't moved since. So can you confirm this is an issue?