Good morning David, > Currently, bitcoin must be redeemed by providing input to a script which > results in the required output. This causes the attached amount of bitcoin > to become available for use in the outputs of a transaction. Is there any > work on creating a shorter "transaction" which, instead of creating a new > output, points to (creates a virtual copy of) an existing (unspent) output > with a larger amount attached to it? This would invalidate the smaller, > earlier UTXO and replace it with the new one without requiring the earlier > one to be redeemed, and also without requiring the original script to be > duplicated. It is a method for aggregating bitcoin to a UTXO which may > otherwise not be economically viable. > > The idea is that there already exists a script that must be satisfied to > spend X1, and if the owner of X1 would like to have the same requirements for > spending X2, this would be a transaction that does that using fewer data > bytes. Since the script already exists, the transaction can simply point to > it instead of duplicating it. > > This would also enable the capacity of lightning channels to be increased on > the fly without closing the existing channel and re-opening a new one. The > LN layer would have to cope with the possibility that the "short channel ID" > could change. > > Dave.
This moves us closer to an "account"-style rather than "UTXO"-style. The advantage of UTXO-style is that it becomes easy to validate a transaction as valid when putting it into the mempool, and as long as the UTXO it consumes remains valid, revalidation of the transaction when it is seen in a block is unnecessary. Admittedly, the issue with account-style is when the account is overdrawn --- with UTXOs every spend drains the entire "account" and the "account" subsequently is definitely no longer spendable, whereas with accounts, every fullnode has to consider what would happen if two or more transactions spend from the account. In your case, it seems to just *add* to the amount of a UTXO. In any case, this might not be easy to implement in current Bitcoin. The UTXO-style is deeply ingrained to Bitcoin design, and cannot be easily hacked in a softfork. See also https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017135.html and its thread for the difficulties involved with "just copy some existing `scriptPubKey`" and why such a thing will be very unlikely to come in Bitcoin. But I think this can be done, in spirit, by pay-to-endpoint / payjoin. In P2EP/Payjoin, the payer contacts the payee and offers to coinjoin simultaneously to the payment. This does what you want: * Refers to a previous UTXO owned by the payee, and deletes it (by normal transaction spending rules). * Creates a new UTO, owned by the payee, which contains the total value of the below: * The above old UTXO. * The value to be transferred from payer to payee. The only issues are that: * Payee has to be online and cooperate. * Payee has to provide signatures for the old UTXO, adding more blockchain data. * New UTXO has to publish a SCRIPT too. * In terms of *privacy*, of course you *have* to use a new SCRIPT with a new public key anyway. Thus this is superior to your proposal where the pubkey is reused, as P2EP/Payjoin preserves privacy. Regards, ZmnSCPXj _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
