8 ms·

Eth2 dev here, maintainer of https://github.com/prysmaticlabs/prysm https://github.com/prysmaticlabs/prysm, one of the implementations currently running the blo

by rauljordan2020 6y ago

Eth2 dev here, maintainer of https://github.com/prysmaticlabs/prysm https://github.com/prysmaticlabs/prysm, one of the implementations currently running the blockchain written in Go. This has been a monumental effort. There are 3 other implementations in mainnet, and consensus is running perfectly. Few other protocols in blockchain have more than one dominant implementation. The beauty of eth2 comes from its efficiency in signature aggregation: https://twitter.com/technocrypto/status/1330150362427387910 https://twitter.com/technocrypto/status/1330150362427387910. This tweet thread summarizes the importance of the technology used.

nepthar 6y ago
Congrats to you and everyone else! Really cool stuff here :)
wrinkl3 6y ago
I remember Satoshi's old posts where he claimed that Bitcoin Core was the only viable full implementation of the Bitcoin protocol since it had too many quirks to be efficiently standardized and reimplemented. I wonder if that's still true.
- verdverm 6y ago
  https://github.com/bitcoinjs https://github.com/bitcoinjs
- auston 6y ago
  also: https://bcoin.io/ https://bcoin.io/
- iso8859-1 6y ago
  It would be disingenuous to claim that the Bitcoin protocol is only defined by the consensus layer. Then, if you require P2P protocol compatibility, I would say this issue shows that nobody really cares about alternate implementations: https://github.com/btcsuite/btcd/issues/1661 https://github.com/btcsuite/btcd/issues/1661 When Btcd was first released, it was pretty capable, and had lots of development. But it has fallen behind, which makes sense. Why would anybody take the risk of trusting that an alternate implementation when it doesn't decide what bitcoin is, in the end? You may have to patch bitcoind a bit to get your desired interface, but that is much less work than maintaining a full P2P and consensus layer. It is also dangerous to use you a non-standard crypto library. Check this vulnerability, which was caused by LND relying on the btcd project's library: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002856.html https://lists.linuxfoundation.org/pipermail/lightning-dev/20...
  - roasbeef 6y ago
    > Then, if you require P2P protocol compatibility, I would say this issue shows that nobody really cares about alternate implementations Does that? What I see here is bitcoind adding a new feature that isn't yet implemented in btcd. The new feature uses a different extension mechanism in the p2p protocol (a new message to signal knowledge of a new feature vs using the existing version message bits in the main p2p handshake). That new version of bitcoind also hasn't yet been released, but I'd imagine that btcd will land a fix sooner to permit unknown message types being sent from its PoV. > Check this vulnerability, which was caused by LND relying on the btcd project's library Incorrect. The btcsuite libraries we use weren't related to the bug at all. Instead, the bug was introduced by _new_ code which attempted to convert between the fixed 64-byte signature encoding used in the LN Protocol, and the variable sized encoding used in the base Bitcoin protocol. The resulting signatures _were_ valid ECDSA signatures, but didn't adhere to an additional constraint that the Bitcoin system places on this signatures from a mempool policy standpoint. The signatures themselves were still valid from the PoV of Bitcoin consensus, in that they would be included in blocks.
  - roasbeef 6y ago
    > Why would anybody take the risk of trusting that an alternate implementation when it doesn't decide what bitcoin is, in the end? bitcoind doesn't decide what Bitcoin is either: a recent consensus issue introduced for a period of times in _newer_ versions caused it to potentially fork off the "actual" chain. In this instance, btcd was unaffected along with many other implementations and earlier versions of bitcoind.
- centimeter 6y ago
  There are a number of alternative full node implementations, such as btcd.
