Skip to content
This repository has been archived by the owner on Feb 8, 2020. It is now read-only.

Tips Wallet #35

Merged
merged 33 commits into from
Dec 10, 2017
Merged

Tips Wallet #35

merged 33 commits into from
Dec 10, 2017

Conversation

jksf
Copy link

@jksf jksf commented Nov 22, 2017

Closes #23
Replaces #29 with more concise and future-proof implementation.

Checklist:

  • initial setup of owners
  • cheap fallback payable function
  • emit event on deposit
  • arbitrary transaction execution
  • change owners (required approval of all existing owners)
  • reset owners (approval of one of the owners with possibility to cancel request in a configured time window)
  • write security tests
  • write nonce duplication tests
  • run tests in modularized way

Jakub Stefanski added 2 commits November 22, 2017 22:48
I smuggled also some typing and utils refactoring.
@jksf jksf requested a review from biern November 22, 2017 21:59
@jksf jksf mentioned this pull request Nov 22, 2017
9 tasks
@jksf
Copy link
Author

jksf commented Dec 7, 2017

That was a lot of work. Added 2210 and removed 401 lines of code (excluding JSON ABI files), 237 unit/integration tests, not counting 192 skipped tests due to base class tests duplication.
I hope the funds received on this wallet will be worth it ;-).

Commits are decently organized, however I suggest reviewing it in final form.

Copy link
Member

@biern biern left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Impressive work!

  • I couldn't find anything wrong with the contracts. I will take a look at them once again tomorrow to double check.
  • It looks like you have found a nice solution to tests with parametrized contexts. Also the tests are very comprehensive.
  • Naming of the classes / instances related to the commands was a bit confusing for me on the first read, I've suggested some improvements (hopefully), although the general concept is neat.
  • Most of the comments are just minor remarks related mostly to naming, I couldn't find anything wrong here.

}

/* solhint-disable no-empty-blocks */
function() public payable {}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it makes sense to have a Deposit event here?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good suggestion. I had it initially but removed it due to doubts about "Deposit" naming in context of TipsWallet. Nonetheless, it should exist in the MultiSig base contract if we want it to be practical and used in other contexts.
Added it in commit 6b9525a.

/* solhint-disable no-empty-blocks */

function listOwners() public view returns (address[]) {
return owners;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

address is public but it has a getter. It should be made private than.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did it consciously. owners default getter works with indices and returns a single address at given index. So it is a separate use case. I am not sure whether the default getter is useful, I have mixed feelings about default getters for arrays in Solidity. But I thought it wouldn't hurt to leave it as it is.

bytes data
)
public
onlySigned(v, r, s, keccak256(byte(0x19), byte(0), this, destination, value, data, nonce))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, where does 0x19 and byte(0) come from?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It follows ERC191 specification (ethereum/EIPs#191).
0x19 <1 byte version> <version specific data> <data to sign>

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good to know that, thanks


contract RecoverableMultiSig is TransferableMultiSig {

uint256 public recoveryConfirmations;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This name is a bit misleading, maybe recoveryBlockOffset?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 5bbc32b

import "./TransferableMultiSig.sol";


contract RecoverableMultiSig is TransferableMultiSig {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Am I correct that RecoverableMultiSig does not depend on TransferableMultiSig but just MultiSig?
I'm just asking, this is still just fine for our use case.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, you are correct. I flattened it in e3af2c4.
Subconsciously I was worried about Diamond Problem in multiple base classes inheritance, but it is non-existent in Solidity.

);

contract('TransferableMultiSigContract', accounts => {
describe.skip('#ctor', () => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

skip

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Skip usage already commented in other place


const ownerSets = [[accounts[2]], accounts.slice(1, 3), accounts.slice(2, 6)];
ownerSets.map(owners => {
context.skip(`When wallet has ${owners.length} owners`, () => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

skip

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Skip usage already commented in other place

});

describe('#ctor', () => {
it('should set owners', async () => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

set -> list

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 748887e

});

describe('#ctor', () => {
it('should set owners', async () => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

list. This is duplicated, it can be extracted to a testListOwners(ctx) method

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 748887e

const artifacts: SignHashArtifacts;
const assert: Chai.AssertStatic;
const contract: ContractContextDefinition;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure why have you removed that.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are two problems with this approach:

Not in all contexts these variables are defined (e.g. seed)
WebStorm does not recognize them (pretty lousy argument, but I heavily rely on this IDE)

@jksf
Copy link
Author

jksf commented Dec 9, 2017

@biern Thanks for a thorough review. I fixed all the things you pointed out except the declaration of global variables. I will reconsider changing it when WebStorm supports it. But still, there is an issue that not in all context these variables are available (for example in custom scripts, seed).
Let's keep it as it is (for now), it's more verbose but does not hurt.

@biern
Copy link
Member

biern commented Dec 10, 2017

I've took a look at the contracts again today and still couldn't find any issues. Outstanding job, I'm merging this.

@biern biern merged commit ced0929 into SignHash:master Dec 10, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants