search

joule-labs / webln

Spec and client library for WebLN apps and providers
244 stars 28 forks source link

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

Open Overtorment opened 5 years ago

Overtorment commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

juscamarena commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago
  1. No
  2. No

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

juscamarena commented 5 years ago

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.