summaryrefslogtreecommitdiff
path: root/f9/36afff0e2f5a539c14c3950afd6938709fd29e
blob: 744853fea696e60d3d8457814206cfbea81ce195 (plain)
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
Return-Path: <jeremy.l.rubin@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 3F575C002D;
 Mon,  2 May 2022 16:00:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 1D19060F24;
 Mon,  2 May 2022 16:00:04 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.698
X-Spam-Level: 
X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5
 tests=[BAYES_05=-0.5, 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: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Za7mm9sg9-Ca; Mon,  2 May 2022 16:00:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com
 [IPv6:2a00:1450:4864:20::22e])
 by smtp3.osuosl.org (Postfix) with ESMTPS id C351560F0E;
 Mon,  2 May 2022 16:00:02 +0000 (UTC)
Received: by mail-lj1-x22e.google.com with SMTP id c15so18899391ljr.9;
 Mon, 02 May 2022 09:00:02 -0700 (PDT)
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=YR4m42py8GXhJ9/aDdb7c6c5d8in8AZIZmCpidBXwPs=;
 b=FZh01h1ptHMx/hNFv9y3zO2LUhwbmNjXS68ub15a+HrGG/Fd/4fRlNEd5vyVQXsqRT
 Z/r9PgPFMJRUasMn1lbwlHYJqrvvqg5KPV0u+NkJHLgOLLE4xj8DEakLzD5M9SxCVKqy
 sW+c00UZi5kYGjNIXbgW6F45QY8RQihC6uBM+8fYl3wGy4xMh2kNkq+Ht7epFtvHGNaA
 4DOedObTsc7pziIc6B7FuvvxLmHDjGRtPsOWnJO6jG7k2sP5MtNRXO51Wiklv8AaCcDs
 M4qiml99784XOqEWFnl6ltPeCU1fN8vSRIdgKa+JpuhMOiARARSe2lulCBQYFNVMsLd7
 B1yw==
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=YR4m42py8GXhJ9/aDdb7c6c5d8in8AZIZmCpidBXwPs=;
 b=XGBOyZV6TjQjnSGviY0LeUozdTUY+To7Gl/ZeQ3cuqljXs+wa0EvzK+x0DnnjIGZmU
 eEpOsIs3ORQNhdJdsrOBwH8mlycrzgawHJj8MFOU0W6vW+8PSxqV8hObvA8q/viPOnrN
 yniVbUEQk2ovROgh71JIMDn13HzIX5eWBJDpeSKSic6cZ3ci/lwjrKRgyg0GHOigKtZ1
 5GbUHKzP+JUAqIyPDWklkxLKRtb9PdS5UpfV5K7NZBhvhiI0zDnV4pTkv8tRyKeC6I0i
 JT8NtzsEi6E2b8GZ7dQdi3/B5DXtfWSzCHh+/LhKPSwQWPclYx9j1fSxQ4niul6R5nU2
 3+2g==
X-Gm-Message-State: AOAM533hofu602BrySkK9lixv3dpyDRn3kuQns+z2Sp3bDRqtk5jsae2
 63uOegnrHkf2E113FQfSewRvuuawMPJhDKJ+hcU=
X-Google-Smtp-Source: ABdhPJxVi8R65nbi3hBPqmhvfeSilZd/77YK3YmbdyRlKqE1Llr9d8hebgf9UjbuWTqkzVEwrq57ryQLCdfciAqHFwg=
X-Received: by 2002:a05:651c:1258:b0:24f:1050:fd2 with SMTP id
 h24-20020a05651c125800b0024f10500fd2mr8177493ljh.295.1651507200483; Mon, 02
 May 2022 09:00:00 -0700 (PDT)
MIME-Version: 1.0
References: <YgS3sJvg6kG3WnVJ@petertodd.org>
 <CAD5xwhi3Ja8gdU2h_6-1ck4kdU0TiC2Kx5O-61=f9=6JQSMs=A@mail.gmail.com>
 <YhAwr7+9mGJAe2/p@petertodd.org>
 <CAD5xwhi=sKckFZew75tZTogoeFABraWtJ6qMC+RgZjcirxYyZw@mail.gmail.com>
 <YhC6yjoe3bAfBS+W@petertodd.org>
 <CAD5xwhjR06Lp3ka-MqZQE64tfE5uDQB6TrMh06khjYrDzuT95g@mail.gmail.com>
 <YlMw5NxXnGV9WrVg@petertodd.org>
 <CAD5xwhj1kaJf+QCcf1MOtaAec-xTTr2M9LkJPCu2Ej0L9_3iPg@mail.gmail.com>
 <YlmGv6WbDeDqGJKX@petertodd.org>
 <CAD5xwhgGgq30C7GniNh1_DobPe+P4NTJySUkDiBZBj=OjzO5KA@mail.gmail.com>
 <YmqFRlDIkfbyVIZ2@petertodd.org>
In-Reply-To: <YmqFRlDIkfbyVIZ2@petertodd.org>
From: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Date: Mon, 2 May 2022 08:59:49 -0700
Message-ID: <CAD5xwhhB+8n+9pWiSCtx3DAPnSwV_7xHnXZ14mEj9H93eWUNEw@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="00000000000007636f05de097cf2"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 lightning-dev <lightning-dev@lists.linuxfoundation.org>,
 Jeremy <jlrubin@mit.edu>
Subject: Re: [bitcoin-dev] [Pre-BIP] Fee Accounts
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: Mon, 02 May 2022 16:00:04 -0000

--00000000000007636f05de097cf2
Content-Type: text/plain; charset="UTF-8"

Ok, got it. Won't waste anyone's time on terminology pedantism.


The model that I proposed above is simply what *any* correct timestamping
service must do. If OTS does not follow that model, then I suspect whatever
OTS is, is provably incorrect or, in this context, unreliable, even when
servers and clients are honest. Unreliable might mean different things to
different people, I'm happy to detail the types of unreliability issue that
arise if you do not conform to the model I presented above (of which,
linearizability is one way to address it, there are others that still
implement epoch based recommitting that could be conceptually sound without
requiring linearizability).

Do you have any formal proof of what guarantees OTS provides against which
threat model? This is likely difficult to produce without a formal model of
what OTS is, but perhaps you can give your best shot at producing one and
we can carry the conversation on productively from there.

--00000000000007636f05de097cf2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Ok, got it. Won&#39;t =
waste anyone&#39;s time on terminology pedantism.</div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family=
:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)">The model that I proposed above is simply =
what *any* correct timestamping service must do. If OTS does not follow tha=
t model, then I suspect whatever OTS is, is=C2=A0provably incorrect or, in =
this context, unreliable, even when servers and clients are honest. Unrelia=
ble might mean different things to different people, I&#39;m happy to detai=
l the types of unreliability issue that arise if you do not conform to the =
model I presented above (of which, linearizability is one way to address it=
, there are others that still implement epoch based recommitting that could=
 be conceptually sound without requiring linearizability).</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Do =
you have any formal proof of what guarantees OTS=C2=A0provides against whic=
h threat model? This is likely difficult to produce without a formal model =
of what OTS is, but perhaps you can give your best shot at producing one an=
d we can carry the conversation on productively from there.</div></div>

--00000000000007636f05de097cf2--