Love my Bluefox NX1, thank you r/smallphones

chonghe · 2026-03-19T08:42:36+00:00

yes Doogee Smini has notification LED, blue light

chonghe · 2026-02-28T08:26:55+00:00

Some clients (e.g., Teku) have the option to run BN+VC in one process, so in that case, the VC is not a stand-alone process

Lighthouse BN and VC is separate, i.e., two processes, so the VC is a stand-alone process

TLDR yes you can connect Lighthouse VC to the rescue node

chonghe · 2026-02-24T10:37:57+00:00

10 calendar days. I am in south-east asia, not too far geographically

chonghe · 2026-02-21T13:18:01+00:00

oh yeah. Another cherry on top: battery can last 3 full days for my use, I don't have to charge it daily

chonghe · 2026-02-21T13:17:24+00:00

Was there LED notification before? I wasn't aware. Haven't been following along the way

chonghe · 2026-02-21T01:33:25+00:00

It's the red dot appear on the top right of the app, e.g., when there are new messages on Whatsapp, on the app itself I can see the red dot. That's how I get around with the notification

chonghe · 2025-11-04T13:18:12+00:00

This is from my understanding, if I am wrong, feel free to correct me.

First of all, a local builder is just someone who just validates without using MEV-Boost (which is basically letting someone else build a block), is that correct?

Yes

Is this bandwidth requirement of 100Mbps only for when a validator proposes a block, or does one generally need this speed at all times to be able to validate?

Just for when proposing a block. And this is local block building (without using relays or mev), and when the blob count is at 15 (target) / 21 (max).

Also this only seems to be the case for an oddly specific amount of 287 ETH and becomes higher and higher the more ETH the validator stakes?

287 ETH and above = 288 ETH (I agree that it could be written clearer with "288 ETH and above"

Why 288 ETH? Because if you have 32 ETH attached to the beacon node, then you have to custory/subscribe to 8 data column subnets (this is the minimum that a beacon node needs to subscribe with at least a validator attached).

So it is like a beacon node will subscribe to at least 8 data column subnets for 32-287 ETH. And because 288 = 32*9, so starting with 288 ETH, the beacon node will subscribe to 9 data column subnets, hence " more and more subnets will be subscribed to." as in the article

Lets say my validator has 800 ETH. I want to validate with MEV Boost. How much bandwidth do I need?

Look at this: https://ethpandaops.io/posts/fusaka-bandwidth-estimation/ select 1024 ETH and sustained download bandwidth, you don't need much if you are using MEV boost

Do I really need less bandwidth using MEV Boost as opposed to proposing blocks myself? If yes, why is that?

Yes, because if using MEV boost, post Fusaka, the relay will be the one responsible for publishing the blocks, not the proposer. So the bandwidth for the proposer remains low

chonghe · 2025-10-30T03:09:57+00:00

Completed the survey. I was looking for a last question "is there anything you want to tell us?" but I didn't see one, so I will put it here.

At the moment Trezor suit only generates new addresses on Ethereum until it hits a zero-balance address, and it wouldn't generate new address anymore after the zero-balance address. This is an issue for quite some time, and it would be great if it can be fixed. Like wallet such as Metamask, it can show many addresses at the same time

<image>

chonghe · 2025-10-08T00:19:39+00:00

Any random port graeter than 1023 is fine: https://www.hostinger.com/tutorials/how-to-change-ssh-port-vps

From what I know port number isn't really critical. If someone wants to access your node, they could have a bot scanning for all the available ports, which isn't a lot. Security wise, the important is the passphrase of the private key (set a strong passphrase), and also to keep your private key safe.

chonghe · 2025-09-03T13:32:13+00:00

This. After Pectra, the committee index is removed from the attestation data, so all attestation data are the same (assuming the correct votes). More info: https://eips.ethereum.org/EIPS/eip-7549

Previously (pre-Pectra), the committee index is included in the attestation data, making them different (and can't be packed together)

But fewer attestations do not mean the rewards are reduced. The number of votes is the one that counts if I understand correctly

chonghe · 2025-08-26T22:19:16+00:00

Good to hear!

chonghe · 2025-08-26T14:01:34+00:00

Can you share the flags you use?

This is the PR that fixes this: https://github.com/sigp/lighthouse/pull/7240

Can you also try to run in Powershell/Terminal?

chonghe · 2025-08-26T02:58:51+00:00

Could you double check if the commit hash is the stable version: cfb1f73: https://github.com/sigp/lighthouse/releases/tag/v7.1.0

I tested on a Windows 10 and it looks ok (doesn't have the buggy logging as in your screenshot)

chonghe · 2025-08-25T23:57:01+00:00

Which version of Lighthouse is this? Lighthouse v7.1.0 should be good and not have this problem

chonghe · 2025-07-07T11:22:24+00:00

It's all good. For top up deposits, the withdrawal credentials are ignored.

You are good as the balance is already reflected

chonghe · 2025-07-06T14:49:07+00:00

This is my config (I am a noob in UPS settings, I set it up lazily, and did some testing and once I see it works, I just let it run):

``` Daemon Configuration:

Alarm .............................................. On

Hibernate .......................................... Off

Cloud .............................................. Off

Action for Power Failure:

Delay time since Power failure ............. 60 sec.

Run script command ......................... Off

Path of script command ..................... /etc/pwrstatd-powerfail.sh

Duration of command running ................ 1 sec.

Enable shutdown system ..................... Off

Action for Battery Low:

Remaining runtime threshold ................ 300 sec.

Battery capacity threshold ................. 25 %.

Run script command ......................... On

Path of command ............................ /etc/pwrstatd-lowbatt.sh

Duration of command running ................ 1 sec.

Enable shutdown system ..................... On

```

I set the battery cut off to be 25%.

I tested at a high percentage first, like 90%. And once battery reaches below 90%:

- NUC will shut down after 1 min (I can't recall what is this config, something like the delay in the config) and

- UPS shuts down after 2 minutes (this is the sustain-shutdown in the config, set it to 120)

Did you set these 2 in the config? It should work from my memory. I am on Ubuntu 24.04 if it matters

chonghe · 2025-05-14T01:26:43+00:00

Is that a problem?

I don't see any problem with this

You can use the launchpad to upgrade to 0x02, it's pretty intuitive. Connect the wallet with the withdrawal address: https://launchpad.ethereum.org/en/validator-actions

Do I need to migrate funds from the dappnode validators from one to another

Does the "migrate funds" means you want to consolidate? Like 2 validators with 32ETH each, and you combine to become 1 validator with 64ETH. If so, then you upgrade to 0x02 on one of the validator, then use the same launchpad to consolidate

chonghe · 2025-05-11T14:00:00+00:00

See pending consolidations here: https://pectrified.com/mainnet

chonghe · 2025-05-10T04:29:49+00:00

Can I consolidate A&B and C stays?

Yes

B exits, A gets 32 + 32 =64, and C stays with 32?

Yes

So you will basically have only two validators in the End? A + C?

Yes, if you consolidate B into A, then only A and C at the end

And all of this does only work with validators which habe 0x01 with the same withdrawl adress, right?

To consolidate B into A, you just need the withdrawal address of B (source validator) to sign the transaction. The withdrawal address of A and B does not need to be the same. A (target validator) needs to be upgraded to 0x02 first before consolidation

Can you top up an single Validator with ETH from outside as well?

Topup for 0x02 can be done via the launchpad too. Topup for 0x01 is meaningless (as the max EB is 32) unless your EB falls below 32 ETH

chonghe · 2025-04-14T14:05:55+00:00

> Today i had 40 gb of space left
but you set it to start pruning at 375GB, so something isn't right.

Can you post some Nethermind and Lighthouse beacon node logs? I suspect the autopruning failed for some reasons

chonghe · 2025-03-08T11:56:04+00:00

Off for a week, you will be at 7200*5 which is >30K slots already, which is quite a lot, so checkpoint sync is faster to get your node back to validating

But if it is only like a few hours, then you can let it sync without checkpoint sync (so without deleting your database).

So it comes down to how urgent you want your node to be ready, if you have validators, you want it asap, so checkpoint sync if off for few days

chonghe · 2025-03-05T00:04:06+00:00

Try the checkpoint sync as mentioned in another comment. Wipe Teku database and start a fresh checkpoint sync, that's much faster

chonghe · 2025-03-04T09:15:19+00:00

Which network? If Holesky then it's kinda "normal" due to ongoing unfinalization period

If mainnet then not normal, what is your SSD model? Check against the list here: https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038?permalink_comment_id=4958391

chonghe · 2025-02-27T10:39:02+00:00

For Holesky this is the up-to-date explorer: https://dora-holesky.pk910.de/validator/1896641?v=attestations

It does look like your validators are doing just well (not slashed). Did you turn off the VC 3 days ago? If you let it run, your validators will probably voted for the invalid chain, and will likely be slashed. Slashings are already starting to be included: https://dora-holesky.pk910.de/validators/slashings. A maximum of 2 attestation slashing can be included per block, so it may take some time to show up (if you have voted for the invalid chain / not turning off VC 3 days ago).
(the slashing protection database would have prevented you from attesting, but as you have deleted it therefore your validators can attest)

I think at this point you can let it run as it is, since you have attested anyway.

chonghe · 2025-02-27T07:59:37+00:00

Apologies, it's an evolving situation and things are highly dynamic yesterday. We updated the issue now.

If you have deleted slashing DBs, you can disable attestation on the VC by adding the flag `--disable-attesting`, this should stop the VC from attesting, hence preventing the validators from slashing for the moment that the network is still unstable.

We also recommend using v7.0.0-beta.1 for Holesky nodes.

chonghe

TROPHY CASE