For those of you not on twitter / Discord, @georgezgeorgez is done with the HTLC code. I think he still needs the Spork ID.
4 Likes
Ez, this is our second spork (i think), hardcode id #2, and hope the alien tech holds up.
1 Like
@georgezgeorgez found some minor typos.
Line 75
- “DenyProxyUnlock” as codeblock
- “Proxy Unlock” without space
Line 84
- “AllowProxyUnlock” as codeblock
- “Proxy Unlock” without space
Line 193
- “as soon as soon as” should be “as soon as”
Line 230
- "“Embedded Withdraw” has missing end quote.
None of the contract methods currently implemented can be used to spam the network without costs. Whereas the HTLC contract offers the possibility to spam the network for only the cost of 1 znn.
One might create a ZTS token and use the token to create HTLCs. A simple stress test confirmed one can do the following:
- Spam the network with transactions
- Render someones wallet useless (wallet with atomic swaps feature)
Same for AZ submissions, no?
If a malicious actor feels the need to spam the network, that’s their prerogative.
This course of action is generally meaningless.
The UI/UX is being re-designed to mitigate unsolicited spam.
Since users are coordinating swap details out-of-band, they will manually add legitimate swaps in the wallet.
Any auto-discovery mechanism we implement can likely be abused.
There’s a greater cost to spam these.
1 ZNN per AZ submission vs 1 ZNN for near-infinite HTLCs
2 Likes
@CryptoFish We had a discussion about this with Sol and even with the redesign there appears to be no way around the fact that Syrius will have to parse all HTLC contract transactions when it’s scanning for a preimage.
We can set an arbitrary limit on how far back Syrius will parse these transactions for the preimage. It could be 24 hours for example (because that’s the longest expiration time Syrius offers) and this would mean Syrius would have to parse a substantial amount of transactions even with current network limitations.
I don’t know how long parsing those transactions would take, but it could put a lot of strain on public nodes and unfortunately it does seem like the swap’s counterparty is incentivized to spam the HTLC contract to make it hard for the other party to find the preimage.
We can’t monitor the counterparty’s account chain for the preimage (unlock transaction) because they might intentionally use another address and use proxy unlock.
I want to make sure I understand this.
Bob locks 69 ZNN in HTLC for Alice
Alice locks 420 QSR in HTLC for Bob
Bob claims 420 QSR and exposes the preimage to Alice
Then Bob can spam the HTLC Contract making it difficult for Alice to find the preimage to claim the 69 ZNN? Is that correct?
If the time expires on the HTLC and Alice does not claim the 69 ZNN, can Bob reclaim the 69 ZNN he originally locked up for Alice?
Pretty much yes that’s what could happen. Bob could then easily reclaim the funds that were meant for Alice.
Alice closes her wallet/goes to bed/whatever and during that time Bob unlocks the HTLC and proceeds to spam the HTLC contract with junk transactions. Then Alice comes back and reopens her wallet hours later to claim her side of the swap but Syrius will have to parse through all of the junk transactions Bob has sent.
I think it is possible that the amount of these transactions could be so great that it could take a considerable amount of time to parse through them. At the very least it could strain public nodes a lot. The public node going down or giving slow responses in that situation would not be good for Alice if she’s using one.
We would have to do some benchmarking on what the perfomance would be like in this type of situation to get a better understanding.
How does he spam the contract?
- Can we make it increasingly more difficult to do that with dynamic plasma somehow? George indicated he is working on that next.
- Can we block the spam at the contract level after Bob has unlocked the 420 QSR and exposed the preimage?
Just thinking out loud w/out know the technical details.
CryptoFish mentioned this earlier here. Bob could create a ZTS token and then use that token to create a large amount of HTLCs.
If Bob is loaded with QSR he would probably have enough Plasma to cause enough spam for it to potentially be a problem. I’m not too familiar with the details of how dynamic plasma would work though.
I don’t see how we could block that entirely. Bob could use any address/addresses to spam the contract. Something like having to lock 1 ZNN to create an HTLC (that you’d get back when the HTLC is unlocked) could be one way to mitigate the spam.
2 Likes
looks like this is an attack vector if someone just wants to attack the network too and make HTLCs slow or not possible to do.
Current s y r i u s implementation aside.
I don’t know how long parsing those transactions would take
I think it boils down to how much of a problem scanning is. If it’s too slow or a big strain on the public nodes, some form caching could help us out. Htlc spamming only creates a lot of tx’s and poses no problem if scanning tx’s is fast enough. The spammer even speeds things up If using the same hashlock. Htlc spamming is not a htlc specific problem and can be considered as spamming the network. Something dynamic plasma could solve.
So if dynamic plasma solves general spamming of the network, you’re left with an efficient scanning impl.
Yes for atomic swaps I think that’s what it boils down to. I’ll do some testing on this.
But I think it is a unique problem to atomic swaps because the client has to parse every single transaction that is made to the HTLC contract during the duration of the swap. No other use case requires that right now. If someone is otherwise spamming the network a client doesn’t have to parse all those transactions.
1 Like
We are discussing this issue in two locations. I wanted to share Gorg’s feedback from Discord so others can see it.
“if the problem is, “can wallets handle bursts of scanning txs” this solution is to spread the scanning out as the txs come in any application which relies on timelocks will have the same problem”
“if the problem is, “can wallets handle bursts of scanning txs” this solution is to spread the scanning out as the txs come in any application which relies on timelocks will have the same problem”
" without htlcs, a user can already attack a public rpc node by requesting pages and pages of txs any sort of public rpc node that wants to serve public rpc (without any incentive) will likely to need a reverse proxy with some middleware to throttle rpc calls"
Regarding the last comment, I have been looking into setting up a HA cluster where the cluster does RPC health checks to route. So the load balancer would throttle requests and perform health checks to make sure each node is synced before routing requests. I found a project that does it for ETH nodes.
1 Like
Okay I took some benchmarks with Dart for fetching and parsing a large amount of transactions.
Using a local node
Fetched & decoded 200k account blocks.
Total time: 1min 20s
Using a remote node
Fetched & decoded 200k account blocks.
Total time: 18min 42s
This time obviously depends a lot on the user’s internet speed.
Using a local node to fetch and parse a large amount of transactions probably wouldn’t be a usability problem but using a remote node (like DeeZNNodez) with Syrius has a small chance of causing problems to the user in the scenario described previously.
Looking at the benchmarks this is probably not something we need to worry too much about but it could be good to advise the user to keep Syrius open for the duration of the swap.
5 Likes
Did you use Dart isolates for this task?
You can also cache blocks before processing.
No. I suppose using isolates could improve performance but the botteneck is the RPC API. Decoding 200k account blocks takes only a few seconds on one core. Would have to test how much isolates improve performance with the RPC API when fetching data.