Implementing BIP-47

[retrnull]

I would like to work on implementing send and receive support for BIP-47 payment codes. However, before I start the work, I have a few questions:

• Would such a feature be accepted into the codebase?
• I expect to take about a month to implement it. Approximately when would a release including the functionality be made available for download?

Thanks in advance. Please let me know of any concerns about BIP-47 and this particular endeavor. I'll start working on the implementation once I get answers.

[alessandro-saglimbeni]

Hi @retrnull before you start any implementation how do you think your implementation would fit with the current UX? Keep in mind we're trying to simplify the user interface as much as possible, few options exposed on the first layer of the interface and more options within menus.

Also consider that on Green there's multiple types of accounts, and we normally refrain from adding new features just for one account type.

Let me know and I'll evaluate whether this can become a priority (in terms of review pre- and post-implementation) for our team

[retrnull]

Sorry for the delay, I've only recently been able to look into the integration.

In essence, there are 4 features that need to be implemented:

1. Sending
2. Receiving
3. Watch-only wallet support
4. Wallet recovery

Sending

For sending, I plan to modify the "Send" screen in a few ways for BIP47 transactions:

• Add a "Payment Code" section, with a "Use ephemeral payment code" toggle.
• For transactions that require a notification or conversion transaction (described in detail below), rename the "Network Fee" section to "Network Fees", and display the fee for every transaction, allowing the user to set the fee rates for each of them separately.

Furthermore, for transactions that require a notification or conversion transaction, I plan to modify the "Review" screen by adding an "Extra costs" section, which will display the values and associated fees of each of the transactions (excluding the main transaction, whose value is already specified in "Sent To").

Conversion transaction

The conversion transaction is a novel feature that allows the user to "convert" one of their segwit UTXOs into a P2PKH UTXO. This is useful for BIP47 transactions because the BIP doesn't specify segwit scripts as one of the formats that a receiving wallet should support in order to successfully acquire the sender's public key.

The way it works is very simple: it spends segwit UTXOs to a P2PKH address, and then spends that UTXO in the notification transaction. This way, we can guarantee that the receiver will be able to parse the public key from the notification transaction.

In order for a user to make use of this feature, I plan to make the app display a dialog when the user presses the "Next" button in the "Send" screen, which warns the user that there are only segwit UTXOs available, and that if they are not completely sure that the receiver will be able to parse the public key from them, they should make a conversion transaction. The dialog would have buttons to allow the user to proceed anyways, make the conversion transaction or cancel the transaction. If the user chooses to make the conversion transaction, the dialog will be closed, and the conversion transaction will be added to the "Network Fees" section.

Receiving

For the receive support, in the "Receive" screen, I plan to replace the "Account Address" label with "Address" and "Reusable Payment Code" tabs.

Furthermore, in the "Received" screen, I plan to add a "Refund Sender" button, and to make it always display the payment code that received the transaction instead of the ephemeral address.

Notification transactions will be handled seamlessly and not be displayed to the user (except in watch-only wallets, see below).

Watch-only

Sending

In the context of watch-only wallets, sending is concerned with the "sweep" feature, since sending from watch-only wallets is not supported. In the "Sweep" screen, I plan to do the following changes:

• Add radio buttons to allow the user to specify whether the specified private key is a root private key or a per-address key.

• If the key is a root private key, show checkboxes to allow the user to specify which kinds of transactions to check for (e.g. segwit, P2PKH), and include BIP47 transactions in the options. If the BIP47 checkbox is checked, display a toggle to allow the user to specify whether to do a "deep scan" (explained further in the wallet recovery section), with a "help" button that shows a dialog displaying the same information as the deep scan screen described in the wallet recovery section.

Receiving

Receive support requires quite a bit of additions both to the watch-only wallet and to the offline wallet.

Watch-only wallet's end

In the watch-only wallet's end, it's required to implement a mechanism for the user to specify the payment code in the first place. In order to do that, I plan to add an "Address" button alongside the "xPub" and "Descriptor" buttons in the "Watch-only credentials" screen. Pressing on this button will allow the user to specify addresses, which may include payment codes. This is a feature that is not solely concerned with BIP47, but I believe that it's a good addition nonetheless because the xpubs or descriptors may not always be easily available. Furthermore, other options (that I could think of) for specifying the payment code didn't seem as fitting with the current design, including specifying the payment code separately from the xpub/descriptor in the same screen, or importing it in the "Receive" screen (potentially along with the ephemeral payment codes).

In order to be able to receive BIP47 transactions, the watch-only wallet needs a mechanism for sharing the blinded payment code conveyed through the notification transaction with the offline wallet, and import the ephemeral addresses generated based on it. For that purpose, I plan to make the following changes to how the transaction item in the transaction lists is displayed for notification transactions:

• Replace "Received" with "Notification Transaction", because receiving notification transactions is the only possibility for watch-only wallets.
• Omit the transaction value, since values transferred through notification transactions are not meant to be spent.
• Use a notification icon instead of the typical "received" icon.
• Display a bubble next to the "Notification Transaction" label saying "Action Required". Pressing on the transaction item navigates to another screen that describes how to proceed and has buttons to allow the user to export the blinded payment code and import the ephemeral addresses generated by the offline wallet (explained further later on). The bubble is removed once ephemeral addresses are imported, and pressing on the transaction item will then open the usual "Received" screen, except for the following differences:
  • The transaction value will be omitted.
  • The notification address will be replaced with the payment code.
  • "Transaction Completed" will be replaced with "Notification Completed".
  • "The transaction was successfully received" will be replaced with "Further transactions from this sender can now be received".

Further transactions received to the payment code are displayed as for full wallets.

For importing more ephemeral addresses in case all of them get used, I plan to do the following:

• When the transaction that uses the last ephemeral address is received, display the "Action Required" bubble again, but in this case, allow the user to simply ignore the export/import screen by going back.
• Add an option "Import BIP47 ephemeral addresses" to the menu in the "Receive" screen, which will display a list that allows the user to see the payment codes that have sent payments to the user, how many ephemeral addresses we have for them and how many have been used. The payment codes for which all ephemeral addresses have been used will be placed higher in the list and will be highlighted. Each item in the list will have a button that will allow the user to export the blinded payment code and import the generated ephemeral addresses.

For importing ephemeral payment codes, I plan to add another button to the menu in the "Receive" screen, saying "Import BIP47 payment codes", which will allow the user to import them from a file.

Offline wallet's end

In the offline wallet's end, I plan to add a "BIP47" section to the "Watch-only" screen from the "Settings" screen, with the following contents for each account:

• A "BIP47 Ephemeral Payment Codes" section, with text fields which will allow the user to specify an offset and an amount (both of will be filled in by default, but can be optionally changed by the user), and with a button that allows the user to save the generated ephemeral payment codes to the filesystem.
• A "BIP47 Ephemeral addresses" section, similar to the above, but with another text field that allows the user to specify the blinded payment code. The generated addresses will also be saved to the filesystem.

Wallet recovery

For wallet recovery, the only UI change required is for supporting "deep scanning", i.e. the scanning of every one of the 2^32 ephemeral payment codes for potential refunds. In order to do that, I plan to modify the menu in the account-specific wallet screen in the following ways:

• Move the account-related options to an "Account" section.
• Add a "General" section and a "BIP47 deep scan" within it.

The deep scan button will navigate to another screen that describes what deep scanning is, why it may be required, and warns the user that the operation may take very long and transfer hundreds of gigabytes of data over the network. The screen will also have text fields to allow the user to specify an optional offset and an optional number of ephemeral payment codes to check for transactions for, both of which will be automatically populated if the user has interrupted a previous deep scanning operation.

---

This is a (somewhat high-level) overview of what I plan to do at the UI level. Please let me know if anything sounds unclear or unfitting and I will try to elaborate better or figure out alternative approaches.

Regarding the multiple types of accounts matter, BIP47 is only specified for singlesig wallets and watch-only wallets. In other words, 2FA accounts are not supported, nor are hardware wallets, for that matter.

Now that I have provided a concrete overview of the features to be added, I would like to ask the same questions, for confirmation:

• Is BIP47 support really a desired feature? I understand that the amount of changes can seem intimidating, but I'm certain that, with enough planning, the implementation can be integrated smoothly with the codebase, and the changes will ultimately make it more robust and flexible for future features.
• When, approximately, would a release including the functionality be made, assuming that the implementation itself takes about a month? As far as I can tell from the release history, releases closely follow the addition of features to the codebase. However, given the large number of changes, and the kind of the changes, I imagine that a major release will be required, and I'm not aware if there exists a roadmap or similar schedule for such releases. Furthermore, I'm uncertain regarding how long it would take for the PR to be reviewed. Please enlighten me on these matters.

I understand that there are many additions and many changes to the code may be required, but I'm determined to see the implementation through completion.