512 sats \ 3 replies \ @ek 27 Feb \ parent \ on: Have you connected an external wallet on SN? meta
Mhh, I think we are talking past each other. Are you talking about LUD-14 and maybe LUD-15 when you say "persistent withdrawal links"?
write
preview
1332 sats \ 2 replies \ @justin_shocknet 27 Feb
Nope, none of that extra stuff is needed,.. straight LUD-03 which you have already is fine.
The balance you see in my screenshot comes from the maxWithdrawable tag in the response, literally the only thing in the way is the timeout of the k1. Fixing this obviates your AUTO-WITHDRAW efforts with the existing neutral spec.
Conversely, LUD-19 could be used for "AUTO-FUND" too if desired, but that's redundant to the user just adding their "stackerwallet" lightning address as a source
reply
659 sats \ 1 reply \ @ek 27 Feb
Mhh, I see now what you are talking about, thanks!
I was confused since LUD-03 mentions that k1 should be ephemeral:
Note that service will withdraw funds to anyone who can provide a valid ephemeral k1.
So aren't "persistent withdrawals links" non-standard behavior? All the other sources in your screenshot, do they accept the same k1 over and over again?
Also, can you elaborate on this part:
so they aren't accidentally sniped
What do you mean with "sniped"?
reply
2205 sats \ 0 replies \ @justin_shocknet 27 Feb
We haven't run into any other expiring K1's yet
Per the spec "k1": string, // Random or non-random string, so it's not opinionated either way
On the subject of sniping, that foot note on the spec is related and @k00b actually mentioned this before too...
When you go to the stacker wallet and click on QR Code, the QR just displays on your screen and contains the k1... any cameras behind you could potentially sweep funds before you do.
The expiring of the k1 is a mitigation for a camera behind you doing a replay attack later.
2 simple ways to fix both problems:
One is to instead of the QR code, provide the LNURL as a clickable link so that only the designated protocol handler can see the k1 parameter.
The other is to keep the QR code, but blur it out and make the user click off a warning to be sure they have privacy first, this would mitigate the existing sniping vulnerability.
Personally I think both would be good.
The flow in ShockWallet, when it gets an LUD03, is it asks the user if they want to sweep the balance... or add it as a source so they can subject it to continued automation in accordance with their trust preferences and budgeting rules.
reply