path: root/8f/15ef3e58dacae74f20634d94ba23dc0729b640

Return-Path: <user@petertodd.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 18994C002D;
 Thu, 28 Apr 2022 12:15:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 0E3F840101;
 Thu, 28 Apr 2022 12:15:08 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level: 
X-Spam-Status: No, score=-2.8 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, RCVD_IN_DNSWL_LOW=-0.7,
 RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
 SPF_HELO_PASS=-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=petertodd.org header.b="iDwsZYUl";
 dkim=pass (2048-bit key) header.d=messagingengine.com
 header.b="tZEKEsxF"
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 yWdCXn73oFXh; Thu, 28 Apr 2022 12:15:06 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com
 [66.111.4.25])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 8639F40012;
 Thu, 28 Apr 2022 12:15:06 +0000 (UTC)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44])
 by mailout.nyi.internal (Postfix) with ESMTP id 413C75C0144;
 Thu, 28 Apr 2022 08:15:05 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute4.internal (MEProxy); Thu, 28 Apr 2022 08:15:05 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=petertodd.org;
 h=cc:cc:content-type:date:date:from:from:in-reply-to
 :in-reply-to:message-id:mime-version:references:reply-to:sender
 :subject:subject:to:to; s=fm2; t=1651148105; x=1651234505; bh=Pd
 AZf6u30HPmrLWY207i9ytJHePJXkNkLzgzuW8pTM0=; b=iDwsZYUl8Jt1T7rCtF
 o6JqqGwhFoUH+sj9cN9eyhWXbGo0r18w2p/KD4PzcrO1fziuh9fr8nm2cDQ2Gzkw
 8SNEE2HfRu5NAj1Xv3+oZoCCzzgyzAcG8m3pnLi6DQpnqqZfDl3NdjzfAsusaj6A
 1ZvMr0dU0UR0IwPzHRzj11/pXqsHoK5h+kOe3SRf8Bd0GdqwlpzBxfv6H/rZFiYm
 csqgYxcPIgxHDT/I2VEMKoi/LEhKQqXJIcIhQ4TjOjwMsP3wuF+ZZi81L4OpDzb1
 I8R8sk2A6hRsen+KOMknZjUX16u1pBdO2Q+V053QseTdos7OFw6P/mArcuHKXf9s
 UPYA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-type:date:date:from:from
 :in-reply-to:in-reply-to:message-id:mime-version:references
 :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy
 :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1651148105; x=
 1651234505; bh=PdAZf6u30HPmrLWY207i9ytJHePJXkNkLzgzuW8pTM0=; b=t
 ZEKEsxF/GdfVJ72h0X4JqNzd1K1eL36DU8hWNJmttXrKF7PZxzL9qNTTYiVsizd7
 j7nUCBIJeA0Zeenry6oI1qpg03U3iNsMVAtQ5RH1zpER2KacNQCloR02Cixj9At1
 tIvQCdFO+pmaHWBpslsU1ZdYBgU5wogkq9K0ttGhnBalL/y8g4JC0pKqmQtVDWel
 pJcnRYrzpWVNnuGSNBf5a1tOfpXX6VSd8bEir3ypgLqpwNvLwoSMnHUxlM0R/a+T
 tnqQ+g+SC3ImO8cJCnU662L6Dj6TsvjkdE7KRbFvsZEwtbkpNB+Fk20HM01Fmjax
 mpza7KPePSSm5drMNjOog==
X-ME-Sender: <xms:SYVqYuAO-EPcHyTHt0qSxjmjsp8r1UomLkK1PpoMxVgel0m5FQtG3w>
 <xme:SYVqYoixcQy_FB87xkghbShUzy0pCbESCRmJXhE-19RAbD-iFzWjlIKZoqtLKMfXo
 FFD-pq125PEhXl8zIg>
X-ME-Received: <xmr:SYVqYhkfqQKRLwmUp0rlG48UQYcpDqa8jyAWrenkWwZ9ikfg7MXDC7zG-oFM>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudejgdehtdcutefuodetggdotefrodftvf
 curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
 uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
 fjughrpeffhffvvefukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpefrvghtvghr
 ucfvohguugcuoehpvghtvgesphgvthgvrhhtohguugdrohhrgheqnecuggftrfgrthhtvg
 hrnhepledvleelffdtudekudffjefgfeejueehieelfedtgfetudetgeegveeutefhjedt
 necuffhomhgrihhnpehpvghtvghrthhouggurdhorhhgnecuvehluhhsthgvrhfuihiivg
 eptdenucfrrghrrghmpehmrghilhhfrhhomhepuhhsvghrsehpvghtvghrthhouggurdho
 rhhg
X-ME-Proxy: <xmx:SYVqYswf4rGRa-_8U9novs22OzSYn339x1X-Gs-02H4Dd46rsjemnA>
 <xmx:SYVqYjSWLFrDPj-OKxOkeFjokyaesVu_2-Gu4S-lSP0VPnvPqIBVpQ>
 <xmx:SYVqYnZIxYRWnwxVsIQEz8emcxVDDWKzeANvwgP_2Y9xD6oWVA8BeQ>
 <xmx:SYVqYue1WA8_4Pn13O_xxmGSXFSqA0KiYbi_RxgglWu_XH0zjoCcMg>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 28 Apr 2022 08:15:04 -0400 (EDT)
Received: by localhost (Postfix, from userid 1000)
 id 918CD5FAFB; Thu, 28 Apr 2022 08:15:02 -0400 (EDT)
Date: Thu, 28 Apr 2022 08:15:02 -0400
From: Peter Todd <pete@petertodd.org>
To: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Message-ID: <YmqFRlDIkfbyVIZ2@petertodd.org>
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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="6beR0q5z9Iv1KmW/"
Content-Disposition: inline
In-Reply-To: <CAD5xwhgGgq30C7GniNh1_DobPe+P4NTJySUkDiBZBj=OjzO5KA@mail.gmail.com>
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: Thu, 28 Apr 2022 12:15:08 -0000


--6beR0q5z9Iv1KmW/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Apr 17, 2022 at 01:57:28PM -0700, Jeremy Rubin wrote:
> the 'lots of people' stuff (get confused, can't figure out what i'm
> quoting, actually are reading this conversation) is an appeal to an
> authority that doesn't exist. If something is unclear to you, let me know.
> If it's unclear to a supposed existential person or set of persons, they
> can let me know.

It's pretty simple: bitcoin-dev is read by hundreds of people. This has not=
hing
to do with authority. It's about not wasting the time of those people.

> concretely, I am confused by how OTS can both support RBF for updating to
> larger commitments (the reason you're arguing with me) and not have an
> epoch based re-comittings scheme and still be correct. My assumption now,
> short of a coherent spec that's not just 'read the code', is that OTS
> probably is not formally correct and has some holes in what is
> committed to, or relies on clients re-requesting proofs if they fail to be
> committed. in any case, you would be greatly aided by having an actual sp=
ec
> for OTS since i'm not interested in the specifics of OTS software, but I'm
> willing to look at the protocol. So if you do that, maybe we can talk more
> about the issue you see with how sponsors works.

OpenTimestamps is, as the name suggests, for cryptographic timestamping. As=
 is
obvious to anyone with a good knowledge of cryptography, a cryptographic
timestamp proves that data existed prior to some point in time. That's it.

> further, I think that if there is something that sponsors does that could
> make a hypothetical OTS-like service work better, in a way that would be
> opaque (read: soft-fork like wrt compatibility) to clients, then we should
> just change what OTS is rather than committing ourselves to a worse design
> in service of some unstated design goals. In particular, it seems that
> OTS's servers can be linearized and because old clients aren't looking for
> linearization, then the new linearization won't be a breaking change for
> old clients, just calendar servers. And new clients can benefit from
> linearization.

The fact you keep bringing up linearization for a timestmaping service make=
s me
think something is missing in your understanding of cryptography. Tell me, =
how
exactly do you think linearization would help in an example use-case? More
specifically, what attack would be prevented?

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--6beR0q5z9Iv1KmW/
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmJqhUMACgkQLly11TVR
LzeGpg/6Aj1Tpq9nEBTQldhdg7K8r08D3Q9mLxKnodcWq3ob5dpkH0i4J4EqWAJo
L0gzavOJqTzVeneXeu8cNHW+1Dc2rHqfgMnxIkgeWe1cB3ICb6muonboaL+2X2Zn
FXikQxxPAXcjdHvWnlQcYZPmV4wLGjxmOtwXxvOSKdIYyVIdK4hjn2oPu73NtEXR
3U3Q1QuTNp6EjTUYnPTiu6UTEKa5n42HMnMt2NHhvDkc//FFfsUBbWWqIObYN8bO
SnsBZepzr7U9skMI5R+2ZWWAVMfzdcFoiZ+eYejv+jP+ZXCawMdXPeu+uqdNNC7P
0+rMedvoavBQuv2V0m8K82wajfe6jV3MJgB7B0Bp4x9ClSYpRCF2Rm+6yJ/Pd8p6
BAMCioh6733jL6xkmvbtADxTjKxK+ywIvM06q7yNqgZUue8mvk8D1kZKuwFwu7Nn
kqMPisE6NHo4WnAXAxd/PoZKAn+GqzT1WwEz4xLKOsk9TjH0b2J8uaKikxp2ymfZ
ZVwO0+umV9KNRwP39K/i6rvEQQmI4pwnUOHORKiLOPJJlKiSvavTiGlF3Oo2RlR4
TaLFbIuf1BRgw+FC0PiGN648ZWfXx2me485iU8UGPULim+inmx2lmofP+jx/7p1w
7+WezAJrVODp+7qRhUX2/gdIILqtvWJllk9DXWd3H1g1nrI1ZoQ=
=IXid
-----END PGP SIGNATURE-----

--6beR0q5z9Iv1KmW/--