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
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
|
Return-Path: <fresheneesz@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 800E1C0033
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Feb 2022 22:00:02 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 671824010C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Feb 2022 22:00:02 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
HTML_MESSAGE=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 GipkQVqXQi2q
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Feb 2022 22:00:01 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
[IPv6:2a00:1450:4864:20::535])
by smtp2.osuosl.org (Postfix) with ESMTPS id 42B7F400B9
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Feb 2022 22:00:01 +0000 (UTC)
Received: by mail-ed1-x535.google.com with SMTP id bq11so366017edb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Feb 2022 14:00:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=blWWOr89XNf7Q4p7KMHgm9mJZZVfa+4uh0+sG5zs5K0=;
b=k7QIpEQI3UzWpxQ0ppVhSo6j8CMGMpypQNCuunViInHUNwr1KFjXGATlDNrw49oJVq
w7SRiu23djH9pVs2zcsmkij1bFCzPtjhwnXFshHJs7ZKm5fFtbqG7SerpN53wnHHDKwd
KCqLEJf6ZhyQXOTXlx8HIeW8U1tTn4WjbFPEI1qMa3k19AR51U1gchRZpskdZ4y8PlLH
U2sy8UMHXQgS6rAVn4X11jQEUZddavOnKHY1sH1JMqzk8wGXJ9bNoIfLeM4EzJku2HOy
r3XqJ+9l3IatlEqQWHQEoyTI+vCCjRJfiGeKvwU9ZX+gkuKgqkcyVV/EQqD2/EXbMvBV
+GbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=blWWOr89XNf7Q4p7KMHgm9mJZZVfa+4uh0+sG5zs5K0=;
b=C5tJ7wao1D9F9pItpZe4iPG8NH+aFP2zevAVTmqN/9uJzHcrCtBYBLlmX5iCTFM78/
jrXBQ3PySfDewwIQUOXMOCoU+P9FmKFrrrQT0Rw1oUjTh3Tr/ca7CtlwjnRyyz7g0bpH
vIJrWILKCdgkexVBYFvDm/5e6T8IGVILC7L54k9jnDCEPktKnJ9KqH5pfDKMr1V/A86V
aU6i8kmhu2GUpR77ad9j/HekjVjXlIfwUhcqptt5Ay7dJv6TWaTO28pgA7AdY4xx+1ad
RkTLu90w+j4lq8QOxUx28dEn1JfTUtL32FxSGrPZVcNFE4Ws6nlJr19q/1916qKPQ38H
7Dkw==
X-Gm-Message-State: AOAM532YxG3BwfwbGDBKO6u3dMJ0WuVgmNr641CcXzI7AQVhOfsJwnn9
9Q0HfjtzTZzkXCmSirtq5Luv31KKmV10yk8G024=
X-Google-Smtp-Source: ABdhPJzl8NklvjPkbfOKLl5Quj0G5vm0EL1Nr/MGQ/f82J+owmjY4Msjc24QOcQ25eKED3nn/5G+yd1gilKYW7hlvg0=
X-Received: by 2002:a50:8a89:0:b0:410:c862:40b2 with SMTP id
j9-20020a508a89000000b00410c86240b2mr14265452edj.81.1645307999192; Sat, 19
Feb 2022 13:59:59 -0800 (PST)
MIME-Version: 1.0
References: <6nZ-SkxvJLrOCOIdUtLOsdnl94DoX_NHY0uwZ7sw78t24FQ33QJlJU95W7Sk1ja5EFic5a3yql14MLmSAYFZvLGBS4lDUJfr8ut9hdB7GD4=@protonmail.com>
<CALZpt+Ee9kuVjpXYgOb_7dB7Yr8HYmicdRhfgXsQkey2szNDHg@mail.gmail.com>
<0mhhHzTun8dpIcLda1CLFihMsgLoWQUEE8woKUKhf_UHYps2w7jVzbJAUJ302kQEB1ZdvMfakP9IBUHLM8bGns-pg0NHmpuak3yjpphjJnw=@protonmail.com>
<CAD5xwhh9JHE0QAfRMeKs7w=L-GB5DaEomsQ0aH4ibSDi9Oe8Rg@mail.gmail.com>
<CAB3F3Dt6znirMfe4C6ASh6OvS_qR7XLx1fQ4O5ZCwbxhcNKsNg@mail.gmail.com>
<CAGpPWDYUJ66oA2gzjXYk2fvRaRMZeY4wCyS0KmimXtid03ahCw@mail.gmail.com>
<gcBcBwsL0ocO4fpTF1ZNkFTWGNhuPCHpbwjV5pzO4I2IR9WOfEEsQqL_i2IMqV2k8eDj9POJlQ0IX7eIzovjYq7gV6E6LTOjmAlINIIbxQM=@protonmail.com>
In-Reply-To: <gcBcBwsL0ocO4fpTF1ZNkFTWGNhuPCHpbwjV5pzO4I2IR9WOfEEsQqL_i2IMqV2k8eDj9POJlQ0IX7eIzovjYq7gV6E6LTOjmAlINIIbxQM=@protonmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Sat, 19 Feb 2022 15:59:41 -0600
Message-ID: <CAGpPWDY6X3X4ne0AatGaVx9tZSsi9V4hTAVfef-Hqe1kH0SXHA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000d68adb05d8661e87"
X-Mailman-Approved-At: Sat, 19 Feb 2022 23:06:00 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Greg Sanders <gsanders87@gmail.com>
Subject: Re: [bitcoin-dev] `OP_EVICT`: An Alternative to
`OP_TAPLEAFUPDATEVERIFY`
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: Sat, 19 Feb 2022 22:00:02 -0000
--000000000000d68adb05d8661e87
Content-Type: text/plain; charset="UTF-8"
Thanks for the clarification ZmnSCPxj!
On Sat, Feb 19, 2022 at 5:41 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
> Good morning Billy,
>
> > > "fully" punitive channels also make large value channels more
> dangerous from the perspective of bugs causing old states to be published
> >
> > Wouldn't it be ideal to have the penalty be to pay for a single extra
> transaction fee? That way there is a penalty so cheating attempts aren't
> free (for someone who wants to close a channel anyway) and yet a single fee
> isn't going to be much of a concern in the accidental publishing case. It
> still perplexes me why eltoo chose no penalty at all vs a small penalty
> like that.
>
> Nothing in the Decker-Russell-Osunstokun paper *prevents* that --- you
> could continue to retain per-participant versions of update+state
> transactions (congruent to the per-participant commitment transactions of
> Poon-Dryja) and have each participant hold a version that deducts the fee
> from their main owned funds.
> The Decker-Russell-Osuntokun paper simply focuses on the mechanism by
> itself without regard to fees, on the understanding that the reader already
> knows fees exist and need to be paid.
>
> Regards,
> ZmnSCPxj
>
--000000000000d68adb05d8661e87
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thanks for the clarification ZmnSCPxj!=C2=A0</div><br><div=
class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Feb 19=
, 2022 at 5:41 AM ZmnSCPxj <<a href=3D"mailto:ZmnSCPxj@protonmail.com">Z=
mnSCPxj@protonmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">Good morning Billy,<br>
<br>
> >=C2=A0"fully" punitive channels also make large value ch=
annels more dangerous from the perspective of bugs causing old=C2=A0states =
to be published<br>
><br>
> Wouldn't it be ideal to have the penalty be to pay for a single ex=
tra transaction fee? That way there is a penalty so cheating attempts aren&=
#39;t free (for someone who wants to close a channel anyway) and yet a sing=
le fee isn't going to be much of a concern in the accidental publishing=
case. It still perplexes me why eltoo chose no penalty at all vs a small p=
enalty like that.<br>
<br>
Nothing in the Decker-Russell-Osunstokun paper *prevents* that --- you coul=
d continue to retain per-participant versions of update+state transactions =
(congruent to the per-participant commitment transactions of Poon-Dryja) an=
d have each participant hold a version that deducts the fee from their main=
owned funds.<br>
The Decker-Russell-Osuntokun paper simply focuses on the mechanism by itsel=
f without regard to fees, on the understanding that the reader already know=
s fees exist and need to be paid.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>
--000000000000d68adb05d8661e87--
|
