René Pickhardt [ARCHIVE] on Nostr: 📅 Original date posted:2019-01-28 📝 Original message: Dear Melvin, I believe ...
📅 Original date posted:2019-01-28
📝 Original message:
Dear Melvin,
I believe the scheme lightning: should only apply
* for payments in the form of bolt11 strings
* to identifiy nodes like lightning:node_id at ipaddr:port
* maybe to identify channels (look up the short_channel_id of the form of a
triple separated by the letterx. BLOCKHEIGHTxTXINDEXxOUTPUTINDEX)
the orther addresses you mentioned already have a sceme e.g. tcp:
keep in mind that the ip address and port may change but the only real
identifier is the node_id which as you mentioned correctly is the pubkey
from an HD seed and it is bech32 encoded. Also the short channel id points
to a funding transaction on the base layer so implicitly to identify the
base layer transaction we do also need the SHA-256 hash of the genesis
block otherwise it is not clear that the blockheigt, txindex, output index
triple belongs specifically to the bitcoin blockchain.
with kind regards Rene
On Mon, Jan 28, 2019 at 7:13 AM Melvin Carvalho <melvincarvalho at gmail.com>
wrote:
>
>
> On Thu, 24 Jan 2019 at 13:42, René Pickhardt <r.pickhardt at googlemail.com>
> wrote:
>
>> Dear Melvin,
>>
>> I believe the vocabulary is not consistent across implementations. For
>> example if you look at c lightning there is no such command `describegraph`
>> but there are the two commands `listnodes` and `listchannels` which should
>> give the same information. For both I have attached a sample output at the
>> end of the mail to demonstrate how the naming of the vocabulary differs.
>>
>> Since the data of these commands is taken from the gossip store which
>> stores the gossip messages I would suggest to take the vocabulary from the
>> BOLT 07 which defines the gossip messages. Also this mailinglist is for
>> protocol development and the spec should be the authorative source for
>> naming:
>> https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md
>>
>> There are more terms specified in other bolts which could be a basis for
>> a vocabulary. I have created an overview by hand and made a Pull Request to
>> the repository which has not been merged yet as it was the wish of the
>> developers to have such a list to be extracted automatically.
>> Still this the overview in that pull request could serve as a basis for
>> such a vocabulary :
>> https://github.com/lightningnetwork/lightning-rfc/pull/458
>>
>> Now the example outputs from c-lightning we already that there are
>> differences in naming. Take the identifier for a node for example:
>> * BOLT07: node_id
>> * LND: pub_key
>> * clightning: nodeid
>>
>> example outputs:
>>
>> lighting-cli listnodes
>> {
>> "nodeid":
>> "02396bf51e81f8f67eaca3652271b4fe8d3f57bedb9578af711606391c5c66760e",
>> "alias": "PuraSloboda",
>> "color": "68f442",
>> "last_timestamp": 1548200218,
>> "globalfeatures": "",
>> "global_features": "",
>> "addresses": [
>> {
>> "type": "ipv4",
>> "address": "144.136.223.22",
>> "port": 9735
>> }
>> ]
>> }
>>
>> lightning-cli listchannels
>> {
>> "source":
>> "03bb88ccc444534da7b5b64b4f7b15e1eccb18e102db0e400d4b9cfe93763aa26d",
>> "destination":
>> "0272045af48b9871013753f7cce1cf82ed80b97d669ca44709e01976a67df80adc",
>> "short_channel_id": "559893:1912:0",
>> "public": true,
>> "satoshis": 47000,
>> "message_flags": 0,
>> "channel_flags": 1,
>> "flags": 1,
>> "active": true,
>> "last_update": 1548332847,
>> "base_fee_millisatoshi": 1000,
>> "fee_per_millionth": 1,
>> "delay": 144
>> }
>>
>> With kind regards Rene
>>
>
> This is extremely helpful, thank you!
>
> I will go with the RFC naming then. I'm starting with Nodes and Edges and
> will put together a document and demo for review. First step is to do
> Nodes.
>
> I have two questions
>
> 1. node_id -- that's basically your public key -- what types of key and
> serialization is this (my guess an ecdsa pub key derived from the HD seed),
> any pointers would be great
>
> 2. regarding the four address types :
>
> - 1: ipv4; data = [4:ipv4_addr][2:port] (length 6)
> - 2: ipv6; data = [16:ipv6_addr][2:port] (length 18)
> - 3: Tor v2 onion service; data = [10:onion_addr][2:port] (length 12)
> - version 2 onion service addresses; Encodes an 80-bit, truncated
> SHA-1 hash of a 1024-bit RSA public key for the onion service
> (a.k.a. Tor hidden service).
> - 4: Tor v3 onion service; data = [35:onion_addr][2:port] (length 37)
> - version 3 (prop224
> <https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt>;)
> onion service addresses; Encodes: [32:32_byte_ed25519_pubkey] ||
> [2:checksum] || [1:version], where checksum = sha3(".onion
> checksum" | pubkey || version)[:2].
>
>
> These can be looked up in the spec. But in the semantic web we like,
> where possible, to have self describing data. In particular we like URIs
> with a scheme or protocol so instead of example.com we'll have
> http://example.com
>
> In this context would the scheme be lightning: for all 4 address types, or
> is that just for bolt11?
>
>
>
>>
>> On Thu, Jan 24, 2019 at 1:21 PM Melvin Carvalho <melvincarvalho at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Mon, 21 Jan 2019 at 14:11, René Pickhardt <r.pickhardt at googlemail.com>
>>> wrote:
>>>
>>>> Dear Melvin,
>>>>
>>>> have you looked into the W3C Payment Group?
>>>> https://www.w3.org/TR/payment-request/ The entire field of semantic
>>>> web kind of originated from W3C and they are working on a recommendation
>>>> for browser vendors to enable a low level payment API.
>>>>
>>>> Also there is LightningJoule that builds on top of webln. While this is
>>>> not an otology it goes implicitly in a similar direction (c.f.:
>>>> https://github.com/wbobeirne/webln and in particular this discussion:
>>>> https://github.com/wbobeirne/webln/issues/1 in which Will said that in
>>>> his thoughts webln is different to the W3C Payment Group.)
>>>>
>>>> I am looking forward to see your progress with integrating Lightning to
>>>> the semantic web!
>>>>
>>>> with kind regards Rene
>>>>
>>>
>>> My first observation is these two data structures in lnd describe graph,
>>> one for channels and one for nodes. These seem to be two fundamental
>>> concepts in lightning.
>>>
>>> Channel
>>>
>>> {
>>> "channel_id": "615605565348708353",
>>> "chan_point":
>>> "d8cfed73e0004fe1427d3045c5b20da0418f3cb803e8e35be48ee713aadbf56d:1",
>>> "last_update": 1548330355,
>>> "node1_pub":
>>> "024a2e265cd66066b78a788ae615acdc84b5b0dec9efac36d7ac87513015eaf6ed",
>>> "node2_pub":
>>> "03e03c56bb540c36b9e77c2aea2bb6529b907ece6c1395228c05459af13d0e2a5c",
>>> "capacity": "1000000",
>>> "node1_policy": {
>>> "time_lock_delta": 144,
>>> "min_htlc": "1000",
>>> "fee_base_msat": "1000",
>>> "fee_rate_milli_msat": "1",
>>> "disabled": false
>>> },
>>> "node2_policy": {
>>> "time_lock_delta": 144,
>>> "min_htlc": "1000",
>>> "fee_base_msat": "1000",
>>> "fee_rate_milli_msat": "1",
>>> "disabled": false
>>> }
>>> }
>>>
>>> Node
>>>
>>> {
>>> "last_update": 1547380072,
>>> "pub_key":
>>> "0200072fd301cb4a680f26d87c28b705ccd6a1d5b00f1b5efd7fe5f998f1bbb1f1",
>>> "alias": "OutaSpace",
>>> "addresses": [
>>> {
>>> "network": "tcp",
>>> "addr": "46.163.78.93:9760"
>>> },
>>> {
>>> "network": "tcp",
>>> "addr": "[2a01:488:66:1000:2ea3:4e5d:0:1]:9760"
>>> },
>>> {
>>> "network": "tcp",
>>> "addr": "2dkobxxunnjatyph.onion:9760"
>>> },
>>> {
>>> "network": "tcp",
>>> "addr":
>>> "nzslu33ecbokyn32teza2peiiiuye43ftom7jvnuhsxdbg3vhw7w3aqd.onion:9760"
>>> }
>>> ],
>>> "color": "#123456"
>>> },
>>>
>>> It would be useful to write a vocab for these and then document what
>>> they mean. It would then be possible to add markup to an explorer to make
>>> it self documenting.
>>>
>>> My first question is : are these terms consistent across different
>>> implementations e.g. c-lightning, eclair ?
>>>
>>>
>>>>
>>>>
>>>> On Mon, Jan 21, 2019 at 7:17 AM Melvin Carvalho <
>>>> melvincarvalho at gmail.com> wrote:
>>>>
>>>>> Hi All
>>>>>
>>>>> I work on the solid project [1] and am very interested in the
>>>>> lightning network.
>>>>>
>>>>> In particular, I am looking at trying to create an integration between
>>>>> lightning (layer 2) and solid (layer 3? web layer?).
>>>>>
>>>>> The first step towards integration would be to port some of the
>>>>> lightning concepts to the semantic web. This is done by creating an
>>>>> ontology.
>>>>>
>>>>> Does anyone know of any existing work in this area. Alternatively,
>>>>> does anyone have an interest to collaborate on an ontology?
>>>>>
>>>>> Best
>>>>> Melvin
>>>>>
>>>>> [1] https://solid.mit.edu/
>>>>> _______________________________________________
>>>>> Lightning-dev mailing list
>>>>> Lightning-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>>>
>>>>
>>>>
>>>> --
>>>> https://www.rene-pickhardt.de
>>>>
>>>> Skype: rene.pickhardt
>>>>
>>>> mobile: +49 (0)176 5762 3618
>>>>
>>>
>>
>> --
>> https://www.rene-pickhardt.de
>>
>> Skype: rene.pickhardt
>>
>> mobile: +49 (0)176 5762 3618
>>
>
--
https://www.rene-pickhardt.de
Skype: rene.pickhardt
mobile: +49 (0)176 5762 3618
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190128/f3c7bdb1/attachment-0001.html>;
📝 Original message:
Dear Melvin,
I believe the scheme lightning: should only apply
* for payments in the form of bolt11 strings
* to identifiy nodes like lightning:node_id at ipaddr:port
* maybe to identify channels (look up the short_channel_id of the form of a
triple separated by the letterx. BLOCKHEIGHTxTXINDEXxOUTPUTINDEX)
the orther addresses you mentioned already have a sceme e.g. tcp:
keep in mind that the ip address and port may change but the only real
identifier is the node_id which as you mentioned correctly is the pubkey
from an HD seed and it is bech32 encoded. Also the short channel id points
to a funding transaction on the base layer so implicitly to identify the
base layer transaction we do also need the SHA-256 hash of the genesis
block otherwise it is not clear that the blockheigt, txindex, output index
triple belongs specifically to the bitcoin blockchain.
with kind regards Rene
On Mon, Jan 28, 2019 at 7:13 AM Melvin Carvalho <melvincarvalho at gmail.com>
wrote:
>
>
> On Thu, 24 Jan 2019 at 13:42, René Pickhardt <r.pickhardt at googlemail.com>
> wrote:
>
>> Dear Melvin,
>>
>> I believe the vocabulary is not consistent across implementations. For
>> example if you look at c lightning there is no such command `describegraph`
>> but there are the two commands `listnodes` and `listchannels` which should
>> give the same information. For both I have attached a sample output at the
>> end of the mail to demonstrate how the naming of the vocabulary differs.
>>
>> Since the data of these commands is taken from the gossip store which
>> stores the gossip messages I would suggest to take the vocabulary from the
>> BOLT 07 which defines the gossip messages. Also this mailinglist is for
>> protocol development and the spec should be the authorative source for
>> naming:
>> https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md
>>
>> There are more terms specified in other bolts which could be a basis for
>> a vocabulary. I have created an overview by hand and made a Pull Request to
>> the repository which has not been merged yet as it was the wish of the
>> developers to have such a list to be extracted automatically.
>> Still this the overview in that pull request could serve as a basis for
>> such a vocabulary :
>> https://github.com/lightningnetwork/lightning-rfc/pull/458
>>
>> Now the example outputs from c-lightning we already that there are
>> differences in naming. Take the identifier for a node for example:
>> * BOLT07: node_id
>> * LND: pub_key
>> * clightning: nodeid
>>
>> example outputs:
>>
>> lighting-cli listnodes
>> {
>> "nodeid":
>> "02396bf51e81f8f67eaca3652271b4fe8d3f57bedb9578af711606391c5c66760e",
>> "alias": "PuraSloboda",
>> "color": "68f442",
>> "last_timestamp": 1548200218,
>> "globalfeatures": "",
>> "global_features": "",
>> "addresses": [
>> {
>> "type": "ipv4",
>> "address": "144.136.223.22",
>> "port": 9735
>> }
>> ]
>> }
>>
>> lightning-cli listchannels
>> {
>> "source":
>> "03bb88ccc444534da7b5b64b4f7b15e1eccb18e102db0e400d4b9cfe93763aa26d",
>> "destination":
>> "0272045af48b9871013753f7cce1cf82ed80b97d669ca44709e01976a67df80adc",
>> "short_channel_id": "559893:1912:0",
>> "public": true,
>> "satoshis": 47000,
>> "message_flags": 0,
>> "channel_flags": 1,
>> "flags": 1,
>> "active": true,
>> "last_update": 1548332847,
>> "base_fee_millisatoshi": 1000,
>> "fee_per_millionth": 1,
>> "delay": 144
>> }
>>
>> With kind regards Rene
>>
>
> This is extremely helpful, thank you!
>
> I will go with the RFC naming then. I'm starting with Nodes and Edges and
> will put together a document and demo for review. First step is to do
> Nodes.
>
> I have two questions
>
> 1. node_id -- that's basically your public key -- what types of key and
> serialization is this (my guess an ecdsa pub key derived from the HD seed),
> any pointers would be great
>
> 2. regarding the four address types :
>
> - 1: ipv4; data = [4:ipv4_addr][2:port] (length 6)
> - 2: ipv6; data = [16:ipv6_addr][2:port] (length 18)
> - 3: Tor v2 onion service; data = [10:onion_addr][2:port] (length 12)
> - version 2 onion service addresses; Encodes an 80-bit, truncated
> SHA-1 hash of a 1024-bit RSA public key for the onion service
> (a.k.a. Tor hidden service).
> - 4: Tor v3 onion service; data = [35:onion_addr][2:port] (length 37)
> - version 3 (prop224
> <https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt>;)
> onion service addresses; Encodes: [32:32_byte_ed25519_pubkey] ||
> [2:checksum] || [1:version], where checksum = sha3(".onion
> checksum" | pubkey || version)[:2].
>
>
> These can be looked up in the spec. But in the semantic web we like,
> where possible, to have self describing data. In particular we like URIs
> with a scheme or protocol so instead of example.com we'll have
> http://example.com
>
> In this context would the scheme be lightning: for all 4 address types, or
> is that just for bolt11?
>
>
>
>>
>> On Thu, Jan 24, 2019 at 1:21 PM Melvin Carvalho <melvincarvalho at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Mon, 21 Jan 2019 at 14:11, René Pickhardt <r.pickhardt at googlemail.com>
>>> wrote:
>>>
>>>> Dear Melvin,
>>>>
>>>> have you looked into the W3C Payment Group?
>>>> https://www.w3.org/TR/payment-request/ The entire field of semantic
>>>> web kind of originated from W3C and they are working on a recommendation
>>>> for browser vendors to enable a low level payment API.
>>>>
>>>> Also there is LightningJoule that builds on top of webln. While this is
>>>> not an otology it goes implicitly in a similar direction (c.f.:
>>>> https://github.com/wbobeirne/webln and in particular this discussion:
>>>> https://github.com/wbobeirne/webln/issues/1 in which Will said that in
>>>> his thoughts webln is different to the W3C Payment Group.)
>>>>
>>>> I am looking forward to see your progress with integrating Lightning to
>>>> the semantic web!
>>>>
>>>> with kind regards Rene
>>>>
>>>
>>> My first observation is these two data structures in lnd describe graph,
>>> one for channels and one for nodes. These seem to be two fundamental
>>> concepts in lightning.
>>>
>>> Channel
>>>
>>> {
>>> "channel_id": "615605565348708353",
>>> "chan_point":
>>> "d8cfed73e0004fe1427d3045c5b20da0418f3cb803e8e35be48ee713aadbf56d:1",
>>> "last_update": 1548330355,
>>> "node1_pub":
>>> "024a2e265cd66066b78a788ae615acdc84b5b0dec9efac36d7ac87513015eaf6ed",
>>> "node2_pub":
>>> "03e03c56bb540c36b9e77c2aea2bb6529b907ece6c1395228c05459af13d0e2a5c",
>>> "capacity": "1000000",
>>> "node1_policy": {
>>> "time_lock_delta": 144,
>>> "min_htlc": "1000",
>>> "fee_base_msat": "1000",
>>> "fee_rate_milli_msat": "1",
>>> "disabled": false
>>> },
>>> "node2_policy": {
>>> "time_lock_delta": 144,
>>> "min_htlc": "1000",
>>> "fee_base_msat": "1000",
>>> "fee_rate_milli_msat": "1",
>>> "disabled": false
>>> }
>>> }
>>>
>>> Node
>>>
>>> {
>>> "last_update": 1547380072,
>>> "pub_key":
>>> "0200072fd301cb4a680f26d87c28b705ccd6a1d5b00f1b5efd7fe5f998f1bbb1f1",
>>> "alias": "OutaSpace",
>>> "addresses": [
>>> {
>>> "network": "tcp",
>>> "addr": "46.163.78.93:9760"
>>> },
>>> {
>>> "network": "tcp",
>>> "addr": "[2a01:488:66:1000:2ea3:4e5d:0:1]:9760"
>>> },
>>> {
>>> "network": "tcp",
>>> "addr": "2dkobxxunnjatyph.onion:9760"
>>> },
>>> {
>>> "network": "tcp",
>>> "addr":
>>> "nzslu33ecbokyn32teza2peiiiuye43ftom7jvnuhsxdbg3vhw7w3aqd.onion:9760"
>>> }
>>> ],
>>> "color": "#123456"
>>> },
>>>
>>> It would be useful to write a vocab for these and then document what
>>> they mean. It would then be possible to add markup to an explorer to make
>>> it self documenting.
>>>
>>> My first question is : are these terms consistent across different
>>> implementations e.g. c-lightning, eclair ?
>>>
>>>
>>>>
>>>>
>>>> On Mon, Jan 21, 2019 at 7:17 AM Melvin Carvalho <
>>>> melvincarvalho at gmail.com> wrote:
>>>>
>>>>> Hi All
>>>>>
>>>>> I work on the solid project [1] and am very interested in the
>>>>> lightning network.
>>>>>
>>>>> In particular, I am looking at trying to create an integration between
>>>>> lightning (layer 2) and solid (layer 3? web layer?).
>>>>>
>>>>> The first step towards integration would be to port some of the
>>>>> lightning concepts to the semantic web. This is done by creating an
>>>>> ontology.
>>>>>
>>>>> Does anyone know of any existing work in this area. Alternatively,
>>>>> does anyone have an interest to collaborate on an ontology?
>>>>>
>>>>> Best
>>>>> Melvin
>>>>>
>>>>> [1] https://solid.mit.edu/
>>>>> _______________________________________________
>>>>> Lightning-dev mailing list
>>>>> Lightning-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>>>
>>>>
>>>>
>>>> --
>>>> https://www.rene-pickhardt.de
>>>>
>>>> Skype: rene.pickhardt
>>>>
>>>> mobile: +49 (0)176 5762 3618
>>>>
>>>
>>
>> --
>> https://www.rene-pickhardt.de
>>
>> Skype: rene.pickhardt
>>
>> mobile: +49 (0)176 5762 3618
>>
>
--
https://www.rene-pickhardt.de
Skype: rene.pickhardt
mobile: +49 (0)176 5762 3618
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190128/f3c7bdb1/attachment-0001.html>;