Published on: 2017-11-07T22:21:41+00:00
Cezary Dziemian, a Bitcoin ATM builder from Poland, expressed gratitude for the response to his previous inquiry. He mentioned that the Lightning Network (LN) is believed to be the next big thing in Poland with a huge pro-LN community and translated LN whitepaper to Polish. Cezary asked if it would be possible for a payer to make two payments based on the same invoice under a particular scenario.Rusty Russell, a developer of the Lightning Network, responded that this scenario would not be possible because the payer's wallet would refuse to make two payments to the same payment_hash until one has failed. Rusty advised Cezary to ask the merchant for another invoice instead of trying to make another payment using the same invoice.The email thread discusses various aspects of Lightning Network implementation and usage. The initial email talks about Bitcoin ATMs being built in Poland and the plan to use Lightning Network (LN). The email also mentions a strong pro-LN community in Poland and the availability of a translated version of the LN whitepaper in Polish.The following emails discuss specific scenarios related to LN usage. One scenario involves two hubs belonging to the same person attempting to cheat by not updating HTLC contract to the Merchant, resulting in a "pending" payment. Another scenario discusses the issue of users not knowing whether the other party uses LN or on-chain payment, and the possibility of including both public address and LN invoice in a QR code. The third scenario talks about the decremental time lock and its relation to block confirmation time and the potential solution for unreliable payments.The email thread also includes responses from Rusty Russell and Johan Torås Halseth. Rusty Russell suggests that the transition to LN can be painful, but BOLT 11 QR codes with fallback addresses can be used. He also suggests that if a payment fails, the user can wait or try again with a new invoice. For 1.1, the same invoice can be safely reused as long as the merchant was honest in rejecting the second payment. Johan Torås Halseth suggests adding a lightning parameter to the bitcoin URL to make QR codes backwards compatible. The margin required for turning around payments in LN is also discussed.A user named Johan suggested adding a lightning parameter to the bitcoin: url to make QR codes backwards compatible. Cezary Dziemian asked Rusty Russell questions regarding the use of Lightning Network (LN) and its transition from on-chain payments. Rusty replied that a BOLT 11 QR code can contain a fallback address, but it still requires the app to understand BOLT11 enough to extract it. The BIP70 payment protocol could include an alternate payment mechanism, but it seems nobody actually uses this. Rusty also explained the two worst case scenarios for LN payments - one where the payment fails, and the other where it has succeeded but the payer doesn't know yet. If the latter happens, the payer will get their goods and won't care about waiting for the money to be deducted. If the payment fails, the payer can either wait or try again with a new invoice. Finally, Rusty stated that although the decremental time lock is somewhat related to block confirmation time, if payments are so unreliable that this case needs to be worried about, then something is horribly wrong.The email exchange between Cezary Dziemian and Rusty explains the difficulties faced with the Lightning Network (LN) in terms of payments. Cezary raises concerns regarding how to verify if a user is using LN or not when making a payment, since it is difficult to ask every user about their payment preference. Rusty suggests using a BOLT 11 QR code with a fallback address or the BIP70 payment protocol with an alternate payment mechanism. In response to Cezary's second question, Rusty acknowledges that there may be cases where a payment might fail due to a non-cooperative party in the middle, but assures him that it is rare. He suggests that if the payment has succeeded, then the recipient will receive the goods regardless of the delay. On the other hand, if it fails, the payer can wait or try again with a new invoice, but cannot pay the same one twice unless it definitely failed.Cezary also queries whether the decremental time lock on the network is related to block confirmation time and whether having a currency with a faster confirmation rate would solve the problem described in his second question. Rusty responds that while there is some relationship between the two, a fast confirmation time does not necessarily mean a short time lock period.Cezary Dziemian, a fan of Lightning Network (LN) technology for over a year, has some questions regarding its functionality. Firstly, he wonders how to receive payments using LN if some users prefer on-chain payments instead. He suggests showing the buyer a QR code containing both public address and LN invoice so that their wallet can choose how to pay.
Updated on: 2023-07-31T19:24:56.890637+00:00