Data piggybacking within the payment_preimage for offline payments in wallets



Summary:

The conversation revolves around a proposal for transmitting information encoded within the preimage, so that it is only revealed after payment. One use case proposed is "pay to pay" where Alice wants to pay Bob some sizable amount onchain, but Bob gives Alice a tiny LN invoice and piggybacks his onchain address for Alice to pay him, upon payment of the LN invoice, Alice decrypts Bob's address. The conversation also discusses the best solution between two proposals with each having its own advantages and disadvantages. While one proposal allows for an initial configuration of the machine with the shared secret for an unlimited series of payments, the second proposal requires a standard wallet and allows for devices that have intermittent connectivity. However, the biggest drawback to the second scheme is the logistics needed for replenishing the hashes into offline vending machines. The conversation also touches on other issues such as price changes, static QR codes, privacy, and security. There are concerns about the vulnerability of both systems to hacking, especially with physical access to the machine. In conclusion, the discussion highlights the importance of having standards to increase usability and mentions Rusty's proposal for static offers.


Updated on: 2023-06-02T15:58:11.809433+00:00