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
signature.asc
Description: PGP signature
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
