Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2020-05-06 📝 Original message: I do see the consensus ...
📅 Original date posted:2020-05-06
📝 Original message:
I do see the consensus capture argument by miners but in reality isn't this
attack scenario have a lot of assumptions on topology an deployment ?
For such attack to succeed you need miners nodes to be connected to clients
to feed directly the invalid headers and if these ones are connected to
headers/filters gateways, themselves doing full-nodes validation invalid
chain is going to be sanitized out ?
Sure now you trust these gateways, but if you have multiple connections to
them and can guarantee they aren't run by the same entity, that maybe an
acceptable security model, depending of staked amount and your
expectations. I more concerned of having a lot of them and being
diversified enough to avoid collusion between gateways/chain access
providers/miners.
But even if you light clients is directly connected to the backbone network
and may be reached by miners you can implement fork anomalies detection and
from then you may have multiples options:
* halt the wallet, wait for human intervention
* fallback connection to a trusted server, authoritative on your chain view
* invalidity proofs?
Now I agree you need a wide-enough, sane backbone network to build on top,
and we should foster node adoption as much as we can.
Le mar. 5 mai 2020 à 09:01, Luke Dashjr <luke at dashjr.org> a écrit :
> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
> > Trust-minimization of Bitcoin security model has always relied first and
> > above on running a full-node. This current paradigm may be shifted by LN
> > where fast, affordable, confidential, censorship-resistant payment
> services
> > may attract a lot of adoption without users running a full-node.
>
> No, it cannot be shifted. This would compromise Bitcoin itself, which for
> security depends on the assumption that a supermajority of the economy is
> verifying their incoming transactions using their own full node.
>
> The past few years has seen severe regressions in this area, to the point
> where Bitcoin's future seems quite bleak. Without serious improvements to
> the
> full node ratio, Bitcoin is likely to fail.
>
> Therefore, all efforts to improve the "full node-less" experience are
> harmful,
> and should be actively avoided. BIP 157 improves privacy of fn-less usage,
> while providing no real benefits to full node users (compared to more
> efficient protocols like Stratum/Electrum).
>
> For this reason, myself and a few others oppose merging support for BIP
> 157 in
> Core.
>
> > Assuming a user adoption path where a full-node is required to benefit
> for
> > LN may deprive a lot of users, especially those who are already denied a
> > real financial infrastructure access.
>
> If Bitcoin can't do it, then Bitcoin can't do it.
> Bitcoin can't solve *any* problem if it becomes insecure itself.
>
> Luke
>
> P.S. See also
>
> https://medium.com/@nicolasdorier/why-i-dont-celebrate-neutrino-206bafa5fda0
>
> https://medium.com/@nicolasdorier/neutrino-is-dangerous-for-my-self-sovereignty-18fac5bcdc25
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200506/7b20c4d4/attachment.html>;
📝 Original message:
I do see the consensus capture argument by miners but in reality isn't this
attack scenario have a lot of assumptions on topology an deployment ?
For such attack to succeed you need miners nodes to be connected to clients
to feed directly the invalid headers and if these ones are connected to
headers/filters gateways, themselves doing full-nodes validation invalid
chain is going to be sanitized out ?
Sure now you trust these gateways, but if you have multiple connections to
them and can guarantee they aren't run by the same entity, that maybe an
acceptable security model, depending of staked amount and your
expectations. I more concerned of having a lot of them and being
diversified enough to avoid collusion between gateways/chain access
providers/miners.
But even if you light clients is directly connected to the backbone network
and may be reached by miners you can implement fork anomalies detection and
from then you may have multiples options:
* halt the wallet, wait for human intervention
* fallback connection to a trusted server, authoritative on your chain view
* invalidity proofs?
Now I agree you need a wide-enough, sane backbone network to build on top,
and we should foster node adoption as much as we can.
Le mar. 5 mai 2020 à 09:01, Luke Dashjr <luke at dashjr.org> a écrit :
> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
> > Trust-minimization of Bitcoin security model has always relied first and
> > above on running a full-node. This current paradigm may be shifted by LN
> > where fast, affordable, confidential, censorship-resistant payment
> services
> > may attract a lot of adoption without users running a full-node.
>
> No, it cannot be shifted. This would compromise Bitcoin itself, which for
> security depends on the assumption that a supermajority of the economy is
> verifying their incoming transactions using their own full node.
>
> The past few years has seen severe regressions in this area, to the point
> where Bitcoin's future seems quite bleak. Without serious improvements to
> the
> full node ratio, Bitcoin is likely to fail.
>
> Therefore, all efforts to improve the "full node-less" experience are
> harmful,
> and should be actively avoided. BIP 157 improves privacy of fn-less usage,
> while providing no real benefits to full node users (compared to more
> efficient protocols like Stratum/Electrum).
>
> For this reason, myself and a few others oppose merging support for BIP
> 157 in
> Core.
>
> > Assuming a user adoption path where a full-node is required to benefit
> for
> > LN may deprive a lot of users, especially those who are already denied a
> > real financial infrastructure access.
>
> If Bitcoin can't do it, then Bitcoin can't do it.
> Bitcoin can't solve *any* problem if it becomes insecure itself.
>
> Luke
>
> P.S. See also
>
> https://medium.com/@nicolasdorier/why-i-dont-celebrate-neutrino-206bafa5fda0
>
> https://medium.com/@nicolasdorier/neutrino-is-dangerous-for-my-self-sovereignty-18fac5bcdc25
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200506/7b20c4d4/attachment.html>;