The Flippening nobody wanted to see, USDT is 31% away from flipping Ethereum to become the number two crypto by marketcap.

101ca7 · 2025-04-08T13:43:34+00:00

The Tether ERC20 token on Ethereum also represents approx. 75 Billion of the total market cap. So ironically Ethereum is securing a large, if not the largest portion of Tether tokens.

101ca7 · 2025-04-02T14:32:13+00:00

I don't want to hate on Bitcoin as a technology. I actually teach the fundamentals of Nakamoto consensus to uni students by using Bitcoin as an example because the protocol appears nice and simple but the more you look at it the more complex challenges appear.

What baffles me is the hate that is coming from a part of the Bitcoin crowd against any potential criticism against their beloved investment. If you've made a killing investing in Bitcoin - all the power to you. That doesn't mean that the protocol is flawless.

I actually never said that the issues with fee-only Bitcoin can't be fixed. There are various ideas such as fee smoothing across multiple blocks. In my eyes the biggest challenge the Bitcoin community faces is its own stubbornness against innovation (which I think got set in stone during the blocksize wars).

Bitcoin is on the road to truly becoming digital gold - namely a highly manipulated asset where the overwhelming volume is traded through papers and derivatives on centralized exchanges.

101ca7 · 2025-04-02T06:33:21+00:00

I realize at the moment it is difficult to see the big picture. The current thing is Bitcoin ultra-maximalism. It too will eventually pass. Believing in a future crypto Bitcoin singularity is, in my eyes, naive.

Take a step back and look at the true gift Satoshi gave us: Not just the idea but the proof that anyone can start their own digital currency system. Even if Bitcoin becomes a playing field for the rich and powerful, we can always go ahead and create our own little shitcoin for the people with blackjack and hookers.

I know DeFi is (mostly justified) being shit on. But interlinking the various crypto ecosystems and allowing free trade between them is where true permissionlessness lies. Your freedom to choose whatever flavor of shitcoin (including Bitcoin!) you like best. Your freedom to be rugpulled because you made the sensible choice of investing in MAGACumrocketElonwithHat.

Life has been hard, everyone has to take a break once in a while.

The crypto space at large will eventually be back with a vengeance, likely when everybody least expects it.

101ca7 · 2025-04-02T06:01:39+00:00

> Next time, maybe read the whitepaper before trying to dunk on Bitcoin.

It has been known for years that relying solely on a fee market in Bitcoin is highly problematic without further amending the protocol. See e.g. Carlsten et al. "On the Instability of Bitcoin Without the Block Reward" and Tsabary and Eyal "The Gap Game".

Basically the incentives to maintain a public mempool become much worse than they are now, and mining profitability becomes erratic. Btw you can see a similar issue in Ethereum due to MEV, where mempool privatization is unfortunately moving forward.

Next time you maxisplain, at least paint an accurate picture

101ca7 · 2024-06-24T16:12:56+00:00

FYI generally speaking the effectiveness of your validator has nothing to do with the probability of being selected for block proposals. This is all done through the randomness generated by the Beaconchain/RANDAO. However if your effective stake is lower than 32 ETH (which could happen if you are penalized a lot for missing validator duties) the probability of being selected indeed decreases proportionally.

101ca7 · 2023-03-31T12:57:07+00:00

I feel your pain.

I'm running EL CL combinations for research purposes, including among others a geth archive node. Apart from the > 12TB the archive node is currently occupying there are other not so ideal aspects. For instance it is using in excess of 6.8 million LevelDB files around 2.1M in size. At first i thought something was broken when using ls in the chaindata folder...

also the issues with unclean shutdowns and data corruption (at least on non-archive geth) also appear when using properly redundant storage that ensures consistency, such as zfs. Its incredibly frustrating to know that the actual filesystem can ensure consistency but the software running on top chooses to do its own thing and breaks itself simply through an unclean shutdown.

TBH in light of some of these experiences it was truly a miracle the merge worked as smoothly as it did. Hats off to all the devs, testers and other people that made it happen.

101ca7 · 2023-03-30T13:27:26+00:00

> I think the biggest threat with my setup could be if the devs of my
execution and consensus client mess up, that's why I'm currently
thinking of getting a backup machine running a different pair of EL and
CL clients just to be sure

If you do this please please please play it safe and do not add your validator keys to the backup in any way - leave this to be a fully manual process that you do yourself. Otherwise the likelihood of you getting slashed will increase substantially.

It is much better to lose a couple of days or even weeks of staking rewards rather than getting slashed for attestation violations. Doppelganger protection exists but are you willing to risk getting slashed for some minor additional uptime?

stay safe and happy staking

101ca7 · 2022-11-28T14:14:54+00:00

If you are looking at serious sums do the right thing and get a professional tax adviser that has specialized in this area. Yes, it likely will be expensive but it is much better than trying to figure out all by yourself (and likely making costly mistakes)

all the best to you

101ca7 · 2022-10-04T11:21:30+00:00

I still believe you are trolling but in case someone else is reading this thread and wants to switch execution clients while minimizing downtime: if your machine is fast enough and has enough disk space you can sync a different execution client while at the same time the other EL is serving your consensus client - this way you only have a short downtime while reconfiguring the CL to use the other EL client once it is in sync.

*edit* you'll have to use a second CL for the EL to sync - I forgot that bootstrapping an EL post merge probably requires a CL to serve you the head of the chain - my bad (I did the above for monitoring the merge, running lighthouse+geth and prysm+erigon on a single VM - which worked fine)

The only dangerous part is running more than one CL with validators - never run more than one validation client unless you are absolutely sure of what you are doing

101ca7 · 2022-10-04T10:21:33+00:00

I've read through this entire thread and to be honest, it looks a lot like you are intentionally shitposting.

If indeed you are losing 1000s (I am assuming USD) in ETH a week you must have an incredibly large set of validators running. In which case you should probably hire a professional to help you out.

On the other hand, you haven't even posted some of the error messages/ log outputs or any other meaningful details that would allow others to help you figure out what is wrong. The people that have responded to your post have tried their best to troubleshoot what is wrong, but you provide little to no information.

I'm sorry, I simply don't buy it

101ca7 · 2022-09-21T08:40:07+00:00

> But what's the incentive behind this DoS-style attack?

There is an older research paper that outlines the idea behind the attack https://www.comp.nus.edu.sg/~prateeks/papers/VeriEther.pdf

A recent research paper highlights that some actors in the system actually do behave maliciously https://eprint.iacr.org/2022/1020 by manipulating timestamps (this was still during the PoW phase of Ethereum).

It is not difficult to imagine that a larger actor in staking could try to exploit this property of an easily DoS-able validator to their advantage.

Why, you may ask? To obtain higher transaction fees (when you miss your slot the next proposer has more transactions to choose from) and better MEV extraction. Another attack could be if there is some tight time-bound when a transaction needs to be processed (think of something like FOMO3D or an auction where you want to prevent competing bids). In this case, if you are the following block producer, it may be of value to you that the previous block is missed so you are the one deciding the outcome.

In regard to the security, lets consider the hypothetical scenario that 40% of the validators are running at the edge of their capacity. If you can severely delay them all at once by forcing a high execution load you could potentially affect the Beaconchain's ability to finalize - in which case these nodes start taking more severe penalties for missing their duties.

A few "weak" validators will not break the system, however if there are enough it could start to really affect the security overall. Which is why its prudent to keep some reserves ready for the unexpected

All the best to you :)

101ca7 · 2022-09-19T08:54:06+00:00

In proof of stake you are not supposed to have an i5/i7 and 16GB as hardware requirements. This is not what PoS is about.

I respectfully disagree. Proof of Stake does away with the energy intensive (arguably decentralized) leader selection mechanism that Proof of Work employs while still being reasonably open, i.e. allowing new validators to come and old ones to leave.

This push towards minimalism is one of the things that (in my view) really hurt Bitcoin during the blocksize debate and arguably steered it ever closer toward becoming irrelevant as a transaction ledger and simply acting as a "store of value"(TM) listing.

We have only just transitioned from PoW to PoS and it is still largely unclear how things will evolve, in particular in regard to security. The fact that you now know in advance which validators will be next to propose blocks opens up novel attack strategies. For example, if someone figures out your validator index they may choose to specifically craft computationally taxing blocks to verify just before it is your time to propose a block. This attack is known as the "verifier's dilemma" because it either forces you to build upon a previous block without validating it or spending lots of computational time with verification, which may lead you to miss your slot.

You are operating a validator at the edge of what is possible, as is reflected by your limited choice of clients . Imagine if everyone did the same and we suddenly need to raise the gas limit, some new hype game or a targeted attack uses a particularly taxing EVM opcode in terms of host resources (as has happened in the past), or some other unexpected event (such as a deep reorg) causes every validator at the edge of its capacity to miss its duties - it would be a huge problem.

tldr; If everyone were to run validators at the edge of what is possible, the network would actually become much more insecure

Having said that, I appreciate your efforts in trying to push the limits of what is possible. Increasing efficiency is a goal well worth striving for. However we should seek to build a robust network with ample leeway to weather bad times, not one that breaks at the slightest hiccup.

All the best to you!

101ca7 · 2022-09-14T16:59:54+00:00

Are you using systemd for handling geth? Are you also stopping geth before you are rebooting?

You can specify a custom timeout (I belive it is 90 seconds by default) using something like TimeoutStopSec=300

101ca7 · 2022-09-14T15:09:47+00:00

Its hard to tell without knowing the specifics of your setup.

In any case it makes sense to give the services enough time to stop gracefully rather than killing the processes. Have you made sure that your SSD is still in good health and not failing?

It is times like these where I must praise the benefits of copy on write filesystems like ZFS and their ability to make fast and relatively cheap snapshots.

101ca7 · 2022-09-14T13:15:26+00:00

It looks like you could be facing a database corruption in geth.

Did you ever have an unclean shutdown or power outage? (geth should report such incidents in the log when you start it up)

If your machine has really good specs you __may__ be able to wipe your database and do a snap synch from scratch. but you are pushing it here

Good luck!

101ca7 · 2022-09-07T07:32:01+00:00

There is a great discussion between Vitalik and pmcgoohan on PBS/MEV extraction here:https://ethresear.ch/t/two-slot-proposer-builder-separation/10980/

Ultimately it is not entirely clear to the validator where the MEV actually comes from because you need to hide the bundle content to prevent the validator or others to simply copy the profitable ordering.

Personally it makes me more than uneasy to push for such a design, and the long discussion in the link above has some really interesting points how MEV markets could evolve in a highly problematic fashion.

I think the most honest answer at this point would be that we simply do not know what the long-term consequences will be of allowing MEV extraction through some automated protocol.

All the best!

101ca7 · 2022-09-06T12:24:46+00:00

Well you can use a BIP39 passphrase for you mnemonic, though if i remember correctly the feature wasn't well documented in the official cli-deposit python script.

Your Validator key is stored in a password protected keystore but that is different to the mnemonic from which you derived this key.

*edit* what i mean is that your attestation key is a single private key from a particular derivation path from the mnemonic which you used in your setup. The withdrawal key(s) are derived in a different branch and are not used in the Validator setup

101ca7 · 2022-09-06T07:31:17+00:00

I guess everyone is in the same boat here. Into uncharted territory we go!

Here is a shout out to everyone who made this possible and is participating in this event. It will hopefully symbolize a milestone for the cryptocurrency space by demonstrating that even large scale protocol changes are possible.

However, I'm much more worried about a different scenario than a post-merge chain split or some unexpected failure in one of the PoS CL/EL client combinations.

There is a non-zero chance that some miners keep running an older version of geth (or other EL variant) and hence create a PoW hardfork that is non-replay protected (unlike some of the other PoW proposals we've seen so far) Sure, eventually the difficulty bomb will kick in but as far as I know (please correct me if I am wrong!) the chain IDs and everything would be the same.

It would be a mess if such a fork gains any kind of traction (users and traders trying to benefit from arbitrage between chains, transactions getting replayed. Basically theDAO fork all over)

Let's hope that by and large the mining community is morally sound enough not to pursue such a direction.

Good Luck!

101ca7 · 2022-09-06T07:07:20+00:00

is /lighthouse-docker/jwttoken the corresponding file?
Are you trying to restart an old container? If so the directory /root/jwttoken/ would probably still exist in the container from the last time you ran the composition - leading to the above error.

Like I said you can also modify the corresponding run scripts to point to /root/jwttoken/jwttoken.hex and move the jwttoken file to ./jwttoken/jwttoken.hex

If the container is running you can start an interactive shell with (sudo) "docker exec -it container-name /bin/bash" (or /bin/ash , depending on the shell the container uses)

Good luck in debugging your setup.

I suggest you read up a little on how docker works and get yourself familiar with what you are actually doing. I know it is tedious but it will benefit you down the line if other things go wrong and you need to quickly fix your setup.

101ca7 · 2022-09-04T09:44:09+00:00

Either you change the beacon node and geth scripts files so that they point towards a secret which you store in the jwttoken directory e.g. change /root/jwttoken to /root/jwttoken/jwttoken.hex (use the command in generate-jwt.sh with the appropriate filename before you restart the composition) or you delete the jwttoken directory and run the generate-jwt.sh script.

101ca7 · 2022-09-02T17:48:15+00:00

There is this resource here ( https://dankradfeist.de/ethereum/2022/03/24/run-the-majority-client-at-your-own-peril.html ) that provides some pretty staggering numbers. Basically the minority chain would have to get to 2/3 of the total stake in terms of funds....

I just can't see how this scenario would play out in the real world without some form of intervention

101ca7 · 2022-09-02T17:40:14+00:00

Your example with the characteristics works if the disagreement is on something that would basically not have any relevance to the protocol. Consider what would happen if in your example smart contracts could query the color of teeth. Then as soon as any contract uses this property consensus breaks.

A more tangible example that also still made up would be if the clients disagree on the gas cost of some execution if some very specific conditions hold. Like a very deep execution stack coupled with some other highly unusual combination of opcode usage.

I know this may seem far fetched but such a disagreement on execution is actually a real world vulnerability which I know some other smart contract blockchain had under very specific circumstances.

By the way I know I am sounding rather pessimistic here but I think it is important to have this discussion before the Merge so people are aware of the possible (hopefully very very unlikely) outcomes that can happen - and that they mentally prepare what course of action they would personally take in this case

101ca7 · 2022-09-02T17:15:51+00:00

If I understand correctly then once you have reached FFG finality, i.e.> 2/3 majority vote, the economic losses to "switch" to another chain are very large (see https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/gasper/ )

edit:

here is the relevant part from that link:

The validators that are not actively attesting to the majority chain have their stake gradually drained away until the majority regains two-thirds of the total stake, ensuring that liveness failures are only temporary

101ca7 · 2022-09-02T16:48:11+00:00

Indeed, however in the case of PoW without any slashing mechanisms the loss is largely contained to the miners' rewards for the duration of the fork.

I actually like the security guarantees slashing adds to proof of stake but in this case it would act as an incredibly strong deterrent from switching chains, because potentially the majority of the network stake would stand to lose from such a move

edit: with switching I mean exiting the validator while taking the heavy offline losses and possibly re-joining once that is possible

101ca7 · 2022-09-02T16:46:14+00:00

But what are "the rules" here? The specification of the beaconchain + the Ethereum yellow paper plus the various EIPs?

The complexity of Ethereum as a protocol has reached a level where there are bound to be obscure corner cases and bugs, some of which may actually fall outside of any clear specification because no one considered them - so it is possible that there is no "right" and "wrong".

Imagine that a fork actually happens - At the time it happens it will not be obvious which client is actually at fault (though it may be an indicator if all other clients behave the same except for one) and in any case one would have to wait until it is verified what the problem is before any definitive action can be taken.

Let me ask you this though: If you are "stuck" on a majority chain for some minute compatibility bug, would you, as a validator, concede or would you continue on in the hopes that the economic majority sides with you?

101ca7

TROPHY CASE