Provable Burn: ERC20 Extension

[alex-miller-0]

Title

EIP: 661
Title: Provable Burn of ERC20 Tokens
Author: Alex Miller
Created: 2017-07-01
Version: 3

Specification

A provableBurn function is added to an ERC20 token such that the owner of this token may sign a message to burn a certain number of tokens. This is an extension of ERC20 using the proposed provable_ standard from #662 .

function provable_burn(bytes32[3] sig, uint256 value) returns (bool) {
  // ABI definition of this function
  bytes32 word = 0xc1644b1f;
  address signer = ecrecover(msg, uint8(data[2]), data[0], data[1]); 
  uint nonce = nonces[signer];
  bytes32 msg = sha3(sha3(uint(value)), bytes4(word), address(this), uint(nonce));
  
  // Replay protection
  if (played[signer][msg] == true) { return false; }      
  
  // Update state variables
  played[signer][msg] = true;
  nonces[signer] += 1;

  // Burn tokens
  balances[owner] = safeSub(balances[owner], value);
  supply = safeSub(supply, value);
  Transfer(owner, 0, value);

  return true;
}

No tokens are moved during the burn. Rather, the number of atomic token units burned is simply subtracted both from the user's balance and from the total supply.

Rationale

Some token systems may desire to have users burn some number of tokens to unlock certain rewards. This uses the event emission proposed in #621, namely transfer to the zero address and requires the owner of the tokens to sign a message that proves the desire to burn them.

Per #662, calling of provable_burn may be outsourced with a signed message and played by any actor with the message. This includes a contract that might require this provable burn to happen before initiating an internal mechanism.

[alexvandesande]

Mmm I see two things happening here:

1. A function to burn tokens. This is indeed useful, as it's more deliberate than sending to a unretrivable address. Actually @evertonfraga added that to the ethereum.org/token example, after he added a trigger preventing accidentally sending to the zeroth address

2. Ability to execute token actions via signing messages. This is very useful too, but it could be extended to all other functions: move tokens, approve transactions, etc just by signing so the user doesn't need to pay gas

In my opinion these can be discussed separately

[alex-miller-0]

@alexvandesande Thanks for the comments. I opened a new EIP for the more abstract set of provable functions.

Please consider this EIP a discussion of the burn function proposed.

[vessenes]

I like this, but I'd like to recommend there be an optional metadata section here - we are working on a number of mechanisms which would like to attach some sort of data to a burn function. Happy to work up a proposed bit of code if desired.

[jpantunes]

I like this and I wanted to contribute with a suggestion for an alternative way of assuring replay protection:
// Replay protection
require(played[signer][msg] == false);

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.