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
|
Return-Path: <j.delbonis.3@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C3AEDE331
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 Feb 2019 17:27:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com
[209.85.160.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4624A7DB
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 Feb 2019 17:27:45 +0000 (UTC)
Received: by mail-qt1-f176.google.com with SMTP id p48so3906555qtk.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 Feb 2019 09:27:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=TH2IohkpYpkTuQi+9KLVT7+bsXAyIF+02AK1yRAHvO0=;
b=YJmCLtoG4dfaP6kDIqjSkV3V5+SoUCTVbWBBunvmYCOclLncTMB6JMsa6q59qzIIG9
AA4FfkKX1ES9BcWfDvqc8/xWWisSC6GvLh6mYCGqMyOAown8LlQU+srGF8oSSaQOd3/b
SyykbOgBUVHYWAM6OcEV3Y2ttoDsYRsqZbhIB0Ugf3tzp/640FnW4A/pywxMTXIlmpK3
AfwbniuYzc6Z3bUkvgCclCJC+E/PHrV1rwyeE9ZccReSOywTX0spkGbwgiOfwYIaIdIj
i3pz7a6llxDMzZbb+RbtcTbgMgCRdQDAVZ6w5UcgrGC+VZ6/g1tu5j7HGr/gzPtcVPrB
oCcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=TH2IohkpYpkTuQi+9KLVT7+bsXAyIF+02AK1yRAHvO0=;
b=pjkoq6sk7gSQ5EBNNGGYHRbX+/zT9auK4GU2tIaM6AM74ctyhHp3D35D4E1veQhQZJ
+vNIYEncIOacmwCAyW0Dv+CjxXpJxgFzJDoW8Jqt+jrwE2aeMY7eX7Bp3V62BznNo4Mi
+X7n2KGtl6hNQpViR0aNdYqycnU/hCa3YviiVU6A+/DXd51wsTA7KnLdcbi7AkwFwNpZ
YCCwcS7EYLOb5eoqHi6WilzDpKPaQ6HcIt0ii5MzfI2Diz2jvD51A/AeSaq08ifHODtc
OAKv/9Kyrnt8flxAYrp2kZQqre1ZO/6zuIfVteI7qAnh5NZT7a3NmriWdKqrub63gPis
+5CQ==
X-Gm-Message-State: AHQUAuYQldiQVXoyI9Z6BHNUSiy8N6ytz7PealUDXvRG50KJLoPgQ0kM
acVOgGPGZFbTpV84b4Peyygms7m27Am+YMkLzVk=
X-Google-Smtp-Source: AHgI3IZ1Ell2+o5EsQ5tiS4D8rlaABprrCalQRXF+K2M40MUzETPwidAUbFOf5xWSbz5sJr5PslTjczKC0A2rLKcsGw=
X-Received: by 2002:a0c:9953:: with SMTP id i19mr3575827qvd.114.1549992464392;
Tue, 12 Feb 2019 09:27:44 -0800 (PST)
MIME-Version: 1.0
References: <DB6PR10MB183228F27750132F9A6A3542A6690@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
<U-ugv1xWdp4czsN38WhD6KQUPcYa4VLxNzUusM3YLRu4825eigldn3xTOw6IyoqpyFbymdKxWUGOQdlknr3L7rBOtssEKeYMkW4RKj5Rc1o=@protonmail.com>
In-Reply-To: <U-ugv1xWdp4czsN38WhD6KQUPcYa4VLxNzUusM3YLRu4825eigldn3xTOw6IyoqpyFbymdKxWUGOQdlknr3L7rBOtssEKeYMkW4RKj5Rc1o=@protonmail.com>
From: Trey Del Bonis <j.delbonis.3@gmail.com>
Date: Tue, 12 Feb 2019 12:27:32 -0500
Message-ID: <CAFUsdzpALfj_htx1iGw0UtdLtWwMCW8UXSaRrd5q8ezGXbm2Yg@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 12 Feb 2019 17:42:40 +0000
Subject: Re: [bitcoin-dev] Implementing Confidential Transactions in
extension blocks
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: Tue, 12 Feb 2019 17:27:45 -0000
>Under this point-of-view, then, extension block is "not" soft fork.
>It is "evil" soft fork since older nodes are forced to upgrade as their intended functionality becomes impossible.
>In this point-of-view, it is no better than a hard fork, which at least is very noisy about how older fullnode versions will simply stop working
Offtopic: I believe that this kind of "evil soft fork" where nodes who
don't upgrade can continue to read the blockchain, update their
utxoset, etc. but can't actually spend some or all of the coins they
have has been referred to as a "firm fork". I think this is a pretty
useful term to pass around when talking about potential future forks.
The earliest reference I can find to that term from a quick search is
this talk from 2016 by Adam Back:
http://diyhpl.us/wiki/transcripts/adam3us-bitcoin-scaling-tradeoffs/
-Trey Del Bonis
On Tue, Feb 12, 2019 at 7:48 AM ZmnSCPxj via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Good morning Kenshiro,
>
> > - Soft fork: old nodes see CT transactions as "sendtoany" transactions
>
> There is a position that fullnodes must be able to get a view of the UTXO set, and extension blocks (which are invisible to pre-extension-block fullnodes) means that fullnodes no longer have an accurate view of the UTXO set.
> SegWit still provides pre-SegWit fullnodes with a view of the UTXO set, although pre-SegWit fullnodes could be convinced that a particular UTXO is anyone-can-spend even though they are no longer anyone-can-spend.
>
> Under this point-of-view, then, extension block is "not" soft fork.
> It is "evil" soft fork since older nodes are forced to upgrade as their intended functionality becomes impossible.
> In this point-of-view, it is no better than a hard fork, which at least is very noisy about how older fullnode versions will simply stop working.
>
> > - Safe: if there is a software bug in CT it's impossible to create new coins because the coins move from normal block to normal block as public transactions
>
> I think more relevant here is the issue of a future quantum computing breach of the algorithms used to implement confidentiality.
>
> I believe this is also achievable with a non-extension-block approach by implementing a globally-verified publicly-visible counter of the total amount in all confidential transaction outputs.
> Then it becomes impossible to move from confidential to public transactions with a value more than this counter, thus preventing inflation even if a future QC breach allows confidential transaction value commitments to be opened to any value.
>
> (do note that a non-extension-block approach is a definite hardfork)
>
> > - Capacity increase: the CT signature is stored in the extension block, so CT transactions increase the maximum number of transactions per block
>
> This is not an unalloyed positive: block size increase, even via extension block, translates to greater network capacity usage globally on all fullnodes.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
