René Pickhardt [ARCHIVE] on Nostr: 📅 Original date posted:2018-03-13 📝 Original message: Hey Christian, I agree ...
đź“… Original date posted:2018-03-13
đź“ť Original message:
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.christian at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180313/b1e24dd5/attachment-0001.html>;
đź“ť Original message:
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.christian at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180313/b1e24dd5/attachment-0001.html>;