Good example, even if rather hard to setup :-)
What I meant with the attack being identical is that we can replay the
entire attack on-chain, without needing Lightning in the first place,
i.e., the attacker needed to own the funds he is going to steal at some
time, whether that is as part of a channel settlement that is repalced
or an output that has been spent.
You are however right that Lightning with its multi-hop payments
increases the potential exposure of a node, increasing the attackers
payoff in case of a successful attack.
Cheers,
Christian
René Pickhardt <r.pickha...@googlemail.com> writes:
> Hey Christian,
>
> I agree with you on almost anything you said. however I disagree that in
> the lightning case it produces just another double spending. I wish to to
> emphasize on my statement that the in the case with lightning such a 51%
> attack can steal way more BTC than double spending my own funds. The
> following example is a little extrem and constructed but it should help to
> make the point. Also for pure convenience reasons I neglected the fact that
> channels should never be worse distributed than 99% to 1%:
>
> Let us assume I am the attacker currently owning 1000 BTC. Now 1000 nodes
> called n_0,...n_{999} open a payment channel with me (all funded by the
> other side with 999 BTC in each channel (and 1 BTC from me)) resulting in
> the following channel balance sheet:
> c_0: me = 1 BTC and n_0 = 999 BTC
> c_1: me = 1 BTC and n_1 = 999 BTC
> c_2: me = 1 BTC and n_2 = 999 BTC
> ...
> c_{999}: me = 1 BTC and n_{999} = 999 BTC
>
> Now node n_0 sends 1 BTC to each node n_1,...,n_{999} (using me for routing
> the payment) so the channel balances read:
> c_0: me = 1000 BTC and n_0 = 0 BTC (save the corresponding
> commitment transaction!)
> c_1: me = 0 BTC and n_1 = 1000 BTC
> c_2: me = 0 BTC and n_2 = 1000 BTC
> ...
> c_{999}: me= 0 BTC and n_{999} = 1000 BTC
>
> next n_1 sends 1000 BTC to n_0:
> c_0: me = 0 BTC and n_0 = 1000 BTC
> c_1: me = 1000 BTC and n_1 = 0 BTC (save the corresponding
> commitment transaction!)
> c_2: me = 0 BTC and n_2 = 1000 BTC
> ...
> c_{999}: me= 0 BTC and n_{999} = 1000 BTC
>
> similarly n_2 sends 1000 BTC to n_1:
> c_0: me = 0 BTC and n_0 = 1000 BTC
> c_1: me = 0 BTC and n_1 = 1000 BTC
> c_2: me = 1000 BTC and n_2 = 0 BTC (save the corresponding
> commitment transaction!)
> ...
> c_{999}: me = 0 BTC nad n_{999} = 1000 BTC
>
> following this scheme n_3 --[1000 BTC]--> n_2, n_4 --[1000 BTC]--> n_3,...
>
> due to this (as mentioned highly constructed and artificial behavior) I
> will have old commitment transactions in *each* and every channel (which
> spends 1000 BTC to me)
>
> When starting my secret mining endeavor I spend those commitment
> transactions which gives in this particular case 1000 * 1000 BTC = 1M BTC
> to me.
>
> So while I agree that a 51% is a problem for any blockchain technology I
> think the consequences in the lightning scenario are way more problematic
> and makes such an attack also way more interesting for a dishonest
> fraudulent person / group. In particular I could run for a decade on stable
> payment channels storing old state and at some point realizing it would be
> a really big opportunity secretly cashing in all those old transactions
> which can't be revoked.
>
> I guess one way of resolving this kind of limitless but rare possibility
> for stealing could be to make sure no one can have more than 2 or three
> times the amount of BTC she owns in all the payment channels the person has
> open. As funding transactions are publicly visible on the blockchain one
> could at least use that measure to warn people before opening and funding
> another payment channel with a node that is heavily underfunded. Also in
> the sense of network topology such a measure would probably make sure that
> channels are somewhat equally funded.
>
> best Rene
>
>
>
>
>
> On Tue, Mar 13, 2018 at 3:55 PM, Christian Decker <
> decker.christ...@gmail.com> wrote:
>
>> Hi René,
>>
>> very good question. I think the simple answer is that this is exactly
>> the reason why not having a participant in the network that can 51%
>> attack over a prolonged period is one of the base assumptions in
>> Lightning. These attacks are deadly to all blockchains, and we are
>> certainly no different in that regard.
>>
>> More interesting is the assertion that this may indeed be more dangerous
>> than a classical 51% attack, in which an attacker can only doublespend
>> funds that she had control over at some point during the attack
>> (duration being defined as the period she can build a hidden fork of). I
>> think the case for Lightning is not more dangerous since what they could
>> do is enforce an old state in which they had a higher balance than in
>> the final state, without incurring in a penalty. The key observation is
>> that in this old state they actually had to have the balance they are
>> stealing on the channel. So this maps directly to the classical
>> scenario in which an attacker simply doublespends funds they had control
>> over during the attack, making the attack pretty much the same.
>>
>> Another interesting observation is that with Lightning the state that
>> the attacker is enforcing may predate the attack, e.g., an attacker
>> could use a state that existed and was replaced before it started
>> generating its fork. This is in contrast to the classical doublespend
>> attack in which invalidated spends have to happen after the fork
>> started, and the attacker just filters them from its fork.
>>
>> But as I said before, if we can't count on there not being a 51%
>> attacker, then things are pretty much broken anyway :-)
>>
>> Cheers,
>> Christian
>>
>> René Pickhardt via Lightning-dev
>> <lightning-dev@lists.linuxfoundation.org> writes:
>> > Hey everyone,
>> >
>> > disclaimer: as mentioned in my other mail (
>> > https://lists.linuxfoundation.org/pipermail/lightning-dev/
>> 2018-March/001065.html
>> > ) I am currently studying the revocation system of duplex micropayment
>> > channels in detail but I am also pretty new to the topic. So I hope the
>> > attack I am about to describe is not possible and it is just me
>> overseeing
>> > some detail or rather my lack of understanding.
>> > That being said even after waiting one week upon discovery and double
>> > checking the assumptions I made I am still positive that the revocation
>> > system in its current form allows for a new form of a 51% attack. This
>> > attack seems to be way more harmful than a successful 51% attack on the
>> > bitcoin network. Afaik within the bitcoin network I could 'only double
>> > spend' my own funds with a successful 51% attack. In the lightning case
>> it
>> > seems that an attacker could steal an arbitrary amount of funds as long
>> as
>> > the attacker has enough payment channels with enough balance open.
>> >
>> > The attack itself follows exactly the philosophy of lightning: "If a tree
>> > falls in the forest and no one is around to hear it. Does it make a
>> sound?"
>> > In the context of the attack this would translate to: "If a 51% attacker
>> > secretly mines enough blocks after fraudulently spending old commitment
>> > transactions and no one sees it during the the *to_self_delay* period,
>> > have the commitment transactions been spent? (How) Can they be revoked?"
>> >
>> >
>> > As for the technical details I quote from the spec of BOLT 3:
>> > "*To allow an opportunity for penalty transactions, in case of a revoked
>> > commitment transaction, all outputs that return funds to the owner of the
>> > commitment transaction (a.k.a. the "local node") must be delayed for *
>> > *to_self_delay** blocks. This delay is done in a second-stage HTLC
>> > transaction (HTLC-success for HTLCs accepted by the local node,
>> > HTLC-timeout for HTLCs offered by the local node)*"
>> >
>> > Assume an attacker has 51% of the hash power she could open several
>> > lightning channels and in particular accept any incoming payment channel
>> > (the more balance is in her channels the more lucrative the 51% attack).
>> > Since the attacker already has a lot of hash power it is reasonable (but
>> > not necessary) to assume that the attacker already has a lot of bitcoins
>> > and is well known to honest nodes in the network which makes it even more
>> > likely to have many open channels.
>> >
>> > The attacker keeps track of her (revocable) commitment transactions in
>> > which the balance is mostly on the attackers side. Once the attacker
>> knows
>> > enough of these (old) commitment transactions the attack is being
>> executed
>> > in the following way:
>> > 0.) The max value of to_self_delay is evaluated. Let us assume it is 72
>> > blocks (or half a day).
>> > 1.) The attacker secretly starts mining on her own but does not
>> broadcasts
>> > any successfully mined block. Since the attacker has 51% of the hash
>> power
>> > she will most likely be faster than the network to mine the 72 blocks of
>> > the safety period in which fraudulent commitment transactions could be
>> > revoked.
>> > 2.) The attacker spends all the fraudulent (old) commitment transactions
>> in
>> > the first block of her secrete mining endeavor.
>> > 3.) Meanwhile the attacker starts spending her own funds of her payment
>> > channels e.g on decentralized exchanges for any other (crypto)currency.
>> > 4.) As soon as the attacker has mined enough blocks that the commitment
>> > transactions cannot be revoked she broadcasts her secretly minded
>> > blockchain which will be accepted by the network as it is the longest
>> > chain. (In Particular she includes all the other bitcoin transactions
>> that
>> > are also in the original public blockchain so that other people don't
>> even
>> > realize something suspicious has happened.)
>> >
>> > Since according to the spec channels should never be balanced worse than
>> > 99% to 1% the attacker could steal up to 99% of all the bitcoins
>> allocated
>> > in the sum of all payment channels the attacker was connected to. This
>> > amount could obviously be way higher than just double spending her own
>> > funds. This attack would be interesting in particular for the power nodes
>> > created by the Barabasi-Albert model of lnd's autopilot (c.f.:
>> > https://github.com/lightningnetwork/lnd/issues/677 ).
>> >
>> > I understand that with the growth of the bitcoin (mining) network a 51%
>> > attack becomes less and less likely. Also I am very happy to be proven
>> > false about the attack that I am describing.
>> >
>> > Another sad thing about this attack is that I currently do not see any
>> > (reasonable) way of preventing this form of a 51% attack (other than
>> > creating payment channels that don't offer the possibility of revocation)
>> > as it is abusing exactly the core idea of lightning to do something in
>> > secret without broadcasting it.
>> >
>> > Best regards Rene
>> >
>> > ---
>> >
>> > http://www.rene-pickhardt.de
>> > _______________________________________________
>> > Lightning-dev mailing list
>> > Lightning-dev@lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
>
>
> --
> www.rene-pickhardt.de
> <http://www.beijing-china-blog.com/>
>
> Skype: rene.pickhardt
>
> mobile: +49 (0)176 5762 3618
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
