Blockchain Transactions Suck. TLDR; proposal of a contract that will…
By: Daniel Choi
Tags: Solidity, Smart Contracts, Ethereum, Dapps, Blockchain

Has there ever been an instance where you had doubts that you were sending something to the right person over the internet? This can be quite scary, especially when transferring valuables or large sums of money. We must trust the platform or service to provide this assurance and certainty to its users. Any fear, uncertainty, or doubt that one might experience might deter them from using the product.

In blockchain, there can be some uncertainty that one is sending an amount of token or asset to the correct address. There are a few ways of verifying that the recipient is the correct one.

A few are listed below:

For EOA (externally owned account): send a small amount of token to the address, receive confirmation that they had received it, send the rest of the amount.

For smart contracts: go to the network’s monitoring site to verify that the contract code is correct (if available). Also can send a small amount to see if the transaction was made to the correct smart contract address.

Simpler solutions are needed to lessen uncertainty and in turn, pave the way for mass adoption.

Image from etherscan.io. Transactions with small amounts of ETH are sent to verify that the right address is used.

A little bit of motivation:

At the recent hackathon in EthDenver, I was speaking to Joseph Delong who was trying to make a transaction to the MolochDAO smart contract. This required staking of 100ETH in order to be a founding member of this project. He had some fear that he might have been sending the funds to the wrong address. 100ETH (valued at $13195, at time of writing) is not an insignificant amount of money that anyone would be fine with losing. This then got me thinking… how can we make users feel secure about sending funds to the right person?

Some Useful Information:

In Ethereum, it is possible to send a transaction to an address that is not owned by any user.

It is near impossible to have a transaction reverted after it has been included in a block.

The recipient could send your money back but this would be very unlikely.

The only other way to get your money back would be to have the approval from the whole Ethereum community to fork.

There is a solution to use ENS (Ethereum Name Service) to send a transaction to a human-readable name (e.g. araskachoi.eth); however, this process is very difficult and time-consuming (may take about 3–5 days).

— Here is the actual (complicated) process of buying an ENS.

— Some issues with this procedure are (but not limited to):

— — If you miss the timing of revealing your bid, you will lose your bid amount and also not be able to claim the domain name.

— — If you are lucky and there are no other bidders, you can re-bid to buy the domain name again.

Proposed solution:

An unpolished solution I have come up with is to have a smart contract that will facilitate the transferring of funds with preventative safeguards.

The user flow of this contract will be as follows:

1. The sender will deploy this smart contract — CCRFactory (the sender is the owner of this smart contract)

2. The sender will pay the smart contract (the amount to send to the recipient)

3. The sender will specify the recipient address to the smart contract

4. The recipient will verify they are the correct person (address)

5. The sender will release the funds to the recipient

User flow of the smart contract.

The safeguard:

Each smart contract is disposable and a new one will be generated for every secure transaction you would like to make.

If the recipient address has been incorrectly inputted, the sender can choose to self destruct the smart contract and return the funds.

Requires a verification transaction from the recipient to release the funds.

Here is the smart contract code:

pragma solidity 0.4.25;

*

*

* functions, this simplifies the implementation of "user permissions".

*/

contract Ownable {

...

} /** @title Ownable @dev The Ownable contract has an owner address, and provides basic authorization control* functions, this simplifies the implementation of "user permissions".*/contract Ownable {... // Certainly Correct Receiver Factory Contract

contract CCRFactory is Ownable {

address _receiver;

bool _receiveValidation; event Deposit(address _sender, uint value);

event Validate(address _receiver); constructor() {

_receiveValidation = false;

} // only owner can set the address of the receiver

function setReceiver(address receiver) public onlyOwner {

_receiver = receiver;

}



// receiver will confirm that they are the person that we want to interact with

function confirm() public {

// verify that the receiver is the correct person (address)

require(msg.sender == _receiver);

_receiveValidation = true;

}



// sender will be able to see if the confirmation has come in from the receiver

function getConfirmation() public onlyOwner returns(bool) {

return _receiveValidation;

}



// the sender will send the funds to the receiver after checks have been made

function sendToReceiver() onlyOwner public {

require(_receiveValidation == true);

release(_receiver);

} // internal function to send the contract funds to the receiver address

function release(address _receiver) internal returns(bool) {

// transfer ETH to _receiver

_receiver.send(this.balance);

} // manual kill switch for owner to reclaim funds at any time

function kill() public onlyOwner{

selfdestruct(msg.sender);

} function() payable {

if (msg.value > 0) {

Deposit(msg.sender, msg.value);

}

} }

* I have collapsed the `Ownable` smart contract for ease-of-read. The full contract can be found here.

In Conclusion

This will allow the user to confidently send any amount of ETH to a recipient and give them the ability to take back the amount if the address was mistyped or incorrect. This is a crucial aspect to consider in blockchain (Ethereum) as there is no customer support number or email you can reach to have this dilemma figured out.

This little idea/project can be extended to use an oracle to include a feature that can request the recipient’s email or phone number. Once the funds have been added to the smart contract, an email or text will be sent to the recipient. This will prompt the recipient to verify that they are the correct person so that the sender can release the funds to them.

Another aspect to consider would be how this would interact with another smart contract. Right now, the presented solution is only possible with two users (EOAs). The problem here would be that a smart contract would need to be able to identify itself as the correct address but this might prove to be difficult. But maybe that’s for another post (or comment if you want to discuss!)