📅 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>;
Antoine Riard [ARCHIVE] /
npub1vj…4x8dd
2023-06-09 15:03:59
in reply to nevent1q…359g
Author Public Key
npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8ddPublished at
2023-06-09 15:03:59Event JSON
{
"id": "a357b5ac72d4cfe562ef386bd62c3ec44a28a43f9d3e147ee756431c28d25f67",
"pubkey": "6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551",
"created_at": 1686315839,
"kind": 1,
"tags": [
[
"e",
"1d180632202ba667799a8f8e5d81e5c2ea7441ac1cfc58e28276a449e432a17c",
"",
"root"
],
[
"e",
"25eced0ff428a59aba8136e17eb07dd189b778c72ce909cafaad98aff063a13d",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2021-10-04\n📝 Original message:\n\u003e In other words, simply not secured.\n\nHow do you define Bitcoin base-layer security ? How strong are the\nassumptions we're relying on the base-layer ?\nNot easy answers :/\n\n\u003e L2s shouldn't build on flawed assumptions.\n\nWaiting for your proposal to scale Bitcoin payments relying on pure\nconsensus assumptions :)\n\n\u003e No thanks. Not sure that would even help (since policies can always be\nset to\na higher dust limit than any consensus rule)\n\nSure. Policies can always be more restrictive. One of them could be to not\nrelay transactions at all. If widely-deployed, such policy would make the\nnetwork quite unusable....\n\nMore seriously, I think when we consider this policy discussion, we should\nhave more in mind the consequences of adopting a given policy or another\none.\nAs long as they're economically-compatible, they should be followed by an\neconomically rational node operator.\nI think we're already making that kind of social or economic assumption on\nthe user behavior w.r.t to full-node design. Blocks and transactions are\nrelayed for \"free\" today, not satoshis are received in exchange.\n\n\nLe lun. 4 oct. 2021 à 12:28, Luke Dashjr \u003cluke at dashjr.org\u003e a écrit :\n\n\u003e On Monday 04 October 2021 16:14:20 Antoine Riard wrote:\n\u003e \u003e \u003e The \"dust limit\" is arbitrarily decided by each node, and cannot be\n\u003e \u003e \u003e relied upon for security at all. Expecting it to be a given default\n\u003e value\n\u003e \u003e \u003e is in itself a security vulnerability\n\u003e \u003e\n\u003e \u003e Reality is that an increasing number of funds are secured by assumptions\n\u003e \u003e around mempool behavior.\n\u003e\n\u003e In other words, simply not secured.\n\u003e\n\u003e \u003e And sadly that's going to increase with Lightning growth and deployment\n\u003e of\n\u003e \u003e other L2s.\n\u003e\n\u003e L2s shouldn't build on flawed assumptions.\n\u003e\n\u003e \u003e Maybe we could dry-up some policy rules in consensus like the dust limit\n\u003e \u003e one :)\n\u003e\n\u003e No thanks. Not sure that would even help (since policies can always be set\n\u003e to\n\u003e a higher dust limit than any consensus rule)\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211004/30471001/attachment.html\u003e",
"sig": "bbf6cba185970bbf0d66b797ddb58d008b16e4ffaf8452b7c486e46387256fd962e3c86190cbbff2853a2f6b9e3a5714789b06a3a8f2f0cde77048e23349af4d"
}