📅 Original date posted:2018-11-09
📝 Original message:
> How do i unsubscribe from this email list? Could someone help me please.
There’s a link in the footer to the linux list, there you can enter your
email to unsubscribe
Cheers,
Conner
-- Sent from my Spaceship
On Fri, Nov 9, 2018 at 17:19 alexis petropoulos <akexis823 at hotmail.com>
wrote:
> How do i unsubscribe from this email list? Could someone help me please.
>
> Kindly,
>
> Alex
> ------------------------------
> *From:* lightning-dev-bounces at lists.linuxfoundation.org <
> lightning-dev-bounces at lists.linuxfoundation.org> on behalf of Gert-Jaap
> Glasbergen <gertjaap at gertjaap.nl>
> *Sent:* Monday, November 5, 2018 3:48:56 PM
> *To:* lightning-dev at lists.linuxfoundation.org; Rusty Russell
> *Subject:* Re: [Lightning-dev] RFC: simplifications and suggestions on
> open/accept limits.
>
>
> Op 1 nov. 2018 om 03:38 heeft Rusty Russell <rusty at rustcorp.com.au> het
> volgende geschreven:
>
>
> I believe this would render you inoperable in practice; fees are
> frequently sub-satoshi, so you would fail everything. The entire
> network would have to drop millisatoshis, and the bitcoin maximalist in
> me thinks that's unwise :)
>
>
> I can see how not wanting to use millisatoshis makes you less compatible
> with other people that do prefer using that unit of account. But in this
> case I think it's important to allow the freedom to choose.
>
> I essentially feel we should be allowed to respect the confines of the layer
> we're building upon. There's already a lot of benefits to achieve from second
> layer scaling whilst still respecting the limits of the base layer. Staying
> within those limits means optimally benefit form the security it offers.
>
> Essentially by allowing to keep satoshi as the smallest fraction, you ensure
> that everything you do off-chain is also valid and enforced by the chain when
> you need it to. It comes at trade offs though: it would mean that if someone
> routes your payment, you can only pay fees in whole satoshis - essentially
> meaning if someone wants to charge a (small) fee, you will be overpaying to
> stay within your chosen security parameters. Which is a consequence of your
> choice.
>
> I would be happy to make a further analysis on what consequences allowing this
> choice would have for the specification, and come up with a proposal on how to
> add support for this. But I guess this discussion is meant to "test the waters"
> to see how much potential such a proposal would have to eventually be included.
>
> I guess what I'm searching for is a way to achieve the freedom of choice,
> without negatively impacting other clients or users that decide to accept some
> level of trust. In my view, this would be possible - but I think working it out
> in a concrete proposal/RFC to the spec would be a logical next step.
>
> Gert-Jaap
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181109/c820dd77/attachment-0001.html>;
Conner Fromknecht [ARCHIVE] /
npub1za…uua2a
2023-06-09 12:51:58
in reply to nevent1q…eh4m
Author Public Key
npub1za0a9afyj7um5feva0d5xmhfsah3zxm252hna2duq0numa952frqvuua2aPublished at
2023-06-09 12:51:58Event JSON
{
"id": "6149986043b8158dfe07e40183eaffb6c6cd2ce310387ec1f2d3840dee73c137",
"pubkey": "175fd2f52497b9ba272cebdb436ee9876f111b6aa2af3ea9bc03e7cdf4b45246",
"created_at": 1686315118,
"kind": 1,
"tags": [
[
"e",
"c9cdd9e4a2595ac262f22b0a0d9db9260e1433c3622d0a4a06a29ae0cf8c9eea",
"",
"root"
],
[
"e",
"b830c4de0cf77c67b0b9aa16d30f903b761d48e8333df8ee3f095e8b9a4b22fa",
"",
"reply"
],
[
"p",
"5312c43811a848e0aa6c01b003821ff63660a69ca3ee07e10511559a14b11d01"
]
],
"content": "📅 Original date posted:2018-11-09\n📝 Original message:\n\u003e How do i unsubscribe from this email list? Could someone help me please.\n\nThere’s a link in the footer to the linux list, there you can enter your\nemail to unsubscribe\n\nCheers,\nConner\n\n-- Sent from my Spaceship\n\nOn Fri, Nov 9, 2018 at 17:19 alexis petropoulos \u003cakexis823 at hotmail.com\u003e\nwrote:\n\n\u003e How do i unsubscribe from this email list? Could someone help me please.\n\u003e\n\u003e Kindly,\n\u003e\n\u003e Alex\n\u003e ------------------------------\n\u003e *From:* lightning-dev-bounces at lists.linuxfoundation.org \u003c\n\u003e lightning-dev-bounces at lists.linuxfoundation.org\u003e on behalf of Gert-Jaap\n\u003e Glasbergen \u003cgertjaap at gertjaap.nl\u003e\n\u003e *Sent:* Monday, November 5, 2018 3:48:56 PM\n\u003e *To:* lightning-dev at lists.linuxfoundation.org; Rusty Russell\n\u003e *Subject:* Re: [Lightning-dev] RFC: simplifications and suggestions on\n\u003e open/accept limits.\n\u003e\n\u003e\n\u003e Op 1 nov. 2018 om 03:38 heeft Rusty Russell \u003crusty at rustcorp.com.au\u003e het\n\u003e volgende geschreven:\n\u003e\n\u003e\n\u003e I believe this would render you inoperable in practice; fees are\n\u003e frequently sub-satoshi, so you would fail everything. The entire\n\u003e network would have to drop millisatoshis, and the bitcoin maximalist in\n\u003e me thinks that's unwise :)\n\u003e\n\u003e\n\u003e I can see how not wanting to use millisatoshis makes you less compatible\n\u003e with other people that do prefer using that unit of account. But in this\n\u003e case I think it's important to allow the freedom to choose.\n\u003e\n\u003e I essentially feel we should be allowed to respect the confines of the layer\n\u003e we're building upon. There's already a lot of benefits to achieve from second\n\u003e layer scaling whilst still respecting the limits of the base layer. Staying\n\u003e within those limits means optimally benefit form the security it offers.\n\u003e\n\u003e Essentially by allowing to keep satoshi as the smallest fraction, you ensure\n\u003e that everything you do off-chain is also valid and enforced by the chain when\n\u003e you need it to. It comes at trade offs though: it would mean that if someone\n\u003e routes your payment, you can only pay fees in whole satoshis - essentially\n\u003e meaning if someone wants to charge a (small) fee, you will be overpaying to\n\u003e stay within your chosen security parameters. Which is a consequence of your\n\u003e choice.\n\u003e\n\u003e I would be happy to make a further analysis on what consequences allowing this\n\u003e choice would have for the specification, and come up with a proposal on how to\n\u003e add support for this. But I guess this discussion is meant to \"test the waters\"\n\u003e to see how much potential such a proposal would have to eventually be included.\n\u003e\n\u003e I guess what I'm searching for is a way to achieve the freedom of choice,\n\u003e without negatively impacting other clients or users that decide to accept some\n\u003e level of trust. In my view, this would be possible - but I think working it out\n\u003e in a concrete proposal/RFC to the spec would be a logical next step.\n\u003e\n\u003e Gert-Jaap\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181109/c820dd77/attachment-0001.html\u003e",
"sig": "106b665dd477d475361b41599c4c9c3eebe15c2f1747fab1ce25fc8a1ebf634131e556b16ee319ee5d0443e5a4871ebcc2b2ce4e05c567a109d7727aa1b7d79f"
}