Re: [Lightning-dev] DataSig -- Data signatures over Lightning

[Azz via Lightning-dev]

I have to agree with John on this. Just ignoring previous discussions and thoughts about using LN as a transport layer (it’s not) isn’t helpful. The transport layer is one of the most, if not the most critical layer on the internet and putting everything inside the LN isn’t what it was designed to do. It would serve no actual purpose compared to other transmission means. AsteriaValera Labs




publicKey - asteria@valera.sh - 69152307.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] DataSig -- Data signatures over Lightning

[George Tsagkarelis]

Hi John,

Main reason is the fact that I can just message a node without requiring
other pieces of technology attached to my Lightning node. Our goal is not
to pair the payment to some data, but get some data from node A to node B.
The fact that payments and data in this approach are always paired is a
sweet bonus. Keep in mind that every time I message a node I'm actually
sending a min-value payment towards the destination, rewarding the routing
nodes with the base fee of the channels I used. The routing nodes don't
know if I'm messaging or not, and will keep forwarding my "min-value
payments" because I'm compensating them for that. Even if they assume that
a payment is carrying a message, they still won't be able to figure out
what the message is or who is sending/receiving it.

In DataStruct spec we describe a structure that can support data
fragmentation, but we do not in any case encourage content streaming over
LN. We are not planning to "put the whole Internet & web" inside of
Lightning. If you want to stream media or download files you SHOULD choose
an out-of-band solution. We focus on small footprint data that will
eventually utilize a handful of HTLCs to reach their destination, which is
not harmful for LN.

We are also not against pairing LN with the HTTP world, technologies like
LSAT/LNURL have valid use cases. There is a big number of
applications/services that would benefit by directly connecting to your
node and have the ability to also communicate with other nodes, not only
pay them. I guess the answer to "why" is just the fact that its more
simple, secure and private compared to out-of-band hybrid solutions, but
comes with a cost in sats. At the end of the day it is the developers and
users the ones that will decide what solution best fits their needs.




On Fri, Jun 17, 2022 at 10:20 AM John Carvalho  wrote:

> The scope of these specs is transmitting data over the Lightning
>> Network (over HTLC custom records). This is a use-case already used
>> by a few projects ([1], [2], [3], [4]), and in this context
>> we do not intend to debate the validity of it.
>
>
> You can't just handwave away whether something is up for debate because a
> few people did some proofs-of-concept that pretty much no one actually uses.
>
> The main question here is "why?!" Why shoehorn data transmissions into LN
> when you could pair LN payments with any other transmission method?
>
> You could gate downloads, and permissions in packets totally out of band
> from the payments. The files could be torrents or any format that is
> better-suited for the task. As an example, look at Dazaar tools:
> https://github.com/bitfinexcom?q=dazaar-l=all
>
> We don't need to put the whole internet & web inside of Lightning.
> Lightning is for payments. If you try to use it for broad communication use
> cases, you end up crippling both the use case and LN.
>
> --
> John Carvalho
> CEO, Synonym.to 
>
>
> On Thu, Jun 16, 2022 at 4:48 PM <
> lightning-dev-requ...@lists.linuxfoundation.org> wrote:
>
>>
>> Date: Thu, 16 Jun 2022 18:36:28 +0300
>> From: George Tsagkarelis 
>> To: lightning-dev@lists.linuxfoundation.org
>> Subject: [Lightning-dev] DataSig -- Data signatures over Lightning
>> Message-ID:
>> <
>> cacrhu9irxqefllddtwzg93qsaznypjp71o9w24b1lxvkzna...@mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> # DataSig -- Data signatures over Lightning
>>
>> ## Introduction
>>
>> Greetings, Lightning devs
>>
>> This mail serves as an introduction to one of the two specs
>> that we want to propose to the community.
>> The scope of these specs is transmitting data over the Lightning
>> Network (over HTLC custom records). This is a use-case already used
>> by a few projects ([1], [2], [3], [4]), and in this context
>> we do not intend to debate the validity of it.
>>
>> As mentioned, DataSig is one of the two specs we aim in proposing:
>>   * DataSig: Concerns the authentication of some data with regards to
>> the source and destination of the transmission.
>>   * DataStruct: Concerns the outer layer of the data structure,
>> mainly focusing on the data fragmentation aspect of transmission.
>>
>> We seek feedback on the two specs as we want to improve and tweak
>> them before proceeding with a BLIP proposal.
>>
>> ## DataSig
>>
>> This spec's aim is to describe the format of a structure representing
>> a signature over some arbitrary data.
>>
>> Before proceeding, a few clarifications must be made:
>>   * The DataSig structure is placed inside a custom TLV record
>>   * DataSig allows the receiving end validate that:
>> * Data were authored by the source node
>> * Data were meant to be received by the receiving node.
>>
>> The main scope of DataSig is assisting with data verification
>> independently of what medium one chooses for data transmission.
>> Nevertheless, for simplicity, in the follow-up DataStruct spec
>> we assume the data to be transmitted over custom TLV 

Re: [Lightning-dev] DataSig -- Data signatures over Lightning

[John Carvalho]

>
> The scope of these specs is transmitting data over the Lightning
> Network (over HTLC custom records). This is a use-case already used
> by a few projects ([1], [2], [3], [4]), and in this context
> we do not intend to debate the validity of it.


You can't just handwave away whether something is up for debate because a
few people did some proofs-of-concept that pretty much no one actually uses.

The main question here is "why?!" Why shoehorn data transmissions into LN
when you could pair LN payments with any other transmission method?

You could gate downloads, and permissions in packets totally out of band
from the payments. The files could be torrents or any format that is
better-suited for the task. As an example, look at Dazaar tools:
https://github.com/bitfinexcom?q=dazaar-l=all

We don't need to put the whole internet & web inside of Lightning.
Lightning is for payments. If you try to use it for broad communication use
cases, you end up crippling both the use case and LN.

--
John Carvalho
CEO, Synonym.to 


On Thu, Jun 16, 2022 at 4:48 PM <
lightning-dev-requ...@lists.linuxfoundation.org> wrote:

>
> Date: Thu, 16 Jun 2022 18:36:28 +0300
> From: George Tsagkarelis 
> To: lightning-dev@lists.linuxfoundation.org
> Subject: [Lightning-dev] DataSig -- Data signatures over Lightning
> Message-ID:
> <
> cacrhu9irxqefllddtwzg93qsaznypjp71o9w24b1lxvkzna...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> # DataSig -- Data signatures over Lightning
>
> ## Introduction
>
> Greetings, Lightning devs
>
> This mail serves as an introduction to one of the two specs
> that we want to propose to the community.
> The scope of these specs is transmitting data over the Lightning
> Network (over HTLC custom records). This is a use-case already used
> by a few projects ([1], [2], [3], [4]), and in this context
> we do not intend to debate the validity of it.
>
> As mentioned, DataSig is one of the two specs we aim in proposing:
>   * DataSig: Concerns the authentication of some data with regards to
> the source and destination of the transmission.
>   * DataStruct: Concerns the outer layer of the data structure,
> mainly focusing on the data fragmentation aspect of transmission.
>
> We seek feedback on the two specs as we want to improve and tweak
> them before proceeding with a BLIP proposal.
>
> ## DataSig
>
> This spec's aim is to describe the format of a structure representing
> a signature over some arbitrary data.
>
> Before proceeding, a few clarifications must be made:
>   * The DataSig structure is placed inside a custom TLV record
>   * DataSig allows the receiving end validate that:
> * Data were authored by the source node
> * Data were meant to be received by the receiving node.
>
> The main scope of DataSig is assisting with data verification
> independently of what medium one chooses for data transmission.
> Nevertheless, for simplicity, in the follow-up DataStruct spec
> we assume the data to be transmitted over custom TLV records as well.
>
> We consider a compact encoding to be used for representing the
> DataSig structure over a TLV, so it is expressed as the following
> protobuf message:
>
> ```protobuf
> message DataSig {
>   uint32 version = 1;
>   bytes sig  = 2;
>   bytes senderPK = 3;
> }
> ```
>
> * `version`: The version of DataSig spec used.
> * `sig`: The bytes of the signature.
> * `senderPK`: The sender's public key.
>
> ### Generation
>
> In order to instantiate a DataSig signing the data `D`, one needs
> to follow these steps:
>
> 1. Populate `version` with the version that is going to be used.
> 2. Prepend the desired destination address (`A`) to `D`,
>creating a new byte array (`AD`).
> 3. Sign the byte array `AD`, generating a signature encoded in
>fixed-size LN wire format.
> 4. Populate the `sig` field with the generated signature.
> 5. Populate `senderPK` with own address.
> 6. Encode the resulting DataSig structure to wire format
>(byte array `S`).
>
> ### Verification
>
> Assuming that the destination node has retrieved:
>   * The byte array of the data `D`
>   * The byte array of the encoded signature struct `S`
>
> The data should be verified against the signature
> by following the below procedure:
>
> 1. Decode bytes `S` according to DataSig protobuf message definition.
> 2. If signature `version` is not supported or unknown, consider data
>to be unsigned.
> 3. Prepend own address (`A`) to byte array `D`, generating the byte
>array `AD`.
> 4. Verify the signature provided in `sig` field against the message
>`AD` and sender public key `senderPK`.
>
> ### Notes / Remarks
>
> * The scope of this spec is to deal with the verification
>   of the author and intended recipient of transmitted data.
>   We do not intend to solve the issue of associating a DataSig
>   to the corresponding data (signed by it), in case they are
>   not transmitted in pairs.
>   For now, we assume that data and