-
Notifications
You must be signed in to change notification settings - Fork 92
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
eth: Fix init and redeem. #1414
Conversation
// DecodeCoinID creates a human-readable representation of a coin ID for Ethereum. | ||
func (d *Driver) DecodeCoinID(coinID []byte) (string, error) { | ||
const invalid = "<invalid coin>" | ||
if len(coinID) == common.HashLength { | ||
id, err := dexeth.DecodeCoinID(coinID) | ||
if err != nil { | ||
return invalid, err | ||
} | ||
return id.String(), nil | ||
} | ||
id, err := decodeFundingCoinID(coinID) | ||
if err != nil { | ||
return "<invalid coin>", err | ||
return invalid, err | ||
} | ||
return id.String(), nil | ||
} |
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.
Sometimes a tx hash, and we can gauge that by length. Otherwise a funding coin.
@@ -689,7 +697,7 @@ func (eth *ExchangeWallet) Swap(swaps *asset.Swaps) ([]asset.Receipt, asset.Coin | |||
return nil, nil, 0, fmt.Errorf("unfunded contract. %d < %d", totalInputValue, totalSpend) | |||
} | |||
|
|||
tx, err := eth.node.initiate(eth.ctx, swaps.Contracts, swaps.FeeRate, swaps.AssetVersion) | |||
tx, err := eth.node.initiate(eth.ctx, swaps.Contracts, 200 /*swaps.FeeRate*/, swaps.AssetVersion) |
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.
Here and in redeem, this was too low. Will fix this better.
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.
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.
I'm of the opinion that the server should just set the Match.{FeeRateBase,FeeRateQuote}
to the (dex.Asset).MaxFeeRate
for eth at match time. The current base fee rate is not relevant to the validation of the transaction. In theory, the client could just log the MaxFeeRate
at order time and persist that info and use it as an input to the Swap
method. But I don't see how that makes things easier for anyone. Instead, we can just think of the Match.{FeeRateBase,FeeRateQuote}
as the "validation rate", or the rate that we are going to validate in their transaction. This fits into our current architecture without changes, and the relevant values are persisted.
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.
Agree completely with that @buck54321. Ref, your comment in my issue on the matter: #1372 (comment)
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.
Will leave for now if that's ok.
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.
OK, when we implement the changes discussed here and #1372 (comment) we will switch this back to swaps.FeeRate
// Time is not yet set for uninitiated swaps. | ||
if swap.State == dexeth.SSNone { | ||
return false, time.Time{}, asset.ErrSwapNotInitiated | ||
} |
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.
Useful for not logging this as an error, as it is expected until the init is mined.
log.Infof("Secret validation failed (match id=%v, maker=%v, secret=%v)", | ||
matchID, actor.isMaker, params.Secret) |
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.
%v prints hex and I think this is info. It is the fault of the user if the redemption secret is incorrect.
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.
Good call on both accounts. I fell into the %x-with-a-Stringer pitfall that I like to remind others about.
Also, starting the node from seed every time isn't really making things faster. As commented in the nodeclient harness tests, the node has trouble figuring out the correct account nonce it seems, and always starts with zero, even if it cannot send txs using zero. Maybe there is a way fix for this, but often need a new eth harness if you really need to start over. edit: Actually seems alright now. Maybe just need to wait for the Also this does not touch refunds which may not work yet. |
0aa37e4
to
167690d
Compare
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.
Looks good, I was able to successfully swap dcr<->eth on simnet.
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.
Brilliant! My first swap with eth. Do whatever with the ErrSwapNotInitiated
I guess, but we need a comprehensive plan there.
if err != nil && !errors.Is(err, asset.ErrSwapNotInitiated) { | ||
// No need to log an error if swap not initiated as this | ||
// is expected for newly made swaps involving contracts. | ||
t.dc.log.Errorf("isSwappable: error getting confirmation for our own swap transaction: %v", err) | ||
} |
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 closely related to #1425, and ErrSwapNotInitiated
is analogous to CoinNotFoundError
, as far as I can tell. There was some discussion on this on Element too. On that end, chappjc decided to just return nil
error and zero confs in that case. Is there a strong argument to do it differently here?
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.
Just want to reiterate that #1425 is just a stopgap for v0.4, and if we do keep it nil
when the swap isn't found (either txn with utxo assets or an entry in the contract's swaps map for eth), I suspect we'll want a found bool
or similar from SwapConfirmations
, with an error reserved for the case where it is actually unexpected to not find it, but of course when unconfirmed on eth it is expected since no state has changed to record the new swap (proper error semantics).
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.
I am trying to avoid returning a false positive int the case of returning nil, and false negative in case of returning CoinNotFoundError
, I guess. Not finding the swap could be a problem or it might not be. It's not that there is absolutely no problem, there may be a problem. Does that make sense? We could use the initiation tx instead of the contract instead and confidently return CoinNotFoundError
like the server does.
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.
Maybe it would be more correct to log as warn?
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.
It depends on (a) the capabilities of the wallet backend and (b) time and blocks that have elapsed. I've beat this horse to death now, but I am adamantly opposed to logging a warning or error if it's normal for the wallet not to find the unconfirmed swap.
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.
No need to change this now, but I think the ultimate solution involves more work in Core to be intelligent about gauging severity.
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.
Good to go after popping off the first two commits, rebasing and and squashing the last two.
On the client side: Allow decoding coins to discern between tx hashes and funding coin encodings. Temporarily set max fees to 200 so that they can be mined on our simnet. Return tx hashes for redeems instead of inputs because that's currently what the server needs to create swap coins. Add a new error type for uninitiated swaps. This is returned when checking swap confirmations and locktime for logging purposes so this is not considered an error for logging purposes. Add the ability to squelch eth's internal node because it is very loud on trace. For the server: Return TxData and SecretHash with contract data. TxData is the entire serialized transaction that initiates a swap.
354918f
to
7d05911
Compare
With these changes I was able to successfully swap.
A few of the current problems are pointed out.