Corné Plooy [ARCHIVE] on Nostr: 📅 Original date posted:2018-04-05 📝 Original message: If there are censorship ...
📅 Original date posted:2018-04-05
📝 Original message:
If there are censorship concerns, you could opt for a set-up where payer
has an authenticated connection to a trusted server, through the
Internet connection provided by payee. The trusted server can, for
instance, be a full Lightning node running at the payer's home.
The payer then only has to take a very light piece of electronics with
him/her. It will still be larger than a credit card (since
authentication should be done payer-side, e.g. with a PIN code), but it
can be smaller than a smart phone. Personally, I like this kind of
set-up, because I see cell phones as a huge privacy issue (you're
continuously transmitting your rough location to the network).
Why would there need to be a direct channel between payer and payee? We
have the Lightning network to avoid needing direct channels, right?
CJP
Op 05-04-18 om 17:39 schreef ZmnSCPxj via Lightning-dev:
> Good morning Igor,
>
> This is quite an interesting use-case for Lightning.
>
> However it seems to me that the payer will need a direct channel to
> the payee, or at least the payment terminal (of the payee...?).
>
> In addition the payer will need to somehow get blockchain information
> from the payee if the payer itself has no Internet. The payee may
> have an incentive to prevent the payer from knowing that timeouts have
> been reached, for example, and may withhold new blocks (although all
> censorship attacks I know of that could be used on LN target the payee
> and not the payer).
>
> Is my understanding correct?
>
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail <https://protonmail.com>; Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On April 5, 2018 5:46 PM, Igor Cota <igor at codexapertus.com> wrote:
>
>> Hello all,
>>
>> I feel that one of the biggest promises of lightning lies in it being
>> used for everyday retail payments.
>>
>> I'd like to see a system that's:
>> 1) instantaneous like the contactless bank cards of today
>> 2) encodes a fancy HTML receipt in bolt11 for the payers future reference
>>
>> QR codes are a bit unwieldy and even more so if you want a nice HTML
>> table description of your grocery shopping with hundreds of items -
>> this relatively large amount of data makes them impractical to scan.
>>
>> To this end I've been running an instance of c-lightning on Android
>> [1][2][3] and experimenting with payments via NFC. I set up a machine
>> with an NFC USB dongle that acts as an point-of-sale terminal [4]. So
>> far so good!
>>
>> There are two basic ways you can use NFC enabled phones today - as
>> passive tag readers or in card emulation mode (not sure if the latter
>> is available on iOS).
>>
>> Passive tags are really simple and encoding bolt11 to them works as
>> expected. If you set the right MIME type Android will open whatever
>> app is registered to handle lightning and you can either pay
>> instantaneously or after user confirmation. Works great provided both
>> the phone and terminal are connected to the network and have a route
>> to each other.
>>
>> Card emulation mode is more interesting because it enables us to have
>> two way communication and therefore an ad hoc connection to the
>> lightning network. After some handshaking, phone can tell the
>> terminal that it wants to connect to lightning via NFC. All
>> communication between these two lightning nodes can be done over NFC
>> or even bluetooth [5]. This might be useful as fallback in situations
>> where mobile data is not available.
>>
>> I settled on a MIME type (application/lightning) and an NFC
>> application id (LIGHTNING). There is also a very simple protocol to
>> forward socket data. For the sake of interoperability it would be
>> great if we agreed on some standards but I'm not sure how to proceed
>> with this. Should these be part of a future BOLT or is mailing list
>> banter enough?
>>
>> I look forward to your views!
>>
>> Cheers,
>> Igor
>>
>>
>> [1]
>> https://github.com/ElementsProject/lightning/commit/bd95aba7a5f9bad8f447bf3de8f7e8cfe83751af
>> [2]
>> https://github.com/ElementsProject/lightning/commit/d4d1c4acb08efb6be4f491cdee5cb6dd4b84ddf7
>> [3]
>> https://github.com/ElementsProject/lightning/commit/bd95aba7a5f9bad8f447bf3de8f7e8cfe83751af
>> [4] https://github.com/icota/presto
>> [5] https://github.com/ElementsProject/lightning/pull/1323
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
📝 Original message:
If there are censorship concerns, you could opt for a set-up where payer
has an authenticated connection to a trusted server, through the
Internet connection provided by payee. The trusted server can, for
instance, be a full Lightning node running at the payer's home.
The payer then only has to take a very light piece of electronics with
him/her. It will still be larger than a credit card (since
authentication should be done payer-side, e.g. with a PIN code), but it
can be smaller than a smart phone. Personally, I like this kind of
set-up, because I see cell phones as a huge privacy issue (you're
continuously transmitting your rough location to the network).
Why would there need to be a direct channel between payer and payee? We
have the Lightning network to avoid needing direct channels, right?
CJP
Op 05-04-18 om 17:39 schreef ZmnSCPxj via Lightning-dev:
> Good morning Igor,
>
> This is quite an interesting use-case for Lightning.
>
> However it seems to me that the payer will need a direct channel to
> the payee, or at least the payment terminal (of the payee...?).
>
> In addition the payer will need to somehow get blockchain information
> from the payee if the payer itself has no Internet. The payee may
> have an incentive to prevent the payer from knowing that timeouts have
> been reached, for example, and may withhold new blocks (although all
> censorship attacks I know of that could be used on LN target the payee
> and not the payer).
>
> Is my understanding correct?
>
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail <https://protonmail.com>; Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On April 5, 2018 5:46 PM, Igor Cota <igor at codexapertus.com> wrote:
>
>> Hello all,
>>
>> I feel that one of the biggest promises of lightning lies in it being
>> used for everyday retail payments.
>>
>> I'd like to see a system that's:
>> 1) instantaneous like the contactless bank cards of today
>> 2) encodes a fancy HTML receipt in bolt11 for the payers future reference
>>
>> QR codes are a bit unwieldy and even more so if you want a nice HTML
>> table description of your grocery shopping with hundreds of items -
>> this relatively large amount of data makes them impractical to scan.
>>
>> To this end I've been running an instance of c-lightning on Android
>> [1][2][3] and experimenting with payments via NFC. I set up a machine
>> with an NFC USB dongle that acts as an point-of-sale terminal [4]. So
>> far so good!
>>
>> There are two basic ways you can use NFC enabled phones today - as
>> passive tag readers or in card emulation mode (not sure if the latter
>> is available on iOS).
>>
>> Passive tags are really simple and encoding bolt11 to them works as
>> expected. If you set the right MIME type Android will open whatever
>> app is registered to handle lightning and you can either pay
>> instantaneously or after user confirmation. Works great provided both
>> the phone and terminal are connected to the network and have a route
>> to each other.
>>
>> Card emulation mode is more interesting because it enables us to have
>> two way communication and therefore an ad hoc connection to the
>> lightning network. After some handshaking, phone can tell the
>> terminal that it wants to connect to lightning via NFC. All
>> communication between these two lightning nodes can be done over NFC
>> or even bluetooth [5]. This might be useful as fallback in situations
>> where mobile data is not available.
>>
>> I settled on a MIME type (application/lightning) and an NFC
>> application id (LIGHTNING). There is also a very simple protocol to
>> forward socket data. For the sake of interoperability it would be
>> great if we agreed on some standards but I'm not sure how to proceed
>> with this. Should these be part of a future BOLT or is mailing list
>> banter enough?
>>
>> I look forward to your views!
>>
>> Cheers,
>> Igor
>>
>>
>> [1]
>> https://github.com/ElementsProject/lightning/commit/bd95aba7a5f9bad8f447bf3de8f7e8cfe83751af
>> [2]
>> https://github.com/ElementsProject/lightning/commit/d4d1c4acb08efb6be4f491cdee5cb6dd4b84ddf7
>> [3]
>> https://github.com/ElementsProject/lightning/commit/bd95aba7a5f9bad8f447bf3de8f7e8cfe83751af
>> [4] https://github.com/icota/presto
>> [5] https://github.com/ElementsProject/lightning/pull/1323
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev