public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
To: Dave Scotese <dscotese@litmocracy.com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Smaller "Bitcoin address" accounts in the blockchain.
Date: Fri, 04 Oct 2019 06:45:35 +0000	[thread overview]
Message-ID: <BoxdwCcItqGY7JSaG245SNsgO6ijaeruqzdSUvSomOJLMHM33L8lRXPKE4e38g3DewzUEwbGNu7o2V5l9z2A48HrRpubm0U4zgpUecaXW60=@protonmail.com> (raw)
In-Reply-To: <CAGLBAheDMFkFtJG1gLf61ZZ9U3rasZ_T6f_sAHWWRiAcNWiO8A@mail.gmail.com>

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


      reply	other threads:[~2019-10-04  6:45 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-04  1:37 [bitcoin-dev] Smaller "Bitcoin address" accounts in the blockchain Dave Scotese
2019-10-04  6:45 ` ZmnSCPxj [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='BoxdwCcItqGY7JSaG245SNsgO6ijaeruqzdSUvSomOJLMHM33L8lRXPKE4e38g3DewzUEwbGNu7o2V5l9z2A48HrRpubm0U4zgpUecaXW60=@protonmail.com' \
    --to=zmnscpxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=dscotese@litmocracy.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox