Re: [Lightning-dev] Link-level payment splitting via intermediary rendezvous nodes

2018-11-12 Thread ZmnSCPxj via Lightning-dev
Good morning Christian, I am nowhere near a mathematician, thus, cannot countercheck your expertise here (and cannot give a counterproposal thusly). But I want to point out the below scenarios: 1. C is the payer. He is in contact with an unknown payee (who in reality is E). E provides the

Re: [Lightning-dev] Packet switching via intermediary rendezvous node

2018-11-12 Thread Christian Decker
Hi ZmnSCPxj, like I mentioned in the other mailing thread we have a minor complication in order get rendez-vous working. If I'm not mistaken it'll not be possible for us to have spontaneous ephemeral key switches while forwarding a payment. Specifically either the sender or the recipient have to

Re: [Lightning-dev] Approximate assignment of option names: please fix!

2018-11-12 Thread ZmnSCPxj via Lightning-dev
Good Morning Rusty, OG AMP is inherently spontaneous in nature, therefore invoice might not exist to put the feature on. Thus it should be global feature. Do we tie spontaneous payment to OG AMP or do we support one which is payable by base AMP or normal singlepath? Given that both

[Lightning-dev] Approximate assignment of option names: please fix!

2018-11-12 Thread Rusty Russell
Hi all, I went through the wiki and made up option names (not yet numbers, that comes next). I re-read our description of global vs local bits: The feature masks are split into local features (which only affect the protocol between these two nodes) and global features

Re: [Lightning-dev] Recovering protocol with watchtowers

2018-11-12 Thread ZmnSCPxj via Lightning-dev
Good morning Margherita, How does this scheme protect privacy of node? I would at least suggest that the pubkey used be different from the node normal pubkey. If I find out the pubkey of A, can I spoof A and give a higher nonce value with a blob containing random data (which is

Re: [Lightning-dev] Proposal for Advertising Channel Liquidity

2018-11-12 Thread ZmnSCPxj via Lightning-dev
Good morning lisa, >>> can simply close the channel. So if I'm charging for liquidity, I'd actually >>> want to charge for the amount (in mSAT/BTC) times time. >> >> So perhaps you could make a market here by establishing a channel saying >> that >> >> "I'll pay 32 msat per 500 satoshi per hour

Re: [Lightning-dev] Proposal for Advertising Channel Liquidity

2018-11-12 Thread ZmnSCPxj via Lightning-dev
Good morning lisa, > As you point out below, at the very least a liquidity providing node would > get paid. Another thing worth considering is that the spec, as written, is > merely a mechanism for advertising and receiving offers for dual funding. > There are no rules about what offers you,

Re: [Lightning-dev] Proposal for Advertising Channel Liquidity

2018-11-12 Thread lisa neigut
On Wed, Nov 7, 2018 at 11:02 PM 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

Re: [Lightning-dev] Proposal for Advertising Channel Liquidity

2018-11-12 Thread lisa neigut
On Wed, Nov 7, 2018 at 10:17 PM Anthony Towns wrote: > On Wed, Nov 07, 2018 at 06:40:13PM -0800, Jim Posen wrote: > > can simply close the channel. So if I'm charging for liquidity, I'd > actually > > want to charge for the amount (in mSAT/BTC) times time. > > So perhaps you could make a market

Re: [Lightning-dev] Proposal for Advertising Channel Liquidity

2018-11-12 Thread lisa neigut
Hello ZmnSCPxj, You bring up some good points. On Wed, Nov 7, 2018, 21:19 ZmnSCPxj Good morning Lisa, > > On Wednesday, November 7, 2018 2:17 PM, ZmnSCPxj via Lightning-dev < > lightning-dev@lists.linuxfoundation.org> wrote: > > Good morning Lisa, > > >Should a node be able to request more