Vitalik wrote the following in the Ethereum white paper.

Value-blindness - there is no way for a UTXO script to provide fine-grained control over the amount that can be withdrawn. For example, one powerful use case of an oracle contract would be a hedging contract, where A and B put in $1000 worth of BTC and after 30 days the script sends $1000 worth of BTC to A and the rest to B. This would require an oracle to determine the value of 1 BTC in USD, but even then it is a massive improvement in terms of trust and infrastructure requirement over the fully centralized solutions that are available now.

However, because UTXO are all-or-nothing, the only way to achieve this is through the very inefficient hack of having many UTXO of varying denominations (eg. one UTXO of 2k for every k up to 30) and having O pick which UTXO to send to A and which to B.

What does this mean? 'All or nothing' seems to mean the fact that the entirety of a UTXO should be spent. Yes it is true, but you can send some btc to A and the rest to B. Why 'the very inefficient hack of having many UTXO of varying denominations' is needed here? (FYI, I am not a developer. Thanks in advance.)

1 Answer 1


Again, no expert, but I believe that this means that while the scripts allow for some logic to determine whether a given transaction goes through, each UTXO input to the script can only go through, or fail. So either the whole block of UTXO is transferred, or none. There is no logic to sending some fraction of the total to an adres and doing something else with the rest.

The proposed fix is roughly as follows. Suppose for simplicity that at the start of the contract 1 BTC is 1$. Both parties put in 1,2,4,8 BTC into the contract, for a total value of 15$ each, or 30$ in total. The total UTXO available to the contract are now: 2x1 BTC, 2x2 BTC, 2x4 BTC and 2x8 BTC.

Suppose that after the 30 days the value of BTC is now 3$. This means that A should get 15/3= 5 BTC. 5 BTC = 1 + 4 BTC (there are different ways to make the UTXO that we have available sum up to 5, but just chose one). This means that now the contract can:

transfer 1 BTC to A, 1 BTC to B. transfer 2x2 BTC to B. transfer 4 BTC to A, 4 BTC to B. transfer 2x8 BTC to B.

While if the contract only had two big blocks of 15 BTC, the contract can only dynamically send each one of these blocks to A or B, but cannot split the blocks up further.

  • So it seems you need to program each of the 8 coins who will receive it depending on the BTC/USD price. Let's say they are a1, b1, a2, b2, a4, b4, a8, b8. If BTC price = 1 USD, a1 goes to A, b1 goes to B, a2 goes to A, b2 goes to B, etc. (Skipping 2, as it is not neatly divisible) If BTC price = 3 USD, a1 to A, b1to B, a2 to A, all the rest to B. Commented May 19, 2022 at 2:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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