by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Feb 28 2019 19:45
    @Arachnid banned @merkle_tree_twitter
  • Feb 17 2019 00:56
    @jpitts banned @Aquentson_twitter
  • Apr 09 2018 04:14
    @holiman banned @JennyJennywren_twitter
  • Oct 21 2017 19:12
    @Arachnid banned @Musk11
ledgerwatch
@AlexeyAkhunov
now it does exactly the same number of accesses as Hashimoto (existing ethash) = 128. And because they use simpler keccak function, it is faster than Hashimoto. Again, no wonders here too
Paweł Bylica
@chfast
Thanks for checking it out. I didn't have time yet to compare this with the EIP. The progpow verification takes here 0.0013 ms which is suspiciously fast. The 0.9 ms is for Ethash verification (Go time is 4 ms).
ledgerwatch
@AlexeyAkhunov
Ah, 0.9ms is EtHash. I see
ledgerwatch
@AlexeyAkhunov
actually, Progpow makes 64 accesses
Paweł Bylica
@chfast
Do you know where to find Keccak-f[800] reference implementation with test cases?
ledgerwatch
@AlexeyAkhunov
it uses simpler keccak too, that is why maybe it faster. But I would also be sceptical. Also, since the algorithm has been changed so much (judging by the significant change of number of accesses), does it still has claimed ASIC-resistant properties? I did not look at any depth into why it has these properties, because I have a limited understanding of modern ASIC design and manufacturing processes, but I just know that innovation in that space is very fast
@chfast No, I don't know where to find them, sorry
Paweł Bylica
@chfast
There must be bug in the code as progpow verification should be slower (https://github.com/ethereum/go-ethereum/pull/17731#issuecomment-424519942), not 1000x faster.
ledgerwatch
@AlexeyAkhunov
The latest piece I am reading about is the article "A Domain-Specific Architecture for Deep Neural Networks", which describes how Google went from using GPUs for deep learning to in-house developed TPUs (Tensor Processing Unit). Here is one quote I like
Paweł Bylica
@chfast
@lrettig No, SHA-3 is based on Keccak-f[1600]. The algorithm is the same, but state size is different (uses 32-bit words instead of 64-bit words). I have to find some constants for this variant. Will find it, don't worry.
ledgerwatch
@AlexeyAkhunov
"Since transistors are not getting much better (reflecting the end of Moore's Law), the peak power per mm^2 of chip area is increasing (due to the end of Dennard scaling), but the power budget per chip is not increasing (due to electro-migration and mechanical and thermal limits), and chip designers have already played the multi-core card (which is limited by Amdahl's Law), architects now widely believe the only path left for major improvements in performance-energy is domain-specific architectures. They do only a few tasks but do them extremely well".
I am also reading another book, called "Parallel Algorithms and Architectures" by F. Thomson Leighton (superficially for now)
and the intuition that I got from these two sources is that ASICs (or Domain-Specific architectures) can beat GPU not just because they do less things, but also because they can have different computing architectures, like two-dimensional arrays, or meshes, which allow systolic computations instead of GPU model, where all the computation flows through the registers
so it is not that simple
Greg Colvin
@gcolvin
Way back in the mid-1970s I was wanting to emulate portions of the nervous system with physical networks of microprocessors. I was told that any parallel process can be simulated efficiently on a serial computer, and went back to feeding punch cards full of FORTRAN to our mainframe...
ledgerwatch
@AlexeyAkhunov
@gcolvin Ha-ha :) at that time, I suspect, the Moore's Law was still a thing, so advice you were given totally made sense. But now ASICs and Domain-Specific architectures is the only way. We already see the rise of meta-programming (programs write programs), I guess we will see the rise of meta-programming when programs design hardware, print it, and so on. This should gradually abolish the supremacy of large chip companies (I suspect a lot of their hardware design tooling is implemented in hardware itself)
Alex Beregszaszi
@axic
Is the specification of extcodehash “final” or are there any expected changes to it?
Reason I am asking is I’d like to merge the PR adding it to the Solidity assembler and having confidence in:
  • the opcode number
  • the fact that it will be part of constantinople
  • (and would be nice to be confident in the associated gas cost)
Paweł Bylica
@chfast
@holiman @AlexeyAkhunov Here are test vectors for Keccak-f800 from Keccak Code Package: https://github.com/XKCP/XKCP/blob/master/tests/TestVectors/KeccakF-800-IntermediateValues.txt
Danny Ryan
@djrtwo
What is (if there is one) the common strategy to handle peers that send a huge number of txs with gasprice that is too low?
Mikhail Kalinin
@mkalinin
I am sure it depends on client's implementation. EthereumJ has a gas price threshold for Tx mem pool, Txes with gas prices lower than that threshold just skipped. And there is nothing that would be done with the peer in that case. I think it worth to reduce peer's reputation if it sends tons of spam messages.
ledgerwatch
@AlexeyAkhunov
@djrtwo I just checked in geth. There is no penalisation. In this "case" clause at the link, you can see that the only place "p" (peer) is still associated with the transaction is the call to p.MarkTransaction(). And inside that MarkTransaction, it only adds tx ID to the set of max 32k transaction that the peer "knows about", so that we do not send them back to the same peer: https://github.com/ethereum/go-ethereum/blob/4b6824e07b1b7c5a2907143b4d122283eadb2474/eth/handler.go#L666
Danny Ryan
@djrtwo
Thank you!
Mikhail Kalinin
@mkalinin
Btw, known Txes set is implemented in EthereumJ, also, and it works in the same way as @AlexeyAkhunov described, this set is also used to quickly recognize already known Txes if they come again from the net
ledgerwatch
@AlexeyAkhunov
Yes, the determination of whether to ignore certain transaction happens in the tx pool, by which point the information about which peer sent it, is not there anymore
ledgerwatch
@AlexeyAkhunov
same for parity. I think. In the code under the link, you can see that peer_id is not passed into "import_external_transactions" (this is where txs get to the pool). In the "notify.transaction_received()" no penalisation happens either. https://github.com/paritytech/parity-ethereum/blob/cc963d42a06bcae2480cec657fa4b55a829fdaa6/ethcore/src/client/client.rs#L2099
Greg Colvin
@gcolvin
@AlexeyAkhunov Yeah, Moore's law was in the process of becoming an imperative about then. Still, there was a market for Cray's specialized vector machines.
ledgerwatch
@AlexeyAkhunov
I have read that article about TPUs a bit further, and understood that Google only uses TPUs for inference on the neural networks that have already been trained. For the training itself, it is still GPUs :)
S. Matthew English
@s-matthew-english
is there an agenda for the next meeting?
just to share it around with other PegaSysers and make sure we have all the relevant information for the call
ah
it's this I guess...
Paweł Bylica
@chfast
If someone whats to review some "crypto" code I sending changes related to ProgPOW here: https://github.com/chfast/ethash/pulls
Danny Ryan
@djrtwo
eth2.0 implementer call in a little more than one hour. agenda here ethresearch/eth2.0-pm#8
zoom link to follow
Danny Ryan
@djrtwo
Hudson Jameson
@Souptacular

@/all Core devs meeting in a little less than 12 hours

Agenda for meeting: ethereum/pm#58

Videoconference Link: https://zoom.us/j/717504189

We will be having someone who has ran new benchmarks for EIP 1108: Reduce alt_bn128 precompile gas costs.

We will also be having the team behind ProgPoW on the call so we can all sync up with what various people have been doing to test, benchmark, and otherwise explore it.

Please look over EIP 1108 and think of any questions you have for the ProgPoW team.

Hudson Jameson
@Souptacular
@/all 15 minutes until the call
Martin Holst Swende
@holiman
Trying to get this merged: ethereum/EIPs#1375 . Clarifications regarding Skinny Create2 cc @vbuterin
vbuterin
@vbuterin
not sure I understand the question
0xff is a single byte, why would it have endianness?
Lane Rettig
@lrettig
Preliminary call notes are up, please PR additions and corrections, thanks! https://github.com/ethereum/pm/blob/master/All%20Core%20Devs%20Meetings/Meeting%2047.md
ledgerwatch
@AlexeyAkhunov
@lrettig Awesome as always!
Noel Maersk
@veox
I'm just listening to the recording... How about block 4242424 for Ropsten fork?
I use https://ropsten-stats.parity.io/ for basic stats on Ropsten.
OK, you've settled on 4200000.
Lane Rettig
@lrettig
https://ropsten-stats.parity.io/ is helpful, it says the average block time is 12.89 sec. I used 14 sec in my math. If it is indeed 12.89 sec (not sure over what time horizon this is calculated), then it will be closer to ten days from now, not 11.
Noel Maersk
@veox
In principle, having deterministic "init code" in CREATE2 doesn't guarantee anything to the counterparty. For example, the "init code" can reference an outside contract X that's itself a dispatcher. So, although the "init code" itself doesn't change, the behaviour might.