RFC: getAddress for (fallback?) on-chain transaction

[Overtorment]

I propose to add something like this to Provider signature:

getAddress(comment: string): Promise<BitcoinAddress|String>;

For a case when Lapp needs an onchain address for whatever reason. Reason should be provided in comment which is displayed to user.
Common use cases: change; refund in case of some kind of failure; lapp wants to payout too big amount; issue with user-provided invoice (via makeInvoice) - no route/no capacity

Prodiver shall display comment to user and user should choose his regular onchain btc wallet to receive such transaction.

[wbobeirne]

Since on-chain address for refunds / large payments is a part of the BOLT-11 spec, is there any reason we wouldn't just rely on that?

[Overtorment]

Use-case: ZigZag exchanges lighnting coins on on-chain coins, thus, asks for onchain address, it doesnt need whole bolt invoice. Otherwise, workaround would be: makeInvoice generates bolt11 string, but ln invoice is absent/not valid/simply ignored, and only fallback address is extracted. Feels hacky.

[Overtorment]

Oh, also provider might not know that fallback is really required in some case, while getAddress would specifically ask for address.

[juscamarena]

If we want to include bitcoin payments in webLN goodness I see merit in adding this call. Also agree with @Overtorment with ZigZag style exchange being able to autofill on chain address as good example.

[wbobeirne]

Sorry for the delay, this makes plenty of sense to me, even more-so now with Loop. A question to the audience though:

1. Does the address need to come back with any additional metadata about it other than the address itself? Maybe its type?
2. Should the application be able to specify an address type, e.g. they don't support bech32? A large part of me wants to say 'no' to this because it may be difficult for some providers to adhere to address type constraints, but I want to make sure all use cases are covered.

[juscamarena]

Most services check the address and know what type it is anyway, so I don't think so.

Would be nice to have the service be able to say a they do support bech32 and prefer that, but not be a hard requirement.

[Overtorment]

1. No
2. No

I doubt any dinosaur application will support webLN and NOT support bech32

[juscamarena]

True, eclair seems to be one of the weird ones not offering native bech32 receive support, but it's a mobile wallet, strict bech32 would be preferred, can always add an optional type in the future, but probably not needed now.