@SuperTestnet idea for sending a blinded amount onchain \ stacker news ~ideasfromtheedge

It feels a little bit like cheating because the lightning payment is out of band in a way.

Here's an idea for hiding amounts on bitcoin with reduced liveness assumptions compared to payjoin. Suppose you want to send someone 1000 sats without disclosing the amount on the blockchain, and you know your recipient's pubkey. Create a secret, hash it, and set up a script like this:

//branch 1
[ op_sha256, hash, op_equalverify, recipients_pubkey, op_checksig ],
//branch 2
[ 2016, op_checksequenceverify, op_drop, senders_pubkey, op_checksig ],
]

Deposit 100k sats into the address and send the recipient a lightning invoice for 99k sats, locked to the hash in branch 1. If they pay your invoice, they learn the secret, and sweep all 100k sats via branch 1. Outcome: your recipient nets 1k sats, because they sweep 100k sats from the address, but send away 99k sats on lightning.

If they don't pay your invoice, you wait for the timelock to expire and take back the money via branch 2. Outcome: your recipient gets nothing.

Either way, chain analysts just see 100k sats go into the address and come out again, but do not know how much was really sent. And, unlike a payjoin, your recipient did not need to be online when you funded the bitcoin address.

160 sats \ 0 replies \ @justin_shocknet 5h

Seems the observer would know the amount was less-than, also if you're involving lightning may as well have just used that for privacy

its basically batching a loop-in with a payment, but with one output instead of two, so maybe some negligible cost savings in a niche situation where you're paying the swap service for something else already

102 sats \ 0 replies \ @k00b 10h

I'd guess that the lightning requirement is even less desirable than the liveness requirement, but it's a cool construct.

0 sats \ 0 replies \ @optimism 8h

But if you send on LN, they do know what was sent?