-
Notifications
You must be signed in to change notification settings - Fork 104
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
erc20: Add testnet usdc. #1733
erc20: Add testnet usdc. #1733
Conversation
Can rebase. I think using the actual USDC testnet ERC20 is important. |
Need to figure out testnet or wait for it to work I guess before this pr is relevant again. |
4c4cda8
to
a69d511
Compare
c8f6e45
to
9fcd4b4
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.
Some observations from a cursory review. Looking good though.
Address: common.Address{}, | ||
SwapContracts: map[uint32]*SwapContract{}, |
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.
Any reason not to populate this now?
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.
We don't have a contract out yet do we? I guess the gasses would be the same?
Address: common.Address{}, | ||
SwapContracts: map[uint32]*SwapContract{}, |
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 a thought. No need for followup here. But @chappjc has seemingly found the actual USDC contracts. We could launch them with the simnet harness.
BTW, @chappjc's gist was the first google result for the search "usdc sol contract github".
f9700e1
to
dbd42f0
Compare
Seems to be working fine. A few things not perfect yet: The simnet harness tests often fail on
I think I looked into this a few weeks ago and it was due to the nonce being reused or something. Will look again. A few UI issues. I don't think this is related to this issue. Two things happened that were unexpected. The server could not find a swap while the clients (infura) could. Which is concerning. But then after the taker here redeemed it sticks in an invalid coin. We don't know the tx that redeemed the contract without the server relaying that info to us from maker, but this should display something more informative I guess. I made a comment about the same thing here #1866 (review) |
server/market/orderrouter.go
Outdated
if lo, ok := ord.(*order.LimitOrder); ok { | ||
redeems = int(calc.QuoteToBase(lo.Rate, trade.Quantity) / tunnel.LotSize()) | ||
} else { | ||
redeems = int(calc.QuoteToBase(safeMidGap(tunnel), trade.Quantity) / tunnel.LotSize()) | ||
} | ||
redeems = int(trade.Quantity / tunnel.LotSize()) |
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 think this was incorrect, please check me.
If going back to a client that doesn't have the new usdc id added the logs will show:
So should probably handle that more gracefully since it is expected for new ids to exist that client may not know about yet. |
I have now seen the replacement transaction error outside of tests so there is a bug somewhere. This was on master. Have never seen before and suspect it has to do with the provider changes:
So it is trying to use a previous nonce but with the same gas fee? How do replacement transactions work now that you don't bid with a gas price? |
That's unnerving. This is almost certainly an accidental replacement, right? sounds like a nonce tracking issue. Relying on multiple providers, or not allowing a provider to lag on next-nonce info?
Good question. I would guess the tip. |
Does the tip cap go to the stakers now? |
d22de7e
to
8a38f65
Compare
Fixing the rate https://github.com/decred/dcrdex/compare/d22de7e94a7b97a27266dab4ece6d54bb8bb6868..8a38f65f33a857b5131f5b25aae45dc620e8b8b4 Not smart enough to know why, but moving multiplication first seems to be more precise https://go.dev/play/p/2mcaci8LGOF The |
That's why we avoid floating point types like the plague in the backend. For ieee754 floats, you generally lose precision immediately for fractional values, while whole numbers can be represented exactly up to fairly large values (I think it's 2^53 for 64 bit floats). Naturally, Javascript offers neither a real integer type or an arbitrary precision integer type. Anyway, by multiplying the two integers first, you get a large integer exactly represented instead of a tiny decimal value number (with precision loss) that you then divide. I had to deal with this all the time with matlab and image processing and the lesson is don't assume floats are gonna be fine. |
Added a cache that is working well in tests. Maybe a good solution to the nonce problem. |
Did you try adjusting the |
client/asset/eth/eth.go
Outdated
err := f(contractor) | ||
// If a transaction fails with a provider, trust the next nonce. | ||
if err != nil { | ||
if c, is := contractor.(*contractorV0); is { | ||
if mRPC, is := c.cb.(*multiRPCClient); is { | ||
mRPC.voidUnusedNonce() | ||
} | ||
} | ||
} | ||
return 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.
It certainly would be convenient to have the nonce returning done in a more central place like this, but withContractor
is not just for contract interactions that involve a transaction. We have read-only contract API requests that involve no transaction and thus no preceding new-nonce request.
I think this needs to be done in the same function that did the nonce reservation itself, i.e. initiate
, redeem
, etc.
func (w *assetWallet) initiate(ctx context.Context, assetID uint32, contracts []*asset.Contract,
maxFeeRate, gasLimit uint64, contractVer uint32) (tx *types.Transaction, err error) {
var val uint64
if assetID == BipID {
for _, c := range contracts {
val += c.Value
}
}
w.nonceSendMtx.Lock()
defer w.nonceSendMtx.Unlock()
// 1. get nonce
txOpts, _ := w.node.txOpts(ctx, val, gasLimit, dexeth.GweiToWei(maxFeeRate))
// 2. attempt transaction with the nonce
return tx, w.withContractor(contractVer, func(c contractor) error {
tx, err = c.initiate(txOpts, contracts)
if err != nil {
// 3. return the unused nonce
c.voidUnusedNonce()
}
return err
})
}
func (c *contractorV0) voidUnusedNonce() {
if mRPC, is := c.cb.(*multiRPCClient); is {
mRPC.voidUnusedNonce()
}
}
Even that is a touch fishy though because it requires implementing voidUnusedNonce
, but maybe alright.
Other ways to do this and be sure we're only targeting failed transactions?
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 could be a txWithContractor
function that is the same as withContractor
but also voids the nonce. Then use that function for initiate
, redeem
, etc.
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.
Put the void in init, redeem, refund, approve, and the sends https://github.com/decred/dcrdex/compare/b20ce45607fe929b82d3127ed59e153f70dcb566..f683573222317c8399e82ccff3439ab5e161f2c4
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.
Thanks for doing this nonce work. It's critical to get right.
A couple comments pertaining to the last diff.
d5ea00d
to
f011f1e
Compare
Allow nonce to be overridden for redeems https://github.com/decred/dcrdex/compare/d5ea00d49ef4a672c0edfac553d1666208ab4594..f011f1e3bc587a4e2207795c492a9b8dd4d1a2c2 |
client/asset/eth/multirpc.go
Outdated
@@ -502,6 +508,44 @@ func (m *multiRPCClient) connect(ctx context.Context) (err error) { | |||
return nil | |||
} | |||
|
|||
// unusedNonce returns true and saves the nonce for the next call when a nonce | |||
// has not been received recently. | |||
func (m *multiRPCClient) unusedNonce(nonce uint64) bool { |
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.
Would prefer registerNonce(nonce uint64) error
semantics, but I'm not gonna fight you for it.
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.
The registerNonce
name certainly fits better with the method's functionality. Less fond of error returns when a flag serves the same purpose.
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.
unusedNonce -> registerNonce
I don't feel an error is great because none of the outcomes are an error imo, unless the provider continues to give us a nonce we are sure we used. From testnet testing, we expect the same nonce to come back once sometimes from remote providers.
checkDelay := time.Second * 5 | ||
for i := 0; i < checks; i++ { |
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 for now, but we should look to move past our reliance on external sources permanently. We already are tracking recent txs with the monitoredTxs
work. I wonder if we could spin that into double-duty for nonce generation too.
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.
Continuation of the conversation at #1733 (comment)
Less reliance is better, but I think we'll always need some way to see what the chain thinks is the next nonce. Consider these cases: restore from seed, starting up after a while and the user has been messing in an external wallet with the same keys, "kvdb" failure, or just internal dex accounting bugs that could be catastrophic and have cascading effects if we don't at least occasionally "check in" with the chain. I think these are things that @JoeGruffins was alluding to in his response in the previous thread.
I don't think we've got the perfect solution yet either, but there's gotta be some way to have the chain (via rpc provider) inform us, but be more defensive against the possibility of being mislead by a trusted third party.
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.
Oh, for sure. RPC wallet will always need to "seed" its nonce.
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.
Leaving as is for now...
if diff.CmpAbs(dexeth.GweiToWei(1)) >= 0 { // Ugh. Need to get to != 0 again. | ||
t.Fatalf("%s: unexpected parent chain balance change: want %d got %d, diff = %.9f", | ||
test.name, dexeth.WeiToGwei(wantParentBal), dexeth.WeiToGwei(parentBal), float64(diff.Int64())/dexeth.GweiFactor) | ||
if len(diff.Bits()) != 0 { |
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 this?
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 what 😅
I think len(diff.Bits()) != 0
checks for a diff of 0, which is what we wanted, expected to be what we got. So no 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.
Oh, the docs do say to avoid using it https://pkg.go.dev/math/big#Int.Bits so will change I guess.
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.
Changed to diff.Cmp(big.NewInt(0))
, if that was the problem
client/core/exchangeratefetcher.go
Outdated
if sa.Wallet == nil { | ||
// TODO: asset.Info will be nil for tokens. Make this work for | ||
// tokens. | ||
if sa.Wallet == nil || sa.Info == 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.
The only thing being use is the sa.Info.Name
, which is now duplicated on the SupportedAsset
, so you can use sa.Name
instead. Just need to verify that coinpapSlug
will work correctly.
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, did a slight hack to make the ids correct. Also the send screen will not show the fiat balance yet. Maybe can fix in another pr.
server/market/balancer.go
Outdated
@@ -79,7 +79,7 @@ func NewDEXBalancer(tunnels map[string]PendingAccounter, assets map[uint32]*asse | |||
} | |||
bb.feeFamily[parentID] = parent.assetInfo | |||
for tokenID := range asset.Tokens(parentID) { | |||
if tokenID == assetID { // Don't double count | |||
if tokenID == assetID || assets[tokenID] == nil { // Don't double count |
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.
Can you comment on the need for this?
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 should have commented then because it's difficult to remember now. I think because we can have tokens specific to networks. So, usdc will not exist on simnet, but will be in the childrens map this is looking through. Let me confirm that.
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.
Yes, that's it. Added a comment unless we should do more.
Hmm, panic after rebasing and starting client:
Maybe no dc yet?
Then panic. Made #1989 |
client/cmd/dexc-desktop/build/dexc_0.6.0-pre-0_amd64/DEBIAN/control
Outdated
Show resolved
Hide resolved
@@ -135,6 +135,8 @@ var ( | |||
// funds will be printed. | |||
testnetWalletSeed string | |||
testnetParticipantWalletSeed string | |||
usdcID, _ = dex.BipSymbolID("usdc.eth") |
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.
EDIT: Github review is hiding the fact that this comment is part of a thread here: #1733 (comment)
A cli tool to run GetGasEstimates
sounds smart to me (at some point). I'm also not fond of functions like that in the product code that are not intended to be used in the app.
However, we no longer do operator-set gasses (or transaction sizes for utxo assets), only fee rates. Clients only use their own baked-in trusted values. So if we want it back so that an operator can "adjust the gases up to a factor of 2, in case some unforeseen subtlety of an ERC20 contract", we'll have to modify the asset.Wallet
interface again.
But I think we accepted, that a server changing a client's understanding of transaction "weight" (not just fee rate) is not a desirable approach, especially in light of mesh.
IMO we should pad the compiled-in gasses more generously. Consider: If you use metamask to interact with these contracts manually, it sets a surprisingly high gas limit for the transaction. See this comment regarding the approve
method: #1733 (comment) I don't know how it gets the gas limit number (some evm simulation? eth_estimateGas
at the provider?), but I think it's an indication that we should pad these numbers generously. In that limited test, it sets the gas limit to 150% of what the executed transaction ends up actually consuming.
just rebased and removed unintended dexc-desktop folder |
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.
Working well!
dex-test updated with DCR-USDC.ETH market.
Tested using Ankr (https://www.ankr.com/rpc/eth?tab=get-started)
Goerli testnet
Here we have to fix the pre-swap fee projections when buying the token (as quote asset):
Approval automatically submitted. However, it used a gas limit of 400,000 instead of 65,000:
https://goerli.etherscan.io/tx/0x48405dbc89186d126b34f48d7b32063630a2733bca558dbe28f25aca7fac4aef
The gas limit on the initiate
is extremely tight. We need more like 75% there:
https://goerli.etherscan.io/tx/0x21a47c304d514771c34dd671cda487fe321b22a81677918fe8a7f5ddd35116d1
Gas limit on the redeem
is also very tight:
https://goerli.etherscan.io/tx/0x736e6a3ff53534046f05e9ed1bf16dc606efd69e3482caf54c94f13dadc336b2
2022-12-15 00:25:13.572 [DBG] CORE[eth][USDC.ETH]: Skipping live swap gas because contract is not approved for transferFrom
2022-12-15 00:25:14.866 [TRC] CORE[eth][ETH][RPC]: using cached header from "rpc.ankr.com"
2022-12-15 00:25:16.077 [TRC] CORE[eth][ETH][RPC]: Sending signed tx via "rpc.ankr.com"
2022-12-15 00:25:16.376 [INF] CORE[eth][USDC.ETH]: Approval sent for usdc.eth at token address 0x07865c6E87B9F70255377e024ace6630C1Eaa37F, nonce = 0
...
2022-12-15 00:35:07.909 [INF] CORE: Starting negotiation for match 24d55c264b1ae28b0b9af8132e6ddd151ec9e5b70e90116d700b2a2dd7e234c3 for order b23a23514b4ac05246537225e87924e51c27f3d8a96eddcc706d100ba816f111 with swap fee rate = 14, quantity = 200000000
2022-12-15 00:35:07.909 [DBG] CORE: Trade order b23a23514b4ac05246537225e87924e51c27f3d8a96eddcc706d100ba816f111 matched with 1 orders: +200000000 filled, total fill 200000000 / 200000000 (100.0%)
2022-12-15 00:35:07.909 [DBG] CORE: notify: |POKE| (order) Matches made - Sell order on dcr-usdc.eth 100.0% filled (b23a2351) - Order: b23a23514b4ac05246537225e87924e51c27f3d8a96eddcc706d100ba816f111
2022-12-15 00:35:07.910 [TRC] CORE[eth][ETH][RPC]: fetching fresh header from "rpc.ankr.com"
2022-12-15 00:35:07.911 [INF] CORE: Starting negotiation for match 24d55c264b1ae28b0b9af8132e6ddd151ec9e5b70e90116d700b2a2dd7e234c3 for order 5514e2b0a5cd1c0059a0dc3de03441985dacc27fc1a0746d35af9370a623dcac with swap fee rate = 200, quantity = 200000000
2022-12-15 00:35:07.911 [DBG] CORE: Trade order 5514e2b0a5cd1c0059a0dc3de03441985dacc27fc1a0746d35af9370a623dcac matched with 1 orders: +200000000 filled, total fill 200000000 / 200000000 (100.0%)
2022-12-15 00:35:07.911 [DBG] CORE: notify: |POKE| (order) Matches made - Buy order on dcr-usdc.eth 100.0% filled (5514e2b0) - Order: 5514e2b0a5cd1c0059a0dc3de03441985dacc27fc1a0746d35af9370a623dcac
2022-12-15 00:35:07.912 [DBG] CORE: Swappable match 24d55c264b1ae28b0b9af8132e6ddd151ec9e5b70e90116d700b2a2dd7e234c3 for order 5514e2b0a5cd1c0059a0dc3de03441985dacc27fc1a0746d35af9370a623dcac (Maker)
2022-12-15 00:35:07.912 [DBG] CORE: Using stored change coin address: 0x47e177f774e0Db1Cc68a7448135D3a10014E251f, amount:42580000, fees:35000000 (usdc.eth) for order 5514e2b0a5cd1c0059a0dc3de03441985dacc27fc1a0746d35af9370a623dcac matches
...
2022-12-15 00:35:08.474 [DBG] CORE[eth][ETH]: tip change: 8136521 (0x1a9e1379ee77effffd762c21c6a37798cd2123f908e30744edc071bc2efe5572) => 8136522 (0x34b8db64f7370eb07b91ead2f48f2af83354ae20ae733fbbcb3b71e45998fa5e)
2022-12-15 00:35:08.474 [TRC] CORE: Processing tip change for usdc.eth
2022-12-15 00:35:08.474 [TRC] CORE: Processing tip change for eth
2022-12-15 00:35:08.828 [TRC] CORE: notify: |DATA| (balance) balance updated
2022-12-15 00:35:08.845 [TRC] CORE[eth][ETH][RPC]: using cached header from "rpc.ankr.com"
2022-12-15 00:35:08.845 [DBG] CORE: Slow tick: trade b23a23514b4ac05246537225e87924e51c27f3d8a96eddcc706d100ba816f111 processed in 935.211907ms, blocked for 173ns
2022-12-15 00:35:10.068 [TRC] CORE[eth][ETH][RPC]: Sending signed tx via "rpc.ankr.com"
2022-12-15 00:35:11.114 [INF] CORE: Broadcasted transaction with 1 swap contracts for order 5514e2b0a5cd1c0059a0dc3de03441985dacc27fc1a0746d35af9370a623dcac. Assigned fee rate = 200. Receipts (usdc.eth): [{ tx hash: 0x21a47c304d514771c34dd671cda487fe321b22a81677918fe8a7f5ddd35116d1, contract address: 0x9E493d3766989e701797b9371682B7b94fD8Af9c, secret hash: 3aff97cefebb5572a4ed200c1e5fb0a3c9e0a0cf3f917a7b59256e0ececc4682 }].
2022-12-15 00:35:11.115 [INF] CORE: Contract coin 0x21a47c304d514771c34dd671cda487fe321b22a81677918fe8a7f5ddd35116d1 (usdc.eth), value = 42580000, refundable at 2022-12-15 14:35:06 -0600 CST (receipt = { tx hash: 0x21a47c304d514771c34dd671cda487fe321b22a81677918fe8a7f5ddd35116d1, contract address: 0x9E493d3766989e701797b9371682B7b94fD8Af9c, secret hash: 3aff97cefebb5572a4ed200c1e5fb0a3c9e0a0cf3f917a7b59256e0ececc4682 }), match = 24d55c264b1ae28b0b9af8132e6ddd151ec9e5b70e90116d700b2a2dd7e234c3
2022-12-15 00:35:11.115 [TRC] CORE: Contract coin 0x21a47c304d514771c34dd671cda487fe321b22a81677918fe8a7f5ddd35116d1 secret = bbfda2973ec67850f03ac353016a522e19b9856d2c9dbab0424c6676bc98c830
2022-12-15 00:35:11.116 [INF] CORE: Notifying DEX dextesttaggpdj27s26wklczemovhqdzyvgokyumey33uemlw4imawqd.onion:7232 of our usdc.eth swap contract 0x21a47c304d514771c34dd671cda487fe321b22a81677918fe8a7f5ddd35116d1 for match 24d55c264b1ae28b0b9af8132e6ddd151ec9e5b70e90116d700b2a2dd7e234c3
2022-12-15 00:35:11.116 [DBG] CORE: notify: |POKE| (order) Swaps initiated - Sent swaps worth 42.580000 USDC on order 5514e2b0 - Order: 5514e2b0a5cd1c0059a0dc3de03441985dacc27fc1a0746d35af9370a623dcac
2022-12-15 00:35:11.116 [DBG] CORE: Slow tick: trade 5514e2b0a5cd1c0059a0dc3de03441985dacc27fc1a0746d35af9370a623dcac processed in 3.204066028s, blocked for 183ns
2022-12-15 00:35:11.611 [TRC] CORE: notify: |DATA| (balance) balance updated
2022-12-15 00:35:11.611 [INF] CORE: runJob(match) completed in 3.703908825s
...
2022-12-15 00:35:12.848 [DBG] CORE: Slow tick: trade 5514e2b0a5cd1c0059a0dc3de03441985dacc27fc1a0746d35af9370a623dcac processed in 4.374342168s, blocked for 2.64177359s
2022-12-15 00:35:12.849 [INF] CORE: runJob(match_proof) completed in 440.147653ms
2022-12-15 00:35:12.942 [DBG] CORE: Received valid ack for 'init' request for match 24d55c264b1ae28b0b9af8132e6ddd151ec9e5b70e90116d700b2a2dd7e234c3
2022-12-15 00:35:12.942 [TRC] CORE[eth][ETH][RPC]: Sending signed tx via "rpc.ankr.com"
2022-12-15 00:35:12.944 [INF] CORE: Audited contract (usdc.eth: 0x21a47c304d514771c34dd671cda487fe321b22a81677918fe8a7f5ddd35116d1) paying to 0x47e177f774e0Db1Cc68a7448135D3a10014E251f for order b23a23514b4ac05246537225e87924e51c27f3d8a96eddcc706d100ba816f111, match 24d55c264b1ae28b0b9af8132e6ddd151ec9e5b70e90116d700b2a2dd7e234c3, with tx data = true. Script: 000000003aff97cefebb5572a4ed200c1e5fb0a3c9e0a0cf3f917a7b59256e0ececc4682
2022-12-15 00:35:13.180 [TRC] CORE: notify: |DATA| (balance) balance updated
...
2022-12-15 00:35:18.474 [TRC] CORE[eth][ETH][RPC]: fetching fresh header from "rpc.ankr.com"
2022-12-15 00:35:18.762 [TRC] CORE[eth][ETH][RPC]: fetching fresh header from "rpc.ankr.com"
2022-12-15 00:35:18.818 [DBG] CORE[eth][ETH]: tip change: 8136522 (0x34b8db64f7370eb07b91ead2f48f2af83354ae20ae733fbbcb3b71e45998fa5e) => 8136523 (0xf9faf97445fe93bd015bcf309382d2cf51bbf8364ccc22e35a0cd71a2e35baa8)
2022-12-15 00:35:18.818 [TRC] CORE: Processing tip change for eth
2022-12-15 00:35:18.818 [TRC] CORE: Processing tip change for usdc.eth
2022-12-15 00:35:19.255 [TRC] CORE: notify: |DATA| (balance) balance updated
2022-12-15 00:35:20.824 [DBG] CORE: Slow tick: trade 5514e2b0a5cd1c0059a0dc3de03441985dacc27fc1a0746d35af9370a623dcac processed in 2.062211064s, blocked for 407ns
2022-12-15 00:35:20.824 [WRN] CORE: checkTrades completed in 2.487452626s (slow)
2022-12-15 00:35:22.548 [DBG] CORE: Slow tick: trade 5514e2b0a5cd1c0059a0dc3de03441985dacc27fc1a0746d35af9370a623dcac processed in 3.72949721s, blocked for 2.005655373s
...
2022-12-15 00:35:22.987 [TRC] CORE: notify: |DATA| (balance) balance updated
2022-12-15 00:35:29.475 [TRC] CORE[eth][ETH][RPC]: fetching fresh header from "rpc.ankr.com"
2022-12-15 00:35:40.474 [TRC] CORE[eth][ETH][RPC]: fetching fresh header from "rpc.ankr.com"
2022-12-15 00:35:51.474 [TRC] CORE[eth][ETH][RPC]: fetching fresh header from "rpc.ankr.com"
2022-12-15 00:35:51.937 [DBG] CORE[eth][ETH]: tip change: 8136523 (0xf9faf97445fe93bd015bcf309382d2cf51bbf8364ccc22e35a0cd71a2e35baa8) => 8136524 (0xf1cffe87cf35444ce6631fe60d06f8e1918756c4924f0bf64c2f57af4cbb1f29)
2022-12-15 00:35:51.937 [TRC] CORE: Processing tip change for usdc.eth
2022-12-15 00:35:51.937 [TRC] CORE: Processing tip change for eth
2022-12-15 00:35:52.410 [TRC] CORE: notify: |DATA| (balance) balance updated
2022-12-15 00:35:52.735 [INF] CORE: Contract for match 24d55c264b1ae28b0b9af8132e6ddd151ec9e5b70e90116d700b2a2dd7e234c3 with swap coin 0x21a47c304d514771c34dd671cda487fe321b22a81677918fe8a7f5ddd35116d1 (USDC.ETH) expires at 2022-12-15 14:35:06 -0600 CST (19h59m13s).
2022-12-15 00:35:52.753 [INF] CORE: Match 24d55c264b1ae28b0b9af8132e6ddd151ec9e5b70e90116d700b2a2dd7e234c3 not yet swappable: current confs = 1, required confs = 4
...
2022-12-15 00:36:35.474 [TRC] CORE[eth][ETH][RPC]: fetching fresh header from "rpc.ankr.com"
2022-12-15 00:36:35.907 [DBG] CORE[eth][ETH]: tip change: 8136526 (0x656d4a776b856fe0296149e7346c3984e978b2bb62e61009f3d37603a5ac7eca) => 8136527 (0x734573787a5f65497a4a6cdfd46459bdbe230be99874f3abc9f5755554ea3ca2)
2022-12-15 00:36:35.907 [TRC] CORE: Processing tip change for usdc.eth
2022-12-15 00:36:35.907 [TRC] CORE: Processing tip change for eth
2022-12-15 00:36:36.486 [TRC] CORE: notify: |DATA| (balance) balance updated
2022-12-15 00:36:36.791 [DBG] CORE: Slow tick: trade 5514e2b0a5cd1c0059a0dc3de03441985dacc27fc1a0746d35af9370a623dcac processed in 883.941621ms, blocked for 327ns
2022-12-15 00:36:36.807 [DBG] CORE: Swappable match 24d55c264b1ae28b0b9af8132e6ddd151ec9e5b70e90116d700b2a2dd7e234c3 for order b23a23514b4ac05246537225e87924e51c27f3d8a96eddcc706d100ba816f111 (Taker)
2022-12-15 00:36:36.812 [DBG] CORE[dcr]: Change output size = 36, addr = TsnCApNFdyfnNVsfbgxJfdvQbS1EMfwpTvc
2022-12-15 00:36:36.813 [DBG] CORE[dcr]: 2 signature cycles to converge on fees for tx e71409dc2d5cf04db6ec76aa93a4c79e37128658a091dc352380eb64efda7bdb: min rate = 14, actual fee rate = 14 (3500 for 250 bytes), change = true
2022-12-15 00:36:36.816 [DBG] CORE[dcr]: returning coins [42a1262ceb68abf46f3d1c74c23593c06792b63cf636b744f8ac72444b08d6fa:1]
2022-12-15 00:36:36.816 [INF] CORE: Broadcasted transaction with 1 swap contracts for order b23a23514b4ac05246537225e87924e51c27f3d8a96eddcc706d100ba816f111. Assigned fee rate = 14. Receipts (dcr): [e71409dc2d5cf04db6ec76aa93a4c79e37128658a091dc352380eb64efda7bdb:0].
2022-12-15 00:36:36.816 [INF] CORE: The following are contract identifiers mapped to raw refund transactions that are only valid after the swap contract expires. These are fallback transactions that can be used to return funds to your wallet in the case dexc no longer functions. They should NOT be used if dexc is operable. dexc will refund failed contracts automatically.
Refund Txs: {"e71409dc2d5cf04db6ec76aa93a4c79e37128658a091dc352380eb64efda7bdb:0": 0100000001db7bdaef64eb802335dc91a0588612379ec7a493aa76ecb64df05c2ddc0914e70000000000feffffff01aab0eb0b0000000000001976a914087a5c5aec443b52ba2efffadc583587dcf6183288ac3adc9a63000000000100c2eb0b0000000000000000ffffffffce473044022045e8cfa8063d9ffb957aa130a474ca2504ab2757f1206e2de7cf09db7a8be28d0220799d67ae3c65af5571ada4aa21ed7b2f7d1e96f650549d4de104e40db679c7b101210259ba1e8832c4d065b81acc8fbd48bae05af8720e37ef2896dd7e0d2ab04ac651004c616382012088c0203aff97cefebb5572a4ed200c1e5fb0a3c9e0a0cf3f917a7b59256e0ececc46828876a914727704bd67afcfe7534e5b40525fc13043555dec67043adc9a63b17576a914087a5c5aec443b52ba2efffadc583587dcf618326888ac}
2022-12-15 00:36:36.817 [DBG] CORE: Saving change coin e71409dc2d5cf04db6ec76aa93a4c79e37128658a091dc352380eb64efda7bdb:1 (dcr) to DB for order b23a23514b4ac05246537225e87924e51c27f3d8a96eddcc706d100ba816f111
2022-12-15 00:36:36.817 [INF] CORE: Contract coin e71409dc2d5cf04db6ec76aa93a4c79e37128658a091dc352380eb64efda7bdb:0 (dcr), value = 200000000, refundable at 2022-12-15 08:35:06 +0000 UTC (receipt = e71409dc2d5cf04db6ec76aa93a4c79e37128658a091dc352380eb64efda7bdb:0), match = 24d55c264b1ae28b0b9af8132e6ddd151ec9e5b70e90116d700b2a2dd7e234c3
2022-12-15 00:36:36.818 [INF] CORE: Notifying DEX dextesttaggpdj27s26wklczemovhqdzyvgokyumey33uemlw4imawqd.onion:7232 of our dcr swap contract e71409dc2d5cf04db6ec76aa93a4c79e37128658a091dc352380eb64efda7bdb:0 for match 24d55c264b1ae28b0b9af8132e6ddd151ec9e5b70e90116d700b2a2dd7e234c3
2022-12-15 00:36:36.818 [DBG] CORE: notify: |POKE| (order) Swaps initiated - Sent swaps worth 2.00000000 DCR on order b23a2351 - Order: b23a23514b4ac05246537225e87924e51c27f3d8a96eddcc706d100ba816f111
2022-12-15 00:36:36.818 [DBG] CORE: Slow tick: trade b23a23514b4ac05246537225e87924e51c27f3d8a96eddcc706d100ba816f111 processed in 911.239691ms, blocked for 296ns
2022-12-15 00:36:36.841 [TRC] CORE: notify: |DATA| (balance) balance updated
2022-12-15 00:36:37.240 [TRC] CORE: notify: |DATA| (balance) balance updated
2022-12-15 00:36:37.427 [TRC] CORE[eth][ETH][RPC]: using cached header from "rpc.ankr.com"
2022-12-15 00:36:40.672 [DBG] CORE: Received valid ack for 'init' request for match 24d55c264b1ae28b0b9af8132e6ddd151ec9e5b70e90116d700b2a2dd7e234c3
2022-12-15 00:36:40.673 [INF] CORE: Audited contract (dcr: e71409dc2d5cf04db6ec76aa93a4c79e37128658a091dc352380eb64efda7bdb:0) paying to TsbTN5ynwpZjAWfAXeWLEZ7Xgn8hHtpX5qP for order 5514e2b0a5cd1c0059a0dc3de03441985dacc27fc1a0746d35af9370a623dcac, match 24d55c264b1ae28b0b9af8132e6ddd151ec9e5b70e90116d700b2a2dd7e234c3, with tx data = true. Script: 6382012088c0203aff97cefebb5572a4ed200c1e5fb0a3c9e0a0cf3f917a7b59256e0ececc46828876a914727704bd67afcfe7534e5b40525fc13043555dec67043adc9a63b17576a914087a5c5aec443b52ba2efffadc583587dcf618326888ac
2022-12-15 00:36:46.474 [TRC] CORE[eth][ETH][RPC]: fetching fresh header from "rpc.ankr.com"
2022-12-15 00:36:46.922 [DBG] CORE[eth][ETH]: tip change: 8136527 (0x734573787a5f65497a4a6cdfd46459bdbe230be99874f3abc9f5755554ea3ca2) => 8136528 (0xbba3ed68cbb2b7dbaacc289c15ef95f6beaae1aae4f20ad8d989442a4c0b2291)
2022-12-15 00:36:46.922 [TRC] CORE: Processing tip change for usdc.eth
2022-12-15 00:36:46.922 [TRC] CORE: Processing tip change for eth
2022-12-15 00:36:46.924 [INF] CORE: Contract for match 24d55c264b1ae28b0b9af8132e6ddd151ec9e5b70e90116d700b2a2dd7e234c3 with swap coin e71409dc2d5cf04db6ec76aa93a4c79e37128658a091dc352380eb64efda7bdb:0 (DCR) expires at 2022-12-15 08:35:06 +0000 UTC (7h58m19s).
2022-12-15 00:36:46.924 [DBG] CORE: Redeemable match 24d55c264b1ae28b0b9af8132e6ddd151ec9e5b70e90116d700b2a2dd7e234c3 for order 5514e2b0a5cd1c0059a0dc3de03441985dacc27fc1a0746d35af9370a623dcac (Maker)
2022-12-15 00:36:46.925 [TRC] CORE[dcr]: Obtained estimate for 1-conf fee rate, 10
2022-12-15 00:36:46.931 [INF] CORE: Broadcasted redeem transaction spending 1 contracts for order 5514e2b0a5cd1c0059a0dc3de03441985dacc27fc1a0746d35af9370a623dcac, paying to bd2c17ab74ea2bd47ba554210188124517f7d138fc4a6a611ede376681afd09b:0 (dcr)
2022-12-15 00:36:46.932 [INF] CORE: Match 24d55c264b1ae28b0b9af8132e6ddd151ec9e5b70e90116d700b2a2dd7e234c3 complete: buy 200000000 dcr
2022-12-15 00:36:46.933 [INF] CORE: Notifying DEX dextesttaggpdj27s26wklczemovhqdzyvgokyumey33uemlw4imawqd.onion:7232 of our dcr swap redemption bd2c17ab74ea2bd47ba554210188124517f7d138fc4a6a611ede376681afd09b:0 for match 24d55c264b1ae28b0b9af8132e6ddd151ec9e5b70e90116d700b2a2dd7e234c3
2022-12-15 00:36:46.933 [DBG] CORE: notify: |POKE| (order) Match complete - Redeemed 2.00000000 DCR on order 5514e2b0 - Order: 5514e2b0a5cd1c0059a0dc3de03441985dacc27fc1a0746d35af9370a623dcac
2022-12-15 00:36:46.963 [TRC] CORE: notify: |DATA| (balance) balance updated
2022-12-15 00:36:47.358 [TRC] CORE: notify: |DATA| (balance) balance updated
2022-12-15 00:36:47.444 [TRC] CORE: notify: |DATA| (balance) balance updated
2022-12-15 00:36:47.519 [DBG] CORE[dcr]: tip change: 1048109 (00000000107e6cc423ab69274d44b252c926783e6fe5c9df3281def684cb94cb) => 1048110 (0000000075fa1ace33b994f55fd5c5bd16f5e67bb712b94268ddaaa2d1dfdea4)
2022-12-15 00:36:47.519 [TRC] CORE: Processing tip change for dcr
2022-12-15 00:36:47.544 [TRC] CORE: notify: |DATA| (balance) balance updated
2022-12-15 00:36:50.814 [DBG] CORE: Received valid ack for 'redeem' request for match 24d55c264b1ae28b0b9af8132e6ddd151ec9e5b70e90116d700b2a2dd7e234c3)
2022-12-15 00:36:50.814 [INF] CORE: Notified of maker's redemption (dcr: bd2c17ab74ea2bd47ba554210188124517f7d138fc4a6a611ede376681afd09b:0) and validated secret for order b23a23514b4ac05246537225e87924e51c27f3d8a96eddcc706d100ba816f111...
2022-12-15 00:36:50.816 [DBG] CORE: Redeemable match 24d55c264b1ae28b0b9af8132e6ddd151ec9e5b70e90116d700b2a2dd7e234c3 for order b23a23514b4ac05246537225e87924e51c27f3d8a96eddcc706d100ba816f111 (Taker)
2022-12-15 00:36:52.617 [TRC] CORE[eth][ETH][RPC]: using cached header from "rpc.ankr.com"
2022-12-15 00:36:53.047 [TRC] CORE[eth][ETH][RPC]: using cached header from "rpc.ankr.com"
2022-12-15 00:36:54.423 [TRC] CORE[eth][ETH][RPC]: Sending signed tx via "rpc.ankr.com"
2022-12-15 00:36:55.042 [INF] CORE: Broadcasted redeem transaction spending 1 contracts for order b23a23514b4ac05246537225e87924e51c27f3d8a96eddcc706d100ba816f111, paying to 0x736e6a3ff53534046f05e9ed1bf16dc606efd69e3482caf54c94f13dadc336b2 (usdc.eth)
2022-12-15 00:36:55.043 [INF] CORE: Match 24d55c264b1ae28b0b9af8132e6ddd151ec9e5b70e90116d700b2a2dd7e234c3 complete: sell 200000000 dcr
2022-12-15 00:36:55.044 [INF] CORE: Notifying DEX dextesttaggpdj27s26wklczemovhqdzyvgokyumey33uemlw4imawqd.onion:7232 of our usdc.eth swap redemption 0x736e6a3ff53534046f05e9ed1bf16dc606efd69e3482caf54c94f13dadc336b2 for match 24d55c264b1ae28b0b9af8132e6ddd151ec9e5b70e90116d700b2a2dd7e234c3
2022-12-15 00:36:55.044 [DBG] CORE: notify: |POKE| (order) Match complete - Redeemed 42.580000 USDC on order b23a2351 - Order: b23a23514b4ac05246537225e87924e51c27f3d8a96eddcc706d100ba816f111
2022-12-15 00:36:55.044 [DBG] CORE: Slow tick: trade b23a23514b4ac05246537225e87924e51c27f3d8a96eddcc706d100ba816f111 processed in 4.227939311s, blocked for 210ns
2022-12-15 00:36:55.044 [INF] CORE: runJob(match_proof) completed in 755.477414ms
2022-12-15 00:36:55.067 [TRC] CORE: notify: |DATA| (balance) balance updated
2022-12-15 00:36:55.484 [TRC] CORE: notify: |DATA| (balance) balance updated
2022-12-15 00:36:57.474 [TRC] CORE[eth][ETH][RPC]: fetching fresh header from "rpc.ankr.com"
2022-12-15 00:36:59.069 [TRC] CORE: Received a courtesy redemption request for match 24d55c264b1ae28b0b9af8132e6ddd151ec9e5b70e90116d700b2a2dd7e234c3 as maker
2022-12-15 00:36:59.070 [DBG] CORE: Received valid ack for 'redeem' request for match 24d55c264b1ae28b0b9af8132e6ddd151ec9e5b70e90116d700b2a2dd7e234c3)
...
2022-12-15 00:37:08.928 [TRC] CORE: Processing tip change for usdc.eth
2022-12-15 00:37:08.928 [TRC] CORE: Processing tip change for eth
2022-12-15 00:37:09.524 [TRC] CORE: notify: |DATA| (balance) balance updated
2022-12-15 00:37:10.617 [DBG] CORE: Slow tick: trade b23a23514b4ac05246537225e87924e51c27f3d8a96eddcc706d100ba816f111 processed in 1.688640682s, blocked for 285ns
...
2022-12-15 00:39:09.474 [TRC] CORE[eth][ETH][RPC]: fetching fresh header from "rpc.ankr.com"
2022-12-15 00:39:09.918 [DBG] CORE[eth][ETH]: tip change: 8136537 (0x69d069b4a911f83e1a03a9a4701505146cfcfec4f898342494743eb7db34f658) => 8136538 (0xb7aa7677a3a8ea29f192ff0bd5f7c9c3fdafa3c375cfead03888c8949099a94d)
2022-12-15 00:39:09.918 [TRC] CORE: Processing tip change for usdc.eth
2022-12-15 00:39:09.918 [TRC] CORE: Processing tip change for eth
2022-12-15 00:39:10.378 [TRC] CORE: notify: |DATA| (balance) balance updated
2022-12-15 00:39:11.291 [INF] CORE: notify: |SUCCESS| (match) Redemption Confirmed - Your redemption for match 24d55c26 in order b23a2351 was confirmed
2022-12-15 00:39:11.291 [DBG] CORE: Slow tick: trade b23a23514b4ac05246537225e87924e51c27f3d8a96eddcc706d100ba816f111 processed in 1.372469443s, blocked for 275ns
2022-12-15 00:39:11.706 [TRC] CORE: notify: |DATA| (balance) balance updated
Ticks are slow. To be expected with a remote provider I suppose, but it backs up the tick loop and trades have to wait on eachother.
Did a second swap with maker/taker switched:
The /api/maxbuy
and /api/preorder
endpoints were extremely slow:
2022-12-15 00:33:43.159 [INF] CORE[eth][USDC.ETH]: MaxOrder reducing lots because of low fee reserves: 22 -> 2
2022/12/14 18:33:43 "POST http://127.0.0.2:5758/api/maxbuy HTTP/1.1" from 127.0.0.1:38366 - 200 198B in 2.490447686s
2022-12-15 00:33:46.367 [INF] CORE[eth][USDC.ETH]: MaxOrder reducing lots because of low fee reserves: 22 -> 2
2022/12/14 18:33:47 "POST http://127.0.0.2:5758/api/preorder HTTP/1.1" from 127.0.0.1:38366 - 200 723B in 3.39130873s
We'll have to look into that. It's going to be a problem. The UX is already poor with a long wait to submit an order.
what |
Indeed. https://goerli.etherscan.io/tx/0x48405dbc89186d126b34f48d7b32063630a2733bca558dbe28f25aca7fac4aef |
Was reading the relevant code, noticed that answer could be because it is directly using this constant value: |
Contract tests passing but some other's are not. Will update this comment at some point.
depends on #1622depends on #1832closes #1724