Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap

Hello ZmnSCPxj, On 25/08/2020 04:16, ZmnSCPxj wrote: > > Good morning Antoine, > > >> Note, I think this is independent of picking up either relative or absolute >> timelocks as what matters is the block delta between two links. > > I believe it is quite dependent on relative locktimes. > Re

Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap

Good morning Chris, > A big downside is that it really ruins the property of allowing coins to > remain unspent indefinitely. That has privacy implications: if a coin > remains unspent for longer than 2 weeks (or another short locktime) then > for sure the transaction was not a CoinSwap, and so th

Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap

Hello ZmnSCPxj, On 03/09/2020 10:45, ZmnSCPxj wrote: > Good morning Chris, > >> A big downside is that it really ruins the property of allowing coins to >> remain unspent indefinitely. That has privacy implications: if a coin >> remains unspent for longer than 2 weeks (or another short locktime)

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

Just had an idea that an an "inverse timelock" can be made almost-certainly automatic: a revocation UTXO shall become anyone-can-spend after a timeout, and bear some non-dust amount. Before the timelock expiration, it shall be spendable only along with the covenant-locked 'main' UTXO (via a signat

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

CTV does not enable this afaiu because it does not commit to the inputs (otherwise there's a hash cycle for predicting the output's TXID. -- @JeremyRubin On Thu, Sep 3, 2020 at 7:39 AM Dmitry Petukhov wrote: > Just had an ide

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

It's also not something that's trivial to set up in any scheme because you have to have an ordering around when you set up the tx intended to be the inverse lock before you create the tx using it. -- @JeremyRubin On Thu, Sep 3,

Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap

Good morning Chris, > > This seems a great solution! > > Since B is the one offering HTLCs, the taker of a CoinSwap sequence can be > > B as well. > > This means, the taker has to have some collateral input, of at least value > > K, that it cannot swap (because if it tried to swap that amount,