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