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 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 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 > >