|
hello all,
just checked this morning and the bonus part 'get extra 100% bonus on minimum of 0.456LTC deposit' is no longer present on the deposit page.
evidently someone has seen the flaw in having it there after the first deposit and it has been removed.
i have not heard from any bc.game staff, so im guessing someone saw that it might actually be a legitimate conflict of interest.
james
|
|
|
|
|
Ah, it appears that on the 23rd September 2023 they have changed many of their bonus terms and conditions.
Regarding hero level, I'm a programmer.. I see red all day (in terms of bugs, not red streaks..) - at the end of the day I enjoy relaxing, which includes throwing a few bucks around.
If i were to suddenly change the behavior of any code that I developed, I would do so by changing prompts and the user experience - not by tucking something away 'at the back'.
I do this even for my own sake, to prevent the phone lighting up.
Many sites I've used in the past have had deposit bonuses, where it certainly isn't limited 'to the first deposit' (which also conflicts with support saying that instead, 'you must deposit on Tuesday or Thursday').
I've since heard that there are quite a few people who are less than happy with the unexpected change at bc.game; unfortunately I don't think I will see a resolution.
james
|
|
|
|
|
Well sure.
If there was a 'first deposit only' bonus, then the message wouldn't appear on the deposit page after the bonus has been claimed.
The first deposit bonus was claimed, yet the message is still there each time.
Nothing more to it.
Not even trying to imply or deceive here.
If they don't intend to give a bonus, then remove this message.
|
|
|
|
Hi all,
Not quite sure if this is common knowledge yet, but bc.game is doing everything possible to avoid paying the deposit bonus that shows on the deposit page.
I've raised the issue several times with support, with responses ranging from 'its only the first deposit bonus' (why is it listed on each deposit page?), to 'issue has been reported' and finally 'you must deposit on tuesday and thursday'.
Seems fairly simple to me, can someone from bc.game reach out to resolve this?
james
But do you claim already their first 100% bonus on different currencies? Maybe you manage to claim and successfully clear the wagering requirements that’s why they are trying to restrict you on their bonus promotion. The latest screenshot you provided is incomplete. Please upload complete conversation because the support might answering a previous message of yours containing information related to his answer. You just trim the conversation on the answer of the support then your last post meaning support post is not a response to your last message. But bc really received a lot of complaints about bonuses and withdrawals lately. I understand what you're saying, but to be blunt it is spelled out on the deposit window (above): 'Get extra 100% bonus on minimum of 0.459 LTC deposit'. I didn't receive the bonus, there is literally no way around it. If they want to bury some fineprint off in another page sure, however theres nothing indicating that (asterisk etc). Not to mention, if thats how they are going to do things - I'd rather not know about their dishonest tactics and not play there whatsoever. I will upload the conversation in its entirety. (edit for clarity: I did receive the first deposit bonus, no issues there. However, there is no indication that this stops. The bonus message ('Get extra 100% bonus on minimum of 0.459 LTC deposit') is present to this second. This is a lock, no wiggle room). |
|
|
|
 I would advise someone from bc.game to reach out, if this is the sort of response support gives then clearly there is no honest intentions here. |
