From rusty at rustcorp.com.au Mon Aug 31 00:34:03 2015 From: rusty at rustcorp.com.au (Rusty Russell) Date: Mon, 31 Aug 2015 10:04:03 +0930 Subject: [Lightning-dev] A state machine. In-Reply-To: References: <87si7eiehg.fsf@rustcorp.com.au> <87h9ntifwf.fsf@rustcorp.com.au> <877fopi4un.fsf@rustcorp.com.au> Message-ID: <87a8t8qosk.fsf@rustcorp.com.au> Pierre 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 Signed-off-by: Rusty Russell 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)