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

[ZmnSCPxj via bitcoin-dev]

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, it would 
> > be unable to provide a collateral as well).
> > How much does C need to know about the B collateralized contract 
> > transaction?
> > At the minimum, it has to know the output pays out to the correct contract, 
> > so it seems to me it has to know the entire B collateralized contract 
> > transaction, meaning it learns another input of B ("collateral(B)") that is 
> > not otherwise involved in the CoinSwap.
> > This is important, again, if B is a taker, as it means an unrelated input 
> > of B is now learned by C as having the same ownership as B.
>
> Yes, in fact that's why in my example I talk about a CoinSwap between
> two makers Bob and Charlie. Makers can be reasonably expected to own
> multiple UTXOs, but takers cannot. As you say because collateral
> payments breaks the ability of takers to sweep their entire wallet
> through CoinSwap.
>
> Happily, I think takers themselves don't need to use collateral
> payments. Here's an argument to why:
>
> Riskless theft attempts by the taker who no longer controls the coins
> actually isnt riskless or costless: Because it reduces the privacy of
> the previously-owned coins. If a taker genuinely wanted good privacy
> (Which, after all, they're paying for via miner fees and CoinSwap fees)
> then they would benefit if the coins they no longer own remain unspent
> for a long time, because it increases their anonymity set by making them
> hide among a greater crowd of coins which also don't get spent for a
> long time.

Hmmm.

The attack can only be mounted after protocol completion.
Thus, at that point, makers have made money, and takers have paid.
And taker is now in possession of a coin unlinked with its original coin, which 
is what it paid for.

However, if the taker considers the maker fee it has already paid as a sunk 
cost, then it would still be rational of them to mount this attack (sunk costs 
should be ignored).
>From this point-of-view, it is possible to do so with only a *subsequent* 
>potential gain, and still no downside.

For example, suppose the taker has already performed an "honest" CoinSwap.
Then, it is now in possession of a UTXO that is not linked with its income 
stream.
It can then perform another CoinSwap, and *then* perform the attack.
This reveals that the UTXO it provided is involved in a CoinSwap due to 
publication of the contract transaction, which is not a loss in this case since 
the UTXO it put in was not linked to its income stream already, via a previous 
non-attacked CoinSwap.

A taker might rationally consider doing riskless costless theft with its 
already-delinked coins if it assesses that some maker is not sufficiently 
online and with insufficient watchtowers (both operating expenditures!) that it 
has some probability of success times amount it has to seed the theft, versus 
the fee of that maker plus miner fees.

In response, a maker that is forced to accept a sweeping taker will raise its 
fee, so as to disincentivize this attack using already-delinked coins.

Hmmm.

In addition, post-Scriptless-Script, assuming relative-locktime-use is 
"normalized" as proposed in 
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002412.html
 , then the "contract transaction" and its timelock-path-transaction look 
exactly the same as ordinary (P2SH-)P2WPKH single-input-single-output 
transactions, thus in that case the taker does ***not*** lose any privacy.
This removes whatever protection you can get from contract transaction 
blackmail.

--

The above suggests to me that you still want the collateralized contract 
transaction from the taker as well.

A sweeping taker can split its funds in half, swapping one half (and using the 
remainder for collateral input), then after that swap, using the 
already-swapped coins for the collateral input of the remaining unswapped coins.
This leaks information: you are now linking a post-mix coin with a pre-mix 
coin, not onchain (if you do not mount an attack, which you probably will not) 
but you *do* reveal this information to the maker (one input is from the 
funding tx that is pre-mix, the collateral input is from the post-mix coin).

The only protection here is that the maker is unaware of the fact that your 
input coin is pre-mix and your collateral input is post-mix, so it can be hard 
for a maker to *use* this information.


However, it might be possible to prevent the maker from learning the collateral 
input at all.

If my understanding of BIP-143 is correct, inputs are hashed separately 
(`hashPrevouts`) from outputs (`hashOutputs`).
Bob can provide the `hashPrevouts` as an opaque hash, while providing a 
decommitment of `hashOutputs` to show that the outp

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

[Jeremy via bitcoin-dev]

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, 2020 at 10:34 AM Jeremy  wrote:

> 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 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 signature or mutual covenant)
>>
>> This way, after a timeout expires, a multitude of entities will be
>> incentivized to spend this UTXO, because this would be free money for
>> them. It will probably be spend by a miner, as they can always replace
>> the spending transaction with their own and claim the amount.
>>
>> After the revocation UTXO is spent, the covenant path that commits to
>> having it in the inputs will be unspendable, and this would effectively
>> constitute an "inverse timelock".
>>
>>
>>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

[Jeremy via bitcoin-dev]

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 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 signature or mutual covenant)
>
> This way, after a timeout expires, a multitude of entities will be
> incentivized to spend this UTXO, because this would be free money for
> them. It will probably be spend by a miner, as they can always replace
> the spending transaction with their own and claim the amount.
>
> After the revocation UTXO is spent, the covenant path that commits to
> having it in the inputs will be unspendable, and this would effectively
> constitute an "inverse timelock".
>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

[Dmitry Petukhov via bitcoin-dev]

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 signature or mutual covenant)

This way, after a timeout expires, a multitude of entities will be
incentivized to spend this UTXO, because this would be free money for
them. It will probably be spend by a miner, as they can always replace
the spending transaction with their own and claim the amount.

After the revocation UTXO is spent, the covenant path that commits to
having it in the inputs will be unspendable, and this would effectively
constitute an "inverse timelock".

В Fri, 14 Feb 2020 11:16:26 -0800
Jeremy  wrote:

> Hi Dmitry,
> 
> I don't think that this is fundamentally introducing new behavior, but
> let's take a closer look.
> 
> We can talk about the issue you bring up purely in terms of a
> hypothetical "OP_CHECKINPUTOUTPOINTVERIFY" and
> "OP_CHECKINPUTSCRIPTVERIFY" (CIOV, CISV) with obvious implied by name
> semantics, as a separate construct from CTV itself. Such opcodes
> would be strictly more powerful/flexible than what CTV is enabling.
> 
> Using these opcodes I can make an output that can *only* be spent with
> another output -- e.g.,
> 
>   OP_CISV OP_DROP  OP_CHECKSIGVERIFY
>   OP_CIOV OP_DROP  OP_CHECKSIGVERIFY
> 
> Let's look at CISV first:
> 
> 1) Assume that  is from the same owner as PK
> 2) Assume that  is from a different owner than PK
> 
> In case 1, the wallet can create or recreate the appropriate output as
> needed if it gets spent/stuck
> 
> In case 2, the wallet can get "frozen" in a reorg until a signer on
>  re-spends.
> 
> 
> For CIOV:
> 
> 1) Assume that  exists in the chain somewhere
> 2) Assume that  exists in the mempool somewhere
> 3) Assume that  does not exist (or, is provably non-creatable
> -- h = txid(x) | x.IsValid() == false)
> 
> In case 2, this is just a fancy op-return.
> 
> Case 1 degrades into case 2 in the event of a reorg.
> 
> In Case 2, if the output  is spent in another transaction, our
> script becomes provably unspendable (unless a second reorg).
> 
> Otherwise, it is possible to mine a block with our transaction.
> 
> 
> Compare the above to normal transactions:
> 
> 1) If a reorg occurs, and someone double-spends, your transaction gets
> cancelled.
> 2) You can re-sign your UTXO onto a different transaction
> 
> However, if you have deleted your key (e.g. using a pre-signing HSM),
> or your transaction was using a multi-sig with an uncooperating
> party, you will have an output that may be effectively burned.
> 
> These issues are -- as with CTV -- not present in the single input
> use case.
> 
> Thus I argue that CTV -- whose semantics are less powerful/flexible
> than CISV/CIOV -- aren't introducing something that's not already
> present when doing protocols involving more than one input.
> 
> Further, on CTV "monotonic authorization":
> 
> Generally we want Bitcoin Scripts to have the property that once a
> condition is reached, it is 'permanently' a true case. E.g., showing
> a hash preimage to C x, H(x) == C. This can't change with the weather
> or anything else. Even things like timelocks -- although not obvious
> at first glance -- have this property. They express logic that says
> "given the chain is at this height, ...". This means that on any
> chain at such a height the txn is valid. CISV/CIOV semantics also
> fall in line with this description. It says, "given such an input U,
> ...". If that input is realizable one time, it is provably realizable
> across reorgs. However, that doesn't mean someone couldn't interrupt
> U from being created. But generally, with Reorg + Double spend, or
> Reorg > 100 blocks (potentially destroying CB reward), all bets are
> off as to the replay-ability of transactions.
> 
> I want to also point out that this "revocation" property -- to the
> extent it is something new that can't already be emulated with
> pre-signeds or RBF -- is entirely opt-in as far as CTV is concerned.
> You have to specify that an output can only be spent with another,
> most wallets shouldn't do that, and it can't "infect" other wallets
> to an extent more than spending from any recently confirmed output
> exposes you to more reorg risk.
> 
> *In sum, we do not need to worry about this for CTV.*
> 
> 
> Lastly, I want to note that revocation is part of what CTV is
> designed to do (absent reorgs). It allows us to prune spending
> conditions by playing a transaction forward.
> 
> E.g., spending conditions {Alice & Bob, Preimage(H(X)) + Eve,
> CTV({Alice & Bob}, 1 day)}
> 
> Expresses that Eve has 1 day to reveal the preimage to H(X), otherwise
> Alice and Bob can take the coin back by removing Eve's HTLC path.
> What's cool about this revocation v.s. just {Alice & Bob,
> Preimage(H(X)) + Eve} is that Alice and Bob don't need to coordinate

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

[Chris Belcher via bitcoin-dev]

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) then
>> for sure the transaction was not a CoinSwap, and so the anonymity set of
>> the CoinSwap system would be far smaller For this reason I'm pretty
>> desperate to solve the vulnerability without losing the coins remaining
>> unspent indefinitely feature.
> 
> Ah, right accept no small privacy leaks!

I'd argue its not even a small leak. A huge amount of coins remain
unspent for weeks, months and years, and it would be great to add them
to our CoinSwap anonymity set. And also have them benefit from
CoinSwap's anonymity set even if they didn't use CoinSwap.

> 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, it would be 
> unable to provide a collateral as well).
> 
> How much does C need to know about the B collateralized contract transaction?
> At the minimum, it has to know the output pays out to the correct contract, 
> so it seems to me it has to know the entire B collateralized contract 
> transaction, meaning it learns another input of B ("collateral(B)") that is 
> not otherwise involved in the CoinSwap.
> This is important, again, if B is a taker, as it means an unrelated input of 
> B is now learned by C as having the same ownership as B.

Yes, in fact that's why in my example I talk about a CoinSwap between
two makers Bob and Charlie. Makers can be reasonably expected to own
multiple UTXOs, but takers cannot. As you say because collateral
payments breaks the ability of takers to sweep their entire wallet
through CoinSwap.

Happily, I think takers themselves don't need to use collateral
payments. Here's an argument to why:

Riskless theft attempts by the taker who no longer controls the coins
actually isnt riskless or costless: Because it reduces the privacy of
the previously-owned coins. If a taker genuinely wanted good privacy
(Which, after all, they're paying for via miner fees and CoinSwap fees)
then they would benefit if the coins they no longer own remain unspent
for a long time, because it increases their anonymity set by making them
hide among a greater crowd of coins which also don't get spent for a
long time.
Assuming that all peers, especially makers, deploy multiple redundant
watchtowers then we can assume the success rate of such a theft attempt
is very low. Because of the very low payoff, and privacy benefit of
leaving coins unspent, then it can be argued that taker software which
attempts such theft will never get popular.

Of course this privacy argument only applies to takers, and if the
CoinSwap contract is between two makers as part of a multi-transaction
CoinSwap then it doesn't apply. So a maker-to-maker CoinSwap must use
collateral payments.

== Leak of first hop ==
Collateral inputs only applying to maker-maker CoinSwaps adds an
additional information leak, which is that makers can now tell whether
their previous peer was a taker or maker, based on whether they used a
collateral input or not.

This should be okay because the first maker doesn't know the final
destination of the coins. This is similar to Tor, where this information
is already leaked, for example when the user connects to a Tor bridge.
The operator of the Tor bridge knows that everyone connecting to it is
not a Tor relay node but an actual user. The operator of the tor bridge
still has no idea where the user's internet traffic goes. Our situation
is actually better than Tor, because in Tor the final relay always knows
that they are an exit node, while the final maker in a CoinSwap might
not know that.

Also, if the taker does happen to own an extra UTXO, they may choose to
use a collateral input anyway, just to pretend that they're a maker.


Regards
CB
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[ZmnSCPxj via bitcoin-dev]

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 the anonymity set of
> the CoinSwap system would be far smaller For this reason I'm pretty
> desperate to solve the vulnerability without losing the coins remaining
> unspent indefinitely feature.

Ah, right accept no small privacy leaks!

>
> We need to solve the vulnerability you found, which I'll call the
> riskless theft attempt problem. So what do you think of this solution:
>
> == Building block 1: A, B and C having different contract txes ==
>
> In the original proposal each CoinSwap peer has the same contract
> transaction, and either side can broadcast it whenever they like. This
> actually isn't necessary. We can have a contract transaction
> fully-signed but only known to one peer, with a possibly-different
> transaction transaction fully-signed and only known to the other peer.
>
> Obviously for the CoinSwap to work both contract transactions must have
> the same hash-time-locked contract, but they can differ in other ways.
>
> == Building block 2: collateral payments ==
>
> The riskless theft attempt problem happens because the previous owner of
> the coins knows the fully-signed contract transaction and can broadcast
> it at no cost to themselves. So to solve the problem we add a cost.
>
> There is a 2of2 multisig made up of Bob's and Charlie's keys. The
> associated contract transaction known to Bob must now also have one of
> Bob's single-sig inputs. The outputs are such that some of the money
> from Bob's input now ends up in the HTLC output. The result is that
> after the CoinSwap if Bob broadcasts his contract transaction but fails
> to take the money from the HTLC output, then Bob will have lost money.

Just to be clear:

* B is the one who originally funded the HTLC, and owns the timelock.
* C is the one who will accept the HTLC, and owns the hashlock.

> I'm calling this idea collateral payments, by analogy with collateral
> used for loans. A collateral is someone valuable a debtor puts on the
> table, and if they don't repay the loan then they lose the collateral
> (presumably the creditor sells it to repay the loan).
>
> Here is a diagram of the contract transaction known to Bob:
>
> multisig (B+C) [I btc]---> (B+timelock_B OR C+hash) [I+K-M~ btc]
>
> collateral(B)  [J btc] (Bob)[J-K btc]
>
>
> where:
> I = CoinSwap amount
> J = Value of Bob's collateral input
> K = Value that Bob loses if he broadcasts his contract tx but doesnt
> get the money
> M~ = miner fee (random variable)
>
> The value K is something that can be set by the protocol, and made high
> enough so that doing a riskless theft attempt is not worth it. Probably
> the value of K will be quite small because the odds of a riskless
> payment attempt succeeding is very small (assuming the makers all use
> multiple redundant watchtowers). Mostly likely K will be smaller than
> M~, so if the collateral is lost to Bob then the miners will the ones to
> gain, rather than Charlie.

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, it would be 
unable to provide a collateral as well).

How much does C need to know about the B collateralized contract transaction?
At the minimum, it has to know the output pays out to the correct contract, so 
it seems to me it has to know the entire B collateralized contract transaction, 
meaning it learns another input of B ("collateral(B)") that is not otherwise 
involved in the CoinSwap.
This is important, again, if B is a taker, as it means an unrelated input of B 
is now learned by C as having the same ownership as B.

A fresh maker that is given its starting funds in a single UTXO needs to split 
up its funds to make at least one collateral input it can use.

Of note is that the B output also serves as a point for CPFPing this 
transaction, thus only one version of the B collateralized contract transaction 
needs to be made, and the B collateralized contract transaction can be at or 
close to the minimum relay feerate and later CPFPed.

In terms of onchain analysis heuristics, it looks like the B output is change, 
while the B+C contract output is the send-out, I think, for most cases.
In case of a protocol abort, this heuristic is misled, since both outputs 
become owned by B due to the protocol abort.
In case of a protocol completion, this heuristic is accurate, since the B+C 
contract output will be claimed by C, but we do not expect this transaction to 
be confirmed onchain after protocol completion anyway (it effectively donates K 
to C or miners), so this 

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

[Chris Belcher via bitcoin-dev]

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.
> Relative locktimes *require* a contract transaction to kick off the relative 
> locktime period.
> On the other hand, with Scriptless Script (which we know how to do with 
> 2p-ECDSA only, i.e. doable pre-Taproot), absolute locktimes do not need a 
> contract transaction.
> 
> With absolute locktimes + Scriptless SCript, in a single onchain PTLC, one 
> participant holds a completely-signed timelock transaction while the other 
> participant holds a completely-signed pointlock transaction.
> This can be arranged by having one side offer partial signatures for the 
> transaction of the other, and once completing the signature, not sharing it 
> with the other until we are ready to actually broadcast the transaction of 
> our own volition.
> There is no transaction that both participants hold in completely-signed form.
> 
> This should remove most of the shenanigans possible, and makes the 30xRBF 
> safe for any range of fees.
> I think.
> 
> Since for each PTLC a participant holds only its "own" transaction, it is 
> possible for a participant to define its range of fees for the RBF versions 
> of the transaction it owns, without negotiation with the other participant.
> Since the fee involved is deducted from its own transaction, each participant 
> can define this range of RBFed fees and impose it on the partial signatures 
> it gets from the other participant.
> 
> --
> 
> Private key turnover is still useful even in an absolute-timelock world.
> 
> If we need to bump up the block delta between links, it might be impractical 
> to have the total delta of a multi-hop swap be too long at the taker.
> 
> As a concrete example, suppose A is a taker who wants to route over makers B 
> and C.
> However, B and C require a CLTV delta of 1 week.
> 
> If A wants to route "directly" A->B->C->A, then if something bad happens, it 
> could be looking at having its funds locked for two weeks.
> 
> To reduce this risk, A can instead first swap A->B->A, then when that 
> completes, A->C->A.
> This limits its funding lockup to 1 week.
> 
> Private key turnover is useful since as soon as the A->B->A swap completes, 
> it can directly fund the A->C->A swap from the B-side funding transaction of 
> the A->B->A swap.
> 
>  |   A->B->A |A->C->A   |
>  :   :  :
>   A -:->funding A&B--> B :  :
>  :   :  :
>   B -:->funding A&B -:--> funding A&C --> C :
>  :   :  :
>  :   :C-> funding A&C --:-> to-cold  A -->
>  :   :  :
> 
> This increases the number of transactions by 1 per swap beyond the first, 
> compared to a direct routing A->B->C->A, but this may be worth it for A if 
> the timelocks involved are too big for A.
> 
> With 2p-ECDSA, a funding A&C looks exactly the same as a to-cold A, so B is 
> unable to reliably determine if it is the last hop in the route.
> 
> Without private key turnover, A would have:
> 
>   **NO** private key turnover!
> 
>  |   A->B->A |A->C->A  |
>  :   : :
>   A -:->funding A&B--> B : :
>  :   : :
>   B -:->funding A&B -:--> claim A -> funding A&C --> C :
>  :   : :
>  :   :   C-> funding A&C --:-> to-cold  A 
> -->
>  :   : :
> 
> So if timelock-deltas are possibly-high (to reduce the probability of the 
> MAD-HTLC argument, and other attacks, succeeding), takers might prefer to 
> route by completing one swap first before starting the next one, and private 
> key turnover is useful by reducing blockspace required by each hop.
> 
> For reference, this is how it looks like with a single A->B->C->A swap with 
> private key turnover:
> 
>  |   A->B->C->A  |
>  :   :
>   A -:->funding A&B--> B :
>  :   :
>   B -:->funding B&C -> C :
>  :   :
>   C -:->funding A&C -:-> to-cold A -->
>  :   :
> 
> This is still smaller than in the A->B->A, A->C->A with private key turnover, 
> by one funding tx per hop.
> However, A risks a much higher timelock (twice the timelock).
> Thus, A might prefer a lower timelock in exchange for paying for an 
> additional transaction.
> 
> Regards