Re: [Lightning-dev] AMP: Atomic Multi-Path Payments over Lightning

Olaoluwa Osuntokun writes: > Hi Y'all, > > A common question I've seen concerning Lightning is: "I have five $2 > channels, is it possible for me to *atomically* send $6 to fulfill a > payment?". The answer to this question is "yes", provided that the receiver This is awesome!

Re: [Lightning-dev] AMP: Atomic Multi-Path Payments over Lightning

Olaoluwa Osuntokun writes: > Protocol Overview > == > This design can be seen as a generalization of the single, non-interactive > payment scheme, that uses decoding of extra onion blobs (EOBs?) to encode > extra data for the receiver. In that design, the extra

Re: [Lightning-dev] Improving the initial gossip sync

I like Christian's proposal of adding a simple announcement cutoff timestamp with the intention of designing something more sophisticated given more time. I prefer the approach of having an optional feature bit signalling that a `set_gossip_timestamp` message must be sent immediately after

Re: [Lightning-dev] Improving the initial gossip sync

Hi, Suppose you partition nodes into 3 generic roles: - payers: they mostly send payments, are typically small and operated by end users, and are offline quite a lot - relayers: they mostly relay payments, and would be online most of the time (if they're too unreliable other nodes will eventually

Re: [Lightning-dev] channel_reserve_satoshis?

Good Morning Cezary, > This is quite good way to replace both-funding channels by such "superhub". > It would be even easier if I could open more then single channel between both > parties, but I saw this is not possible in c-lightning. From a risk perspective, you have increased risk in