Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 02 2018 09:26
    @Arachnid banned @johnny_musk_twitter
  • Jun 06 2018 10:22
    @Arachnid banned @ethsupport1
  • Oct 21 2017 19:12
    @Arachnid banned @Musk11
  • Jun 05 2016 10:37
    @chriseth banned @adamskee
DigiDelight
@jamesdigid
if it is done this way, it would increase efficiency by adding computing power to the most recent block and offering higher reward if you truly want to sync all the way back down to the... Thinking about it older blocks take more work and should have higher reward for storing but newer chains lower reward but more consistent and faster
DigiDelight
@jamesdigid
@Arachnid Actually a better approach would be just have a DHT(simple table of block id hashes) of blocks/epochs/dynasties then take the top order chain and start processing in reverse order making more recent transactions priority... Building everything from first to last seems inefficient as the first few blocks will be accessed the least. Is my thinking in line with your philosophies, i'll be happy to work on an EIP if this is feasiable
feasible *
In either case, shouldn't reverse order building seem like an ideal approach as more recent blocks will be higher priority
*be
Nick Johnson
@Arachnid
@jamesdigid How would you process blocks 'backwards'? Transactions aren't reversible.
Micah Zoltu
@MicahZoltu
This says final but FORK_BLKNUM is TBA: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-155.md
Is it live yet?
Though, maybe it isn't a concensus impacting thing, just a recommendation to tool authors?
William Entriken
@fulldecent
Hello room
William Entriken
@fulldecent
I notice that the EIP list shows a Layer for each EIP. However when you open the EIP, there is no such Layer. It seems to me that this is arbitrarily added.
William Entriken
@fulldecent
I am pretty active on ERC-721. Not sure if anybody cares about that but I can do a lot more on it.
Nick Savers
@nicksavers
@whitj00 it's inconsistent naming. Category is also used. Check EIP-1 for the different categories / layers
Yoichi Hirai
@pirapira
@MicahZoltu it is live and is a consensus impacting thing.
@MicahZoltu https://github.com/ethereum/EIPs/blob/master/EIPS/eip-607.md says EIP-155 is a part of Spurious Dragon.
Nick Savers
@nicksavers
I suppose we could add the actual ETH blocknumber there but a few clients make it possible to enable EIPs starting at your own custom block numbers. So I supoo it should be clear that it's the ETH fork block
Micah Zoltu
@MicahZoltu
I recommend either adding the fork block number in place of TBA, or removing the the FORK_BLKNUM line all together. Having it there but TBA implies that it isn't actually a live change. (I strongly preference the first option of correctly setting the block number).
ethereum/EIPs#833 fixes this issue.
Yoichi Hirai
@pirapira
@nicksavers do you think it's a good idea to include the "previous fork" in fork EIPs? For example, the DAO Fork EIP mentions "Previous version: Homestead".
Nick Savers
@nicksavers
Having the fork block number might be enough to make this clear. Same can be said about the mention of the forks in the yellowpaper README
Yoichi Hirai
@pirapira
Right, if you have a table of all forks, block numbers are enough.
Nick Johnson
@Arachnid
I don't know why we use fork block numbers anyway. Why not use fork timestamps?
Yoichi Hirai
@pirapira
When mining takes too much time the block has to be created again.
William Entriken
@fulldecent
Hello. I am hosting a meeting on the non-fungible token ERC 721.
This meeting convenes 2018-01-19 17:00 GMT. It will last 60 minutes.
Please join then if you are interested.
Micah Zoltu
@MicahZoltu
@Arachnid As a means of deciding which block the fork block is, or for recording history in EIPs?
Nick Johnson
@Arachnid
@MicahZoltu The former
William Entriken
@fulldecent
We are NOW hosting a meeting on ERC-721 Non-fungible tokens
fulldecent @fulldecent finding link
William Entriken
@fulldecent
That is for transfer and call
ethereum/eips#677
The bytes are sent to a different function after the call goes through
This is a composition of sending and performing some other function
ethereum/eips#677 also includes provisions to ensure that a contract which receives tokens should be prepared to accept them
Does anyone see value in this?
I do not see value in this because the approve / transferFrom does this in an easier way
Does anyone see value in function composition being built into 721?
Sorry ignore ^^^
Federico Bond
@federicobond
Hi, I wrote a draft spec for typed errors using REVERT. Would love to get feedback: ethereum/EIPs#838
z-akira
@z-akira
is there any repo that implement the DAICO model already?
Vincent Stark
@vince-stark
Hey everyone! I'm working on a universal search interface standard ERC that would allow exposing a public interface for (yet-to-be-created) Ethereum search engines. Could you please quickly check it out: ethereum/EIPs#857 ? Is it a dumb idea, or is there something in it?
Paweł Bylica
@chfast
ethereum/EIPs#862
Anderson
@Ankarrr
In EIP55(Mixed-case checksum address encoding), I don’t understand why change some characters from lower-case to upper-case in address can help mistyping address? Could anyone help me?
Vincent Stark
@vince-stark
There are some more interesting use cases for ethereum/EIPs#857 - please check it out!
Paweł Bylica
@chfast
@karalabe EVM shift test cases have been added: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-145.md#test-cases