Quote from: jl777 on February 16, 2016, 10:52:22 PM

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.

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.

Quote

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.

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

Code:

IF
HASH160 EQUALVERIFY CHECKSIG
ELSE
CLTV
END

and

Code:

IF
HASH160 EQUALVERIFY CHECKSIG
ELSE
CLTV
END

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

Code:

OP_IF
OP_CLTV OP_DROP OP_CHECKSIG
OP_ELSE
OP_HASH160 OP_EQUALVERIFY OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
OP_ENDIF

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

Quote

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.

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.