hydra VS consensus-specs

So many wrong statements made in your comment it's pretty wild. My original comment was to highlight some differences between Cardano and Ethereum in regards to how they operate rather than to decide which one was better. Regardless, you've decided it was complete non-sense and gone on a tangent because I state both tx fee models have their pros and cons? Lol. If you think a viable solution is to have insane gas fees on the L1 then we fundamentally disagree and crypto will never find real adoption. You've blurted so many things idk where to start but to sort of sum it up is that Cardano has scaled and is still scaling with things like input endorsers and hydra which is actually just about ready to start using: https://hydra.family/head-protocol/ This also tells me your information about what's happening is outdated. Also I know exactly what throughput is, my point was that the metric doesn't capture the full picture for different blockchains capabilities.. We can go all day but you clearly have something against Cardano, I'm happy to have a genuine discussion but the intent on bashing is clear here as this was unprovoked.

Hydra, a L2 solution using isomorphic state channels. Caveat: This is NOT an easy fix that can simply scale all Cardano dapps, it remains to be seen what parts of Cardano can actually be scaled by Hydra. This currently is a bit complicated. Sundaeswap is experimenting with Hydra, but Axo devs do not think Hydra is good for scaling DEXs...

The Hydra team completed work on a different way of dealing with contests during the contestation period. These will now always push the deadline out, making contestation periods easier to pick depending on the network a head runs on. They also added an important acceptance test and completed internal refactoring of the protocol logic, making future changes easier to implement.

I'm thinking about this for some time, about having a bot for P2P exchange much like P2P lightning bot but for Cardano and no, necessarily implementing a full-blown "lightning network", but I'm confused about the state of the Hydra Head Protocol and its capabilities for this particular use case.

The Hydra team released version0.8.1, which includes several fixes and an extension of the persistence (introduced by version 0.8.0) of replaying server outputs to make clients like the hydra-tui aware of the latest hydra-node state. The team also worked on the specification and closing gaps in the on-chain scripts, collaborated with the education team on a Hydra tutorial, and renamed the repository from hydra-poc to `hydra`.

I think its 1 million: https://github.com/ethereum/consensus-specs/issues/2137

how "radically decentralized" the development of the Ethereum core is. In the past half a decade only 133 devs have contributed to Ethereum source code. 2 devs have written 25% of the code. The first 10 developers have written 70% of the Ethereum code. Consensus specifications the ones that all the clients implement. Half are Consensys employees https://github.com/ethereum/consensus-specs

I think this will be defined here: https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/fork-choice.md

Clients dependent on Consensys core and ETH management repo. A client is just the implementation directed by Consensys written in a different language. Fact is about 10 developers are the only reason those clients will update with staking. https://github.com/ethereum/consensus-specs

Exits are processed at 7 per epoch (currently). There is no queue for withdrawals. See https://github.com/ethereum/consensus-specs/pull/3068

https://github.com/ethereum/consensus-specs/blob/dev/specs/p...

For that, we have to take the vanilla deposit contract from the consensus specs: deposit_contract.sol, get the Solidity compiler version 0.6.11, compile the binary of the runtime part, and create an empty deposit tree.

The PoS consensus specification