public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Stanga <stanga@gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Cc: Matan Yehieli <matany@campus.technion.ac.il>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>,
	Itay Tsabary <sitay@campus.technion.ac.il>
Subject: Re: [bitcoin-dev] MAD-HTLC
Date: Tue, 23 Jun 2020 16:18:35 +0300	[thread overview]
Message-ID: <CABT1wWmm=rx1MkFeNhGeEgdu7XpBXYeq_PWaZFfBOA7MRSKezw@mail.gmail.com> (raw)
In-Reply-To: <CABT1wWknczx62uCpJPWku-KeYuaFvJHrvOS74YzqfoVe5x=edg@mail.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 --]

  reply	other threads:[~2020-06-23 13:18 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CABT1wW=X35HRVGuP-BHUhDrkBEw27+-iDkNnHWjRU-1mRkn0JQ@mail.gmail.com>
2020-06-23  6:41 ` [bitcoin-dev] MAD-HTLC Stanga
2020-06-23  9:48   ` ZmnSCPxj
2020-06-23 12:47     ` Stanga
2020-06-23 13:18       ` Stanga [this message]
2020-06-25  1:38         ` ZmnSCPxj
2020-06-25  3:26           ` Nadav Ivgi
2020-06-25  4:04             ` ZmnSCPxj
2020-06-25  4:35               ` Nadav Ivgi
2020-06-25 13:12                 ` Bastien TEINTURIER
2020-06-28 16:41       ` David A. Harding
2020-07-04 21:05         ` ZmnSCPxj
2020-06-28 12:15   ` David A. Harding
2020-06-29 11:57     ` Tejaswi Nadahalli
2020-06-29 18:05     ` ZmnSCPxj
2020-06-30  6:28       ` Stanga
2020-06-30  6:45       ` Tejaswi Nadahalli
2020-07-01 16:58         ` ZmnSCPxj
2020-07-02 12:22           ` Tejaswi Nadahalli
2020-07-02 16:06             ` ZmnSCPxj
2020-07-03  9:43               ` Tejaswi Nadahalli
2020-07-03 10:16                 ` ZmnSCPxj
2020-07-03 10:44                   ` Tejaswi Nadahalli
     [not found]                     ` <CAF-fr9Z7Xo8JmwtuQ7LE3k1=er+p7s9zPjH_8MNPwbxAfT1z7Q@mail.gmail.com>
2020-07-03 12:38                       ` ZmnSCPxj
     [not found]                         ` <CAF-fr9YhiOFD4n8rGF-MBkWeZmzBWfOJz+p8ggfLuDpioVRvyQ@mail.gmail.com>
2020-07-04 20:58                           ` ZmnSCPxj
2020-07-05  9:03                         ` Stanga
2020-07-06 11:13                       ` Tejaswi Nadahalli
2020-07-02 12:39           ` Tejaswi Nadahalli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABT1wWmm=rx1MkFeNhGeEgdu7XpBXYeq_PWaZFfBOA7MRSKezw@mail.gmail.com' \
    --to=stanga@gmail.com \
    --cc=ZmnSCPxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=matany@campus.technion.ac.il \
    --cc=sitay@campus.technion.ac.il \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox