Re: [bitcoin-dev] MAD-HTLC

2020-07-04 Thread ZmnSCPxj via bitcoin-dev
Good morning Dave,


> > > -   Inputs:
> > > -   Bob 1 BTC - HTLC amount
> > > -   Bob 1 BTC - Bob fidelity bond
> > > -   Cases:
> > > -   Alice reveals hashlock at any time:
> > > -   1 BTC goes to Alice
> > > -   1 BTC goes to Bob (fidelity bond refund)
> > > -   Bob reveals bob-hashlock after time L:
> > > -   2 BTC goes to Bob (HTLC refund + fidelity bond refund)
> > > -   Bob cheated, anybody reveals both hashlock and bob-hashlock:
> > > -   2 BTC goes to miner
> > >
> > > [...]
> >
> > The cases you present are exactly how MAD-HTLC works. It comprises two
> > contracts (UTXOs):
> >
> > -   Deposit (holding the intended HTLC tokens), with three redeem paths:
> > -   Alice (signature), with preimage "A", no timeout
> > -   Bob (signature), with preimage "B", timeout T
> > -   Any entity (miner), with both preimages "A" and "B", no timeout
> > -   Collateral (the fidelity bond, doesn't have to be of the same amount)
> > -   Bob (signature), no preimage, timeout T
> > -   Any entity (miner), with both preimages "A" and "B", timeout T
>
> I'm not these are safe if your counterparty is a miner. Imagine Bob
> offers Alice a MAD-HTLC. Alice knows the payment preimage ("preimage
> A"). Bob knows the bond preimage ("preimage B") and he's the one making
> the payment and offering the bond.
>
> After receiving the HTLC, Alice takes no action on it, so the timelock
> expires. Bob publicly broadcasts the refund transaction with the bond
> preimage. Unbeknownst to Bob, Alice is actually a miner and she uses her
> pre-existing knowledge of the payment preimage plus her received
> knowledge of the bond preimage to privately attempt mining a transaction
> that pays her both the payment ("deposit") and the bond ("collateral").
>
> Assuming Alice is a non-majority miner, she isn't guaranteed to
> succeed---her chance of success depends on her percentage of the network
> hashrate and how much fee Bob paid to incentivize other miners to
> confirm his refund transaction quickly. However, as long as Alice has a
> non-trivial amount of hashrate, she will succeed some percentage of the
> time in executing this type of attack. Any of her theft attempts that
> fail will leave no public trace, perhaps lulling users into a false
> sense of security.


This note seems to have gotten missed in discussion.

Another note is that from what I can tell, the preimages "A" and "B" can be 
provided by any miner.

If the fund value plus the collateral is large enough, it may incentivize 
competing miners to reorg the chain, redirecting the funds of the MAD-HTLC to 
themselves, rather than advance the blockchain state, at least until 
alternative transctions bump their fees up enough that the collateral + fund is 
matched.

This may not apply to Lightning at least if you do not go beyond the Wumbo 
limit, but *could* apply to e.g. SwapMarket, if it uses MAD-HTLCs.

Regards,
ZmnSCPxj

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


Re: [bitcoin-dev] MAD-HTLC

2020-07-04 Thread ZmnSCPxj via bitcoin-dev
Good morning Ittay,


 The analysis in our MAD-HTLC paper shows that when all players are 
rational (i.e., make the best decisions), and have the greater strategy space 
(which is easy to achieve, 150 Loc), the subgame-perfect-equilibrium strategy 
(this is like Nash-equilibrium for dynamic 
gameshttps://en.wikipedia.org/wiki/Subgame_perfect_equilibrium) for even 
relatively-small fee is to support the attack. Putting it in game-theory terms 
-- strategy "exclude-Alice-until-timeout-then-include-Bob" results with higher 
utility than strategy "include-Alice-Tx-now" (and by definition, 
"include-Alice-Tx-now" does not dominante 
"exclude-Alice-until-timeout-then-include-Bob").

It may be helpful to think in terms of Prisoner Dilemma.


   | cooperate | betray
---+---+-
cooperate  | -1, -1| 0, -3
---+---+-
betray | -3, 0 | -2, -2

"include-Alice-Tx-now" imposes a greater cost on those playing 
"exclude-Alice-until-timeout-then-include-Bob" players, than the benefit that 
both miners play "exclude-Alice-until-timeout-then-include-Bob".

Basically, "cooperate" == "exclude-Alice-until-timeout-then-include-Bob", 
"betray" == "include-Alice-Tx-now".

One way to get around this is to invoke Iterated Prisoner Dilemma, but that 
requires that miners can identify other miners and to be able to act 
accordingly to how those other miners have acted in the past.
The entire point of Bitcoin mining is to allow strong anonymity of miners (not 
that this commonly happens in practice, given the habit of putting identifying 
information in coinbases).

Another way would be to have a higher system that polices its constituents and 
ensures that every miner plays "exclude-Alice-until-timeout-then-include-Bob", 
and punishes "include-Alice-Tx-now".
But that would be equivalent to a centralized cartel, and would be the death of 
Bitcoin anyway, at which point, all Bitcoin tokens will be worthless.


Regards,
ZmnSCPxj

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