Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-30 📝 Original message: Pierre <pm+lists at ...

📅 Original date posted:2015-08-30
📝 Original message:
Pierre <pm+lists at acinq.fr> writes:
> Thanks, this helps a lot !
>
> I have more questions after reviewing your new branch 'state', if you have
> time for that ;-)
>
> 1) In PKT_UPDATE_ADD_HTLC, why is the field amount an int32 and not an
> uint32 ? the value shouldn't be negative right ?

Indeed! Thanks, fixed (see below for patch).

> 2) For a given payee, is the (simplified) htlc flow always :
>
> A->B PKT_UPDATE_ADD_HTLC
> B->A PKT_UPDATE_COMPLETE_HTLC
> A->B PKT_UPDATE_ADD_HTLC
> B->A PKT_UPDATE_COMPLETE_HTLC ?
>
> can we have two successive PKT_UPDATE_ADD_HTLC with the same H, the latter
> updating the former ? and then a single completion ?

That's not quite right.

Adding an HTLC goes like so:

A: PKT_UPDATE_ADD_HTLC
B: PKT_UPDATE_ACCEPT (or PKT_UPDATE_DECLINE_HTLC, in which case end)
A: PKT_UPDATE_SIGNATURE
B: PKT_UPDATE_COMPLETE

There are three ways to remove it.

It has timed out, so A wants to cancel it:
A: PKT_UPDATE_TIMEDOUT_HTLC

OR, B finally gets a failure upstream, so wants to cancel it:
B: PKT_UPDATE_ROUTEFAIL_HTLC

OR, B gets the R value, and wants to compleete it:
B: PKT_UPDATE_COMPLETE_HTLC

All these cases lead to the
PKT_UPDATE_ACCEPT/PKT_UPDATE_SIGNATURE/PKT_UPDATE_COMPLETE sequence.

I will rename PKT_UPDATE_COMPLETE_HTLC to PKT_UPDATE_FULFILL_HTLC which
avoids overloading "COMPLETE".

> 3) Since an htlc is completed with a PKT_UPDATE_COMPLETE_HTLC, what is the
> use case of PKT_UPDATE ?

PKT_UPDATE is a non-htlc transfer. It was useful for writing test
utilities, but I've actually now taken it out of the state machine since
it's not useful in practice.

So all updates are now HTLC updates..

> 4) Why is there no PKT_UPDATE_DECLINE ?

See above.

> 5) I understand the High/Low priorities are a way of resolving conflicts,
> but I don't get how it works. Could you please explain the principle of it ?

Sure. The protocol can only do one update at a time. In the case where
we both propose an update, we need to decide which goes first.

Thus, each peer alternates between high and low priority states. If
you're high priority, your update takes precedence. Arbitrarily, the
anchor funder starts in high priority, the other one in low priority.

> 6) In a closing by mutual consent, who is supposed to publish the final
> transaction ?

Both sides should publish (they should be identical anyway, but it
doesn't matter).

> 7) How do we manage the fees ?

That's mainly unresolved. A node will decline if not enough fees are
offered, but how those are advertised (and how routes are advertised) is
still TBA.

We'll probably implement fixed fees and terrible routing to begin with.

Cheers,
Rusty.

Subject: protocol: HTLC amounts can't be negative.

Reported-by: Pierre <pm+lists at acinq.fr>
Signed-off-by: Rusty Russell <rusty at rustcorp.com.au>

diff --git a/lightning.pb-c.c b/lightning.pb-c.c
index b601697..3108aa5 100644
--- a/lightning.pb-c.c
+++ b/lightning.pb-c.c
@@ -1711,7 +1711,7 @@ static const ProtobufCFieldDescriptor update_add_htlc__field_descriptors[4] =
"amount",
2,
PROTOBUF_C_LABEL_REQUIRED,
- PROTOBUF_C_TYPE_INT32,
+ PROTOBUF_C_TYPE_UINT32,
0, /* quantifier_offset */
offsetof(UpdateAddHtlc, amount),
NULL,
diff --git a/lightning.pb-c.h b/lightning.pb-c.h
index 05b0a58..77a6c7b 100644
--- a/lightning.pb-c.h
+++ b/lightning.pb-c.h
@@ -278,7 +278,7 @@ struct _UpdateAddHtlc
/*
* Amount for htlc
*/
- int32_t amount;
+ uint32_t amount;
/*
* Hash for HTLC R value.
*/
diff --git a/lightning.proto b/lightning.proto
index 4388c5c..86ca52e 100644
--- a/lightning.proto
+++ b/lightning.proto
@@ -113,7 +113,7 @@ message update_add_htlc {
// Hash for which I will supply preimage to revoke this commitment tx.
required sha256_hash revocation_hash = 1;
// Amount for htlc
- required int32 amount = 2;
+ required uint32 amount = 2;
// Hash for HTLC R value.
required sha256_hash r_hash = 3;
// Time at which HTLC expires (absolute)