Re: [bitcoin-dev] MAD-HTLC

[Stanga <stanga@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 6422 bytes --]

Of course the order at the end should have been switched:

Consider first the case where Alice *does not* publish preimage "A": Bob
can safely publish preimage "B" and get both the Deposit and Collateral
tokens after the timeout.
Now, consider the case where Alice *publishes* preimage "A": If Bob
publishes preimage "B" he gets nothing (and so does Alice - this is the
mutual assured destruction), and if he doesn't, he gets the Collateral
tokens.


On Tue, Jun 23, 2020 at 3:47 PM Stanga <stanga@gmail.com> wrote:

> Hi ZmnSCPxj,
>
> Thank you for taking the time to respond, these are very good points.
> Responses inline.
>
> On Tue, Jun 23, 2020 at 12:48 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>
>> Good morning Itay, Ittay, and Matan,
>>
>> I believe an unstated assumption in Bitcoin is that miners are
>> short-sighted.
>>
>> The reasoning for this assumption is:
>>
>> * Deployment of new mining hardware controlled by others may occur at any
>> time you do not control.
>>   * Thus, any transactions you leave on the table are potentially taken
>> by somebody else and not by you.
>>   * Sudden changes in hashpower distribution may reduce your expected
>> future earnings, so any future theoretical earnings should be discounted
>> (*in addition to* expected return-on-investment on getting money you can
>> invest *now*).
>>
>
> Our analysis assumes constant difficulty, i.e., no significant changes of
> the miners set. Indeed, hash-rate changes typically occur at a much larger
> granularity than your average HTLC timeout. For instance, we noticed plenty
> of lightning nodes use timeouts of a day. So, we do not consider
> optimization at infinity, just a day ahead, and within this time frame all
> the factors you mentioned are not expected to dramatically change.
>
> That being said, it would be interesting to analyze the effect of miners
> joining during the HTLC duration. Intuitively, this shouldn’t affect the
> results, as those new miners have the same incentive to wait for the
> higher-paying tx.
>
>
>>
>> It also strikes me that, in a world with RBF and CPFP, the same endpoint
>> (i.e. miners earn the entire fund of the HTLC) is achieved by existing
>> HTLCs, without the additional branch and script opcodes needed by MAD-HTLC.
>> For example, if an HTLC is confirmed but the hashlock-claiming
>> transaction is not being confirmed (because miners are holding it up
>> because Bob is offering a much higher fee in the future for the
>> timelock-claiming transaction), then Alice can, regardless of the reason
>> why it is not being confirmed, bump up the fee with RBF or CPFP.
>>
>> If the fee bump offered by Alice is sufficiently large, then miners will
>> start re-preferring the Alice hashlock transaction.
>> To counter this, Bob has to bid up its version higher.
>>
>> As the timeout approaches, Alice can bump up its fee until it is just 1
>> satoshi short of the total fund.
>> It is rational for Alice to do so since at timeout, it can expect to lose
>> the entire fund.
>> In order for Bob to win, it has to beat that fee, at which point it
>> equals or exceeds the total fund, and miners get the total fund (or more).
>>
>> Knowing this end-point, rational Bob will not even begin this game.
>>
>> I think this research considers these two endpoints to be distinct:
>>
>> * Bob misbehaves and the entire fund is punished by miners, leaving
>> miners with the fund and Alice and Bob without money (MAD-HTLC).
>> * Bob misbehaves, Alice counters, and the ensuing fee war leads to fees
>> approaching the fund value, leaving miners with the fund and Alice and Bob
>> without money (standard HTLC).
>>
>> But in practice I think both endpoints are essentially equivalent.
>>
>
> These are not the same scenario, since in HTLC there is a race between
> Alice and Bob. Alice might not wish to pay the full HTLC amount once she
> sees Bob is trying to cheat. She could wait until close to the timeout so
> as to reduce the time Bob can respond. Of course Bob would do the same. So
> this is an actual race, and Bob takes no risk since his payment is all from
> the HTLC amount. Mutual destruction is only assured under certain
> assumptions in HTLC. MAD-HTLC achieves security without relying on such
> assumptions.
>
>
>>
>> --
>>
>> What MAD-HTLC can do would be to make different claims:
>>
>> * 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
>>
>> This is an actual improvement over HTLC: Bob misbehavior leads to loss of
>> the fidelity bond.
>> The above cases can be assured by requiring both Alice and Bob to sign in
>> the alice-hashlock branch, so that the splitting of the fund is enforced,
>> and SegWit signing so that the dependent transaction is signed before the
>> HTLC-funding transaction is.
>> It can also be implemented with `OP_CHECKTEMPLATEVERIFY`.
>
>
> 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
>
> Only Bob initially knows preimage "B", and is required to reveal it if he
> wishes to get the Deposit tokens.
>
> Consider first the case where Alice publishes preimage "A": Bob can safely
> publish preimage "B" and get both the Deposit and Collateral tokens after
> the timeout.
> Now, consider the case where Alice does not publish preimage "A": If Bob
> publishes preimage "B" he gets nothing (and so does Alice - this is the
> mutual assured destruction), and if he doesn't, he gets the Collateral
> tokens.
>
> Best,
> Ittay
>
>

[-- Attachment #2: Type: text/html, Size: 7586 bytes --]