Does the BOB token have an index canister?
WE NEED OPEN SOURCING OF CODE. 100x network burn growth without verifying what does the program do. This is insane. Community and Dfinity should be advocating for open sourcing. This is putting us all at risk and there is no way to verify the experience.
“Dfinity” workers are part of bob lol.
What a way of letting us know you missed the train.
Stop the fud please, thanks
I know a lot has been mentioned about open sourcing the code. I 100% support this. The mint data coming in from 221Bravo shows some pretty big mints in the early transactions. There was also 3k tokens minted in a single transaction within the last 24 hours.
The devs are saying this is related to ‘Old Bob’ to ‘New Bob’ migration. There is nothing mentioned about this in the blurb above. There is also nothing on the website explaining how to swap old bob to new bob. There could be 21 million ‘old bob’ for all we know.
I really wish the ‘meme’ developers would up their game. It might as well be running on AWS with all the holes in this one. (PS - I’ve got a couple of miners and a little BOB… not trying to be kill joy!)
FYI - The 3k mint aligned with a move in the ‘old bob’ token which suggests it’s linked to migration. There are 864,577 old bob tokens.
Who cares about code or money. BOB just made crypto fun again after a long bear market. IYKYK
Play the game, don’t let the game play you.
We don’t know who Satoshi Nakamoto is either but just in case Bitcoin ever takes off I want to own some. Same sentiment for BOB.
Nice ninja premine
Yea we need this and a new fair launch with some “old” ninja premine
Its not under SNS control or any other gov mechanism, so dev has total control over the canisters?
At this stage it’s exactly like that @Samer, total control.
I just expect they have a much better vision for this amazing experiment than rug and run.
Bob can be huge.
I see you are the same everywhere @Henry_Suso
This is getting a bit worse. After a few upgrades today with no problem at 1, I started one today and got a ton of ‘stop’ your canister first errors. So I stopped it and it is just hung at stopping. I’ve upped my compute allocation to 4 and I’m still stuck at stopping.
It sounds like we have uncovered a new DDoS attack vector on the IC!
I have to crash. If someone at DFINTY can check backend logs to see what might be going on with auotf-hqaaa-aaaas-aem7q-cai taking so long to stop…it is now stuck in stopping mode and I put the compute allocation up as high as 6. Shouldn’t this schedule me for 6% of the rounds? I’m convinced that there may be some outstanding calls that aren’t getting returned. Maybe it is the BOB canisters itself?
I’ve bumped the compute back down to 1. Last night stopping burned something like 20T+ cycles. Hoping that doesn’t happen again tonight.
I’ll add that it would be really nice if the replica could give some kind of report of how many messages are outstanding so we can identify a run away process:
Error: Failed to install wasm module to canister ‘backend’.
Caused by: Failed during wasm installation call
Caused by: The replica returned a rejection error: reject code CanisterError, reject message Error from Canister auotf-hqaaa-aaaas-aem7q-cai: Canister called ic0.trap
with message: canister_pre_upgrade attempted with outstanding message callbacks (try stopping the canister before upgrade).
Consider gracefully handling failures from this canister or altering the canister to handle exceptions. See documentation: Execution errors | Internet Computer, error code None
So, basically, without the source code and a reproducible build to check the canisters’ module hash, the BOB “mother” canister could just be selecting, between a predefined list of dev’s canisters, which miner will get the next reward.
The devs could also select a few random miners from time to time just to make it look legit.
The miners could just be running a empty for loop with billion iterations as not even the block hashes or the challenges are revealed after computed. Even if they were reveled, without the source-code, they could just be faked as well.
This has NOTHING to do with Bitcoin or Doge. Both are completely open-source and the miners are fairly competing to resolve challenges. The miners are controlled by the owners, not by the dev’s like in BOB. With Bitcoin, each owner can update their miner to, for example, switch to a better hash algo or to implement optimizations to solve more challenges. With BOB? You don’t even own the canister, the controller is the dev’s mother canister.
Don’t trust, verify.
I’m getting timeouts as well when trying to interact with a bob canister through an inter-canister call from a canister on the European subnet.
Maybe it’s time to move off that subnet
Error: Failed update call.
Caused by: The replica returned a rejection error: reject code SysTransient, reject message Ingress message 0x82b33cbc9c31e179cc8eb5f87f7b240382228dfe839124311c41511d92ce1d6a timed out waiting to start executing., error code None
Update: Made a canister that isn’t on the European subnet and tried again. Now one of my canisters that hit Bob is failing to stop as well
Error: Failed to stop canister lazvm-xqaaa-aaaan-qmynq-cai.
Caused by: Failed to call update function 'stop_canister' regarding canister 'lazvm-xqaaa-aaaan-qmynq-cai'.
Caused by: Update call (without wallet) failed.
Caused by: The request timed out.
Luckily I spun up a fresh “test” canister to try this out.
Lesson - don’t integrate directly with Bob or high load subnets or you might get stuck!
@Manu will the new scalable messaging model help stuck canisters in this specific case?
Here is a quick guide how I top up canisters from terminal avoiding paying 0.5 ICP to the bob (I tried to top up via bob.fun interface, it just ate my 0.5 and did not top up the miner canister):
- install dfx toolkit
- create identity
bob-mining % dfx identity new topupper
Your seed phrase for identity 'topupper': clump jelly pause nuclear suspect addict injury rich list success mask finish price area rebuild crime leader flush ignore leg minor easily edit maze
This can be used to reconstruct your key in case of emergency, so write it down in a safe place.
Created identity: "topupper".
- switch to the new identity
bob-mining % dfx identity use topupper
Using identity: "topupper".
- get principal
bob-mining % dfx identity get-principal
l657j-hsgfs-eeb6h-4jvbb-nh7fv-rciml-ug66x-sznuw-4i3tk-cfs75-rqe
- Send some ICP from your wallet to this principal id
- Run this to top up your miner:
dfx ledger --ic top-up --amount 0.2 2r5gw-sqaaa-aaaas-aftuq-cai
Replace 0.2
with icp amount you want to use to top up the miner, replace 2r5gw-sqaaa-aaaas-aftuq-cai
with your miner address.
So far, I deployed 25 miners set at 10T cycles dailiy limit. I’m mining for 24 hours already.
Something just does not add up.
There is 200 blocks produced every 24 hours. There is 3000 active miners mining right now. that means that I should have 200 * 25 = 5000
chances each day to mine a block and my math expectation is to mine (25 / 3000 * 200) = 1.6
blocks every day.
So far I mined zero blocks. Might just be a bad luck, but I wonder did anyone on this forum manage to mine at least one block?