ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2020-05-31 📝 Original message:Good morning Ruben, > > ...
📅 Original date posted:2020-05-31
📝 Original message: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 think.
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.
Regards,
ZmnSCPxj
📝 Original message: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 think.
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.
Regards,
ZmnSCPxj