Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-14 📝 Original message: CJP <cjp at ...
📅 Original date posted:2015-07-14
📝 Original message:
CJP <cjp at ultimatestunts.nl> writes:
>> Fees are a real issue. Without source routing the client is guessing
>> how much fees will be, and there'll be a lot of gaming to decide how
>> much of the pie to take (take too much, you get none as payment fails to
>> route). I think you'll end up asking your provider how you should to
>> pay, and that's a pretty horrible model for privacy.
>>
>> With source routing and onion it's a little better; you can explicitly
>> state what each hop gets. Of course, if your route/payment information
>> is out of date you lose, too.
>
> I like to think of fees in the same way as we pay for Internet access.
> Every physical hop in the Internet has related costs, e.g. in placing
> the cables and upgrading the cables when new technology becomes
> available and when demand grows. Yet it doesn't matter for your Internet
> bill how many hops your packets make, or which route they follow. Your
> ISP will just average out all the costs it has to make on its
> interfaces, and present a fraction of that to each customer. At some
> points in the middle between providers, there are places where both
> sides have an equal interest in maintaining their link, and no fees are
> charged.
>
> One major difference with the Internet is that we already have a
> micro-transaction infrastructure in place, which is something the
> Internet has never had (until now). This means it is possible to do
> instant per-transaction payment of transaction fees. The fact that we
> CAN do it doesn't mean we SHOULD, but I think there are advantages:
> non-immediate payment models always require some form of trust from at
> least one of the sides. Immediate payment of a transaction fee is as
> simple as updating the micro-transaction channel with a slightly larger
> amount than the to-be-forwarded transaction amount.
Yes, it's a great question! The resource which is used up is not so
much CPU and bandwidth, it's the channel capacity and the security risk
involved with having bitcoin in a hot wallet. Both these costs scale
with the size of payment, making a "pay per satoshi" model seem
reasonable.
I'm concerned that if we don't take a reasonable stab at monetization,
it's another centralization pressure: the only nodes become those who
have a second income source, such as selling your data or providing
service only to (paying) registered businesses.
> An interesting question is whether nodes will be prepared to forward
> payments at a net loss (the to-be-paid fee is higher than the
> to-be-received fee); maybe they will, if they can compensate the losses
> with higher profits on other transactions. Fee differences could play a
> role in routing decisions.
>
> That brings me to another point: fees could be used as a way to
> incentivize people to bring channels back to equilibrium. When a
> channel's funds are almost fully assigned to one of its sides, further
> payments towards that side become nearly impossible. Increasing fees in
> that direction and decreasing fees in the opposite direction should
> incentivize people to perform more transactions that bring the channel
> back to equilibrium, and to perform less transactions that bring it
> further out of equilibrium, or find alternative routes for those
> transactions.
>
> You could even offer negative fees for transactions that bring a channel
> back to equilibrium. There could be a market for people making money
> from bringing other peoples' channels back to equilibrium. This would
> require either to step away from "net neutrality" (so, not the same fee
> for every route / destination), or it would require some form of source
> routing and explicitly setting the fees of intermediate nodes.
Yes, this was suggested to me by Joseph Poon in a face-to-face
conversation we had in San Francisco. It kind of blew my mind,
actually. The fact that you discovered it too provides fairly
convincing proof that you're smarter than me :)
eg. He suggested your client would initially connect to 5 random hubs.
It would then occasionally route payments back to itself, where doing so
was profitable or even neutral. If every client did this, it could
provide significant liquidity.
> My "neutral meeting point" routing design, which is effectively a
> two-hop source routing, is already good enough: a node in the middle of
> the network is advertising that it can benefit from a negative fee, and
> it invites people to perform transactions and to share the profit. It
> creates two routable addresses (one for the negative-fee interface (A)
> and one for all other interfaces (B)). Other people can then perform a
> payment-to-self, with payee side routing to A and payer-side routing to
> B. Payee-side can then have a larger payment amount than payer-side, as
> agreed with the meeting point, to transfer a part of the profit to the
> person performing the transaction.
(Sorry, a bit of a brain dump follows!)
I think negative fees fall out naturally from a route description which
includes fees (eg. A->B costs Xa + Ya-per-satoshi, B->A costs Xb +
Yb-per-satoshi). Naturally they need constraints (ie. don't bother
sending me 1BTC, my channel isn't that big).
There's going to be a real problem here with minimizing route flap.
Spamming the network every time pricing changes due to another HTLC is
not going to work, and could even undermine privacy by revealing
amounts.
A time-based model may work, but we'd need some serious modelling.
eg. "My fee will decrease by 0.1 satoshi per byte per second until you
hear otherwise".
WRT fee payment: The simplest fee method involves skimming an amount
from the HTLC. That only works if the HTLC succeeds! On the other
hand, if you pay each node up-front, it has no incentive to deliver.
And stalled payments are the greatest cost to a node (tying up capital
for days, potentially).
It seems the ideal payment calculation would be in satoshi-seconds (how
much capital you used, for how long).
Perhaps we can rig something that requires the recipient to pay more
according to time?
Joseph?
Cheers,
Rusty.
📝 Original message:
CJP <cjp at ultimatestunts.nl> writes:
>> Fees are a real issue. Without source routing the client is guessing
>> how much fees will be, and there'll be a lot of gaming to decide how
>> much of the pie to take (take too much, you get none as payment fails to
>> route). I think you'll end up asking your provider how you should to
>> pay, and that's a pretty horrible model for privacy.
>>
>> With source routing and onion it's a little better; you can explicitly
>> state what each hop gets. Of course, if your route/payment information
>> is out of date you lose, too.
>
> I like to think of fees in the same way as we pay for Internet access.
> Every physical hop in the Internet has related costs, e.g. in placing
> the cables and upgrading the cables when new technology becomes
> available and when demand grows. Yet it doesn't matter for your Internet
> bill how many hops your packets make, or which route they follow. Your
> ISP will just average out all the costs it has to make on its
> interfaces, and present a fraction of that to each customer. At some
> points in the middle between providers, there are places where both
> sides have an equal interest in maintaining their link, and no fees are
> charged.
>
> One major difference with the Internet is that we already have a
> micro-transaction infrastructure in place, which is something the
> Internet has never had (until now). This means it is possible to do
> instant per-transaction payment of transaction fees. The fact that we
> CAN do it doesn't mean we SHOULD, but I think there are advantages:
> non-immediate payment models always require some form of trust from at
> least one of the sides. Immediate payment of a transaction fee is as
> simple as updating the micro-transaction channel with a slightly larger
> amount than the to-be-forwarded transaction amount.
Yes, it's a great question! The resource which is used up is not so
much CPU and bandwidth, it's the channel capacity and the security risk
involved with having bitcoin in a hot wallet. Both these costs scale
with the size of payment, making a "pay per satoshi" model seem
reasonable.
I'm concerned that if we don't take a reasonable stab at monetization,
it's another centralization pressure: the only nodes become those who
have a second income source, such as selling your data or providing
service only to (paying) registered businesses.
> An interesting question is whether nodes will be prepared to forward
> payments at a net loss (the to-be-paid fee is higher than the
> to-be-received fee); maybe they will, if they can compensate the losses
> with higher profits on other transactions. Fee differences could play a
> role in routing decisions.
>
> That brings me to another point: fees could be used as a way to
> incentivize people to bring channels back to equilibrium. When a
> channel's funds are almost fully assigned to one of its sides, further
> payments towards that side become nearly impossible. Increasing fees in
> that direction and decreasing fees in the opposite direction should
> incentivize people to perform more transactions that bring the channel
> back to equilibrium, and to perform less transactions that bring it
> further out of equilibrium, or find alternative routes for those
> transactions.
>
> You could even offer negative fees for transactions that bring a channel
> back to equilibrium. There could be a market for people making money
> from bringing other peoples' channels back to equilibrium. This would
> require either to step away from "net neutrality" (so, not the same fee
> for every route / destination), or it would require some form of source
> routing and explicitly setting the fees of intermediate nodes.
Yes, this was suggested to me by Joseph Poon in a face-to-face
conversation we had in San Francisco. It kind of blew my mind,
actually. The fact that you discovered it too provides fairly
convincing proof that you're smarter than me :)
eg. He suggested your client would initially connect to 5 random hubs.
It would then occasionally route payments back to itself, where doing so
was profitable or even neutral. If every client did this, it could
provide significant liquidity.
> My "neutral meeting point" routing design, which is effectively a
> two-hop source routing, is already good enough: a node in the middle of
> the network is advertising that it can benefit from a negative fee, and
> it invites people to perform transactions and to share the profit. It
> creates two routable addresses (one for the negative-fee interface (A)
> and one for all other interfaces (B)). Other people can then perform a
> payment-to-self, with payee side routing to A and payer-side routing to
> B. Payee-side can then have a larger payment amount than payer-side, as
> agreed with the meeting point, to transfer a part of the profit to the
> person performing the transaction.
(Sorry, a bit of a brain dump follows!)
I think negative fees fall out naturally from a route description which
includes fees (eg. A->B costs Xa + Ya-per-satoshi, B->A costs Xb +
Yb-per-satoshi). Naturally they need constraints (ie. don't bother
sending me 1BTC, my channel isn't that big).
There's going to be a real problem here with minimizing route flap.
Spamming the network every time pricing changes due to another HTLC is
not going to work, and could even undermine privacy by revealing
amounts.
A time-based model may work, but we'd need some serious modelling.
eg. "My fee will decrease by 0.1 satoshi per byte per second until you
hear otherwise".
WRT fee payment: The simplest fee method involves skimming an amount
from the HTLC. That only works if the HTLC succeeds! On the other
hand, if you pay each node up-front, it has no incentive to deliver.
And stalled payments are the greatest cost to a node (tying up capital
for days, potentially).
It seems the ideal payment calculation would be in satoshi-seconds (how
much capital you used, for how long).
Perhaps we can rig something that requires the recipient to pay more
according to time?
Joseph?
Cheers,
Rusty.