by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 14:27
    cburgdorf closed #676
  • 14:27
    cburgdorf commented #676
  • 14:26
    cburgdorf closed #797
  • 14:26
    cburgdorf commented #797
  • 14:24
    cburgdorf closed #1044
  • 14:24
    cburgdorf commented #1044
  • 14:23
    cburgdorf closed #1091
  • 14:23
    cburgdorf commented #1091
  • 14:21
    cburgdorf commented #1133
  • 14:19
    cburgdorf milestoned #1133
  • 14:19
    cburgdorf labeled #1133
  • 14:19
    cburgdorf labeled #1133
  • 14:19
    cburgdorf labeled #1133
  • 14:17
    cburgdorf edited #1745
  • 14:17
    cburgdorf edited #1745
  • 14:16
    cburgdorf closed #1137
  • 14:16
    cburgdorf commented #1137
  • 14:15
    cburgdorf labeled #1745
  • 14:15
    cburgdorf opened #1745
  • 14:11
    cburgdorf closed #1195
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Guilherme Salgado> Happy to give it a go!
<Piper> Cool, it'll be roughly on par with the asyncio version but not quite 1:1
<Piper> And then when you get to the test suite, it would be awesome if we could run all of the tests against both backends (child using trio/asyncio)
<Piper> Awesome, that actually takes us in the direction I wanted to go in the first place of bringing the two libraries together.
KuDeTa
@KuDeTa
Is there an opensource effort to contribute to trinity eth2? What kind of state is it in?
And where is the otherside of this gitter bridge? Is there a discord somewhere?
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<carver> Yup, there are a number of contributors to trinity eth2, including several folks from the Ethereum Foundation. We're always happy to welcome another contributor if you're interested.
<carver> The other side is a discord used by EF contributors. But almost all trinity collaboration happens in this channel (or really, mostly on github).

<carver> Wow, from geth's latest release:

The highlight of the release is support for un-indexing transaction: configure how many recent blocks to keep searchable, saving up to 32GB SSD space if you remove all indices! 🤯
Probably makes sense to support something similar in py-evm/trinity.

KuDeTa
@KuDeTa
ok thanks carver. Can you let me know how to get started? It's been awhile since i python'd deeply but i've been following the prysm effort pretty closely. I need to spend some time reading through the current codebase and spec. What's the state of the eth2 client, how close to latest release? Testnet?
And how about the eth1 client?
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<carver> I think @ralexstokes will be better able to give you specifics on eth2 -- I thought he said something about having a milestone with attached issues, but I'm not seeing it.
<carver> The eth1 client development is active, we're pushing toward an MVP, which is... "soon" ™️ Progress tracked here: https://github.com/ethereum/trinity/milestone/4
KuDeTa
@KuDeTa
Awesome.
I almost started contributing 3 years ago - and life got in the way - i intend to make it stick this time. Let me do some reading. @ralexstokes a sitrep on Eth2 would be great. I'll be listening in on the dev call tomorrow anyway.
Thanks carver
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<carver> Great, happy to help! Looking forward to working with you whenever you get a chance. 🙂
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<ralexstokes> @KuDeTa happy to hear your interest -- i'll reach out soon with more info
<ralexstokes> would be great to have your help, we have a lot that needs to be done with our immediate goal being the multiclient testnet 🙂
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Guilherme Salgado> Anybody up for some quick code review? ethereum/trinity#1721
<Guilherme Salgado> I thought there'd be more interest in that one as it finally frees us from the damn EOFError on CI 😉
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Christoph> Woah! Awesome. I'm going to look at it after lunch. I've been in zen flow for the past couple of ours and know I noticed I'm half starved to death.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<carver> ping @Piper for ethereum/py-trie#102
Voith Mascarenhas
@voith
@carver Will trinity implement EIPs scheduled for Berlin? I didn’t see trinity listed in James Hanacock’s excel sheet?
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<carver> 👍 yeah, it was addressed during the call
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Guilherme Salgado> Hey guys, has anybody seen a DecryptionError('Invalid header mac: ... immediately after connecting to a local geth instance? I'm getting that when I try to run tests/integration/test_lightchain_integration.py or scripts/peer.py
<Guilherme Salgado> I used to be able to run that test locally, but now I get that and it fails. Thought that maybe it was a regression but tried a ton of different geth versions (and both building from source or installing from snaps), and I always get the same
<Guilherme Salgado> Running from the same venv I can connect/sync just fine to remote geth instances
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Guilherme Salgado> That error seems to come from the first msg after the handshake, when geth asks us for a certain block header to decide whether or not they can sync from us
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Guilherme Salgado> Ok, managed to reproduce it when connecting to a remote geth as well, but in that case it doesnt always raise that decryptionerror
<Guilherme Salgado> And it does not seem to ever happen with parity nodes
<Guilherme Salgado> http://sprunge.us/eds35B is a successful run, showin both geth and parity nodes sending us GetBlockHeaders
<Guilherme Salgado> http://sprunge.us/iOUvZg shows us disconnecting from the geth node because of the decryptionerror

<Guilherme Salgado> To reproduce, pull https://github.com/gsalgado/trinity/tree/misc and run

python -m scripts.peer -enode all

Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<Guilherme Salgado> @Christoph @carver @Piper I would really appreciate if one of you guys could try to reproduce that before I start digging. would also be good to know if you guys can successfully run

pytest --integration -s --log-cli-level=debug tests/integration/test_lightchain_integration.py

Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Guilherme Salgado> for me the test always fails, and in the logs I always see a line like this:

<Guilherme Salgado> > Bad message header from peer <p2p.transport.Transport object at 0x7f0b64eb5810>: Error: DecryptionError('Invalid header mac: expected 832e9207903d81f132bbde60f7b39

9be, got a0c0f8ab9d11734d4b9705145c2dd4b2')

Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Guilherme Salgado> Just found that with geth v1.8.22 (the version we use on CI) the test passes
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<carver> @Guilherme Salgado Yup, I get the same DecryptionError('Invalid header mac ...') with geth 1.9.14-stable
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<M H Swende (holiman)> That sounds interesting.. ^ I can take a look
<M H Swende (holiman)> So the handshake is successful, then the next message fails?
Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<M H Swende (holiman)> This looks odd:

19:26:08 INFO: Received GetBlockHeadersV65 (proto=(eth, 63)) from <Node(0x15ac30@52.176.7.10)>

Looks like geth would send a v65 message over 63 proto?

Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Guilherme Salgado> @M H Swende (holiman) it's actually a bug on our side: https://github.com/ethereum/trinity/issues/1001#issuecomment-633364583
<M H Swende (holiman)> Ok, thanks!
<Guilherme Salgado> @Christoph any idea why a getblockheaders msg over eth/63 is being decoded into a GetBlockHeadersV65, though?
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Christoph> @Guilherme Salgado It's because GetBlockHeadersV65 is shared across the eth/63, eth/64 and eth/65 protocols. We name the commands the highest version that it is still supported. But now that I think about it, maybe naming it GetBlockHeadersV63 would sound make it sound better? The issue would still be the same then, we would use GetBlockHeadersV63 across the protocols eth/63, eth/64 and eth/65.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Guilherme Salgado> Why not just GetBlockHeaders ?
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Christoph> Because when you start to diverge (e.g. with eth/66) you will have GetBlockHeaders and GetBlockHeadersV66 and then you are basically in the same situation where e.g. for the hypothetical eth/67 there may be no change and so you end up having GetBlockHeaders for everything below eth/66 and GetBlockHeadersV66 used for eth/66 and eth/67. And then maybe we drop everything below eth/66 at some point and go through the code base again to remove the V66 suffix again. To avoid this, we recently decided (there was some discussion in a PR) to just always use a Vxx suffix for these commands.
<Christoph> @Guilherme Salgado It's because GetBlockHeadersV65 is shared across the eth/63, eth/64 and eth/65 protocols. We name the commands the highest version that it is still supported. But now that I think about it, maybe naming it GetBlockHeadersV63 would make it sound better? The issue would still be the same then, we would use GetBlockHeadersV63 across the protocols eth/63, eth/64 and eth/65.