Public BarterDEX Testing – We Are Making Regular Atomic Swaps

We have renamed our Native Decentralized Exchange technology to BarterDEX. The BarterDEX is currently our priority, and the development is advancing as planned.

BarterDEX testing found connectivity issues between nodes as the primary problem, which required revamping the low-level networking and totally changing how the pubkey based communications are done.

I decided to go to a broadcast method, which is theoretically more bandwidth intensive, but due to the redundancy needed to ensure the time critical packets got to the destination, it was using the bandwidth anyway. And if the design is a broadcast method, it means that we can add ‘point to point’ encryption for all the pubkey based comms.

So I did.

I also streamlined the broadcast mechanism and added a broadcasting service that the LP nodes do for client nodes. It allows any client to request a broadcast of an encrypted packet to the network. Now I am tracking the number of redundant packets sent to make sure we aren’t flooding the network.

About 20% redundant packets, which is not bad at all. Since the atomic swap is using pubkey based messaging, this means that the atomic swaps are done in the dark. Of course, there are still indirect means that can be used to determine who made a trade at a particular time, just by looking at the blockchains, so it isn’t anything like zero-knowledge level privacy, but having all the trade details under encryption makes it harder for others to know what is going on.

This will, of course, create a bit of a problem when trying to gather stats, but I have an idea on how to do that without infringing on the privacy.

As I have discussed before nodes that can’t bind ports that other nodes can connect to (virtually all home isps!) is the hardest case. Of course, we want to support this case as the alternative is that anybody that wants to post an order long term would need to run a VPS. The new broadcast mode is designed to work much more reliably with such nodes. And in fact was able to list some JUMBLR for sale and then fill it from another node!

All this means that even now, anybody can run a barterDEX client, post orders and have it filled, without requiring the LP nodes to be involved in anything but the routing of packets (which do not have any IP address information of the client). Now if a client uses canbind: then it will need to give its IP address to the nodes it trades with, but with the trade details encrypted it is only to the counterparties to a trade. Still if you do a lot of trades maybe this is not so good, and canbind:0 is the way to go, as the IP address you give to the counterparties is the IP address of the LPnode that created a psock for you.

A psock is a paired socket that the LPnodes binds on two ports. These ports are then published and exactly one node can connect to each one. This also provides a mutual exclusion functionality, and with the connection address under encryption, it makes any wannabe interlopers job much more challenging, even if they manage to become a man in the middle. The LP node does not even get the IP address in the request or even the pubkey of who is requesting it, it just allocates a psock and then whenever there is data available on either port just sends it from one port to the other. Of course, given wireshark level data the LP node that makes the psock for you will be able to determine your IP address, but with proper precautions, you can make it so that it won’t matter, i.e., use a VPS node as your client.

Anyway, I have been busy getting barterDEX production ready, and it is almost passing all the required must have test points. We still need to do the stress testing and illegal input type of tests along with disconnection during atomic swaps, so not done yet, but the finish line is now appearing visible.

I tried doing a JUMBLR/BTC atomic swap and it almost worked, it seems the autofee calculation is a bit wonky, but considering this was the first BTC swap I even tried, it is not a bad result

alicespend: 9254b848a7e0644c553605394c910d90b39405a03fca8ffa68ceec61790ee4c3 1.00000000 JUMBLR (this is a bug where the txfee was not deducted)

bobspend: 01000000019723204304ef6d139557ef660878e367688210017dea916c20795e55db3b7e9500000000db0048304502210099723f1d7912b8ce431aa28e3a6b809aa591c5afeb789e0529fc90866b0b960802204cf5d62f140808491ceeef21d8ccddfa6f7d1ee638a1f0b6d8b5d89c9fc645850148304502210090696d279ac68121e9b72b35b2064947a998f0ab3b24e79e27a85cc7f05f4bba02200583d64b4a1d6563ee65f54702ef371b121fdbbf539168b3b13ca88942f40ceb0147522102725643f29e4139071c632c6cf0ff84108070074eec46ba11376052492e13406f210383d62d25e9ef6087dc92a4d16c40eb21272f3407feb65f772ecd59539dc329da52aeffffffff01a8dd0600000000001976a 914efdfb7a012b73ad7a2aecfa013d231dd9b6736c088ac00000000 error due to insufficient priority trying to spend 449960 sats when input is the same

We seem to be down to some small issues with the error recovery code. I am using the same code for error recovery as for the mainstream swap cases to minimize the amount of code needed and maximize the code path coverage.