Final Comment Period for CAP-0023: Two-Part Payments

[Jonathan Jove]

We are opening the one week long final comment period for CAP-0023 (Two-Part Payments with PreparedTrustLineEntry and ClaimableBalanceEntry) before accepting it. We have developed this proposal from a targeted tool into a powerful building-block for the protocol. Any feedback, comments, and questions are appreciated!

[Bartek Nowotarski]

Hey Jon!

I'm late to the party but decided to send a message here because I have small, cosmetic suggestions to CAP-0023 and some questions:

• We have TimePoint type. Why not use it in absBefore and absAfter?
• Why not use a fixed-length array instead of variable-length in andPredicates and orPredicates? It would make validation easier (for [] it always has to be 2 elements so we could remove <2 conditions from validation checklist).
• There are two cases in which an account "does not have at least reserve available limit of native asset" when sending back a reserve. Is this really the case? When something like this can happen?
• Any specific reason for allowing up to 10 claimants? Just curious.
• Why not use a global counter/sequence (like with offers) instead of operation ID? Both OfferEntry and ClaimableBalanceEntry are ledger entries so it's not consistent.
  
• Big one: have you considered Reverse Polish notation instead of the tree-like structure for ClaimPredicate? I think it would be more powerful if we want to extend it in the future and would make running and validating it easier. It would be also easier to represent in downstream systems (list vs tree).

Bartek

On Fri, Feb 28, 2020 at 9:49 AM 'Jonathan Jove' via Stellar Developers <stell...@googlegroups.com> wrote:

We are opening the one week long final comment period for CAP-0023 (Two-Part Payments with PreparedTrustLineEntry and ClaimableBalanceEntry) before accepting it. We have developed this proposal from a targeted tool into a powerful building-block for the protocol. Any feedback, comments, and questions are appreciated!

--
You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellar-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/CAG4FKhzfkTe27mcBeYMWR%2B5fNUy7_5OJ1yviGokUt1tBv_aFuA%40mail.gmail.com.

[Jonathan Jove]

Good questions!

> We have TimePoint type. Why not use it in absBefore and absAfter?

We could have done so. The only reason I didn't is that TimePoint is defined as uint64, which can cause issues for downstream systems like PostgreSQL. 

> Why not use a fixed-length array instead of variable-length in andPredicates and orPredicates? It would make validation easier (for [] it always has to be 2 elements so we could remove <2 conditions from validation checklist).

I wanted to, but it is not possible with xdrc. The problem is that xdrc is not standard-compliant. Look at https://tools.ietf.org/html/rfc4506#section-4.19 where it introduces the alternative definition of "stringlist". It is my understanding that xdrc does not generate C++ which compiles in that case. I have discussed this with David in the past. If he wants to fix this, then I would very much prefer to use fixed-length arrays.

> There are two cases in which an account "does not have at least reserve available limit of native asset" when sending back a reserve. Is this really the case? When something like this can happen?

With the changes to ClaimableBalanceEntry coming in CAP-33, this situation is no longer relevant. But yes this really can happen, as a consequence of https://github.com/stellar/stellar-protocol/blob/master/core/cap-0003.md! I actually get this question quite often, so I will lay out such a scenario now. You create an account A with starting balance 3*baseReserve + baseFee. You then submit a transaction with fee baseFee that creates an offer selling (INT64_MAX - 3*baseReserve) of any asset issued by A for native at a price of 1:1. The account has a balance of 3*baseReserve; the native buying liabilities are (INT64_MAX - 3*baseReserve). For the account to satisfy its native buying liabilities, it's balance must be less than INT64_MAX - (INT64_MAX - 3*baseReserve) = 3*baseReserve. So the account has a current balance, minimum balance, and maximum balance of 3*baseReserve!

> Any specific reason for allowing up to 10 claimants? Just curious.

No specific reason, it just seemed like it was a high enough number to satisfy any typical use case. Is there some other number you prefer?

> Why not use a global counter/sequence (like with offers) instead of operation ID? Both OfferEntry and ClaimableBalanceEntry are ledger entries so it's not consistent.

I agree it's not consistent, but it was a deliberate choice. If I could, then I would make it consistent by changing it for offers (obviously I cannot do this). The hash-based approach has the advantage of knowing in advance the ID you will generate. This means that it can be used in protocols much more easily, because you can pre-sign transactions that depend on the ID that will eventually appear.

> Big one: have you considered Reverse Polish notation instead of the tree-like structure for ClaimPredicate? I think it would be more powerful if we want to extend it in the future and would make running and validating it easier. It would be also easier to represent in downstream systems (list vs tree).

I haven't considered this, but it is a very interesting idea! I'm going to give this some thought, and I will update you later.

Thanks,

Jon

[Bartek Nowotarski]

Thanks for a quick response! I have one extra question below but the rest is clear, thanks again!

On Fri, Jun 26, 2020 at 8:28 PM Jonathan Jove <j...@stellar.org> wrote:

Good questions!

> We have TimePoint type. Why not use it in absBefore and absAfter?

We could have done so. The only reason I didn't is that TimePoint is defined as uint64, which can cause issues for downstream systems like PostgreSQL. 

I understand now but we already use TimePoint for time bounds. What about adding a validation step that disallows unreasonable values (like years 2100+ or something like that). This wouldn't cause problems downstream but will be consistent with existing structs using this type. I think adding validation like this is actually better for downstream apps displaying these values in human readable format (right now you can see something like 277026596-01-01 00:00:00 for some transactions with max_time in Horizon ;) ).

[Graydon Hoare]

On Fri, Jun 26, 2020 at 10:44 AM 'Bartek Nowotarski' via Stellar
Developers <stell...@googlegroups.com> wrote:

> Big one: have you considered Reverse Polish notation instead of the tree-like structure for ClaimPredicate? I think it would be more powerful if we want to extend it in the future and would make running and validating it easier. It would be also easier to represent in downstream systems (list vs tree).

Hmm, I think RPN wouldn't bring anything new to the table here, and
would incur additional costs. Specifically:

- XDR is already a serial (pre-order) encoding of a tree. Downstream
clients already need to be able to deserialize XDR in order to work
with any of this. Adding a new RPN (post-order) encoding for sub-trees
within XDR increases the burden on downstream clients, doesn't reduce
it.

- We already have an idiom for versioning / extending XDR that works
ok: version unions. It's not beautiful but it does work and explicitly
defines version-compatibility points in need of coverage.

- If you want to delay XDR-decoding of some sub-tree, say either to
enforce a "whole sub-tree" size limit or perhaps as an extreme case of
versioning "everything" in a sub-tree, serializing an "inner" XDR tree
into an opaque array embedded in an "outer" XDR structure also works.
We do this in a few places already (eg. when signing payloads or
versioning upgrades).

- XDR definitions have strong well-formedness and type-compatibility
rules baked into them already. A new encoding for sub-trees would need
additional rules around this, eg. to prohibit [pubkey, pubkey, +] as
an operator-operand-incompatible tree or [1, +] as a non-well-formed
tree.

-Graydon

[Leigh McCulloch]

Hi Jon,

I'm wondering if we can get one more capability out of CAP-23 than it currently provides.

CAP-23 does a solid job of making it possible to push a balance into an object another account can claim. But it would be more powerful and flexible if an account could push a balance into an object that some future account that doesn't yet exist or isn't yet known could claim, but where the signers of that future account is known. What I'm describing is I think something you considered early on where you can attach signers to a ClaimableBalance and those signers could claim the balance into any account, but I can't find the reasoning for why we didn't explore that further. I'm thinking it might be because a Stellar account on its own is basically a claimable balance with signers and so maybe a claimable balance with the same capabilities would be too much overlap.

Is this something you think belongs in CAP-23, or something that would be better explored separately, or should only be provided by accounts and not claimable balances?

Leigh

[Jonathan Jove]

Hi Leigh,

Claimants should be accounts based on the analysis in this section https://github.com/stellar/stellar-protocol/blob/master/core/cap-0023.md#claimablebalanceentry-claimants-are-accounts, specifically the second paragraph. I don't know how to unify authorization and claimable balance entries otherwise.

It is possible to use claimable balance entries for accounts that don't exist. But accounts that aren't yet known is a far more difficult problem. In general, I don't think Stellar really supports that use case today. I don't know if we want to tackle something like that here, although I'm open to proposals as always. What is the use case for such functionality?

Thanks,

Jon

--

You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellar-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/cc1aac20-8477-47bf-a64f-43d316696fa5n%40googlegroups.com.

[Nicolas Barry]

Agree.

I think that what Leigh is describing sounds a lot like what UTXOs would provide (decoupling from accounts).

UTXO support is something I spent some time looking into in the context of CAP0023 (the analysis I did is still mostly relevant) and I think it is doable as an extension if there is more appetite for it.

As it's a purely additive change on top of CAP0023, what we decided on that front was to *not* do anything at this time as it adds quite a bit of complexity that we don't need for the first version of two parts payment.

Nicolas

To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/CAG4FKhyHv5-zMmOGydAQLa7bkPoAp4YKm6%2BurhJ-uqRR3JKbcg%40mail.gmail.com.