Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 21 2017 21:24
    @jpitts banned @Musk55
Felix Lange
@fjl
You could also make them deterministic and use the prefix of sha256(tag || message-pt) or something.
Antoine Toulme
@atoulme
ok
Felix Lange
@fjl
This needs to be explained better in the spec :)
Antoine Toulme
@atoulme
how about we just write a testing tool that tries to break in
Felix Lange
@fjl
Sure, you can try that. Just still thinking about the best way to implement that session cache.
Probably best if we just use an LRU cache with entries containing [read-key, write-key, counter].
Maybe spec should recommend the 4-byte counter, 8-byte random construction for the nonce then.
Antoine Toulme
@atoulme
yeah. It’s ok it’s early days there.
Felix Lange
@fjl
Just submitted the final update to the ENR spec:
I feel a lot better about the whole IPv6 thing now.
Felix Lange
@fjl
Does anyone object to changing the status of EIP-778 to "accepted" and committing to this spec? I'll bring it up in the allcoredevs call, just asking because there might be people here who can't join that call.
Nick Savers
@nicksavers
@fjl for Accepted do you have (commitment for) implementation of the protocol change in the major network clients?
Felix Lange
@fjl
EIP-778 and EIP-868 are implemented in geth, aleth and Apache Tuweni (née Cava DevP2P). Not sure if that's sufficient for accepting the EIP.
Nick Savers
@nicksavers
What are the commitments made by teams working on other clients? Parity, Pantheon, Ethereumjs, PyEVM?
Frank Szendzielarz
@FrankSzendzielarz
@tkstanczak Pls see above on ENR...for later call on discv5 in general
Tomasz Kajetan Stańczak
@tkstanczak
see it, thanks
Felix Lange
@fjl
@BNI haven't heard commitments from other clients yet.
(Sorry wrong mention, meant @nicksavers )
Nick Savers
@nicksavers
Knowing their intentions to support the protocol changes would be useful.
Tomasz Kajetan Stańczak
@tkstanczak
I have spoken with Frank - we would be hugely in favour of introducing the ENR EIP-778, would be great to test the implementation together or through Hive
this is on behalf of Nethermind
Daniel Lipshitz
@DanielLipshitz_twitter
HI All - looking to subscribe to trxs before they go through the dropping criteria of the node - running parity - in Bitcoin we do this using P2P and listening to INV messages - is their something similar in Ethereum we could use? Is this possibly an option
I would use this : https://wiki.parity.io/JSONRPC-parity_pubsub-module
Tomasz Kajetan Stańczak
@tkstanczak
there is a Kafka pubsub in Nethermind and that can be customized
also gRPC
may need some work from us
@DanielLipshitz_twitter
Daniel Lipshitz
@DanielLipshitz_twitter
Ok thanks
Daniel Lipshitz
@DanielLipshitz_twitter
HI All - following up here - dont think the pubsub or other client API into the node will help us - we looking to receive external trxs before they go through the dropping or acceptance logic being added to the transaction queue example - https://wiki.parity.io/Transactions-Queue - the aim is to catch any double spend attempts - is it possible to configure the dropping logic on parity or are you aware of other options possibly P2P environment which could assist ? Thanks @tkstanczak
Felix Lange
@fjl
Geth has a JSON-RPC endpoint that dumps p2p messages. It is very low-level though, and doesn't fit your problem exactly because it doesn't expose message content - only message type for now.
We could extend that though
Otherwise just extend a client yourself to catch the transactions message
Daniel Lipshitz
@DanielLipshitz_twitter
thanks that sounds interesting - are you referring to this https://github.com/ethereum/wiki/wiki/JSON-RPC#shh_getmessages - Is it possible to receive all messages and then filter for trxs?
Tomasz Kajetan Stańczak
@tkstanczak
@DanielLipshitz_twitter - talk to Rick Dudley - I think thay do exactly that at Vulcanize
@DanielLipshitz_twitter - also from Nethermind you can get txs before they go through anything - just Vulcanize runs nodes around the world to get txs faster
Daniel Lipshitz
@DanielLipshitz_twitter
Ok thanks
Felix Lange
@fjl
@DanielLipshitz_twitter no, it's another endpoint, it's not documented. I'll get back to you next week if you still need it.
jannikluhn
@jannikluhn
from the discv5 wire protocol spec: "The authentication header also contains [...] node A's node record if the local sequence number is higher than enr-seq.". I assume this refers to auth-response-pt = [id-nonce-sig, node-record]. What if the sequence number is up to date already? Does auth-response-pt become [id-nonce-sig] or [id-nonce-sig, ""] or something else?
Felix Lange
@fjl
Very good question
I have to clarify it in the spec
It's [id-nonce-sig, []] in Go right now
(I think)
Daniel Lipshitz
@DanielLipshitz_twitter
HI All - we using https://github.com/ethereumjs/ethereumjs-devp2p/blob/master/examples/peer-communication.js however when we sort for TX messages and compare to our Parity node - we seem to only get 50% of the TX which our parity node receives - possibly their is a setting we need to update - Thanks
Antoine Toulme
@atoulme
you might want to open an issue on the repo and document how to reproduce the behavior you are seeing.
Daniel Lipshitz
@DanielLipshitz_twitter
Thanks did that - it looks like we solved the issue by commenting out https://github.com/ethereumjs/ethereumjs-devp2p/blob/master/examples/peer-communication.js#L283 txCache limit
Daniel Lipshitz
@DanielLipshitz_twitter
Correction issue isnt solved - we create a list of trx received via pairty on the list for 10 seconds and compare to see if received from p2p - it still 50/50
Zelos
@Zelos39482837_twitter
hi