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.

[GBKS]

I think we can consider this task as complete (even the page in the design docs says so).

One thing I noticed is that we need to address the state for when the app is built without QR code support. I created #141 for this.

Still think that there is some refinement to do with our decision to make the payment request screen the same as the transaction screen (one being a bit like a draft for the other), but that can be done in #140.