Skip to content
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

Add build and send sweep transaction for bitcoin js wallet #358

Merged
merged 11 commits into from
Oct 7, 2020

Conversation

matthewjablack
Copy link
Contributor

@matthewjablack matthewjablack commented Sep 30, 2020

Description

This PR adds buildSweepTransaction and sendSweepTransaction for Bitcoin js wallet enabling the ability to sweep all utxos to a destination of choice.

This is particularly useful if you wish to remove all funds from a wallet

Note: This can be useful for Ethereum as well. The major use case would be for sweeping all ETH from a wallet (since it's already pretty easy to do this for ERC20's)

Submission Checklist 📝

  • Add `buildSweepTransaction
  • Add `sendSweepTransaction
  • Add tests for sendSweepTransaction

@matthewjablack matthewjablack changed the title Add build and send sweep transaction for js wallet Add build and send sweep transaction for bitcoin js wallet Sep 30, 2020
@monokh
Copy link
Collaborator

monokh commented Sep 30, 2020

Hey @matthewjablack thanks for the PR here, this is a very cool function
To keep the compatibility of the library uniform, we usually need any new functions to have implementations across ETH and ERC20 too, is this something you can add?

@matthewjablack
Copy link
Contributor Author

matthewjablack commented Sep 30, 2020

Hey @monokh we're pretty focused on Bitcoin development at the moment, so unfortunately the ETH side of things would be out of scope of us.

@monokh
Copy link
Collaborator

monokh commented Oct 2, 2020

@matthewjablack To ensure the library is predictable and fits the purpose of being an abstraction layer between the chains, we really need any functionality implemented to have a suitable interface and be implemented across the supported chains where possible.

Maintaining single chain based functionality adds overhead that the library is not suited towards. For example the current signature for async sendSweepTransaction (externalChangeAddress, outputs, fee, fixedInputs) is not compatible with the ETH chain and will need breaking changes when implemented cross chain.

So we ask for new features to be implemented cross chain because it:

  • Forces the right interface to be created at the client level
  • Ensures that the functionality is indeed able to be abstracted in a usable way
  • Ensures that between the chains, the function is uniform and behaves in a predictable way
  • Works as expected for the target users of the library (those looking to abstract cross chain)

@matthewjablack
Copy link
Contributor Author

Hey @monokh good point about async sendSweepTransaction (externalChangeAddress, outputs, fee, fixedInputs) not being compatible with the ETH chain.

I've changed it to async sendSweepTransaction (externalAddress, fee, outputs, fixedInputs) and implemented it on the ETH chain

Copy link
Collaborator

@monokh monokh left a comment

Choose a reason for hiding this comment

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

Please also include the ERC20 implementation. I believe it would be in EthereumErc20Provider

throw Error('There should not be any change for sweeping transaction')
}

_outputs.forEach((output, i) => {
Copy link
Collaborator

Choose a reason for hiding this comment

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

What is going on here with the _outputs and fixedInputs ?
The common set of function across chains would be to send all value in the wallet to a single address.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Having _outputs and fixedInputs allows you to spend all utxos in a wallet, and send a specific amount to an address, while sending the change to another address.

Useful if you want to pay someone and sweep your wallet at the same time.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ok, i see what you are going for here. However i think the functions should not cater for complex features, unless it can be abstracted cross chain or is required for a specific need.

Copy link
Collaborator

Choose a reason for hiding this comment

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

we want to reduce our maintenance to what is necessary for common usage

Copy link
Collaborator

Choose a reason for hiding this comment

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

changing that should make this function as well as getInputsForAmount simpler

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There are actually a couple of use cases where this is quite important.

If you want to allow users to select specific utxos and spend them or send funds to a particular location (similar to Wasabi) having defined inputs and outputs is necessary.

Another case is for DLC's. Every DLC created, must commit to a specific utxo for the funding tx. If the user wants to create multiple DLC's, they must split up the utxos beforehand. To do this as efficiently as possible, it's important to be able to specify a particular utxo, create one output to be used for a specific DLC, and the other one be change.

packages/client/lib/Chain.js Outdated Show resolved Hide resolved
packages/client/lib/Chain.js Outdated Show resolved Hide resolved
@matthewjablack
Copy link
Contributor Author

matthewjablack commented Oct 5, 2020

@monokh added sendSweepTransaction to EthereumERC20Provider and addressed all your comments

Copy link
Collaborator

@monokh monokh left a comment

Choose a reason for hiding this comment

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

This is looking in really good shape! Just one final comment

throw Error('There should not be any change for sweeping transaction')
}

_outputs.forEach((output, i) => {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Ok, i see what you are going for here. However i think the functions should not cater for complex features, unless it can be abstracted cross chain or is required for a specific need.

throw Error('There should not be any change for sweeping transaction')
}

_outputs.forEach((output, i) => {
Copy link
Collaborator

Choose a reason for hiding this comment

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

we want to reduce our maintenance to what is necessary for common usage

throw Error('There should not be any change for sweeping transaction')
}

_outputs.forEach((output, i) => {
Copy link
Collaborator

Choose a reason for hiding this comment

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

changing that should make this function as well as getInputsForAmount simpler

@matthewjablack
Copy link
Contributor Author

Updated @monokh to remove Bitcoin specific functionality. This can be implemented externally if developers wish to allow wasabi type functionality

@monokh monokh self-requested a review October 7, 2020 07:35
Copy link
Collaborator

@monokh monokh left a comment

Choose a reason for hiding this comment

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

Looking good! Thanks for this

@monokh monokh merged commit 2ff1b58 into dev Oct 7, 2020
@kraikov kraikov deleted the sweep-transaction branch April 29, 2022 09:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants