Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 729C7C002A; Sat, 6 May 2023 06:05:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 399B14044F; Sat, 6 May 2023 06:05:16 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 399B14044F Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=mattcorallo.com header.i=@mattcorallo.com header.a=rsa-sha256 header.s=1683351661 header.b=UpCzkaob; dkim=pass (2048-bit key) header.d=clients.mail.as397444.net header.i=@clients.mail.as397444.net header.a=rsa-sha256 header.s=1683351663 header.b=PIIQjQVb X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O_zl_0NkHWTk; Sat, 6 May 2023 06:05:15 +0000 (UTC) X-Greylist: delayed 00:06:06 by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org E1BFC400D8 X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from mail.as397444.net (mail.as397444.net [IPv6:2620:6e:a000:1::99]) by smtp2.osuosl.org (Postfix) with ESMTPS id E1BFC400D8; Sat, 6 May 2023 06:05:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mattcorallo.com; s=1683351661; h=To:In-Reply-To:Cc:References:Subject:From: From:Subject:To:Cc:Reply-To; bh=M1qGgwkwDDXnwk3Mq7ZfWQP89mk9ZRR+c4tgeLkpikE=; b=UpCzkaob8VooLMa0+qsPnjDNz9uHPgi7TF0rQfSxFNZC8qvb2x/2QM3XXbbI6D5V3LoMIdQQf/E 1Pgry/U5OrH6RXdT8MDk12kKe+L3rS65nJkOjHFGBZMXxpWPw4wh2NlhDQ2lpBC8OfXn75g63x7v3 dkrivqhsPGW06pHD4+qpA/M/jFTjltXU4DyUKHx8pwFUgCjslNp5LNONdanInTWfxh2izKHR2tbMD JKRlpZdfkMUGnzvFgdWVOL2JmFYi0d4CMrVmKN8Wy7+SLjOujV1vY/v/qnkQx/bGNhFqi86HfYv1i xYQPLVf0QWqCY8FLlgr6boBT+3sbTbX2tvKg==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=clients.mail.as397444.net; s=1683351663; h=To:In-Reply-To:Cc:References: Subject:From:From:Subject:To:Cc:Reply-To; bh=M1qGgwkwDDXnwk3Mq7ZfWQP89mk9ZRR+c4tgeLkpikE=; b=PIIQjQVbs/gDpoW8FyRyAgHMKU 2IDgWs3VbDll8ZfwlGIeJ0udeJqakWChVMJ7FvAfK8DIUKyJ2LfPXtJH7NgV0qfQV1w4+hRAtRBF7 WQPkC9gKrZ1VkIEl4VAKNYnyQ67fOqg19flqRZUz7rcbBIZDBF+N6YwNUUtN0ydNNuRFNhU+hyktA MO1k/ozxooby8QtSG0hDR/wZECo/gqpWKDrGZgroJ6jpfsblfh3DgTfT5wDfs1MBzZr51E/g7+SZx EzPdFsd9JzlJ8N0Z7tQcQdr54+GK6ZNeDlwhGIs0Nq8lV6cq3ofdFYliNTpxvP7uoXDFbMtXGVfih oiudqF3A==; Received: by mail.as397444.net with esmtpsa (TLS1.3) (Exim) (envelope-from ) id 1pvAwi-00DYXI-2b; Sat, 06 May 2023 05:59:05 +0000 Content-Type: multipart/alternative; boundary=Apple-Mail-912C2163-CCD9-4188-9ABC-638C3467BC6E Content-Transfer-Encoding: 7bit From: Matt Corallo Mime-Version: 1.0 (1.0) Date: Fri, 5 May 2023 22:58:55 -0700 Message-Id: References: In-Reply-To: To: Michael Folkson , Bitcoin Protocol Discussion X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/mattcorallo.com X-DKIM-Note: For more info, see https://as397444.net/dkim/ Cc: Lightning Dev Subject: Re: [bitcoin-dev] [Lightning-dev] A new Bitcoin implementation integrated with Core Lightning X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2023 06:05:16 -0000 --Apple-Mail-912C2163-CCD9-4188-9ABC-638C3467BC6E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi M= ichael,

While I don=E2=80=99= t think forks of Core with an intent to drive consensus rule changes (or lac= k thereof) benefits the bitcoin system as the Bitcoin Core project stands to= day, if you want to build a nice full node wallet with lightning based on a f= ork of Core, there was code written to do this some years ago.


It never went anywhere as lightning= (and especially LDK!) were far from ready to be a first class feature in bi= tcoin core at the time (and I=E2=80=99d argue still today), but as a separat= e project it could be interesting, at least if maintenance burden were kept t= o a sustainable level.

Matt=

= On Jan 14, 2023, at 13:03, Michael Folkson via Lightning-dev <lightning-d= ev@lists.linuxfoundation.org> wrote:

=EF=BB=BF
I tweeted this [0] back in November 2022.

"With the btcd bugs and the analysis paralysis on a R= BF policy option in Core increasingly thinking @BitcoinKnots and consensus c= ompatible forks of Core are the future. Gonna chalk that one up to another t= hing @LukeDashjr was right about all along."

A new bare bones Knots style Bitcoin implementation (in C++/C) i= ntegrated with Core Lightning was a long term idea I had (and presumably man= y 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 s= tart 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 s= ource project to be managed. Very little discussion is public anymore and de= cisions seem to be increasingly made behind closed doors or in private IRC c= hannels (to the extent that decisions are made at all). Core Lightning seems= to have the opposite problem. It is managed effectively in the open (admitt= edly with fewer contributors) but doesn't have the eyeballs or the usage tha= t Bitcoin Core does. Regardless, selfishly I at some point would like a bare= bones Bitcoin and Lightning implementation integrated in one codebase. The B= itcoin Core codebase has collected a lot of cruft over time and the ultra co= nservatism that is needed when treating (potential) consensus code seems to p= ermeate into parts of the codebase that no one is using, definitely isn't co= nsensus code and should probably just be removed.

The libbitcoinkernel project was (is?) an attempt to extrac= t the consensus engine out of Core but it seems like it won't achieve that a= s consensus is just too slippery a concept and Knots style consensus compati= ble codebase forks of Bitcoin Core seem to still the model. To what extent y= ou can safely chop off this cruft and effectively maintain this less crufty f= ork 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 supers= et of C but assuming this merging of Bitcoin Core and Core Lightning is/was t= he optimal final destination it surely would have been better if Core Lightn= ing was written in the same language (i.e. with classes) as Bitcoin Core.

I'm just floating the idea to (hopefu= lly) hear from people who are much more familiar with the entirety of the Bi= tcoin Core and Core Lightning codebases. It would be an ambitious long term p= roject but it would be nice to focus on some ambitious project(s) (even if j= ust conceptually) for a while given (thankfully) there seems to be a lull in= soft fork activation chaos.

Than= ks
Michael


--
= Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40= EAF4 9835 92D6 0159 214C FEE3
=20
=20
_______________________________________________
Lightn= ing-dev mailing list
Lightning-dev@lists.linuxfoundation.org=
https://lists.linuxfoundation.org/mailman/listinfo/lightnin= g
= --Apple-Mail-912C2163-CCD9-4188-9ABC-638C3467BC6E--