Re: [bitcoin-dev] MAD-HTLC

2020-06-24 Thread ZmnSCPxj via bitcoin-dev
Good morning Nadav,

> > I and some number of Lightning devs consider this to be sufficient 
> > disincentive to Bob not attacking in the first place.
>
> An additional disincentive could be introduced in the form of bribery proofs 
> for failed attempts.
>
> If we assume that "honest" users of the LN protocol won't reveal their 
> timelocked transactions before reaching the timelock expiry (they shouldn't 
> anyway because standard full node implementations won't relay them), we can 
> prove that Bob attempted bribery and failed to an outside observer by showing 
> Bob's signed timelocked transaction, spending an output that was in reality 
> spent by a different transaction prior to the locktime expiry, which should 
> not be possible if Bob had waited.


Unfortunately this could be subject to an inversion of this attack.

Alice can wait for the timelock to expire, then bribe miners to prevent 
confirmation of the Bob timelocked transaction, getting the Alice hashlocked 
transaction confirmed.

Now of course you do mention "prior to the locktime expiry" but there is now 
risk at around locktime.

Particularly, "natural" orphaned blocks and short-term chainsplits can exist.
Bob might see that the locktime has arrived and broadcast the signed timelocked 
transaction, then Alice sees the locktime has not yet arrived (due to 
short-term chainsplits/propagation delays) and broadcast the signed hashlocked 
transaction, then in the end the Alice side of the short-term chainsplit is 
what solidifies into reality due to random chance on which miner wins which 
block.
Then Bob can now be accused of bribery, even though it acted innocently; it 
broadcasted the timelock branch due to a natural chainsplit but Alice 
hashlocked branch got confirmed.

Additional complications can be added on top to help mitigate this edge case 
but more complex == worse in general.
For example it could "prior to locktime expiry" can ignore a few blocks before 
the actual timelock, but this might allow Bob to mount the attack by initiating 
its bribery behavior earlier by those few blocks.

Finally, serious attackers would just use new pseudonyms, the important thing 
is to make pseudonyms valuable and costly to lose, so it is considered 
sufficient that LN nodes need to have some commitment to the LN in the form of 
actual channels (which are valuable, potentially money-earning constructs, and 
costly to set up).

Other HTLC-using systems, such as the "SwapMarket" being proposed by Chris 
Belcher, could use similar disincentivizing; I know Chris is planning a 
fidelity bond system for SwapMarket makers, for example, which would mimic the 
properties of LN channels (costly to set up, money-earning).

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-06-24 Thread ZmnSCPxj via bitcoin-dev
Good morning Stanga et al,


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

We already know that hashrate tends to trend upwards, and that we do not expect 
hashrate to fall except for occasional transients.

The expectation is not that new miners have different incentives.
Instead, the expectation is that current miners discount future possible gains 
because in the future, they expect to have less hashrate share than right now.

The only trustless way for Bob to bribe miners into deferring Alice tx is to 
attach the bribe to the future confirmation of the Bob tx, thus Bob is offering 
future-coins, not present-coins like Alice can offer, and the fact that miners 
expect an overall uptrend in total hashrate (leading to an overall downtrend in 
their hashrate share) means that miners discount the Bob offered future-coins.
The discounting is proportional to the time delay involved, as a larger delay 
implies greater reduction in hashrate share.

This discounting is, again, *in addition to* natural discounting a.k.a. "I will 
gladly pay you Thursday for a hamburger today", the hamburger seller will want 
some pretty stiff assurances plus a bigger payment on Thursday for giving you a 
hamburger today, due to expected returns on investment.


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

Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest

2020-06-24 Thread Matt Corallo via bitcoin-dev
Given transaction relay delays and a network topology that is rather 
transparent if you look closely enough, I think this is very real and very 
practical (double-digit % success rate, at least, with some trial and error 
probably 50+). That said, we all also probably know most of the people who know 
enough to go from zero to doing this practically next week. As for motivated 
folks who have lots of time to read code and dig, this seems like something 
worth fixing in the medium term.

Your observation is what’s largely led me to conclude there isn’t a lot we can 
do here without a lot of creativity and fundamental rethinking of our approach. 
One thing I keep harping on is maybe saving the blind-CPFP approach with a) 
eltoo, and b) some kind of magic transaction relay metadata that allows you to 
specify “this spends at least one output on any transaction that spends output 
X” so that nodes can always apply it properly. But maybe that’s a pipedream of 
complexity. I know Antoine has other thoughts.

Matt

> On Jun 22, 2020, at 04:04, Bastien TEINTURIER via bitcoin-dev 
>  wrote:
> 
> 
> Hey ZmnSCPxj,
> 
> I agree that in theory this looks possible, but doing it in practice with 
> accurate control
> of what parts of the network get what tx feels impractical to me (but maybe 
> I'm wrong!).
> 
> It feels to me that an attacker who would be able to do this would break 
> *any* off-chain
> construction that relies on absolute timeouts, so I'm hoping this is insanely 
> hard to
> achieve without cooperation from a miners subset. Let me know if I'm too 
> optimistic on
> this!
> 
> Cheers,
> Bastien
> 
>> Le lun. 22 juin 2020 à 10:15, ZmnSCPxj  a écrit :
>> Good morning Bastien,
>> 
>> > Thanks for the detailed write-up on how it affects incentives and 
>> > centralization,
>> > these are good points. I need to spend more time thinking about them.
>> >
>> > > This is one reason I suggested using independent pay-to-preimage
>> > > transactions[1]
>> >
>> > While this works as a technical solution, I think it has some incentives 
>> > issues too.
>> > In this attack, I believe the miners that hide the preimage tx in their 
>> > mempool have
>> > to be accomplice with the attacker, otherwise they would share that tx 
>> > with some of
>> > their peers, and some non-miner nodes would get that preimage tx and be 
>> > able to
>> > gossip them off-chain (and even relay them to other mempools).
>> 
>> I believe this is technically possible with current mempool rules, without 
>> miners cooperating with the attacker.
>> 
>> Basically, the attacker releases two transactions with near-equal fees, so 
>> that neither can RBF the other.
>> It releases the preimage tx near miners, and the timelock tx near non-miners.
>> 
>> Nodes at the boundaries between those that receive the preimage tx and the 
>> timelock tx will receive both.
>> However, they will receive one or the other first.
>> Which one they receive first will be what they keep, and they will reject 
>> the other (and *not* propagate the other), because the difference in fees is 
>> not enough to get past the RBF rules (which requires not just a feerate 
>> increase, but also an increase in absolute fee, of at least the minimum 
>> relay feerate times transaction size).
>> 
>> Because they reject the other tx, they do not propagate the other tx, so the 
>> boundary between the two txes is inviolate, neither can get past that 
>> boundary, this occurs even if everyone is running 100% unmodified Bitcoin 
>> Core code.
>> 
>> I am not a mempool expert and my understanding may be incorrect.
>> 
>> Regards,
>> ZmnSCPxj
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev