Extended the message signing and verification with on chain addresses

[cherry-1729-9090]

Description

Project : Extended signing & verification of messages with on chain addresses

This PR implements on-chain address message signing and verification in the ZEUS wallet, extending the existing Lightning node pubkey functionality. Users can now sign and verify messages using their on-chain address keys, which provides additional verification capabilities for use cases where Bitcoin address ownership needs to be proven.

Issue : #2922

Implementation Details

• Extended UI to allow users to select between Lightning node pubkey and on-chain address key for signing
• Added Address Picker interface similar to one while checking the on chain addresses, for selecting specific on-chain addresses for signing
• Integrated with backend support for address-based message signing via the supportsAddressMessageSigning() capability flag
• Important: Added conditional rendering of UI components based on backend capabilities:
  • When a backend doesn't support address signing (like CLN Rest), only Lightning node options are shown
  • When a backend supports address signing (like LND, LNC), both Lightning and on-chain options are available
• Enhanced contrast in the Signing Type tabs for better visibility (fixed gold on white contrast issues)
• Added comprehensive error handling for unsupported implementations

Demo Videos

I've created several demonstration videos showing the implementation working with different types of nodes:

• Zeus extended on chain signing demo

The demos show how the UI adapts to different backend implementations.

Technical Implementation Notes

• Core Lightning (CLN Rest) doesn't currently support signing with on-chain addresses, so I've implemented the supportsAddressMessageSigning() capability flag that returns false for CLN Rest
• For backends that support on-chain address signing (LND, LNC), the flag returns true
• The UI components in SignVerifyMessage.tsx check this flag and conditionally render the appropriate options
• This implementation ensures proper backward compatibility

This pull request is categorized as a:

• [x] New feature
• [ ] Bug fix
• [ ] Code refactor
• [ ] Configuration change
• [ ] Locales update
• [ ] Quality assurance
• [ ] Other

Checklist

• [x] I've run yarn run tsc and made sure my code compiles correctly
• [x] I've run yarn run lint and made sure my code didn't contain any problematic patterns
• [x] I've run yarn run prettier and made sure my code is formatted correctly
• [x] I've run yarn run test and made sure all of the tests pass

Testing

If you modified or added a utility file, did you add new unit tests?

• [ ] No, I'm a fool
• [ ] Yes
• [x] N/A

I have tested this PR on the following platforms (please specify OS version and phone model/VM):

• [x] Android (Android 13, Pixel 4)
• [ ] iOS

I have tested this PR with the following types of nodes (please specify node version and API version where appropriate):

• [x] Embedded LND
• [x] LND (REST)
• [x] LND (Lightning Node Connect)
• [x] Core Lightning (CLNRest)
• [ ] Nostr Wallet Connect
• [ ] LndHub

Locales

• [ ] I've added new locale text that requires translations (for UI labels)
• [ ] I'm aware that new translations should be made on the ZEUS Transfix page and not directly to this repo

Third Party Dependencies and Packages

• [ ] Contributors will need to run yarn after this PR is merged in
• [ ] 3rd party dependencies have been modified:
  • verify that package.json and yarn.lock have been properly updated
  • verify that dependencies are installed for both iOS and Android platforms

Other:

• [ ] Changes were made that require an update to the README
• [ ] Changes were made that require an update to onboarding

[kaloudis]

Looks pretty good on first glance. Notes:

• LND REST and Lightning Node Connect backends need to be wired up for this too. Be sure to wire these up and test with https://lightningpolar.com/
• We need to see if CLNRest has a comparable endpoint, otherwise we need to add another flag in BackendUtils to mark the functionality to complement the base supportsMessageSigning - perhaps supportsAddressMessageSigning
• On the Verify: Signing Type tabs: change the text color the the theme's text color when highlight: the contrast between the gold and white is very poor
• Fix your PR description and ensure you get all your tests passing

[cherry-1729-9090]

Old UI :

The new UI for both Sign and Verify Pages to those implementations which support signMessageWithAddr and verifyMessageWithAddr (LND, LNC & Embedded LND)

And for the CLN Rest as there are no endpoints that supports message signing with on chain addresses, they can see the old screens.

[kaloudis]

I don't think we need the address type itself in the dropdown.

I also wonder if it would maybe have a second view to select the address on. Perhaps we can leverage the existing Coins view and create a selection mode of sorts for it

[cherry-1729-9090]

@kaloudis, thanks for your feedback! I'll remove the address type from the dropdown as suggested.

Regarding your idea for a separate view for address selection—similar to the Coins view—could you share more about the specific UX benefits you have in mind? Is it because users might have many addresses to select from, and we need to show more details for each address? I'd love to hear more about your thought process.

[kaloudis]

@kaloudis, thanks for your feedback! I'll remove the address type from the dropdown as suggested.

Regarding your idea for a separate view for address selection—similar to the Coins view—could you share more about the specific UX benefits you have in mind? Is it because users might have many addresses to select from, and we need to show more details for each address? I'd love to hear more about your thought process before making any larger UI changes.

