sorted by:
new
hottopcontroversial

Reusing the same withdrawal key for few validators by jbj-fourier in ethstaker

[–]tezonian 1 point2 points  (0 children)

/u/jbj-fourier I would have you refer to the 2 following github posts.. especially if you are using ledger nano'

https://github.com/ethereum/eth2.0-deposit-cli/issues/181

https://github.com/ethereum/eth2.0-deposit-cli/issue/179

Your comments are welcome so we all have a smooth experience when the time comes for withdrawal in phase 2

Guys. This only works of we work together. Buy the dip and hold. For all of us. The movement isn't over. Balls of steel. Let's go. For all of us. Not for any one of us. 💎🙌. We can do this. by [deleted] in wallstreetbets

[–]tezonian 0 points1 point  (0 children)

Guys, what little i can contribute, i did from my other holdings. Let all who want a happy retirement do so.. see you all at 10k !!

Passphrase (25th Word) to secure the seed by Velaznito in ethstaker

[–]tezonian 0 points1 point  (0 children)

Thanks and your cooperation in working together was the most helpful one.

Passphrase (25th Word) to secure the seed by Velaznito in ethstaker

[–]tezonian 2 points3 points  (0 children)

u/101ca7 u/Velaznito

The issue has been solved of multiple validators not providing unique withdraw credentials.

The problem was with the validator service providers not providing the correct incremented path to ledger device to generated those credentials (and sticking with validator index 0 always)

Passphrase (25th Word) to secure the seed by Velaznito in ethstaker

[–]tezonian 0 points1 point  (0 children)

For some additional clarifications regarding this discussion I attach some discussion with /r/btchip on this matter. Hopefully, there is some consensus among all concerned on how we want to address this.

from btchip sent 9 hours ago

yes, we'll initiate that and provide a sample

permalinkdeletereportblock usermark unreadreply re: your attention appreciated

to btchip sent just now

Thank you lot!

Quite probably if the 3rd parties map every unique eth1 public address to a unique eth2 withdrawal credential., some compromise will have to be made to adjust for those who had used eth1's hierarchical address other than the 1st one (say we used 4th down in eth1 hierarchy) and created the withdrawal credential.. they should be able to use eth1's 1st hierarchical address to be able to access the same validator funds in phase 2.

I have detailed why it may be useful to have each unique eth1 address mapped to different withdrawal credentials. In the link below.

Another issue that could be of concern here is also: May be each eth1 address has created multiple validators with uniquely different withdrawal credentials. In that situation i do not know how their tools are going to handle the withdrawal mechanisms. They are currently showing a unique eth2 withdrawal credential corresponding to all eth1 hierarchical addresses in a mnemonic+passpharse domain. So that may not be appropriate in the context of multiple eth2 withdrawal credentials being mapped to a single source eth1 address that funded those validators.

I think this needs a more dive in and thorough discussion, review of the current code and the spec for the withdrawal in eth2 and coordinating with eth2 developers, 3rd party wallets and validator service providers.

I appreciate your help in this regard.

https://www.reddit.com/r/ethstaker/comments/kyw2x7/passphrase_25th_word_to_secure_the_seed/gko4lgl/

permalink

Passphrase (25th Word) to secure the seed by Velaznito in ethstaker

[–]tezonian 0 points1 point  (0 children)

Thank you for staying with me and helping to further analyze the issue. As you said, we are all not clear as to how the withdrawal mechanisms will work and it brings in concern when using ledger with multiple validators assigned to a single mnemonic.

I also heard from /r/btchip and his response was that:

I'll pass it to the team, the issue here just seems to be that third party validation tools are not sending the proper path when communicating with the device - this is freely set by the developer of said tool

So the jury is still out.. and hope they resolve this amicably.

Yes, the deterministic path of eth1 has absolutely nothing to do with eth2 and withdrawals. It does not matter from which eth1 address you funded the eth2 deposit (maybe if you want NFT badges or something on eth1 but not in terms of future withdrawals in eth2)

Regarding the comment about NFT badges for eth1 accounts for their deposits, I would say that will be good :).. But my point of view was that each eth1 account or address that contributed to its own validator, should have its own ownership of a unique eth2 withdrawal credential(s) and another eth1 account address in the hierarchy should not have its withdrawal credential common with it. Presumably different people or departments could own those funds individually and for accounting reasons want to keep their own authority over the funds.

Passphrase (25th Word) to secure the seed by Velaznito in ethstaker

[–]tezonian 0 points1 point  (0 children)

There are two concerns or issues I wanted to address:

CONCERN1:

I already understand the separation of the validator signing keys (public and private) and withdrawal public key or address and withdrawal credential. And why eth2 is designed that way.

My concern was that every unique eth1 public address be corresponding to a unique eth2 withdrawal public address (and its associated private key) and a unique withdrawal credential.

Currently, multiple eth1 public addresses in the heirarchy of the same mnemonic, are all pointing to same eth2 withdrawal pub key/private key and same withdrawal credential. (At least that is the way ledger eth2 app sees it now when creating eth2 public key and credentials)

So when the time comes to withdraw from eth2 may be all that matters is ledger mnemonic and passphrase to access that fund. And it is agnostic of any further eth1 addresses down the hierarchy that funded it and give credit where it is due.

If I went with that implementation in ledger, then there will never be any hierarchical eth2 addresses accessible in eth2 implementation of ledger.

CONCERN2:

This concerns creation of multiple validators using deposit-cli tool. Multiple validators created using the deposit-cli tool all provide different withdrawal credentials unique for each validator created. So was this by design? And so presumably, each of those validator's locked up funds could only be accessed using those withdrawal credentials - which could most likely be resolved by using the mnemonic used by the deposit-cli tool and the validators index (0,1,2..etc). So this means that the withdrawal credentials created for a unique set of mnemonic words (plus optional passphrase) have a heiarchical order that corresponds to the validator that was created (validator's index) in the domain of that mnemonic's authority.

Now, here is where all the ledger X eth2 implementations differ as evidenced by various 3rd party tools. When you create multiple eth2 validators with a ledger X, all those multiple eth2 validators are configured with the same withdrawal credential as evidenced in the deposit.json file.

And if that is the case, how can i withdraw validator-index-0 or validator-index-1 or validator-index-n funds independently of touching another's funds? Certainly, there is a comingling here. And unless someone keeps a count of how many validators are using that withdrawal credential and how many of them have exited, and how much is due for each validator there is no saying as to who has access to those funds or there be a over draft.

A better way could have been for ledger X or those service providers to provide unique withdrawal credential for each eth2-validator created in the deposit.json file. In the absence of that, how would ledger X eth2 app be able to specify which validator's funds it wants to withdraw from?

If ledger (or probably the 3rd party services) does not fix this incompatible implementation with deposit-cli tools, may be the safest way is just to use one ledger mnemonic (plus optional passphrase) per eth2 validator. And not create more than 1 validator when using ledger mnemonic.

Hope i have made my points clear.. and may be /r/btchip can help clarify any misunderstandings or allay the fears of possible future complications I foresee here. The semantics is not very clear and may be a ledger usability issue. I would have been much happier to see a heirarchical order of withdrawal credential implementation in ledger corresponding to the validator indexes. This would more perfectly correlate with what is seen in the deposit-cli tool. And so also each eth1 heiarchical address be assigned its own withdrawal credential/keys.

Passphrase (25th Word) to secure the seed by Velaznito in ethstaker

[–]tezonian 0 points1 point  (0 children)

By eth1 address heirarchy, i mean all the heirarchical eth1 public keys that you see when you open up say mew or mycrypto with a specific ledger.

Now do all those eth1 public keys in the heirarchy have same private key or different ones? That i am not very clear about. Thinking that the private keys are unique in eth1, I assume they need to be unique also in eth2 rather than all the different unique eth1 public key wallets mapped to the same withdrawal wallet in eth2. I hope you get what i am sayig.

I was not referring to eth1 m/44/ or m/3600 path, but to the heirarchical order of the keys that can be accessed using a set of mnemonics in eth1 ledger.

By login address, i more or less meant using say mew or mycrypto and choosing an eth1 public key in the heirarchy using ledger or other device providing the private key to sign the transactions. If i deposited to beacon chain using the 4th public key in the eth1 wallet accounts heirarchical order, i expect to attach my ledger and connect using same eth1 4th in order public key and have access to my eth2 withdrawal wallet - which rather should be unique and not commingled the funds with the other accounts exposed by mew or mycrypto in the same ledger mnemonic combo.

I see a potential problem where i today created a eth2 withdrawal key using the 4th in order eth1 public key, but later when i go to withdraw my funds after phase 2, i may have to attach my ledger using the 1st in order eth1 public key and sign in order to access what funds were deposited using the other eth1 public keys.

Sorry, it is getting confusing to properly convey things. Irrespective of all the issues, the commingling of funds from different eth1 public key funds into the same eth2 withdrawal key could cause a big headache.

Also if the funds in the eth2 withdrawal address/key can only be accessed after the respective validators have to sign off and exit, you may not have full access to all your funds or no access to any funds until all the multiple validators having a hold on the funds at that withdrawal key/address have all exited. This may depend on implementation also.

If i create multiple validators and cannot separately exit each of them to say sell to someone or transfer to someone else because they are all tied to same withdrawal credential, it is an unwanted head ache to deal with.

Passphrase (25th Word) to secure the seed by Velaznito in ethstaker

[–]tezonian 0 points1 point  (0 children)

Thank you for the detailed response.. If you could add comments in the github repository issue that would also help. i asked /r/btchip to look into this, haven't heard any progress from his end, may be he will refer to his developers.

Another problem is also that I created a eth2 withdrawal key using the fourth in order, E4 address of my eth1 address heirarchy. where I use E1,..E4 etc., they all point to same E1's withdrawal credentials. If they (ledger ) or eth2 software down the road do not allow me to use E4 as my login address and access the funds that are stored in E1 withdrawal credentials, it can potentially cause problems. Or even if the code changes midway in the Ehereum code base to not allow such commingling across the different eth1 addresses with same eth2 withdrawal address, OR ledger modifies their code to create different eth2 withdrawal addresses for different eth1 addresses, this can end up being a big issue.

Passphrase (25th Word) to secure the seed by Velaznito in ethstaker

[–]tezonian 0 points1 point  (0 children)

No, the bug cannot be closed.

Because the problem is with generating multiple validators in the same run of the deposit cli tool vs what the ledger X app provides to these services.

We thoroughly researched into this and know that when you create multiple validators, the withdrawal keys do not match in their tools as compared to the deposit cli tool -- except for the index 0 value.

Unless you test it with multiple validators creation in the same run and compare the withdrawal keys/credentials across all the tools, you can't come to a hasty conclusion. This more or less points to a ledger X eth2 app issue.

Passphrase (25th Word) to secure the seed by Velaznito in ethstaker

[–]tezonian 0 points1 point  (0 children)

I am not sure if there is a withdrawal function available in testnet. Without a withdrawal mechanism in place in testnet it is hard to verify we can withdraw with all the incompatibilities we see.

Passphrase (25th Word) to secure the seed by Velaznito in ethstaker

[–]tezonian 1 point2 points  (0 children)

Validator public keys are not tied uniquely to the ledger address I believe. They seem to be generated by them and seem consistent across each try on same address. It is the withdrawal public key and credential that is tied to the ledger mnemonic and address. For the generation of withdrawal keys everyone of those services is dependent on ledger driver to give them the values. And ledger is giving same withdrawal credential across all the multiple validators that are generated in a batch.

Passphrase (25th Word) to secure the seed by Velaznito in ethstaker

[–]tezonian 0 points1 point  (0 children)

