public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jeremy Rubin <jeremy.l.rubin@gmail.com>
To: Peter Todd <pete@petertodd.org>
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
Date: Mon, 2 May 2022 08:59:49 -0700	[thread overview]
Message-ID: <CAD5xwhhB+8n+9pWiSCtx3DAPnSwV_7xHnXZ14mEj9H93eWUNEw@mail.gmail.com> (raw)
In-Reply-To: <YmqFRlDIkfbyVIZ2@petertodd.org>

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

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.

[-- Attachment #2: Type: text/html, Size: 1688 bytes --]

  reply	other threads:[~2022-05-02 16:00 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-01 20:04 [bitcoin-dev] [Pre-BIP] Fee Accounts Jeremy
2022-01-18 16:12 ` Billy Tetrud
2022-01-18 17:43   ` Jeremy
2022-01-19  2:37     ` Billy Tetrud
2022-01-19  2:51       ` Jeremy
2022-01-19  4:53         ` Billy Tetrud
2022-01-19  7:32           ` Jeremy
2022-01-19 16:51             ` Billy Tetrud
2022-01-19 20:08               ` Jeremy
2022-01-20  5:23                 ` Billy Tetrud
2022-02-10  6:58 ` Peter Todd
2022-02-10  8:08   ` Jeremy Rubin
2022-02-18 23:50     ` Peter Todd
2022-02-19  0:38       ` Jeremy Rubin
2022-02-19  9:39         ` Peter Todd
2022-02-19 17:20           ` [bitcoin-dev] [Lightning-dev] " darosior
2022-02-19 20:35             ` Peter Todd
2022-02-20  2:24               ` ZmnSCPxj
2022-02-20  2:39                 ` ZmnSCPxj
     [not found]             ` <590cf52920040c9cf7517b219624bbb5@willtech.com.au>
2022-02-20 14:24               ` ZmnSCPxj
2022-02-20 16:29                 ` Jeremy Rubin
     [not found]                 ` <CAD5xwhgEeTETburW=OBgHNe_V1kk8o06TDQLiLgdfmP2AEVuPg@mail.gmail.com>
2022-02-20 16:34                   ` ZmnSCPxj
2022-02-20 16:45                     ` Jeremy Rubin
2022-02-20 16:29           ` [bitcoin-dev] " Jeremy Rubin
2022-04-10 19:32             ` Peter Todd
2022-04-11 13:18               ` Jeremy Rubin
2022-04-15 14:52                 ` Peter Todd
2022-04-17 20:57                   ` Jeremy Rubin
2022-04-28 12:15                     ` Peter Todd
2022-05-02 15:59                       ` Jeremy Rubin [this message]
2022-06-14 11:12                         ` [bitcoin-dev] Why OpenTimestamps does not "linearize" its transactions Peter Todd
2022-06-14 11:39                           ` Undiscussed Horrific Abuse, One Victim of Many
2022-06-14 11:53                             ` Undiscussed Horrific Abuse, One Victim of Many
2022-06-14 12:28                               ` rot13maxi
2022-06-14 12:45                                 ` Undiscussed Horrific Abuse, One Victim of Many
2022-06-14 13:55                                   ` Bryan Bishop
2022-06-14 15:06                                     ` digital vagabond
2022-06-14 15:34                                   ` Peter Todd
2022-06-14 17:15                                     ` Undiscussed Horrific Abuse, One Victim of Many
2022-06-14 20:33                                       ` Andrew Poelstra
2022-06-15  1:16                                         ` Undiscussed Horrific Abuse, One Victim of Many
2022-06-15  1:21                                           ` Undiscussed Horrific Abuse, One Victim of Many
2022-06-19 11:04                                           ` Peter Todd
2022-06-14 15:22                               ` Peter Todd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAD5xwhhB+8n+9pWiSCtx3DAPnSwV_7xHnXZ14mEj9H93eWUNEw@mail.gmail.com \
    --to=jeremy.l.rubin@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jlrubin@mit.edu \
    --cc=lightning-dev@lists.linuxfoundation.org \
    --cc=pete@petertodd.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox