Re: [Lightning-dev] Reuse of payment_hash in lightning invoices
>From Anton Kumaigorodski (not in the list till now): This already happens. Yesterday I was contacted by a user who claimed he did not receive a payment while payer was able to provide a preimage. Turns out he reused the same invoice twice which is this one: lnbc100u1pwy03lupp5q004g320cfw6y93lfrv30sxvdfppysjvuqspln6mrzwcmfxzpv5qdq823jhxaqcqzysusu5zpfyqw5qetv3w2hsug7uact0hvpten83h7r57e7tz0gu6y78qv4dwh0z2ggxylnvcjcj55fdycj2dc2h599jf3vl5q2tzr4cw7sqq98vek It's expired by now but if you try to fulfill it a routing node 02ee8c40b64c2bd14bba4a7a7a80b06065f3a683b2f02b9580be5e8bffe201beda will return a preimage right away. I can say this for sure since I've obtained user logs which show no incoming update_add_htlc while outgoing payment gets fulfilled in my wallet. This is definitely not what users would expect, I guess something should be done about it. BLW already warns users about QR reuse yet this happened anyway. Any ideas? El jue., 3 ene. 2019 a las 17:42, Andrea RASPITZU () escribió: > Okay so the knowledge of a preimage for a certain payment_hash is the > sufficient (and only) payment proof for the payer. But in any case the > reuse of payment_hashes should be strongly discouraged, in the donations > scenario 2 donors will send across the network a payment for the same > preimage and if the routes overlap (as it's likely to happen getting close > to the recipient) an intermediate routing node can effectively steal the > payment from the recipient. Shouldn't we make this clear in BOLT11? > > Cheers, Andrea. > > > > On Thu, 3 Jan 2019 at 14:13, ZmnSCPxj wrote: > >> Good morning Andrea, >> >> > For example a malicious receiver can provide an invoice with assisted >> routes where among those he/she controls a node and that node won't forward >> to the htlc but steal the funds instead (the preimage is known to the >> intermediate node as well), thus it will be claimed that the payment hasn't >> been received. If the above is correct then there should be at least a >> warning in the spec regarding the reuse of payment_hash in invoices. >> >> The fact that ultimate payer has received the payment preimage is >> considered sufficient proof of payment. >> Thus, in case of reuse, the fact that the ultimate payer has received the >> payment preimage is sufficient proof of payment, and whatever the receiver >> claims is to be ignored: the payment preimage in possession of the ultimate >> payee is considered the whole of the proof of payment. >> >> >> >a malicious receiver can provide an invoice with assisted routes where >> among those he/she controls a node and that node won't forward to the htlc >> but steal the funds instead >> >> Then the receiver has received it, not on the purported final node, but >> on another node it controls, and the fact that the ultimate payer has >> received the payment preimage is sufficient proof of that. >> >> Obviously, if the receiver knows it does not control the entire Lightning >> Network, it should not reuse payment hashes, since intermediate nodes it >> does not control could claim the payment and give the proof-of-payment to >> the ultimate payer. >> This can be clarified, but in the context of proofs, the attack you >> described is not possible, since the possession of the payment preimage is >> itself the entirety of the proof of the payment, regardless of what the >> receiver claims. >> >> Regards, >> ZmnSCPxj >> > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -- Un saludo, Josema ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Lightning and the semantic web
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
On Thu, Jan 24, 2019 at 1:21 PM Melvin Carvalho
wrote:
>
>
> On Mon, 21 Jan 2019 at 14:11, René Pickhardt
> 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": "100",
> "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"
>
Re: [Lightning-dev] Lightning and the semantic web
On Mon, 21 Jan 2019 at 14:11, René Pickhardt
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": "100",
"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
> 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@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
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
