Proposal to reimburse failed mint and lost funds

Proposals
1

This proposal is to request Threshold network to pay back a user who lost funds in a mint that went wrong and the user lost over 4 BTC. The user opened a support request with the help of Victor and John Packel and the support team concluded that the funds could not be recovered. The user who lost funds makes the following case for reimbursement :

The minting UI is a poor design that caused a tBTC mint deposit to be lost. The mint requires BTC to be sent to a wallet that is stored in the browser cache with its private data stored in a JSON browser download. The JSON file handling is non-standard for holding private wallet data. The language used and method of handling the JSON are poor design choices that unnecessarily open vectors for a failed mint and lost funds. As happened in this case the JSON browser download was blocked automatically in the background by the browser unknown to myself which lead to a lost JSON. I request the Threshold network send the equivalent of the lost funds 4.04185123 BTC back to the sending address. I explain below some of the reasons that lead to the loss.

The document page STEP 1 #4 says: “Make sure to download the JSON file by clicking Download. The JSON file contains a wallet public key, a refund public key, and a refund lock time. You need to keep this JSON file until you receive your tBTC tokens.”

So it mentions public keys not private keys so does not indicate private wallet data. The file actually also contains a blinding factor that is not mentioned here which turns out to be critical to the loss. And it says one needs to keep this file for fast recovery but doesn’t clarify that this file contains the private data required to forever move the funds. So the JSON is actually a non-standard wallet because it contains the only copy of the private data required to move the funds after the deposit. This is a very non standard way of handling what is a new wallet address. There is no wallet setup protocol followed as is standard when creating a new wallet that would indicate to the user they are still responsible for the funds at this time. Also it is not a standard application of the browser download and cache to hold new wallet private data which is subject to browsers default security policies that may automatically in the background block certain browser downloads.

The phrase in the mint page says “in case you need to make a fast recovery” that also implies the JSON is only required to speed up the recovery process and not essential for it. The support team had the habit of calling the JSON a receipt. A receipt does often help “in case you need to make a fast recovery”. But a receipt is never an essential key to forever require access to the valuable that was deposited. Issuing a receipt literally means proof of deposit meaning the liability for the valuable has changed. And so the liability doesn’t stick to the depositor. So this also indicated to me that the tBTC UI mint design is flawed.

Since the JSON receipt is so critically important why not require it to be uploaded before displaying the deposit address similar to the existing RESUME feature?

In any case the process should and can be bullet proof and yet using the browser download and cache for a new private wallet is a very non-standard design especially if the intention is that liability remains with the user for this part of the process.

Therefore I request the Threshold Network approve this proposal to send funds equivalent to the lost 4.04185123 BTC to the same address which originally sent the funds as follows:

Original send address/reimbursement address:
1BdupQuUWT1s6CZHMfQ2NYutBuY3vcw5Ys

Mint Deposit Transaction ID: 38dc55c71a7d192dfb8dd2c01b16f40fc712252205e24287b5271bc725080f6a

Thank you kindly for your consideration.

1 Like
2

I strongly oppose this. There is no way to verify that the user hasn’t downloaded the json correctly and therefore would be able to continue with the tBTC mint after receiving a refund.

It’s unfortunate, and I’m sorry this has happened. But this is entirely the users fault and responsibility.

3 Likes
3

So actually you highlight another design flaw that a user can be in my situation where funds are stuck but they cannot prove it. So we are just supposed to watch the funds sit there forever in no mans land because perhaps I have the wallet file? This is a wallet file that Threshold Network docs never explicitly even describe as a wallet file.

I am an early contributor and supporter. I took a risk to support tBTC by minting large amounts and you just want to wash your hands. The Threshold Network should at least acknowledge these minting design issues. How long before some other poor user sends more BTC to be lost because of this horribly designed minting process? How many other deposits are sitting there unmoved? Threshold Network should monitor these stuck deposit funds. Or is that another impossible step because of design flaws?

Threshold Network can at least try to come up with a solution instead of shedding responsibility.

Are you sure there is not a way for the network to rule out a resume? Is there not a time out? Perhaps a way to black list those coins from being minted in the future? Are you sure there is not another way for the Threshold Network to move the stuck funds?

You say: “this is entirely the users fault and responsibility.”! Automatic background blocking of a browser download is not the users fault. It happens in the background by default in many browsers. Where do the minting documents warn users about browser blocked downloads? Why not require the user to upload the wallet file before displaying the deposit address? Such a simple fix confirms the poor design.

The obscure, non-standard wallet handling means this is not my fault or my responsibility. Are you going to tell me an actual reason why its okay for the the mint page to create a non-standard new wallet without giving me the seed and without following standard wallet creation protocol? And without confirming the user actually possesses this non-standard wallet file? If the Threshold Mint intention is the user is liable for the funds in the deposit address then the process should take users through standard wallet setup, give them the seed phrase and confirm a backup first.

Its not my fault but it is my problem. This is the fault of Threshold Network minting design team.

Threshold Network should AT LEAST:

  1. take responsibility;
  2. immediately pause minting and fix the mint design asap;
  3. monitor and report on all the deposit addresses which have funds apparently stuck;
  4. attempt every possible angle to help me recover the funds;
  5. or attempt a reimbursement plan that is viable.

The Threshold Mint deposit wallet handling is pathetic. The minting process can and should be bullet proof. Not implementing standard wallet protocols is lazy and terrible design. Everyone should know the risks of using the tBTC minting process in its current form.

4

Currently there is a risk that the blinding factor that would be stored in the JSON can be used to mint tBTC or refund BTC after 9 months. As long as that remains a risk, a refund is not acceptable, however I strongly support making the protocol safer and better protected against user error.

In principle I support a refund of this user. I hope someone with the technical expertise can lay out possible solutions, not just for this specific user, but for prevention in the future.

Perhaps it is possible to block minting of tBTC after x months and allow a refund to address of origin?

2 Likes
5

Currently there is a risk that the blinding factor that would be stored in the JSON can be used to mint tBTC or refund BTC after 9 months. As long as that remains a risk, a refund is not acceptable

Users should not be held responsible for the fact that threshold network doesn’t allow them to prove loss of funds.

6

The JSON file is the proof, if the user doesn’t keep the proof there’s no other way than some kind of timeout and refund to address of origin.

I’m inclined to support a proposal of refund, but that requires a technical solution, the current proposal doesn’t address that part and will put other users funds at risk, for that reason, this proposal isn’t acceptable in its current form.

1 Like
7

If the user did not execute a reveal transaction, they should check their local storage.

If the user goes to https://dashboard.threshold.network/tBTC/mint, connects their wallet, and still sees step 2 with the Bitcoin address where they sent the 4 BTC, then it should be in local storage.

The blinding factor may have been recoverable via the logs maintained by Thesis if the user had reached out for assistance earlier. Unfortunately, there was a significant delay (>30 days) between when the user deposited and when they contacted support and the logs were not permanently maintained (although I understand the day of the deposit was checked and no record of the transaction in question was found, but this may be attributable to timezone translation issue).

tLabs now maintains a log server which permanently records the blinding factor.

4 Likes
8

Thanks. It is good news to hear a fix is in place and the logs now permanently record the blinding factor.

Regarding the 30 days of waiting before contacting support the below Threshold Network documentation made me believe that if I wait 30 days I would get an automatic refund:
https://github.com/threshold-network/tbtc-v2/blob/main/docs/rfc/rfc-1.adoc

“2.3.3. Automated Refunds
A bitcoin transaction is an amount and a script. The script can be something as simple as “these funds can be spent by wallet 0xabc”, or in our case, as complex as “these funds can be spent by wallet 0xabc but if they aren’t spent within 30 days they can be spent by wallet 0x123”. This gives us the ability to create deposits that automatically are refunded after 30 days if they aren’t swept. Thus, if a user misfunds or they get cold feet (for any reason), all they need to do is not submit their reveal and wait 30 days.”

This is why it took me 30 days to contact support. I was very surprised not to receive an automated refund and it was at that time I panicked and started researching more details about what was going on and I escalated via Threshold Network support. The Threshold Network community response and technical support team was always very responsive and extremely professional.

The word “deposit” means custody has changed to Threshold Network for minting. Apparently it turns out the user via their local browser cache is still the custodian of the funds at this “deposit” stage and not Threshold Network. If it is the intended design that the user remains the custodian at this stage then another improvement to the minting design can be to relabel the BTC transfer phase of the mint from “deposit” to something like “pre-deposit” instead. I understood that a “deposit” means Threshold Network is the depository for minting meaning the depository now has control and liability. A user deposits something and the depository is liable to keep it safe. But if the intended design is Threshold Network is not the depository at this BTC transfer stage then the stage should be be renamed something like “pre-deposit”.

I appreciate that there are now fixes that were put in place such as keeping the blinding factor logs. These fixes confirm that there are/were minting UI design issues which confirms that I should be made whole. I think its unfair for me to be told “we made these fixes so this doesn’t happen again but oh maybe you will move the deposit funds after we refund you and yes that is another technical flaw of the minting design that we can’t positively confirm control of the deposit funds but you have to pay for that.” Threshold Network should pay for that. I would be keen for the support team to work with me again to search again for the blinding factor in case there is some chance we can find it in the Thesis logs.

I hope Threshold Network can find a solution to move or neutralize the stuck deposit funds but it is not my fault to fix and I think it should not be a pre-requisite for me being made whole. Although it doesn’t help in my case one future fix could be to require the RESUME of the JSON before displaying the “deposit” address thereby confirming that the user has custody of the blinding factor.

So my perspective is Threshold Network is confirmed to be liable based on fixes being implemented already to close these holes in the minting design. Therefore I think Threshold Network should reimburse me even if there is no technical solution to move the funds or to distinguish me from a “scammer” since control of deposit funds cannot be confirmed.

9

You are free to make your case to token holders and/or contact Thesis for further assistance.

But you are not free to invent and wrongly attribute quoted statements.

None of what you describe are considered bugs or flaws with the minting process. As far as I understand, they were intentional design decisions by Thesis and there are no plans to change how the mechanism works. Adding logging as a courtesy function does not change any aspect of the protocol.

Kindly refrain from misrepresenting the statements and opinions of myself or other users.

10

My understanding here is that tLabs is a part of Threshold Network. I am new to learning about the network and community and there are many parts I do not understand but I deeply appreciate the technical work done and the courtesy logs in my case would have been very helpful to fix the lost funds.

11

the courtesy logs in my case would have been very helpful to fix the lost funds.

Perhaps, although as I stated above, Thesis indicated their logs on the date in question had no record of the transaction.

12

Feel free to ask if you have any questions.

13

Given that the browser blocked the JSON download automatically in the background and this is default behaviour in many contexts (I am open minded) but currently I don’t see how this loss can be categorized as user error so I’d like to challenge anyone who thinks this loss was caused by user error to explain the steps the user should have taken and how those steps were clearly articulated in the minting documentation.

14

IMO from the outside, this whole story sounds sus to the max.. You come here and meticulously disect the minting process and argue like in court, post transfering a huge amount of BTC without testing the minting process with a smaller batch first. Instead of panicking, you waited >30 days before contacting the team via known channels because, again, you assumed some kind of deposit transfer to Thesis, even if it is clear from the way tBTC is marketed, that only YOU are the sole custodian of your assets and no team/person holds sole control over your funds/deposits and can initiate this. Who does that? You put total trust into a mechansim you didn’t knew and didn’t care to research and now you come here and try to argue for reimbursements and tries to put on pressure to the team. Sorry, but I will vote against this if this comes to the vote because IMO it sounds more like an elaborate scam than a true story.

15

Thanks for your reply. I appreciate any kind of engagement for me its better than nothing.

I have made other small and large mints before this and the support team can confirm this. The problem happened when I used a different browser than normal the Tor browser which has a different default security context that blocks browser downloads automatically in the background and deletes the browser cache when the browser is closed. You can try doing a mint with Tor browser to see my perspective.

Of course I argue like I am in court I lost 4 BTC! Who wouldn’t!? I am in a state of anxiety and panic and so my desperation shines through in my approach and verbose language. What else can I do? I was told by support to make my case in a proposal so this is my last hope. I am taking my time writing these messages to make them as detailed and clear as possible.

Of course I know meticulous details about tBTC minting now after working with the support team for weeks I started studying the process and I have learned more and more about the fine details of the process.

I explained why I waited 30 days because I expected an automatic refund which is in the documentation! I certainly couldn’t imagine there was a temporary wallet created in my browser cache.

I acknowledge you make a good point about the sole custodian of funds always being the user. It still stands that the minting process should not rely upon a browser download for control of a temporary wallet created in the browser cache. It should take me through a standard wallet creation setup giving me the seed phrase. At least it should require users to upload the JSON to confirm the user has it before displaying the deposit address.

I am trying to add supporting information to to rule out any suspicion that this can be an elaborate scam and I am willing to co-operate with anyone to work through this but I need help. Can you help me?

Currently I am trying to figure out exact details about the script address where the funds are now. My understanding from discussions with the support team is that the script limits the next address where the funds can be sent. Either funds can be sent to a tBTC pool address or the refund address I entered into the tBTC minting form. I don’t know yet if this is correct. Do you know if this is correct? If it is correct then I can reveal the private key of the refund address to the support team or here in this forum to prove my case is genuine. Perhaps a technician can request me perform some other action that can prove my case is genuine? Everybody will see the days, weeks, months, years go by as the funds sit there doing nothing so that is something else that the community will be able to verify.

Its easy to throw an accusation like you have and I do empathize with where you are coming from. The other side of that judgement is I am an early contributor and supporter and I’ve made numerous significant mints.

I am genuine and the problems with the minting process I have detailed are real. Can you please tell me if you think the problems are real? Can you answer my challenge in the earlier post? As you can see it has been a few days and so far nobody in the community can explain what steps I should have taken and how the documentation backs that up. I would expect to see something warning me about browser blocked downloads or warnings against using some browsers like Tor. From my perspective the failure to answer my challenge confirms that I am right (so far) that the minting process and documentation are flawed. So all I need to do then is remove the possibility that this could be a scam.

I apologize for the long messages and I beg you to hold your judgement for now and reconsider voting in favor to reimburse me. It is easy for Threshold Network token holders to slink away and take no responsibility even without articulating where I went wrong so I am at the mercy of the token holders. I am depending on technical assistance and integrity amongst token holders.

1 Like
16

Just a reminder since nobody seems in a rush to answer my challenge that the documentation is flawed. So here is a link which minters access one click from the tBTC minting page on the “TIMELINE” section it says:

2.3.3. Automated Refunds

“if a user misfunds or they get cold feet (for any reason), all they need to do is not submit their reveal and wait 30 days.”

So I wonder where is my automated refund?

This is false and misleading advertising. I relied upon this automated refund and waited 30 days and then I learned it is not true and that waiting 30 days perhaps cost me access to the log files I needed for the lost blinding factor.

Keeping this in your documentation certainly does increase the confidence for minters to read this and so token holders will likely be increasing their profits by ignoring my constructive criticism. This section should be removed urgently.