summaryrefslogtreecommitdiff
path: root/b5/d721048727b9dc986dc381d99ae8481957f9a4
blob: 76ca5895ac8f98f095fe11a0f37e6dc8902c4468 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
Return-Path: <kkarasavvas@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D1DDEC002A;
 Wed, 19 Apr 2023 09:05:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id B7CEA41ECF;
 Wed, 19 Apr 2023 09:05:24 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org B7CEA41ECF
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=UF9y8s6e
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 MfJ_mWz2dSHL; Wed, 19 Apr 2023 09:05:22 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org A3C7941EC7
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yw1-x112e.google.com (mail-yw1-x112e.google.com
 [IPv6:2607:f8b0:4864:20::112e])
 by smtp4.osuosl.org (Postfix) with ESMTPS id A3C7941EC7;
 Wed, 19 Apr 2023 09:05:22 +0000 (UTC)
Received: by mail-yw1-x112e.google.com with SMTP id
 00721157ae682-54fe3cd445aso185795047b3.5; 
 Wed, 19 Apr 2023 02:05:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1681895121; x=1684487121;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=THgzz2VXYr93qhysq+1nUy9qy1oFs2NP5jm1h905B+Y=;
 b=UF9y8s6eOQZF+sujjpcBoZ6bi+Z+nUh29VbLx1WoYSagG2rCTo2mza0Y+wZj1Y5ppO
 Puqi7yalPd2fSl3uWmNx8LTZ4CsREnK+k57uskUVfTthIh+5c71S9C0ai7TJC0q/ZfI2
 aYFHYDo/VkMy1Tn19pDaHLnPd61w6XooWXDzze6NbLFvixLs3UWAcWJkDkkN4VBziMGw
 BlnyTa2t2hDc/FQ9o9m1z495roHG/sb7yxK8CVO2C+Z2qjy1nhSMEpu7XfCKr9P3qqMd
 R61osidFg79rbT5cnK+f/53kbUEUFlO0foR3vVes5LyIrZ00or3qWy1WSgIBCGgbYWEy
 9vHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1681895121; x=1684487121;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=THgzz2VXYr93qhysq+1nUy9qy1oFs2NP5jm1h905B+Y=;
 b=cwhaSL1I83EXnh5UY0txLILB4JCLozbmAfJrY2l8mrX3V7fOCUbReqfdv3u0gEuxzR
 yccIgs3NWkgCWmfvfZ1EjacMVYlLHfyelBRrVYE4bQIdbfOXO3KS3wAgLkP2AE2911ae
 qgbOnVXxsTNUXxe7a3E7SFU2fYTwNJuE302V0Sjs5T7+s7K3Se6uYJq4tGeoiDlEv1iy
 Vj4m8kuBNCbFZCPqb+PmSb6pCcKDh9kymOSPCmLMbvfl6XzPTmdRDnUNiI6a50rzKucB
 G+8oJb7V2fqfJAdd9MialwM/CR2DmyEsNMPU0MMFbYkQuYETo1sMLyfTxyXbj+BVYS9P
 fqZA==
X-Gm-Message-State: AAQBX9daWsNgt3ocKDujoIzungcYK6YhgWFc+1mSO0D+MFM8UHvLPYZZ
 SYJYXVyJZY2rL0lopZooLlZvXWpqN4HpZoGCZzshUdk5yI4=
X-Google-Smtp-Source: AKy350ZyzWapOXncW4yFfMWHpI2796SxhyPqX0WiwKxkErUOGbjq9L39uXpD6+lOafKcjIlTxMKpI9ygmmRXluaZyJM=
X-Received: by 2002:a81:ac28:0:b0:54c:a67:90b with SMTP id
 k40-20020a81ac28000000b0054c0a67090bmr1564250ywh.5.1681895121412; 
 Wed, 19 Apr 2023 02:05:21 -0700 (PDT)
MIME-Version: 1.0
References: <aka4qP9Cig-OhfMlQ9y1kghZWExjpno4cs47KIgYwv4aLYtiQB37eHbj2X2hiDuoK0D1gSeKWP97P0bRADbTg1CZRBIpHGZ5WFFYPWIJ87Y=@protonmail.com>
 <fiR7LHbBUV54aYegN2eIGIwX5f8Sg5bfaSSoBT0niB1huGYNGyvNeDQ1q32o15PRMC4JfaZUv_H06zuChvRgsMD5QaqZTX_bm-MPVw52asc=@protonmail.com>
In-Reply-To: <fiR7LHbBUV54aYegN2eIGIwX5f8Sg5bfaSSoBT0niB1huGYNGyvNeDQ1q32o15PRMC4JfaZUv_H06zuChvRgsMD5QaqZTX_bm-MPVw52asc=@protonmail.com>
From: Kostas Karasavvas <kkarasavvas@gmail.com>
Date: Wed, 19 Apr 2023 12:05:10 +0300
Message-ID: <CABE6yHs2P62shRJhiWtkXV4KT3X4tVy64ZbgnuzuBonRq_KN5A@mail.gmail.com>
To: Michael Folkson <michaelfolkson@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000042e5bb05f9acb9aa"
X-Mailman-Approved-At: Wed, 19 Apr 2023 09:07:30 +0000
Cc: Lightning Dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Apr 2023 09:05:25 -0000

--00000000000042e5bb05f9acb9aa
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Michael,

