Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.
How do i unsubscribe from this email list? Could someone help me please. Kindly, Alex From: lightning-dev-boun...@lists.linuxfoundation.org on behalf of Gert-Jaap Glasbergen Sent: Monday, November 5, 2018 3:48:56 PM To: lightning-dev@lists.linuxfoundation.org; Rusty Russell Subject: Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits. Op 1 nov. 2018 om 03:38 heeft Rusty Russell mailto:ru...@rustcorp.com.au>> het volgende geschreven: I believe this would render you inoperable in practice; fees are frequently sub-satoshi, so you would fail everything. The entire network would have to drop millisatoshis, and the bitcoin maximalist in me thinks that's unwise :) I can see how not wanting to use millisatoshis makes you less compatible with other people that do prefer using that unit of account. But in this case I think it's important to allow the freedom to choose. I essentially feel we should be allowed to respect the confines of the layer we're building upon. There's already a lot of benefits to achieve from second layer scaling whilst still respecting the limits of the base layer. Staying within those limits means optimally benefit form the security it offers. Essentially by allowing to keep satoshi as the smallest fraction, you ensure that everything you do off-chain is also valid and enforced by the chain when you need it to. It comes at trade offs though: it would mean that if someone routes your payment, you can only pay fees in whole satoshis - essentially meaning if someone wants to charge a (small) fee, you will be overpaying to stay within your chosen security parameters. Which is a consequence of your choice. I would be happy to make a further analysis on what consequences allowing this choice would have for the specification, and come up with a proposal on how to add support for this. But I guess this discussion is meant to "test the waters" to see how much potential such a proposal would have to eventually be included. I guess what I'm searching for is a way to achieve the freedom of choice, without negatively impacting other clients or users that decide to accept some level of trust. In my view, this would be possible - but I think working it out in a concrete proposal/RFC to the spec would be a logical next step. Gert-Jaap ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Link-level payment splitting via intermediary rendezvous nodes
Good morning list, As was discussed directly in summit, we accept link-lvel payment splitting (scid is not binding), and provisionally accept rendez-vous routing. It strikes me, that even if your node has only a single channel to the next node (c-lightning), it is possible, to still perform link-level payment splitting/re-routing. For instance, consider this below graph: E<---D--->C<---B ^ / | / |L A In the above, B requests a route from B->C->D->E. However, C cannot send to D, since the channel direction is saturated in favor of D. Alternately, C can route to D via A instead. It holds the (encrypted) route from D to E. It can take that sub-route and treat it as a partial route-to-payee under rendez-vous routing, as long as node A supports rendez-vous routing. This can allow re-routing or payment splitting over multiple hops. Even though C does not know the number of remaining hops between D and the destination, its alternative is to earn nothing anyway as its only alternative is to fail the routing. At least with this, there is a chance it can succeed to send the payment to the final destination. Regards, ZmnSCPxj___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Explicit Fee Management Proposal
Good morning list, For extra bikeshedding opportunities, I present below, a proposal for explicit management of commitment transaction and mutual close transaction fees. By this thought, "explicit management", I want to convey, that the parties have more control over fees. ### Additional Variables Nodes will now additionally track for each channel: * `from_local_fee_msat` - 64-bit unsigned integer. The amount of fees contributed by this node. * `from_remote_fee_msat` - 64-bit unsigned integer. The amount of fees contributed by this node If the node is the initiator of the channel, its `from_local_fee_msat` contains the fee decided during channel opening, and its `from_remote_fee_msat` is 0. If it is not the initiator, then the reverse is true. Rationale Although onchain fees are measured in satoshi, the above variables are in millisatoshi in order to allow finer proportional deductions when reducing fees. ### Additional channel state updates These update messages behave similarly to `offer_htlc`. Multiple of these messages may be sent, and then `commitment_signed` puts them into effect for the commitment transaction. The `add_fees` message 1. type - TBD 2. data: * [`8`: `short_channel_id`] * [`8` : `additional_donated_fee_sat`] `additional_donated_fee_sat` is the amount of fees that the sending node proposes to donate as fees, in order for the commitment transaction to be confirmed in a timely manner. The donated fee is deducted from the sender funds of the channel. Multiple `add_fees` message add up their effects. The sender: * MUST NOT offer a fee donation that would put their balance below the channel reserve. * MAY donate their entire balance, minus the channel reserve. Both nodes: * MUST convert the satoshi units in this message to millisatoshis before updating the `from_local_fee_msat` and `from_remote_fee_msat` when a commitment is signed. The `propose_deduct_fees` message 1. type - TBD 2. data: * [`8`: `short_channel_id`] * [`8` : `proposed_deducted_fee_sat`] `proposed_deducted_fee_sat` is the amount by which the total fees will be deducted. This message starts a sub-protocol, where other channel state update messages for the channel are disallowed and will trigger an `error` message with code `TBD`. The sub-protocol involves `propose_deduct_fees` messages, and is ended once both sides send `accept_deduct_fees`. The lowest `proposed_deducted_fee_sat` before the `accept_deduct_fees` is selected. Thus each node has the ability to veto a deduction by simply sending a 0 `proposed_deducted_fee_sat`. The `accept_deduct_fees` message 1. type - TBD 2. data: * [`8`: `short_channel_id`] * [`8` : `min_proposed_deducted_fee_sat`] Once both nodes have sent this `accept_deduct_fees` for a channel with the same `min_proposed_deducted_fee_sat`, then both nodes have come to an agreement on how much to deduct as fees. The deduction is split between the two nodes in proportion to how much each one donated to the fees. Thus, to compute how much will be deducted from `from_local_fee_msat`, the division below is rounded down: deduct_from_local_fee_msat = 1000 * min_proposed_deducted_fee_sat * from_local_fee_msat / (from_local_fee_msat + from_remote_fee_msat) The receiver: * SHOULD send `propose_deduct_fees` with the lowest deducted fee, if the `min_proposed_deducted_fee_sat` does not match what it believes to have seen as the lowest. * this may occur if messages get sent at about the same time. * MAY fail the channel if this occurs too often. * MAY fail the channel if it considers the fee deduction to be too low to be reasonable. Regards, ZmnSCPxj___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Proposal for Advertising Channel Liquidity
Was approaching more so from the angle of a node new node with no existing channels seeking to bootstrap connections to the network. -- Sent from my Spaceship On Fri, Nov 9, 2018, 9:10 AM Anthony Towns On Thu, Nov 08, 2018 at 05:32:01PM +1030, Olaoluwa Osuntokun wrote: > > > A node, via their node_announcement, > > Most implementations today will ignore node announcements from nodes that > > don't have any channels, in order to maintain the smallest routing set > > possible (no zombies, etc). It seems for this to work, we would need to > undo > > this at a global scale to ensure these announcements propagate? > > Having incoming capacity from a random node with no other channels doesn't > seem useful though? (It's not useful for nodes that don't have incoming > capacity of their own, either) > > Cheers, > aj > > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Proposal for Advertising Channel Liquidity
On Thu, Nov 08, 2018 at 05:32:01PM +1030, Olaoluwa Osuntokun wrote: > > A node, via their node_announcement, > Most implementations today will ignore node announcements from nodes that > don't have any channels, in order to maintain the smallest routing set > possible (no zombies, etc). It seems for this to work, we would need to undo > this at a global scale to ensure these announcements propagate? Having incoming capacity from a random node with no other channels doesn't seem useful though? (It's not useful for nodes that don't have incoming capacity of their own, either) Cheers, aj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
