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
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.
Lane Rettig
@lrettig
I said 14 sec based on https://ropsten.etherscan.io/chart/blocktime but there’s been a lot of variance lately
image.png
oh geez - that data is from 2017!
Noel Maersk
@veox
Yeah, was about to say...
Lane Rettig
@lrettig
I just noticed haha
So yea if the block time is indeed ~12.9 secs, my math shows block 4.2M happening in 10.16 days
Noel Maersk
@veox
It's regularly fluctuating on Ropsten. Hashpower comes and goes.
4242424 would actually come 6 to 7.5 days later than 4200000, so maybe 4200000 is better.
Martin Holst Swende
@holiman
@vbuterin your approval is required to merge the pr to the eip
So I didn't mean to ask about endianness, but the PR in general, since you're the author of the eip
ledgerwatch
@AlexeyAkhunov
@veox By "deterministic init code" I mean the init code that is, for example, always returns the same string regardless of what is on other contracts. What is deemed "deterministic" shall be agreed between the participants in a state channel
Noel Maersk
@veox
@AlexeyAkhunov Yes, I understand. What I meant is that deterministic behaviour can't be guaranteed by this destroy/re-create scheme. Just a thing to keep in mind.
ledgerwatch
@AlexeyAkhunov
@veox no, the destroy/re-create allows great flexibility that I wanted to bring to everyone attention. And this flexibility might have lots of uses outside of state channels. But for state channels, I suspect they will use very strict subset of init codes
Noel Maersk
@veox
Say, contract X references external contract E for some behaviour. contract E relies on a storage value in X being set. Destroying and re-creating X will see code for both X and E remain the same, but the behaviour of E will change, and so by extension will that of X's.