Published on: 2018-11-05T06:44:07+00:00
The email thread discusses various technical aspects of payments made through the Lightning Network. The participants explore different methods of proving payment and delivering goods in exchange. They discuss the use of private and public keys, as well as the verification of payments through signed statements. The topic of using revocable invoices for purchases is also raised.In a separate discussion, Anthony Towns expresses his skepticism about using Reddit as a reliable platform for dispute resolution. He argues that there is no intermediary to verify disputes, making it difficult to determine who is right in a conflict. However, Rusty counters this by stating that platforms like Reddit and Twitter can serve as starting points for thinking about receipts when no intermediary is involved. He discusses four types of "proof of payment" that people might desire, ranging from no proof to third-party verifiable receipts.Rusty Russell engages in an email conversation where he suggests potential improvements to the Lightning Network protocol. The topics covered include sending multiple payments with the same hash, partial payment theft, secp256k1 AMP, and the implementation of HORNET. He also proposes a BOLT 11 v1.1 "offer" that includes a URL for users to enter personal information for orders. Additionally, he suggests including crypto keys in the invoice for on-chain fallback payments.Another discussion on the Lightning-dev mailing list raises concerns about the uniqueness of identification required to verify payments in Bitcoin. The issue of sock puppetry and fraudulent claims is addressed. The participants discuss the technicalities of proving payment and propose interactive proofs and signatures as solutions. The need for a PKI infrastructure for mapping pubkeys to real-world identities is also mentioned.In another conversation, ZmnSCPxj suggests including a signature for a key only known to the payer in order to prove payment. The discussion revolves around the necessity of such a signature and the technical details of proving payment. The challenges of identifying the payer and preventing fraudulent claims are also addressed.The conversation between ZmnSCPxj, Rusty, and aj focuses on the topic of channel announcements and the use of secp256k1 for hashes. The participants discuss a hypothetical scenario where a payment is made through multiple channels with different schemes. They explore the possibilities of integrating secp256k1 and sha256 in payment routes.Rusty Russell and Jonas Nick discuss a proposed scheme for Schnorr signatures in Lightning Network. They delve into the technicalities and challenges of implementing recurrent payments and Atomic Multi-Path Payments (AMP). The conversation also touches upon the verification of proof-of-payment and future features that may require interaction messages.Rusty Russell highlights the benefits and drawbacks of various methods for sending payments through Lightning Network. He discusses payment splitting and joining, proof-of-payment, privacy improvement through decorrelation, and the inclusion of URLs in offers. He also raises concerns about complicated AMP schemes without decorrelation.Anthony Towns proposes adding support for using secp256k1 public/private keys for payment hashes/preimages in v1.1 of the lightning spec. The conversation explores the technical requirements and implications of this proposal. The topics of channel announcements and generating multiple nonces are also discussed.In a channel announcement thread, the question arises regarding the support of secp256k1 for hashes. The possibility of alternating between 2p-ECDSA and Schnorr contingent payment schemes in payment routes is explored.Rusty Russell discusses the future flow of lightning payments, suggesting experimental support for secp256k1 public/private keys in the Lightning Network specification. He outlines the components required for this implementation and emphasizes its importance for payment decorrelation, AMP, and third-party verifiable proof-of-payment. Russell also touches upon Atomic Multi-Path Payments (AMP) and its benefits.The Lightning Network community is currently discussing the future payment flow for lightning. Rusty Russell, a Linux kernel developer and one of the original developers of Bitcoin's Lightning Network, has proposed using secp256k1 public/private keys for payment hashes/preimages in version 1.1 of the Lightning specification. This experimental/optional feature aims to enable payment decorrelation, AMP (Atomic Multi-Path) payments, and third-party verifiable proof-of-payment.Russell argues that invoices should be able to be paid multiple times by different individuals, allowing for scenarios like donation invoices or monthly invoices. To achieve this, he suggests that invoices should contain enough information to link them to the payer. He also introduces the concept of scriptless scripts as a possible solution to this issue. In this approach, an HTLC (Hash Time-Locked Contract) signature would commit to the invoice/payment hash as well as "something I sent to you in the payment onion." The protocol would define this "something" to ensure that merchants can parse and understand the conditions it presents before accepting the payment.Furthermore, Russell proposes a hypothetical example involving Alice selling a t-shirt to Bob. He suggests that Alice should provide Bob with a receipt signed with her public key using a Schnorr signature.
Updated on: 2023-07-31T20:38:06.842556+00:00