đź“… Original date posted:2023-05-02
🗒️ Summary of this message: The writer is interested in the differences between libbitcoinkernel and libconsensus, and wanted to make node policy polymorphic. They also ask about the "bitcoin-inquisition" default signet and seek a forum to defend themselves.
đź“ť Original message:
I'm not familiar with libbitcoinkernel, but sounds similar to what I wanted
libconsensus to do (different from what matt corallo wanted). What would be
the differences?
Regarding node policy, I also wanted to make it polymorphic and let the
user chose RBF or the default of the time.
I can't remember the arguments against it.
Why do you call the default signet "bitcoin-inquisition" ?
I'm sorry if some of my inquires are offtopic for this mailing list, but I
no longer follow the main bitcoin mailing list for reasons that are
definitely offtopic to this mailing list (and apparently offtopic for
twitter and youtube too).
I'm all in favor of public communication, but I don't want to be kicked out
from this list.
So I'm happy to follow up this discussion privately too if it gets too
offtopic.
I know this is not the appropriate forum to publicly defend myself from
public attacks against me. Is there any forum appropriate for that?
I'm afraid not, nostr perhaps.
Anyway, sorry for the offtopic.
Keep up the good work, everyone.
On Sun, Apr 30, 2023 at 3:57 AM niftynei <niftynei at gmail.com> wrote:
> Hi Michael,
>
> CLN as implemented is currently nicely decoupled from the block source; as
> a project we assume that the node runner will choose a block backend that
> fits their self-sovereignty goals.
>
> This provides us with a nice separation of concerns. The block source is
> responsible for ensuring that only consensus valid data is delivered to the
> node, which in turn allows us to focus on processing and reacting to that
> data, as necessary.
>
> Bitcoin core as a project implements a broad swath of functionality
> (wallet, consensus, peering, rpc server, coin selection, key management,
> etc); breaking out the validation and peering functions into more
> composable parts would def open up more opportunities for building block
> sources for a wide variety of projects, not just CLN.
>
> There’s probably a real opportunity to “comingle” the peering of LN gossip
> + block data networks, this has been suggested a few times but never
> seriously pursued from the LN side. Having the peering functions of
> bitcoin-core broken out into a more composable/reusable piece may be a good
> first step here, and as a project would largely be on the bitcoin core
> side. Maybe this work is already in progress? I havent been keeping up with
> developments there.
>
> Thanks for the email, it’s definitely a good question.
>
> Lisa
>
>
> On Mon, Apr 24, 2023 at 02:09 Michael Folkson via Lightning-dev <
> lightning-dev at lists.linuxfoundation.org> wrote:
>
>> Any thoughts on this from the Core Lightning contributors? The way I see
>> it with upcoming proposed changes to default policy (primarily though not
>> exclusively for Lightning) and a soft fork activation attempt of APO/APOAS
>> (primarily though not exclusively for Lightning) that a tighter coupling
>> between the full node and the Lightning node could eventually make sense.
>> In a world where transaction fees were much higher you'd think almost every
>> full node would also want to be a Lightning node and so the separation of
>> concerns would make less sense. Having two separate P2P networks and two
>> separate P2P protocols also wouldn't make much sense in this scenario. You
>> could obviously still opt out of Lightning P2P messages if you weren't
>> interested in Lightning.
>>
>> The alternative would be just to focus on Knots style consensus
>> compatible forks of Core with limited additional functionality. But I think
>> we've reached the point of no return on Core dominance and not having
>> widely used "distros". As the ecosystem scales systems and processes should
>> be constantly evolving and improving and to me if anything Core's seem to
>> be going backwards.
>>
>> Thanks
>> Michael
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at protonmail.com
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> ------- Original Message -------
>>
>> On Saturday, January 14th, 2023 at 20:26, Michael Folkson <
>> michaelfolkson at protonmail.com> wrote:
>>
>> I tweeted this [0] back in November 2022.
>>
>> "With the btcd bugs and the analysis paralysis on a RBF policy option in
>> Core increasingly thinking @BitcoinKnots and consensus compatible forks of
>> Core are the future. Gonna chalk that one up to another thing @LukeDashjr
>> was right about all along."
>>
>> A new bare bones Knots style Bitcoin implementation (in C++/C) integrated
>> with Core Lightning was a long term idea I had (and presumably many others
>> have had) but the dysfunction on the Bitcoin Core project this week (if
>> anything it has been getting worse over time, not better) has made me start
>> to take the idea more seriously. It is clear to me that the current way the
>> Bitcoin Core project is being managed is not how I would like an open
>> source project to be managed. Very little discussion is public anymore and
>> decisions seem to be increasingly made behind closed doors or in private
>> IRC channels (to the extent that decisions are made at all). Core Lightning
>> seems to have the opposite problem. It is managed effectively in the open
>> (admittedly with fewer contributors) but doesn't have the eyeballs or the
>> usage that Bitcoin Core does. Regardless, selfishly I at some point would
>> like a bare bones Bitcoin and Lightning implementation integrated in one
>> codebase. The Bitcoin Core codebase has collected a lot of cruft over time
>> and the ultra conservatism that is needed when treating (potential)
>> consensus code seems to permeate into parts of the codebase that no one is
>> using, definitely isn't consensus code and should probably just be removed.
>>
>> The libbitcoinkernel project was (is?) an attempt to extract the
>> consensus engine out of Core but it seems like it won't achieve that as
>> consensus is just too slippery a concept and Knots style consensus
>> compatible codebase forks of Bitcoin Core seem to still the model. To what
>> extent you can safely chop off this cruft and effectively maintain this
>> less crufty fork of Bitcoin Core also isn't clear to me yet.
>>
>> Then there is the question of whether it makes sense to mix C and C++
>> code that people have different views on. C++ is obviously a superset of C
>> but assuming this merging of Bitcoin Core and Core Lightning is/was the
>> optimal final destination it surely would have been better if Core
>> Lightning was written in the same language (i.e. with classes) as Bitcoin
>> Core.
>>
>> I'm just floating the idea to (hopefully) hear from people who are much
>> more familiar with the entirety of the Bitcoin Core and Core Lightning
>> codebases. It would be an ambitious long term project but it would be nice
>> to focus on some ambitious project(s) (even if just conceptually) for a
>> while given (thankfully) there seems to be a lull in soft fork activation
>> chaos.
>>
>> Thanks
>> Michael
>>
>> [0]:
>> https://twitter.com/michaelfolkson/status/1589220155006910464?s=20&t=GbPm7w5BqS7rS3kiVFTNcw
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at protonmail.com
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> _______________________________________________
> 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/20230502/66c578d7/attachment-0001.html>;
Jorge TimĂłn [ARCHIVE] /
npub1fx…cl2d8
2023-06-19 17:42:12
in reply to nevent1q…8u0y
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Published at
2023-06-19 17:42:12Event JSON
{
"id": "99c74466bae17fac718d466717825cfd87063fa1e1b639fb728cbffba47dc0ca",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1687196532,
"kind": 1,
"tags": [
[
"e",
"1ea593d31c710d1681d53a25d4ebd42a755d9f7bc84d134c330271828cdcfa45",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2023-05-02\n🗒️ Summary of this message: The writer is interested in the differences between libbitcoinkernel and libconsensus, and wanted to make node policy polymorphic. They also ask about the \"bitcoin-inquisition\" default signet and seek a forum to defend themselves.\n📝 Original message:\nI'm not familiar with libbitcoinkernel, but sounds similar to what I wanted\nlibconsensus to do (different from what matt corallo wanted). What would be\nthe differences?\n\nRegarding node policy, I also wanted to make it polymorphic and let the\nuser chose RBF or the default of the time.\nI can't remember the arguments against it.\n\nWhy do you call the default signet \"bitcoin-inquisition\" ?\n\nI'm sorry if some of my inquires are offtopic for this mailing list, but I\nno longer follow the main bitcoin mailing list for reasons that are\ndefinitely offtopic to this mailing list (and apparently offtopic for\ntwitter and youtube too).\n\nI'm all in favor of public communication, but I don't want to be kicked out\nfrom this list.\nSo I'm happy to follow up this discussion privately too if it gets too\nofftopic.\n\nI know this is not the appropriate forum to publicly defend myself from\npublic attacks against me. Is there any forum appropriate for that?\nI'm afraid not, nostr perhaps.\n\nAnyway, sorry for the offtopic.\nKeep up the good work, everyone.\n\n\nOn Sun, Apr 30, 2023 at 3:57 AM niftynei \u003cniftynei at gmail.com\u003e wrote:\n\n\u003e Hi Michael,\n\u003e\n\u003e CLN as implemented is currently nicely decoupled from the block source; as\n\u003e a project we assume that the node runner will choose a block backend that\n\u003e fits their self-sovereignty goals.\n\u003e\n\u003e This provides us with a nice separation of concerns. The block source is\n\u003e responsible for ensuring that only consensus valid data is delivered to the\n\u003e node, which in turn allows us to focus on processing and reacting to that\n\u003e data, as necessary.\n\u003e\n\u003e Bitcoin core as a project implements a broad swath of functionality\n\u003e (wallet, consensus, peering, rpc server, coin selection, key management,\n\u003e etc); breaking out the validation and peering functions into more\n\u003e composable parts would def open up more opportunities for building block\n\u003e sources for a wide variety of projects, not just CLN.\n\u003e\n\u003e There’s probably a real opportunity to “comingle” the peering of LN gossip\n\u003e + block data networks, this has been suggested a few times but never\n\u003e seriously pursued from the LN side. Having the peering functions of\n\u003e bitcoin-core broken out into a more composable/reusable piece may be a good\n\u003e first step here, and as a project would largely be on the bitcoin core\n\u003e side. Maybe this work is already in progress? I havent been keeping up with\n\u003e developments there.\n\u003e\n\u003e Thanks for the email, it’s definitely a good question.\n\u003e\n\u003e Lisa\n\u003e\n\u003e\n\u003e On Mon, Apr 24, 2023 at 02:09 Michael Folkson via Lightning-dev \u003c\n\u003e lightning-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e Any thoughts on this from the Core Lightning contributors? The way I see\n\u003e\u003e it with upcoming proposed changes to default policy (primarily though not\n\u003e\u003e exclusively for Lightning) and a soft fork activation attempt of APO/APOAS\n\u003e\u003e (primarily though not exclusively for Lightning) that a tighter coupling\n\u003e\u003e between the full node and the Lightning node could eventually make sense.\n\u003e\u003e In a world where transaction fees were much higher you'd think almost every\n\u003e\u003e full node would also want to be a Lightning node and so the separation of\n\u003e\u003e concerns would make less sense. Having two separate P2P networks and two\n\u003e\u003e separate P2P protocols also wouldn't make much sense in this scenario. You\n\u003e\u003e could obviously still opt out of Lightning P2P messages if you weren't\n\u003e\u003e interested in Lightning.\n\u003e\u003e\n\u003e\u003e The alternative would be just to focus on Knots style consensus\n\u003e\u003e compatible forks of Core with limited additional functionality. But I think\n\u003e\u003e we've reached the point of no return on Core dominance and not having\n\u003e\u003e widely used \"distros\". As the ecosystem scales systems and processes should\n\u003e\u003e be constantly evolving and improving and to me if anything Core's seem to\n\u003e\u003e be going backwards.\n\u003e\u003e\n\u003e\u003e Thanks\n\u003e\u003e Michael\n\u003e\u003e\n\u003e\u003e --\n\u003e\u003e Michael Folkson\n\u003e\u003e Email: michaelfolkson at protonmail.com\n\u003e\u003e Keybase: michaelfolkson\n\u003e\u003e PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3\n\u003e\u003e\n\u003e\u003e ------- Original Message -------\n\u003e\u003e\n\u003e\u003e On Saturday, January 14th, 2023 at 20:26, Michael Folkson \u003c\n\u003e\u003e michaelfolkson at protonmail.com\u003e wrote:\n\u003e\u003e\n\u003e\u003e I tweeted this [0] back in November 2022.\n\u003e\u003e\n\u003e\u003e \"With the btcd bugs and the analysis paralysis on a RBF policy option in\n\u003e\u003e Core increasingly thinking @BitcoinKnots and consensus compatible forks of\n\u003e\u003e Core are the future. Gonna chalk that one up to another thing @LukeDashjr\n\u003e\u003e was right about all along.\"\n\u003e\u003e\n\u003e\u003e A new bare bones Knots style Bitcoin implementation (in C++/C) integrated\n\u003e\u003e with Core Lightning was a long term idea I had (and presumably many others\n\u003e\u003e have had) but the dysfunction on the Bitcoin Core project this week (if\n\u003e\u003e anything it has been getting worse over time, not better) has made me start\n\u003e\u003e to take the idea more seriously. It is clear to me that the current way the\n\u003e\u003e Bitcoin Core project is being managed is not how I would like an open\n\u003e\u003e source project to be managed. Very little discussion is public anymore and\n\u003e\u003e decisions seem to be increasingly made behind closed doors or in private\n\u003e\u003e IRC channels (to the extent that decisions are made at all). Core Lightning\n\u003e\u003e seems to have the opposite problem. It is managed effectively in the open\n\u003e\u003e (admittedly with fewer contributors) but doesn't have the eyeballs or the\n\u003e\u003e usage that Bitcoin Core does. Regardless, selfishly I at some point would\n\u003e\u003e like a bare bones Bitcoin and Lightning implementation integrated in one\n\u003e\u003e codebase. The Bitcoin Core codebase has collected a lot of cruft over time\n\u003e\u003e and the ultra conservatism that is needed when treating (potential)\n\u003e\u003e consensus code seems to permeate into parts of the codebase that no one is\n\u003e\u003e using, definitely isn't consensus code and should probably just be removed.\n\u003e\u003e\n\u003e\u003e The libbitcoinkernel project was (is?) an attempt to extract the\n\u003e\u003e consensus engine out of Core but it seems like it won't achieve that as\n\u003e\u003e consensus is just too slippery a concept and Knots style consensus\n\u003e\u003e compatible codebase forks of Bitcoin Core seem to still the model. To what\n\u003e\u003e extent you can safely chop off this cruft and effectively maintain this\n\u003e\u003e less crufty fork of Bitcoin Core also isn't clear to me yet.\n\u003e\u003e\n\u003e\u003e Then there is the question of whether it makes sense to mix C and C++\n\u003e\u003e code that people have different views on. C++ is obviously a superset of C\n\u003e\u003e but assuming this merging of Bitcoin Core and Core Lightning is/was the\n\u003e\u003e optimal final destination it surely would have been better if Core\n\u003e\u003e Lightning was written in the same language (i.e. with classes) as Bitcoin\n\u003e\u003e Core.\n\u003e\u003e\n\u003e\u003e I'm just floating the idea to (hopefully) hear from people who are much\n\u003e\u003e more familiar with the entirety of the Bitcoin Core and Core Lightning\n\u003e\u003e codebases. It would be an ambitious long term project but it would be nice\n\u003e\u003e to focus on some ambitious project(s) (even if just conceptually) for a\n\u003e\u003e while given (thankfully) there seems to be a lull in soft fork activation\n\u003e\u003e chaos.\n\u003e\u003e\n\u003e\u003e Thanks\n\u003e\u003e Michael\n\u003e\u003e\n\u003e\u003e [0]:\n\u003e\u003e https://twitter.com/michaelfolkson/status/1589220155006910464?s=20\u0026t=GbPm7w5BqS7rS3kiVFTNcw\n\u003e\u003e\n\u003e\u003e --\n\u003e\u003e Michael Folkson\n\u003e\u003e Email: michaelfolkson at protonmail.com\n\u003e\u003e Keybase: michaelfolkson\n\u003e\u003e PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e Lightning-dev mailing list\n\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\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/20230502/66c578d7/attachment-0001.html\u003e",
"sig": "490142813e4e76673b348231fcf44e9519576c6c4f10886e20ba14903fe642606bf4fee2e6b2918b9fb3a1e67d177fc27f67c6bdc8594a3f56445c816aa00bd6"
}