-
Notifications
You must be signed in to change notification settings - Fork 279
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
MTX.fund - Fixes #666
MTX.fund - Fixes #666
Conversation
Test is just repeat of the matrix, it can be rewritten and shortened as a function.. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Questions and comments below. One other thing I think we should test is some signatures / witness stacks. There's no mtx.check()
in these tests and one of the important reasons for this patch is to enable the wallet to fund a MTX that already has a signed input. Use cases are coinjoins, atomic swaps, wallet plugins that handle fancy non standard scripts, etc. We already kinda have that in the atomic-swap test but I think it'd be prudent to include at least one external signature check in mtx-test.js
as well.
@@ -1413,6 +1413,27 @@ class MTX extends TX { | |||
/** | |||
* Coin Selector | |||
* @alias module:primitives.CoinSelector |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice job on the jsdocs properties -- do we actually need this alias?
http://hsd-dev.org/hsd/module-primitives.CoinSelector.html
I'm not sure why it needs to be listed as a primitive since the code is not in the primitves/
directory...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also we're not describing the options
here but I see that is missing from many classes in hsd, so that should be a future project...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm.. CoinSelector is part of the primitives/mtx - so I guess that's the reason?
Will also add options. It's almost exact as properties but still.
const coin = dummyCoin(wallet1.getAddress(), 1000000); | ||
|
||
mtx.addOutput(wallet2.getAddress(), 1500000); | ||
mtx.view.addCoin(coin); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could also be mtx.addCoin(coin)
right? I tried this and test passed -- is there any significant difference?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above. We want to make sure view is processed properly.
|
||
// Ensure we have coins for the existing inputs. | ||
const view = this.tx.view; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is confusing me a little bit because the constructor already assigns this.tx = tx.clone();
and this.view = tx.view;
Except for the last for
loop (line 1782) you use this.view
which is what I'd expect ...?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because mtx.clone
does not clone coinview
, this.tx
has fresh view
.
So this method ensures we have all necessary coins in the original CoinView and copies to the new one.
Another thing I noticed is that in the worst case scenario, we will loop through |
for (const coin of coins) { | ||
view.addCoin(coin); | ||
this.viewCoins.push(coin); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this ending different than resolvePreferred()
? Do we already have these coins in chosen
?
for (const coin of coins) {
this.tx.addCoin(coin);
this.chosen.push(coin);
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this.tx.addCoin will also create inputs
in the tx. We don't want to do that here, because those inputs already exist in the this.tx
. We are just updating view (Comment above)
return; | ||
|
||
while (this.index < this.coins.length) { | ||
const coin = this.coins[this.index++]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible that a coin would be added twice? If, for example, this.coins[1]
was actually spent by one of the preferred or existing inputs, could that coin be mistakenly added a second time to fund the rest of the transaction? I actually am not even sure mtx.check()
would catch a double-spend like this, we might need an explicit test
The anyone can renew test can also be updated: hsd/test/anyone-can-renew-test.js Lines 309 to 312 in 06aabff
|
@nodech checking in on this? |
One thing that users will have to consider with these changes is that, coinview should always be supplied with coin information when using As for double spend question: It's not job of the CoinSelector to resolve double spents that happen because of the |
Previous version of interactive-name-swap used a ugly hack to get around limitations on wallet funding, since wallet.fund() no longer wipes previous inputs, the previous implementation is not longer the recommended way.
This is alternative implementation of #639 that solves issue in the
CoinSelector
.Separate
existing
andpreferred
inputs:options.inputs
.CoinView
to resolvecoins
.Closes #639
Closes #901