- garmaine 6y ago
  This is still true (and is just as true of Ethereum, whether the devs on that project think of it as true or not). There is at least one instance in the past where the network has forked based on the (unspecified) behavior of bitcoind, and a couple more close calls where such forking behavior was properly reported and fixed before triggering. If there is any way in which different implementations of consensus-critical code behave differently for the same inputs, it can be used to split the network. If you are running a node implementation other than the majority hash-rate reference client, you open yourself up to be potentially vulnerable during the fork. This remains just as true, if not more so with staking instead of proof-of-work. You can do things to protect yourself like run ALL implementations and shut down if a fork is detected, although properly setting that up is nontrivial and in the end what value is gained? It very, very, VERY rarely makes sense to have multiple reference implementations of consensus code.
eMGm4D0zgUAVXc7 6y ago
Hey, I tried figuring out what the most recent official Ethereum wallet is, but the wallets which the website lists all seem like third-party ones. The previous official wallet's repository says "Mist and Ethereum Wallet have been deprecated.". Is it true that the Ethereum foundation isn't providing a wallet software anymore? Why is that? I would consider it as quite unsolvable as a user to determine which of the 24 third-party wallets is the most trustworthy, hence I'd prefer to just use one developed by the same people as Ethereum.
- pietjepuk88 6y ago
  With the advent of hardware wallets, and so many competing wallets/interfaces out there (tailored to different user bases), I feel it makes little sense for the Ethereum Foundation to pour their own (human) resources into this. They will support the ecosystems as necessary though, e.g. Metamask got funding way back in 2016.
  - eMGm4D0zgUAVXc7 6y ago
    > I feel it makes little sense for the Ethereum Foundation to pour their own (human) resources into this. Well, they received $ 18.3 million in crowdfunding [1], so I would dare to say it's not only "their" resources but also the resources of the community which they're spending, isn't it? Given that the central thing a user needs to use a cryptocurrency is the wallet it would seem a bit weird to collect $ 18M from their users to develop a cryptocurrency and then not develop the software which the users need to use the currency? I mean they're a non-profit organization, if they don't hand anything out for the $ 18.3 M then they have profited quite a bit by taking in money but not delivering effectively usable goods from it? [1] https://en.wikipedia.org/wiki/List_of_highest-funded_crowdfunding_projects https://en.wikipedia.org/wiki/List_of_highest-funded_crowdfu...
    - PretzelPirate 6y ago
      It’s odd to accuse the Ethereum Foundation of not delivering and it would be hard to back that claim. Developing yet another Ethereum wallet when there are so many on the market would be a waste. It’s better for the foundation to provide a list of high quality wallets that already exist.

nepthar 6y ago

Congrats to you and everyone else! Really cool stuff here :)

wrinkl3 6y ago

I remember Satoshi's old posts where he claimed that Bitcoin Core was the only viable full implementation of the Bitcoin protocol since it had too many quirks to be efficiently standardized and reimplemented. I wonder if that's still true.

verdverm 6y ago
https://github.com/bitcoinjs https://github.com/bitcoinjs
auston 6y ago
also: https://bcoin.io/ https://bcoin.io/
iso8859-1 6y ago
It would be disingenuous to claim that the Bitcoin protocol is only defined by the consensus layer. Then, if you require P2P protocol compatibility, I would say this issue shows that nobody really cares about alternate implementations: https://github.com/btcsuite/btcd/issues/1661 https://github.com/btcsuite/btcd/issues/1661 When Btcd was first released, it was pretty capable, and had lots of development. But it has fallen behind, which makes sense. Why would anybody take the risk of trusting that an alternate implementation when it doesn't decide what bitcoin is, in the end? You may have to patch bitcoind a bit to get your desired interface, but that is much less work than maintaining a full P2P and consensus layer. It is also dangerous to use you a non-standard crypto library. Check this vulnerability, which was caused by LND relying on the btcd project's library: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002856.html https://lists.linuxfoundation.org/pipermail/lightning-dev/20...
- roasbeef 6y ago
  > Then, if you require P2P protocol compatibility, I would say this issue shows that nobody really cares about alternate implementations Does that? What I see here is bitcoind adding a new feature that isn't yet implemented in btcd. The new feature uses a different extension mechanism in the p2p protocol (a new message to signal knowledge of a new feature vs using the existing version message bits in the main p2p handshake). That new version of bitcoind also hasn't yet been released, but I'd imagine that btcd will land a fix sooner to permit unknown message types being sent from its PoV. > Check this vulnerability, which was caused by LND relying on the btcd project's library Incorrect. The btcsuite libraries we use weren't related to the bug at all. Instead, the bug was introduced by _new_ code which attempted to convert between the fixed 64-byte signature encoding used in the LN Protocol, and the variable sized encoding used in the base Bitcoin protocol. The resulting signatures _were_ valid ECDSA signatures, but didn't adhere to an additional constraint that the Bitcoin system places on this signatures from a mempool policy standpoint. The signatures themselves were still valid from the PoV of Bitcoin consensus, in that they would be included in blocks.
- roasbeef 6y ago
  > Why would anybody take the risk of trusting that an alternate implementation when it doesn't decide what bitcoin is, in the end? bitcoind doesn't decide what Bitcoin is either: a recent consensus issue introduced for a period of times in _newer_ versions caused it to potentially fork off the "actual" chain. In this instance, btcd was unaffected along with many other implementations and earlier versions of bitcoind.
centimeter 6y ago
There are a number of alternative full node implementations, such as btcd.
garmaine 6y ago
This is still true (and is just as true of Ethereum, whether the devs on that project think of it as true or not). There is at least one instance in the past where the network has forked based on the (unspecified) behavior of bitcoind, and a couple more close calls where such forking behavior was properly reported and fixed before triggering. If there is any way in which different implementations of consensus-critical code behave differently for the same inputs, it can be used to split the network. If you are running a node implementation other than the majority hash-rate reference client, you open yourself up to be potentially vulnerable during the fork. This remains just as true, if not more so with staking instead of proof-of-work. You can do things to protect yourself like run ALL implementations and shut down if a fork is detected, although properly setting that up is nontrivial and in the end what value is gained? It very, very, VERY rarely makes sense to have multiple reference implementations of consensus code.

eMGm4D0zgUAVXc7 6y ago

Hey, I tried figuring out what the most recent official Ethereum wallet is, but the wallets which the website lists all seem like third-party ones. The previous official wallet's repository says "Mist and Ethereum Wallet have been deprecated.". Is it true that the Ethereum foundation isn't providing a wallet software anymore? Why is that? I would consider it as quite unsolvable as a user to determine which of the 24 third-party wallets is the most trustworthy, hence I'd prefer to just use one developed by the same people as Ethereum.

pietjepuk88 6y ago
With the advent of hardware wallets, and so many competing wallets/interfaces out there (tailored to different user bases), I feel it makes little sense for the Ethereum Foundation to pour their own (human) resources into this. They will support the ecosystems as necessary though, e.g. Metamask got funding way back in 2016.
- eMGm4D0zgUAVXc7 6y ago
  > I feel it makes little sense for the Ethereum Foundation to pour their own (human) resources into this. Well, they received $ 18.3 million in crowdfunding [1], so I would dare to say it's not only "their" resources but also the resources of the community which they're spending, isn't it? Given that the central thing a user needs to use a cryptocurrency is the wallet it would seem a bit weird to collect $ 18M from their users to develop a cryptocurrency and then not develop the software which the users need to use the currency? I mean they're a non-profit organization, if they don't hand anything out for the $ 18.3 M then they have profited quite a bit by taking in money but not delivering effectively usable goods from it? [1] https://en.wikipedia.org/wiki/List_of_highest-funded_crowdfunding_projects https://en.wikipedia.org/wiki/List_of_highest-funded_crowdfu...
  - PretzelPirate 6y ago
    It’s odd to accuse the Ethereum Foundation of not delivering and it would be hard to back that claim. Developing yet another Ethereum wallet when there are so many on the market would be a waste. It’s better for the foundation to provide a list of high quality wallets that already exist.