Sponsored trustlines (a.k.a. embryonic trustlines)

[David Mazieres]

In order to facilitate sending assets to an account, I propose adding
a new kind of "sponsored trustline" that can be created by someone
other than the account holder. A sponsored trustline holds both an
issued asset and the native asset, the later of which serves to meet
the trustline's reserve requirement.

Accounts creating sponsored trustlines contribute the native assets
required for the sponsored trustline to meet the base reserve
requirement. This is done through one new operation called
SPONSOR_TRUST, with the following argument:

enum OperationType
{
// ...
BUMP_SEQUENCE = 11,
SPONSOR_TRUST = 12
};

// This type can get factored into AllowTrustOp, too
union IssuedAsset switch (AssetType type) {
// ASSET_TYPE_NATIVE is not allowed

case ASSET_TYPE_CREDIT_ALPHANUM4:
opaque assetCode4[4];

case ASSET_TYPE_CREDIT_ALPHANUM12:
opaque assetCode12[12];
};

struct SponsorTrustLineOp
{
// Account for which trustline is being sponsored
AccountID destination;

// Asset held in trustline
IssuedAsset asset;

// Amount of asset to move into trustline
int64 amount;

// Amount of ASSET_TYPE_NATIVE to move into trustline
// (must be at least baseReserve if trustline does not exist)
int64 nativeAssetAmount;
};

If the destination account already has a normal TrustLine for asset,
this operation acts just like a payment sending amount of asset to
destination.

Otherwise, if the account does not already have a sponsored trustline
and if it has not reached the limit for the number of sponsored
trustlines (20), then the operation creates a sponsored trustline.
Either way, if a sponsored trustline exists or is created, the operation
moves both amount of asset and nativeAssetAmount of ASSET_TYPE_NATIVE
into the new sponsored trustline. The operation fails if the asset is
AUTH_REQUIRED, the sponsored trustline does not have AUTHORIZED_FLAG
set, and amount is non-zero.

A sponsored trustline has the following characteristics:

* The owner may delete the sponsored trustline by calling
ChangeTrustOp with a limit of zero. When this happens, the
IssuedAsset is destroyed and the nativeAssetAmount is transferred
into the account's main balance.

* The owner may convert a sponsored trustline into a normal
trustline by calling ChangeTrustOp with a limit at least as high
as the balance. (Calling with a non-zero limit below the balance
causes the operation to fail.) When this happens, the
nativeAssetAmount is transfered into the account's main balance.

* Asset issuers may set and clear the AUTHORIZED_FLAG on a sponsored
trustline as usual via AllowTrustOp.

* Payments and path payments into a sponsored trustline always fail.
SponsorTrustLineOp is the only way to move assets into a sponsored
trustline.

* The account that owns the sponsored trustline may not use the
assets in the trustline without first claiming them by converting
it to a normal trustline.

* The limit is always INT64_MAX, and there can never be any
liabilities.

* The account that owns the sponsored trustline may be merged
without deleting the sponsored trustline, in which case the
IssuedAsset is destroyed and the lumens are sent to the
destination account of the merge.

* A destination account may have at most 20 sponsored trustlines.
(This and the previous point are to avoid DoS attacks, so we might
want to fiddle with the specifics.)

A sponsored trustline is just an ordinary trustline with a different
union value at the end to eliminate liabilities (which are not
allowed) and track the amount of native currency in the trustline.

enum TrustLineEntryType {
TRUSTLINE_V0 = 0,
TRUSTLINE_V1 = 1,
TRUSTLINE_SPONSORED = 2
};

struct TrustLineEntry
{
AccountID accountID; // account this trustline belongs to
Asset asset; // type of asset (with issuer)
int64 balance; // how much of this asset the user has.
// Asset defines the unit for this;

int64 limit; // balance cannot be above this
uint32 flags; // see TrustLineFlags

// reserved for future use
union switch (TrustLineEntryType v)
{
case TRUSTLINE_V0:
void;
case TRUSTLINE_V1:
struct
{
Liabilities liabilities;

union switch (int v)
{
case 0:
void;
}
ext;
} v1;
case TRUSTLINE_SPONSORED:
int64 reserve; // Native assets held by this trustline
}
ext;
};

[Mister Ticot]

That's very precisely the solution I crafted the other day when we had this big debate about trustlines — in the "Sender adds trustline" discussion of this very group :)

Yeah, of course I support this. This is working around any issue that was raised by the time. No other option offered that.

Nice that you did put it in code. I advice that you rename it "Pending trustline" — its original name — as this makes the purpose more obvious to everybody.

P.S.: I'm a free software guy, and when I work on something that happen to be useful — especially for free — I appreciate to receive due credits & a little "Thank you!". I know it's not the style de la maison, but it's important for me. For the record I had to face contradictor with quite a mean behavior, by the time.

---

From: stell...@googlegroups.com <stell...@googlegroups.com> on behalf of David Mazieres <dm-list-s...@scs.stanford.edu>
Sent: Friday, March 15, 2019 7:18:04 AM
To: Stellar Developers
Subject: [stellar-dev] Sponsored trustlines (a.k.a. embryonic trustlines)

 

--
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 post to this group, send email to stell...@googlegroups.com.
Visit this group at https://groups.google.com/group/stellar-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/87r2b9t2gz.fsf%40ta.scs.stanford.edu.
For more options, visit https://groups.google.com/d/optout.

[Rafal Malinowski]

Can an account have two sponsored trustlines for the same asset?

> --
> 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 post to this group, send email to stell...@googlegroups.com.
> Visit this group at https://groups.google.com/group/stellar-dev.
> To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/87r2b9t2gz.fsf%40ta.scs.stanford.edu.
> For more options, visit https://groups.google.com/d/optout.

--
Rafał Przemysław Malinowski
C++ Developer at Stellar.org

[David Mazieres]

'Rafal Malinowski' via Stellar Developers <stell...@googlegroups.com>
writes:

> Can an account have two sponsored trustlines for the same asset?

No. But two SponsorTrustLineOp operations can both contribute to the
sponsored trustline. Hence, even if the base reserve is increased,
someone else can top-up the reserve amount.

I didn't really specify the behavior when the base reserve goes up, but
presumably the sponsored trustline gets locked, cannot receive more
funds, and can only be converted to normal if the resulting account
would meet the base reserve.

David

[Christian Rudder]

The contradictor is still here! 

David, I'd like to know what the sponsored trustline workaround adds vis a vis Dan's more straightforward suggestion from before.

I 100% think it's a major upgrade to where we are, so if it's this or nothing, I much prefer your solution to the current stasis. 

But, still, this kind of account/sending behavior will seems strange to devs coming to Stellar. It adds an additional layer of complexity--now there are two kinds of trustlines where even one kind of trustline is unusual. Furthermore the two kinds of trustlines act quite differently from one another. And, for end-users, it still requires wallets/exchanges to either obfuscate this sponsored trustline distinction (in which case what's the point of having it) or, if they surface the sponsored trustlines to users, to build in more UI baggage. There's already A LOT of that with Stellar, and I don't think adding in more is a good idea.

So these are the costs of your proposal--can you explain to me the upside?

--
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 post to this group, send email to stell...@googlegroups.com.
Visit this group at https://groups.google.com/group/stellar-dev.

To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/87mulwdqnn.fsf%40ta.scs.stanford.edu.

[Ishai Strauss]

* Payments and path payments into a sponsored trustline always fail. 
    SponsorTrustLineOp is the only way to move assets into a sponsored 
    trustline.

Why? This seems like it would cause a bunch of issues (i.e. imagine someone creates a sponsored trustline and then somebody else tries to send a payment before the account holder has a chance to accept the trustline). Why not let any payments accumulate in the sponsored trustline just like a regular trustline?

  * A destination account may have at most 20 sponsored trustlines. 

Why? This seems like it would open up the possibility of DoS attacks (i.e. I just spam fill an accounts 20 sponsored trustline limit). If we just make it unlimited then the sponsored trustline creator needs to pay a base reserve each time. That should prevent spam (if it doesn't then the base reserve should be changed). 

[Ishai Strauss]

I may be misunderstanding the proposal but I don't really see this as two separate kinds of trustlines (rather an additional column in the existing trustline table). From the user's perspective it will just be a balance they need to "Accept" before they can use, seems pretty user-friendly to me. Also, it really doesn't change much of the current way of doing things (i.e. there are still trustlines, just a new column and a new operation to add a trustline).

[Christian Rudder]

Ishai, I share both your questions/concerns in the first email. 

For your second, it just makes Stellar more complicated. Both for devs and for end users. Having a flows for users to "accept" funds that they think they already have is both more work, and, in terms of user-experience, just weird.

Again, Dave's proposal is way better than where we are--and we've been going in circles on this for months now--but his idea is worse in some clear ways from one already on the table (Dan's.) So I'd just like to know in which ways is it better.

--
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 post to this group, send email to stell...@googlegroups.com.
Visit this group at https://groups.google.com/group/stellar-dev.

To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/20f9bf2c-b91c-4fe2-b168-77573072d97f%40googlegroups.com.

[Ishai Strauss]

I'm not sure I agree with you that it is a weird user experience to have to accept a payment. In fact, until recently chase quickpay had users accept each payment that came in. Now, its true they recently changed it so that one does not have to accept incoming payments (they just hit your account and you get a notification) but that is for USD through chase, not some random XYZ token on Stellar. I mean, not matter which way we go, wallets are going to have to do this kind of work anyway. A wallet can't just let somebody flood an accounts balances with random garbage. There would need to be a way for user to "accept" a balance as something they care about. This is just formalizing that in the protocol (which I like).

[David Mazieres]

First, for everyone on the list, I should have provided some context.
I'm not saying my proposal is better or worse than other proposals. The
point was just to see what a minimal change looks like that uses the
embryonic or "pending" (Mr. Ticot's term, probably preferable to mine)
account concept to facilitate sending issued assets to someone for the
first time. The protocol working group wants to taxonomize the solution
space to be able to discuss trade-offs more comprehensively and make
progress on this issue.

> David, I'd like to know what the sponsored trustline workaround adds vis a
> vis Dan's more straightforward suggestion from before.

Do you mean SEP-0013? I think the working group considers SEP-0013 to
be a bit complicated. It's also a much bigger change, in that it gets
rid of features like a trustline balance.

> I 100% think it's a major upgrade to where we are, so if it's this or
> nothing, I much prefer your solution to the current stasis.

It's just another point in the design space, which in its favor has
backwards compatibility. I would like to see us make progress with any
one of these proposals, and sometimes the best way to do that is to
throw more proposals up. For instance, when I proposed cosigned assets,
this inspired Jon to propose his even simpler sandwich solution, and now
at long last we have a solution to that problem on the horizon.

> But, still, this kind of account/sending behavior will seems strange to
> devs coming to Stellar. It adds an additional layer of complexity--now
> there are two kinds of trustlines where even one kind of trustline is
> unusual. Furthermore the two kinds of trustlines act quite differently from
> one another.

It doesn't need to be this way. The idea was that if you are sending
assets to an account, you might want to know whether or not the owner of
the account has consented to hold those assets. Nothing breaks
technically in my proposal if you let payments and path payments just
work to sponsored trustlines, it's just a question of which behavior we
want. A sponsored trustline souldn't prevent someone from merging an
account, so do we want to risk that a payment succeeds to an account
that is subsequently merged, destroying the assets sent by that payment?

> And, for end-users, it still requires wallets/exchanges to
> either obfuscate this sponsored trustline distinction (in which case what's
> the point of having it) or, if they surface the sponsored trustlines to
> users, to build in more UI baggage. There's already A LOT of that with
> Stellar, and I don't think adding in more is a good idea.
>
> So these are the costs of your proposal--can you explain to me the upside?

The proposal would work either way. The two questions are: should you
need to consent to holding an asset (I think the group felt yes), and
then should a normal payment work to someone who hasn't consented to
hold the assset (up for debate).

David

[Orbit Lens]

This approach looks quite appealing to me. From the UI perspective, it's quite easy to hide by default new "embryonic" trustlines and organize the notifications about the incoming payments. And it also contains the description of the extended merge behavior. 

Of course, CAP-13 looks much simpler from the developer and end-user perspective. And from that point of view, it is still the number one choice. However, as Nicolas and Jon stated, CAP-13 implementation will require major changes in multiple Core modules. So if David's new proposal is easier to implement, I'll vote for it, as it anyways will be better than current UX.

I have only one remark/suggestion. To my mind, the SPONSOR_TRUST operation should check whether the trustline exists, and use PATH_PAYMENT internally to get enough XLM for the reserve. In that case, the anchor (or a regular user) can simply send 1BTC to the destination account and don't care about the reserve requirements. Under the hood, SPONSOR_TRUST checks the trustline, and if it's not there sends PATH_PAYMENT BTC -> XLM (0.5) to fund new trustline creation. The recipient automatically receives the rest (something like 0.9999934 BTC) on the account balance. Of course, it requires some liquidity to be present on the DEX for the asset being sent. Therefore, it might not work in all cases. Such behavior may be optional (if nativeAssetAmount==0, then use PATH_PAYMENT to fund the trustline).

[Ishai Strauss]

What do you think about allowing regular payments to a pending trustline and the 20 pending trustline limit? btw I vote for "Pending" over "Embryonic" or "Sponsored". if we are voting.

I have to disagree with you regarding packing the path payment logic into the sponsor operation. It just overcomplicates it IMO especially given lack of liquidity etc. and will result in some unexpected results sometimes I think. Better to leave them decoupled. Then, the sender can either:

A) First do a path payment to themselves in one tx and then send the payment (this allows them to change BTC -> XLM if there is liquidity, otherwise to just sponsor the trustline with their own XLM)

B) Send path payment and sponsor ops in one tx (which allows them to conditionally send the sponsor if there is liquidity).

[Orbit Lens]

What do you think about allowing regular payments to a pending trustline

It may have some implications in the situation when two different people send the same asset to the same destination. A user won't be able to refuse one of the payments, as both of them ended up the same balance record in the db. Regular users probably don't care, but it may impact the smart contracts. 

20 pending trustline limit

It's a protection from some kind of spam attack, but 20 looks like a too small limit for me. I'd set something like 1000. If someone wants to spend 500 XLM on spamming a third-party account, the destination account can once in a while remove all those trustlines and cash the reserves.

I have to disagree with you regarding packing the path payment logic into the sponsor operation

Probably you are right. Just trying to think of any way to simplify the sending process. Well, the PATH_PAYMENT really can be implemented on the sender side. It should be a sender's wallet problem.

[David Mazieres]

Orbit Lens <orbit...@gmail.com> writes:

> This approach looks quite appealing to me. From the UI perspective, it's
> quite easy to hide by default new "embryonic" trustlines and organize the
> notifications about the incoming payments. And it also contains the
> description of the extended merge behavior.
>
> Of course, CAP-13 looks much simpler from the developer and end-user
> perspective. And from that point of view, it is still the number one
> choice. However, as Nicolas and Jon stated, CAP-13 implementation will
> require major changes in multiple Core modules. So if David's new proposal
> is easier to implement, I'll vote for it, as it anyways will be better than
> current UX.

From the end-user perspective, I was just imagining you would have a
bunch of pending trustlines (let's just adopt Mr. Ticot's term), and
could click "accept" or "reject" to accept or reject the tokens. You
get the base reserve either way, which more than makes up for the
transaction fee of having to reject a spam trustline.

So whether this is simpler than CAP-13 depends on whether we think it
should be possible to make an account hold an asset against its will.

> I have only one remark/suggestion. To my mind, the SPONSOR_TRUST operation
> should check whether the trustline exists, and use PATH_PAYMENT internally
> to get enough XLM for the reserve.

I'm agnostic on this point because I'm not close enough to the use case.
I discussed it briefly with Tom, who seemed to think that path payment
functionality was not necessary. I think if we did have path payments,
it might be more useful for the main asset than for the reserve. But
this can be debated, particularly if there are specific use cases that
need the path payment functionality.

David

[David Mazieres]

'Ishai Strauss' via Stellar Developers <stell...@googlegroups.com>

writes:

> What do you think about allowing regular payments to a pending trustline
> and the 20 pending trustline limit? btw I vote for "Pending" over
> "Embryonic" or "Sponsored". if we are voting.

There's no technical reason not to allow regular payments, but it seemed
a little more dangerous (since the assets could get destroyed) and not
necessary. You can always emulate a regular payment by sending a
SponsorTrustLineOp with a nativeAssetAmount of 0. The bigger question
is whether you need path payments into pending trustlines, and if the
answer is no then the existing proposal is okay.

In terms of the 20 pending trustline limit, remember the limit only
applies to pending trustlines. If spammers fill your account with 20
pending trustlines, you can reject them all, get 10 XLM, and then use
those XLM to create non-pending trustlines for the assets that you
really want to receive.

The main reason for placing the limit is to ensure that the XLM don't
get lost when you merge an account with pending trustlines. The
ACCOUNT_MERGE can pull XLM from 20 pending trustlines, but not
1,000,000. An alternative would be not to have a limit and to say that
when you merge an account you don't collect the XLM in pending
trustlines. Rather, the pending trustlines could live forever as
garbage in the ledger. But that seemed uglier.

David

[Jeremy Rubin]

Limiting the pending trust lines is a fundamentally broken approach for channels.

Should be unlimited. 

--
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 post to this group, send email to stell...@googlegroups.com.
Visit this group at https://groups.google.com/group/stellar-dev.

To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/87o96cj77k.fsf%40ta.scs.stanford.edu.

[David Mazieres]

Christian Rudder <crudderp...@gmail.com> writes:

> Ishai, I share both your questions/concerns in the first email.
>
> For your second, it just makes Stellar more complicated. Both for devs and
> for end users. Having a flows for users to "accept" funds that they think
> they already have is both more work, and, in terms of user-experience, just
> weird.

In the protocol group, we discussed whether it was better to consent to
holding an asset before a payment or after, and the group seemed to feel
that it was better to consent afterwards. In other words, one could
imagine, when buying some new asset from an issuer or exchange, that you
would sign some message allowing the seller to create the trustline for
your account. But then if you are out with friends, someone can't just
send you an asset for which you don't have a trustline, you would first
have to get out your wallet and authorize that or create the trustline.

Another alternative would be to allow anyone to create a trustline on
any account, which is essentially what Dan proposed in SEP-0013. That
has some compatibility issues and makes account merging harder, but more
importantly means that now you can hold assets without consenting to
hold the assets, which is a policy we might or might not want to have.

I can also see combining the two proposals. For example, adopting
pending trustlines but also adding a REMOVE_BALANCE operation, or even
changing the semantics of setting the limit to 0 so that it works even
on frozen assets.

David

[David Mazieres]

'Jeremy Rubin' via Stellar Developers <stell...@googlegroups.com>
writes:

> Limiting the pending trust lines is a fundamentally broken approach for
> channels.
>
> Should be unlimited.

It would be good to have a concrete example of this, as I don't think
your assertion is correct. In particular, channels should never need to
make use of pending trust lines. What functionality would require
channels to make use of pending trustlines?

We can of course make the number unlimited, but at the cost of burning
some lumens and leaving some crud in the ledger when you merge accounts.

David

[Christian Rudder]

Thanks for the context, David. I don't think users should need to consent to hold an asset, so that's I guess the core of why I don't like this proposal. I noted this in the doc. I don't think users expect this behavior or think about it that way. In fact I know they don't, because that's not how non-Stellar money transfers work. I would strongly prefer we do our best to mimic non-Stellar use patterns and match non-Stellar expectations.

I know part of this group disagrees with me. On the other hand, as seen from many of the comments in earlier versions of this thread, and, as I've heard from many people who build on Stellar who aren't here, entrepreneurs and builders tend to agree with me. 

--
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 post to this group, send email to stell...@googlegroups.com.
Visit this group at https://groups.google.com/group/stellar-dev.

To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/87imwkj6cb.fsf%40ta.scs.stanford.edu.

[Jeremy Rubin]

Christian I don't think anyone is debating the UX. 

The issue is that stellar core can't support payments as such, without substantial modifications -- the extent to which make it a non starter. 

Given that CAP-13 is technically infeasible, you should evaluate David's proposal.

Separately, you should evaluate CAP-13 Implementatability with Jon. 

[Christian Rudder]

My understanding was that the UX is under debate. "In the protocol group, we discussed whether it was better to consent to holding an asset before a payment or after, and the group seemed to feel
that it was better to consent afterwards." I can't tell to what extent this idea of consent (before or after) is driving the drawbacks in David's proposal. Or to put it another way: what is the best we can do that treats the received asset exactly like any other asset B holds.

I'm not advocating for CAP13 if it doesn't work, and like I said David's proposal is far better than what we have now. But you're basically asking me to design an alternative, when that should be the devs on this list's job. If the above is the best we can do to match the reqs, then what can I say.

[Jeremy Rubin]

The consent issue is more, imo, about whether it's a tolerable UX rather than the best.

Note that under this proposal you don't need to consent to hold it, you need to consent to having it show up in your account. This is the necessary part. The coins are in fact, yours, when the embryo is created. It's just weather or not they are inmediately spendable on your account. 

Consent in fact, isn't even about consent. It's about being in control of the state of your account to prevent DoS type issues. Consent can be given automatically without user interaction by the wallet software. 

I'm also reticent to support the language around 'things being the job of devs'. Keep in mind that Stellar is in part a volunteer driven community and people in this thread are participating at their own discretion for their own interest. It also is a Dev list, so it's not unreasonable for the expectation to be that by participating here you're signing up to discuss as a developer, which means that you should be prepared to propose alternatives or work with someone (I proposed Jon) to better understand the issues with CAP-13.

[David Mazieres]

Christian Rudder <crudderp...@gmail.com> writes:

> My understanding was that the UX is under debate. "In the protocol group,
> we discussed whether it was better to consent to holding an asset before a
> payment or after, and the group seemed to feel
> that it was better to consent afterwards." I can't tell to what extent this
> idea of consent (before or after) is driving the drawbacks in David's
> proposal. Or to put it another way: what is the best we can do that treats
> the received asset exactly like any other asset B holds.

Let's separate the debate into three questions:

1. Can you implement the UX that you want on top of the pending
trustline interface?

2. What are the security considerations of a UX? A UX that mimics
traditional payment systems can still present vulnerabilities
because traditional payment systems aren't perfect and because
there are challenges unique to the blockchain setting.

3. What are are the requirements to get this into stellar-core?

I believe the answer to #1 is almost. There is no reason that a wallet
can't show both pending and regular trustlines side by side, and just
transparently accept a trustline the first time you try to use its
balance. The main issue here is the limit of 20 pending trustlines,
which is not fundamental, though it's there for a reason.

As for #2, the biggest issue is that Stellar is trivially vulnerable to
bogus assets. So the fact that non-blockchain users are used to having
payments just show up in their accounts is all the more reason to add an
additional verification step through which wallets can ensure their
users understand that this is a new, possibly bogus asset. That doesn't
prevent wallets from having a "never show me this message again"
checkbox or whitelisting well-known assets. But there's a good chance
that by default, wallets should warn users that arbitrary assets might
not be worth what they purport to be worth, as well as providing account
views that separate "real" balances from the spam.

As for #3, here are the things that I think are probably prerequisites
for getting into stellar-core:

* The new mechanism must not be able to make ACCOUNT_MERGE operations
unexpectedly fail.

* The new mechanism must not allow the creation of transactions that
touch the database arbitrarily many times (e.g., delete 1,000,000
trustlines simultaneously).

* Any change should not increase the difficulties associated with
increasing baseReserve (e.g., allow an attacker to disable accounts
whose owners deposited enough XLM for the new baseReserve).

* Since question #2 is obviously debatable, any changes to
stellar-core should be compatible with our most conservative idea of
what constitutes a secure UX. That doesn't mean all wallets need to
support the secure UX, but wallets need to be able to do so without
further changes to stellar-core.

* While less of a strict requirement, backwards compatibility with
things like trustlines would certainly help get the change in sooner
rather than later.

So if I were to sketch out the design point that meets the above
criteria and that I think most satisfies what you want, it would be
sponsored trustlines with the following tweaks:

A. Accounts can have an unlimited number of pending trustlines.

B. If an account is merged, the pending trustlines remain as permanent
crud in the ledger and their XLM gets burned (or maybe the asset
issuer can eventually garbage collect the trustline to claim the XLM
reserve).

C. Pending trustlines can receive ordinary payments and path payments
as well as special SponsorTrustLineOp payments.

The arguments for the original version of sponsored trustlines over this
tweaked one are first that A requires B (to avoid touching the database
an arbitrary number of times during ACCOUNT_MERGE) and B is kind of
ugly.

More importantly, C means that you can send a normal payment and have
the assets get burned, because the trustline was only pending. I might
look at my account and say "oh, I have only 0.00000001 of this asset,
let me just abandon it and delete the trustline or merge my account,"
but then my transaction doing so crosses with a very large payment whose
assets then get burned. SponsorTrustLineOp can get burned, but you know
that when you specifically select that operation instead of a payment.

So personally I'm opposed but probably persuadable on A+B, particularly
if Jeremy can convince me that channels need pending trustlines (though
since each stage of a channel is signed by all parties, I don't
understand why channels wouldn't always use normal trustlines). I'm a
lot more opposed to C, which seems like a footgun, but if C turns out to
be the majority opinion, then I'll just be overruled.

David

[Christian Rudder]

David, thanks for breaking it down like this.

For your answer to #1, my question in return is: if wallets, etc. will just obfuscate the pending/actual distinction, what is the point of implementing the second type of trustline it in the first place? Is it because of a technical necessity or because of a desire to keep the assets separate in some way? 

For #2, I completely understand the situation with bogus assets, but as I've laid out in detail before it's not something the protocol should design for. Most of the solutions you lay out: whitelisting, etc. are available on the client side regardless of the pending/actual distinction. A "secure ux" isn't the right way to think about this--you'll never prevent people from lying to each other or from being ignorant, and things you're suggesting--like the additional verification step because xyz might be bogus--would immediately sink whatever service puts them there. I guess that's what I'm trying to figure out here: is the sponsored trustline mechanism the way it is because you're trying to design for this "secure ux"? Or is it the way it is because something simpler isn't possible at the technical level?

[David Mazieres]

Christian Rudder <crudderp...@gmail.com> writes:

> David, thanks for breaking it down like this.
>
> For your answer to #1, my question in return is: if wallets, etc. will
> just obfuscate the pending/actual distinction, what is the point of
> implementing the second type of trustline it in the first place? Is it
> because of a technical necessity or because of a desire to keep the
> assets separate in some way?

Some will and some won't, and some uses of the stellar network won't
look like wallets at all. I guess I tried to lay out the requirements
in my previous email, but maybe it wasn't clear, so let me break it down
in more detail:

* If anyone can create a normal trustline, then anyone can prevent an
account from being merged. That leads to super ugly things like
CAP-0013's ALLOW_ADD_BALLANCE flag and effectively makes it
impossible to merge an account using a preauthorized transaction.

* As an alternative, you could just throw away or merge trustlines with
a merge account, but throwing away breaks backwards compatibility in
a potentially dangerous way, and merging requires a potentially
unbounded number of database accesses for a single transaction.

* If anyone can create a normal trustline and there is a pending
increase in the baseReserve, even if you correctly top up your
account to meet the new reserve requirement in advance, you can be
DoSed by an attacker who adds new trustlines right before the
increase.

* If anyone can create a trustline for an account, then the limit is no
longer meaningful, so this is breaking backwards compatibility by
removing functionality that has already been deployed in
stellar-core. Maybe no one needs the limit, but any change that
breaks compatibility is going to have to be rolled out more slowly.

> For #2, I completely understand the situation with bogus assets, but as
> I've laid out in detail before it's not something the protocol should
> design for. Most of the solutions you lay out: whitelisting, etc. are
> available on the client side regardless of the pending/actual distinction.
> A "secure ux" isn't the right way to think about this--you'll never prevent
> people from lying to each other or from being ignorant, and things you're
> suggesting--like the additional verification step because xyz might be
> bogus--would immediately sink whatever service puts them there.

There's a great amount of empirical evidence that the abstractions on
which people base software have an outsized impact on the security of
the resulting systems. Just compare the number of buffer overruns in C
vs. Java. This is even more true of layers providing communications and
interoperability. Just compare the catastrophic state of password
authentication on the web vs. widespread use of public-key
authentication in SSH, or the susceptibility of email to spear-phishing
attacks compared to keybase.

It would be flagrant negligence not to consider the UX security of a
PAYMENT SYSTEM (no less) in designing the underlying protocol. There
are so many issues here. What if you use different mobile and desktop
wallets? Different wallets need to coordinate non-spam assets in a
consistent way. Or what if I want to send you a large payment without
risk of burning the tokens? I need to coordinate this in a way that
provides proof of who messed up if the tokens are lost.

We can debate what security issues any particular wallet should address,
but when it comes to the underlying blockchain, we have to consider all
security issues any wallet would need to address.

> I guess that's what I'm trying to figure out here: is the sponsored
> trustline mechanism the way it is because you're trying to design for
> this "secure ux"? Or is it the way it is because something simpler
> isn't possible at the technical level?

I laid out 5 requirements. One of them is to facilitate the most
conservatively secure UX. Again, no one is forcing you to implement a
secure UX, it just has to be possible. The other 4 requirements are:
reliable account merge, bounded computational cost of transactions,
robustness to increases in baseReserve, and backwards compatibility.

David

[Mister Ticot]

This is

what I feared @dmazieres: the name you used obfuscated the purpose of this thing. I really think it must be renamed prior to pushing it to the ecosystem. I suppose "pending trustline" is what fits better so far.

However, the drawback with it is we could imagine the user is supposed to accept it, which is not the case. This confusion may have bad consequences about understanding the purpose of this thing. The name must convey that user consent is actually asked for. Maybe "trust proposal", "trust invitation", or something like this.

For anybody confused let me explain what we're talking about:

This is *not* a new kind of trustline. This is *not* a new kind of payment. This is a pending deposit for an asset you don't trust yet. If you don't know that, you will struggle to understand its rationale or how it will integrate into UX. So I repeat: This is not a new kind of trustline. This is a *pending deposit*.

Now it is _implemented_ as kind of trustline, because it is technically convenient. However the trustline is not opened yet, and *maybe it never will*. Hence:

- The deposit is pending because user did not consent to receive the related asset yet. She is not forced to. In consequence, pending deposit must not be considered as part of user holdings.

- Payments must not feed pending trustlines because else a payment system would assume the payment had been received, which is not the case.

- In UX, pending trustlines *must not* appear as being part of user balance: they are not. They must appear as pending deposits or trust invitation.

If you wonder why this thing even exists:

* Anchors, airdrops & co wanted to send assets to users without having to wait for trustline to be open by them.

* It is not possible to open trustline on someone account without her consent both for ethical & legal reasons (e.g. peoples are right now in court in states for holding some canabis related coins).

* Hence it requires pending deposits.

It was the only solution that could comply with the list of constraints related to this challenge.

A few things worth noting:

- You can't create a pending trustline for an asset an user already trust (this property is better conveyed by naming it "pending trustline" rather than "pending deposit").

- Spam is not an issue due to the base reserve fee.

- This is not intended to be used massively or as an alternative to payment/changeTrust operations. This is intended to cover the very specific use case.

I think the way David did formalize this is good. A point I could not decide on back then was what to do with the pending assets in case of refusal. And indeed destroying them ends up to be least bad option.

P.S.: This is a *pending deposit* that the user can freely accept, decline, or ignore.

De : David Mazieres

Envoyé : dimanche 17 mars à 8:16 AM

Objet : Re: [stellar-dev] Re: Sponsored trustlines (a.k.a. embryonic trustlines)

À : Christian Rudder

Cc : Jeremy Rubin, Ishai Strauss, Stellar Developers

Christian Rudder writes: > David, thanks for breaking it down like this. > > For your answer to #1, my question in return is: if wallets, etc. will > just obfuscate the pending/actual distinction, what is the point of > implementing the second type of trustline it in the first place? Is it > because of a technical necessity or because of a desire to keep the > assets separate in some way? Some will and some won't, and some uses of the stellar network won't look like wallets at all. I guess I tried to lay out the requirements in my previous email, but maybe it wasn't clear, so let me break it down in more detail: * If anyone can create a normal trustline, then anyone can prevent an account from being merged. That leads to super ugly things like CAP-0013's ALLOW_ADD_BALLANCE flag and effectively makes it impossible to merge an account using a preauthorized transaction. * As an alternative, you could just throw away or merge trustlines with a merge account, but throwing away breaks backwards compatibility in a potentially dangerous way, and merging requires a potentially unbounded number of database accesses for a single transaction. * If anyone can create a normal trustline and there is a pending increase in the baseReserve, even if you correctly top up your account to meet the new reserve requirement in advance, you can be DoSed by an attacker who adds new trustlines right before the increase. * If anyone can create a trustline for an account, then the limit is no longer meaningful, so this is breaking backwards compatibility by removing functionality that has already been deployed in stellar-core. Maybe no one needs the limit, but any change that breaks compatibility is going to have to be rolled out more slowly. > For #2, I completely understand the situation with bogus assets, but as > I've laid out in detail before it's not something the protocol should > design for. Most of the solutions you lay out: whitelisting, etc. are > available on the client side regardless of the pending/actual distinction. > A "secure ux" isn't the right way to think about this--you'll never prevent > people from lying to each other or from being ignorant, and things you're > suggesting--like the additional verification step because xyz might be > bogus--would immediately sink whatever service puts them there. There's a great amount of empirical evidence that the abstractions on which people base software have an outsized impact on the security of the resulting systems. Just compare the number of buffer overruns in C vs. Java. This is even more true of layers providing communications and interoperability. Just compare the catastrophic state of password authentication on the web vs. widespread use of public-key authentication in SSH, or the susceptibility of email to spear-phishing attacks compared to keybase. It would be flagrant negligence not to consider the UX security of a PAYMENT SYSTEM (no less) in designing the underlying protocol. There are so many issues here. What if you use different mobile and desktop wallets? Different wallets need to coordinate non-spam assets in a consistent way. Or what if I want to send you a large payment without risk of burning the tokens? I need to coordinate this in a way that provides proof of who messed up if the tokens are lost. We can debate what security issues any particular wallet should address, but when it comes to the underlying blockchain, we have to consider all security issues any wallet would need to address. > I guess that's what I'm trying to figure out here: is the sponsored > trustline mechanism the way it is because you're trying to design for > this "secure ux"? Or is it the way it is because something simpler > isn't possible at the technical level? I laid out 5 requirements. One of them is to facilitate the most conservatively secure UX. Again, no one is forcing you to implement a secure UX, it just has to be possible. The other 4 requirements are: reliable account merge, bounded computational cost of transactions, robustness to increases in baseReserve, and backwards compatibility. David -- 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 post to this group, send email to stell...@googlegroups.com. Visit this group at https://groups.google.com/group/stellar-dev. To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/875zsis3lh.fsf%40ta.scs.stanford.edu. For more options, visit https://groups.google.com/d/optout.

[Christian Rudder]

David, the security/design issues you cite here are of a totally different nature than what we're debating here. The conflation of "trustlines" with "security" is wrong--that's a point I've made over and over again. We're retreading the same arguments. Clearly, the circle of devs who are going to make this decision and who, to my knowledge, have no meaningful experience with popular user-facing systems and who haven't even had to build something usable on Stellar (!!!) have their own way of thinking about these issues. 

So just do what you want, and let's see what happens. I'd rather do that than endless repeat the same arguments.

C 

[Orbit Lens]

Yesterday I checked David's proposal again, and it appears to me that it already contains a lot of protocol changes: 

• New operation introduced.
• The number of pending trustlines is limited.
• ACCOUNT_MERGE operation behavior changed.
• CHANGE_TRUST operation behavior changed.

Christian has a point here. We are changing a lot of stuff, but the UX isn't ideal (yes, better, but still not ideal). So can we update it a bit more to make everything working smoothly? I have a few suggestions that will improve the UX part of David's proposal.

1. Introduce the global max_trustlines_per_account limit. 

Security considerations regarding the trustlines number limiting are perfectly sane. But what about trustlines created by the account itself? 

I can add 50,000 trustlines to my account, and it will produce a bunch of problems: Horizon will choke on that account, wallets will run out of memory trying to load trustlines. Therefore, let's introduce max_trustlines_per_account constant and set it to, say, 200 (the limit is a subject to additional considerations). This number will include both regular and pending trustlines. It may be increased in the future to match the particular needs. 

Optionally, we can track pending trustlines separately as specified in David's proposal, so for example, an account should have no more than 200 trustlines and max 50 pending trustlines.

2. Extend ACCOUNT_MERGE operation with removeTrusltines flag.

If the flag is set, ACCOUNT_MERGE will automatically send all custom assets to the issuers and remove trustlines. As we have `max_trustlines_per_account` limit, we can expect that ACCOUNT_MERGE will always have a predictable performance cost, and can't be adopted for DoS attacks. Such behavior allows safe usage in smart contracts and improves the UX. 

3. Use informational pending flag on the sponsored trustline instead of new trustline type.

To make the UX smoother, all trustlines created by SPONSOR_TRUSTLINE operation should become usable immediately upon creation without the need for explicit confirmation from the user. We can achieve this by introducing new PENDING trustline flag. The wallet can mark sponsored trustlines as "pending deposit", or simply hide them by default (we need to define this on SEP level), but a user should be able to transfer/sell tokens immedaitelly. 

Therefore, PAYMENT, PATH_PAYMENT, MANAGE_OFFER, CREATE_PASSIVE_OFFER, and CHANGE_TRUST operations should implicitly remove the `pending` flag from trustline. Additionally, CHANGE_TRUST can be used to explicitly "accept" the trustline. From the legal perspective, a user automatically accepts the trustline once she wants to transfer/sell the tokens. Using the real-world analogy, a person can't be put to jail only because someone transferred dirty money to his/her bank account, but the fact of spending/withdrawal is a completely different thing. So any operation with pending trustline (or deposit, if you like) can be viewed as implicit consent.

As a bonus, all existing wallets/apps/exchanges will automatically support pending trustlines without any modifications. 

4. (Optionally) Add TRUSTLINE_ACCEPTED effect

This new effect will allow tracking status changes for pending trustlines.

[David Mazieres]

Christian Rudder <crudderp...@gmail.com> writes:

> David, the security/design issues you cite here are of a totally different
> nature than what we're debating here. The conflation of "trustlines" with
> "security" is wrong--that's a point I've made over and over again. We're
> retreading the same arguments. Clearly, the circle of devs who are going to
> make this decision and who, to my knowledge, have no meaningful experience
> with popular user-facing systems and who haven't even had to build
> something usable on Stellar (!!!) have their own way of thinking about
> these issues.

Are you asserting that the design of trustlines doesn't affect security?
Or do you have some hypothetical design in mind that doesn't impact
security? Part of the problem is that you have me arguing with
myself--I'm trying to anticipate the design you want and nothing I think
you want works, but you aren't really countering with specifics. Or
maybe you aren't even talking about my proposal since you talk about
developers who have never built something usable on Stellar? Or maybe
you consider that usability of CLI tools doesn't matter, when in fact
their usability significantly impacts security?

> So just do what you want, and let's see what happens. I'd rather do that
> than endless repeat the same arguments.

To be clear, I don't want anything--I'm just trying to facilitate a
feature that other people, including you, have been asking for. If you
don't like pending trustlines, and you don't propose an alternative, and
you don't like or even really engage with the specifics of the tweaks
(A, B, C) I suggested a few messages ago to try to meet your concerns,
then we probably shouldn't implement my proposal.

David

[Mister Ticot]

@orbit

Specifically about why pending trustline, there is 2 reasons pending deposits must not considered as part of users holdings:

* Legal issue

* Ethical issue

Last time we talked about legal issues we agreed that we would need advice from an actual layer. Not sure if anything happened on that side?

Anyway, we must not to make lazy shortcuts just to go ahead with a design we would find more convenient. This is easy but consequences may be really bad.

For example: if you receive dirty money on your account & some power is investing about it, you WILL definitely have troubles. Even if you are innocent, you clearly may get suspected & may have to prove it landed here without your consent — and remember some countries can put a suspect in jail for weeks if not months before even auditioning him.

- BUT -

We are not talking about dirty money here. We are talking about tokens that may represent an illegal product were you live, or a share into an illegal industry. This is totally worse.

To take an appropriate analogy, imagine you live in a country where canabis is illegal and you receive some by mail. Now I don't now about US but in France you may definitely get problems for that because cops would never trust it was an error. Now imagine if they find it into your personal safe (stellar account is more similar to a safe than a mail box)...

And I'm not even talking about countries were you can be put to jail or death for that.

See?

You guys must acknowledge that assets on Stellar are not always money. It can represent a physical object, a share in a company, debt, a contract,... hence it may have a legal or a moral weight.

That was also part of the ethical issue that it would be an unpleasant experience to be imposed an asset in your portfolio that goes against your moral (i.e.: porn/drug related coins, share in criminal industries, or whatever can hurt some people ethic/moral...)

The other part is that opening new trustline in someone else account is obviously abusive. Once again this CAN'T be compared with sending money to someone: as far as I now when you receive money on your account it's in the account currency, it's not in an arbitrary currency, in stock, in bonds, in shitcoin or whatever we could imagine.

So yeah... If you guys want to use analogies to make your points please make an effort and use one that makes really fit. 0:-)

Anyway yes, this design is tricky. Yes, it is like this for a reason. Yes, it was hard to find something which comply with each constraints. So obviously yes, you can make it easier by skipping some of those constraints but then it doesn't fit the task anymore. 

De : Orbit Lens

Envoyé : lundi 18 mars à 10:09 PM

Objet : Re: [stellar-dev] Re: Sponsored trustlines (a.k.a. embryonic trustlines)

À : Stellar Developers

Yesterday I checked David's proposal again, and it appears to me that it already contains a lot of protocol changes: 

New operation introduced.The number of pending trustlines is limited.ACCOUNT_MERGE operation behavior changed.CHANGE_TRUST operation behavior changed.

Christian has a point here. We are changing a lot of stuff, but the UX isn't ideal (yes, better, but still not ideal). So can we update it a bit more to make everything working smoothly? I have a few suggestions that will improve the UX part of David's proposal.

1. Introduce the global max_trustlines_per_account limit. 

Security considerations regarding the trustlines number limiting are perfectly sane. But what about trustlines created by the account itself? 

I can add 50,000 trustlines to my account, and it will produce a bunch of problems: Horizon will choke on that account, wallets will run out of memory trying to load trustlines. Therefore, let's introduce max_trustlines_per_account constant and set it to, say, 200 (the limit is a subject to additional considerations). This number will include both regular and pending trustlines. It may be increased in the future to match the particular needs. 

Optionally, we can track pending trustlines separately as specified in David's proposal, so for example, an account should have no more than 200 trustlines and max 50 pending trustlines.

2. Extend ACCOUNT_MERGE operation with removeTrusltines flag.

If the flag is set, ACCOUNT_MERGE will automatically send all custom assets to the issuers and remove trustlines. As we have `max_trustlines_per_account` limit, we can expect that ACCOUNT_MERGE will always have a predictable performance cost, and can't be adopted for DoS attacks. Such behavior allows safe usage in smart contracts and improves the UX. 

3. Use informational pending flag on the sponsored trustline instead of new trustline type.

To make the UX smoother, all trustlines created by SPONSOR_TRUSTLINE operation should become usable immediately upon creation without the need for explicit confirmation from the user. We can achieve this by introducing new PENDING trustline flag. The wallet can mark sponsored trustlines as "pending deposit", or simply hide them by default (we need to define this on SEP level), but a user should be able to transfer/sell tokens immedaitelly. 

Therefore, PAYMENT, PATH_PAYMENT, MANAGE_OFFER, CREATE_PASSIVE_OFFER, and CHANGE_TRUST operations should implicitly remove the `pending` flag from trustline. Additionally, CHANGE_TRUST can be used to explicitly "accept" the trustline. From the legal perspective, a user automatically accepts the trustline once she wants to transfer/sell the tokens. Using the real-world analogy, a person can't be put to jail only because someone transferred dirty money to his/her bank account, but the fact of spending/withdrawal is a completely different thing. So any operation with pending trustline (or deposit, if you like) can be viewed as implicit consent.

As a bonus, all existing wallets/apps/exchanges will automatically support pending trustlines without any modifications. 

4. (Optionally) Add TRUSTLINE_ACCEPTED effect

This new effect will allow tracking status changes for pending trustlines.

On Monday, March 18, 2019 at 2:03:22 PM UTC+2, Christian Rudder wrote:

David, the security/design issues you cite here are of a totally different nature than what we're debating here. The conflation of "trustlines" with "security" is wrong--that's a point I've made over and over again. We're retreading the same arguments. Clearly, the circle of devs who are going to make this decision and who, to my knowledge, have no meaningful experience with popular user-facing systems and who haven't even had to build something usable on Stellar (!!!) have their own way of thinking about these issues. 

So just do what you want, and let's see what happens. I'd rather do that than endless repeat the same arguments.

C 

On Sat, Mar 16, 2019 at 9:15 PM David Mazieres <dm-list-s...@scs.stanford.edu> wrote:

--

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 post to this group, send email to stell...@googlegroups.com.

Visit this group at https://groups.google.com/group/stellar-dev.

To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/3f741bac-07d1-4f12-a5ab-83da95342b5e%40googlegroups.com.

[Ishai Strauss]

1) Is this related to the subject of this thread (i.e. allowing the creation of trustlines by outside entities)? If so, I am not following the connection.

2) The whole concept of limiting the usability of a system to avoid spam/DoS is I think a bad approach. The fee system should be taking care of this. In other words, if certain operations can be abused, then maybe we need to borrow from ETH and charge variable fees depending on the complexity of the operation (i.e. allow merging an account with existing trustlines but charge a minimum fee per trustline).

3) I had assumed that this is what the original proposal was proposing (i.e. just a new column on the existing trustlines table). If not, I definitely think that this is the right approach (rather than some new table...)

4) +1

[David Mazieres]

'Ishai Strauss' via Stellar Developers <stell...@googlegroups.com>
writes:

> 1) Is this related to the subject of this thread (i.e. allowing the
> creation of trustlines by outside entities)? If so, I am not following the
> connection.

I think so, but it would probably be good to focus on the specifics of
proposals, like how we want to change XDRs, because otherwise it can get
not productive.

> 2) The whole concept of limiting the usability of a system to avoid
> spam/DoS is I think a bad approach. The fee system should be taking care of
> this. In other words, if certain operations can be abused, then maybe we
> need to borrow from ETH and charge variable fees depending on the
> complexity of the operation (i.e. allow merging an account with existing
> trustlines but charge a minimum fee per trustline).

Well, fees can take care of system-wide DoS, but it's also not good to
allow someone to disable a particular account. In fact, with things
like pre-authorized and pre-signed transactions, the ability to DoS a
particular account can actually lead to large financial loss.

> 3) I had assumed that this is what the original proposal was proposing
> (i.e. just a new column on the existing trustlines table). If not, I
> definitely think that this is the right approach (rather than some new
> table...)

