[bitcoin-dev] Smaller "Bitcoin address" accounts in the blockchain.

[bitcoin-dev] Smaller "Bitcoin address" accounts in the blockchain.

[Dave Scotese]

[-- Attachment #1: Type: text/plain, Size: 1287 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1427 bytes --]

Re: [bitcoin-dev] Smaller "Bitcoin address" accounts in the blockchain.

[ZmnSCPxj]

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