-
Notifications
You must be signed in to change notification settings - Fork 307
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merging account with trustlines #324
Comments
For reference, #56 |
Agree that this is tricky. I believe the two mechanisms you propose still leave some corner cases. For example, the merge asset operation could exceed the trustline or could exceed 2^{63}, or authorization could be revoked by an asset issuer. I think you need two transactions to close a channel (in case one fails because a party does something weird like delete their account or trustline), and it's better just to change the signers on the escrow account to put it under one party's control than to try to merge that account. |
You mentioned a third alternative that would also work and is currently the only practical solution to that problem (it's also the only "workaround" we found). However, it has big legal implications if neither party is allowed to get complete control over the escrow account – they might require certain licenses first. Therefore it is very critical for legal reasons to extend the protocol in the sense of one of the first two alternatives I mentioned. |
There may be corner cases, but there is also the happy path, where it is indeed possible to do a "full" merge. Does it not make sense to accommodate this scenario? |
@TorstenStueber did you look at leveraging CAP-0023 that we're trying to finalize in the next couple months? It allows to decouple transfers from accounts and seems to have strong desirable properties for smart contracts in general (and we think for payment channels too). If it doesn't work in your particular scenario, we'd like to hear the blockers and potentially incorporate new changes into CAP-0023. |
@MonsieurNicolas I'm not sure CAP-0023 will solve our problem, but perhaps I'm missing something here. The issue is not the receiving account, the problem is guaranteeing that the escrow account is fully merged. Example:
We're looking for a robust way to fully merge an account without having to specify the exact balance of each trust line asset. It is not an option to let one one account take full control of the account at any point in time. |
@MonsieurNicolas I agree with what @erasmus said. CAP-0023 does not solve our problem. CAP-0023 would be helpful in a case where the target account that the escrow is to be merged into might not have the proper trust lines (yet). But this is not our problem: the target account of the merge operation does have the required trust lines. See @erasmus explanation for some more details. |
I was not saying that CAP0023 will make merging accounts easier, but that it should make writing payment channels easier. In the context of payment channels, as transactions can fail, you really don't want to have any of the pre-signed transactions fail (a "merge asset" operation can fail) as the failure modes get very tricky to handle as the number of participants or assets increases. CAP0023 allows to do just that (we think): as we decouple what the channel does with pre-signed transactions (creates pending transfers, this cannot fail), and what each recipient does ("claims" can fail but can be retried). |
I understand and that makes sense. But wouldn't that still require the kind of operations I am asking for in my initial post? So maybe CAP0023 would be an additional improvement but we still need some way to merge assets. Or am I missing something? |
yeah merging assets becomes interactive and doesn't need to be done from within the smart contract @TorstenStueber so the existing operations should be enough |
@TorstenStueber what is your current status on this issue? Do you think that there are still fundamental problems here? I have some ideas based on what has been discussed in this thread (although I would want to make sure that I understand the problem fully before proposing any solutions), but obviously if the problem has been resolved then there is nothing of value for me to add. |
In order to merge an account that has a trustline first the following operations need to be executed:
Certain smart contract schemes (such as payment channels) involve refund transactions for escrow accounts that are created and signed well before they are submitted on chain. If such a scheme deals with an assets different from the native asset, then these refund transactions need to contain the following operations (as stated above):
The refund transaction will fail if the payment operation does not contain the correct balance of the trusted asset at the time the transaction is submitted. Since the refund transaction is created and signed a long time before, this would allow an attacker to invalidate the transaction by sending a single stroop of the trusted asset to the escrow account before the refund transaction is submitted.
A workaround would be to always set the trust limit of the asset to the current balance on the account. However, this has some downsides – e.g., topping up a payment channel would not be possible.
We propose any of the following solutions:
The text was updated successfully, but these errors were encountered: