Nostr Web Client

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.

Reply to this note

Please Login to reply.

Discussion

Slyghtning 3mo ago

That sounds simple!

waxwing 3mo ago

Swaps like this are good but it'd be nicer to make it like the better version of coinswap where there isn't an onchain footprint of the hashlock. When the recipient pays the invoice they could also send a cosign of a keypath 2 of 2? But that would need a setup step, so not sure.

Super Testnet 3mo ago

the sender could treat the preimage as a private key, derive its public key, tweak the recipient's public key with it, and use the tweaked public key as the keypath. Then the recipient can spend the money once they learn the preimage without using branch 1. Just add the privkey to their "real" privkey to derive the privkey of the tweaked public key.

waxwing 3mo ago

Yeah i think so, i think that ticks all the boxes.

This is like the payjoin equivalent for onchain/offchain swaps.

It's unfortunate that LN nodes in route could correlate it right? But that's still a lot better than status quo onchain/offchain swaps (from what i vaguely remember of submarine swaps as used today, which isn't much).

Super Testnet 3mo ago

> It's unfortunate that LN nodes in route could correlate it right?

They get to learn the preimage, and can derive its pubkey, subtract it from every pubkey that spent money recently, and check if the result is a pubkey they know. I think you can fix this by tweaking it twice, and sending your recipient one of the tweaks with your invoice. That way, routing nodes can only untweak one step, which isn't good enough. They would need to learn *both* tweaks to identify the recipient's "real" pubkey.

waxwing 3mo ago

Yes i think so. Good call.