Draft: BOLT7: The `route_price_update` Message

[jtimon]

DISCLAIMER: This is not a firm proposal yet, only a draft to hopefully receive some feedback. If this is not the right place for such a thing I can close it and open it as a PR to my own repo instead until it is more mature to actually be considered to be merged.

A few weeks ago I was discussing on IRC with alexbosworth and others about being able as a hop to charge specific fees for routing through different channel pair combinations.

My main use case was to be able to allow routing through channels with different chain_hash, so it's not really a fee, but a price, a multiplier. For example, if you want to route a BTC channel to an AAA channel and give 10 AAA for every BTC, you would set the "route price" (suggestions for better names welcomed) to 10.

But it can be also used to charge specific additional fees for channel combinations. For example, let's say you have 2 BTC channels c1 and c2 and you want to charge an additional 1% fee through them, in addition to any per channel fees. You would set the price for the pair to 0.99.

I'm talking in float numbers here to simplify, but in the draft I avoided them. Not sure if in a nice way or a stupid one.

As said, feedback welcomed. Please, be kind to me, but not to the draft or the proposal.

[jtimon]

I don't get this proposal. Why are the current routing fees not sufficient?

How do you satisfy my examples with the current routing fees? From what I was told on IRC, it is not possible, and after reading the specification, I don't see how one could do it with the current specification either.

(which could include the fees for the exchange and which should not be propagated over gossip anyway as exchange rates are probably needed in real time)

Well, I was assuming this "route_price_update" could be updated relatively often but not more often than that. I guess if people want more regular updates they can receive them from the connecting node in some other protocol other than the gossip one. Note the hop can always reject to route a payment when if the offered rate is not to his liking anymore, even if it had announce that rate would be fine before.

[kallewoof]

I don't think a price announce message will be useful at all. Nothing prevents a node from lying and the price constantly changes. Instead, I think a node would ask "how much X to fulfill this invoice paid in Y?" in some higher layer system (e.g. multi-chain-lightning... "storm"?).

Apologies for the long-winded explanation below, but it feels like it makes things clearer:

• For a multi-node pay-bitcoin-invoice-using-litecoin scenario, there would be some bitcoin nodes B1, B2, B3 and some litecoin nodes L1, L2, L3 where B1 is the payee and L1 is the payer, and a route that looks like L1, L2, L3/B3, B2, B1. Say the amount to pay is 1000 satoshi.
• The nodes L3 and B3 are both on the same machine owned by the same user, and the user is willing to take litecoin in exchange for bitcoin.
• To calculate the litecoin amount required to pay B1 through this route, the payer would iteratively ask each node starting with B2 the following question: "what would it cost to pay [next node] [required amount]", where [next node] starts with B1 and [required amount] is 1000 satoshi.
• If the fee is 10 satoshi, the answer would be 1010, so the next question would be to B3: "what would it cost to pay B2 1010 satoshi?".
• If the fee again is 10 satoshi, the answer would be 1020. The next question is to L3 (=B3): "how much (litecoin) would L3 want in order to pay 1020 (bitcoin) satoshi to B3?"
• If the rate was 1 btc satoshi = 100 ltc satoshi (determined by L3/B3 owner via some method, such as a price feed), and a 1000 ltc sat fee, the answer would be 1020*100 + 1000 = 103000.
• This then iterates to L2 and finally back to the payer, who now has an estimate on how much litecoin it would cost to make the payment.

The actual payment itself would then do the exact same thing as above, except as a multi-hop lightning payment. I am not an expert, but I believe the method with the secret reveal should work even in this case, despite the payee and payer being on different chains.

[jtimon]

I'm not sure what do you mean by lying. Do you mean they will announce a price higher than they will accept or they will announce a price lower than they will accept? I mean, nodes can lie with the channel_update message, I guess, but why would they do that? Just for DoS? If so, I guess you can start ignoring that connection between 2 channels or even that node altogether.

Regarding doing this in an upper layer, actually, running a different node for each chain would greatly simplify implementation, but I'm not sure I understand your proposal. Once L1 gets the invoice from B1, how does it calculate the L1 -> L2 -> L3 -> B3 -> B2 -> B1 ?

How does one calculate paths without having a single graph including both L and B gossips?

What you describe seems to be after the LN tx has been initiated, but I don't see how that can be done without this message or something equivalent.

[jtimon]

Actually, I think it's worse than that: How does L1 even know that L3 and B3 belong to the same person and will accept routing through them at a given price? I was doing L1 -> L2 -> L3 -> B3 -> B2 -> B1 which is rally L1 -(chan1)-> L2 -(chan2)-> L3 -(chan3)-> B3 -(chan4)-> B2 -(chan5)-> B1 But there's actually no channel 3, for what would that channel be denominated in? LTC or BTC? Either way, L3 cannot use BTC channels and B3 cannot use LTC channels. I really think you need L3=B3 to be the same node (with the same node id), supporting both BTC and LTC channels for this to work. The payer L1 will also need to connect to the bitcoin network to see if the payment is going through or not, anyway.

[kallewoof]

I think what I'm trying to aim at is, you don't want a price message, you want a quote message; i.e. I ask you for an estimate of a given payment, kind of like how nodes today find routes by asking for fee rates at different paths. (I think they do that. If not, I think that is the intention.)

You can convert the question of "what is the price of 1 btc in litecoin" to "what would the feerate be for sending litecoin into your channel and having it go out as bitcoin". Since I doubt the lightning implementation wants to implement a bunch of multi-coin stuff, this would have to happen at a higher layer, what I nicknamed "storm" above (so you would have storm which does gossip across multiple chains, and lightning below storm which does the per-chain stuff).

If L3/B3 takes a 5% premium on the price and the price is 100 ltc per btc, and you want to send 100 ltc, then the "fee" here would turn out to be "5 ltc" in the payment L3->B3, but since you don't know about the exchange rates used internally in L3/B3, all you would see is that it will cost you 105 ltc (plus other fees) to send 1 bitcoin to B3. From this you can derive the exchange rate of 105 ltc/btc, and compare it to your own price feeds. You can test other routes to find other quotes, and pick the cheapest one, unless the price is completely out of sync with your price feeds.

Once L1 gets the invoice from B1, how does it calculate the L1 -> L2 -> L3 -> B3 -> B2 -> B1 ?

It would act the same way that lightning multi-hop works today, I assume. There would have to be some trickery of course, but from L1's point of view, L3 and B3 are just two hops in the path.

But there's actually no channel 3, for what would that channel be denominated in? LTC or BTC? Either way, L3 cannot use BTC channels and B3 cannot use LTC channels.

Assuming we have the network protocol stuff in place for storm, this would simply be a matter of L3 having available incoming balance to receive litecoin from L2, and B3 having available outgoing balance to send bitcoin to B2.

I really think you need L3=B3 to be the same node (with the same node id), supporting both BTC and LTC channels for this to work.

Yes, I think you may be right. Edit: No, they probably should not be the same node id in lightning, but in storm they would gossip as a single entity with its own storm node id (i.e. "i am node id xyz, and I have ltc balance X/Y and btc balance Z/U").

The payer L1 will also need to connect to the bitcoin network to see if the payment is going through or not, anyway.

I think so, yeah.