Jasper Hugunin [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-08-11 to 2015-09-02
💬 Posted a total of 4 messages
📚 Participated in the following categories: Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 14:44:20

- reply

📅 Original date posted:2015-09-02
📝 Original message:
I had an idea regarding an alternative to the high/low priority. My
understanding is that the problem is this case:
Alice sends PKT_UPDATE and transitions to WAIT_FOR_UPDATE_ACCEPT.
Bob sends PKT_UPDATE, and also transitions to WAIT_FOR_UPDATE_ACCEPT.
Then Bob receives Alice's PKT_UPDATE. Since he is waiting for his own
update, he doesn't know which *single* update is the official one. Same for
Alice.
What if Bob and Alice agree on a new update that combines both updates. The
protocol can only handle one update at a time, but the update doesn't have
to happen one-way.
This would be similar to TCP Simultaneous Open/Close.
So Alice and Bob would exchange PKT_SIMULTANEOUS_ACCEPT containing
signatures, and then exchange PKT_SIMULTANEOUS_COMPLETE containing revoking
pre-images.
Continuing my example above, Bob would receive PKT_UPDATE, send
PKT_SIMULTANEOUS_ACCEPT and transition to WAIT_FOR_SIMULTANEOUS_ACCEPT.
Alice would receive Bob's PKT_UPDATE, send PKT_SIMULTANEOUS_ACCEPT and
transition to WAIT_FOR_SIMULTANEOUS_ACCEPT.
Bob would recieve Alice's PKT_SIMULTANEOUS_ACCEPT, send
PKT_SIMULTANEOUS_COMPLETE, and transition to NORMAL.
Same for Alice.
I think that avoids either deadlock or livelock, and does not require
duplicating states for priority.
- Jasper
On Tue, Sep 1, 2015 at 10:55 PM, Rusty Russell <rusty at rustcorp.com.au>
wrote:
> Anthony Towns <aj at erisian.com.au> writes:
> > On 1 September 2015 at 17:32, Rusty Russell <rusty at rustcorp.com.au>
> wrote:
> >
> >> Looking at that git tree (I've done some work since then)...
> >
> > Oh, github hasn't been updated since Aug 20? That's forever ago!
> >
> >
> >> Ah, you
> >> can't send a command while processing an existing command. Seems a
> >> logical simplification.
> >>
> >
> > I'm thinking of CMD_CLOSE like "Ctrl-C"; why wouldn't you want it to work
> > anytime?
>
> Yes, I think you do. And the other side can CMD_CLOSE during an HTLC
> negotiation (for example), so this should be allowed.
>
> I will update it to allow CMD_CLOSE at any time (except when already
> closing).
>
> >> >> This makes the constraints clearer, eg. you can't DECLINE_HTLC
> anything
> >> >> but an ADD_HTLC.
> >> > Your states currently allow declining those though:
> >> Not at all (or if it does, it's a bug).
> >
> > Right, it's a bug as of 52cda01 then :)
>
> Weird, my tester should have found that (every tested-for input must be
> given).
>
> Ah, yes, it did, once I enhanced the tester to actually track htlcs.
> And I've fixed it :)
>
> (Those should be going to STATE_WAIT_FOR_UPDATE_ACCEPT).
>
> >> The simplest (and safest) system is always to error and close when they
> >> break protocol. There's some game theory involved in whether you should
> >> wait or not, but in the end, they're broken and there's not much you can
> >> do.
> >>
> >
> > Well, you can ignore some errors -- time sync problems might resolve
> > themselves, eg. And the "error" might be because of an error on your side
> > (your admin ran the wrong date command, there's a bug in your code), that
> > might well be fixable. I guess what I'm thinking is that closing a
> channel
> > is a real cost; if they're not actively cheating -- by not completing an
> > HTLC update once they agree to it eg -- I'd probably rather it stay open
> > (in degraded mode perhaps) than automatically close.
>
> We could add such things later, but it's really hard to know in advance
> what bugs will lose money and which can be ignored.
>
> >> I also wonder if
> >> > A: TIMEDOUT_HTLC -> B: DECLINE (err_time_sync_lost)
> >> > might be useful.
> >> I don't think it's useful, though if you disagree on time you might get
> >> an error packet. (What else can you do?)
> >>
> >
> > How is "an error packet" different to a decline packet or a channel
> close?
>
> It carries an ascii message giving you a clue :)
>
> > Perhaps we should add a current time field to UPDATE_ADD_HTLC so you can
> >> defuse clock sync problems earlier?
> >>
> >
> > Or maybe time sync is part of the p2p protocol? I guess channel
> > counterparties are always peers?
>
> Yes, that makes sense.
>
> >> Sorry, I was assuming that one or both implementations were buggy. I
> >> meant
> >> > to make that explicit. You're talking with strangers on the network,
> so
> >> > you can't assume their software is bug free, right?
> >> That applies to any scheme you come up with, though. Propose something
> >> simpler, and I'll gladly rewrite.
> >
> > I'll have another look when I can see current code :)
>
> NW, just running the now-glacial state tester. I'm sure there's only 1
> bug left!
>
> Cheers,
> Rusty.
> _______________________________________________
> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150902/e41ada10/attachment.html>

2023-06-09 14:44:00

- reply

📅 Original date posted:2015-08-12
📝 Original message:
The routing protocol is a variant of distance-vector routing
<https://en.wikipedia.org/wiki/Distance-vector_routing_protocol>. The idea
is that nodes tell their peers beforehand "I know how to get to node X, and
it will cost you this much." Nodes use this information to build a routing
table saying "If I want to send payment to node X, I should forward payment
to node B." Then when payment needs to be sent, the node looks up "Which of
my peers do I forward to?" That is done by the "SELECT nexthop, cost FROM
ROUTES WHERE address = ?" query. If the peer you select does not know the
destination, they lied to you. If you have more than one peer, you choose
the cheapest one.
That said, the current routing protocol is something of a hack to
demonstrate potential, rather than a final solution.
Thanks,
- Jasper
On Wed, Aug 12, 2015 at 9:31 AM, Bryan Bishop <kanzure at gmail.com> wrote:
> On Wed, Aug 12, 2015 at 11:12 AM, Jasper Hugunin <jasper at hashplex.com>
> wrote:
>
>> Here is the repo: https://github.com/hashplex/Lightning
>>
>
> The routing seems to only send to one peer. What happens if that peer does
> not know the destination either? or what if you have more than one peer?
>
>
> https://github.com/hashplex/Lightning/blob/fa94a05170faa954d3f6505265d34ac97983f083/lightning.py#L99
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150812/bab6697b/attachment.html>

2023-06-09 14:43:59

- reply

📅 Original date posted:2015-08-11
📝 Original message:
Hi all,
I'm Jasper Hugunin, a developer at HashPlex. I have implemented a full
prototype Lightning node in Python and will be releasing tomorrow.
Features include:
Micropayment channels supporting unilateral close.
Basic routing support which allows payment to be routed multiple hops.
Integration tests.
MIT License.
Please be looking forward to it,
- Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150811/ad83066f/attachment.html>

2023-06-09 14:43:59

- reply

📅 Original date posted:2015-08-12
📝 Original message:
Sorry for the wait.
Here is the repo: https://github.com/hashplex/Lightning
This version is meant to be a minimal node able to send payment across
multiple hops in the network. I intend to follow Rusty's micro-payment
channel design, but revocation and HTLCs have not yet been implemented.
Routing also uses an insecure payment forwarding algorithm (since HTLCs are
missing), and does not handle channels closing. See the GitHub issue
tracker for more details.
I have attempted to split the server, the UI, the channel protocol, and the
routing protocol into separate modules so that they can be developed
independently. My hope is that someone interested in routing can work on
the routing protocol before micro-payment channels are fully secured.
I look forward to working with you all,
- Jasper
On Tue, Aug 11, 2015 at 10:58 AM, Joseph Poon <joseph at lightning.network>
wrote:
> Hi Jasper,
>
> On Tue, Aug 11, 2015 at 10:48:57AM -0700, Jasper Hugunin wrote:
> > I'm Jasper Hugunin, a developer at HashPlex. I have implemented a full
> > prototype Lightning node in Python and will be releasing tomorrow.
> >
> > Features include:
> > Micropayment channels supporting unilateral close.
> > Basic routing support which allows payment to be routed multiple hops.
> > Integration tests.
> > MIT License.
>
> Very cool, I'm looking forward to it!!
>
> --
> Joseph Poon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150812/53aab9cc/attachment.html>