Refunding Design

Another issue we encountered is what to do in a situation where there are no miners available and someone has excess funds. We have two possible options to address this:

1. Automatically refund the funds: In this scenario, if there are no miners to process the transaction, the system will automatically initiate a refund of the excess funds to the sender.

2. Destroy the transaction: Alternatively, if there are no miners and excess funds are detected, the system can choose to destroy the transaction altogether, ensuring that the excess funds do not remain in an unresolved state.

These options provide potential solutions for handling situations where there is a lack of available miners and excess funds are involved. The choice between refunding the funds or destroying the transaction depends on the specific requirements and considerations of the system.

Here is the design details:

Accoun

A ---> B 
A ---> C

UTXO

/
A  ---> B 
   ---> C 
   ---> D
utxos = (txs vout = null)

//---MINT---//
mint -> f run( 
----insert into utxos (txid, value, vin_txid, vin_vout) values (hash, value, "coinbase", 0) )

//---TRANSFER---// 
transfer -> 
----f index for Transaction( 
--------vout ( 
------------f run( 
----------------insert into txs (txid, value, vin_txid, vin_vout) values (hash, select -> value, input -> txid, index) 
------------) 
--------) 
--------vin ( 
------------f run( 
----------------update txs set vout_amt = NULL 
--------------------------AND vout_addr = NULL 
------------) 
-------) 
----)

   

We conducted a voting process and sought input from the community regarding the issue. The final voting results indicated that the majority of users preferred a direct refund as the solution. Based on this feedback, we have decided to align our technical path with the refunding rule.