Release v1.5.4

[mischat]

This PR is used to put changes on top of v1.5.3 for the initial alpha release.

[mischat]

i guess @i-stam ... if you and @nostdm could look too and then we can tag 1.5.4 and get that deployed.

[i-stam]

I guess i want to use our transfer method, as that is protected by the dailySpend limit. I wouldn't want to by pass that in any shape or form.

this confuses me, I was expecting this one to be a function that can be used for updating to the new contracts. Thus, it should transfer all at once..Am i missing something?

[mischat]

@i-stam as discussed, we have to use our own transfer cause otherwise it will break our security model.

When upgrading it will go like follows :
1 - read security settings on old contract
2 - deploy new contract with same security settings
3 - set own so new and old have same owner
4 - add new contract to whitelist
5 - bulkTransfer X number of times depending on number of assets

Otherwise people can just use the method, which breaks our whole security protections around someone having their key compromised.

addresses dragan's issues

[i-stam]

@mischat I added tests to simulate an upgrade scenario and a full funds transfer

[nostdm]

LGTM 👍

Is the plan to deploy these changes now and then eventually transition users to the master version of the contracts? If I'm understanding this correctly we branched off from the older branch to keep the contract ABI the same as the currently deployed contracts without introducing breaking changes to the backend?

Would we support the contract migration flow in the app or is this just a convenience thing and users would have to do the migration on the blockchain directly? Because if this is to be supported by the app, it means that we would have to add the backend logic to be able to process multiple contract types at the same time with potentially different subset of features and different ABIs. i.e. user can see contract A then contract B which both have to be supported by our backend at the same time so that both contracts can be shown in the app.

[mischat]

LGTM 👍

Is the plan to deploy these changes now and then eventually transition users to the master version of the contracts? If I'm understanding this correctly we branched off from the older branch to keep the contract ABI the same as the currently deployed contracts without introducing breaking changes to the backend?

Would we support the contract migration flow in the app or is this just a convenience thing and users would have to do the migration on the blockchain directly? Because if this is to be supported by the app, it means that we would have to add the backend logic to be able to process multiple contract types at the same time with potentially different subset of features and different ABIs. i.e. user can see contract A then contract B which both have to be supported by our backend at the same time so that both contracts can be shown in the app.

@nostdm ^^ with respect to your questions. Yes, we would be giving people v1.5.4 and then what is in master will become v2.X.X ... When we are happy with version v2.X.X we will upgrade people through the app. Happy to talk you through the plans there when I see you next!

[mischat]

@i-stam as discussed, we have to use our own transfer cause otherwise it will break our security model.

When upgrading it will go like follows :
1 - read security settings on old contract
2 - deploy new contract with same security settings
3 - set own so new and old have same owner
4 - add new contract to whitelist
5 - bulkTransfer X number of times depending on number of assets

Otherwise people can just use the method, which breaks our whole security protections around someone having their key compromised.

@nostdm the plans are summarized at a high-level as follows ^^