Introducing BOB

General
65

Do not trust the link above, it is phishing.

67

I’ve been looking into candid of “Mother canister” https://dashboard.internetcomputer.org/canister/6lnhz-oaaaa-aaaas-aabkq-cai

There is only 3 “update” methods:

  1. migrate_tokens - seems we need it only to migrate BOB (old) to BOB
  2. spawn_miner - seems like this spawns “miner” canister(s)
  3. submit_burned_cycles - this is the only place where miner can report how many cycles were burnt

There is 2 update methods on the “miner” canister

  1. push_challenge - seems like mother canister notifies the miners about the new challenge
  2. update_settings - to update cycles/day and to transfer ownership of miners to different “mother” canister.

Takeaway 1:

I am not sure what hashes are being caluclated inside miner canisters, but I don’t think the mother node cares about the correct answer and who gets it first. I think it only cares who burned the most of the cycles.

This contradicts to their description on bob.fun

  • Main computers (mother nodes) give out these problems.
  • Miners solve the problems and tell the mother node.
  • If correct, the mother node adds a new block to the blockchain.

Mother node doesn’t care if the problem is solved or not, it just gives a task and waits for miner to submit how many cycles were burned.

Takeaway 2:

There is no way to deploy your own miner. All the miners are being deployed from the “mother” canister. It’s not possible to write your own miner canister:

Screenshot 2024-09-12 at 04.37.18
Screenshot 2024-09-12 at 04.37.182486×448 133 KB

Takeaway 3:

I think that this is the reason they do not release the source code for mother and miner. I think that the code is not (yet?) fully doing what it is supposed to do.

I also think that if the devs wanted to quickly pre-mint a bunch of bob tokens for themselves, they could deploy “fake” miners that would report really high usage of the cycles once every 400 seconds or so :slight_smile:

6 Likes
68

Another potential challenge I could see here is:

Even if the system was working fully, allowed any miners accessing it and verified computed hashes, how would you verify that the computation was indeed done on-chain and not off-chain.

What i mean is:

  1. mother gives challenge: find a salt for previous blockhash, where the resulting hash starts with 0xb0b0b
  2. attacker miner, instead of doing expensive computation on internet computer node cpus just off-loads computation to a gpu farm off-chain and then just submits a result? This would go out of hand super quickly.
5 Likes
69

Is there any way to query what outstanding calls are and who they are waiting for?

70

Very interesting information.
I don’t think it selects the miner with the most burnt cycles, but it probably takes the cycle burn rate information on a weighted random curve to decide who to payout to. That’d be the best way to simulate PoW without actually doing PoW in my opinion.

3 Likes
71

This would make a lot of sense, But without source code of how the miner is determined, we can only guess.

4 Likes
72

For sure. Hopefully the developer will respond with source code or at least provide an explanation, since it’s honestly pretty suspicious.

73

I’ve attempted to up the compute to 17 which was as high as it would go just to see if I might be able to brute force it. But it doesn’t seem to be budging.

76

My observation is:
If there are more than 600 Tx/s in the European Subnet, it is no longer possible to load a 600 KB image data from a Motoko canister.

So I ask again, what is the aim? To block all other canisters? Has nobody had this or similar observations?

77

There is no API for that.

If you could explore a checkpoint, there are protobuf files in there that contain the open call contexts, callbacks, message queues, etc. But the checkpoint can only be accessed by a node operator. And this is only ever done for subnet recovery / debugging.

78

Pretty sketch really. I set up 3 miners on day one and they took 8 hours to start mining. Then the shutdown happened and lasted almost a day. My cycles were burned and canister addresses were changed. What happened to my original canisters and the blocks they may have mined?

1 Like
79

I have feeling that BOB devs are same as Windoge98

1 Like
80

This is not a scam!!! I mined a block! yay!!!

Screenshot 2024-09-12 at 22.48.36

7 Likes
81

Will we be able to get this once snapshotting is turned on?

82

Will we be able to get this once snapshotting is turned on?

Probably not.
In the current version of snapshotting this is not possible. The snapshots are on-chain, and stay on-chain.

There are plans for future extensions of snapshotting that include downloading and uploading of snapshots, which will open the possibility of investigating these snapshots. But open call contexts are not part of these snapshots, as they wouldn’t make much sense if you restore them a month later. You wouldn’t ever get an answer to these calls.

83

That doesn’t mean anything lol

84

Also, snapshots explicitly drop enqueued messages, call contexts and callbacks because you definitely don’t want your restored canister to hang forever waiting for a response that it already processed; or producing (different) responses to calls it has already handled days ago.

Technically, I suppose that a snapshot could retain all of that and just not restore it, but that’s not how it’s implemented. Nor would it be particularly useful beyond its potential use as a very rough debugging tool.

1 Like
85

Yes…some kind of api would be much better…like the logs functionality. I’m finding lots of instances on this subnet where I’m just waiting around(hours) and being able to debug why and optimize would be nice

1 Like
86

I think folks here may find this interesting: Announcing New Security Best Practices Documentation: Protect Against Denial of Service (DoS) Attacks

3 Likes
87

BOB is going to fall :joy: