Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2021-10-04 📝 Original message: > In other words, simply ...
📅 Original date posted:2021-10-04
📝 Original message:
> In other words, simply not secured.
How do you define Bitcoin base-layer security ? How strong are the
assumptions we're relying on the base-layer ?
Not easy answers :/
> L2s shouldn't build on flawed assumptions.
Waiting for your proposal to scale Bitcoin payments relying on pure
consensus assumptions :)
> No thanks. Not sure that would even help (since policies can always be
set to
a higher dust limit than any consensus rule)
Sure. Policies can always be more restrictive. One of them could be to not
relay transactions at all. If widely-deployed, such policy would make the
network quite unusable....
More seriously, I think when we consider this policy discussion, we should
have more in mind the consequences of adopting a given policy or another
one.
As long as they're economically-compatible, they should be followed by an
economically rational node operator.
I think we're already making that kind of social or economic assumption on
the user behavior w.r.t to full-node design. Blocks and transactions are
relayed for "free" today, not satoshis are received in exchange.
Le lun. 4 oct. 2021 à 12:28, Luke Dashjr <luke at dashjr.org> a écrit :
> On Monday 04 October 2021 16:14:20 Antoine Riard wrote:
> > > The "dust limit" is arbitrarily decided by each node, and cannot be
> > > relied upon for security at all. Expecting it to be a given default
> value
> > > is in itself a security vulnerability
> >
> > Reality is that an increasing number of funds are secured by assumptions
> > around mempool behavior.
>
> In other words, simply not secured.
>
> > And sadly that's going to increase with Lightning growth and deployment
> of
> > other L2s.
>
> L2s shouldn't build on flawed assumptions.
>
> > Maybe we could dry-up some policy rules in consensus like the dust limit
> > one :)
>
> No thanks. Not sure that would even help (since policies can always be set
> to
> a higher dust limit than any consensus rule)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211004/30471001/attachment.html>;
📝 Original message:
> In other words, simply not secured.
How do you define Bitcoin base-layer security ? How strong are the
assumptions we're relying on the base-layer ?
Not easy answers :/
> L2s shouldn't build on flawed assumptions.
Waiting for your proposal to scale Bitcoin payments relying on pure
consensus assumptions :)
> No thanks. Not sure that would even help (since policies can always be
set to
a higher dust limit than any consensus rule)
Sure. Policies can always be more restrictive. One of them could be to not
relay transactions at all. If widely-deployed, such policy would make the
network quite unusable....
More seriously, I think when we consider this policy discussion, we should
have more in mind the consequences of adopting a given policy or another
one.
As long as they're economically-compatible, they should be followed by an
economically rational node operator.
I think we're already making that kind of social or economic assumption on
the user behavior w.r.t to full-node design. Blocks and transactions are
relayed for "free" today, not satoshis are received in exchange.
Le lun. 4 oct. 2021 à 12:28, Luke Dashjr <luke at dashjr.org> a écrit :
> On Monday 04 October 2021 16:14:20 Antoine Riard wrote:
> > > The "dust limit" is arbitrarily decided by each node, and cannot be
> > > relied upon for security at all. Expecting it to be a given default
> value
> > > is in itself a security vulnerability
> >
> > Reality is that an increasing number of funds are secured by assumptions
> > around mempool behavior.
>
> In other words, simply not secured.
>
> > And sadly that's going to increase with Lightning growth and deployment
> of
> > other L2s.
>
> L2s shouldn't build on flawed assumptions.
>
> > Maybe we could dry-up some policy rules in consensus like the dust limit
> > one :)
>
> No thanks. Not sure that would even help (since policies can always be set
> to
> a higher dust limit than any consensus rule)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211004/30471001/attachment.html>;