[feature]: Sign message from address (Ocean Mining bolt12 payouts)

[chrisguida]

CLN is the only officially supported way to receive Lightning payouts on Ocean, so a totally reasonable thing for a small pleb miner to do would be to use an on-chain address generated from CLN as the Ocean username, then sign a message from that on-chain address to verify the receiving bolt12 for Lightning payouts.

Note that LND already has this functionality:

Currently on the CLN the process is:

1. find key index using lightning-cli listaddresses | grep -C5 <address>
2. verify the derivation path: bitcoin-cli deriveaddresses "wpkh(<xpriv>/0/0/<keyidx>)#checksum" (change the checksum to the one bitcoin-cli suggests)
3. install bitcoinlib pip install bitcoinlib
4. go into the python repl: python

from bitcoinlib.keys import HDKey
xprv = "<xpriv>"
k = HDKey.from_wif(xprv)
# verify address is correct
k.subkey_for_path("0/0/<keyidx>").address(encoding='bech32', script_type='p2wpkh')
derived_key = k.subkey_for_path("0/0/<keyidx>")
# print WIF key
derived_key.wif_key()

6. bitcoin-cli signmessagewithprivkey <privkey_wif> '<ocean_json_message>'

This is pretty much limited to just devs, and it would be great to get decentralized template construction into the hands of less technical pleb miners!

cc @vincenzopalazzo

[Lagrang3]

I think I figured this out. I still need to test it and polish some details.

[hMsats]

@chrisguida Forget my deleted comment it doesn't work because additional info is necessay

[Lagrang3]

@vincenzopalazzo: who pays for lightning fees when Ocean sends payouts?

Imagine the mean fee for sending a payment was 1%, forget for a moment the pool operation fees for simplicity.
A user does some work and earns some shares. A block is found on the pool and Ocean has to send X sats to the user.
Who pays the lightning fees? ie. should either:

• Ocean send X+1% sats to the user, the user receives X sats, or
• Oceans sends X sats and the user receives X - 1%

The first case is the usual customer-server implicit agreement: the baker asks you 1$ for the bread and he doesn't
care about the costs you incur to get to the bakery store.

But on the other hand, in the case of Ocean, if the user of the pool is owned X sats for his work,
it means he "produced" the equivalent of X sats, not X sats + 1%. Extrapolating to the entire block reward:
the pool obtains a reward for a block B bitcoins not B+1%. Ocean cannot bear the cost for delivering the payment
because it doesn't have that money.

That said, maybe we should have an option in xpay to indicate the recipient pays for fees..., ie. the sending amount
is fixed and the recipient gets that minus fees.

[chrisguida]

@Lagrang3 IIRC Ocean is currently eating these fees, but you are correct that it doesn't seem sustainable.

Of course Ocean doesn't pay fees for on-chain payouts since it mines these blocks itself, but Lightning is a different beast.

And agreed that an option for the recipient to pay fees would be broadly useful.

[Lagrang3]

If the recipient pays for lightning fees, there is a change in the incentives:
the sender is not incentivized to find an cheap route. Maybe in a case like this
the recipient should be the one who builds the route and it could communicate this
to the sender via the bolt12 invoice in the form of a blinded path.
One issue is that the recipient doesn't know the identity of the sender, and the sender
shouldn't reveal his identity either.
I don't know... maybe this problem is already solved by some bolt12 magic.

[chrisguida]

just going to defer to @vincenzopalazzo on this one