Coins view allows users to navigate address types more easily due to the address type collapsible sections, and also allows users to identify addresses thanks the amounts being listed

[cherry-1729-9090]

https://github.com/user-attachments/assets/d0b8d655-cf7e-47d4-a7cf-b48435aade7a

@kaloudis , please take a look at this flow, I made a separate component for Address selection.

[kaloudis]

It's getting there.

Perhaps we should add sort and search functionality to the address picker.

I think it would also be an improvement to move the loading indicator into the top right corner on the sign view

[kaloudis]

needs rebase and cleaned up commit structure

[cherry-1729-9090]

@kaloudis @shubhamkmr04

I've attached a video demonstration of the search and filter operations in the address picker as you suggested: https://drive.google.com/file/d/1KalGPpuWzJxytW4ABvjnY2X1te0wN5tt/view?usp=sharing

I've successfully rebased my branch as requested to remove the merge commit. During the rebase process, I noticed some commits from master (not authored by me) also appeared in my PR history. Please let me know if you'd prefer a different approach to the commit history, or if anything else needs adjustment.

Thank you for your guidance!

[kaloudis]

@cherry-1729-9090 you need to learn how to rebase. Other people's commits should not appear in your PR structure.

[cherry-1729-9090]

@kaloudis, I've now properly rebased and squashed my changes into a clean commit structure. The PR now contains only my 3 commits related to the message signing feature. I had been working on cleaning up the commits when you commented, and I've completed that process now. Can you please review my PR now and suggest me any necessary changes that I can improve on ? Thanks !

[kaloudis]

The loading icon position on the page looks weird. I would potentially move it into the right corner of the header of the page

[kaloudis]

The search bar for the address picker is a bit squished. I would give it some higher margins to it has more room.

[shubhamkmr04]

@cherry-1729-9090 solve the conflicts

[cherry-1729-9090]

@shubhamkmr04 @kaloudis

Thanks for the feedback and guidance !

I have resolved the conflicts and now the branch and PR is clean. Here is the demo of AddressPicker after making the enhancements

https://drive.google.com/file/d/1Y_Ir75K0BClmDw2gv2ys_hP8Kv7KVdy6/view?usp=sharing

[kaloudis]

Looking pretty good now. Is it possible on the verification success message to have the on-chain address returned? I think we might want the pubkey converted to hex at the very least

[cherry-1729-9090]

@kaloudis Thanks for the feedback !, I've seen how the different backend implementations handle pubkey formats for on-chain address signature verification. I'll implement the changes to show the verified address in the success message along with the pubkey to be displayed in hex format. Users can already copy the address from the 'Full Address' section which has a dedicated copy button.

Regarding the UI, I few thoughts for improving the user experience:

• For the pubkey, we could add a dedicated copy button next to it in the success message
• Alternatively, we could add a toggle to switch between original and hex formats if that would be useful

I've attached a screenshot of the UI. Please provide your suggestion for the pubkey display/copying functionality.

[kaloudis]

@kaloudis Thanks for the feedback !, I've seen how the different backend implementations handle pubkey formats for on-chain address signature verification. I'll implement the changes to show the verified address in the success message along with the pubkey to be displayed in hex format. Users can already copy the address from the 'Full Address' section which has a dedicated copy button.

Regarding the UI, I few thoughts for improving the user experience:

* For the pubkey, we could add a dedicated copy button next to it in the success message

* Alternatively, we could add a toggle to switch between original and hex formats if that would be useful

I've attached a screenshot of the UI. Please provide your suggestion for the pubkey display/copying functionality.

If we can get address associated to display correctly, we don't need to also include the pubkey. Make sure it displays correctly across all address types too.

[shubhamkmr04]

@cherry-1729-9090 we should remove the search bar while its loading

[shubhamkmr04]

https://github.com/user-attachments/assets/cda624c3-faa6-483a-b94b-8ff9b56290be

clear button is removing the on-chain field as well until we refresh the app

[shubhamkmr04]

let's change the background of generated signature

@cherry-1729-9090

[cherry-1729-9090]

let's change the background of generated signature

@cherry-1729-9090

@shubhamkmr04 After the previous review I have changed the background color to secondary theme color. Could you please let me know if you're looking for a different color or additional styling changes?

[cherry-1729-9090]

@shubhamkmr04 Can you please check whether this is the expected UI for selected address ?

[shubhamkmr04]

@cherry-1729-9090 don't make the highlighted text bold

[kaloudis]

@cherry-1729-9090 a rebase is required

[kaloudis]

Sorting labels appear to break here. At least on iOS

[kaloudis]

Have you tested this against the Embedded node? I'm hitting this:

[kaloudis]

The public key here is displaying incorrectly, at least on iOS:

[kaloudis]

When verifying address messages, often times the address you're verifying for won't be your own. This should just be a standard text field here.

[shubhamkmr04]

When verifying address messages, often times the address you're verifying for won't be your own. This should just be a standard text field here.

What if we give user both the options ? text field and a option to select an address from Address picker. cc @kaloudis