You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the attached screenshots below, you see the same trade offer SeiOKTX being taken by a buyer four times.
The left side is buyer no. 1, attempting to take the trade twice. As you can see the the Trade date is just 90 seconds apart. The Maker fee transaction ID is the same, and the Taker fee transaction ID is different for each. This all seems consistent with the kind of timeout errors we've seen before, although, as far as I can recall, I've never actually seen the same trade get taken twice like this. The trade has always ended up in a failed state for both taker and maker. Perhaps I'm mistaken about that though.
Now, the mystery: on the right side, you see the same trade offer SeiOKTx being taken twice, this time by buyer no. 2. Again, the Trade date values are just a few minutes apart. The Maker fee transaction ID remains the same as it was in the trade attempts with buyer no. 1, but—and here's the thing—the trade amount is different on the right side. In the first pair of attempts the trade amount was 0.1250 BTC. On the right, it is 0.18 BTC. Offers are not (yet) editable in Bisq. Therefore it is a mystery to me how these values could ever be different while the Trade ID remains the same.
I have already reimbursed buyer no. 1 in #73, and I am going to go ahead with a reimbursement for buyer no. 2. shortly. I originally thought there may be some fraudulent behavior here, but that seems unlikely given the very small amounts being reimbursed (just the fees). There is something going on here that I don't fully understand, and I believe it may be the first time we've seen this sort of thing, thus my writing it up here.
The offer probably had min. amount set lower so the trader 2 used a lower amount. taker fee txid is different as expected in that case as a new take-offer attempt use a new address.
can you post the onion address and offer details so we can try to contact the maker? seems his app is buggy or old...
The offer probably had min. amount set lower so the trader 2 used a lower amount.
Of course. Thanks.
can you post the onion address and offer details so we can try to contact the maker?
The maker's address (per the screenshot above) is dz725rmfbx7taiji.onion:9999 It wasn't my trade (it was @keo-bisq's), so I can't get any more information than what's listed above.
cbeams
changed the title
Investigate the mysterious 4 failures of trade SeiOKTX
Investigate the 4 failures of trade SeiOKTX
Mar 8, 2018
In the attached screenshots below, you see the same trade offer
SeiOKTX
being taken by a buyer four times.The left side is buyer no. 1, attempting to take the trade twice. As you can see the the
Trade date
is just 90 seconds apart. TheMaker fee transaction ID
is the same, and theTaker fee transaction ID
is different for each. This all seems consistent with the kind of timeout errors we've seen before, although, as far as I can recall, I've never actually seen the same trade get taken twice like this. The trade has always ended up in a failed state for both taker and maker. Perhaps I'm mistaken about that though.Now, the mystery: on the right side, you see the same trade offer
SeiOKTx
being taken twice, this time by buyer no. 2. Again, theTrade date
values are just a few minutes apart. TheMaker fee transaction ID
remains the same as it was in the trade attempts with buyer no. 1, but—and here's the thing—the trade amount is different on the right side. In the first pair of attempts the trade amount was0.1250 BTC
. On the right, it is 0.18 BTC. Offers are not (yet) editable in Bisq. Therefore it is a mystery to me how these values could ever be different while theTrade ID
remains the same.I have already reimbursed buyer no. 1 in #73, and I am going to go ahead with a reimbursement for buyer no. 2. shortly. I originally thought there may be some fraudulent behavior here, but that seems unlikely given the very small amounts being reimbursed (just the fees). There is something going on here that I don't fully understand, and I believe it may be the first time we've seen this sort of thing, thus my writing it up here.
@ManfredKarrer, any thoughts?
The text was updated successfully, but these errors were encountered: