Eth fruit bot write if want withdraw quick pay eth at ethscan address.after pay got only #U723462472

https://medalla.beaconcha.in/validator/6545
Graffitis: poapFA4yQ0B9peFxKji9NocEShBGTHwA, railgun.eth
Eth1 address: 0xA29FD283430Ab091434161Ec847A125BDAB0230F

Launchpad and chain explorer are up and running

• Launchpad ethereum.org
• Chain Explorers beaconcha.in

Can be added to
https://github.com/goerli/medalla/tree/master/zinken

When addressing sigp/lighthouse#1186, I attempted to connect to Witti to verify LH could sync. I noticed that the boot ENR have a 0.0.0.0 address:

enr-cli --enr "enr:-
KG4QO6QrRlWQ2Z5ss4XoUsrPvsepRuuogcHyC81gMQr7PJ3IFh41bDnGSl9iN_ijg2EgQeEQDpRPkE4FzD2ecbp6XoChGV0aDKQgGboQQAAARP__________4JpZIJ2NIJpcIQAAAAAiXNlY3AyNTZrMaEDpsGvSN7oM2c04ZT9mrG32TVj-sMhb6HiKc6LMEXYEyiDdGNwgnUwg3VkcIJ1MA"

ENR Read
Sequence No: 2
Node ID: 0x5b8c..0cf7
IP: 0.0.0.0
TCP Port: 30000
UDP Port: 30000

(Install enr-cli with cargo install enr-cli --version 0.1.0-alpha)

Launchpad and chain explorer are up and running

• Launchpad ethereum.org
• Chain Explorers beaconcha.in

Can be added to
https://github.com/goerli/medalla/tree/master/zinken

Today I have seen 8 logs related with this problem with this tag "PLEASE FIX OR REPORT"

teku.log

There are 6 error logs related with this problem today in between 11:19 - 11:27

io.netty.channel.ExtendedClosedChannelException: null
	at io.netty.channel.AbstractChannel$AbstractUnsafe.write(...)(Unknown Source) ~[netty-all-4.1.36.Final.jar:4.1.36.Final]

teku.log

Validator 2329 was slashed: https://medalla.beaconcha.in/validator/2329

Graffiti: Stefan#3917

https://spadina.beaconcha.in/validator/2621
Graffiti: 'sparkpool | prysm'

Hello,

this is more an issue of documentation and understanding I think rather then a technical issue.
I mananged to contriubute in the testnet5 and would like to do it in the schlesi testnet as well.

Geth is running properly,
lighthouse is properly running a beacon node
I have a MetaMask wallet with >32 ETH.

The only thing I do not get is how I "sign and use the contract" as a validator. There is a section that tries to explain the procedure. However, it's not entirely clear to me:

As far as I understood I need to send 32 ETH to 0xA15554BF93a052669B511ae29EA21f3581677ac5. But I cannot see how I do this with that line:

lighthouse account validator new
--send-deposits
--password ./password.txt
--deposit-value 3200000000 random

For my understanding there is no parameter for the destination (contract address).

• So how does lighthouse know where to send the GörliETH to?
  Moreover there is no adress from my wallet (source).
• So how does lighthouse know where to send the GörliETH from?

And also my questions are:

• How would I send additional GörliETH to the contract if I wanted to?
• How would I withdraw GörliETH from the contract if I wanted to?
• Where can see the current deposite of GörliETH I made for the contract?

I do have a lack of knowledge here.
I appreciate your help.

Thank you

Hi all,

As this multiclient effort matures, it's important for teams to be on the same page regarding what is needed before we can do a public, coordinated testnet launch like the @prysmaticlabs' topaz testnet here. Here are some tentative milestones before a lighthouse+prysm public testnet announcement should occur:

• No skipping or minimal finality delays for N epochs
• Testnet resilience to recover under N epochs without finality
• Initial chain sync stress tested
• Stress testing N number of validators, where N in (16k, 50k, 100k)
• Slashable events occurring and successfully caught by slasher
• Major node panics/crashes resolved across both clients
• High chain participation > 97% as well as good profitability metrics for validators (less critical as can be improved over time)

Thoughts?

I am trying to use the Medalla Launchpad and am at the "CONNECT WALLET" page. Although Metamask shows that I am connected to the Medalla Launchpad, on the CONNECT WALLET I am in a continuous cycle. Is there a distinction between an Account and a Wallet in Metamask?

The Prysm beacon config only shows --web3provider ws://127.0.0.1:8546
This is incomplete as currently Prysm uses both ws and http.

Only specifying the above can lead to issues, as the http parameter will default to "https://goerli.prylabs.net"
(resulting in 2 different eth1 sources potentially being different)

So if you specify localhost on port 8546, you also have to specify:
--http-web3provider="http://127.0.0.1:8545" \

Details around issue in Prysm rep : prysmaticlabs/prysm#5826

Below a screen print of the Prysm witti config:

https://medalla.beaconcha.in/validator/21769
Graffiti: /
Eth1 address: 0x3A15459851b5346677bf9f7d3F8B2A8233eAdaad

https://medalla.beaconcha.in/validator/21759
Eth1 address: 0x694e5550d604F176B037Afd776722a79D3616d6d
Graffiti (on other validator by same Eth1 address): poapaU5VUNYE8XawN6/XdnIqedNhbW0A

I cant visit medalla.launchpad.ethereum.org ,

but launchpad.ethereum.org is ok.

See comments at bottom of #11
ws should be changed in http

Name: v0.12.1 Altona

Tracker:

• Lighthouse sigp/lighthouse#1182
• Prysm prysmaticlabs/prysm#6076
• Teku Consensys/teku#2038
• Nimbus status-im/nimbus-eth2#1103

See https://medalla.beaconcha.in/validator/5212
(no blocks proposed, so graffiti not known)

Hi guys - On behalf of Etherscan - Would it be possible to add also a hyperlink to the "About" section right here?

Reckon there can only be one hyperlink at a time on that section though, so to be honest not exactly too sure how more than one link could be accomodated (maybe as a tag etc)?

cc @mtbitcoin

error information:
error: patch failed: beacon_node/genesis/src/eth1_genesis_service.rs:10
error: beacon_node/genesis/src/eth1_genesis_service.rs: patch does not apply
error: patch failed: eth2/state_processing/src/genesis.rs:1
error: eth2/state_processing/src/genesis.rs: patch does not apply
error: patch failed: eth2/state_processing/src/lib.rs:10
error: eth2/state_processing/src/lib.rs: patch does not apply

Just wanted to let you know that the first ENR in bootnodes.txt refers to the LAN address 10.0.1.97. Not sure if that makes a lot of sense unless it's being used in some sort of internal testenv :)

Decode -> https://enr2maddr.herokuapp.com/?inaddr=enr:-KG4QIOJRu0BBlcXJcn3lI34Ub1aBLYipbnDaxBnr2uf2q6nE1TWnKY5OAajg3eG6mHheQSfRhXLuy-a8V5rqXKSoUEChGV0aDKQGK5MywAAAAH__________4JpZIJ2NIJpcIQKAAFhiXNlY3AyNTZrMaEDESplmV9c2k73v0DjxVXJ6__2bWyP-tK28_80lf7dUhqDdGNwgiMog3VkcIIjKA

cheers 🙌

Hi, I'm from the @prysmaticlabs team. We have recently launched our latest testnet (Topaz) on the v0.11.1 spec version with full mainnet configuration. We are wondering how we can contribute to the multiclient testnet effort.

Should we add Topaz information here? It is multi-client compatible.

I see Teku specific information v0.11.1, but using fractional deposits. Is the scope of The Multiclient Testnet defined? Are we planning to use the exact configuration intended for mainnet?

Thanks

Eth1 address: 0x3a15459851b5346677bf9f7d3f8b2a8233eadaad

Instead of having 1 validator client running 4 keys. The victim launched 4 validator clients running 4 keys on each client. With 4 validator clients, each validator client has its own protection DB so that didn't help. Lesson learned from this incident, we have to improve on documentations and add protection schemes around wallet designs. See tracking issue for more details

Tracking issue:
prysmaticlabs/prysm#6948

Add lock file for wallets:
prysmaticlabs/prysm#6952

https://medalla.beaconcha.in/validator/5116
Eth1 address: 0xf689d779d9108FAa0Ba447399Fb2477687923278

No proposed blocks, so no graffiti

The Fate of Medalla

As discussed on our latest call, we need to decide what to do with Medalla.

Two primary options:

1. Let it die as we approach mainnet, replacing it with a new v1.0 testnet
2. Keep it running, and upgrade it to v1.0 release (BLSv4, discv5.1, maybe fork the state to "mainnet" v1.0 constants)

Arguments for (1)

• With respect to validator breakdown, Medalla is primarily run by the community. As mainnet approaches, I expect most community members to have little appetite to consistently run two nodes, and thus the largely community composed testnet is in for a number of rough leak periods. Validators cannot be activated during a leak so this might diminish the quality of service the testnet provides for the community. (We are currently seeing such a leak and expect finality at end of October. That said, we could easily see another leak or two in the coming months).
• Forking can be difficult. This is not only wrt the underlying technicals, but also wrt community/user coordination. Given mainnet is imminent, asking existing Medalla users to coordinate software upgrades might (1) distract from their mainnet preparations and (2) might result in a low percentage actually upgrading to the fork. This would lead to another leak. Additionally, there is technical overhead to upgrade each of the fork components. While good practice, it will take significant developer resources.
• A clean reset when most of the community migrates to mainnet will give us a chance to run the majority of validators on the new network to provide a much higher quality of service to those that need a testnet for testing. Additionally, we can consider "testnet" features that might make keeping the quality of service higher in the first place. For example, we can have a set of master exit keys that are allowed to submit exits for any validator. We can then daily sweep validators that haven't been online in some time period and submit exits for them.

Arguments for (2)

• We're going to have to do forking upgrades sooner rather than later so it could be good practice for devs and community. This is a practice in both technicals and coordination. The technical upgrade can either be just discv5.1 and BLSv4, or it can also include a migration to v1.0 configuration (e.g. alter some constants, expand some arrays in beacon state, etc). If we do this part of the upgrade, I would recommend doing a "re-genesis" at this fork state and not serve blocks/states prior to the fork. If we did that, it would mean that Medalla does not satisfy the following goal
• Medalla has a bunch of syncing data so we can have a solid place to test more stressful syncing when mainnet goes live. It has been expressed by some devs that this is an asset to the development and release process and starting mainnet without the asset in place

My thoughts

I probably showed my bias in the arguments above. I personally lean toward not upgrading Medalla and letting it degrade in mid to late November.

In the next couple of months, there will be a high coordination event (mainnet genesis) going on that I think a testnet fork will distract from on both technical and community. Additionally, if we upgrade to v1.0 configuration, I would recommend doing a "regenesis" event with a single script migration rather than maintaining legacy states/code paths for the testnet. If we do that, it defeats the syncing data argument.

Instead, we could keep the Medalla config around and just upgrade discv5.1 and blsv4. blsv4 could be quietly upgraded anytime because 0 pubkey is not currently on that testnet, but this could change anytime. As for discv5.1 there are two options, (a) do a catdog style dual table or (b) a migration at a discrete epoch. (a) would help reduce the coordination overhead on the upgrade but would require a significant more amount of development and maintenance. (b) would require a single epoch of coordination and the majority of the network to upgrade their nodes.

My ideal: Starting in November, we should begin standing up some private v1.0 testnets to make sure everything plays nicely. If in mid-November, we have a net we are happy with, we can keep it running and open it up to the public to serve as a new public testnet (but with less fanfair pushing the community to join). Instead, just a static resource for when people need it. We could keep Medalla around until the end of the year to have a place to test longer syncs, but eventually let Medalla die in favor of the new testnet that would then have more than a month of sync data.

A lot of the decison on what to do is probably more of a dev resourcing standpoint. The various paths have different engineering/time requirements and also have implications for longer term maintenance.

Client teams care to chime in?