Milestone 1.6: Receive - specs & progress

[GBKS]

This is a tracker/discssion issue for the 1.6 milestone (design docs).

Goal is to add payment request generation and management, including addresses and payment request history.

Requirements:

• Receive form screen
  • Amount
  • Label
  • Message
  • Address type
• Payment request history screen
• Payment request details screen
  • Address
  • QR code
  • Amount, label, message
  • Prior transactions with this address (address reuse warning?)
  • Share & copy options
• Addresses screen

Future additions:

• Silent payments
• Tags

User flow consideration: Most bitcoin wallets directly show an address and QR code when entering the receive screen. The Qt application uses a more explicit approach:

• Show a form for payment details
• The user confirms the form input (even if all fields are empty)
• Only then show an address (as part of the payment request)

This creates payment request (aka invoices) objects in the UI, and indirectly asks users to be more intentional with their address generation. We decided to keep this more explicit flow.

A resulting design decision is about what happens if a payment request is fulfilled by an incoming transaction. Do those two object now merge in the UI (like stapling an invoice and a payment confirmation together IRL)? A follow-up design decision is then whether to show payment requests in the activity screen rather than a separate screen.

Considerations:

• The app can be built without QR code support (docs)

[rabbitholiness]

Started a Figma file here: https://www.figma.com/design/NrJQuNwAHN9KwBsrAqU7Q7/Bitcoin-Core-App-Design-(Michael)?node-id=9017-6161&t=A1ar6k7SFxBeqoXS-1

It includes:

• MVP scope
• Clickable prototype
• Concepts for silent payments & tags (potential future scope)

[GBKS]

The design docs for receiving were just updated via this PR.