|
|
|
Wasn't allowing the image in the first post for some reason.  |
|
|
|
|
Hi all,
Not quite sure if this is common knowledge yet, but bc.game is doing everything possible to avoid paying the deposit bonus that shows on the deposit page.
I've raised the issue several times with support, with responses ranging from 'its only the first deposit bonus' (why is it listed on each deposit page?), to 'issue has been reported' and finally 'you must deposit on tuesday and thursday'.
Seems fairly simple to me, can someone from bc.game reach out to resolve this?
james
|
|
|
|
|
Hi all,
Is there any known issue in regards to the deposit bonus at bc.game?
Might be a temporary issue on my account which I've put to support.. anyone else had this problem?
james
|
|
|
|
|
Bc.game has hit the wall hard.
They started to take back the bonuses and incentives they were offering players around mid last year.
It started with a 20% decrease of player bonuses like level rewards weekly and monthly bonuses also being reduced.
Affiliate commissions have also been affected with a reduction in the % your affiliates wager gives you.
They haven't even been paying me the USD level rewards for my affiliates when they level up and I am ignored when I try to get answers or heaven forbid have it fixed.
Many players have reported their bc.game accounts being hacked.
Upon reaching out to support for help are either completely ignored or finding their accounts being rendered useless, with banking features being disabled and left in this state indefinitely and again radio silence from support.
Bc.games most embarrassing incident occurred last March, where some players suddenly found their balance had hundreds of thousands of dollars showing!
Many people were fast acting and withdrew as much as they could, within 3 or 4 minutes the site went offline.
I know many people whose balances went the other way because of this "bwlwnce glitch" experiencing issues with their balances not displaying correctly and losing funds.
To this day 2 months later there are players whose cries for help to support or vip hosts, mods and admins have been totally ignored.
Bc.game staff just completely ignore any request for help and are happy to leave players in a state of loss not to any of the players own fault but bc.games.
Bc lack of player care or appreciation has no bounds, they have now stooped to an all time low with removing rakeback completely and players who had any banked up losing these funds if they didn't claim them before the removal was initiated.
Recently only last night or so the head honcho "Coco" appeared in chat asking players if they had any PEPE coin they could buy.
Not only is this a breach of the chat rules and warrants being banned for asking for loans or tips etc but it's just a slap in every player who has been loyal to this sites face.
Chat obviously blew up with a virtual angry mob style attack and as expected due to lack of any backbone whatsoever "Coco" made a fast exit.
It's funny that any admin or higher level of mod on Bc.game is SVIP, Coco being SVIP55.
Which is fine except for the fact they have taken so much from players now, all while VIP hosts are receiving $70k and upwards in bonuses being given NFTs.
Yet ask any player with a VIP host and 9 out of 10 they will say their host gives nothing back to them or very little if anything at all.
I used to recommend Bc.game even when I lost, as it was a solid place to invest your loyalty over time.
Now I feel as a player who joined the same month they opened and remained an active loyal frequent depositor with a semi high level of VIP59 I should be letting people know what has become of this once amazing casino.
My conscience would weigh heavily if I weren't to tell people to stay away from bc.game atm, at least until they fix their security flaws and implement better bonuses systems and return rakeback to their players.
Their lack of human empathy and clear pure desire to take from players to make their already fat pockets fatter is truly disgusting.
Do not play at bc.game, you will regret it.
Date of experience: May 09, 2023
|
|
|
|
It's simply a fact that Python is slow; it's an interpreted language. 10 to 15 minutes may still be acceptable in this case, but what if you need to analyze 1 million private keys?
python can handle 1 million private keys. Or do something more complex with fewer keys?
like what? what would someone be needing to do exactly? other than make a vanity address or crack a bitcoin address. The same program in C or Rust can easily run 10-100x faster; so instead of 3 months a program would run for a day. That's quite significant.
i'm sure the cpu makes a difference too. get a high end cpu and run python on it and it will be just as fast as a low end computer running c. there's optimizations to be made everywhere not just in software. or just use the same types that bitcoin provides: https://github.com/bitcoin/bitcoin/blob/master/src/arith_uint256.hhttps://github.com/bitcoin/bitcoin/blob/master/src/uint256.husable in any c++ program once trimmed down, to 2-3 files. |
|
|
|
This is probably a very newbie question, but is there a way that I can monitor the hashes and or candidate blockheaders that my BTC Antminer is sending back and forth to a pool? Can this be done just by observing the communication traffic on my subnet or would I have to go through the pool to view this?
In the paper 'Hardening Stratum, the Bitcoin Pool Mining Protocol', it seems like they are able to view this traffic, eg Figure 4. How would one set this kind of a view up? I'm good with dealing with the data side, it's the networking aspect. I'm interested in observing the difficulty of hashes that my miners are outputting, but with more depth than most mining pools I have been on provide.
very easily, you simply need to place a tcp proxy inbetween your miner and the pool. i use this one all the time ( https://voorloopnul.com/blog/a-python-proxy-in-less-than-100-lines-of-code/), you simply modify the host/port at the top, then the listening interface at the bottom. |
|
|
|
|
have been waiting 6 hours now for a withdrawal of 3.43LTC,
no response, nothing.
why would a dice site have manual withdrawals?
james
|
|
|
|
and? this doesnt prevent you from running it, although it does suggest you should try a compiler thats a bit more recent that 2015  |
|
|
|
as long as you can produce correct nbits for the next block (15 lines of c++), validate the previous header hash (using openssl lib, 5 lines of c++), you can test to see whether the blockheader you received is indeed accurate. I didn't mean this. Sure, you can write a program that checks the validity of the block header, but if you haven't verified the entire chain until that point, you can't know for sure what's the previous block hash or if a transaction double-spends etc. not including transactions (since you wouldnt know or be listening for txes) would actually improve your chances of nailing a block. Yes, but it's little matter when it comes to earning millions of sats in fees. understood, sure. however given bitcoin's difficulty, it would be highly unlikely for some party to solve a blockheader where the contents were invalid (and you could easily test this). additionally, if you let a spv program run for a little while before starting your stratum up... it would be trivial to test if the 'blocks heard' did in fact form a legitimate chain. prevhash being the sha256d of the previous block.. easy to check (edit) in fact, the most difficult part would be determining the block height - this is indeed part of the coinbase tx (bip34).. but you dont have access to it if you are just listening to headers.. you'd have to have this info ahead of time james
The timestamp difference is likely not 3 minutes, though that would be indicative of some sort of block withholding/selfish mining but I highly doubt so. It is far more likely for an inaccuracy between the timestamp. From my past experience, my node always received the blocks within ~1-5 seconds of each other which is congruent with the propagation time of the network. You can still use the timestamp as a variable if for some reason you need it though.
The main problem with SPV mining (or mine now, validate at the same time) was the major fork back in 2015 by the various larger pools which has largely resulted in a huge income loss by the larger pools. If you read back on the issue and the topic at that time, they actually didn't really care if they validated the block or not which resulted in a total mess that the community had to deal with. The point at that time was that they wanted to gain an edge over the others, not because of bandwidth constraints. It simply made more sense to just get a server that does it for you or to just join a pool. The profits from the block transaction fee far outweighs the cost.
I highly doubt that any farms would bother to not include transactions because those up/down speed would be okay for stratum, considering the fact that you can still cut down on unnecessary transmissions to the pool. It is still faster and more cost efficient to rely on an external server to compile and feed the data instead of pure SPV mining. With that in mind, most of the larger miners/pools used to use Bitcoin Relay Network or now known as FIBRE but I'm not sure if its still in use or replaced again. They actually do have an edge over the others by that alone though SPV mining was a prominent practice at that time. I think there was some proof that it actually didn't really made sense now with all the optimizations.
Also, at some point in time, the empty blocks might've been due to covert ASICBoost but it isn't happening now that overt ASICBoost is so prominent.
P.S. I don't think intentional sabotage is likely because that is quite expensive in the first place, only happened once accidentally.
do you have any links for the 2015 event? i dont recall this, but could be wrong.. bitcoin has always validated the block contents and transactions before accepting it. james |
|
|
|
when a pool makes a blocksolve it knows it has a bit of time to quickly work on another block while the network is propagating its first block. so instead of wasting time collating transactions to make a new blockheader it just begins a 'empty block' and as the asics run through the first few rounds of their nonce/extranonce. the pool then starts adding transactions into a blocktemplate for the next header to send in the next round of hashing once then finished their attempts.
Actually almost all the time it is another pool that miners the empty block because they are "spy mining" and get the successful header before the block is even propagates and start working on the next block right away. Otherwise if it is their own block they don't need to "collect transactions" since they already know what transactions were included in that previous block. This case could be the same too considering the coinbase string in the two blocks are slightly different (one has "Mined by unp1" and the other doesn't) that could mean 2 stand-alone servers. oh and the '3 minutes' is not actual 3 physical minutes. its a use of the timestamp to add some extra 'nonce' possibility.
If the block is empty why would they change time, it is not like they have to compute merkle root hash by computing a thousand hashes?! this is what i was alluding to. back in 2015 i personally watched antpool mine 4 blocks on top of each other without relaying the blocks to the network. this is possible by listening to their stratum.notify and watching prevhash change, while the network doesnt change. james
worth mentioning as well, back in the day there would often be bitcoin mines setup with rigged power out in the expanse of china.. with the WAN link being an old 2g mobile phone. the max send rate on 2g being around about 0.05-0.1megabit/sec (so 5-10kilobytes/sec). with even a half megabyte block taking up to 1.5 minutes to get out onto the network, you can see why blocks with only the coinbase txn were mined. james
Another possibility is the stratum/pool mining software responsible for this block is not connected to a full node, rather a lite or SPV node. To build a valid block, you really only need to know the previous block hash, the height and the coinbase reward. Running a bitcoin node again, is quite resource intensive - and the disk space alone is 405Gb (standard, not txindex) - I can fully see a situation where some clever software simply listening to the headers could work. But, running a full node is a necessity if you want to be accurate and sure. Listening to an SPV node increases your chances to be beaten in propagation as you receive the info later than the others. (And you're trusting an entity that can set you up) as long as you can produce correct nbits for the next block (15 lines of c++), validate the previous header hash (using openssl lib, 5 lines of c++), you can test to see whether the blockheader you received is indeed accurate. not including transactions (since you wouldnt know or be listening for txes) would actually improve your chances of nailing a block. james |
|
|
|
|
Not an accident at all.
There really isn't any incentive to include transactions in blocks.
It's a modest amount of processing power required to test, pick and commit transactions to block (nearly a quarter of the bitcoin codebase is dedicated to this).
On top of that, if the node is behind a slow WAN connection - the time to propogate the block across the network could very well mean it is beaten by a more responsive node.
You could argue that the fees are the incentive to include them in a block, but when you are talking 6.25BTC ($184,000 USD) as the base - some aren't bothered by this.
Another possibility is the stratum/pool mining software responsible for this block is not connected to a full node, rather a lite or SPV node. To build a valid block, you really only need to know the previous block hash, the height and the coinbase reward. Running a bitcoin node again, is quite resource intensive - and the disk space alone is 405Gb (standard, not txindex) - I can fully see a situation where some clever software simply listening to the headers could work.
There are much more devious reasons as to why the block has no transactions, but will leave them to the readers imagination.
The majority of it stopped around April last year (2021) *cough*.
james
|
|
|
|
probably not going to be the code that finds it, but i notice people have posted python here so.. https://github.com/barrystyle/b58is currently hardcoded for #64, on my 11th gen i7-1165g7 manages around 124,000 keys/sec. matches using the hash160 rather than the full base58 address for speed. james |
|
|
|
Every company is for surely keeping our email addresses and they've got a lot of purposes on it. And it's not just the companies that we used to sign up are the ones keeping it.
If there's someone who get to see it and they have ideas and database of keeping it, they'll sell it to the other parties. That's why we have no idea where these ads and promotions are coming from despite we just signed up for a few websites before.
This had been happening for long now without our consent, our private documents can be sold out without the prior permission of the owners. Just image little bride in the data of those companies holding out emails and private documents. All this can be exposed to the public or sold out to third parties which can be used to harm without we knowing how come it happens. I am very conscious when I am giving out my information to websites or companies that ask for it. This is the major reason why I don't always support the use of exchanges especially those ones that ask for other identity information from customers. what we can do is just limit the info that we disclose in these sites. as much as possible use a different email if you feel it is not for long-term usage. because using only one email in most of your transactions will subject you to high likelihood of being pawned or attacked by unnecessary actors from the net. those collected data - of course, we don't know where they will end up with. so be cautious also on the unsolicited links sent to you. better discard it without opening the mail if you know it is just a spam. simple. go buy a domain name from a service that offers an email forwarder (i know namecheap offers this, probably quite common place now). then point it at your regular email address. when you start getting lots of spam or too many promotional posts, remove the entry and create a new one - again, pointing at your regular email. have done this for years and has worked a treat. james |
|
|
|
|
has anyone tried porting this up to the latest bitcoin codebase etc?
james
|
|
|
|
|
Show Posts