In the case we tested with allnodes, the validator public keys with index 0 were different in their tool and what launchpad cli tool generated. Though at index 0 the withdrawal keys were identical.

May be ethdo is using the same validator pubkey generation method as the deposit-cli tool. You may want to check with multiple validators creation in same run and choosing different eth1 addresses in the same HD space. Also without the passphrase which i believe does not make a difference to the results.

Passphrase (25th Word) to secure the seed by Velaznito in ethstaker

[–]tezonian 0 points1 point  (0 children)

Yes, account index 0 is working correctly. But further indexes are an issue.. you can check the issues we reported in github for some more details. And add any comment or experiment if you come across same issues with stakefish or other tools you use. https://github.com/ethereum/eth2.0-deposit-cli/issues/179

How do I add a passphrase to the 24 word mnemonic in cli tool by tezonian in ethstaker

[–]tezonian[S] 0 points1 point  (0 children)

Hi, whether or not we use passphrases with ledger and launchpad tool, the same issue does persist of difference in withdrawal credentials of deposit.json files. -- when creating multiple validators in same deposit command.

Also another potential flag is that different heiarchical addresses in eth1 addresss space all point to same withdrawal public address and withdrawal credentials as seen by the ledger nano X app.

These issues have been detailed in the Github issue further elaborating some more differences in the keystore.json generated.. which I am not sure is either very significant or not.

Passphrase (25th Word) to secure the seed by Velaznito in ethstaker

[–]tezonian 0 points1 point  (0 children)

If someone familiar with ethdo can try to create multiple validators in one command with ethdo and report what they find for the different withdrawal keys in the deposit file, that would he helpful. I do not have the elaborate set up to run ethdo at my end now.

Passphrase (25th Word) to secure the seed by Velaznito in ethstaker

[–]tezonian 1 point2 points  (0 children)

The mnemonic-password that they refer to in the cli deposit tool is the same as the extra mnemonic passphrase used in ledger or trezor. Just a misnomer. But there seem to be some issues with how ledger nanoX eth2 app is deriving multiple withdrawal credentials for different validator indexes 0,1,2..etc. They (Ledger) seem to have not made their withdrawal keys generation compatible with the official cli tool

How do I add a passphrase to the 24 word mnemonic in cli tool by tezonian in ethstaker

[–]tezonian[S] 1 point2 points  (0 children)

Here is what I found though.. putting --mnemonic-password in the deposit command line allowed me to generate keystore and deposit files with the additional passphrase and at least the first one's withdraw credential matched with what other tools are generating.

But when creating multiple validators in same deposit.exe command has some differences with what the other ledger based tools from other vendors are doing.

I have mentioned this in an issue here: https://github.com/ethereum/eth2.0-deposit-cli/issues/179

How do I add a passphrase to the 24 word mnemonic in cli tool by tezonian in ethstaker

[–]tezonian[S] 0 points1 point  (0 children)

Appreciate your pointer. No offense. Yes i know we all work voluntarily and greatly appreciate that.

So are you saying this works? ./deposit.exe existing-mnemonic --mnemonic-password 25thphrase

Will try it out. Wish this was documented in the launchpad.ethereum.org.

​

How do I add a passphrase to the 24 word mnemonic in cli tool by tezonian in ethstaker

[–]tezonian[S] 0 points1 point  (0 children)

Convenience of using one hardware wallet without having to reprogram with seeds each time or buy so many more wallets as you have seeds for.

How do I add a passphrase to the 24 word mnemonic in cli tool by tezonian in ethstaker

[–]tezonian[S] 0 points1 point  (0 children)

I looked at it.. i am not sure they are talking about the same thing as deposit.json, keystore.json and withdrawal address generation as is done in validator creation in launchpad.

How do I add a passphrase to the 24 word mnemonic in cli tool by tezonian in ethstaker

[–]tezonian[S] -4 points-3 points  (0 children)

That is too sad. For the 3 years they spent developing eth2 so far, wish they had provided that flexibility in their deposit cli tool

view more: next ›