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
Precedence: list


--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/--