@@ -68,7 +68,7 @@ LND. Signets are test networks anyone can use to simulate Bitcoin's
68
68
main network (mainnet), either as it exists today or how it might exist
69
69
with certain changes (such as the activation of a soft fork consensus
70
70
change). Most software implementing signets also supports a default
71
- signet that provides a particularly convenient environment for software
71
+ signet that provides a particularly convenient means for software
72
72
developed by different teams to be tested in a safe environment that
73
73
comes as close as possible to the environment they'll experience when
74
74
real money is at stake. Also [ discussed] [ signet reorgs ] this year was
@@ -245,7 +245,7 @@ addresses.
245
245
- ** December<!-- taproot--> ** saw Bitcoin Core merge a PR that would
246
246
allow [ descriptor wallets] [ topic descriptors ] to create
247
247
[ bech32m] [ topic bech32 ] addresses for receiving taproot payments. LN
248
- devs also further discussed [ making use] [ ln ptlcs ] of taproot's
248
+ developers also further discussed [ making use] [ ln ptlcs ] of taproot's
249
249
features.
250
250
251
251
Despite complications choosing an activation mechanism for taproot and
@@ -392,7 +392,7 @@ relay][topic package relay] will allow relay nodes and miners to treat
392
392
packages of related transactions as if they were a single transaction
393
393
for feerate purposes. A package might contain a parent transaction with a
394
394
low feerate and a child transaction with a high feerate; the
395
- profitability of mining the parent transaction would incentivize miners
395
+ profitability of mining the child transaction would incentivize miners
396
396
to also mine the parent transaction. Although package mining has been
397
397
[ implemented] [ bitcoin core #7600 ] in Bitcoin Core since 2016, there has
398
398
so far been no way for nodes to relay transactions as packages, meaning
@@ -424,7 +424,7 @@ instant payments. A node that sees the advertisement can simultaneously
424
424
pay for and receive the inbound capacity using a [ dual funded] [ topic
425
425
dual funding] channel open. Although there’s no way to enforce that the
426
426
advertising node actually routes payments, the proposal does incorporate
427
- an earlier proposal also [ later used] [ lnd#5709 ] in Lightning Pool that
427
+ an earlier proposal ( also [ later used] [ lnd#5709 ] in Lightning Pool) that
428
428
prevents the advertiser from using their money for other purposes until
429
429
the agreed upon lease period has concluded. That means refusing to
430
430
route payments would provide no advantages but would deny the
@@ -504,7 +504,7 @@ In Optech's fourth year, we published 51 weekly [newsletters][], added 30
504
504
new pages to our [ topics index] [ ] , published a [ contributed blog
505
505
post] [ additive batching ] , and wrote (with the help of [ two] [ zmn guest ]
506
506
guest [ posters] [ darosior guest ] ) a 21-part series about [ preparing for
507
- taproot] [ p4tr ] ) . Altogether, Optech published over 80,000 words about
507
+ taproot] [ p4tr ] . Altogether, Optech published over 80,000 words about
508
508
Bitcoin software research and development this year, the rough
509
509
equivalent of a 250-page book. <!-- wc -w _ posts/en/newsletters/2021-*
510
510
_ includes/specials/taproot/en/* -->
@@ -554,7 +554,7 @@ the same benefits of eltoo but without requiring the
554
554
consensus changes. The proposal would reduce payment latency to nearly
555
555
as fast as data could travel one way between all the routing nodes on a
556
556
particular path. It would also increase resiliency by allowing a node to
557
- backup all of the information it needs at the time a channel is created
557
+ back up all of the information it needs at the time a channel is created
558
558
and obtain any other information in most cases during a data restore.
559
559
It would also allow receiving payments with an offline key, allowing
560
560
merchant nodes in particular to limit the amount of time their keys
@@ -597,7 +597,7 @@ very much want to see them credited for their incredible work, but we
597
597
also want to recognize all of the contributors who we wouldn't normally
598
598
mention.
599
599
600
- They're the people spending hours on coding reviews, or who are writing
600
+ They're the people spending hours on code reviews, or who are writing
601
601
tests for established behavior to ensure it doesn't unexpectedly change,
602
602
or who put effort into debugging mysterious issues to fix problems
603
603
before money is put at risk, or who are working on a hundred other tasks
@@ -616,7 +616,6 @@ see what exciting new developments they will deliver in 2022.
616
616
* The Optech newsletter will return to its regular Wednesday publication
617
617
schedule on January 5th.*
618
618
619
- <!-- FIXME add topic links, there's gonna be a lot!!! -->
620
619
{% include references.md %}
621
620
{% include linkers/issues.md issues="878,7600" %}
622
621
[ 2018 summary ] : /en/newsletters/2018/12/28/
0 commit comments