2

For example, firefly.eth currently resolves to 0xce31f0ad68d9565004bbe351a8677eb74c86866d

Without my software knowing or looking up the specific address "0xce31f0ad68d9565004bbe351a8677eb74c86866d" before it creates the transaction (the way almost all wallet software supporting ENS does/will do), can I sign a transaction which sends funds from my externally owned secp256k1 account directly to "whatever firefly.eth resolves to" without knowing that information at the time the transaction is created? I dont want to send it to some type of custom built contract that first resolves firefly.eth and then forwards my funds to "0xce31..." once it obtains it. I want the funds to go directly from my account to "0xce31..." so that if "0xce31" checked the msg.sender it would consider the funds to have come from my account directly.

Is this possible?

1
+50

The answer is "no". You either need to resolve the address outside the chain (via web3 or whatever), or have an on-chain contract do it for you.

If the hard requirement is that msg.sender is your address, then you would need to resolve the address via an off-chain solution.

| improve this answer | |
1

I dont want to send it to a contract that first resolves firefly.eth and then forwards my funds to "0xce31...", I want to send from my account directly to "whatever firefly.eth resolves to".

I think you are misunderstanding how the ENS system operates, because it actually works like you want it to, to the best of my knowledge.

The way the ENS system works, the ENS public resolver doesn't actually forward funds as part of name resolution, the contract only holds the database which off-chain code can use to resolve ENS names. This means that firefly.eth gets converted to 0xce31... before your funds even leave your wallet.


When you send funds from your address to an ENS name, the following happens, as an example:

  1. You type "firefly.eth" into the destination field on your wallet and send 1ETH to it.

  2. Your wallet runs the addr function of the public ENS resolver contract (after hashing the address) to resolve firefly.eth to 0xce31....

  3. Your wallet signs and sends a transaction for 1ETH directly to 0xce31... without any middlemen, forwarding, or any more contract code.


So your funds themselves never go through any contract. The ENS resolver contract is used in resolving the final address, then your funds go there directly.

For more information on how ENS name resolution works, check out the ENS paper.

| improve this answer | |
  • Look, I understand how ENS works. I'm not under the impression that the ENS resolver is a forwarder or anything like that. And I know that right now most wallets simply do the resolving clientside before forming the transaction. That is explicitly not what I want, which is why I clarified that. What I could also do just fine is write my own forwarding contract that does do the lookup and then forward the funds to the resolved address. But I don't want that either, because the call to 0xce31... would be coming from the forwarder instead of from the EOA. – Jeff Coleman Jun 10 '17 at 18:08
  • This is a much more technical/lower level question than just about the workings of ENS. Imagine a hardware wallet trying to be sure that a given transaction is going to firefly.eth for example. How can we write a transaction that guarantees this without routing through a forwarding contract which would change the msg.sender? That is my question. – Jeff Coleman Jun 10 '17 at 18:20
  • @JeffColeman To the best of my knowledge there is no way to send money from a contract and have the msg.sender show an address other than the contract address. As far as a hardware wallet being sure that a given transaction is going to firefly.eth, the hardware wallet would either need to be a full node itself (to be able to verify the ENS public resolver contract state) or trust the software running on the computer it's plugged into to do the ENS resolution properly. If you have a Trezor/Ledger, I think that you just can't send to an unresolved ENS name and have it be fully trusted. – Maximillian Laumeister Jun 10 '17 at 18:20
  • @JeffColeman Other than that you would still need a forwarding contract, if you want the ENS name to be verified on-chain. Edit: Hopefully someone else will prove me wrong. – Maximillian Laumeister Jun 10 '17 at 18:21
  • If true, the answer to this question will be no. (which is what I'm thinking, although I asked this question to be sure). And that's quite unfortunate, because from an evidence perspective, there's no reason we can't do this--it's just a technical gap. In fact, more generally being able to attach multiple actions or true/false asserts to a transaction would make things so much better for a variety of needs. – Jeff Coleman Jun 10 '17 at 18:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.