From cezary.dziemian at gmail.com Wed Jun 5 14:05:17 2019 From: cezary.dziemian at gmail.com (Cezary Dziemian) Date: Wed, 5 Jun 2019 16:05:17 +0200 Subject: [Lightning-dev] Proposal for Advertising Channel Liquidity In-Reply-To: References: <20181108061703.cfbnzuuuudok5aor@erisian.com.au> Message-ID: Good morning group, My friend came to similar (almost the same) conclusions over a year ago, and I were working on implementation of this. I had first working prototype based on clightning (but not trustless), but at that time there were so many troubles with c-lightning, co I decided to make this solution based on LND. Unfortunately, I have other issues with LND also. There are some API method missing in LND and c-lightning also. This is the reason, I'm seriously tired doing this. I think, that was mistake to start working on that without more talks with you and community. Tomorrow, we scheduled to talk if it make sense to continue. A lot of options are possible. If you, agree, it would be valuable to make such thing, I can work on it as full time job (my friend is wiling to pay for that). I prefer to write it in Java rather and also need your support especially in terms of lack of some API methods. Please let me know, if we can build cross-implementation group to work on such thing and if you are willing to help. Best Regards, Cezary Dziemian pon., 12 lis 2018 o 11:05 ZmnSCPxj via Lightning-dev < lightning-dev at lists.linuxfoundation.org> napisa?(a): > 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 for the first 3 days" >> >> When you open the channel with 500,000 satoshi donated by the other guy, >> you're then obliged to transfer 32 satoshi every hour to the other guy >> for three days (so a total of 14c or so). >> >> If the channel fails beforehand, they don't get paid; if you stop >> paying you can still theoretically do a mutual close. >> > > I think that this can also be gamed by a second, cooperating node that > sends payments through the channel to meet the rate and capture the fees > for the first. You can make this less likely by charging higher > transmission fees that make such an attack infeasible, and it's less > 'damaging' than an immediate close in that there's still open capacity > available for some time, at least until the 'bogus' payments have drained > the capacity that you solicited in the first place. > > > I believe not? > I do not see any terms in the contract regarding payments through the > channel other than the "liveness" payment. > So regardless of activity (or lack of activity) in the channel, the above > payments should be made. > If the taker misses a payment, the maker closes the channel outright, > freeing itself from the obligation. > If the maker refuses to route, it loses out on potential routing fees. > Any activity through it do not seem to matter. > > This mechanism may actually be superior to the CLTV-encumberance I and > Rene proposed. > > Regards, > ZmnSCPxj > > > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: