Date: Fri, 04 Oct 2019 06:45:35 +0000
To: Dave Scotese <dscotese@litmocracy.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <BoxdwCcItqGY7JSaG245SNsgO6ijaeruqzdSUvSomOJLMHM33L8lRXPKE4e38g3DewzUEwbGNu7o2V5l9z2A48HrRpubm0U4zgpUecaXW60=@protonmail.com>
In-Reply-To: <CAGLBAheDMFkFtJG1gLf61ZZ9U3rasZ_T6f_sAHWWRiAcNWiO8A@mail.gmail.com>
References: <CAGLBAheDMFkFtJG1gLf61ZZ9U3rasZ_T6f_sAHWWRiAcNWiO8A@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Smaller "Bitcoin address" accounts in the
	blockchain.
Precedence: list

Good morning David,

> Currently, bitcoin must be redeemed by providing input to a script which =
results in the required output.=C2=A0 This causes the attached amount of bi=
tcoin to become available for use in the outputs of a transaction.=C2=A0 Is=
 there any work on creating a shorter "transaction" which, instead of creat=
ing a new output, points to (creates a virtual copy of) an existing (unspen=
t) output with a larger amount attached to it?=C2=A0 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 sc=
ript to be duplicated.=C2=A0 It is a method for aggregating bitcoin to a UT=
XO 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 f=
or spending X2, this would be a transaction that does that using fewer data=
 bytes.=C2=A0 Since the script already exists, the transaction can simply p=
oint 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.=
=C2=A0 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 transacti=
on as valid when putting it into the mempool, and as long as the UTXO it co=
nsumes 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" sub=
sequently is definitely no longer spendable, whereas with accounts, every f=
ullnode 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 so=
me existing `scriptPubKey`" and why such a thing will be very unlikely to c=
ome 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 simult=
aneously to the payment.
This does what you want:

* Refers to a previous UTXO owned by the payee, and deletes it (by normal t=
ransaction 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 P=
2EP/Payjoin preserves privacy.


Regards,
ZmnSCPXj