feat(legacy-stats): broadcast swap status for privacy coins#2648
feat(legacy-stats): broadcast swap status for privacy coins#2648
Conversation
|
@mariocynicys can you change the target branch to staging? |
after hiding identifying info from it
each is hidden from the other parties side these values also exist in the negotation messages but they seem to be mostly set to zeros (added a fixme for discussing that)
52624ea to
3aa7aad
Compare
the other party will send their status anyway to the stats node, and their pubkey will be present in `my_persistent_pub` if they every choose to include it
aside from the taker and maker gui and version, we now also grap the maker pubkey from the maker and the taker pubkey from the taker. (i.e. we won't rely on the taker to get the maker's pubkey). on the downside, if the maker has a modded kdf that doesn't send the status, then we won't get the maker's pubkey (which is their right anyway)
d253b57 to
22c4652
Compare
|
@smk762 could u test if u get consistent pubkeys in this one? (the pubkeys that will be stored are the |
this migration replaces the htlc pubkeys with persistent pubkeys with the help of swap jsons. if a specific swap json can not be found, no action is performed and the pubkey stays as is (might be right or might be wrong)
this changes the migration system to use parameters of type SqlValue instead of plain Strings
|
Tested a swap local kdf (as maker) and seednode running this version. **On seednode: **
On local maker KDF:
|
|
@smk762 the thing is, for privacy coins, the persistent pubkey for the party who is running the privacy coin will not be disclosed (will be set to zeros), for their privacy. the taker's persistent pubkey here also wasn't set (was NULL) because it seems that the taker didn't send their status (could you please confirm by checking whether If the taker json exists, then could u please post the logs of this stats node. edit:
if you mean here that the taker is running an old version, then this taker defiantly didn't send the swap status. because before this PR, if one of the coins in the swap (the maker here using ARRR) is a privacy coin, we don't send any status for stats. |
|
Confirmed taker was on older version of KDF. I'll setup a pair on the latest commit of this branch for confirmation testing, and post here once complete. |
|
Under maker/taker, there appears to be a different value for UUID: seednode
MAKER:
TAKER:
|
|
@smk762 yup that's the expected behavior. let's not regard the info saved in stats jsons and stats DB is masked as expected (for privacy coins, persistent pubkeys shouldn't be leaked). If you wanna test that persistent pubkeys are stored correctly for both taker and maker (in stats DB), then u gotta use two non-privacy coins in the swap so u can view both persistent pubkeys. the stats this PR provide for the privacy coins exclude the persistent pubkey for the party using the privacy coin, since that defeats the anonymity aspect of using the privacy coin. |
dunno if recreate_taker_swap even works due to this, but also my_persistent_pub might not be that useful after all for the party who is receiving the recreated swap since they already have hold of that public key already
shamardy
left a comment
There was a problem hiding this comment.
Thanks a lot for the fix!
…staging-to-dev chore(release): propagate #2648 (staging→dev)
This PR now includes a DB migration. Backup your DB before testing!
This PR allows broadcasting the swap status for privacy coins after hiding the identifying information from it (namely:
my_persistent_pub).We also decided to clear out
MakerSwapData.taker_pubkeyandTakerSwapData.maker_pubkeyso not to reveal the other side's persistent pubkey. They can reveal it themselves when they want.This PR also correct the stats db index pubkeys, where in the past we used to store one persistent pubkey for side X and htlc pubkey for side Y, but now we store persistent pubkey for side X and also the persistent pubkey for side Y. (X & Y here being the maker or taker interchangeably. such a behaviour mainly depended on who's status messages reached the stats node first)