On Wed, Apr 19, 2023 at 2:40=E2=80=AFAM Michael Folkson via bitcoin-dev <
bitcoin-dev@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/APOA=
S
> (primarily though not
>

Could you please point me to a resource that describes the default policy
changes (that are happening for lightning)? I have seen discussions here
and there but it would help if they are aggregated somewhere for reviewing.


> 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 woul=
d
> also want to be a Lightning node and so the separation of concerns would
> make less sense.
>

Separation of concerns always makes sense to manage complexity. One would
need to have really strong incentives to counter the complexity argument.

I might be missing some context here but what would the actual benefit of
integrating them be? Not having to install lightning node separately and
maybe a more intuitive UX?


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 compatibl=
e
> 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 us=
ed
> "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.
>
>
Personally, I have great difficulty seeing lightning as something other
than an L2 build on top of Bitcoin. There will be other L2s.

Regards,
Kostas

PS. Besides, the amount of effort would be significant. Wouldn't that
effort be better spent on, say, separating the consensus logic (i.e. a
second libbitcoinkernel attempt)?



> 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@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 o=
f
> 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 other=
s
> 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 sta=
rt
> to take the idea more seriously. It is clear to me that the current way t=
he
> 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 an=
d
> decisions seem to be increasingly made behind closed doors or in private
> IRC channels (to the extent that decisions are made at all). Core Lightni=
ng
> 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 tim=
e
> and the ultra conservatism that is needed when treating (potential)
> consensus code seems to permeate into parts of the codebase that no one i=
s
> using, definitely isn't consensus code and should probably just be remove=
d.
>
> The libbitcoinkernel project was (is?) an attempt to extract the consensu=
s
> engine out of Core but it seems like it won't achieve that as consensus i=
s
> 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++ cod=
e
> 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 optim=
al
> 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 nic=
e
> 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=3D20&t=3D=
GbPm7w5BqS7rS3kiVFTNcw
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


--=20
https://twitter.com/kkarasavvas

--00000000000042e5bb05f9acb9aa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Michael,</div><div><br></div><div class=3D"gmail_q=
uote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Apr 19, 2023 at 2:40=E2=
=80=AFAM Michael Folkson via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@=
lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style=
=3D"font-family:Arial,sans-serif;font-size:14px">Any thoughts on this from =
the Core Lightning contributors? The way I see it with upcoming proposed ch=
anges to default policy (primarily though not exclusively for Lightning) an=
d a soft fork activation attempt of APO/APOAS (primarily though not </div><=
/blockquote><div><br></div><div><div>Could you please point me to a resourc=
e that=20
describes the default policy changes (that are happening for lightning)?
 I have seen discussions here and there but it would help if they are=20
aggregated somewhere for reviewing.<br></div></div><div>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><div style=3D"font-family:Arial,=
sans-serif;font-size:14px">exclusively for Lightning) that a tighter coupli=
ng between the full node and the Lightning node could eventually make sense=
. In a world where transaction fees were much higher you&#39;d think almost=
 every full node would also want to be a Lightning node and so the separati=
on of concerns would make less sense. </div></blockquote><div><br></div><di=
v>Separation of concerns always makes sense to manage complexity. One would=
 need to have really strong incentives to counter the complexity argument.<=
br></div><div><br></div><div>I might be missing some context here but what =
would the actual benefit of integrating them be? Not having to install ligh=
tning node separately and maybe a more intuitive UX?<br></div><div><br></di=
v><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div sty=
le=3D"font-family:Arial,sans-serif;font-size:14px">Having two separate P2P =
networks and two separate P2P protocols also wouldn&#39;t make much sense i=
n this scenario. You could obviously still opt out of Lightning P2P message=
s if you weren&#39;t interested in Lightning.</div><div style=3D"font-famil=
y:Arial,sans-serif;font-size:14px"><br></div></blockquote><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div style=3D"font-family:Arial,sans-serif=
;font-size:14px"></div><div style=3D"font-family:Arial,sans-serif;font-size=
:14px">The alternative would be just to focus on Knots style consensus comp=
atible forks of Core with limited additional functionality. But I think we&=
#39;ve reached the point of no return on Core dominance and not having wide=
ly used &quot;distros&quot;. As the ecosystem scales systems and processes =
should be constantly evolving and improving and to me if anything Core&#39;=
s seem to be going backwards.</div><div style=3D"font-family:Arial,sans-ser=
if;font-size:14px"><br></div></blockquote><div><br></div><div>Personally, I=
 have great difficulty seeing lightning as something other than an L2 build=
 on top of Bitcoin. There will be other L2s.<br></div><div><br></div><div>R=
egards,</div><div>Kostas</div><div><br></div><div>PS. Besides, the amount o=
f effort would be significant. Wouldn&#39;t that effort be better spent on,=
 say, separating the consensus logic (i.e. a second libbitcoinkernel attemp=
t)?<div><br></div></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><div style=3D"font-family:Arial,sans-serif;font-size:14px">=
</div><div style=3D"font-family:Arial,sans-serif;font-size:14px">Thanks</di=
v><div style=3D"font-family:Arial,sans-serif;font-size:14px">Michael</div><=
div style=3D"font-family:Arial,sans-serif;font-size:14px"><br></div>
<div style=3D"font-family:Arial,sans-serif;font-size:14px">
    <div>
        <div style=3D"font-family:arial;font-size:14px"><span style=3D"colo=
r:rgb(38,42,51);font-style:normal;font-weight:400;letter-spacing:normal;tex=
t-indent:0px;text-transform:none;white-space:pre-wrap;word-spacing:0px;back=
ground-color:rgb(255,255,255);float:none;display:inline"><span style=3D"fon=
t-family:&quot;SFMono-Regular&quot;,Consolas,&quot;Liberation Mono&quot;,Me=
nlo,monospace,monospace"><span style=3D"font-size:14px">--<br>Michael Folks=
on<br>Email: michaelfolkson at </span></span></span><a href=3D"http://proto=
nmail.com/" style=3D"line-height:normal;text-decoration:underline;font-fami=
ly:&quot;SFMono-Regular&quot;,Consolas,&quot;Liberation Mono&quot;,Menlo,mo=
nospace,monospace;font-size:14px;font-style:normal;font-weight:400;letter-s=
pacing:normal;text-indent:0px;text-transform:none;white-space:pre-wrap;word=
-spacing:0px" rel=3D"noopener noreferrer" target=3D"_blank">protonmail.com<=
/a><span style=3D"color:rgb(38,42,51);font-style:normal;font-weight:400;let=
ter-spacing:normal;text-indent:0px;text-transform:none;white-space:pre-wrap=
;word-spacing:0px;background-color:rgb(255,255,255);float:none;display:inli=
ne"><span style=3D"font-family:&quot;SFMono-Regular&quot;,Consolas,&quot;Li=
beration Mono&quot;,Menlo,monospace,monospace"><span style=3D"font-size:14p=
x"> </span></span></span><br></div><div style=3D"font-family:arial;font-siz=
e:14px"><span style=3D"color:rgb(38,42,51);font-style:normal;font-weight:40=
0;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:pre=
-wrap;word-spacing:0px;background-color:rgb(255,255,255);float:none;display=
:inline"><span style=3D"font-family:&quot;SFMono-Regular&quot;,Consolas,&qu=
ot;Liberation Mono&quot;,Menlo,monospace,monospace"><span style=3D"font-siz=
e:14px">Keybase: michaelfolkson<br>PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 =
0159 214C FEE3</span></span></span><br></div>
    </div>
   =20
            <div>
       =20
            </div>
</div>
<div style=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><div>
        ------- Original Message -------<br>
        On Saturday, January 14th, 2023 at 20:26, Michael Folkson &lt;<a hr=
ef=3D"mailto:michaelfolkson@protonmail.com" target=3D"_blank">michaelfolkso=
n@protonmail.com</a>&gt; wrote:<br><br>
        <blockquote type=3D"cite">
            <div style=3D"font-family:Arial;font-size:14px">I tweeted this =
[0] back in November 2022.</div><div style=3D"font-family:Arial;font-size:1=
4px"><br></div><div style=3D"font-family:Arial;font-size:14px">&quot;With t=
he btcd bugs and the analysis paralysis on a RBF policy option in Core incr=
easingly 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.&quot;</div><div style=3D"font-family:Arial;font-size:14px"=
><br></div><div style=3D"font-family:Arial;font-size:14px">A new bare bones=
 Knots style Bitcoin implementation (in C++/C) integrated with Core Lightni=
ng 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 mo=
re seriously. It is clear to me that the current way the Bitcoin Core proje=
ct is being managed is not how I would like an open source project to be ma=
naged. Very little discussion is public anymore and decisions seem to be in=
creasingly made behind closed doors or in private IRC channels (to the exte=
nt that decisions are made at all). Core Lightning seems to have the opposi=
te problem. It is managed effectively in the open (admittedly with fewer co=
ntributors) but doesn&#39;t have the eyeballs or the usage that Bitcoin Cor=
e does. Regardless, selfishly I at some point would like a bare bones Bitco=
in and Lightning implementation integrated in one codebase. The Bitcoin Cor=
e codebase has collected a lot of cruft over time and the ultra conservatis=
m that is needed when treating (potential) consensus code seems to permeate=
 into parts of the codebase that no one is using, definitely isn&#39;t cons=
ensus code and should probably just be removed.</div><div style=3D"font-fam=
ily:Arial;font-size:14px"><br></div><div style=3D"font-family:Arial;font-si=
ze:14px">The libbitcoinkernel project was (is?) an attempt to extract the c=
onsensus engine out of Core but it seems like it won&#39;t achieve that as =
consensus is just too slippery a concept and Knots style consensus compatib=
le 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=
 fork of Bitcoin Core also isn&#39;t clear to me yet.</div><div style=3D"fo=
nt-family:Arial;font-size:14px"><br></div><div style=3D"font-family:Arial;f=
ont-size:14px">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 supe=
rset of C but assuming this merging of Bitcoin Core and Core Lightning is/w=
as the optimal final destination it surely would have been better if Core L=
ightning was written in the same language (i.e. with classes) as Bitcoin Co=
re.</div><div style=3D"font-family:Arial;font-size:14px"><br></div><div sty=
le=3D"font-family:Arial;font-size:14px">I&#39;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 lo=
ng 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 b=
e a lull in soft fork activation chaos.</div><div style=3D"font-family:Aria=
l;font-size:14px"><br></div><div style=3D"font-family:Arial;font-size:14px"=
>Thanks</div><div style=3D"font-family:Arial;font-size:14px">Michael</div><=
div style=3D"font-family:Arial;font-size:14px"><br></div><div style=3D"font=
-family:Arial;font-size:14px"><span style=3D"color:rgb(34,34,34);background=
-color:rgb(255,255,255)">[0]:=C2=A0</span><span style=3D"font-family:Times;=
font-size:15px;white-space:pre-wrap;background-color:rgb(0,0,0);display:inl=
ine"><a href=3D"https://twitter.com/michaelfolkson/status/15892201550069104=
64?s=3D20&amp;t=3DGbPm7w5BqS7rS3kiVFTNcw" rel=3D"noreferrer nofollow noopen=
er" target=3D"_blank"><span style=3D"color:rgb(34,34,34);background-color:r=
gb(255,255,255)">https://twitter.com/michaelfolkson/status/1589220155006910=
464?s=3D20&amp;t=3DGbPm7w5BqS7rS3kiVFTNcw</span></a></span></div><div style=
=3D"font-family:Arial;font-size:14px"><br></div>
<div style=3D"font-family:Arial;font-size:14px">
    <div>
        <div style=3D"font-family:arial;font-size:14px"><span style=3D"colo=
r:rgb(38,42,51);font-style:normal;font-weight:400;letter-spacing:normal;tex=
t-indent:0px;text-transform:none;white-space:pre-wrap;word-spacing:0px;back=
ground-color:rgb(255,255,255);float:none;display:inline"><span style=3D"fon=
t-family:&quot;SFMono-Regular&quot;,Consolas,&quot;Liberation Mono&quot;,Me=
nlo,monospace,monospace"><span style=3D"font-size:14px">--<br>Michael Folks=
on<br>Email: michaelfolkson at </span></span></span><a rel=3D"noreferrer no=
follow noopener" style=3D"line-height:normal;text-decoration:underline;font=
-family:&quot;SFMono-Regular&quot;,Consolas,&quot;Liberation Mono&quot;,Men=
lo,monospace,monospace;font-size:14px;font-style:normal;font-weight:400;let=
ter-spacing:normal;text-indent:0px;text-transform:none;white-space:pre-wrap=
;word-spacing:0px" href=3D"http://protonmail.com/" target=3D"_blank">proton=
mail.com</a><span style=3D"color:rgb(38,42,51);font-style:normal;font-weigh=
t:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space=
:pre-wrap;word-spacing:0px;background-color:rgb(255,255,255);float:none;dis=
play:inline"><span style=3D"font-family:&quot;SFMono-Regular&quot;,Consolas=
,&quot;Liberation Mono&quot;,Menlo,monospace,monospace"><span style=3D"font=
-size:14px"> </span></span></span><br></div><div style=3D"font-family:arial=
;font-size:14px"><span style=3D"color:rgb(38,42,51);font-style:normal;font-=
weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-=
space:pre-wrap;word-spacing:0px;background-color:rgb(255,255,255);float:non=
e;display:inline"><span style=3D"font-family:&quot;SFMono-Regular&quot;,Con=
solas,&quot;Liberation Mono&quot;,Menlo,monospace,monospace"><span style=3D=
"font-size:14px">Keybase: michaelfolkson<br>PGP: 43ED C999 9F85 1D40 EAF4 9=
835 92D6 0159 214C FEE3</span></span></span><br></div>
    </div>

            <div>

            </div>
</div>

        </blockquote><br>
    </div>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div><br clear=3D"all"><br><span class=3D"gmail_signature_pre=
fix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"l=
tr"><div><a href=3D"https://twitter.com/kkarasavvas" target=3D"_blank">http=
s://twitter.com/kkarasavvas</a><br></div></div></div></div>

--00000000000042e5bb05f9acb9aa--