Sanity test swaps #676
Comments
|
Nice! So for the LTC/BTC pair we would swap:
during the handshake and upon success all continues as of now? How about a failure? We'd need a feature to disable a certain trading pair with a peer. If all pairs fail, disconnect. |
|
By such check we can learn that there is a BTC route from me to peer and there is an LTC route from the peer to me. Once we do that we are sure about routing and we are sure about resolver setup. This is a very good start as it will handle the situation we have with xud1 which is not setup properly. What will be missing is capacity check. Also, I'm not sure about doing this as part of the handshake. We should mimic full swap including the request/response/error P2P packets. Suggest to kick this as a task after the handshake is done. What should we do if we are not properly connected to LND? |
The proposal was to swap 1 satoshi for 1 satoshi and 1 litoshi for 1 litoshi to test the setup. Question: can we currently even support this? Resolver wouldn't be involved? @offerm
Ok, but then we would need a whole new logic to take care of disabling/enabling pairs for peers. But you are right, we shouldn't only run this test once on handshake.
Throw an error through gRPC and disadvertise all trading pairs with swap rptocol LND. Also disable all peerOrders with swap protocol LND. Complicated. |
|
I don't think we currently support BTC to BTC swap. Nothing is missing on the resolver side but XUD is not ready for it (I think). I was thinking about trying a swap for real. So when I accept a connection, I can play the role of a taker and try to swap LTC to BTC with the peer. This test swap will not complete with success. It will be set in a rate that will cause me to reject it when I accept the BTC. Checking the route between me and the peer can also be done my making a payment with an r_hash that the peer can't resolve. based on the response we can analyze if there is a route or not. So, I suggest we start by defining what we want to check :-) For the second part, I think that when LND is not connected properly we can't participate in the XUD network. So we basically need to disconnect and wait for LND to come back. If you agree, we should make this a seperate issue. |
Oh, controlled failing of the swap indeed would be a great ozption! Just have to take care HOW we let the swap fail. E.g. a wrong rate could result in a negative reputation event at some point. Also knowing this, the maker could just accept the rate and exploit the situation by letting the swap succeed. I'd prefer a safer way to gracefully cancel the trade right before pre-image release. We want to check full swap capability, not only parts of it (like a payment route). Also we want to do it for all trading pairs (both directions) of NEW peers (I'd prefer handshake, but tbd) as well as regular checks for connected peers (tbd). Still we would want to categorize different kind of swap failures and deal with them (#661 (comment)) Scope of this issue:
|
Opened a separate issue. I wouldn't want to just disconnect from all peers if LND fails, because we still have raiden and others in future. We can add a check that if all enabled SWAP clients are offline, we can just disconnect which would trigger a disconnect in our current situation since we have LND only. |
|
I was thinking of swapping the smallest amount of one currency for another, a true cross-chain swap. If we can do swaps of the same currency without making it more complicated that would be fine too, better even.
What's your concern with doing it as part of the handshake? What alternative do you have in mind? I think handshake makes sense because that's when peers advertise the pairs they support and it's a good time to verify that they actually can send and receive payments for those currencies. |
|
That should be possible, right? @sangaman Anything else still open to be discussed? |
|
I'm not sure I'm following, why would we want to cancel the sanity test swap? It should be possible to do up until the preimage release, though. |
To avoid abuse.
That's what I thought. |
|
For planning: PR for this one is more or less ready, right? @sangaman |
sangaman
added a commit
that referenced
this issue
Mar 5, 2019
This is a major commit that changes the procedure for accepting orders from peers to ensure that we can send and receive payments for both currencies that make up the order's trading pair. This introduces the concept of "sanity swaps," which are atomic swaps of 1 satoshi for 1 satoshi within a single currency/chain. The flow for atomic swaps is as follows: 1. A connection is established with a peer. 2. The handshake is performed successfully. 3. A `SanitySwapPacket` will be sent to the peer to request that they initiate a sanity swap for each currency the appears in the peer's trading pairs advertised in the `nodeState`. Simultaneously, the peer may also send us `SanitySwapPackets` depending on our advertised pairs. We begin listening for events indicating that the requested sanity swap has succeeded (or failed) 4. Upon receiving a `SanitySwapPacket`, we generate a payment preimage and hash and send a 1 satoshi payment to the peer for the hash. 5. Upon receiving our 1 satoshi payment, the peer attempts to learn the preimage by sending a 1 satoshi payment to us. 6. We release the preimage that we created, effectively settling the swap. 7. After all sanity swaps resolve, we check which advertised pairs had successful swaps for both the base and quote currency. 8. These pairs are marked "active" and we send a `GetOrdersPacket` for the newly active pairs. Other notable changes include: - Tracking "active" pairs on a per-peer basis. "Active" pairs are those that have been advertised by a peer's node state, which we have been able to successfully perform a sanity swap for, and which have not encountered unexpected payment errors from our perspective. - Not requesting all orders via a `GetOrdersPacket` automatically upon a successful connection and handshake. - Ignoring order packets we receive for trading pairs that are not active. Closes #676.
sangaman
added a commit
that referenced
this issue
Mar 5, 2019
This is a major commit that changes the procedure for accepting orders from peers to ensure that we can send and receive payments for both currencies that make up the order's trading pair. This introduces the concept of "sanity swaps," which are atomic swaps of 1 satoshi for 1 satoshi within a single currency/chain. The flow for atomic swaps is as follows: 1. A connection is established with a peer. 2. The handshake is performed successfully. 3. A `SanitySwapPacket` will be sent to the peer to request that they initiate a sanity swap for each currency the appears in the peer's trading pairs advertised in the `nodeState`. Simultaneously, the peer may also send us `SanitySwapPackets` depending on our advertised pairs. We begin listening for events indicating that the requested sanity swap has succeeded (or failed) 4. Upon receiving a `SanitySwapPacket`, we generate a payment preimage and hash and send a 1 satoshi payment to the peer for the hash. 5. Upon receiving our 1 satoshi payment, the peer attempts to learn the preimage by sending a 1 satoshi payment to us. 6. We release the preimage that we created, effectively settling the swap. 7. After all sanity swaps resolve, we check which advertised pairs had successful swaps for both the base and quote currency. 8. These pairs are marked "active" and we send a `GetOrdersPacket` for the newly active pairs. Other notable changes include: - Tracking "active" pairs on a per-peer basis. "Active" pairs are those that have been advertised by a peer's node state, which we have been able to successfully perform a sanity swap for, and which have not encountered unexpected payment errors from our perspective. - Not requesting all orders via a `GetOrdersPacket` automatically upon a successful connection and handshake. - Ignoring order packets we receive for trading pairs that are not active. Closes #676. BREAKING CHANGE: New SanitySwapPacket.
sangaman
added a commit
that referenced
this issue
Mar 18, 2019
This is a major commit that changes the procedure for accepting orders from peers to ensure that we can send and receive payments for both currencies that make up the order's trading pair. This introduces the concept of "sanity swaps," which are atomic swaps of 1 satoshi for 1 satoshi within a single currency/chain. The flow for atomic swaps is as follows: 1. A connection is established with a peer. 2. The handshake is performed successfully. 3. A `SanitySwapPacket` will be sent to the peer to request that they initiate a sanity swap for each currency the appears in the peer's trading pairs advertised in the `nodeState`. Simultaneously, the peer may also send us `SanitySwapPackets` depending on our advertised pairs. We begin listening for events indicating that the requested sanity swap has succeeded (or failed) 4. Upon receiving a `SanitySwapPacket`, we generate a payment preimage and hash and send a 1 satoshi payment to the peer for the hash. 5. Upon receiving our 1 satoshi payment, the peer attempts to learn the preimage by sending a 1 satoshi payment to us. 6. We release the preimage that we created, effectively settling the swap. 7. After all sanity swaps resolve, we check which advertised pairs had successful swaps for both the base and quote currency. 8. These pairs are marked "active" and we send a `GetOrdersPacket` for the newly active pairs. Other notable changes include: - Tracking "active" pairs on a per-peer basis. "Active" pairs are those that have been advertised by a peer's node state, which we have been able to successfully perform a sanity swap for, and which have not encountered unexpected payment errors from our perspective. - Not requesting all orders via a `GetOrdersPacket` automatically upon a successful connection and handshake. - Ignoring order packets we receive for trading pairs that are not active. Closes #676. BREAKING CHANGE: New SanitySwapPacket.
sangaman
added a commit
that referenced
this issue
Mar 18, 2019
This is a major commit that changes the procedure for accepting orders from peers to ensure that we can send and receive payments for both currencies that make up the order's trading pair. This introduces the concept of "sanity swaps," which are atomic swaps of 1 satoshi for 1 satoshi within a single currency/chain. The flow for atomic swaps is as follows: 1. A connection is established with a peer. 2. The handshake is performed successfully. 3. A `SanitySwapPacket` will be sent to the peer to inform them of a sanity swap attempt for each currency the appears in the peer's trading pairs advertised in the `nodeState`. Simultaneously, the peer may also send us `SanitySwapPackets` depending on our advertised pairs. We begin listening for events indicating that the requested sanity swap has succeeded (or failed) 4. We send a 1 satoshi payment to the peer for each sanity swap. 5. Upon receiving our 1 satoshi payment, the peer attempts to learn the preimage by sending a 1 satoshi payment to us. 6. We release the preimage that we created, effectively settling the swap. 7. After all sanity swaps resolve, we check which advertised pairs had successful swaps for both the base and quote currency. 8. These pairs are marked "active" and we send a `GetOrdersPacket` for the newly active pairs. Other notable changes include: - Tracking "active" pairs on a per-peer basis. "Active" pairs are those that have been advertised by a peer's node state, which we have been able to successfully perform a sanity swap for, and which have not encountered unexpected payment errors from our perspective. - Not requesting all orders via a `GetOrdersPacket` automatically upon a successful connection and handshake. - Ignoring order packets we receive for trading pairs that are not active. Closes #676. BREAKING CHANGE: New SanitySwapPacket.
sangaman
added a commit
that referenced
this issue
Mar 19, 2019
This is a major commit that changes the procedure for accepting orders from peers to ensure that we can send and receive payments for both currencies that make up the order's trading pair. This introduces the concept of "sanity swaps," which are atomic swaps of 1 satoshi for 1 satoshi within a single currency/chain. The flow for atomic swaps is as follows: 1. A connection is established with a peer. 2. The handshake is performed successfully. 3. A `SanitySwapPacket` will be sent to the peer to inform them of a sanity swap attempt for each currency the appears in the peer's trading pairs advertised in the `nodeState`. Simultaneously, the peer may also send us `SanitySwapPackets` depending on our advertised pairs. We begin listening for events indicating that the requested sanity swap has succeeded (or failed) 4. We send a 1 satoshi payment to the peer for each sanity swap. 5. Upon receiving our 1 satoshi payment, the peer attempts to learn the preimage by sending a 1 satoshi payment to us. 6. We release the preimage that we created, effectively settling the swap. 7. After all sanity swaps resolve, we check which advertised pairs had successful swaps for both the base and quote currency. 8. These pairs are marked "active" and we send a `GetOrdersPacket` for the newly active pairs. Other notable changes include: - Tracking "active" pairs on a per-peer basis. "Active" pairs are those that have been advertised by a peer's node state, which we have been able to successfully perform a sanity swap for, and which have not encountered unexpected payment errors from our perspective. - Not requesting all orders via a `GetOrdersPacket` automatically upon a successful connection and handshake. - Ignoring order packets we receive for trading pairs that are not active. - The `ListPeers` rpc call only returns active trading pairs. Closes #676. BREAKING CHANGE: New SanitySwapPacket.
sangaman
added a commit
that referenced
this issue
Apr 18, 2019
This is a major commit that changes the procedure for accepting orders from peers to ensure that we can send and receive payments for both currencies that make up the order's trading pair. This introduces the concept of "sanity swaps," which are atomic swaps of 1 satoshi for 1 satoshi within a single currency/chain. The flow for atomic swaps is as follows: 1. A connection is established with a peer. 2. The handshake is performed successfully. 3. A `SanitySwapPacket` will be sent to the peer to inform them of a sanity swap attempt for each currency the appears in the peer's trading pairs advertised in the `nodeState`. Simultaneously, the peer may also send us `SanitySwapPackets` depending on our advertised pairs. We begin listening for events indicating that the requested sanity swap has succeeded (or failed) 4. We send a 1 satoshi payment to the peer for each sanity swap. 5. Upon receiving our 1 satoshi payment, the peer attempts to learn the preimage by sending a 1 satoshi payment to us. 6. We release the preimage that we created, effectively settling the swap. 7. After all sanity swaps resolve, we check which advertised pairs had successful swaps for both the base and quote currency. 8. These pairs are marked "active" and we send a `GetOrdersPacket` for the newly active pairs. Other notable changes include: - Tracking "active" pairs on a per-peer basis. "Active" pairs are those that have been advertised by a peer's node state, which we have been able to successfully perform a sanity swap for, and which have not encountered unexpected payment errors from our perspective. - Not requesting all orders via a `GetOrdersPacket` automatically upon a successful connection and handshake. - Ignoring order packets we receive for trading pairs that are not active. - The `ListPeers` rpc call only returns active trading pairs. Closes #676. BREAKING CHANGE: New SanitySwapPacket.
sangaman
added a commit
that referenced
this issue
Apr 18, 2019
This is a major commit that changes the procedure for accepting orders from peers to ensure that we can send and receive payments for both currencies that make up the order's trading pair. This introduces the concept of "sanity swaps," which are atomic swaps of 1 satoshi for 1 satoshi within a single currency/chain. The flow for atomic swaps is as follows: 1. A connection is established with a peer. 2. The handshake is performed successfully. 3. A `SanitySwapPacket` will be sent to the peer to inform them of a sanity swap attempt for each currency the appears in the peer's trading pairs advertised in the `nodeState`. Simultaneously, the peer may also send us `SanitySwapPackets` depending on our advertised pairs. We begin listening for events indicating that the requested sanity swap has succeeded (or failed) 4. We send a 1 satoshi payment to the peer for each sanity swap. 5. Upon receiving our 1 satoshi payment, the peer attempts to learn the preimage by sending a 1 satoshi payment to us. 6. We release the preimage that we created, effectively settling the swap. 7. After all sanity swaps resolve, we check which advertised pairs had successful swaps for both the base and quote currency. 8. These pairs are marked "active" and we send a `GetOrdersPacket` for the newly active pairs. Other notable changes include: - Tracking "active" pairs on a per-peer basis. "Active" pairs are those that have been advertised by a peer's node state, which we have been able to successfully perform a sanity swap for, and which have not encountered unexpected payment errors from our perspective. - Not requesting all orders via a `GetOrdersPacket` automatically upon a successful connection and handshake. - Ignoring order packets we receive for trading pairs that are not active. - The `ListPeers` rpc call only returns active trading pairs. Closes #676. BREAKING CHANGE: New SanitySwapPacket.
sangaman
added a commit
that referenced
this issue
Apr 18, 2019
This is a major commit that changes the procedure for accepting orders from peers to ensure that we can send and receive payments for both currencies that make up the order's trading pair. This introduces the concept of "sanity swaps," which are atomic swaps of 1 smallest unit for 1 smallest unit within a single currency/chain. The flow for atomic swaps is as follows: 1. A connection is established with a peer. 2. The handshake is performed successfully. 3. A `SanitySwapPacket` will be sent to the peer to inform them of a sanity swap attempt for each currency the appears in the peer's trading pairs advertised in the `nodeState`. 4. We send a 1 satoshi payment to the peer for each sanity swap. 5. Upon receiving our 1 satoshi payment, the peer attempts to learn the preimage by sending a 1 satoshi payment to us. 6. We release the preimage that we created, effectively settling the swap. 7. After all sanity swaps resolve, we check which advertised pairs had successful swaps for both the base and quote currency. 8. These pairs are marked "active" and we send a `GetOrdersPacket` for the newly activated pairs. Other notable changes include: - Tracking "active" pairs on a per-peer basis. "Active" pairs are those that have been advertised by a peer's node state, which we have been able to successfully perform a sanity swap for, and which have not encountered unexpected payment errors from our perspective. - Not requesting all orders via a `GetOrdersPacket` automatically upon a successful connection and handshake. - Ignoring order packets we receive for trading pairs that are not active. - The `ListPeers` rpc call only returns active trading pairs. - Sanity swaps can be disabled via the `nosanitychecks` config option. Closes #676. BREAKING CHANGE: New SanitySwapPacket.
sangaman
added a commit
that referenced
this issue
Apr 18, 2019
This is a major commit that changes the procedure for accepting orders from peers to ensure that we can send and receive payments for both currencies that make up the order's trading pair. This introduces the concept of "sanity swaps," which are atomic swaps of 1 smallest unit for 1 smallest unit within a single currency/chain. The flow for atomic swaps is as follows: 1. A connection is established with a peer. 2. The handshake is performed successfully. 3. A `SanitySwapPacket` will be sent to the peer to inform them of a sanity swap attempt for each currency the appears in the peer's trading pairs advertised in the `nodeState`. 4. We send a 1 satoshi payment to the peer for each sanity swap. 5. Upon receiving our 1 satoshi payment, the peer attempts to learn the preimage by sending a 1 satoshi payment to us. 6. We release the preimage that we created, effectively settling the swap. 7. After all sanity swaps resolve, we check which advertised pairs had successful swaps for both the base and quote currency. 8. These pairs are marked "active" and we send a `GetOrdersPacket` for the newly activated pairs. Other notable changes include: - Tracking "active" pairs on a per-peer basis. "Active" pairs are those that have been advertised by a peer's node state, which we have been able to successfully perform a sanity swap for, and which have not encountered unexpected payment errors from our perspective. - Not requesting all orders via a `GetOrdersPacket` automatically upon a successful connection and handshake. - Ignoring order packets we receive for trading pairs that are not active. - The `ListPeers` rpc call only returns active trading pairs. - Sanity swaps can be disabled via the `nosanitychecks` config option. Closes #676. BREAKING CHANGE: New SanitySwapPacket.
sangaman
added a commit
that referenced
this issue
Apr 18, 2019
This is a major commit that changes the procedure for accepting orders from peers to ensure that we can send and receive payments for both currencies that make up the order's trading pair. This introduces the concept of "sanity swaps," which are atomic swaps of 1 smallest unit for 1 smallest unit within a single currency/chain. The flow for atomic swaps is as follows: 1. A connection is established with a peer. 2. The handshake is performed successfully. 3. A `SanitySwapPacket` will be sent to the peer to inform them of a sanity swap attempt for each currency the appears in the peer's trading pairs advertised in the `nodeState`. 4. We send a 1 satoshi payment to the peer for each sanity swap. 5. Upon receiving our 1 satoshi payment, the peer attempts to learn the preimage by sending a 1 satoshi payment to us. 6. We release the preimage that we created, effectively settling the swap. 7. After all sanity swaps resolve, we check which advertised pairs had successful swaps for both the base and quote currency. 8. These pairs are marked "active" and we send a `GetOrdersPacket` for the newly activated pairs. Other notable changes include: - Tracking "active" pairs on a per-peer basis. "Active" pairs are those that have been advertised by a peer's node state, which we have been able to successfully perform a sanity swap for, and which have not encountered unexpected payment errors from our perspective. - Not requesting all orders via a `GetOrdersPacket` automatically upon a successful connection and handshake. - Ignoring order packets we receive for trading pairs that are not active. - The `ListPeers` rpc call only returns active trading pairs. - Sanity swaps can be disabled via the `nosanitychecks` config option. Closes #676. BREAKING CHANGE: New SanitySwapPacket.
sangaman
added a commit
that referenced
this issue
Apr 24, 2019
This is a major commit that changes the procedure for accepting orders from peers to ensure that we can send and receive payments for both currencies that make up the order's trading pair. This introduces the concept of "sanity swaps," which are atomic swaps of 1 smallest unit for 1 smallest unit within a single currency/chain. The flow for atomic swaps is as follows: 1. A connection is established with a peer. 2. The handshake is performed successfully. 3. A `SanitySwapPacket` will be sent to the peer to inform them of a sanity swap attempt for each currency the appears in the peer's trading pairs advertised in the `nodeState`. 4. We send a 1 satoshi payment to the peer for each sanity swap. 5. Upon receiving our 1 satoshi payment, the peer attempts to learn the preimage by sending a 1 satoshi payment to us. 6. We release the preimage that we created, effectively settling the swap. 7. After all sanity swaps resolve, we check which advertised pairs had successful swaps for both the base and quote currency. 8. These pairs are marked "active" and we send a `GetOrdersPacket` for the newly activated pairs. Other notable changes include: - Tracking "active" pairs on a per-peer basis. "Active" pairs are those that have been advertised by a peer's node state, which we have been able to successfully perform a sanity swap for, and which have not encountered unexpected payment errors from our perspective. - Not requesting all orders via a `GetOrdersPacket` automatically upon a successful connection and handshake. - Ignoring order packets we receive for trading pairs that are not active. - The `ListPeers` rpc call only returns active trading pairs. - Sanity swaps can be disabled via the `nosanitychecks` config option. Closes #676. BREAKING CHANGE: New SanitySwapPacket.
sangaman
added a commit
that referenced
this issue
Apr 24, 2019
This is a major commit that changes the procedure for accepting orders from peers to ensure that we can send and receive payments for both currencies that make up the order's trading pair. This introduces the concept of "sanity swaps," which are atomic swaps of 1 smallest unit for 1 smallest unit within a single currency/chain. The flow for atomic swaps is as follows: 1. A connection is established with a peer. 2. The handshake is performed successfully. 3. A `SanitySwapPacket` will be sent to the peer to inform them of a sanity swap attempt for each currency the appears in the peer's trading pairs advertised in the `nodeState`. 4. We send a 1 satoshi payment to the peer for each sanity swap. 5. Upon receiving our 1 satoshi payment, the peer attempts to learn the preimage by sending a 1 satoshi payment to us. 6. We release the preimage that we created, effectively settling the swap. 7. After all sanity swaps resolve, we check which advertised pairs had successful swaps for both the base and quote currency. 8. These pairs are marked "active" and we send a `GetOrdersPacket` for the newly activated pairs. Other notable changes include: - Tracking "active" pairs on a per-peer basis. "Active" pairs are those that have been advertised by a peer's node state, which we have been able to successfully perform a sanity swap for, and which have not encountered unexpected payment errors from our perspective. - Not requesting all orders via a `GetOrdersPacket` automatically upon a successful connection and handshake. - Ignoring order packets we receive for trading pairs that are not active. - The `ListPeers` rpc call only returns active trading pairs. - Sanity swaps can be disabled via the `nosanitychecks` config option. Closes #676. BREAKING CHANGE: New SanitySwapPacket.
sangaman
added a commit
that referenced
this issue
Apr 25, 2019
This is a major commit that changes the procedure for accepting orders from peers to ensure that we can send and receive payments for both currencies that make up the order's trading pair. This introduces the concept of "sanity swaps," which are atomic swaps of 1 smallest unit for 1 smallest unit within a single currency/chain. The flow for atomic swaps is as follows: 1. A connection is established with a peer. 2. The handshake is performed successfully. 3. A `SanitySwapPacket` will be sent to the peer to inform them of a sanity swap attempt for each currency the appears in the peer's trading pairs advertised in the `nodeState`. 4. We send a 1 satoshi payment to the peer for each sanity swap. 5. Upon receiving our 1 satoshi payment, the peer attempts to learn the preimage by sending a 1 satoshi payment to us. 6. We release the preimage that we created, effectively settling the swap. 7. After all sanity swaps resolve, we check which advertised pairs had successful swaps for both the base and quote currency. 8. These pairs are marked "active" and we send a `GetOrdersPacket` for the newly activated pairs. Other notable changes include: - Tracking "active" pairs on a per-peer basis. "Active" pairs are those that have been advertised by a peer's node state, which we have been able to successfully perform a sanity swap for, and which have not encountered unexpected payment errors from our perspective. - Not requesting all orders via a `GetOrdersPacket` automatically upon a successful connection and handshake. - Ignoring order packets we receive for trading pairs that are not active. - The `ListPeers` rpc call only returns active trading pairs. - Sanity swaps can be disabled via the `nosanitychecks` config option. Closes #676. BREAKING CHANGE: New SanitySwapPacket.
ghost
closed this as This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is an offshoot from discussion is #661. We might want to do a test swap (1 satoshi for 1 satoshi, or maybe even 1 msat for 1 msat if possible) for each trading pair that is active with a peer (or maybe two test swaps, with each side sending and receiving both pairs). This will verify that routes exist and lnd is properly set up on both sides, and rule out a lot of the problems that might cause swaps to fail.
I'm thinking that this can be part of the handshake process when we connect to a peer. @offerm asked whether we should do it each time we get an order from a peer. I think that could possibly be a little over the top, as we could easily wind up increasing the number of swaps we're making by an order of magnitude or two if we're connected to a lot of peers. I think the benefit is also pretty limited, particularly if we've just had a successful test swap a few seconds earlier. #675 though proposes that we do a
queryroutescheck for each order we receive, which I think is less burdensome and also possibly more helpful since we can see if a route exists for large orders which we don't check with a 1 satoshi test swap.The text was updated successfully, but these errors were encountered: