Why Nostr? What is Njump?
2023-06-09 12:44:22
in reply to

Pierre [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-14 📝 Original message: Hello there, I've been ...

📅 Original date posted:2015-09-14
📝 Original message:
Hello there,

I've been thinking about how we could implement the idea some brilliant
people had here :
https://bitcointalk.org/index.php?topic=1134319.msg11966748#msg11966748.

Basically it would allow to securely move funds in/out an existing channel.

The main use cases would include:
1) funding balanced channels
2) provide a way for merchants to seamlessy cash out their funds

I can't see why we couldn't use the existing htlc contracts to implement
this, it is just another payment after all. But I am certainly missing
something ;-)

Here is what it would look like with rusty-style protobuf messages (swap
in/out are pretty much symmetrical) :

* SWAP IN *

// Whoever wishes to increase her balance in the channel sends this
swap_in_offer {
// How much I would like to increase my balance
required uint32 amount = 1;
// The hash that will be used to do the atomic swap
required sha256_hash r_hash = 2;
// txid of the swap tx, should that be mutated the sender would only be
screwing over himself
required sha256_hash txid = 3;
}

swap_in_accept {
// Maybe we should specify a mindepth here
}

swap_in_decline {
oneof reason {
// the other party needs to be able to compensate the swap in the
channel
bool cannot_swap_more_than_balance = 1;
};
}

regular swap in flow :

Bob -> Alice : swap_in_offer
Alice -> Bob : swap_in_accept
(Bob publishes the swap tx, which pays <amount> BTC to (<alice_final_key> &
r) OR (refund & TIMEOUT))
(tx reaches mindepth)
(alice makes sure the scriptpubkey of this tx indeeds pays her providing r)
Alice -> Bob : update_add_htlc (with same amount and r_hash)
Bob -> Alice : update_accept
Bob -> Alice : update_fulfill_htlc (reveals the r)
(Alice spends the swap tx)

----------------------------------------------------------

* SWAP OUT *

// Whoever wishes to move funds outside the channel sends this
swap_out_offer {
// I would like to cash out this amount
required uint32 amount = 1;
}

swap_out_accept {
// The hash that will be used to do the atomic swap
required sha256_hash r_hash = 1;
// txid of the swap tx, should that be mutated the sender would only be
screwing over himself
required sha256_hash txid = 2;
}

swap_out_decline {
oneof reason {
// you can't get more than your balance !
bool cannot_swap_more_than_balance = 1;
// the other party needs to have corresponding funds available
outside of the channel (meaning it has in fact twice the funds)
bool funds_not_available = 2;
};
}

regular swap out flow :

Bob -> Alice : swap_out_offer
Alice -> Bob : swap_out_accept
(Alice publishes the swap tx, which pays <amount> BTC to (<bob_final_key> &
r) OR (refund & TIMEOUT))
(tx reached mindepth)
(bob makes sure the scriptpubkey of this tx indeeds pays him providing r)
Bob -> Alice : update_add_htlc (with same amount and r_hash)
Alice -> Bob : update_accept
Alice -> Bob : update_fulfill_htlc (reveals the r)
(Bob spends the swap tx)


Cheers,

Pierre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150914/4638a33b/attachment.html>;
Author Public Key
npub1yz88535e0ydqye9q9x8l5cz9d3g6ervfjgyk5xm88zvktmxvstlsuy4pdt