Coinswap is different from coinjoin in that it requires some trust. Although there are timeouts in case of failure, failure still means miner fees and time are wasted. This is a DOS opportunity by servers (makers) against clients (takers).
There are similar issues in LN which are discussed in this talk: Lightning Network as a Directed Graph: Single-Funded Channel Network Topology. The solution seems to be to create payment channels at the same time as initially paying somebody which completely removes the trust required, but this isn't possible in coinswap.
Another set of ideas is to shift the trust onto the taker using elaborate schemes from the joinmarket coinswap issue: https://github.com/JoinMarket-Org/joinmarket/issues/335#issuecomment-291613405 This costs more block space, degrades privacy/fungibility, relies on reputation from past deals which is a force for centralization (because of the Matthew effect of accumulated advantage), and doesn't seem to be compatible with pruning (since it requires everyone to be scanning old transactions).
Reputation comes from money (and time-value-of-money) instead of past coinswap deals, so there's no centralization force. Anyone with money can buy an identity and become a Carol maker server. DOS proofs (https://github.com/AdamISZ/CoinSwapCS/issues/50) can be used to help provide accountability to any of those identities.
The fidelity bonds will be subject to market forces, so probably at the start nobody will use fidelity bonds. As coinswap gets more popular some makers may choose to lock up coins for a short amount of time, then for longer and longer. Not much block space will be required because this requires one small transaction every several months or years.
I imagine Alice would somehow obtain a list of Carol's .onion addresses, then Alice would download proof of their fidelity bonds and check on the blockchain that they are real.
Recovering coins from backup
It would be good to allow recovery of coins from fidelity bonds with only a mnemonic phrase. This is possible by adding granularity to the lock times. So only allowing the CLTV lock dates to be at midnight on the first of each month. If we allow fidelity bonds for up to 50 years, that requires only 12*50 = 600 addresses per public key to be added with importaddress which is totally practical for importing and scanning. That way the fidelity bonds would only need a mnemonic phrase to backup.
Coinswap is different from coinjoin in that it requires some trust. Although there are timeouts in case of failure, failure still means miner fees and time are wasted. This is a DOS opportunity by servers (makers) against clients (takers).
There are similar issues in LN which are discussed in this talk: Lightning Network as a Directed Graph: Single-Funded Channel Network Topology. The solution seems to be to create payment channels at the same time as initially paying somebody which completely removes the trust required, but this isn't possible in coinswap.
Another set of ideas is to shift the trust onto the taker using elaborate schemes from the joinmarket coinswap issue: https://github.com/JoinMarket-Org/joinmarket/issues/335#issuecomment-291613405 This costs more block space, degrades privacy/fungibility, relies on reputation from past deals which is a force for centralization (because of the Matthew effect of accumulated advantage), and doesn't seem to be compatible with pruning (since it requires everyone to be scanning old transactions).
A better idea is to use time-locked fidelity bonds.
Reputation comes from money (and time-value-of-money) instead of past coinswap deals, so there's no centralization force. Anyone with money can buy an identity and become a Carol maker server. DOS proofs (https://github.com/AdamISZ/CoinSwapCS/issues/50) can be used to help provide accountability to any of those identities.
The fidelity bonds will be subject to market forces, so probably at the start nobody will use fidelity bonds. As coinswap gets more popular some makers may choose to lock up coins for a short amount of time, then for longer and longer. Not much block space will be required because this requires one small transaction every several months or years.
I imagine Alice would somehow obtain a list of Carol's .onion addresses, then Alice would download proof of their fidelity bonds and check on the blockchain that they are real.
Recovering coins from backup
It would be good to allow recovery of coins from fidelity bonds with only a mnemonic phrase. This is possible by adding granularity to the lock times. So only allowing the CLTV lock dates to be at midnight on the first of each month. If we allow fidelity bonds for up to 50 years, that requires only 12*50 = 600 addresses per public key to be added with
importaddresswhich is totally practical for importing and scanning. That way the fidelity bonds would only need a mnemonic phrase to backup.