From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 2248FC002D for ; Mon, 16 Jan 2023 15:45:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id EFAA0408DF for ; Mon, 16 Jan 2023 15:45:58 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org EFAA0408DF Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=Afe2ktAi X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPGsAJytFIcQ for ; Mon, 16 Jan 2023 15:45:57 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 6FAF9408CA Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) by smtp4.osuosl.org (Postfix) with ESMTPS id 6FAF9408CA for ; Mon, 16 Jan 2023 15:45:57 +0000 (UTC) Date: Mon, 16 Jan 2023 15:45:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1673883954; x=1674143154; bh=tTDN2WdDSgdRBVEbMy09a2SrooUTHeWnbpCDmjmqPs8=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=Afe2ktAiMJO38yVqyxkfCVgWq60GuFY7j2v83++PbeE/iKFC1GU0SylWkQ3UTkhJB /HWV6jomBUIUeCzVk0euxvjjVOhHZi+wen04Ix9ox4Z7YlRu3XN+Kodk7EiHPOtdg2 b4eTWpzpWqP/gurYYrC8QZL4vZwwLeoOZgtqDM/vlv9Y0yZpxaku9XCwhc1yWwLsrq ihpcWckHGF+HMrBINlkiNV17o5c25TnM526gq5K86aqUTZhp8RCPEAO9VKep+x9h/6 QP8ecp+ws5quojL9M9PjdZ0T6udS5J72qrexip/fy4nxh8ISidXBxPnU2poAf0LM7e WT5mGO+pcFEyg== To: alicexbt From: Michael Folkson Message-ID: In-Reply-To: References: Feedback-ID: 27732268:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 16 Jan 2023 15:49:13 +0000 Cc: Bitcoin Protocol Discussion 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: Mon, 16 Jan 2023 15:45:59 -0000 Hi alicexbt Thanks for the suggestion. I'll take a look at the branch. I'm personally pretty bullish on Lightning and Core Lightning is criminally= underused. Plus it is more exciting (and hopefully will attract more contr= ibutors) to try something ambitious than just trim Core. I'll see if it is = something the Core Lightning contributors might be interested in helping ou= t on. I remember that Rusty said on a podcast that if he had another life h= e'd have liked to have worked on Core. This way he could potentially do bot= h :) 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 Sunday, January 15th, 2023 at 12:58, alicexbt = wrote: > Hi Michael, >=20 > If I were to fork bitcoin core and maintain an implementation, I wouldn't= integrate any lightning implementation with it. Instead remove some things= from bitcoin core and keep it simple. There is also scope for improving pr= ivacy. Example: https://github.com/bitcoinknots/bitcoin/issues/50 >=20 > You might find the commits in this branch interesting if you are looking = to remove things from bitcoin core and maintain an implementation with no g= ui, wallet, less RPCs etc. >=20 > https://github.com/jeremyRubin/bitcoin/commits/delete-it-all >=20 >=20 > /dev/fd0 > floppy disc guy >=20 > Sent with Proton Mail secure email. >=20 > ------- Original Message ------- > On Sunday, January 15th, 2023 at 1:56 AM, Michael Folkson via Lightning-d= ev lightning-dev@lists.linuxfoundation.org wrote: >=20 >=20 >=20 > > I tweeted this 0 back in November 2022. > >=20 > > "With the btcd bugs and the analysis paralysis on a RBF policy option i= n Core increasingly thinking @BitcoinKnots and consensus compatible forks o= f Core are the future. Gonna chalk that one up to another thing @LukeDashjr= was right about all along." > >=20 > > A new bare bones Knots style Bitcoin implementation (in C++/C) integrat= ed with Core Lightning was a long term idea I had (and presumably many othe= rs 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 th= e Bitcoin Core project is being managed is not how I would like an open sou= rce project to be managed. Very little discussion is public anymore and dec= isions 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 seem= s to have the opposite problem. It is managed effectively in the open (admi= ttedly 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 u= ltra conservatism that is needed when treating (potential) consensus code s= eems to permeate into parts of the codebase that no one is using, definitel= y isn't consensus code and should probably just be removed. > >=20 > > The libbitcoinkernel project was (is?) an attempt to extract the consen= sus 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 codeba= se forks of Bitcoin Core seem to still the model. To what extent you can sa= fely chop off this cruft and effectively maintain this less crufty fork of = Bitcoin Core also isn't clear to me yet. > >=20 > > Then there is the question of whether it makes sense to mix C and C++ c= ode that people have different views on. C++ is obviously a superset of C b= ut assuming this merging of Bitcoin Core and Core Lightning is/was the opti= mal final destination it surely would have been better if Core Lightning wa= s written in the same language (i.e. with classes) as Bitcoin Core. > >=20 > > 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 cod= ebases. 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. > >=20 > > Thanks > > Michael > >=20 > > -- > > Michael Folkson > > Email: michaelfolkson at protonmail.com > > Keybase: michaelfolkson > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3