From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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: In-Reply-To: From: Jeremy Rubin Date: Mon, 2 May 2022 08:59:49 -0700 Message-ID: To: Peter Todd Content-Type: multipart/alternative; boundary="00000000000007636f05de097cf2" Cc: Bitcoin Protocol Discussion , lightning-dev , Jeremy 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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 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'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).

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.
--00000000000007636f05de097cf2--