Good morning Ronan,
> If there is a payment to go from party A to be split between parties B & C,
> is it possible that only one of B or C would need a plugin?
>
> If all receiving parties need a plugin that is quite limiting. Thanks, Ronan
Given N payees, only N - 1 need the plugin.
The last
If there is a payment to go from party A to be split between parties B & C,
is it possible that only one of B or C would need a plugin?
If all receiving parties need a plugin that is quite limiting. Thanks, Ronan
On Fri, Dec 17, 2021 at 3:06 PM ZmnSCPxj wrote:
> Good morning cdecker,
>
> > I
Good morning cdecker,
> I was looking into the docs [1] and stumbled over `createinvoice` which does
> almost what you need. However it requires the preimage, and stores the
> invoice in the database which you don't want.
Indeed, that is precisely the issue, we need a `signfakeinvoice`
I was looking into the docs [1] and stumbled over `createinvoice` which
does almost what you need. However it requires the preimage, and stores the
invoice in the database which you don't want.
However if you have access to the `hsm_secret` you could sign in the plugin
itself, completely
Hello list,
In Lightning we have a great scheme to protect the identity of the sender
of a payment. This is awesome, but there are also use cases where opt-in
sender authentication is desired.
An example of such a use case is chat over lightning. If you receive a text
message, you generally want
Hi ZmnSCPxj,
So, are you saying there needs to be a new command "signfakeinvoice" at the
protocol level?
If that was there, how much work/hours would it be to build the poor man's
rendez-vous at the application level?
If the above were to be implemented, when the payer pays the invoice, it's
On Mon, Nov 22, 2021 at 5:11 PM Stefan Richter
wrote:
> I also don't believe putting a choice of more or less seconds expectation
> in the UI makes for a great user experience. IMHO the goal should just be:
> give the user an estimate of fees necessary to succeed within a reasonable
> time.
On Mon, Nov 22, 2021 at 7:53 AM ZmnSCPxj wrote:
> Good morning Dave,
>
> > If LN software speculatively chooses a series of attempts with a similar
> > 95%, accounting for things like the probability of a stuck payment (made
> > worse by longer CLTV timeouts on some paths), it could present