Basically, yes. I was adding a column to trustlines, and using the
existing union discriminant as a kind of flag to separate pending from
regular trustlines.

David

[Michael Feldman]

David,

Another tweak consideration on Jeremy’s point of account state control:
Can accounts set the native reserve amount required for others to create a sponsored trustline?

There will likely be targeted spam cases, so giving account holders the option to pad the native amount sponsored trustline creators must allocate could be helpful (default would be the base reserve).

[Antoine Bodin]

It's what I feared @dmazieres: the name you used obfuscated the purpose of this thing. I really think it must be renamed prior to pushing it to the ecosystem.

For anybody confused let me explain what we're talking about:

This is *not* a new kind of trustline. This is *not* a new kind of payment. This is a *pending deposit*. If you don't know that, you will struggle to understand its rationale or how it will integrate into UX. So I repeat: This is not a new kind of trustline. This is a *pending deposit*.

Now it is _implemented_ as kind of trustline, because it is technically convenient. However the trustline is not opened yet, and *maybe it never will*. Hence:

- payments can't feed pending deposits, because else a payment system would assume the payment is validated, which is not the case.

- in UX, pending deposits *must not* appear as being part of user balance: they are not. They must appear as pending deposit.

- It is not about a new kind of payment that would need to be accepted by the user, it is about a accepting or refusing a new trustline.

