Good morning Ruben,

> That assumes there will be a second transaction. With SAS I believe we can 
> avoid that, and make it look like this:
>              +---+
>     Alice ---|   |--- Bob
>     Alice ---|   |
>       Bob ---|   |
>              +---+

If Alice is paying to a non-SAS aware payee that just provides an onchain 
address (i.e. all current payees today), then the 2-of-2 output it gets from 
the swap (both of whose keys it learns at the end of the swap) is **not** the 
payee onchain address.
And it cannot just hand over both private keys, because the payee will still 
want unambiguous ownership of the entire UTXO.
So it needs a second transaction anyway.
(with Schnorr then Alice and payee Carol can act as a single entity/taker to 
Bob, a la Lightning Nodelets using Composable MuSig, but that is a pretty big 
increase in protocol complexity)

If Alice does not want to store the remote-generated privkey as well, and use 
only an HD key, then it also has to make the second transaction.
Alice might want to provide the same assurances as current wallets that 
memorizing a 12-word or so mnemonic is sufficient backup for all the funds 
(other than funds currently being swapped), and so would not want to leave any 
funds in a 2-of-2.

If Bob is operating as a maker, then it also cannot directly use the 2-of-2 
output it gets from the swap, and has to make a new 2-of-2 output, for the 
*next* taker that arrives to request its services.

So there is always going to be a second transaction in a SwapMarket system, I 

What SAS / private key turnover gets us is that there is not a *third* 
transaction to move from a 1-of-1 to the next address that makers and takers 
will be moving anyway, and that the protocol does not have to add communication 
provisions for special things like adding maker inputs or specifying all 
destination addresses for the second stage and so on, because those can be done 
unilaterally once the private key is turned over.

> >A thing I have been trying to work out is whether SAS can be done with more 
> >than one participant, like in S6
> S6 requires timelocks for each output in order to function, so I doubt it can 
> be made to work with SAS.

Hmmm right right.

Naively it seems both chaining SAS/private key turnover to multiple makers, and 
a multi-maker S6 augmented with private key turnover, would result in the same 
number of transactions onchain, but I probably have to go draw some diagrams or 
something first.

But S6 has the mild advantage that all the funding transactions paying to 
2-of-2s *can* appear on the same block, whereas chaining swaps will have a 
particular order of when the transactions appear onchain, which might be used 
to derive the order of swaps.
On the other hand, funds claiming in S6 is also ordered in time, so someone 
paying attention to the mempool could guess as well the order of swaps.

bitcoin-dev mailing list

Reply via email to