Re: [Lightning-dev] Another Implementation
栗元憲一 writes: > I'm Kenichi Kurimoto from Japan. Greetings Kenichi, I've been wondering what you've been doing, since we've seen so many of your intelligent questions on the lightning-rfc github! We have a Google Hangout every two weeks; you're welcome to join if you want to discuss the specification progress but it is very early for Japan (4:00am!). https://docs.google.com/document/d/1oU4wxzGsYd0T084rTXJbedb7Gvdtj4ax638nMkYUmco/edit I look forward to your contributions! Thankyou, Rusty. > We are the team who have been seeking an application and architecture that > combine cryptocurrency and IoT. (We are corporate team. Nayuta Inc.) > > We are implementing another Node software according to Lightning Network > Specification(BOLT). > https://github.com/nayutaco/ptarmigan > > The software is developping phase, but basic feature of BOLT works on small > closed Testnet network with LND, c-lightning, and éclair. > We wrote how to use it on closed network. https://github.com/nayutaco/ > ptarmigan/tree/development/docs > When this node have valid path to starblocks, payment for starblocks can be > done. > We have not tested ip address broadcast mode. > > We have respect for the efforts of the people who made RFC document, and we > would like to contribute further protocol development. > > -Kenichi Kurimoto > ___ > 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] Improving the initial gossip sync: DRAFT
https://github.com/lightningnetwork/lightning-rfc/pull/392 I'll append to this as suggestions come in. I'm trying to find some cycles to implement it too. Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Lightning Protocol Summit September 10/11 2018?
Hi all, We had a kickoff summit for the Lightning Protocol in October 2016 in Milan. I think we're due for another one, so I'm proposing a date and location which works for me: September 10th and 11th Adelaide, Australia. This would be a meeting for development, update and optimization of the Lightning network protocol, with the aim to figure out what would be in the next version of the specification. I would love to host you all; we're a wine growing region, we have exotic animals, and spring is a great time to visit. Cheers, Rusty. PS. I'm confident we can find travel funds for developers who would otherwise be unable to attend. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] refunds -- was Re: BOLT 11, real time micro payments, and route redundancy
Andy Schroder writes: > On 09/14/2017 11:49 PM, Rusty Russell wrote: >> So, we really need to be able to include a (smaller) return onion to >> fix this properly. I've added that to: >> >> >> https://github.com/lightningnetwork/lightning-rfc/wiki/Brainstorming#refunds >> >> Thanks! >> Rusty. > > If you are including a smaller return onion, you are including that with > the payment? That return onion would be created by the payer since they > know the routes from the payer to the payee? If so, how could this work > if the route no longer has capacity (or goes down) by the time the payee > decides it's going to send the refund back to the payer (which could be > minutes, hours, or days later)? Also, even if all routes are still up, > the payer may not necessarily know how much refund the payee will be > giving them, so they may not necessarily be able to even know what the > best route they should build an onion for? You're right. While optimal routes aren't necessary, failures are possible and made worse by the inability to retry via a different route. I've noted this on the brainstorming phase. We don't currently return a reply message on success, but we could. It's best-effort of course (it won't appear if we drop to chain). I wonder if we could use that somehow. The general solution seems to require an ability to send payments to an anonymous destinations, which we don't have. Thanks! Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Christian Deckers Duplex Micropayment Channels vs Lightning networks revocation key solution
Good morning Rene, >To me the key revocation system seems pretty complex to handle. In particular >as Rusty also mentioned on his article (c.f. >https://medium.com/@rusty_lightning/lightning-watching-for-cheaters-93d365d0d02f > ) that already in the white paper people knew that potentially a third party >observing service to detect a cheater is needed. This seems to me like a big >drawback. I believe this is also necessary under Decker-Wattenhofer? A potential thief trying to reuse old invalid state could make sure you will be offline for a few days, then broadcast (and hope it confirms) the kickoff transaction, wait for the old invalid state to be valid, and then broadcast the old invalid commitment transaction. You have to be online after the kickoff transaction gets confirmed to ensure you can broadcast the latest commitment transaction, too, or if you plan to be offline for long, you also need some watchtower-like service under Decker-Wattenhofer. And I believe that watchtowers under Poon-Dryja need only store the shachain and the funding txid, while watchtowers under Decker-Wattenhofer would have to store entire relative-timelocked transactions, leaking economic information at each update to a Decker-Wattenhofer watchtower, whereas Poon-Dryja watchtowers need to learn only about shachain updates, and can learn economic information only when channels get onchain (and honestly, when channels drop onchain everyone knows the economic information since the blockchain is publicly readable, so it is not a significant information at that point). Regards, ZmnSCPxj___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Christian Deckers Duplex Micropayment Channels vs Lightning networks revocation key solution
Good morning Rene, The main issue I can think of offhand is the below issue for duplex channels: The maximum lockup period for your funds in the worst case is proportional to the number of updates the channel can have. Shorter worstcase lockup, fewer updates before the channel can only be closed. There is a technique to make O(log n) lockup time for n update limit rather than O(n) (at the cost of using O(log n) transactions in sequence), but the basic "more updates more worstcase lockup" exists. With Poon-Dryja (revocation) channels, there is no limit in the number of updates possible on a channel, especially when you use the "shachain" concept by Rusty Russell (which reduces storage for a sequence of revocation keys to just 64 bytes or so, I have not studied it deeply): in effect, you get O(1) lockup time and O(1) transactions for n update limit under Poon-Dryja rather than O(log n) lockup time and O(log n) transactions for Decker-Wattenhofer. Note in particular that every payment actually requires two updates: one to get payer funds to an HTLC, and the other to get the HTLC funds to the payee (or to revert the HTLC funds to the payer in case of routing failure). This is needed to get proof-of-payment and in particular to ensure that the final payee on a long route really did get the funds. So the cost incurred by Decker-Wattenhofer is higher by that factor, too. Decker-Wattenhofer does have the advantage that its construction can be extended to any number of participants per channel, while Poon-Dryja does not seem like it can be easily extended beyond two per channel. Hence the Burchert-Decker-Wattenhofer channel factories, where a Decker-Wattenhofer multiparticipant channel construction terminates into multiple two-participant Poon-Dryja channels. The Poon-Dryja channels can have any number of updates, and the Decker-Wattenhofer part only gets updated if all participants agree to redistribute their funds between terminating Poon-Dryja channels (which we expect to happen much more rarely than routing and sending/receiving funds, so that the O(log n) cost for maximum number of updates is less onerous for fund redistribution, while we still get to enjoy the potentially infinite number of possible channel updates for individual Poon-Dryja channels). Regards, ZmnSCPxj Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On March 4, 2018 7:30 AM, René Pickhardt via Lightning-dev wrote: > Hey everyone, > > as mentioned before I am quite new to lightning dev. Should the questions > I'll ask be too basic please drop me a kind note and I will be more quite or > ask my questions on other places. > > Today I studied Chrstian Deckers nice work about duplex micropayment channels > ( > [http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf](https://www.google.com/url?q=http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf&sa=D&source=hangouts&ust=1520200459037000&usg=AFQjCNG3ZwxZzV6e3VYlLpemzn0ZCUIv-A) > ) > > I am wondering what was the rational for the lightning spec ( > https://github.com/lightningnetwork/lightning-rfc ) to go with the revocation > key system instead of the solution by Christian Decker to the problem? I > understand that the revocation system was already in the whitepaper and at > the time of writing the whitepaper the work by Christian Decker wasn't out > yet. But I guess this will not be the entire reason. > > To me the key revocation system seems pretty complex to handle. In particular > as Rusty also mentioned on his article (c.f. > https://medium.com/@rusty_lightning/lightning-watching-for-cheaters-93d365d0d02f > ) that already in the white paper people knew that potentially a third party > observing service to detect a cheater is needed. This seems to me like a big > drawback. > > So what have been strong arguments to go with the revocation system? > > On a side note I would like to state my respect to you: The lightning network > (in combination with bitcoin) is really the most beautiful piece of > technology I came across since I learnt about TCP/IP. Great work everybody > for creating such an amazing technology and bringing together all those > beautiful ideas. I am very confident that this technology will become history. > > best Rene > > -- > [www.rene-pickhardt.de](http://www.rene-pickhardt.de/)http://www.beijing-china-blog.com/ > > Skype: rene.pickhardt___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
