Re: [Lightning-dev] Another Implementation

[Rusty Russell]

栗元憲一  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

[Rusty Russell]

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?

[Rusty Russell]

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

[Rusty Russell]

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