Topics: add multiple topics for Newsletter 283

_posts/en/newsletters/2024-01-03-newsletter.md

@@ -71,8 +71,8 @@ infrastructure.
   confirmed at an acceptable feerate.
 
     Law notes that this addresses one of the longstanding concerns noted
-    in the [original Lightning Network paper][] about _forced expiration
-    floods_ where too many channels all closing simultaneously may
+    in the [original Lightning Network paper][] about [forced expiration
+    floods][topic expiration floods] where too many channels all closing simultaneously may
     result in insufficient block space for all of them to be
     confirmed before their timelocks expire, potentially resulting in
     some users losing money.  With fee-dependent timelocks in place,
@@ -111,7 +111,7 @@ infrastructure.
 - **Cluster fee estimation:** Abubakar Sadiq Ismail [posted][ismail
   cluster] to Delving Bitcoin about using some of the tools and insights
   from the design of [cluster mempool][topic cluster mempool] to improve
-  fee estimation in Bitcoin Core.  The current fee estimation algorithm
+  [fee estimation][topic fee estimation] in Bitcoin Core.  The current fee estimation algorithm
   in Bitcoin Core tracks the number of blocks it takes for transactions
   entering the local node's mempool to become confirmed.  When
   confirmation happens, the transaction's feerate is used to update a
@@ -229,10 +229,9 @@ infrastructure.
 - **Verification of arbitrary programs using proposed opcode from MATT:**
   Johan Torås Halseth [posted][halseth ccv] to Delving Bitcoin about
   [elftrace][], a proof of concept program that can use the
-  `OP_CHECKCONTRACTVERIFY` opcode from the [MATT][] soft fork proposal
-  to allow a party in a contract protocol to claim money if an arbitrary
-  program executed successfully.  It is similar in concept to BitVM (see
-  [Newsletter #273][news273 bitvm]) but simpler in its Bitcoin
+  `OP_CHECKCONTRACTVERIFY` opcode from the [MATT][topic matt] soft fork proposal
+  to allow a party in a contract protocol to [claim money][topic acc] if an arbitrary
+  program executed successfully.  It is similar in concept to [BitVM][topic acc] but simpler in its Bitcoin
   implementation due to using an opcode specifically designed for
   program execution verification.  Elftrace works with programs compiled
   for the RISC-V architecture using Linux's [ELF][] format; almost any
@@ -288,7 +287,7 @@ infrastructure.
     constructing party.  Ingala roughly describes how this feature could
     be added to a multiparty contract protocol using [OP_CAT][],
     `OP_CHECKCONTRACTVERIFY`, and amount introspection from the proposed
-    [MATT][] soft fork, with him noting that it would be easier with the
+    [MATT][topic matt] soft fork, with him noting that it would be easier with the
     addition also of [OP_CSFS][topic op_checksigfromstack] and 64-bit
     arithmetic operators in [tapscript][topic tapscript].
 
@@ -405,7 +404,6 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], and
 [black descpsbt]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-November/022186.html
 [halseth ccv]: https://delvingbitcoin.org/t/verification-of-risc-v-execution-using-op-ccv/313
 [elftrace]: https://github.com/halseth/elftrace
-[matt]: /en/newsletters/2022/11/16/#general-smart-contracts-in-bitcoin-via-covenants
 [news273 bitvm]: /en/newsletters/2023/10/18/#payments-contingent-on-arbitrary-computation
 [elf]: https://en.m.wikipedia.org/wiki/Executable_and_Linkable_Format
 [ingala exit]: https://delvingbitcoin.org/t/aggregate-delegated-exit-for-l2-pools/297

_topics/en/acc.md

@@ -0,0 +1,101 @@
+---
+title: Accountable Computing Contracts
+
+## Optional.  Shorter name to use for reference style links e.g., "foo"
+## will allow using the link [topic foo][].  Not case sensitive
+shortname: ACC
+
+## Optional.  An entry will be added to the topics index for each alias
+aliases:
+  - BitVM
+  - Zero-Knowledge Contingent Payments (ZKCP)
+
+## Required.  At least one category to which this topic belongs.  See
+## schema for options
+categories:
+  - Contract Protocols
+
+## Optional.  Produces a Markdown link with either "[title][]" or
+## "[title](link)"
+#primary_sources:
+#    - title: Test
+#    - title: Example
+#      link: https://example.com
+
+## Optional.  Each entry requires "title" and "url".  May also use "feature:
+## true" to bold entry and "date"
+optech_mentions:
+  - title: ZKCP versus standardized atomic data delivery following LN payments
+    url: /en/newsletters/2019/07/03/#standardized-atomic-data-delivery-following-ln-payments
+
+  - title: "BitVM: payments contingent on arbitrary computation without consensus changes"
+    url: /en/newsletters/2023/10/18/#payments-contingent-on-arbitrary-computation
+
+  - title: "Publication of two BitVM proof of concepts"
+    url: /en/newsletters/2023/11/22/#bitvm-proof-of-concepts
+
+  - title: Proposal for general smart contracts in Bitcoin via covenants
+    url: /en/newsletters/2022/11/16/#general-smart-contracts-in-bitcoin-via-covenants
+
+  - title: Verification of arbitrary programs using proposed opcode from MATT
+    url: /en/newsletters/2024/01/03/#verification-of-arbitrary-programs-using-proposed-opcode-from-matt
+
+## Optional.  Same format as "primary_sources" above
+see_also:
+  - title: "Merklize All The Things (MATT)"
+    link: topic matt
+
+## Optional.  Force the display (true) or non-display (false) of stub
+## topic notice.  Default is to display if the page.content is below a
+## threshold word count
+#stub: false
+
+## Required.  Use Markdown formatting.  Only one paragraph.  No links allowed.
+## Should be less than 500 characters
+excerpt: >
+  **Accountable Computing Contracts (ACC)** are payments
+  that the receiving party can spend if they verifiably run a specified
+  function on a specified set of inputs.  If the receiving party doesn't
+  run the function or doesn't run it correctly, the paying party can
+  reclaim the payment after a period of time.
+
+---
+For example, Alice claims she has a solution to a puzzle.  Bob wants to
+buy the solution to the puzzle, but Alice is unwilling to give him a
+solution until she's guaranteed to receive a payment.  Bob is similarly
+unwilling to pay Alice until he's sure the solution is correct.  They
+decide to write a program that will return true if it verifies the
+solution is correct. Then Bob pays money to a transaction output that
+will allow Alice to claim the money if she provides a solution that was
+verified by the program.  If the solution is incorrect, either Alice's
+spend will be invalid or she will need to pay a penalty that is equal to
+or greater than the amount of the payment.
+
+There have been several proposals and implementations of this idea for
+Bitcoin:
+
+- [Zero-Knowledge Contingent Payments][zkcp] (ZKCPs) allow Alice to
+  prove that she ran the program on her puzzle solution and that the
+  solution has a particular hash digest.  Bob can then create an
+  [HTLC][topic HTLC] that pays Alice if she discloses the preimage for
+  that hash digest.  If Alice doesn't disclose it, Bob can reclaim his
+  funds after the HTLC timelock expires.
+
+- [BitVM][] allows Bob to deposit money into a contract that
+  compactly references the program they're using for verification.
+  Alice can then provide the solution.  If Bob is satisfied, he releases
+  the money to Alice.  If he fails to take action, Alice can claim the
+  money after a period of time.  If he isn't satisfied, he can challenge
+  Alice to prove that their program returns true when run on her
+  solution, breaking the challenge into multiple steps that each require
+  an onchain transaction.  BitVM is available on Bitcoin today.
+
+- [MATT][topic matt] works similar to BitVM, although it requires a soft
+  fork.  As a tradeoff, it can be much more efficient than BitVM due to
+  changing the consensus rules to make this type of proving
+  efficient.
+
+{% include references.md %}
+{% include linkers/issues.md issues="" %}
+[zkcp]: https://bitcoincore.org/en/2016/02/26/zero-knowledge-contingent-payments-announcement/
+[bitvm]: /en/newsletters/2023/10/18/#payments-contingent-on-arbitrary-computation

_topics/en/expiration-floods.md

@@ -0,0 +1,139 @@
+---
+title: Expiration floods
+
+## Optional.  Shorter name to use for reference style links e.g., "foo"
+## will allow using the link [topic foo][].  Not case sensitive
+# shortname: foo
+
+## Optional.  An entry will be added to the topics index for each alias
+aliases:
+  - Forced expiration spam
+  - Flood and loot
+
+## Required.  At least one category to which this topic belongs.  See
+## schema for options
+categories:
+  - Contract Protocols
+  - Lightning Network
+  - Security Problems
+  - Security Enhancements
+
+## Optional.  Produces a Markdown link with either "[title][]" or
+## "[title](link)"
+primary_sources:
+    - title: "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments"
+      link: https://lightning.network/lightning-network-paper.pdf
+
+    - title: "Flood & Loot: A Systemic Attack On The Lightning Network"
+      link: https://arxiv.org/abs/2006.08513
+
+## Optional.  Each entry requires "title" and "url".  May also use "feature:
+## true" to bold entry and "date"
+optech_mentions:
+  - title: LN developer discussion about flood and loot attacks
+    url: /en/newsletters/2020/08/05/#chicago-meetup-discussion
+
+  - title: Concern about forced expiration spam in very large channel factories
+    url: /en/newsletters/2023/09/27/#using-covenants-to-improve-ln-scalability
+
+  - title: Mitigating expiration floods with fee-depedent timelocks
+    url: /en/newsletters/2024/01/03/#fee-dependent-timelocks
+
+## Optional.  Same format as "primary_sources" above
+see_also:
+  - title: HTLCs
+    link: topic htlc
+
+  - title: PTLCs
+    link: topic ptlc
+
+## Optional.  Force the display (true) or non-display (false) of stub
+## topic notice.  Default is to display if the page.content is below a
+## threshold word count
+#stub: false
+
+## Required.  Use Markdown formatting.  Only one paragraph.  No links allowed.
+## Should be less than 500 characters
+excerpt: >
+  **Expiration floods** occur when many timelock-contingent payments
+  need to be settled onchain within a limited period of time.  If not
+  all of the settlement transactions can fit into blocks before
+  timelocks begin expiring, then not all of the contingent payments will
+  resolve as expected, likely resulting in some users losing money.
+
+---
+For example, Mallory runs a very popular LN node with many users.  Each
+channel has the maximum-allowed number of incoming and outgoing pending
+[HTLCs][topic htlc], making the cost to resolve each of those channels
+onchain around 100,000 vbytes.  A full block can only fit about 10 of
+those channels.  If the most critical [timelocks][topic timelocks] on
+some of the HTLCs might expire in 10 blocks or less, Mallory can force
+close more than 100 of those channels to eliminate the guarantee that
+her honest counterparties will receive their money.
+
+Although an expiration flood can be triggered deliberately by a
+malicious counterparty, it can also happen accidentally either by
+coincidence or by a situation that causes many users to attempt to close
+their channels simultaneously, e.g. a bug in a software implementation.
+In the accidental case, some honest users will get their money and other
+honest users may not, even though they all followed the protocol
+correctly.
+
+Expiration floods were described in the original [Lightning Network
+paper][] under the name **forced expiration spam**.  A later
+[paper][flood and loot] called the attack **flood and loot**.  Concern
+about expiration floods has heavily influenced the development of LN and
+other offchain protocols.
+
+Mitigations that don't require consensus changes include:
+
+- **Minimizing onchain enforcement data:** designing protocols and
+  setting limits so that timelock-contingent payments are small.  For
+  example, many LN implementations default to accepting and creating
+  much less than the protocol-allowed maximum number of pending HTLCs.
+  (That also helps mitigate other attacks.)
+
+- **Using long timelocks when possible:** in our example above, Mallory
+  needs to close at least 100 channels with 10-block timelocks.  If the
+  timelocks were 100 blocks, she'd need to close 1,000 channels
+  simultaneously.  It would take more effort on her part to find that
+  many victims and get their channels into an exploitable state.
+
+- **Improving counterparty decentralization:** someone who is a
+  counterparty to 100 users has more power to execute an expiration
+  flood attack than someone who is only counterparty to 10 users.
+  This suggests that a less centralized distribution of counterparties
+  might be safer against deliberately triggered expiration floods.
+  Of course, in privacy-protecting protocols, it may be impossible to
+  prove that two counterparties are distinct entities and not colluding.
+
+Proposed mitigations that require consensus changes include:
+
+- **Dynamic bounded block sizes:** this would allow miners to create larger
+  blocks during high periods of demand so that they can confirm more
+  transactions during an expiration flood.  [Proposals][friedenbach
+  dynamic] of this [nature][maxwell dynamic]
+  usually require miners to pay a cost for creating higher blocks, such
+  as destroying bitcoins or generating more proof of work.  The lost
+  bitcoins and work are expected to be compensated for by the extra fee
+  income they will receive from confirming urgent transactions.
+
+- **Fee-dependent timelocks:** [this][fdt] would prevent a timelock from
+  expiring when feerates were above a specified amount.  If too many
+  timelock-contingent payments entered the mempool at once; the users
+  would bid up their feerates in competition with each other to get
+  their transactions confirmed before the regular timelocks expired.
+  When feerates exceeded the fee-dependent timelock, expiration of those
+  timelocks would be delayed, keeping those users safe until feerates
+  reduced. As long as the user paid a feerate above their fee-dependent
+  timelock amount, their transaction should confirm before the timelock
+  expires, ensuring the user's desired transaction gets confirmed before
+  the timelock expires.
+
+{% include references.md %}
+{% include linkers/issues.md issues="" %}
+[lightning network paper]: https://lightning.network/lightning-network-paper.pdf
+[flood and loot]: https://arxiv.org/abs/2006.08513
+[friedenbach dynamic]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008017.html
+[maxwell dynamic]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008038.html
+[fdt]: /en/newsletters/2024/01/03/#fee-dependent-timelocks

_topics/en/fee-estimation.md

@@ -0,0 +1,67 @@
+---
+title: Fee estimation
+
+## Optional.  Shorter name to use for reference style links e.g., "foo"
+## will allow using the link [topic foo][].  Not case sensitive
+# shortname: foo
+
+## Optional.  An entry will be added to the topics index for each alias
+#aliases:
+#  - Foo
+
+## Required.  At least one category to which this topic belongs.  See
+## schema for options
+categories:
+  - Fee Management
+
+## Optional.  Produces a Markdown link with either "[title][]" or
+## "[title](link)"
+primary_sources:
+    - title: "Bitcoin Core Fee Estimation Algorithm (2017)"
+      link: https://gist.github.com/morcos/d3637f015bc4e607e1fd10d8351e9f41
+
+## Optional.  Each entry requires "title" and "url".  May also use "feature:
+## true" to bold entry and "date"
+optech_mentions:
+  - title: "LND #4078 adds an `estimatemode` configuration setting for configuring its fee estimation"
+    url: /en/newsletters/2020/04/01/#lnd-4078
+
+  - title: "Bitcoin Core #18766 disables the ability to get fee estimates when using blocks-only mode"
+    url: /en/newsletters/2020/12/16/#bitcoin-core-18766
+
+  - title: "Bitcoin Core #22539 includes replacement transactions seen by the local node in fee estimates"
+    url: /en/newsletters/2021/10/20/#bitcoin-core-22539
+
+  - title: "ECDSA signature grinding helps with fee estimation"
+    url: /en/newsletters/2022/01/26/#what-is-signature-grinding
+
+  - title: "Rust Bitcoin #2213 amends the weight prediction for P2WPKH inputs during fee estimation"
+    url: /en/newsletters/2023/11/29/#rust-bitcoin-2213
+
+  - title: "BTCPay Server #5490 begins using fee estimates from mempool.space"
+    url: /en/newsletters/2023/12/13/#btcpay-server-5490
+
+  - title: "Cluster fee estimation to improve accuracy in a world with CPFP fee bumping"
+    url: /en/newsletters/2024/01/03/#cluster-fee-estimation
+
+## Optional.  Same format as "primary_sources" above
+see_also:
+  - title: Coin selection
+    link: topic coin selection
+
+## Optional.  Force the display (true) or non-display (false) of stub
+## topic notice.  Default is to display if the page.content is below a
+## threshold word count
+#stub: false
+
+## Required.  Use Markdown formatting.  Only one paragraph.  No links allowed.
+## Should be less than 500 characters
+excerpt: >
+  **Fee estimation** is the process of estimating the feerate a
+  transaction will need to pay to have a high probability of being
+  confirmed within a certain number of blocks.
+
+---
+
+{% include references.md %}
+{% include linkers/issues.md issues="" %}