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
131
132
133
134
135
136
137
138
139
|
Return-Path: <john.tromp@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id EA04EC000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 Aug 2021 21:03:28 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id E65D040003
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 Aug 2021 21:03:28 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.601
X-Spam-Level:
X-Spam-Status: No, score=0.601 tagged_above=-999 required=5
tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 6BwhpQZSX-sO
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 Aug 2021 21:03:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com
[IPv6:2a00:1450:4864:20::42b])
by smtp2.osuosl.org (Postfix) with ESMTPS id B084540012
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 Aug 2021 21:03:24 +0000 (UTC)
Received: by mail-wr1-x42b.google.com with SMTP id k29so15332419wrd.7
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 Aug 2021 14:03:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to
:content-transfer-encoding;
bh=YKAjo8ibooNksGD6Abi2HIFrREn7dOI5vwpbLNPdr8w=;
b=pbrBODyrMJP+4r8Ici3kXPxeZS/+mtqjyQAoQZ+vW/HUuua8mfDna/Lf5F6UjAY/Om
aCkYu8pyzNhf5DETAu1BMKtkcgokPZVoZoB12o+A5w+r/O4VtgJ6MZ67bHmmQfkQseY5
y6iamaGEIZnfd2ueTW30vvNVaP+iOMZOh+Je6mrMHGe0orxpL2OcyzQ6JfAInET1MrZL
igoXbEI7rE905P6kPSVbRrFhxrLTJleMi0xDtOgMnnWStuT0Uf+yx6ReHP1h6sS3S8X1
t77dBh4wS12sitQ9nq/YPNc/3qp+0sPi4nEERL6GY54hy2sFJSAfImxkp5wuH/lIJxg1
3GNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to
:content-transfer-encoding;
bh=YKAjo8ibooNksGD6Abi2HIFrREn7dOI5vwpbLNPdr8w=;
b=o7faTJsoiMuFKdevmixiLa0OrfIkmeFrGDymIgL66abHWi9jDuXkToqppWYfeC50nW
ZwFpGrQnjjT1ZYA2cyMts0kVo04dpWPr7EhUgs12wrYEBZRT4gu4JaMx+JlyIB5GDaw0
fAJE1gx36qn2MHRUzFD1ScYXNVzQ60Q/b+h5p/GB95OcLPhXm0Ehw+6/SDVYqvzUIDZj
+QMtocCmgzgJyZT43RttmRPe0p9kHj/5dck2uEs7AMgpkjSM5kiZYKtPBt0S4585uPnU
BWsvukc/dbcfqG9Gn7Fd8hx5knYFSOB0Rp8qm9Z6DjEKwBcQwat9Amzq0/XWkbKZuS6H
/DUQ==
X-Gm-Message-State: AOAM531g6c0GXBr8nGVfKQVfdUKgCpRJD44muyfJvdWlJwSk7jbxlMnE
Y3iCztAUL9zh/NS8SJCsOGM5Wkn/bVwkLRg6XTrwa+6paw==
X-Google-Smtp-Source: ABdhPJxfq5MxWYyQD2gl55armdHCruAzbdiFW+3ExgxPLvEp5bzT2xZEK4B8VgCjuKwqsJfuBaKE0DcrgQtbxQK5X+s=
X-Received: by 2002:adf:dcc1:: with SMTP id x1mr16102598wrm.401.1628629402857;
Tue, 10 Aug 2021 14:03:22 -0700 (PDT)
MIME-Version: 1.0
From: John Tromp <john.tromp@gmail.com>
Date: Tue, 10 Aug 2021 23:03:11 +0200
Message-ID: <CAOU__fx0ajVfuEyoYCOkf8nZPOkbuYDctTfuzhCDdoU=jcA0Tg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Wed, 11 Aug 2021 20:26:36 +0000
Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
Message-ID:
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Tue, 10 Aug 2021 21:03:29 -0000
> Alternately, one possible softforkable design would be for Bitcoin to mai=
ntain a non-CT block (the current scheme) and a separately-committed CT blo=
ck (i.e. similar to how SegWit has a "separate" "block"/Merkle tree that in=
cludes witnesses).
> When transferring funds from the legacy non-CT block, on the legacy block=
you put it into a "burn" transaction that magically causes the same amount=
to be created (with a trivial/publicly known salt) in the CT block.
> Then to move from the CT block back to legacy non-CT you would match one =
of those "burn" TXOs and spend it, with a proof that the amount you are rem=
oving from the CT block is exactly the same value as the "burn" TXO you are=
now spending.
> (for additional privacy, the values of the "burn" TXOs might be made into=
some fixed single allowed value, so that transfers passing through the CT =
portion would have fewer identifying features)
>
> The "burn" TXOs would be some trivial anyone-can-spend, such as `<saltpoi=
nt> <0> OP_EQUAL OP_NOT` with `<saltpoint>` being what is used in the CT to=
cover the value, and knowledge of the scalar behind this point would allow=
the CT output to be spent (assuming something very much like MimbleWimble =
is used; otherwise it could be the hash of some P2WSH or similar analogue o=
n the CT side).
>
> Basically, this is "CT as a 'sidechainlike' that every fullnode runs".
>
> In the legacy non-CT block, the total amount of funds that are in all CT =
outputs is known (it would be the sum total of all the "burn" TXOs) and wil=
l have a known upper limit, that cannot be higher than the supply limit of =
the legacy non-CT block, i.e. 21 million BTC.
> At the same time, *individual* CT-block TXOs cannot have their values kno=
wn; what is learnable is only how many BTC are in all CT block TXOs, which =
should be sufficient privacy if there are a large enough number of users of=
the CT block.
>
> This allows the CT block to use an unconditional privacy and computationa=
l soundness scheme, and if somehow the computational soundness is broken th=
en the first one to break it would be able to steal all the CT coins, but n=
ot *all* Bitcoin coins, as there would not be enough "burn" TXOs on the leg=
acy non-CT blockchain.
>
> This may be sufficient for practical privacy.
This is pretty much the Mimble Wimble Extension Block (MWEB) design
for Litecoin, as described at
https://vaultoro.com/what-is-mweb-on-litecoin/
True to the Harry Potter background theme of Mimblewimble, the regular
Litecoin transaction responsible for pegging into and out of the
extension block is call the Hogwarts Express (hogex).
If all goes well, it may activate as early as the end of this year...
regards,
-John
|
