Clarify that type is not unique

[ysangkok]

Clarify that type is not unique

[cdecker]

Yes, they are used in different contexts: one is a wire message and the other one is an error message wrapped in an error reply. I think it shouldn't be a huge problem and honestly I wouldn't know where to specify these potential collisions.

[ysangkok]

Okay, I understand. Thanks

[cdecker]

Sorry, didn't want to sound discouraging :-) Do you know a good place to add this clarification. The onion routing spec in the introduction of errors seems like the best place.

[ysangkok]

Yeah that would make sense. But now that you explained it , it makes a lot of sense. I hadn't looked at the onion protocol because it is not relevant to our use in Electrum , so I just assumed the output of the protocol message extractor meant it was invalid. I don't think a change is strictly necessary.

…

On Jul 8, 2017 10:29, "Christian Decker" ***@***.***> wrote: Sorry, didn't want to sound discouraging :-) Do you know a good place to add this clarification. The onion routing spec in the introduction of errors seems like the best place. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#202 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AARVd2Gm2tz0o0Xj7kDU1QhCxH_TQe6rks5sLz39gaJpZM4ORRAH> .

[cdecker]

No no, you certainly have a point, I'll create a PR with the clarification. Just wondering: are you integrating LN with Electrum?

[ysangkok]

Yes, I am working on exactly that. 😄 There is most likely going to be an Electrum Lightning server that connects to the rest of the network, and the user could initially only use the Electrum Lightning servers, they would of course provide HTLC's and be relatively well connected.

[cdecker]

Great, looking forward to testing your implementation. I tried to address the clarification issue in #207, does that sound reasonable?

[ysangkok]

Yes, sounds good.