2

Is there a way to divide an unknown future input amount received by a given address amongst three recipients with proportions of, for example 0.2 , 0.3, 0.5?

This would need to be done in such a way that one could send an amount and be sure that it will be divided in this way.

It would not matter if the transaction was "blank cheque"/repeatable as described here.

Lee
  • 392
  • 1
  • 14

2 Answers2

2

No. You can't impose restrictions on where a current UTXO moves (without covenant functionality that isn't enabled on Bitcoin today) let alone impose restrictions on where a future UTXO moves.

Michael Folkson
  • 14,337
  • 3
  • 11
  • 45
  • Thanks, slightly updated q (input rather than output). Another way of asking - is tx input amount able to be referred to by the script? – Lee Sep 05 '22 at 12:05
  • .. and perhaps that would only work if `OP_DIV` or `OP_MUL` enabled – Lee Sep 05 '22 at 12:08
  • Apologies, updated again, removed UTXO ref, I now get that UTXOs are referenced by hash and so you can't "send to an input".. answer still no I think. – Lee Sep 05 '22 at 12:25
  • 1
    No there's no opcode that refers to the amount in the UTXO. You could create a transaction spending to the three recipients with the three stated proportions, not broadcast it and then delete the private keys so no other transaction can be constructed that spends that UTXO. At the moment that's the only way of doing something like this. – Michael Folkson Sep 05 '22 at 12:35
  • I see, you broadcast the tx after deleting keys else would burn the coins? – Lee Sep 05 '22 at 12:37
  • 1
    Only if you lost the transaction that you were meant to broadcast at some later point. As long as you store it safely you can broadcast it later at the time of your choosing. – Michael Folkson Sep 05 '22 at 12:40
2

As Michael already explained, it is not possible to make a transaction that spends unknown UTXOs since a transaction must state which outputs it consumes. Such a functionality could be partially enabled by e.g. sighash_anyprevout (BIP118) which identifies the spent input by the scriptPubKey rather than identifying a specific UTXO, but even then you'd need to know the expected value of the UTXO in advance, as the output amounts are predetermined.

A practical solution might be to run an automated process which regularly checks if there is a balance on the online service's wallet and then creates a transaction which splits the funds in the pre-defined proportions to the receivers. The receivers would then trust this service for the duration until the wallet is swept not to steal or compromise the funds.

Murch
  • 71,155
  • 33
  • 180
  • 600