Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make sending a bolt12 offer a standardized part of fetchinvoice #1203

Open
hMsats opened this issue Oct 9, 2024 · 4 comments
Open

Make sending a bolt12 offer a standardized part of fetchinvoice #1203

hMsats opened this issue Oct 9, 2024 · 4 comments

Comments

@hMsats
Copy link

hMsats commented Oct 9, 2024

Allow any lightning wallet to include an offer in a standardized manner when paying a bolt11 invoice.

Let me give 2 examples where this is (very) useful.

A family goes on vacation to some country and rents an apartment for a week. The rent for that week will be $1000 but there is an obligatory deposit of $300 to cover the risk of damage during their stay. They book the apartment via a website, the website generates the bolt11 qr-code for $1300 and they pay it with their lightning wallet and the payment also includes the/an offer of that wallet. Now if they don't damage anything during their stay, the owner can pay back the $300 or less if there was some minor damage like breaking a cup. Since the wallet automatically included the offer, the family didn't had to insert any extra (complicated) information for the payback.

You play a lightning game where you can win some money, like my own game where you have to guess if the price of bitcoin will be higher of lower after a certain amount of time. Playing the game would go as follows:

  1. The player inserts 50 sats and clicks a button that the bitcoin price will be higher 24 hours from now.
  2. The game generates a qr-code for 52 sats (2 sats gaming fee included)
  3. The player pays the qr-code with his wallet (also sending his offer)
  4. It the bitcoin price is indeed higher after 24 hours, the player gets double the amount paid
  5. The game returns 100 sats to the player

Note that no registration was necessary to play the game, which always makes trying out a (lightning) game a bit annoying.

@t-bast
Copy link
Collaborator

t-bast commented Oct 9, 2024

I don't understand why you'd like to mix Bolt 11 and Bolt 12 (and this most likely won't be implemented)? You can do all of this using Bolt 12 only and the refund flow? This is already specified in https://github.com/lightning/bolts/blob/master/12-offer-encoding.md#payment-flow-scenarios (see the "merchant-pays-user-flow"), doesn't that work for you?

@hMsats
Copy link
Author

hMsats commented Oct 9, 2024

Thanks for the reply. Yes, this might be what I was looking for but I don't have the time at the moment. Closing this issue for now.

I will look into this later and thanks again!

@hMsats hMsats closed this as completed Oct 9, 2024
@hMsats hMsats changed the title Make returning a bolt12 offer a standardized part of a bolt11 payment Make returning a bolt12 offer a standardized part of fetchinvoice Oct 11, 2024
@hMsats
Copy link
Author

hMsats commented Oct 11, 2024

As it is difficult to explain what I mean, I've written a bash shell lightning "game" (100% bolt12) that works between my CLN node (node 1, game) and CLN test node (node 2, player's wallet). The player always wins, only has to pay and never has to register :-)

Here:

cli1=/home/user/lightning/cli/lightning-cli --lightning-dir=/media/ssd/.lightning $*

cli2=/home/user/lightning_test/cli/lightning-cli --lightning-dir=/media/ssd/.lightning_test $*

#!/bin/bash

# AT GAME node
# Create a unique player id
  labelnumber=$(date "+%s") # like a random number
  label=a$labelnumber
  playerid=player$label
# Create a payment qr code for 21 sats
  node_1_offer=$(./cli1 offer amount=21sat description=$playerid label=$label single_use=true | jq '.bolt12' )
# Show qr code of the offer to player

# AT PLAYER wallet
# The player pays the qr code with his wallet (21 sats) adding his own offer via a trick
  node_2_offer=$(./cli2 offer amount=any | jq '.bolt12')
  node_2_bolt11=$(./cli2 fetchinvoice offer=$node_1_offer payer_note=$node_2_offer | jq '.invoice')
  out=$(./cli2 pay bolt11=$node_2_bolt11 description=none)

# Play for 1 minute
  sleep 60

# AT GAME node
# After 1 minute, player $playerid won: payout double
# Get the offer for player $playerid: ugly but it works
  node_2_offer=$(./cli1 listinvoices | grep -A 3 $playerid | tail -1 | sed 's/         "invreq_payer_note": //' | sed 's/,//')
# Now payout the winner
  node_1_bolt11=$(./cli1 fetchinvoice offer=$node_2_offer amount_msat=42000 | jq '.invoice')
  out=$(./cli1 pay bolt11=$node_1_bolt11)

Is this really also possible with invoicerequest and sendinvoice?

I've implemented this idea now in my lighnting game, playable with Phoenix wallet. Where the trick of sending ones lightning address could be done by the wallet, possibly only after crossing a checkbox.

@hMsats hMsats reopened this Oct 11, 2024
@hMsats hMsats changed the title Make returning a bolt12 offer a standardized part of fetchinvoice Make sending a bolt12 offer a standardized part of fetchinvoice Oct 12, 2024
@hMsats
Copy link
Author

hMsats commented Nov 22, 2024

To explain better what I mean here a demonstration video of my modified spark-wallet, where someone pays 100 sats + 30 sats deposit and after a few days gets the deposit back.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants