RFC: Transfer By SHA variants of ESIP-1 and ESIP-2

[tunnckoCore]

The idea is simple: allow transferring Ethscriptions by SHA (keccak256).

In fact, it's proposing 2 new contract events ethscriptions_protocol_TransferEthscriptionBySha and ethscriptions_protocol_TransferEthscriptionForPreviousOwnerBySha.

ESIP-1 variant with transfer by sha:

event ethscriptions_protocol_TransferEthscriptionBySha(
  address indexed recipient,
  bytes32 indexed contentSha
)

ESIP-2 variant with transfer by sha:

event ethscriptions_protocol_TransferEthscriptionForPreviousOwnerBySha(
    address indexed previousOwner,
    address indexed recipient,
    bytes32 indexed contentSha
)

Reasoning

if people are creating through ESIP3 (or the eventual esip3-like "createFrom", #25 ) the contract can save the SHA, and keep track of Ethscriptions by their SHA.

If there are multiple Ethscriptions with that SHA, eg. esip6, then loop over them and transfer only the ones which are owned by prevOwner (esip2) or currentOwner (esip1).

The use cases

As always, i have exact use cases.

Scenario 1: Auction House collection distribution

If i have an auction house, and want to use it as collection distribution (a la Nouns, "minting and putting in auction" in one go).. people would "mint", it will calculate the content's SHA, and emit the ESIP-3 (or #25). On that mint time, we know the content's SHA, we store it in the contract and then we can start immediately an auction for that SHA. Then when highest bidder win, we would be able to just transfer given that SHA because we track it.

This transfer by sha would allow us to know things in the same transaction - the sha as first class citizen, not just the transaction hash which is impossible to get on the same transaction - like, we can't/don't know the ethscription "id" at that moment, eg. at the moment of the "mint". But we can know the content sha in advance.

Like, the problem is that, at the time of the mint, we don't know the Ethscription ID (the transaction hash that's calling the mint). And because we don't know that, later when someone win the auction, we cannot transfer what it won (unless there's bot that links the contract-stored sha to the actual ethscription id (tx hash). If we can transfer by sha we can generate the sha on mint time, then when someone win, we transfer by that sha - it would be used as "auction id".

Scenario 2:

Anything that wants to create Ethscription and use it immediately. If there's some protocol or dapp that needs to mint stuff on user auction, they can't - first because ESIP-3 always sets the creator to the contract address emitting the event, and second because in an open system you cannot force users to deposit after the action - you can pray for that, your dapp or wallet CAN do it in a batch call or something but it's not an absolute guarantee in on-chain perspective.

---

Both this proposal and #25 are opening new apps and possibilities. Allowing building more stuff on top of the protocol.