Initial reference implementations

[owocki]

No description provided.

[lrettig]

I intend to implement this myself in Trinity this week, to start. I don't think it will be too complex. (Famous last words.)

[lrettig]

Responding to @GregTheGreek's comment from #5:

@lrettig The idea was to come up with a way to introduce it to protocol level without having to add an additional TX to the block. The problem I identified was thats we need to be able to verify that the amount to be transferred is correct. I've been going through what i wrote and it adds a huge state size overhead, an extra ~115.2kb / day (i believe), which is a bit counterintuitive to the goal.

Could you share this math/code? Why do you think adding one tx per block is such a big deal?

to address the DAO issue, my idea is baked into the concept that every miner has the option of where to send it to. That way they can choose the individual or DAO of choice.

I don't think miners should have an option where to send the reward. I think that should be specified and hardcoded in-protocol to begin. @owocki and I have discussed this a bunch but governance over where the funds go, and what the percentage gets set to, will be contentious so the simplest thing to do in the beginning is to hardcode things in-protocol (so that they can only be changed via a hard fork).

(If miners have the choice where to send it, they could opt to send it to themselves, thus bypassing the tax completely. This is counter to the idea of a community fund.)

[GregTheGreek]

@lrettig

Could you share this math/code? Why do you think adding one tx per block is such a big deal?

The ~115kb was in reference to expanding the extra_data field from 32 bytes to 64 bytes.

I don't think miners should have an option where to send the reward. I think that should be specified and hardcoded in-protocol to begin. @owocki and I have discussed this a bunch but governance over where the funds go, and what the percentage gets set to, will be contentious so the simplest thing to do in the beginning is to hardcode things in-protocol (so that they can only be changed via a hard fork).

100% i agree with you, but I didn't really view it as a tax rather as an option. As a tax, it would be very simple to implement I could provide an example in for you on the go-ethereum code base :) I've actually done this before for a client!

[lrettig]

Good. I'll do it in Trinity, you do it in geth, I check your code, you check my code, bada-bing, bada-boom, we have two reference implementations. Race you. Go!

[GregTheGreek]

EIP coding competitions. I love it

[lrettig]

It's a thing now. EIP codeathon.

[GregTheGreek]

@lrettig soooo here it is without any tests:
Made an assumption, that instead of reducing the fee with a percent (i.e 10% tax on 2 ETH reward) I just reduced the reward constant to prevent the additional computation.

Here's the commit

EDIT: Update commit hash

[lrettig]

Here's the initial reference implementation in Trinity: lrettig/py-evm@ee5a23f

[GregTheGreek]

@lrettig Looks good to me!

[owocki]

@GregTheGreek @lrettig

Forgive the naive question, but is it enough to build a fee into each individual client? How do other client's that are validating the blocks produced validate that the fee went to the right beneficiary and for the right amount? It would seem we need to protect against some rogue client sending 100000 ETH to a bad beneficiary! Do we need to add some code that validates blocks by other miners, that they've correctly added the fee?

[lrettig]

All of the changes we've made here are in-protocol. That means that all clients must agree on them and implement the exact same change or we have a consensus failure.

Simple right? That's the beauty of the protocol 😇

[gitcoinbot]

⚡️ A *Eth Hacker* Kudos has been sent to @lrettig for this issue from @owocki. ⚡️ The sender had the following public comments: trinity client mod is awesome! Nice work @lrettig! Your Kudos has automatically been sent in the ETH address we have on file.

[gitcoinbot]

⚡️ A *Eth Hacker* Kudos has been sent to @GregTheGreek for this issue from @owocki. ⚡️ The sender had the following public comments: yay, thanks for the client mod! :) Nice work @GregTheGreek! To redeem your Kudos, login to Gitcoin at https://gitcoin.co/explorer and select 'Claim Kudos' from dropdown menu in the top right, or check your email for a link to the Kudos redemption page.

[GregTheGreek]

@owocki To add to Lane's comment. This version would mean its a fixed number to a fixed address. So everyone would need to agree with it!

If you want it to be dynamic, so that anyone could chose their how much and where to send, it gets quite complicated and requires a more extensive mods. Which I eluded to in previous discussions