Now before you devote this thread and pass on my story as if I made a newbie mistake. Hear me out.We are currently in the beta stages of developing a OTC exchange for the South African Bitcoin market. We decided on Blockchain.com's Receive API v2 as our method of generating new addresses to receive Bitcoins from users. The full documentation of this api can be found on their site http://bit.ly/2NoZJrm Kindly reference this documentation on my further statement.We applied for a API key and was provided one. We then used the documentation to implement the API and did so successfully using the parameters and guidelines of the documentation. The root of my issue came from something called the gap_limit. This parameter description is explained from the docs in the following manner'You can control this behavior by optionally passing `gap_limit` as an extra URL parameter. Please note, this will not increase the number of addresses that will be monitored by our servers. Passing the `gap_limit` parameter changes the maximum allowed gap before the API will stop generating new addresses. Using this feature will require you understand the gap limitation and how to handle it (for advanced users only)"Due to this statement we decided not to pass or edit the gap limit within our get requests for a new address. We did this because they state quote'As defined in BIP 44, wallet software will not scan past 20 unused addresses. Given enough requests from this API that don't have a matching payment, you could generate addresses past this horizon, which would make spending funds paid to those addresses quite difficult. For this reason, this API will return an error and refuse to generate new addresses if it detects it would create a gap of over 20 unused addresses. If you encounter this error, you will either need to switch to a new xPub (within the same wallet is fine), or receive a payment to one of the previous 20 created addresses'We assumed on our side ( our fault for doing this ) that if we don't edit the gap_limit it will default to 20 as their servers only scan up until a 20 gap_limit. However after implementation and beta testing with a small client base over time accumulated some unpaid addresses that added up to 20 unused addresses. Then a user created a order, despite the gap_limit being reached the api still returned a address, this address was the 21st address. 1 passed the gap limit. 0.83432528 BTC was sent to this address and no btc was allocated to my Blockchain.com wallet like in the passed with other orders that used addresses generated by my xPub and API key.After days of debugging and investigation the conclusion was made that in fact, the address was the 21st generated address therefore despite Blockchain.com's API saying it will return a error if exceeded, did not. To confirm this we then implemented the gap_limit and set it to 18. Followed by tests resulted in a error when exceeding the set gap_limit of unused addresses. Now we confirmed the issue and implemented a solution but our bitcoins were still in a address which belonged to me and had my bitcoins in but were unaccessible due to Blockchain.com's servers not scanning passed the 20 gap_limit. They appeared to be stuck.I went through the correct channels by opening numerous support tickets, all resulted in the same cycle of events. I open a ticket explaining what has happened, generic response, my further response goes ignored. This repeated over 4 tickets.Almost a month goes by and still despite my efforts of getting my BTC back I could only sit and watch the BTC dwindle away block by block. Till the 2018-08-31.A transaction on the address came about and it was a outgoing one to a much much larger address. To big to be any single person or even potential hackers address ( Yes we did consider this possibility during debugging and investigation and the conclusion was no tampering was found) This destination address appears to be that of one that would likely belong to Blockchain.comHave a look for yourself here is the address that was generated passed the gap_limit,https://www.blockchain.com/btc/address/1Ar23WEvzW8obJWZfgtvQ5Z43AVtCUXoTeThe minor transactions made after the initial large ones were done during my efforts to get a call back response for the api to allocate my funds but those were unsuccessful. The end point of the Bitcoins landed here in this addresshttps://www.blockchain.com/btc/address/1NDyJtNTjmwk5xPNhjgAMu4HDHigtobu1sMy conclusion is aided by the following points in regards to my accusation that blockchain.com pocketed my mistake instead of assisting me in recovery which in their docs does claim to be challenging but as the bitcoins have moved was obviously achieved not for my sake but for theirs.-They ignored my support requests instead of Replying with constructive possible solutions or efforts to worth with me-Their twitter account ignored my tweets and went on to reply to others-My understanding and flow of the issues resulted in me writing off the BTC as a loss due to them not being able to recover it as it was passed their servers set bounders. But they accessed it and took it.-No explanation from Blockchain.com's side on what happened.Please guys help me get this message and my issue to the higher ups responsible for this or banter me into correction of what could have possibly happened in my case. via /r/Bitcoin http://bit.ly/2Cor2h0
No comments :
Post a Comment