Topic: Betnomi | Project status & Refund Plan! - page 24. (Read 7493 times)
@Betwrong, whether you are KYC verified or not is irrelevant. It simply facilitates the process, but feel free to leave it blank if you are not verified. Regarding paragraph 5, please outline the currencies you possess and include their respective addresses in the email.
This is very good news for me personally. Thank you, @betnomi for showing up here and trying to make things right.
I have a few questions regarding this form
1. If I don't remember whether I'm KYC verified on Betnomi, what should I do?
And regarding paragraph 5: If I have funds in 3 different cryptocurrencies, BTC, ETH and USDT, how should my request look like?
Thank you.
I have a few questions regarding this form
Code:
1. First name, Last name (if you are KYC verified)
2. Username (request will be ignored if the username does not exist)
3. Email address (request will be ignored if the email does not match)
4. Refund Amount (approximate balance is acceptable)
5. Wallet address (we will process only in the cryptocurrency you have)
1. If I don't remember whether I'm KYC verified on Betnomi, what should I do?
And regarding paragraph 5: If I have funds in 3 different cryptocurrencies, BTC, ETH and USDT, how should my request look like?
Thank you.
We've received several refund and withdrawal requests, and our team is diligently verifying the information. These requests will be processed and distributed in batches. The first batch should be completed within the next few days.
Thank you for your patience
Thank you for your patience
We also thank you for taking the bold step to face the challenges and cleaning yourselves from the messed you put yourselves. At this juncture I appreciate your effort for the refunds. We have seen many casino companies created threads like this and at the end they could pay back or refund the embezzled funds back the victims but yours and BC. Game is different. It will be good if those who were the victim of the act and created threads for that purpose should come back and inform the community about the new development. And for now to clear your or to retain your reputation here is hard though you can scale through, I am saying this because you are heavily tag and probably most of them are inactive. The first face of this thread is to clear your debt and the second face will the to reclaim your reputation if you can.
We've received several refund and withdrawal requests, and our team is diligently verifying the information. These requests will be processed and distributed in batches. The first batch should be completed within the next few days.
Thank you for your patience
Thank you for your patience
[...]
Let's make it simpler.
Encryption is two way because you always need the original data to perform the functions you have associated with it.
In a web form password can be encrypted or hashed. Hash is one way. If I am not wrong [from my outdated knowledge], hash contains your password, a component called salt or sult and a key. When a database is compromised the salt or sult is compromised but the 128 [I suppose] bits key is not. Without the key you will never know the original password. Because of that developers prefers to store the hash instead of the password you given.
But for email and any other data, it is always encrypted [if it needs more security] and encryption are two way.
Considering the emails were encrypted, certainly it can be decrypted. I believe the team is still trying to mislead everyone or the person behind the account do not have such knowledge.
By the way, I do not have latest knowledge about the tech but anyone who is trustworthy and have programing knowledge, can confirm if I have mistaken anything to explain hash.
Let's make it simpler.
Encryption is two way because you always need the original data to perform the functions you have associated with it.
In a web form password can be encrypted or hashed. Hash is one way. If I am not wrong [from my outdated knowledge], hash contains your password, a component called salt or sult and a key. When a database is compromised the salt or sult is compromised but the 128 [I suppose] bits key is not. Without the key you will never know the original password. Because of that developers prefers to store the hash instead of the password you given.
But for email and any other data, it is always encrypted [if it needs more security] and encryption are two way.
Considering the emails were encrypted, certainly it can be decrypted. I believe the team is still trying to mislead everyone or the person behind the account do not have such knowledge.
By the way, I do not have latest knowledge about the tech but anyone who is trustworthy and have programing knowledge, can confirm if I have mistaken anything to explain hash.
Ahh, well... if I may pull a guess from a hat, they'll probably go with how they're basically stripped to bare minimum staffs, where they don't have access to any system or services. Thus, they don't have the way to extract a decrypted data containing the emails. I guess, in layman terms, the way they propose to verify an email address is by manually typing [email protected] into whatever they have right now, and that bare-minimum system will tell them if that email address is indeed was in the cluster or not.
[...]
We will no longer waste time answering made-up facts. We will act and implement what we have announced in several previous posts.
We will no longer waste time answering made-up facts. We will act and implement what we have announced in several previous posts.
Umm... you do aware that though the post being quoted by BitcoinGirl.Club was mine, that was fully intended to be answered by you? I can give my guess, but I'm afraid that'll be considered as a made-up facts. So, the podium is yours.
The front end stored the data [email and password], when it was sending insertion query to the database it encrypted the data. Anyone with direct access of the database can not read the data. It make sense.
When the front end is retrieving the data [email and password], it's reading the encrypted data and decrypting to perform different functions [checking user when sending login request, password reset, user information and many other things].
Betnomi have the same casino script [functional front end], and the database. Where is the problem?
When the front end is retrieving the data [email and password], it's reading the encrypted data and decrypting to perform different functions [checking user when sending login request, password reset, user information and many other things].
Betnomi have the same casino script [functional front end], and the database. Where is the problem?
Let's make it simpler.
Encryption is two way because you always need the original data to perform the functions you have associated with it.
In a web form password can be encrypted or hashed. Hash is one way. If I am not wrong [from my outdated knowledge], hash contains your password, a component called salt or sult and a key. When a database is compromised the salt or sult is compromised but the 128 [I suppose] bits key is not. Without the key you will never know the original password. Because of that developers prefers to store the hash instead of the password you given.
But for email and any other data, it is always encrypted [if it needs more security] and encryption are two way.
Considering the emails were encrypted, certainly it can be decrypted. I believe the team is still trying to mislead everyone or the person behind the account do not have such knowledge.
By the way, I do not have latest knowledge about the tech but anyone who is trustworthy and have programing knowledge, can confirm if I have mistaken anything to explain hash.
[...]
We will no longer waste time answering made-up facts. We will act and implement what we have announced in several previous posts.
We will no longer waste time answering made-up facts. We will act and implement what we have announced in several previous posts.
Umm... you do aware that though the post being quoted by BitcoinGirl.Club was mine, that was fully intended to be answered by you? I can give my guess, but I'm afraid that'll be considered as a made-up facts. So, the podium is yours.
@Mahdirakib, you don't remind me of a spammer, but based on the nature of our discussion, I find some of your answers not very logical, and filled with vanity. I hope you understand that this is an Internet forum, and coherence in thoughts is also important here.
First, please point out in our original statement where we stated that "the partnership was terminated, and I run it alone in a profitable way." Of course, it doesn't exist. Even so, explain the train of thought or the logic you followed to arrive at that conclusion.
Second, it was clearly stated that, there were backroom deals made with some employees and the other owners (partners). Employees meaning not one person but specifically includes the other developer who had production database access. Again, another made up and nonsensical statement.
Third, you somehow insist definitively that the database was sold "(actually sold)". In our original statement, it was clearly stated that it was compromised or potentially sold. But no, that doesn't support the narrative you want to promote, so you just make it up out of thin air.
I did not have access nor do I know the whereabouts of the database, but I know a third party, someone, got access to it. For this, I concluded that it was either compromised or sold, just like any reasonable person would.
We will delete anything we consider as spam or abuse in our Telegram group, and about trust settings, I am absolutely sure that this is a personal forum setting that everyone can use at their own discretion. This setting does not affect you or anyone except me and the feedback I see.
We will no longer waste time answering made-up facts. We will act and implement what we have announced in several previous posts.
First, please point out in our original statement where we stated that "the partnership was terminated, and I run it alone in a profitable way." Of course, it doesn't exist. Even so, explain the train of thought or the logic you followed to arrive at that conclusion.
Second, it was clearly stated that, there were backroom deals made with some employees and the other owners (partners). Employees meaning not one person but specifically includes the other developer who had production database access. Again, another made up and nonsensical statement.
Third, you somehow insist definitively that the database was sold "(actually sold)". In our original statement, it was clearly stated that it was compromised or potentially sold. But no, that doesn't support the narrative you want to promote, so you just make it up out of thin air.
I did not have access nor do I know the whereabouts of the database, but I know a third party, someone, got access to it. For this, I concluded that it was either compromised or sold, just like any reasonable person would.
We will delete anything we consider as spam or abuse in our Telegram group, and about trust settings, I am absolutely sure that this is a personal forum setting that everyone can use at their own discretion. This setting does not affect you or anyone except me and the feedback I see.
We will no longer waste time answering made-up facts. We will act and implement what we have announced in several previous posts.
What is stopping you to send the email to the users existed with the version of database you have right now? Just a simple email blast, follow a few more to ensure everyone read the email. I will be checking my email.
Because for some reason, they can't decrypt it... apparently.
We can't send mass emails because they are encrypted, and no, before you ask, it is a one-way encryption.
The front end stored the data [email and password], when it was sending insertion query to the database it encrypted the data. Anyone with direct access of the database can not read the data. It make sense.
When the front end is retrieving the data [email and password], it's reading the encrypted data and decrypting to perform different functions [checking user when sending login request, password reset, user information and many other things].
Betnomi have the same casino script [functional front end], and the database. Where is the problem?
@holydarkness, you have a point, and certainly an interesting one.
But to answer your question, we do not upload nor store KYC data on our servers. We do not view or do anything with the information directly.
Rather, we use a third-party service called Veriff. [...]
But to answer your question, we do not upload nor store KYC data on our servers. We do not view or do anything with the information directly.
Rather, we use a third-party service called Veriff. [...]
Which you no longer has access, according to your own statement, or were you trying to say Veriff is an exception and you still have access to the service they offered?
[...] From this point, I no longer had access to any system or services. [...]
What is stopping you to send the email to the users existed with the version of database you have right now? Just a simple email blast, follow a few more to ensure everyone read the email. I will be checking my email.
Because for some reason, they can't decrypt it... apparently.
We can't send mass emails because they are encrypted, and no, before you ask, it is a one-way encryption.
Regarding the suggestion to send an email to users, this is clearly the most effective way to resolve this issue. However, as we mentioned in our initial statement, we do not have access to the database. We do have a limited version of the database that is shared with regulators for compliance purposes. If we had access to the actual site database, we would simply restore the site and allow users to withdraw their funds directly. Unfortunately, this is not the case, and we can only do what we can with the resources available to us.
What is stopping you to send the email to the users existed with the version of database you have right now? Just a simple email blast, follow a few more to ensure everyone read the email. I will be checking my email.Code:
2. Username (request will be ignored if the username does not exist)
3. Email address (request will be ignored if the email does not match)
Betnomi Refund Plan
Code:
1. First name, Last name (if you are KYC verified)
2. Username (request will be ignored if the username does not exist)
3. Email address (request will be ignored if the email does not match)
4. Refund Amount (approximate balance is acceptable)
5. Wallet address (we will process only in the cryptocurrency you have)
This whole thing has more holes than Swiss cheese.
If someone has their database, they do not have access to the email of the users yet.
The refund email still has to be sent from the registered emailaddress and ofcourse only the user himself can do this.
I have no idea, pretty hard still I think. But even if they manage it, if there are 2 emails sent claiming the funds, then ofcourse Betnomi should investigate.
Betnomi Refund Plan
Code:
1. First name, Last name (if you are KYC verified)
2. Username (request will be ignored if the username does not exist)
3. Email address (request will be ignored if the email does not match)
4. Refund Amount (approximate balance is acceptable)
5. Wallet address (we will process only in the cryptocurrency you have)
This whole thing has more holes than Swiss cheese.
If someone has their database, they do not have access to the email of the users yet.
The refund email still has to be sent from the registered emailaddress and ofcourse only the user himself can do this.
Betnomi Refund Plan
Code:
1. First name, Last name (if you are KYC verified)
2. Username (request will be ignored if the username does not exist)
3. Email address (request will be ignored if the email does not match)
4. Refund Amount (approximate balance is acceptable)
5. Wallet address (we will process only in the cryptocurrency you have)
This whole thing has more holes than Swiss cheese.
If someone has their database, they do not have access to the email of the users yet.
The refund email still has to be sent from the registered emailaddress and ofcourse only the user himself can do this.
In June, we faced significant internal challenges related to the company's long-term financial outlook and ownership structure. To address these issues, we temporarily suspended operations and initiated a restructuring process with a focus on long-term profitability. During this time, it became clear that continuing to work with the existing owners was no longer viable, and we terminated the partnership.
the production database access was limited to a single developer and myself with root access.
~snip~
At this point, we made the decision for the developer with the production database to take a backup and the DevOps engineer to terminate the services. This was the timeframe in which relationships went sour, etc. From this point, I no longer had access to any system or services. There was no technological or inappropriate handling of data in this case. It was purely a human factor. It can and does happen with many organizations. It is not a crime to trust people you work with.
~snip~
At this point, we made the decision for the developer with the production database to take a backup and the DevOps engineer to terminate the services. This was the timeframe in which relationships went sour, etc. From this point, I no longer had access to any system or services. There was no technological or inappropriate handling of data in this case. It was purely a human factor. It can and does happen with many organizations. It is not a crime to trust people you work with.
Based on your initial statement, there were more owners of Betnomi beside you. And you had terminated the partnership with other owners to run it alone in a profitable way. You were blaming the other owners for the database leak (actually sold). But today you have said that, there was only one developer who had access to the production database except you. So, the 'existing owners' was a misleading part in your main post. Therefore, users database was either sold by you or the single developer. You are addressing users email address as private information, but it was sold to unknown authority for your irresponsibility. Because, you wanted to save money for ....
There are a lot of "why", but give the answer of these two questions for now
• Why were you deleting the messages from telegram group and banning those users who were asking about the issues?
• Why had you added those users to your 'distrusts list' who left negative feedback on your profile?
Don't blame other people (owners/partners/developer) for these again.
[...] IMO, they will back to the industry but using a different brand name. [...]
That's their intention,
[...] Therefore, we have decided to permanently cease operations and stop using the Betnomi brand in our best interests.
Over the past two years, we have developed our own casino software, risk management engine, and other valuable intellectual property worth millions of dollars. We intend to leverage this expertise to rebuild a stronger brand in the future.
[...]
Over the past two years, we have developed our own casino software, risk management engine, and other valuable intellectual property worth millions of dollars. We intend to leverage this expertise to rebuild a stronger brand in the future.
[...]
[...] From this point, I no longer had access to any system or services. [...]
Whatever we have now is what we uploaded to the Curacao regulators. It has everything we need to be able to verify the information needed for the refund except for the email addresses. However, we have encrypted email logs from a promotion we ran sometime ago. We have our own ways to manually encrypt the submitted emails and run them against the logs to verify them. We can't send mass emails because they are encrypted, and no, before you ask, it is a one-way encryption.
Whatever we have now is what we uploaded to the Curacao regulators. It has everything we need to be able to verify the information needed for the refund except for the email addresses. However, we have encrypted email logs from a promotion we ran sometime ago. We have our own ways to manually encrypt the submitted emails and run them against the logs to verify them. We can't send mass emails because they are encrypted, and no, before you ask, it is a one-way encryption.
Ok, so basically, as what you have right now is what you uploaded to Curacao regulators [except for the email because you deemed it very private] and it's what'll be used to verify the information needed for refund, wasn't it imply you uploaded the first and last name of your users?
You didn't have access to the email addresses because you did not upload them to Curacao regulators, because it's very sensitive and needs to be protected with the degree that is possible, but something that's far more sensitive and literally zeroing into the specific person, their KYC data, you're fine with it being uploaded to the regulators?
I am not saying email address is not private. I am saying there's something more private that needs to be protected. One can make an email address that barely reflect to their identity, but a first and last name and KYC details, one can't fake that. To explain further suppose my first name is Santa and my last name is Claus, there's no one that can prevent me from creating an email address named [email protected], this email address barely gave any clue and privacy risk of me, Santa Claus. That one you protect with the highest degree possible, but my ID is free to be shared?
I don't understand. I believe I understand something wrongly?
For now people doesn't care about their newly launching plan but rather they are looking for the refund process to happen. Gaining trust maybe hard for them to gain again so this is a lot of work that need to fix up so they can regain back their reputation from people in this forum/
Yes as I said before, it seems like everyone will focus on the refund issue so after everyone has got their money, then they will talk about their new project and how they can gain trust again in this forum even though it will definitely be very difficult, but Lately there have also been casino sites that use betnomi templates and icons but I'm not accusing them of having released a replacement site, I'll have to put that aside at least until everyone gets their money back.There's definitely a lot that needs to be fixed to process all refunds, whether it's true or not everyone will definitely be waiting for the latest news from the OP in this thread at least it can make Betnomi users who have funds previously there can be returned immediately, I know this is difficult but I'll be even more curious with their progress through this thread.
For sure there are doubts to use their new casino but if they show some great changes especially with the people working it also in support side maybe it can change the doubts to trust. For now they should be true to their words about the refund since this is what people looking forward to them. If they can do it in short period of time without any delays and all of affected users will get their money then it maybe a game changer for them.
For now people doesn't care about their newly launching plan but rather they are looking for the refund process to happen. Gaining trust maybe hard for them to gain again so this is a lot of work that need to fix up so they can regain back their reputation from people in this forum/
For now people doesn't care about their newly launching plan but rather they are looking for the refund process to happen. Gaining trust maybe hard for them to gain again so this is a lot of work that need to fix up so they can regain back their reputation from people in this forum/
Actually, Betnomi casino is just fine before they shut down. The only issue with their reputation now is only the shutdown while there's still players balance trap in there. Aside from that, there's no known scam accusation against them regarding their service in general. Their reputation can be easily fixed once they refund all the users funds and probably compensate them due to the long term of funds holding.
They are much better unlike other casino here that still active while there's bunch of scam accusation against them. At least on Betnomi, we might understand how this happened due to internal conflict and not that they want to cheat to customer using their service.
@Mahdirakib, it is okay to be wrong sometimes. You don't always have to be right.
You have persistently made unfounded claims that went unchallenged. Our goal is not to mindlessly argue about trivial things. We have a complicated and delicate situation on our hands, and we are doing our best to resolve it. If you have constructive criticism or something useful to contribute, we welcome it. However, personal attacks and name-calling are unproductive.
As for questions regarding the database, let me clarify those.
We use AWS RDS cross-region with a disaster recovery plan in place. Also, we had a secondary ClickHouse database that operated as our data warehouse. It is not that we had a single instance database and lost it overnight. That is not possible with the sophisticated system architecture we had in place, and the production database access was limited to a single developer and myself with root access.
When we suspended our operations, we had to terminate some of our AWS resources because these services cost several thousands of dollars in monthly expenses. It doesn't make sense to keep them running when they are not being utilized.
At this point, we made the decision for the developer with the production database to take a backup and the DevOps engineer to terminate the services. This was the timeframe in which relationships went sour, etc. From this point, I no longer had access to any system or services. There was no technological or inappropriate handling of data in this case. It was purely a human factor. It can and does happen with many organizations. It is not a crime to trust people you work with.
The limited backup we have; the Curacao regulators require you to upload specific information to them once a week. This includes user ID, username, email, balance, last login date, IP, transactions, etc. They need to keep a copy on their own servers to be able to verify reports made by users against our claims. This is a must for every casino operator licensed with them.
Of course, we complied with this process, however, there was some information we deemed unnecessary and sensitive enough where the risk of sharing it outweighed the benefits. Such information would include the users' email addresses. We thought it was important that we protect our users' email addresses from third-party systems, not only with the Curacao regulator but even slots aggregators and sports providers.
We only share usernames and user IDs for identification and never email addresses. They are private and should be protected to the degree that is possible.
Whatever we have now is what we uploaded to the Curacao regulators. It has everything we need to be able to verify the information needed for the refund except for the email addresses. However, we have encrypted email logs from a promotion we ran sometime ago. We have our own ways to manually encrypt the submitted emails and run them against the logs to verify them. We can't send mass emails because they are encrypted, and no, before you ask, it is a one-way encryption.
You have persistently made unfounded claims that went unchallenged. Our goal is not to mindlessly argue about trivial things. We have a complicated and delicate situation on our hands, and we are doing our best to resolve it. If you have constructive criticism or something useful to contribute, we welcome it. However, personal attacks and name-calling are unproductive.
As for questions regarding the database, let me clarify those.
We use AWS RDS cross-region with a disaster recovery plan in place. Also, we had a secondary ClickHouse database that operated as our data warehouse. It is not that we had a single instance database and lost it overnight. That is not possible with the sophisticated system architecture we had in place, and the production database access was limited to a single developer and myself with root access.
When we suspended our operations, we had to terminate some of our AWS resources because these services cost several thousands of dollars in monthly expenses. It doesn't make sense to keep them running when they are not being utilized.
At this point, we made the decision for the developer with the production database to take a backup and the DevOps engineer to terminate the services. This was the timeframe in which relationships went sour, etc. From this point, I no longer had access to any system or services. There was no technological or inappropriate handling of data in this case. It was purely a human factor. It can and does happen with many organizations. It is not a crime to trust people you work with.
The limited backup we have; the Curacao regulators require you to upload specific information to them once a week. This includes user ID, username, email, balance, last login date, IP, transactions, etc. They need to keep a copy on their own servers to be able to verify reports made by users against our claims. This is a must for every casino operator licensed with them.
Of course, we complied with this process, however, there was some information we deemed unnecessary and sensitive enough where the risk of sharing it outweighed the benefits. Such information would include the users' email addresses. We thought it was important that we protect our users' email addresses from third-party systems, not only with the Curacao regulator but even slots aggregators and sports providers.
We only share usernames and user IDs for identification and never email addresses. They are private and should be protected to the degree that is possible.
Whatever we have now is what we uploaded to the Curacao regulators. It has everything we need to be able to verify the information needed for the refund except for the email addresses. However, we have encrypted email logs from a promotion we ran sometime ago. We have our own ways to manually encrypt the submitted emails and run them against the logs to verify them. We can't send mass emails because they are encrypted, and no, before you ask, it is a one-way encryption.
Jump to: