Re: [bitcoin-dev] [Pre-BIP] Fee Accounts

[Peter Todd <pete@petertodd.org>]

[-- Attachment #1: Type: text/plain, Size: 2472 bytes --]

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 nothing
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 spec
> 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 makes 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?

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]