Skip to content

Commit

Permalink
Updated newly generated xml files
Browse files Browse the repository at this point in the history
  • Loading branch information
@urvishp80
urvishp80 committed Oct 6, 2024
1 parent 508d04c commit 75ed443
Show file tree
Hide file tree
Showing 3 changed files with 64 additions and 11 deletions.
18 changes: 18 additions & 0 deletions static/delvingbitcoin/Oct_2024/3326_Expanding-on-BOLT12.xml
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,18 @@
<?xml version='1.0' encoding='UTF-8'?>
<feed xmlns="http://www.w3.org/2005/Atom">
<id>1</id>
<title>Expanding on BOLT12</title>
<updated>2024-10-06T02:24:13.740555+00:00</updated>
<author>
<name>andyschroder 2024-10-05 15:57:36.582000+00:00</name>
</author>
<generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator>
<entry>
<id>1</id>
<title>Expanding on BOLT12</title>
<updated>2024-10-06T02:24:13.740590+00:00</updated>
<link href="https://delvingbitcoin.org/t/expanding-on-bolt12/1167/3" rel="alternate"/>
<summary>The discussion reveals an observation regarding the BOLT12 specification, which lacks a defined prefix for invoices. To address this gap, the proposal is to adopt the `lni` prefix, which, despite not being officially specified, is already in use by Core Lightning (CLN) for certain Remote Procedure Calls (RPC). This adoption is evident in CLN's implementation of the `fetchinvoice` and `pay` commands, as detailed in their documentation. The links to the respective RPC commands on CLN's documentation shed light on how `lni` is utilized within these contexts: [lightning-fetchinvoice](https://docs.corelightning.org/reference/lightning-fetchinvoice) illustrates the command's use in fetching invoices, while [lightning-pay](https://docs.corelightning.org/reference/lightning-pay) demonstrates its application in payment processes. This insight suggests an unofficial but practical standard emerging within the community, underscoring the necessity for a more formalized approach to invoice prefixes in the BOLT12 specification.</summary>
<published>2024-10-05T15:57:36.582000+00:00</published>
</entry>
</feed>
33 changes: 33 additions & 0 deletions static/delvingbitcoin/Oct_2024/combined_Expanding-on-BOLT12.xml
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,33 @@
<?xml version='1.0' encoding='UTF-8'?>
<feed xmlns="http://www.w3.org/2005/Atom">
<id>2</id>
<title>Combined summary - Expanding on BOLT12</title>
<updated>2024-10-06T02:24:30.334043+00:00</updated>
<author>
<name>andyschroder 2024-10-05 15:57:36.582000+00:00</name>
</author>
<author>
<name>andyschroder . 2024-09-30 06:32:47.142000+00:00</name>
</author>
<author>
<name>andyschroder . 2024-09-29 04:18:33.934000+00:00</name>
</author>
<link href="delvingbitcoin/Oct_2024/3326_Expanding-on-BOLT12.xml" rel="alternate"/>
<link href="delvingbitcoin/Sept_2024/3304_Expanding-on-BOLT12.xml" rel="alternate"/>
<link href="delvingbitcoin/Sept_2024/3280_Expanding-on-BOLT12.xml" rel="alternate"/>
<generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator>
<entry>
<id>2</id>
<title>Combined summary - Expanding on BOLT12</title>
<updated>2024-10-06T02:24:30.334100+00:00</updated>
<link href="https://delvingbitcoin.org/t/expanding-on-bolt12/1167/3" rel="alternate"/>
<summary>The discussion opens with the observation that in BOLT12 specifications, there is no human-readable prefix defined for invoices, leading to the proposal of using `lni` as a prefix. This suggestion is underscored by its current utilization in CLN's fetchinvoice and pay RPC commands, as detailed in their documentation. The proposal itself is considered more appropriate as a Bitcoin Lightning Improvement Proposal (bLIP) rather than an amendment to the existing BOLT specifications, highlighting its optional nature and ensuring that the foundational operations of BOLT12 are not impacted for users who may opt out of this feature. For those interested in exploring this concept further, a detailed examination is provided at [delvingbitcoin.org](https://delvingbitcoin.org/t/bolt-12-trusted-contacts/1046), offering insights into the implementation of trusted contacts within BOLT12 that aims to extend its capabilities without compromising its core functionality.

The narrative progresses by acknowledging a significant milestone in BOLT12's development, marked by its integration into the main repository, an action documented in a specific [pull request](https://github.com/lightning/bolts/pull/798). This incorporation signifies the beginning of its practical application and opens discussions on potential enhancements to refine its utility. A focal point of these discussions is the structural flexibility of BOLT12, particularly the requirement for `invoice_request` and `invoice` writers to duplicate all fields from their predecessors, including unknown ones. This aspect suggests a pathway for introducing additional backward-compatible fields. Among the notable suggestions is the inclusion of a `user` field within the `invoice_request`, alongside the proposition of a boolean `refund_invoice_required` field for `offer` writers, aimed at simplifying the refund process by automating it through encoded invoices prefixed with `lni`.

Further proposals include the establishment of an `offer_max_amount` within the `offer` structure to set transaction limits, addressing operational concerns such as inventory and liquidity issues, and managing customer expectations. While direct enforcement through HTLCs might be challenging, setting clear upfront limits could mitigate attempts to exceed agreed transaction volumes. Additionally, the absence of an expiration mechanism for `invoice_request`s is highlighted, suggesting the need for an expiry similar to that of `offers` and `invoices` to manage offer lifecycles more effectively and ensure transaction relevance remains within a mutually understood timeframe.

In summary, these discussions and proposals reflect a concerted effort within the community to enhance BOLT12, inviting feedback to guide its evolution in addressing the diverse needs and challenges faced in real-world implementations.</summary>
<published>2024-10-05T15:57:36.582000+00:00</published>
</entry>
</feed>
24 changes: 13 additions & 11 deletions static/delvingbitcoin/Sept_2024/combined_Expanding-on-BOLT12.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -2,30 +2,32 @@
<feed xmlns="http://www.w3.org/2005/Atom">
<id>2</id>
<title>Combined summary - Expanding on BOLT12</title>
<updated>2024-10-01T02:27:48.047473+00:00</updated>
<updated>2024-10-06T02:24:30.334043+00:00</updated>
<author>
<name>andyschroder 2024-09-30 06:32:47.142000+00:00</name>
<name>andyschroder 2024-10-05 15:57:36.582000+00:00</name>
</author>
<author>
<name>andyschroder . 2024-09-30 06:32:47.142000+00:00</name>
</author>
<author>
<name>andyschroder . 2024-09-29 04:18:33.934000+00:00</name>
</author>
<link href="delvingbitcoin/Oct_2024/3326_Expanding-on-BOLT12.xml" rel="alternate"/>
<link href="delvingbitcoin/Sept_2024/3304_Expanding-on-BOLT12.xml" rel="alternate"/>
<link href="delvingbitcoin/Sept_2024/3280_Expanding-on-BOLT12.xml" rel="alternate"/>
<generator uri="https://lkiesow.github.io/python-feedgen" version="0.9.0">python-feedgen</generator>
<entry>
<id>2</id>
<title>Combined summary - Expanding on BOLT12</title>
<updated>2024-10-01T02:27:48.047512+00:00</updated>
<link href="https://delvingbitcoin.org/t/expanding-on-bolt12/1167/2" rel="alternate"/>
<summary>The proposal to classify a new feature as a bLIP (Bitcoin Lightning Improvement Proposal) rather than amending the existing BOLT (Basis of Lightning Technology) documents is driven by its optional nature, ensuring that BOLT12 continues to function as intended regardless of user adoption. The integration of BOLT12 into the main repository, highlighted by a recent [pull request](https://github.com/lightning/bolts/pull/798), marks a pivotal moment in its evolution, showcasing its readiness for real-world application and signaling the commencement of its practical deployment.

A focal point of ongoing development efforts is the structural design of `invoice_request` and `invoice` elements, specifically the requirement for these components to inherit all fields from their precursors, even those unfamiliar to them. This approach not only embodies a degree of flexibility conducive to future enhancements but also suggests a framework that is inherently designed to accommodate additions in a manner that preserves backward compatibility. A significant enhancement under consideration involves the introduction of a `user` field within the `invoice_request`, providing a detailed specification [here](https://github.com/lightning/blips/blob/b6c3e8c17028926f7c5ae254f419456fe3c4bf13/blip-0032.md?plain=1L86).
<updated>2024-10-06T02:24:30.334100+00:00</updated>
<link href="https://delvingbitcoin.org/t/expanding-on-bolt12/1167/3" rel="alternate"/>
<summary>The discussion opens with the observation that in BOLT12 specifications, there is no human-readable prefix defined for invoices, leading to the proposal of using `lni` as a prefix. This suggestion is underscored by its current utilization in CLN's fetchinvoice and pay RPC commands, as detailed in their documentation. The proposal itself is considered more appropriate as a Bitcoin Lightning Improvement Proposal (bLIP) rather than an amendment to the existing BOLT specifications, highlighting its optional nature and ensuring that the foundational operations of BOLT12 are not impacted for users who may opt out of this feature. For those interested in exploring this concept further, a detailed examination is provided at [delvingbitcoin.org](https://delvingbitcoin.org/t/bolt-12-trusted-contacts/1046), offering insights into the implementation of trusted contacts within BOLT12 that aims to extend its capabilities without compromising its core functionality.

Further proposed improvements include the implementation of a `refund_invoice_required` field for `offer` creators, which, when activated, obliges `invoice_request` authors to issue a `refund_invoice` containing an encoded refund invoice prefixed by `lni`. This initiative is poised to simplify the refund mechanism, facilitating a more streamlined merchant-consumer interaction by circumventing the need for manual refund requests for each transaction. Another noteworthy suggestion is the establishment of an `offer_max_amount` parameter within offers, aimed at predefining the maximum value acceptable for transactions. This addition addresses operational considerations such as inventory limits, liquidity management, and customer relationship dynamics, thereby preempting potential disputes arising from exceeded transaction expectations.
The narrative progresses by acknowledging a significant milestone in BOLT12's development, marked by its integration into the main repository, an action documented in a specific [pull request](https://github.com/lightning/bolts/pull/798). This incorporation signifies the beginning of its practical application and opens discussions on potential enhancements to refine its utility. A focal point of these discussions is the structural flexibility of BOLT12, particularly the requirement for `invoice_request` and `invoice` writers to duplicate all fields from their predecessors, including unknown ones. This aspect suggests a pathway for introducing additional backward-compatible fields. Among the notable suggestions is the inclusion of a `user` field within the `invoice_request`, alongside the proposition of a boolean `refund_invoice_required` field for `offer` writers, aimed at simplifying the refund process by automating it through encoded invoices prefixed with `lni`.

The current lack of an expiration feature for `invoice_request`s presents a challenge in managing the temporal validity of offers, especially in scenarios where timing is critical. Introducing an expiry mechanism akin to those governing offers and invoices could significantly bolster the operational integrity of the BOLT12 framework, ensuring the relevance and enforceability of transactions within agreed timeframes.
Further proposals include the establishment of an `offer_max_amount` within the `offer` structure to set transaction limits, addressing operational concerns such as inventory and liquidity issues, and managing customer expectations. While direct enforcement through HTLCs might be challenging, setting clear upfront limits could mitigate attempts to exceed agreed transaction volumes. Additionally, the absence of an expiration mechanism for `invoice_request`s is highlighted, suggesting the need for an expiry similar to that of `offers` and `invoices` to manage offer lifecycles more effectively and ensure transaction relevance remains within a mutually understood timeframe.

These discussions encapsulate a concerted effort to refine the BOLT12 standard, embodying a community-driven approach to identify and address the complexities of implementing these protocols in diverse real-life contexts. Through active solicitation of feedback and collaborative examination of proposed features, the development of BOLT12 continues to be shaped by a broad spectrum of insights and expertise.</summary>
<published>2024-09-30T06:32:47.142000+00:00</published>
In summary, these discussions and proposals reflect a concerted effort within the community to enhance BOLT12, inviting feedback to guide its evolution in addressing the diverse needs and challenges faced in real-world implementations.</summary>
<published>2024-10-05T15:57:36.582000+00:00</published>
</entry>
</feed>

0 comments on commit 75ed443

Please sign in to comment.