1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A0D4AFF6
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <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
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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
|
