From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A0D4AFF6 for ; Fri, 4 Oct 2019 06:45:45 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AD2AAA8 for ; Fri, 4 Oct 2019 06:45:44 +0000 (UTC) Date: Fri, 04 Oct 2019 06:45:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1570171542; bh=zOWAc9b5w/IcMYpsx5kdXQo58W4aRozZpEaHiTuyHKM=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: From; b=Z3gCFIYf+QceY2ZeTiBEu9MXZMwRmeWqgh6afnOoGLnklO4QEwDbhuExtRpwLqMPF KbQVUIMa5X+Zsw9tYyRElFQBiMWfpzItqZ719ZpmtkVe67DgYll0wLhKu2wtP3rZqE OK6KPFIVyTJ8aPtguDMUUS9R7+CdXJIxHBgzFrhE= To: Dave Scotese , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DOS_RCVD_IP_TWICE_B, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Smaller "Bitcoin address" accounts in the blockchain. X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2019 06:45:45 -0000 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