Re: [Lightning-dev] Proposal for Advertising Channel Liquidity
> 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? Aside from the incentives for leaches to arise that accept the fee then insta close (they just drain the network and then no one uses this), I think this is a dope idea in general! In the past, I've mulled over similar constructions under a general umbrella of "Channel Liquidity Markets" (CLM), though via extra-protocol negotiation. -- Laolu On Wed, Nov 7, 2018 at 2:38 PM lisa neigut wrote: > Problem > > Currently it’s difficult to reliably source inbound capacity for your > node. This is incredibly problematic for vendors and nodes hoping to setup > shop as a route facilitator. Most solutions at the moment require an > element of out of band negotiation in order to find other nodes that can > help with your capacity needs. > > While splicing and dual funding mechanisms will give some relief by > allowing for the initial negotiation to give the other node an opportunity > to put funds in either at channel open or after the fact, the problem of > finding channel liquidity is still left as an offline problem. > > Proposal > = > To solve the liquidity discovery problem, I'd like to propose allowing > nodes to advertise initial liquidity matching. The goal of this proposal > would be to allow nodes to independently source inbound capacity from a > 'market' of advertised liquidity rates, as set by other nodes. > > A node, via their node_announcement, can advertise that they will match > liquidity and a fee rate that they will provide to any incoming > open_channel request that indicates requests it. > > `node_announcement`: > new feature flag: option_liquidity_provider > data: > [4 liquidity_fee_proportional_millionths] (option_liquidity_provider) fee > charged per satoshi of liquidity added at channel open > [4 liquidity_fee_base_msat] (option_liquidity_provider) base fee charged > for providing liquidity at channel open > > `open_channel`: > new feature flag (channel_flags): option_liquidity_buy [2nd least > significant bit] > push_msat: set to fee payment for requested liquidity > [8 liquidity_msat_request]: (option_liquidity_buy) amount of dual funding > requested at channel open > > `accept_channel`: > tbd. hinges on a dual funding proposal for how second node would send > information about their funding input. > > If a node cannot provide the liquidity requested in `open_channel`, it > must return an error. > If the amount listed in `push_msat` does not cover the amount of liquidity > provided, the liquidity provider node must return an error. > > Errata > == > It's an open question as to whether or not a liquidity advertising node > should also include a maximum amount of liquidity that they will > match/provide. As currently proposed, the only way to discover if a node > can meet your liquidity requirement is by sending an open channel request. > > This proposal depends on dual funding being possible. > > Should a node be able to request more liquidity than they put into the > channel on their half? In the case of a vendor who wants inbound capacity, > capping the liquidity request allowed seems unnecessary. > > Conclusion > === > Allowing nodes to advertise liquidity paves the way for automated node > re-balancing. Advertised liquidity creates a market of inbound capacity > that any node can take advantage of, reducing the amount of out-of-band > negotiation needed to get the inbound capacity that you need. > > > Credit to Casey Rodamor for the initial idea. > ___ > 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
Thanks for proposing this! I think it is absolutely one of the biggest onboarding/usability challenges for many use cases. My first thought is that like ZmnSCPxj mentioned, the person offering liquidity 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 like 1 mSAT per satoshi of bandwidth per hour or something like that. I don't think there's a perfect way of enforcing this at the protocol layer, but maybe you could lock up the fees in channel reserve which decreases over time and gets donated to miners on an early close? Instead of a flat payment for liquidity, I've considered in the past a model where you pre-pay on fees. So if I'm a large merchant and I expect to be receiving lots of volume in payments, it is totally rational for you to put up liquidity opening a channel to me because you will earn fees on payments routed to me through that channel. So what I could do to convince you is to say, "I expect if you open a 1 BTC channel to me, you will earn at least 10 mSAT per minute in routing fees. And if you don't I'll cover the difference." So every minute, I'll pay you 10 mSAT up front, then for all HTLCs that come through the channel to me up to that limit, you'll forward the fees onto me as reimbursement. I don't think this protocol is any less vulnerable to attacks, but perhaps aligns incentives better? My other concern with this sort of proposal is that it makes it easier to perform HTLC withholding/loop attacks, which are executed by the receiving end of a circuit. Currently on the network, there's a nice built-in protection that it's not obvious how to convince victim to open a channel to you. This is probably something that should get dealt with separately, but part of me doubts that it'll be possible to create a liquidity market without factoring in reputation. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Wireshark plug-in for Lightning Network(BOLT) protocol
Would it be possible to query a command line program or a JSON-RPC call to get the secret? In that case we could add it to the `listpeers` output. On Wed, Nov 7, 2018 at 6:43 AM tock203 wrote: > We implemented the latter scheme. lightning-dissector already supports key > rotation. > FYI, here's the key log file format lightning-dissector currently > implements. > https://github.com/nayutaco/lightning-dissector/blob/master/CONTRIBUTING.md#by-dumping-key-log-file > > Whenever key rotation happens(nonce==0), lightning node software write > 16byteMAC & key of "first BOLT packet". > When you read .pcap starts with a message whose nonce is not 0, the > messages can not be decrypted until the next key rotation. > > The current design is as described above. Because it is a provisional > specification, any opinion is welcome. > > 2018年11月6日(火) 16:08 Olaoluwa Osuntokun : > >> Hi tomokio, >> >> This is so dope! We've long discussed creating canned protocol >> transcripts for >> other implementations to assert their responses again, and I think this >> is a >> great first step towards that. >> >> > Our proposal: >> > Every implementation has compile option which enable output key >> information >> > file. >> >> So is this request to add an option which will write out the _plaintext_ >> messages to disk, or an option that writes out the final derived >> read/write >> secrets to disk? For the latter path, it the tools that read these >> transcripts >> would need to be aware of key rotations, so they'd be able to continue to >> decrypt the transact pt post rotation. >> >> -- Laolu >> >> >> On Sat, Oct 27, 2018 at 2:37 AM wrote: >> >>> Hello lightning network developers. >>> Nayuta team is developing Wireshark plug-in for Lightning Network(BOLT) >>> protocol. >>> https://github.com/nayutaco/lightning-dissector >>> >>> It’s alpha version, but it can decode some BOLT message. >>> Currently, this software works for Nayuta’s implementation(ptarmigan) >>> and Éclair. >>> When ptarmigan is compiled with some option, it write out key >>> information file. This Wireshark plug-in decode packet using that file. >>> When you use Éclair, this software parse log file. >>> >>> Through our development experience, interoperability test is time >>> consuming task. >>> If people can see communication log of BOLT message on same format >>> (.pcap), it will be useful for interoperability test. >>> >>> Our proposal: >>> Every implementation has compile option which enable output key >>> information file. >>> >>> We are glad if this project is useful for lightning network eco-system. >>> >> ___ >>> 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 > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Walletless channel opens
Good morning list, This topic is out of scope for the Lightning Development Summit 2018 as it requires SIGHASH_NOINPUT, but I thought it might be something to bring up to consider if it would be useful in the future. Currently, every Lightning implementation has to have its own onchain wallet implementation. This is because, the channel opening protocol requires a specific order in which transactions are signed and broadcast. Specifically, the funding transaction must be signed and broadcast *after* the first commitment transaction pair is signed and exchanged. However, SIGHASH_NOINPUT would allow Lightning implementations to be "walletless". What happens is that the first pair of commitment transactions will have to be signed with SIGHASH_NOINPUT, then the funding transaction can be created using a normal wallet. Then when the transaction paying the funding transaction output has been broadcast, succeeding commitment transactions may be created without SIGHASH_NOINPUT. I have discussed this before on bitcoin-dev: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/015925.html The primary use case is to reduce the number of transactions needed when the user prefers to use a specific wallet implementation that may have features unavailable to the Lightning implementation. For instance, the onchain wallet may have privacy features (integrated CoinSwap and CoinJoin, distinction between traceable/cleaned coins, etc.). A secondary use case would be to reduce implementation complexity for Lightning implementations, as there would only be needed to trace status (unconfirmed/confirmed, spent/unspent) specific transaction outputs, not scan the blockchain for specific `scriptPubKey`. 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
Good morning Lisa, On Wednesday, November 7, 2018 2:17 PM, ZmnSCPxj via Lightning-dev wrote: > Good morning Lisa, > >>Should a node be able to request more liquidity than they put into the >>channel on their half? In the case of a vendor who wants inbound capacity, >>capping the liquidity request >>allowed seems unnecessary. > > My initial thought is that it would be dangerous to allow the initiator of > the request to request for arbitrary capacity. > > For instance, suppose that, via my legion of captive zombie computers (which > are entirely fictional and exist only in this example, since I am an ordinary > human person) I have analyzed the blockchain and discovered that you have 1.0 > BTC you have reserved for liquidity requests under this protocol. I could > then have one of those computers spin up a temporary Lightning Node, request > for 1.0BTC incoming capacity with only some nominal fee, then shut down the > node permanently, leaving your funds in an unuseable channel, unable to earn > routing fees or such. This loses you potential earnings from this 1.0 BTC. > > If instead I were obligated to have at least greater capacity tied into this > channel, then I would also be tying up at least 1.0 BTC into this channel as > well, making this attack more expensive for me, as it also loses me any > potential earnings from the 1.0 BTC of my own that I have locked up. A counterpoint to this argument, however, is that if the fee for the liquidity is high enough, then it does not matter to you whether I use the 1.0 BTC or not: you have already been paid for it. This however brings up the other potential attack: 1. I advertise that I have 1.0 BTC available for liquidity requests. 2. You answer this advertisement, and pay me a good fee for this 1.0 BTC being locked into a channel. 3. After the channel is opened, I immediately close it, having earned the fee for liquidity, without in fact delivering that liquidity. Perhaps we can modify channel commitment transactions for channels opened via liquidity requests, so that they have an `nSequence` that prevents them from being claimed for a month or so. What do you think? Regards, ZmnSCPxj > To my mind, this may become important. > > Regards, > ZmnSCPxj > >> Conclusion >> === >> Allowing nodes to advertise liquidity paves the way for automated node >> re-balancing. Advertised liquidity creates a market of inbound capacity that >> any node can take advantage of, reducing the amount of out-of-band >> negotiation needed to get the inbound capacity that you need. >> >> Credit to Casey Rodamor for the initial idea.___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.
On Wed, Nov 07, 2018 at 02:26:29AM +, Gert-Jaap Glasbergen wrote: > > Otherwise, if you're happy accepting 652 satoshis, I don't see why you > > wouldn't be happy accepting an off-chain balance of 652.003 satoshis; > > you're no worse off, in any event. > I wouldn’t be worse off when accepting the payment, I agree. I can safely > ignore whatever fraction was sent if I don’t care about it anyway. The > protocol is however expecting (if not demanding) me to also route payments > with fractions, provided they are above the set minimum. In that case I’m > also expected to send out fractions. Even though they don’t exist on-chain, > if I send a fraction of a satoshi my new balance will be 1 satoshi lower > on-chain since everything is rounded down. But that's fine: suppose you want everything divided up into lots of 1 satoshi, and you see 357.719 satoshis coming in and 355.715 satoshis going out. Would you have accepted 357 satoshis going in (rounded down) and 356 satoshis going out (rounded up)? If so, you're set. If not, reject the HTLC as not having a high enough fee. Yes, you're still expected to send fractions of a satoshi around, but that doesn't have to affect your accounting (except occassionally to your benefit when you end up with a thousand millisatoshis). I think you can set your fee_base_msat to 2000 msat to make sure every HTLC you route pays you at least a satoshi, even with losses from rounding. If you're willing to find yourself having routed payments for free (after rounding), then setting it to 1000 msat should work too. > > Everything in open source is configurable by end users: at worst, either > > by them changing the code, or by choosing which implementation to use… > Well, yes, in that sense it is. But the argument was made that it’s too > complex for average users to understand: I agree there, [...] Then it's not really a good thing for different implementations to have as a differentiator... Cheers, aj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
