diff --git a/meetings/2019-01-24.mdx b/meetings/2019-01-24.mdx new file mode 100644 index 000000000..96c249f6c --- /dev/null +++ b/meetings/2019-01-24.mdx @@ -0,0 +1,78 @@ +--- +title: "2019-01-24" +description: This protocol discussion covered CAP-5 and CAP-6, deterministic account creation, fee-bump transactions, and trustline usability proposals for simpler deposits and payments. +authors: goodnow +tags: + - legacy + - CAP-5 + - CAP-6 + - CAP-7 + - CAP-8 + - CAP-10 + - CAP-13 + - CAP-15 + - SEP-6 + - SEP-8 + - SEP-13 +--- + +## Agenda + +- CAP-5 & CAP-6 - moving to approval. +- [Cosigned Assets Draft](https://github.com/stellar/stellar-protocol/issues/146) - in draft since September; current approach considered viable. +- [CAP-7 Revised Proposal](https://github.com/stellar/stellar-protocol/blob/8f7ea7628cfb0c3e26723963b784752c9e0ea8e5/drafts/draft-detacct.md). +- CAP-15 update. +- CAP-13 vs SEP-13 (CAP-7 + CAP-8) - Change Trustlines to Balances. + +## Meeting Notes + +- CAP-6 progressing with specific messaging for a targeted use case. +- CAP-5 still lacks replace-by-fee and remains problematic. +- Deterministic accounts & creatorTxID (David): + - Vastly simplified since prior iteration. + - Salt mechanism needed; likely a full hash to prevent protocol rewind attacks. +- Cosigned Assets: + - Related to SEP-8. + - NFT discussions considered orthogonal; may warrant a separate CAP. + - Catalog of no-op operations discussed: + - Payment to oneself + - Bump op 0 + - SetOptions with no fields + +## Follow-up Actions + +- Johnny: coordinate CAP-6 community and API updates. +- David: expand deterministic accounts draft and address CAP-10/CAP-15 implications. +- Orbit: consolidate NFT discussions and assess need for a separate CAP. +- Jeremy: review SEP-13A comments and address shortcomings in SEP-13. + +## Trustline follow-up + +The adjacent trustline-focused discussion reprised the agenda above and surfaced additional nuance around asset onboarding and NFT considerations. Tom and Orbit asked the group to clarify how cosigned assets should handle no-op operations, and David emphasized that NFT work is orthogonal but still worth cataloging. + +- Tom asked for clarity on SEP-13A’s handling of edge cases, and Orbit volunteered to gather NFT-related requirements. The session reviewed the same high-level trustline-use case summary document in [Google Docs](https://docs.google.com/document/d/1_3KcBTbF7Diu_wu-ArvajYhEcPoDp9SgK5-dNruOK3c/edit#heading=h.8j5x6v50ft4p). That document lays out the anchor requirements around SEP-6/SEP-13 deposits and transfers so wallets set up user-facing flows that never require extra trustlines/XLM or manual follow-up steps, while also supporting sends to accounts that don’t yet exist. + - Deposits must complete once the anchor receives the external asset, delivering funds to the user’s original account whether or not it has a trustline or even exists yet. + - Users shouldn’t need to add additional XLM to finish a deposit, nor should anchors wait on any extra manual action once the deposit is underway. + - The send requirements emphasize end-to-end usability: sends must arrive without the recipient doing any setup, and the document recommends keeping implementations as simple as possible to encourage adoption. + - The group cataloged known no-ops (payment to self, bump op 0, SetOptions with no fields) and challenged attendees to bring simple, actionable alternatives rather than more complexity. + - A short-term TODO list reiterated that deterministic accounts need a salt/hash to guard against rewind attacks, while CAP-6 updates and SEP-13A comments should stay in sync with the evolving API design. + +## Trustline follow-up actions + +- Johnny: continue improving the DEX-focused messaging tied to CAP-6 and sync with Jon on API revisions. +- David: add concrete deterministic-account examples, harden salt handling, and spell out whether those accounts supplant CAP-10/CAP-15 work. +- Orbit: collect NFT and Asset-object feedback to determine whether a new CAP is warranted. +- Jeremy: respond to Tom’s SEP-13A comments and close the remaining gaps in the proposal. + +## Resources + +- [CAP-5: Throttling and transaction pricing improvements](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0005.md) +- [CAP-6: Add `ManageBuyOffer` Operation](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0006.md) +- [CAP-8: Self Identified Pre-Auth Transaction](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0008.md) +- [CAP-10: Fee Bump Account](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0010.md) +- [CAP-13: Change Trustlines to Balances](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0013.md) +- [CAP-15: Bump Fee Transactions](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0015.md) +- [SEP-6: Anchor/Client interoperability](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0006.md) +- [SEP-8: Regulated Assets](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0008.md) +- [SEP-13: `DEPOSIT_SERVER` proposal](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0013.md) +- [Original mailing-list discussion](https://groups.google.com/g/stellar-dev/c/x0Wrj2kuQ0U/m/CrId5QkoFwAJ) diff --git a/meetings/2019-03-07.mdx b/meetings/2019-03-07.mdx new file mode 100644 index 000000000..8b5914295 --- /dev/null +++ b/meetings/2019-03-07.mdx @@ -0,0 +1,121 @@ +--- +title: "2019-03-07" +description: This protocol discussion reviewed CAP-17 and CAP-18, prioritized trustline and payment-channel work, and compared fee-sponsorship proposals including CAP-10 and CAP-15. +authors: goodnow +tags: + - legacy + - CAP-7 + - CAP-8 + - CAP-9 + - CAP-10 + - CAP-11 + - CAP-13 + - CAP-14 + - CAP-15 + - CAP-16 + - CAP-17 + - CAP-18 + - SEP-13 +--- + +## Announcements + +- **[Merging in CAP/SEP Process](https://github.com/stellar/stellar-protocol/pull/247)** + - Another round of edits completed; further feedback requested on the PR. + - Intent to merge immediately, formalizing the previously ad-hoc CAP/SEP process. + - All CAPs will be numbered upon acceptance as drafts; competing proposals will be explicitly rejected. + - Post-merge cleanup planned for stale PRs and issues, with authors notified of next steps. +- **Establishing focus given limited developer resources** + - Fee structure + - Payment channels + - Payment network (**Starlight**) + +## Final Comment Period - Acceptance + +- CAP-17 (Jonathan Jove) +- CAP-18 (Jonathan Jove) +- Address offer mutability (Jon) +- CAP-16 to be rejected contingent on CAP-18 approval + +## Priorities + +1. Replace Min Fee Mechanism +2. Trustline (& other) Usability + - Explicit intent to revive CAP-13 (Dan Robinson). +3. Payment Channels + - Focus on core components required for a basic payment channel design. +4. Starlight + - Deferred pending availability of dedicated development resources. + +## Deferred Items + +- CAP-7 (Jeremy Rubin) +- CAP-8 (Jeremy Rubin) +- CAP-9 (Jeremy Rubin) +- CAP-11 (Jeremy Rubin) +- Draft: Deterministic accounts and creatorTxID (David Mazières) +- CAP-14 (Jeremy Rubin) + +## Agenda + +- Final Comment proposals - new unresolved concerns (30 min max) +- CAP-17, CAP-18 +- Address offer mutability +- Replace Min Fee (60 min max) + +## Replace Min Fee Discussion + +- Diverging views: + - David and Nico prefer a mechanism _before_ raising the min fee. + - Jed favors pushing fee increases forward immediately. +- Current proposals: + - CAP-10 (Jeremy Rubin) + - CAP-15 (OrbitLens) + - Pre-draft: feeSource and feeMultiplier (David Mazières) +- [Reference spreadsheet](https://docs.google.com/spreadsheets/d/1_u0LE61V-jkXUcNBZW5xhXZEmIz5rQSgZEr8VsVl47o/edit) (OrbitLens) compares fee-sponsorship approaches (CAP-10 fee balances, feeSource/feeMultiplier, deterministic accounts, CAP-15 metadata) across tradeoffs like explicit sponsor control, pre-signed tx support, and algorithmic complexity. + - CAP-10 introduces dedicated fee balances so sponsors can preload fees, but it requires new operations and careful management of locked fee funds. + - FeeSource/feeMultiplier and deterministic accounts keep fees on existing transactions but push complexity to signers (pick fee source in advance, ensure simultaneous submissions) with limited control. + - CAP-15 embeds fee bumping in the transaction envelope, letting sponsors declare amounts per envelope, while the spreadsheet emphasizes choosing the right tradeoff between sponsor control and implementation simplicity. +- Outcomes: + - David to draft a new CAP superseding CAP-15, including Transaction versioning. + - Johnny to follow up with David regarding feeSource draft status. + +## Trustline Usability + +- Discussion on next steps for CAP-13 Change Trustlines to Balances +- Open questions: + - What changes would improve group consensus? + - Are there unpresented fundamental ideas? + - Who should own the proposal going forward? +- Related discussion: **Sender Pays** (sending assets without trustlines). +- Consensus points: + - CAP-13 enables adding balances to others and simplifies token distribution. + - SEP-13 approach explicitly rejected. + - Hard requirements need definition; Tom Q. designated owner. + - Developer-friendliness and Account ID semantics must be addressed. + +## Meeting Notes + +- Inline notes (highlighted in blue in original thread) captured above. + +## Follow-Up Actions + +- **Jon Jove** to update CAPs based on email list feedback. +- **Tom Quisel** to revise and present hard requirements for trustline usability. +- **David** to submit a new proposal for TransactionEnvelope versioning to enable changes like CAP-15. + +## Resources + +- [CAP-7: Deterministic Account Creation](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0007.md) +- [CAP-8: Self Identified Pre-Auth Transaction](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0008.md) +- [CAP-9: Linear/Exterior Immutable Accounts](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0009.md) +- [CAP-10: Fee Bump Account](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0010.md) +- [CAP-11: Relative Account Freeze](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0011.md) +- [CAP-13: Change Trustlines to Balances](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0013.md) +- [CAP-14: Adversarial Transaction Set Ordering](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0014.md) +- [CAP-15: Bump Fee Extension](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0015.md) +- [CAP-16 — Cosigned assets: `NopOp` and `COAUTHORIZED_FLAG`](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0016.md) +- [CAP-17: Update `LastModifiedLedgerSeq` If and Only If `LedgerEntry` is Modified](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0017.md) +- [CAP-18: Fine-Grained Control of Authorization](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0018.md) +- [SEP-13: `DEPOSIT_SERVER` proposal](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0013.md) +- [Original mailing-list discussion](https://groups.google.com/g/stellar-dev/c/NJl_loV_RXU/m/SarzWEJPAgAJ) diff --git a/meetings/2019-03-14.mdx b/meetings/2019-03-14.mdx new file mode 100644 index 000000000..160155587 --- /dev/null +++ b/meetings/2019-03-14.mdx @@ -0,0 +1,70 @@ +--- +title: "2019-03-14" +description: This protocol discussion covered CAP-17 and CAP-18 decisions, SEP-16 and SEP-17 payment flows, CAP-13 trustline balances, and CAP-19 transaction-envelope versioning. +authors: goodnow +tags: + - legacy + - CAP-13 + - CAP-15 + - CAP-17 + - CAP-18 + - CAP-19 + - SEP-6 + - SEP-13 + - SEP-16 + - SEP-17 +--- + +## Announcements + +- Jon made additional changes to [CAP-18](https://github.com/stellar/stellar-protocol/pull/263); with no further comments, it will move out of FCP next week. +- CAP-17 moved to **Approved**. + +## Agenda + +### Trustline Usability + +- Restated [requirements document](https://docs.google.com/document/d/1_3KcBTbF7Diu_wu-ArvajYhEcPoDp9SgK5-dNruOK3c/edit#heading=h.8j5x6v50ft4p) up for discussion. The doc captures the desired SEP-6/SEP-13 deposit and send flows: anchors should auto-complete deposits without additional user actions, deliver funds to the intended account even when it has no trustline or XLM, and allow sends to non-existent accounts by crediting the original account ID. + - Deposits must finish once the anchor receives the external asset, never forcing the user to add trustlines or extra XLM, even when accounts are uncreated. + - Sending should work regardless of the recipient’s trustlines or account state, and funds should arrive at the original Stellar account without extra steps. + - The document stresses usability: anchors/wallets should avoid complex workflows, so any solution must stay simple, fast, and easy to implement. + - SEP-17: Deposit & transfer of assets using CAP-13 + - SEP-16: Deposit & transfer of assets using deterministic accounts + - It is not possible to satisfy all requirements in the protocol's current form. + +### Issues with CAP-13 + +- If base reserve increases, malicious actors could add large numbers of trustlines to an account. +- Accounts can be DoS'd via the subentry limit. +- The proposal has very large scope, affecting most operations and assumptions in the protocol. + +### Alternatives Discussed + +- Use deterministic accounts and merge them if the receiver already has an account. +- Introduce a **SentBalance** ledger entry claimable by the receiver. +- Introduce a **remove trustline** operation that returns assets to the sender. + +### Fee Mechanisms + +- David proposed CAP-19: + - Enables future-upgradability of `TransactionEnvelope` + - Allows a simpler implementation of CAP-15 + +## Follow-up Actions + +- **David**: Write a short proposal on "embryonic accounts". +- **Jeremy**: Clarify SEP-16 workflow with deterministic accounts. +- **Jon**: Provide analysis of attack surfaces and issues in CAP-13. + +## Resources + +- [CAP-13: Change Trustlines to Balances](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0013.md) +- [CAP-15: Bump Fee Extension](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0015.md) +- [CAP-17: Update `LastModifiedLedgerSeq` If and Only If `LedgerEntry` is Modified](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0017.md) +- [CAP-18: Fine-Grained Control of Authorization](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0018.md) +- [CAP-19: Future-upgradable `TransactionEnvelope` type](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0019.md) +- [SEP-6: Anchor/Client interoperability](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0006.md) +- [SEP-13: `DEPOSIT_SERVER` proposal](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0013.md) +- [SEP-16: Account Transfer Permissionless Payment Protocol (@p2p)](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0016.md) +- [SEP-17: Issuer account funding protocol (CAP-13 Based)](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0017.md) +- [Original mailing-list discussion](https://groups.google.com/g/stellar-dev/c/uxmo4LM5FWY/m/psazVteTBgAJ) diff --git a/meetings/2019-03-21.mdx b/meetings/2019-03-21.mdx new file mode 100644 index 000000000..7e07e8b32 --- /dev/null +++ b/meetings/2019-03-21.mdx @@ -0,0 +1,39 @@ +--- +title: "2019-03-21" +description: This protocol discussion advanced authorization and transaction-envelope proposals, revisited fee-bump design, and explored possible directions for Stellar’s order book. +authors: goodnow +tags: + - legacy + - CAP-15 + - CAP-16 + - CAP-18 + - CAP-19 +--- + +## Announcements + +- CAP-16 rejected in favor of CAP-18 (now Accepted). CAP-16 will only be revived if CAP-18 encounters implementation issues. +- CAP-18 moved to Accepted. +- CAP-19 moved to FCP: Acceptance. +- Jed was in Singapore this week; trustline discussions were postponed until his return. + +## Agenda + +### Fee Follow-ups + +- Topics: CAP-19, CAP-15, and other fee-related suggestions. +- Decision: Push CAP-19 to FCP: Acceptance and reframe CAP-15 in the context of CAP-19. + +### Future of the Order Book - Ideation + +- Broad discussion of possible directions for the order book. +- No commitments were made. +- Goal: Produce an exhaustive list of ideas, followed by prioritization and requirements definition in future sessions. + +## Resources + +- [CAP-15: Bump Fee Extension](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0015.md) +- [CAP-16 — Cosigned assets: `NopOp` and `COAUTHORIZED_FLAG`](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0016.md) +- [CAP-18: Fine-Grained Control of Authorization](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0018.md) +- [CAP-19: Future-upgradable `TransactionEnvelope` type](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0019.md) +- [Original mailing-list discussion](https://groups.google.com/g/stellar-dev/c/KzgQc58510o/m/1qRSxo7GCAAJ) diff --git a/meetings/2019-03-28.mdx b/meetings/2019-03-28.mdx new file mode 100644 index 000000000..14538314e --- /dev/null +++ b/meetings/2019-03-28.mdx @@ -0,0 +1,45 @@ +--- +title: "2019-03-28" +description: This protocol discussion reviewed CAP-19 and CAP-20 implementation progress, refined CAP-15 fee-bump transactions, and considered SEP-19 multisig transaction submission. +authors: goodnow +tags: + - legacy + - CAP-5 + - CAP-15 + - CAP-19 + - CAP-20 + - SEP-19 +--- + +## Announcements + +- CAP-19 is moving to Accepted. +- "Implementation Review" stage added for CAPs (see https://github.com/stellar/stellar-protocol/pull/279); keep in mind for future CAP process. +- Jed out this week; trustline discussion pushed again. +- CAP-20 implementation is mostly there. + +## Agenda + +- CAP-15: Modified to utilize CAP-19. Goal is to bring it to a vote, or enumerate what is needed to make it pass. + - David: Two transaction IDs (inner and outer) as a result of the change. + - Nico: Original feedback was that this relies on CAP-5 logic that no longer exists in the CAP-5 implementation. + - Nico and David to discuss offline; David to submit additional edits and document constraints and issues from the meeting. +- SEP-19: + - Significant discussion with contributions from Paul Selden, Antoine (MrTicot), Orbit, Johan, and others. + - Focus should remain on SEP-19 and direction for any related SEPs. + - Can pull in Paul and others for the next meeting; it is likely the most active SEP currently. + - SEP-19 is largely focused on the StellarGuard protocol and currently only describes basic flow properties and API endpoints; substantial work remains. + - Open questions: + - Metadata (storage and off-chain handling) + - Coordinator (no core changes required) + - Possible use of an IPFS home domain + - Orbit to send a document outlining design considerations for multisig transaction coordination. + +## Resources + +- [CAP-5: Throttling and transaction pricing improvements](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0005.md) +- [CAP-15: Bump Fee Extension](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0015.md) +- [CAP-19: Future-upgradable `TransactionEnvelope` type](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0019.md) +- [CAP-20: Bucket Initial Entries](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0020.md) +- [SEP-19: Bootstrapping Multisig Transaction Submission](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0019.md) +- [Original mailing-list discussion](https://groups.google.com/g/stellar-dev/c/t162rVxLYB4/m/XB4_9st1BgAJ) diff --git a/meetings/2019-04-04.mdx b/meetings/2019-04-04.mdx new file mode 100644 index 000000000..e1063701f --- /dev/null +++ b/meetings/2019-04-04.mdx @@ -0,0 +1,61 @@ +--- +title: "2019-04-04" +description: This protocol discussion evaluated alternatives to sponsored trustlines, including SEP-16 and mergeable trustlines, with attention to client complexity, privacy, and payment usability. +authors: goodnow +tags: [legacy, CAP-15, SEP-16] +--- + +## Announcements + +- Pushing fee work out to next week given David and Orbit's absence (Tomer is also out). + +## Agenda + +- Discussing next steps for trustlines work. +- David personally doesn't feel good about pushing forward Sponsored Trustlines, despite multiple people who think it's mostly there (Tom, Orbit). +- There was initial discussion of going back to SEP-16. +- Goal today is to discuss alternative solutions (as opposed to criticism of existing solutions), given the requirements that are extensively listed [here](https://docs.google.com/document/d/1_3KcBTbF7Diu_wu-ArvajYhEcPoDp9SgK5-dNruOK3c/edit). + - Deposits have to finish without additional user clicks, even when the recipient’s account is uncreated or lacks a trustline, and nor should the user need to fund extra XLM. + - The send workflow should credit the intended account ID even if no trustline exists, so clients don’t need to coordinate new trustlines for every payment. + - The document’s overall goal is usability: keep issuer/wallet flows simple so developers actually ship the solution instead of avoiding a hard protocol change. + +## Jon proposal + +- Trying to solve the add balance problem, and the merge problem related to trustlines. +- We add a concept called a mergeable trustline. +- Can send them to anyone; only the account owner can merge it into a "classic" trustline. +- "CAP-XXXX (Pending Trustlines)" that doesn't break merge. +- Carries its own reserve, uses union-find to merge accounts. Would give O(log n) performance for merging accounts (not the most efficient version of union-find, but still performant). + +## Summary of mergeable trustline details + +- Mergeable trustlines are associated with accounts via a variant of a union-find data structure (see https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-046j-design-and-analysis-of-algorithms-spring-2012/lecture-notes/MIT6_046JS12_lec16.pdf) that does not include the path-compression optimization. +- Mergeable trustlines are immutable, except that the balance can be transferred in its entirety to the "real" trustline for the corresponding asset on the same account (noted in the meeting that this might be relaxable). +- Each mergeable trustline carries an amount of native asset equal to the base reserve at the time it was created, and this is the entire reserve requirement of the mergeable trustline. +- An account can have an arbitrary number of mergeable trustlines associated with it, even multiple mergeable trustlines for the same asset. +- Sending a mergeable trustline never fails if the receiving account exists. +- Merging accounts never fails due to the presence of mergeable trustlines. +- Open questions included what happens if the sender owns the trustline, or if the sender merges their account, creating issues around locking accounts and outstanding trustlines. +- Revocability should not be done on-ledger; it should be handled via pre-authorized transactions or other multi-phase protocols. If it is on-ledger, it should be irrevocable. + +## Nico's caveats + +- Similar complexities arise as with SEP-16: clients must track incoming mergeable trustlines, decide whether they matter, query them from Horizon, and take actions. +- This puts significant burden on clients to download and reason about many mergeable trustlines. +- Union-find might help reduce what needs to be downloaded, potentially in tandem with SEP-16. +- David, Nico, and Jon's proposals all rely on some form of "incoming trustline" at the core layer, which does not appear substantially simpler than ecosystem-level approaches. + +## SEP-16 thoughts + +- Defining the last step is difficult given current protocol constraints and would require "shrink to fit" and other small core changes. +- SEP-16 should likely remain a living document that evolves alongside core capabilities. + +## Follow-up actions + +- David to put together a list of constraints and concerns blocking CAP-15 from moving forward with Nico. + +## Resources + +- [CAP-15: Bump Fee Extension](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0015.md) +- [SEP-16: Account Transfer Permissionless Payment Protocol (atp3)](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0016.md) +- [Original mailing-list discussion](https://groups.google.com/g/stellar-dev/c/QSR2wf207ow/m/stluewnDCQAJ) diff --git a/meetings/2019-06-13.mdx b/meetings/2019-06-13.mdx new file mode 100644 index 000000000..e5e94f461 --- /dev/null +++ b/meetings/2019-06-13.mdx @@ -0,0 +1,27 @@ +--- +title: "2019-06-13" +description: This protocol discussion advanced CAP-21 generalized transaction preconditions and CAP-15 fee-bump transactions toward acceptance, focusing on payment channels and implementation details. +authors: goodnow +tags: [legacy, CAP-15, CAP-21] +--- + +## Announcements + +- CAP-21 and CAP-15 moved to FCP: Acceptance. + +## Agenda + +- David's Pre-Condition proposal: CAP-21 + - After several iterations with the Channels working group, CAP-21 was presented for decision. + - Following discussion on its importance for payment channels and its fit within the current framework, the group agreed to move CAP-21 to FCP: Acceptance. +- Clarifying final aspects of fee bump (CAP-15), including questions raised in Nico's latest pull request: + - [Add some clarifications to CAP-0015 regarding handling of duplicate bumpFee transactions PR](https://github.com/stellar/stellar-protocol/pull/323) + - CAP-15 will move to FCP: Acceptance after a final round of wording changes. +- If time permits, Jon to give an update from the trustlines/balances work. + - Decision made not to discuss this fully until the draft is finalized, particularly around rationale and alternative ideas. + +## Resources + +- [CAP-15: Fee Bump Transaction](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0015.md) +- [CAP-21: Generalized transaction preconditions](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0021.md) +- [Original mailing-list discussion](https://groups.google.com/g/stellar-dev/c/I1GAjjcfDA0/m/CIzRMI-FBAAJ) diff --git a/meetings/2019-06-27.mdx b/meetings/2019-06-27.mdx new file mode 100644 index 000000000..9d2316b1b --- /dev/null +++ b/meetings/2019-06-27.mdx @@ -0,0 +1,81 @@ +--- +title: "2019-06-27" +description: This protocol discussion examined CAP-23 two-part payments and claimable balances alongside CAP-21 transaction preconditions and CAP-22 invalid-transaction semantics. +authors: goodnow +tags: + - legacy + - CAP-15 + - CAP-21 + - CAP-22 + - CAP-23 +--- + +## Announcements + +- CAP-15 and CAP-21 move to _Accepted_ today (after this meeting), barring no new concerns. +- CAP-21 moves back to _Draft_ in order to resolve CAP-22 prior to acceptance. + +## Agenda + +- CAP-23 + - Focused on temporal separation between initiating a payment and receiving a payment. + - Explicitly **does not** replace existing payment operations. + - **David's initial framing:** ~10% additional complexity yields significantly more utility. + +### CAP-23 Design Discussion + +- **AuthorizeBalance** + - Should include an optional `AccountID *revocableBy`. + - Small increase in complexity but worth it for added control. +- **Threshold semantics** + - `CreateBalance` should use the _medium_ threshold. + - Authorization should mirror AllowTrust. + - Claiming at a _low_ threshold may be acceptable, since low-threshold keys cannot otherwise act. +- **Operation naming** + - Consider appending `Op` to operation names (XDR style / consistency). +- **NATIVE asset semantics** + - AuthorizeBalance behavior for `NATIVE` assets is unspecified (invalid vs no-op). + - Might be better to factor shared data structures out of both AuthorizeBalance and AllowTrustOp. + - AuthorizeBalance operates by ID and is unaware of the asset of the BalanceEntry; this structure may still be useful for AllowTrust. +- **Why AuthorizeBalance exists** + - Needed to authorize _both_ the account and the payment itself. + - Necessary for deauthorization when assets are sent to bad actors. + - Important for payment channels to ensure all parties are authorized before payout. +- **ACCOUNT_MERGE interaction** + - BalanceEntries resemble hyper-specialized deterministic accounts. + - They do **not** participate in merges and may be abandoned (with their own reserve). + - This behavior should be explicitly documented in the CAP. +- **Global revoke scenarios** + - In cases where assets must be returned for replacement, funds locked in BalanceEntries pose challenges. + - AuthorizeBalance enables trustline authorization prior to account creation. + - Even if authorization is revoked, reclaiming balances should still be possible. +- **Extensibility** + - Consider extending `claimBy` using a union to allow future claim-by-signer functionality. +- **UX considerations** + - Some concern that less-knowledgeable users may struggle with the flow. + - Others believe wallet UX and the existing payment operation mitigate this risk. + +## CAP-21 / CAP-22 & Payment Channel Implementation + +- CAP-21 + - Moved out of Final Comment Period back to Draft due to concerns raised by CAP-22. + - May be implemented separately (branch or protocol version) for payment channels. + - Preference is to resolve outstanding issues before acceptance. +- CAP-22 + - Open question: adopt CAP-22 as written, or pursue a stronger invariant (only fully executing transactions succeed). + +## Follow-Up Actions + +- CAP-23 (Jon) + - Add explicit behavior details regarding `ACCOUNT_MERGE`. + - Evaluate low-threshold usage for `ClaimBalance`. + - Append `Op` to operation names in XDR. + - Extend BalanceEntry claimer via a union to support future signer-based claims or wildcard claimBy. + +## Resources + +- [CAP-15: Fee Bump Transaction](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0015.md) +- [CAP-21: Generalized transaction preconditions](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0021.md) +- [CAP-22: Invalid transactions must have no effects](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0022.md) +- [CAP-23: Two-Part Payments with `BalanceEntry`](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0023.md) +- [Original mailing-list discussion](https://groups.google.com/g/stellar-dev/c/va9Y7lkP4uI/m/K2W_AkvzCQAJ) diff --git a/meetings/2019-07-25.mdx b/meetings/2019-07-25.mdx new file mode 100644 index 000000000..eb2549b7a --- /dev/null +++ b/meetings/2019-07-25.mdx @@ -0,0 +1,35 @@ +--- +title: "2019-07-25" +description: This protocol discussion reviewed CAP-24 path-payment symmetry, CAP-15 signer behavior, and decisions involving transaction preconditions, invalid transactions, and bucket shadowing. +authors: goodnow +tags: + - legacy + - CAP-15 + - CAP-21 + - CAP-22 + - CAP-24 + - CAP-25 +--- + +## Agenda + +- CAP-24 + - Jon to follow up with Morley to get perspective on how this feels from a wallet implementation's perspective, particularly between the two operations. +- CAP-15 + - Implementation question around removal of one-time signers, which currently does not take place. + - Consensus: preserve existing behavior for now and discuss behavior changes separately. + - Jon to follow up with Nico when he returns to better understand existing behavior. +- CAP-21, CAP-22, CAP-25 + - CAP-25 moves to Final Comment Period (FCP): Acceptance. + - CAP-21 is dependent on CAP-22. + - CAP-22 must address additional feedback from Nico. + - David to own follow-up on CAP-21/0022 dependency resolution. + +## Resources + +- [CAP-15: Fee Bump Transaction](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0015.md) +- [CAP-21: Generalized transaction preconditions](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0021.md) +- [CAP-22: Invalid transactions must have no effects](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0022.md) +- [CAP-24: Make `PathPayment` Symmetrical](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0024.md) +- [CAP-25: Remove Bucket Shadowing](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0025.md) +- [Original mailing-list discussion](https://groups.google.com/g/stellar-dev/c/a9JH2c3jTEw/m/k5wg4XNnDAAJ) diff --git a/meetings/2019-11-04.mdx b/meetings/2019-11-04.mdx new file mode 100644 index 000000000..4fe06092e --- /dev/null +++ b/meetings/2019-11-04.mdx @@ -0,0 +1,26 @@ +--- +title: "2019-11-04" +description: Denelle Dixon’s Meridian address examined SDF’s nonprofit stewardship, decentralization progress, and treasury restructuring, followed by a Q&A with Jed McCaleb. +authors: goodnow +tags: [community] +--- + +import YouTube from "@site/src/components/YouTube"; + + + +Denelle Dixon closed day one of the inaugural Meridian with a forward-looking address on SDF’s evolving role and Stellar’s long-term direction. Speaking from the perspective of her first six months leading the foundation, she emphasized SDF’s identity as a nonprofit steward and ecosystem convener, translating open-network principles such as transparency, interoperability, and trust-by-design into practical support for builders, institutions, and regulators. + +The talk focused on aligning governance, resources, and community momentum as Stellar moves from early growth into a more decentralized and durable network. Denelle outlined what has worked well so far, where SDF has fallen short, and how a restructured treasury and clearer priorities are meant to support sustainable adoption while reducing the foundation’s centrality over time. Jed McCaleb joined Denelle for the closing audience Q&A. + +### Key Topics + +- What SDF is (and is not): a nonprofit with no shareholders or dividends, focused solely on long-term network adoption and ecosystem health. +- Decentralization progress: increasing validator independence and a maturing governance feedback loop from community discussion to protocol change. +- What’s working: scalable technology, a growing global team, stronger community coordination, and expanding ecosystem projects. +- What needs improvement: Stellar-wide marketing, policy and regulatory engagement, ongoing transparency, and more effective lumen distribution. +- Treasury reset: announcement of a 55.5 billion lumen burn, with remaining resources reorganized to better align with mission and execution capacity. +- New funding buckets: operational runway with a multi-year release plan, ecosystem and infrastructure support, currency and liquidity support, use-case investment, and user distribution through applications. +- Enterprise Fund model: the ability to invest in or acquire companies to accelerate priority use cases, with returns recycled back into the fund. +- Regulatory approach: emphasis on education and consumer protection, positioning the network layer as internet-like infrastructure. +- Closing Q&A with Jed McCaleb: sustaining SDF beyond the initial multi-year plan, improving DEX liquidity, overcoming network-effects challenges, environmental advantages versus mining-based chains, and inclusion as a requirement for mainstream adoption. diff --git a/meetings/authors.yml b/meetings/authors.yml index 9d92d724b..aa795e351 100644 --- a/meetings/authors.yml +++ b/meetings/authors.yml @@ -56,3 +56,11 @@ kaankacar: image_url: https://github.com/kaankacar.png socials: github: kaankacar +goodnow: + name: Johnny Goodnow + url: https://github.com/theaeolianmachine + image_url: https://github.com/theaeolianmachine.png + page: true + socials: + linkedin: jgoodnow + github: theaeolianmachine diff --git a/routes.txt b/routes.txt index 9f0304cc0..21eec3e0c 100644 --- a/routes.txt +++ b/routes.txt @@ -837,6 +837,16 @@ /docs/validators/admin-guide/soroban-settings /docs/validators/tier-1-orgs /meetings +/meetings/2019/01/24 +/meetings/2019/03/07 +/meetings/2019/03/14 +/meetings/2019/03/21 +/meetings/2019/03/28 +/meetings/2019/04/04 +/meetings/2019/06/13 +/meetings/2019/06/27 +/meetings/2019/07/25 +/meetings/2019/11/04 /meetings/2024/01/18 /meetings/2024/01/26 /meetings/2024/02/01 @@ -918,6 +928,7 @@ /meetings/authors/carstenjacobsen/page/2 /meetings/authors/carstenjacobsen/page/3 /meetings/authors/elliotfriend +/meetings/authors/goodnow /meetings/authors/kalepail /meetings/page/2 /meetings/page/3 @@ -925,12 +936,41 @@ /meetings/page/5 /meetings/page/6 /meetings/page/7 +/meetings/page/8 /meetings/tags +/meetings/tags/cap-10 +/meetings/tags/cap-11 +/meetings/tags/cap-13 +/meetings/tags/cap-14 +/meetings/tags/cap-15 +/meetings/tags/cap-16 +/meetings/tags/cap-17 +/meetings/tags/cap-18 +/meetings/tags/cap-19 +/meetings/tags/cap-20 +/meetings/tags/cap-21 +/meetings/tags/cap-22 +/meetings/tags/cap-23 +/meetings/tags/cap-24 +/meetings/tags/cap-25 +/meetings/tags/cap-5 +/meetings/tags/cap-6 +/meetings/tags/cap-7 +/meetings/tags/cap-8 +/meetings/tags/cap-9 +/meetings/tags/community /meetings/tags/developer /meetings/tags/developer/page/2 /meetings/tags/developer/page/3 /meetings/tags/developer/page/4 /meetings/tags/developer/page/5 /meetings/tags/developer/page/6 +/meetings/tags/legacy /meetings/tags/protocol +/meetings/tags/sep-13 +/meetings/tags/sep-16 +/meetings/tags/sep-17 +/meetings/tags/sep-19 +/meetings/tags/sep-6 +/meetings/tags/sep-8 /search