Topic: Atomic swaps using cut and choose - page 6. (Read 12138 times)

I wonder if this would be a reasonable refund policy.

Both parties generate 1000 key_pairs = (private keys, hash(private keys))

Both parties exchange hash(1000 key pairs).

The fee transaction contains hash(alice_key_pair_hash | bob_key_pair_hash).

This is included in the fee transaction somehow.

To claim the fee refund, the person has to submit the 1000 key pairs and [other_party]_key_pair_hash.  That allows you verify that they had actually generated 100% valid pairs.

Someone who tries to attack the cut-and-choose cannot reclaim their fee.

They have to trust you to do that though, but that is probably ok, since it is just the fee.

Another potential solution is pegged assets on the same block chain, for those coins you want to trade with:


Afaics, that seems to avoid the jamming issue.

I was very sleepy when I wrote my prior post.

I understand your point. You want to design a protocol that is at least immune to jamming against any attacker other than one that has super powers.

Yet the attacker with even meager resources could cause honest participants to lose fees and so they might get turned off from the system. For example, centralized exchanges may have this incentive. Or specific coins might have this incentive to jam DE on other coins (especially those who hadn't yet been listed on a major exchange).

So you proposed to refund fees to those honest participants. You admitted that users might not be prone to apply for a refund since 0.13% is so small. And I pointed out the DE would maybe have a financial incentive (while appearing to be the good guys) to jam each honest participant say 50% of the time, to increase fees to 0.26%.

I am trying to think of a way to make this practical and robust enough, unless we are facing a prolonged attack from a super power. I like the ideological intent of DE. I will now review your latest reply with a clearer mind.

It is not easy to be monitoring multiple chains at once as not only are there the data sync issues, but also just the logistics of running N daemons.

That is why I am developing iguana, a single lightweight multicoin daemon/applications all rolled into a single unified codebase. That just happens to be able to be cross compiled into a chrome app as it has virtually no external dependencies

James

P.S. I am getting BTC sync times from scratch of about half hour

I'm not sure if that helps (if anything does at all)  at all but I read that part here with the ..interactively verifying the presence of data in a foreign blockchain ...


"The Power of Binary Search

In the next two sections, I will give two specific examples. One is about interactively verifying the presence of data in a foreign blockchain, the second is about verifying general (deterministic) computation...."

in

https://blog.ethereum.org/2016/02/17/smart-contracts-courts-not-smart-judges/

I'd say it is same issue with Casper:

Decentral:
You need a trustless clrearing system  / notary in between - some say that 'could work' with some betting design....

Central: Easy but open to hackers.


Think of the actual process in trading as is:

- Client (has ccy1)  & wants to change it to ccy2
- Client needs to deposit (maybe partial) ccy1 first at market maker's account (market maker that could offer ccy2 vs ccy1)
- Market maker activates client to trade since now there is a credit limit = reduced counter party risk to market maker
- Client hits market maker (pays a fee for that service incl settlemet cost)
- Market maker might send real time confirmation notice to client (last chance to cancel?)
- Settlement is initiated by market maker (or escrow service) - atomic

How can you put some code around all that in a decentral way ?

You incorrectly assume some single point of failure. Remember it is decentralized, so the attacker would have to Ddos all the participants all the time. You also incorrectly assume that it will be possible to identify which are specifically DE packets. I have provisions to encapsulate the DE packets with a layer of encryption so they cant be differentiated from other types of traffic. If needed, steganographic techniques could even be used to get the data through. If that doesnt work, there are zero knowledge ways to transmit the DE traffic. So there are quite many levels of defenses that are possible

why would InstantDEX want to attack its own users? That seems quite counterproductive. The volumes of an attackfree DE is much more than double one plagued by attacks. Due to the nature of the internet, over time there will be failed transactions, so eventually the users will recoup the fees. There is no permanent gain of fees from failed trades, so it is a liability on the books. There is no gain for InstantDEX to abuse its own customers.


Once things are automated, probably just allow for automated refunds, it is all pretty much at dust levels so the only concern is the customer support time. With an automated system, it wont be any big burden.

The attacker would be the one who is responding to a match offer, so if an address has 1000 failed trades out of 2000, it wouldn be easy to notice that. Worst case, even if the attacker doesnt lose money, they dont gain anything.

I have a reputation system that cannot be sybil attacked, trading with yourself wont do any good. And before you say its not possible, let me say that it is, at least one that will be very expensive for the attacker and that is what it is all about, making the attacks cost more than the expected return.

Sorry, you are wrong. Maybe it will be the first time this happens? I believe that it is quite difficult to prove a negative, in spite of your claims. While I just need to make it work, and since I have quite a lot of techniques at my disposal, I am very optimistic I will get it to work.

You have no economically viable attack. Just because something is possible, that doesnt mean it is certain to happen, especially when it is economically non-viable. In crypto, the math protects us, so as long as the math yields a negative expected return, it wont attract the money motivated attackers. And if idealogical attackers conduct a permanent attack, I will just have to resort to adding highly leveraged and encrypted comms to make it very cost prohibitive to conduct any large scale attack. It would be a pain to do, but if needed, the DE can be conducted via zero knowledge networking.

I really dont think we can dismiss a project before the real world performance is established. If the failure rate is 90%, of course it wont be used. If the failure rate is 0.1%, then I dont think that will be a large deterrent.

The question is what will the real world failure rate be. I claim that NOBODY is able to predict this ahead of time. I prefer to get a real world results before making any decisions based on theory.
Until there is some significant volume being traded, it seems nonsensical for it to be attacked like that. And by the time there is a significant volume being traded, the more advanced defenses will be ready.

In order for it to fail, either InstantDEX itself would have to attack its own users or there needs to be an attacker from day one who doesnt care about costs, interfering with every single trade AND that I wont be able to devise defenses against this. Defenses can be via reputation system, insurance system, refund system, technically leveraged protections, among others. And all will have to fail with a constant and permanent attacker always interfering with significant numbers of trades.

You really believe this is 100% certain to happen?

James

wow it's really hard for a newbie 

The reason it isnt easy is that there are two independent blockchains.

If using just one blockchain, things become much easier

James

Pardon. Reading the header with SWAP and then parsing the story I finally understand you try to achieve just an "easy" crypto ccy SPOT trade (Even more correct a same day forward) by executing one of the "easiest" smart contract and already struggle with that?

Why not trying some betting stuff? (Sorry, just caspering around a bit  )
I really want to know and see such easy stuff working before more complex things should be developed, savely....

How about some 2factor like mechano?

An attacker with infinite resources that doesnt care about monetary losses...

I claim that such an attacker can bring any network to a standstill. So defending against this is not a high priority in the beginning.

I like the simple approach where the fee (insurance) is prepaid before each trade. The fee is tagged with the orderid of the recipient of the offer, not the initiator of the trade. This means that a papercut attack cannot be done proactively, but only if somebody else initiates a trade with the attacker.

So, that means a reputation system will be effective as trading with newbie accounts will carry some small risk that they are a papercut attacker who set a trap.

By linking the fee to the orderid of the one that posted the bid/ask, that means the papercut attack only delays as the fee that was paid is still valid for completing the atomic swap with a real peer. The attacker cant reuse the fee paid, so this is assymetric in a good way.

Granted the victim will be out a fee if their bid expires without the trade being completed. We are talking about 0.13% in the event of an attack, so most of the time not even worth going through a claim process.

But maybe an active trader over time will accumulate a bunch of such failed fees, and I think if there was some sort of automated claim process for this, it solves the practical issues of this theoretical problem.

Before you start complaining that requires trust that this process will be honored, my response is that if this attack scenario remains hypothetical, then it is not an issue. If it does happen and the fees paid for failed swaps are not refunded, then that will damage the reputation of InstantDEX and so there is strong incentive to keep the customer's happy. Keep in mind it is the 0.13% fees that are lost due to an attacker that doesnt care about losing money and just wants to jam things. Typically non-economically viable attacks are not a big priority to solve. But I dont want there to be any obstacles to using InstantDEX, so I will commit to refund the fees paid for atomic swaps that dont complete, as long as the txfees needed to send out the refunds are less than 10% of the refund.

As opposed to having 100% of your capital at risk when you use centralized exchanges.

James

On further thought, I have decided that my suggestion for coin age is useless by itself and I need to add the following to make it work as intended (while coin age remains necessary else the attacker could use a mixer to create new UXTO that escape the decentralized reputation system I will suggest below).

DoS by jamming is the paramount threat to decentralized exchange that needs to be solved first. If this isn't solved, then it isn't worth pursuing because for sure the government will be against exchanges which they can't regulate to enforce KYC, etc (this will become more so in 2017). Governments have unlimited funds to attack with (e.g. $4+ trillion went missing from the DoD budget and finances the DEEP STATE). Please don't tell me that Donald Rumsfeld and Bill Moyers aren't mainstream and reliable sources.

There is no way to solve the jamming problem by relying on the two block chains that are doing the trade, because someone always has to go first, thus someone will always get jammed. If the honest person never goes first, then no one will go first. Simple logic.

The only way I can hope to fix this problem is to have a separate block chain for recording the intention to enter a trade, and with this block chain track those UXTO which are bailing out and thus users can refuse to trade with them. Again this requires the coin age to prevent the attacker from using a mixer to subvert the tracking by UXTO. Also coin age is necessary so someone doesn't get inadvertently blocked forever due to some glitch on their end where they couldn't follow through on the protocol.

One way I contemplated is to have both parties sign the intention to trade, then they post it to this block chain. However, one might sign and the other might not, thus jamming the other party (in terms of computing the signature and the communication latency between the two parties). Also worse is that one party might sign more than one intention to trade or inadvertently do so if the attacker didn't sign immediately but later signed and published it to this block chain.

Thus the first requirement is we need a way for both to sign where the signature isn't valid if they both didn't complete the signing protocol. I am not sure if this can be accomplished. I would need to think about some variant of Shamir's How to Share a Secret crossed with "simultaneous contract signing". Something like a Diffie-Hellman exchange (but that is sharing a symmetric key) where either party can then sign on behalf of both parties proving that the Diffie-Helman exchange occurred.

If the prior paragraph can be achieved, then the jamming that remains is only on latency of the protocol in the prior paragraph, yet this is still a jamming problem. There is no way for the user who is being jammed to share his UXTO blacklist with other users since the attacker could Sybil attack such sharing.

So thus I conclude that decentralized exchange is probably not going to work unless there is some reputation system. But then when I consider reputation system designs, they can also be Sybil attacked. It seems the only possible solution would be a Web of Trust similar to PGP wherein I decide to trust those who trust me and vice versa. But the problem with Web of Trust in this context is the attacker can Sybil attack it by first gaining trust, then violating trust thus causing the Web of Trust to be unstable.

Sigh.  

If anyone can think of a solution at the conceptual level (never mind what block chains currently offer), I would love to read it.

So far decentralized exchange looks to be jammable in every design I've contemplated.


But my point is the jamming will come before that connection has been established.

Also if both sides lose money when one side bails, then the attacker can cause the innocent party to go bankrupt.

You are ostensibly dismissing the case of the attacker who can charge the cost of the attack to collective. Right at this moment, China's mining cartel controls an estimated 65% of Bitcoin's hashrate and they have vetoed every block size increase (even Classic's reasonable doubling to 2MB), and they apparently have very low electricity costs so it isn't unthinkable that with a "wink and a handshake" this electricity is coming for free from Three Gorges Dam. The fact that I have proven they must have lied about the bandwidth problem  (since of course they could put a pool abroad and just relay the hashes across the Great Firewall of China). One motivation could possibly be to force transaction fees higher and reap more profits.

So there is already circumstantial evidence that the attack scenario I am worried about is not impossible.

Right.  I suggested something similar.  If 99% of trades that are initiated end up completing the cut-and-choose, then the risk is pretty low.  If a trader is burned, then it can push up the requirement for a fee.

It is a pity that there is no way to commit to a public key.

With coinage, you can actually have it consumed with a gossip network.  To "spend" the coinage, you can sign a message with the public key of the output.  If the person doesn't complete the trade, then you can broadcast the message (or just broadcast it immediately).  The message would contain the tradeId for the output and the current time.  It could reset the coinage to zero, for a weaker blacklist.

Both sides of the trade would lose coinage though.  A spammer should lose it faster than a normal user.


You can make it connected with the trade by having the final steps in the protocol release the fee.  If the trade doesn't complete both sides lose money.

The likely reason it was closed is CIYAM got pissed at me (in another thread) and decided to have a temper tantrum (perhaps because I was also supposed to be talking to him soon in Skype about decentralized exchange).

What I suggested to jl777 in a PM, is that he make it (the coin age, a.k.a. "Coin Days Destroyed") a user-adjustable variable so that users can select the tradeoff between delay for themselves and those counter-parties available to trade with, and depending on the level of jamming present at that time. jl777 referred to it as a "rainy day" insurance, which seems an apt characterization of the suggestion.

I have my strong intuitive (generative essence) sense that I will find a flaw in any method of using a fee to block the attacker who wants to jam the protocol, because the fee can't be atomic with the trade (without also opening a jamming window of interaction), so a window of jamming is always opened. Whereas, the coin age is a finite resource which exists (is committed to) prior to the initiation of any protocol for trading. Also it is impossible to use a mixer to hide the identity of the attacker, since mixing will bump the coin age back to 0.

Note my suggestion hinges on the first interaction with the counter-party in the protocol must bump the coin age to 0 on the block chain (else only a local blacklist can be maintained which is much less robust defense). Otherwise the attacker can reuse the same resource over and over to jam with.

Jamming is the main obstacle I forsee impinging on the viability of TierNolan's decentralized exchange protocol. The next obstacle is the very limited scalability of transaction rate for existing block chains, but that is a holistic problem for crypto right now (meaning it MUST be solved else the crypto currency phenomenon dies).

watching.

That seems reasonable too.  You are forcing people to expend a finite resource, so they can't spam. 

It could be an issue for people who have just obtained coins and then have to wait a few days to build up coinage. 


I was thinking that it could be a joint transaction, like with CoinJoin.  Each side would say where they are getting the coins from and then once the tx is built, they can both sign it.  That means that the fee has to be on one of the two coins rather than each paying on their own coin.  This means you need to know the exchange rate, but that can be pulled directly from the trade itself.

I also like the concept of having the transaction finishing transactions allow recovery of the fees.

They could pay the fees to


and


This means that after 2 days, anyone can claim the output.  If the system becomes popular, that means that miners will take the outputs as fees.  Otherwise, someone could just try to be the first to claim them. 

The _fee_unlock codes would have to be agreed before the cut and choose happens.  They would need to be included in the claim transactions. 

The step 4 output, for example, becomes


The nice thing about this is that the fee can be made larger, since it is recovered if the trade completes.


Seems reasonable, but the user should probably be given the option to set a minimum confirm delay.  The other party should be informed, so they don't think they are going to complete the trade in 2 mins and end up having to wait 1 hour for confirms.

@TierNolan

What do you think about anonymint's idea of having a user settable coin age requirement for the feetx? The idea is to slow down the annoyance attacks.

Maybe a specific order of fee payment, ie make the initiator pay the fee first to prevent a proactive attacker from waiting for the other side to pay a fee and bail out.

With contingency plan of just issuing refunds for unused fees due to other side disconnecting, and future reputation systems, I dont see this as a big issue, but if there was a technical bullet that just knocks it out completely it would offer a better user experience.

So far when it is all debugged, I dont see any way either side can lose funds. The worst seems to be having some of your funds tied of for a few hours (I am thinking setting the max transaction time of 2 to 3 hours, with a max expiration time of around 8 hours. That way even if papercut attacker locks you up for the maxtime, there is still plenty of time to complete the trade with someone else.

The two places where blockchain confirmations are needed, I have made it adaptive on the bitcoin side as of smaller tx of 0.1 BTC or less it seems that as soon as it is confirmed that is good enoough and for larger ones 1 + sqrt(BTC value) confirms, so 1 BTC is 2 confirms, 4 BTC is 3 confirms, 9 BTC is 4 confirms, etc.

The altcoin side is so variable, I cant think of any better way than having the user specify it on a per coin basis, or even per trade basis.

If some wealthy vandal actually starts doing nuisance attacks, I think we can always institute a non-gameable reputation system or even a real insurance system

Anyway, first things first. Need to get it doing trades using a simple form as input.

James

Some benchmarks of just the pure state machine:

BOB_gotoffer BOB_sentprivs BOB_waitfee BOB_waitfee BOB_waitfee BOB_waitfee BOB_waitfee BOB_waitfee BOB_sentdeposit BOB_altconfirm BOB_altconfirm BOB_altconfirm BOB_altconfirm BOB_altconfirm BOB_altconfirm BOB_altconfirm BOB_altconfirm BOB_sentpayment BOB_claimedalt reached BTC_cleanup m.20 events most.20 ave 20.00
BOB_sentoffer BOB_sentprivs BOB_waitfee BOB_sentdeposit BOB_altconfirm BOB_altconfirm BOB_altconfirm BOB_altconfirm BOB_altconfirm BOB_sentpayment BOB_sentpayment BOB_claimedalt reached BTC_cleanup m.13 events most.34 ave 11.50
BOB_sentoffer BOB_sentprivs BOB_waitfee BOB_sentdeposit BOB_altconfirm BOB_sentpayment BOB_claimedalt reached BTC_cleanup m.8 events most.36 ave 11.50
BOB_gotoffer BOB_sentprivs BOB_waitfee BOB_waitfee BOB_sentdeposit BOB_altconfirm BOB_sentpayment BOB_claimedalt reached BTC_cleanup m.9 events most.36 ave 11.50
ALICE_sentoffer ALICE_sentprivs Alice_waitfee Alice_waitfee Alice_waitfee Alice_waitfee Alice_waitfee ALICE_waitdeposit ALICE_sentalt ALICE_waitconfirms ALICE_waitconfirms ALICE_claimedbtc reached BTC_cleanup m.13 events most.37 ave 11.50
ALICE_sentoffer ALICE_sentprivs Alice_waitfee ALICE_waitdeposit ALICE_waitdeposit ALICE_waitdeposit ALICE_waitdeposit ALICE_waitdeposit ALICE_waitdeposit ALICE_waitdeposit ALICE_sentalt ALICE_waitconfirms ALICE_claimedbtc ALICE_claimedbtc reached BTC_cleanup m.15 events most.37 ave 11.50
BOB_sentoffer BOB_sentprivs BOB_waitfee BOB_sentdeposit BOB_altconfirm BOB_sentpayment BOB_claimedalt reached BTC_cleanup m.8 events most.37 ave 11.50
BOB_gotoffer BOB_sentprivs BOB_waitfee BOB_sentdeposit BOB_altconfirm BOB_sentpayment BOB_claimedalt reached BTC_cleanup m.8 events most.37 ave 11.50
BOB_sentoffer BOB_sentprivs BOB_waitfee BOB_sentdeposit BOB_altconfirm BOB_altconfirm BOB_altconfirm BOB_altconfirm BOB_sentpayment BOB_claimedalt BOB_claimedalt reached BTC_cleanup m.12 events most.37 ave 11.50
BOB_sentoffer BOB_sentprivs BOB_waitfee BOB_waitfee BOB_waitfee BOB_waitfee BOB_waitfee BOB_sentdeposit BOB_altconfirm BOB_sentpayment BOB_claimedalt reached BTC_cleanup m.12 events most.37 ave 11.50
 most.37 ave 11.50
elapsed 4711.472 ave 0.000471

units are in milliseconds, so less than half a microsecond per FSM simulation. for each one I randomly choose from the starting states and then just use a random number for the next event until it reaches the terminal event (BTC_cleanup);

Above is from a run of 10 million iterations that took a bit less than 5 seconds, with  printouts of the states for every millionth test.

I think it is safe to say that it is fast enough and also that there are no dead ends in the state machine. I didnt do any coverage stats though, so there might be some orphaned states that are never used.

For the full test point of doing an atomic swap, I have things debugged now until it fails due to invalid transactions. Which is kind of expected as I havent connected up the unspents info to the atomic swap yet. First step is to just hardcode a few unspents for each side and make sure the FSM actually makes them complete a swap if all is well.

Then making the unspents come from internal wallet addresses, etc. It is already connected to the instantdex trading API as the "bitcoin" exchange.

The test sequence is to issue the following on one node:

curl --url "http://127.0.0.1:7778" --data "{\"agent\":\"iguana\",\"method\":\"addcoin\",\"newcoin\":\"BTC\"}"
curl --url "http://127.0.0.1:7778" --data "

{\"agent\":\"InstantDEX\",\"method\":\"sell\",\"exchange\":\"bitcoin\",\"base\":\"BTCD\",\"rel\":\"BTC\",\"price\":0.003,\"volume\":2,\"dotrade\":1}"

It just activates the coin and then submits a sell offer to the network.
Then on the other node:
http://127.0.0.1:7778/api/InstantDEX/orderbook?exchange=bitcoin&base=BTCD&rel=BTC&depth=11&allfields=1&ignore=

http://127.0.0.1:7778/api/InstantDEX/buy?exchange=bitcoin&base=BTCD&rel=BTC&price=.003&volume=2&dotrade=1&password=bob

The first one shows the orderbook (this is optional) and the second one is checked to see if it matches an existing order and if it does, initializes the state machine and sends a message to the other node.

FSM is followed by both sides, states change, even "poll" virtual event appeared to work. Been up for quite a while, so not sure when I will be awake next, but it feels like the home stretch.

The only "attack" that I know of is that an attacker who doesnt care about losing money to annoy people would also have to actively post offers at the best market price (ie. realtime price quotes) and then start trades, only to never complete them. Each "attack" will cost the attacker 0.13% but the "victim" can still recycle the fee that was used as the fee tx is based on the orderid of the offer being matched.

I dont see this as any practical attack as it costs fees and only delays the other nodes that try to do a trade with the attacker and quickly it will get blacklisted. Eventually I can add a historical reputation/percentage completion of started trades as all that info will be on the blockchain, so users can decide what type of nodes they will atomic with.

I will change the random deck back to 1000 so the 0.13% fee with have an expected loss of 13% and so will Bob bailing out and losing his deposit.

James