P2P Next Steps

[georgezgeorgez]

@vilkris

Yes it’s a downside but if the swap is funded from an internal BTC wallet inside Syrius, then the user will have to make an extra transaction to first fund the Syrius BTC wallet.

Unless Syrius becomes their daily driver. In the future, I think we will need a full BTC wallet in Syrius that can send, receive, and transparently interact with NoM. I would need to research what exactly we would need to support to be viable as a production wallet. If we want to grow the community, our target consumer must be the sovereign individual, and not the NoM bagholder lmao.

But ok, let’s get an MVP for just the atomic swap.

@vilkris

There are very few examples utilizing P2TR, so it would require a deep understanding of taproot and BTC transactions in general to get it right

Tapscript is the same as script but with a few tweaks particularly around multisig.

Tapscript

Merkelized Alternative Script Tree (MAST) | River Glossary

There is also MAST which is a big improvement.
Basically you commit the root node of a merkle tree, where the leaves are different spending scripts.
To spend you only have to reveal the script you are actually using and the merkle path to the root. The unspent scripts are never revealed.

For example in our case we have 2 spending paths: the htlc unlock and the reclaim. H() is the hash function.
H(htlc script) = X
H(reclaim script) = Y
H(X,Y) = R

The PT2R would just publicly commit to R
To unlock: I would need to provide the following data.
htlc script sig, htlc script, Y

The chain would then be able to verify the htlc script sig unlocks the htlc script.
It would be able to hash htlc script to produce X, and then do the combined H(X,Y) to get R.
Reclaim script is never revealed.

Likewise, reclaiming would be the same.
You only need:
reclaim script sig, reclaim script, X

P2TR is basically just being able to pay to Schnorr sig or MAST.

Schnorr, Tapscript, MAST, P2TR = Taproot

What Is Taproot and How Does It Benefit Bitcoin? | River Learn - Bitcoin...

[vilkris]

I made a sequence diagram of how I see an MVP ZTS <> BTC swap working in Syrius. This is the happy case flow.

Someone will probably wonder why Bob has to send the counter HTLC’s details manually to Alice, since this is not the case with ZTS <> ZTS swaps. While it would probably be possible to scan all BTC transactions looking for an HTLC script that matches what Alice is expecting to see, there are two reasons I don’t think this should be done.

1. I suspect it will be technically fairly challenging to implement such a scanner.

2. From a UX standpoint it can be argued that it is better that Bob has to explicitly notify Alice when the BTC HTLC is ready to be reviewed. This is because, depending on how many confirmations we require, the BTC TX can take 30 to 60 minutes to be confirmed. If Bob has to notify Alice, then Alice doesn’t have to actively keep monitoring her client waiting for the BTC TX to be confirmed. Once Bob notifies Alice, Alice can continue the swap right away.

To utilize proxy unlock and watchtowers it would make sense to always start the swap on the NoM side.

[0x3639]

I have a few questions.

During this step, will Alice provide a BTC address managed by a different wallet?

It looks like Bob sends the BTC to the P2SH address, not the address provided by Alice. How does the BTC get into the address that Alice provided?

[vilkris]

@0x3639

During this step, will Alice provide a BTC address managed by a different wallet?

Yes.

@0x3639

It looks like Bob sends the BTC to the P2SH address, not the address provided by Alice. How does the BTC get into the address that Alice provided?

The BTC is held in the P2SH address. Alice can unlock the funds with her preimage and the public key that was created for the swap. When she unlocks the funds the receiving address is set to the address she specified in the first step.

[0x3639]

I see. Makes sense.

[sol]

2. I believe it would be better for Alice to assess tx confirmation and unlock when she feels it is sufficient or when block confirmation = 6, whichever comes first.

[sol]

For anyone interested, this developer is working on Solana<-> BTC/LN swaps.

• GitHub - adambor/SolLightning-readme: Solana <-> Bitcoin trustless bridge utilizing submarine swaps and bitcoin relay
  • Including a PoC
• GitHub - adambor/btcrelay-libs: Mono-repo containing BtcRelay-related libraries
• GitHub - adambor/crosslightning-libs: Mono-repo containing CrossLightning-related libs

[vilkris]

Good find. Definitely good reference material. There are similarities with our ideas for cross-chain swaps and apparently they’re using PTLCs. Since they’re using a relay, the protocol only requires three on-chain transactions. They also have the watchtower and proxy unlock idea and the watchtowers are incentivized by small fees to unlock the user’s funds.

[0x3639]

@vilkris

watchtowers are incentivized by small fees to unlock the user’s funds.

Where does that fee come from? When they make the initial P2P swap?

[vilkris]

@0x3639

Where does that fee come from? When they make the initial P2P swap?

This is from the documentation:

We can reduce the trust aspect by using multiple watchtowers, further we can incentivize watchtowers by letting them claim the Solana in a PTLC PDA (needed for the account to be rent exempt ~0.0027 SOL). We can then merge this watchtower implementation with BTC Relay implementation, allowing the relayers to earn fees by claiming the swaps on behalf of the clients.

I’m not sure how exactly that mechanism works on Solana.

In a sense these are P2P swaps, but the swap protocol relies on “intermediaries”, which are individual liquidity providers running servers that basically work as automated counterparties for the swap. They need to have liquidity on both chains. The documentation suggests the intermediaries have a reputation that is stored on the Solana blockchain and the reputation is dependent on successful/unsuccessful swaps.