RFC: Fee provider

[pythcoiner]

About fee calculation:

It's not possible to reason about the fees of an transacation when we do not yet
know it's inputs, and fees in coinjoins are a quite important subject.
An other point to consider about the fees is the 'peeling effect':
if if an user want to coinjoin several time the same coin, it will
"peel" it by paying fee and it's impossible to keep a coin w/ a stable denomination,
making hard to have standard denomination pools ala samourai.
One solution can be to have some fee providers that will accept payment for the fees
via lightning or liquid and will add 1 input to the psbt.

Fee provider

One solution of fee provider can be:

• The fee provider run an nostr relay
• Peer have a (custodial) 'account' at the fee provider, using ecash/ln/liquid/ or whatever you
  want
• Fees are never payed by peers in the coinjoined input/outputs in order to keep rounded
  denomination values.
• Instead of creating a toxic change, the amount delta can be used to found an additionnal
  output that go to the fee provider (minus the tx fee that will be deducted from peer
  "account").
• if there is no tx funding the fee provider, the provider will add an input that cover the
  tx fees.
• only one fee provider per pool, so all output funding the provider account can be
  aggregated or only 1 input pay for fees.
• peers can join a pool w/ an "i dont want pay fee" flag so ppl who want to have a quick
  coinjoin or ready to pay for others fee can cherry pick those inputs.

[1440000bytes]

Peer have a (custodial) 'account' at the fee provider, using ecash/ln/liquid/ or whatever you
want

I don't think this is a major concern for most users. However, a custodian would never be a solution or part of the protocol.

[pythcoiner]

i don't mean to a custodian to be part of the protocol, but i think we should allow ppl to construct pool that allow such construction:

• 1 input to pay fees
• 1 output to get the change from the "fee" input