This is why you can't create a pending deposit for an asset that an user already trust.

If you wonder why this thing even exists:

* Anchor, airdrop & co wanted to send assets to users without having to wait for trustline to be open by them.

* It is not possible to open trustline on someone account without her consent both for ethical & legal reasons (e.g. people are right now in court in states for holding some canabis related coins)

* Hence it requires pending deposits.

It was the only solution that could comply with the list of constraints related to this challenge.

I think the way David did formalize this is good. A point I could not decide on back then was what to do with the pending assets in case of refusal. And indeed destroying them ends up to be least bad option.

P.S.: This is not another kind of trustline, this is a *pending deposit* that the user can accept, refuse, or ignore.

First, for everyone on the list, I should have provided some context.
I'm not saying my proposal is better or worse than other proposals.  The
point was just to see what a minimal change looks like that uses the
embryonic or "pending" (Mr. Ticot's term, probably preferable to mine)
account concept to facilitate sending issued assets to someone for the
first time.  The protocol working group wants to taxonomize the solution
space to be able to discuss trade-offs more comprehensively and make
progress on this issue.


> David, I'd like to know what the sponsored trustline workaround adds vis a
> vis Dan's more straightforward suggestion from before.

Do you mean SEP-0013?  I think the working group considers SEP-0013 to
be a bit complicated.  It's also a much bigger change, in that it gets
rid of features like a trustline balance.

> I 100% think it's a major upgrade to where we are, so if it's this or
> nothing, I much prefer your solution to the current stasis.

It's just another point in the design space, which in its favor has
backwards compatibility.  I would like to see us make progress with any
one of these proposals, and sometimes the best way to do that is to
throw more proposals up.  For instance, when I proposed cosigned assets,
this inspired Jon to propose his even simpler sandwich solution, and now
at long last we have a solution to that problem on the horizon.

> But, still, this kind of account/sending behavior will seems strange to
> devs coming to Stellar. It adds an additional layer of complexity--now
> there are two kinds of trustlines where even one kind of trustline is
> unusual. Furthermore the two kinds of trustlines act quite differently from
> one another.

It doesn't need to be this way.  The idea was that if you are sending
assets to an account, you might want to know whether or not the owner of
the account has consented to hold those assets.  Nothing breaks
technically in my proposal if you let payments and path payments just
work to sponsored trustlines, it's just a question of which behavior we
want.  A sponsored trustline souldn't prevent someone from merging an
account, so do we want to risk that a payment succeeds to an account
that is subsequently merged, destroying the assets sent by that payment?

> And, for end-users, it still requires wallets/exchanges to
> either obfuscate this sponsored trustline distinction (in which case what's
> the point of having it) or, if they surface the sponsored trustlines to
> users, to build in more UI baggage. There's already A LOT of that with
> Stellar, and I don't think adding in more is a good idea.
>
> So these are the costs of your proposal--can you explain to me the upside?

The proposal would work either way.  The two questions are: should you
need to consent to holding an asset (I think the group felt yes), and
then should a normal payment work to someone who hasn't consented to
hold the assset (up for debate).

David

-- 
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 post to this group, send email to stell...@googlegroups.com.
Visit this group at https://groups.google.com/group/stellar-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/87tvg4jbax.fsf%40ta.scs.stanford.edu.
For more options, visit https://groups.google.com/d/optout.

[Jeremy Rubin]

The more broad issue is that from a legal liability perspective, a pending deposit is still your property, much like a piece of mail in your mailbox is yours even if you don't open it yet. When a deposit is made, you own it, only you can spend it. You also have liability for it. Now, if the issue is that someone is going to try to put you in jail for holding a potcoin, I don't think we'll be able to ever fully protect a user from that kind of thing. Simply speaking, I can make an account with all sorts of legal coins and then change the keys to your account's keys.

[Mister Ticot]

@Jeremy

What I'm trying to explain since the beginning is that, precisely, pending deposits has been designed not to be your property. This is why it is not part of your balance, can't be fed by payments, and can't be made use of.

It is not yours until you trust the asset. And it gets destroyed if you refuse that asset. Else, it would not be different from a trustline...

So I think your analogy doesn't fit. And this is the very reason I said you need to take care to do the right analogy, if you need to do one.

So for a proper real world analogy this is more like your being proposed a contract to receive asset X but didn't signed it yet.

One issue we're having here is that the debate is going on but the proposal itself has not been understood yet XD.

De : 'Jeremy Rubin' via Stellar Developers

Envoyé : mardi 19 mars à 12:28 AM

Objet : Re: [stellar-dev] Sponsored trustlines (a.k.a. embryonic trustlines)

À : Antoine Bodin

Cc : stell...@googlegroups.com

The more broad issue is that from a legal liability perspective, a pending deposit is still your property, much like a piece of mail in your mailbox is yours even if you don't open it yet. When a deposit is made, you own it, only you can spend it. You also have liability for it. Now, if the issue is that someone is going to try to put you in jail for holding a potcoin, I don't think we'll be able to ever fully protect a user from that kind of thing. Simply speaking, I can make an account with all sorts of legal coins and then change the keys to your account's keys.

--

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 post to this group, send email to stell...@googlegroups.com.

Visit this group at https://groups.google.com/group/stellar-dev.

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

[David Mazieres]

Orbit Lens <orbit...@gmail.com> writes:

> *1. Introduce the global max_trustlines_per_account limit. *

>
> Security considerations regarding the trustlines number limiting are
> perfectly sane. But what about trustlines created by the account itself?
> I can add 50,000 trustlines to my account, and it will produce a bunch of
> problems: Horizon will choke on that account, wallets will run out of
> memory trying to load trustlines. Therefore, let's introduce
> max_trustlines_per_account constant and set it to, say, 200 (the limit is a
> subject to additional considerations). This number will include both
> regular and pending trustlines. It may be increased in the future to match
> the particular needs.
>
> Optionally, we can track pending trustlines separately as specified in
> David's proposal, so for example, an account should have no more than 200
> trustlines and max 50 pending trustlines.

I don't have an inherent objection to adding a limit to the number of
trustlines, but I think a number like 200 is too big in terms of
amplification attacks. While we are charging the same fee for every
operation, I don't want to introduce operations that are 20 times more
expensive than others (particularly if there aren't fallback semantics
we can switch to in case of performance issues).

> *2. Extend ACCOUNT_MERGE operation with removeTrusltines flag.*

>
> If the flag is set, ACCOUNT_MERGE will automatically send all custom assets
> to the issuers and remove trustlines. As we have
> `max_trustlines_per_account` limit, we can expect that ACCOUNT_MERGE will
> always have a predictable performance cost, and can't be adopted for DoS
> attacks. Such behavior allows safe usage in smart contracts and improves
> the UX.

It's predictable but high. Also, I'm not sure it's that useful from an
end-user perspective. If anything, the more useful semantics would be
for the (non-pending) assets to be merged into the new account, not
destroyed. But that of course is its own set of problems. Maybe we
need a new TRUSTLINE_MERGE operation or something, though how this
interacts with the AUTHORIZED flag seems tricky.

> *3. Use informational pending flag on the sponsored trustline instead of
> new trustline type.*

That's effectively what I proposed, just using the union discriminant as
the flag, since its already there. Also, the sponsored trustline needs
an extra field to keep track of its balance. Otherwise, we've allowed
people to DoS accounts right before a baseReserve increase.

> To make the UX smoother, all trustlines created by SPONSOR_TRUSTLINE
> operation should become usable immediately upon creation without the need
> for explicit confirmation from the user. We can achieve this by introducing
> new PENDING trustline flag. The wallet can mark sponsored trustlines as
> "pending deposit", or simply hide them by default (we need to define this
> on SEP level), but a user should be able to transfer/sell tokens
> immedaitelly.
>
> Therefore, PAYMENT, PATH_PAYMENT, MANAGE_OFFER, CREATE_PASSIVE_OFFER, and
> CHANGE_TRUST operations should implicitly remove the `pending` flag from
> trustline. Additionally, CHANGE_TRUST can be used to explicitly "accept"
> the trustline. From the legal perspective, a user automatically accepts the
> trustline once she wants to transfer/sell the tokens. Using the real-world
> analogy, a person can't be put to jail only because someone transferred
> dirty money to his/her bank account, but the fact of spending/withdrawal is
> a completely different thing. So any operation with pending trustline (or
> deposit, if you like) can be viewed as implicit consent.
>
> As a bonus, all existing wallets/apps/exchanges will automatically support
> pending trustlines without any modifications.

This part seems doable. What about incoming payments, though.

> *4. (Optionally) Add TRUSTLINE_ACCEPTED effect*

>
> This new effect will allow tracking status changes for pending trustlines.

Also seems reasonable.

David

[Antoine Bodin]

I agree the cost/benefit of pending trustlines is not so good. More generally, I wonder about implementing a new operation in order to solve a specific use case. All existing operations are more kind of simple generic building blocks.

Anyway I don't mind continuing this process if some peoples think it worth it, or at least want to judge after the fully detailed solution.

I would advice against any changes that weaken the purpose of this solution, though. Things like making the amount immediately available ruins the interest of the whole thing.

Having pending deposit living in sender accounts would obviously be more logical. I originally dismissed it because I felt it would be technically too complicated. Now, maybe I was wrong as we wouldn't have this problem with merging / locking account , base fee raise and so on.

De : David Mazieres

Envoyé : jeudi 21 mars à 10:42 PM

Objet : Re: [stellar-dev] Re: Sponsored trustlines (a.k.a. embryonic trustlines)

À : Orbit Lens, Stellar Developers

Orbit Lens writes: > *1. Introduce the global max_trustlines_per_account limit. * > > Security considerations regarding the trustlines number limiting are > perfectly sane. But what about trustlines created by the account itself? > I can add 50,000 trustlines to my account, and it will produce a bunch of > problems: Horizon will choke on that account, wallets will run out of > memory trying to load trustlines. Therefore, let's introduce > max_trustlines_per_account constant and set it to, say, 200 (the limit is a > subject to additional considerations). This number will include both > regular and pending trustlines. It may be increased in the future to match > the particular needs. > > Optionally, we can track pending trustlines separately as specified in > David's proposal, so for example, an account should have no more than 200 > trustlines and max 50 pending trustlines. I don't have an inherent objection to adding a limit to the number of trustlines, but I think a number like 200 is too big in terms of amplification attacks. While we are charging the same fee for every operation, I don't want to introduce operations that are 20 times more expensive than others (particularly if there aren't fallback semantics we can switch to in case of performance issues). > *2. Extend ACCOUNT_MERGE operation with removeTrusltines flag.* > > If the flag is set, ACCOUNT_MERGE will automatically send all custom assets > to the issuers and remove trustlines. As we have > `max_trustlines_per_account` limit, we can expect that ACCOUNT_MERGE will > always have a predictable performance cost, and can't be adopted for DoS > attacks. Such behavior allows safe usage in smart contracts and improves > the UX. It's predictable but high. Also, I'm not sure it's that useful from an end-user perspective. If anything, the more useful semantics would be for the (non-pending) assets to be merged into the new account, not destroyed. But that of course is its own set of problems. Maybe we need a new TRUSTLINE_MERGE operation or something, though how this interacts with the AUTHORIZED flag seems tricky. > *3. Use informational pending flag on the sponsored trustline instead of > new trustline type.* That's effectively what I proposed, just using the union discriminant as the flag, since its already there. Also, the sponsored trustline needs an extra field to keep track of its balance. Otherwise, we've allowed people to DoS accounts right before a baseReserve increase. > To make the UX smoother, all trustlines created by SPONSOR_TRUSTLINE > operation should become usable immediately upon creation without the need > for explicit confirmation from the user. We can achieve this by introducing > new PENDING trustline flag. The wallet can mark sponsored trustlines as > "pending deposit", or simply hide them by default (we need to define this > on SEP level), but a user should be able to transfer/sell tokens > immedaitelly. > > Therefore, PAYMENT, PATH_PAYMENT, MANAGE_OFFER, CREATE_PASSIVE_OFFER, and > CHANGE_TRUST operations should implicitly remove the `pending` flag from > trustline. Additionally, CHANGE_TRUST can be used to explicitly "accept" > the trustline. From the legal perspective, a user automatically accepts the > trustline once she wants to transfer/sell the tokens. Using the real-world > analogy, a person can't be put to jail only because someone transferred > dirty money to his/her bank account, but the fact of spending/withdrawal is > a completely different thing. So any operation with pending trustline (or > deposit, if you like) can be viewed as implicit consent. > > As a bonus, all existing wallets/apps/exchanges will automatically support > pending trustlines without any modifications. This part seems doable. What about incoming payments, though. > *4. (Optionally) Add TRUSTLINE_ACCEPTED effect* > > This new effect will allow tracking status changes for pending trustlines. Also seems reasonable. David -- 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 post to this group, send email to stell...@googlegroups.com. Visit this group at https://groups.google.com/group/stellar-dev. To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/87va0ctesw.fsf%40ta.scs.stanford.edu. For more options, visit https://groups.google.com/d/optout.

[Orbit Lens]

Thanks for the detailed answers, David. 

I think a number like 200 is too big in terms of amplification attacks.

Agree on that, but currently it's much easier to attack the network by crossing multiple offers. An attacker can create 1000 offers selling fractions of some worthless self-issued asset, and then buy them all using a second account. As far as I understand, it will be much more expensive than closing 200 trustlines. If 200 looks too large, let's set it to 100. I don't think that users will be happy with smaller values. Currently we have about 50 accounts with more than 100 trustlines each.

*2. Extend ACCOUNT_MERGE operation with removeTrusltines flag.* 

 

It's predictable but high.  Also, I'm not sure it's that useful from an 

end-user perspective.  If anything, the more useful semantics would be 
for the (non-pending) assets to be merged into the new account, not 
destroyed. 

I don't think that regular users will often use this flag. This paragraph was added to deal with the situation when someone is spamming with pending trustlines. 

From the top of my head, I can't recollect that anybody was complaining about account_merge behavior. Looks like people are quite happy with current implementation. So, this modification will be widely used by mainly smart contracts creators. Also it's a simple solution and it doesn't require any additional research. With trustlines automatically created on destination account by merge op we have a bunch of potential problems.

> *3. Use informational pending flag on the sponsored trustline instead of 
> new trustline type.* 
That's effectively what I proposed, just using the union discriminant as 
the flag, since its already there.  Also, the sponsored trustline needs 
an extra field to keep track of its balance.  Otherwise, we've allowed 
people to DoS accounts right before a baseReserve increase. 

My main point here was to make the trustlines backwards compatible. If we use a flag, it should work flawlessly even without SDK and wallet code modifications. So we can ensure that old wallets will work with new trustlines just like it's a regular trustline. Eventually all supported clients will add the UX modification to differentiate pending trustlines from good old standard trustlines. If we can achieve this with union discriminant - I have no objections. 

Also, the sponsored trustline needs 
an extra field to keep track of its balance.

To my mind, field nativeAssetAmount is redundant. Anchors and most users will always set it to baseReserve (0.5XLM). 

So can we just always charge baseReserve amount from the sponsoring account to simplify the overall process and reduce the number of required fields? In this case, the pending flag will be the only difference between a pending and regular trustline, so all clients will automatically support pending trustlines from day one.

Otherwise, we've allowed people to DoS accounts right before a baseReserve increase. 

We had a discussion on KB about possible baseReserve increase about half a year ago, and I actually don't see a way to increase baseReserve, only decrease is possible. To my mind, it can be done only on private networks, because on public networks it's not possible to force all users to add additional XLM to their accounts to meet new min balance requirements. Of course, it can be done using some kind of hard-fork with automatic XLM airdrop to all accounts on protocol upgrade, but such situation seems unlikely to me.

What about incoming payments, though. 

I'd say that we should allow incoming payments. When a user resets the pending flag (payment/manage_offer/change_trust) she automatically confirms her consent on using this asset. Until then it actually doesn't matter whether someone can send a payment to this trustline or not. I don't see a strong need to modify default trustlines behavior in this case, so I vote for allowing the incoming payments on pending transaction. However, this is not critical to me.