{"type":"rich","version":"1.0","author_name":"npub1r375vdaydp5nnnytff6ee2kwzxak8whmwkmnkm6h67agr7dadfkqxn6ccq","author_url":"https://nostr.ae/npub1r375vdaydp5nnnytff6ee2kwzxak8whmwkmnkm6h67agr7dadfkqxn6ccq","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-03-10\n📝 Original message:\nHello Corné,\n\nI'm glad to see that someone getting this kind of idea started.\n\nI'm still new to some of these topics, but I have a few comments.\nHopefully I'm not wasting your time if they are too rudimentary!\n\n 1. You mention that the payee gives a URL where the payer can then\n    connect to to request invoices. You mention that this can be a tor\n    hidden service if the payee needs to remain private. You also\n    suggest that the payee can remain private by \"payee can send an\n    invoice to payer which has a partial onion route as destination\n    instead of a node ID\". I was reading about tor hidden services\n    (https://www.torproject.org/docs/onion-services.html.en), and they\n    require an introduction point, and a rendezvous point. Do we not\n    need this two step process for the payment route, because we already\n    have communication initiated over the anonymous communication\n    channel, and the beginning of the partial onion route is not\n    publicly available information, and can change with every invoice?\n 2. What happens if the capacity of the partial onion route is no longer\n    sufficient when the payer is ready to pay? Is there a way to provide\n    a few routes just in case? Or, in the case where no amount is\n    specified, how is the partial onion route possible if we don't even\n    know how much capacity may be needed?\n 3. You say the refund should invalidate the proof of payment of the\n    initial transaction. What about partial refunds? I think there are a\n    lot of applications where there would be a partial refund.\n 4. You say \"this BOLT specifies a protocol where payee gives a URL to\n    one or more potential payers\". How does the payer identify itself to\n    the payee so that the payee knows what goods or services that they\n    want an invoice for? Do they send this after making the connection,\n    or is it part of the URL?\n\n\n\n\nAndy Schroder\n\nOn 03/08/2018 10:19 AM, Corné Plooy via Lightning-dev wrote:\n\u003e Hi,\n\u003e\n\u003e I was thinking of how to use Lightning for various types of payments,\n\u003e and I think it's currently fine for customer/(web)shop type\n\u003e interactions, but it seems a bit inconvenient for other use cases, e.g.\n\u003e salary payments or direct pay-out of cryptocurrency bought on an\n\u003e exchange. I came up with an idea that addresses some of these issues and\n\u003e more (e.g. payee anonymity) by having a direct line of communication\n\u003e between payer and payee instead of BOLT11-style interaction. It's still\n\u003e a bit half-baked, with many details not worked out yet, but you can read\n\u003e it here, and see if you like where this is going:\n\u003e\n\u003e\n\u003e https://github.com/bitonic-cjp/lightning-rfc/blob/payment-protocol/12-payment-protocol.md\n\u003e\n\u003e\n\u003e In true permissionless fashion, I have been so bolD to register bolT #12\n\u003e for my idea.\n\u003e\n\u003e\n\u003e Please let me know what you think.\n\u003e\n\u003e kind regards,\n\u003e\n\u003e CJP\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\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180310/b0f5979c/attachment.html\u003e"}