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

[Peter Todd <pete@petertodd.org>]

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

On Sun, Feb 20, 2022 at 08:29:00AM -0800, Jeremy Rubin wrote:
> > On Fri, Feb 18, 2022 at 04:38:27PM -0800, Jeremy Rubin wrote:
> > > > As I said, it's a new kind of pinning attack, distinct from other types
> > > of pinning attack.
> > >
> > > I think pinning is "formally defined" as sequences of transactions which
> > > prevent or make it less likely for you to make any progress (in terms of
> > > units of computation proceeding).
> >
> > Mentioning "computation" when talking about transactions is misleading:
> > blockchain transactions have nothing to do with computation.
> >
> 
> It is in fact computation. Branding it as "misleading" is misleading... The
> relevant literature is https://en.wikipedia.org/wiki/Non-blocking_algorithm,
> sponsors helps get rid of deadlocking so that any thread can be guaranteed
> to make progress. E.g., this is critical in Eltoo, which is effectively a
> coordinated multi-party computation on-chain to compute the highest
> sequence number known by any worker.
> 
> That transactions are blobs of "verification" (which is also itself a
> computation) less so than dynamic computations is irrelevant to the fact
> that series of transactions do represent computations.

It's misleading in the blockchain environment where lots of people have been
trying to portray blockchain schemes as "world computers" and other nonsense
marketing. You would have been better off just saying "make any progress"
without mentioning "computation" at all.

> > > Something that only increases possibility to make progress cannot be
> > > pinning.
> >
> > It is incorrect to say that all use-cases have the property that any
> > version of
> > a transaction being mined is progress.
> >
> 
> It is progress, tautologically. Progress is formally definable as a
> transaction of any kind getting mined. Pinning prevents progress by an
> adversarial worker. Sponsoring enables progress, but it may not be your
> preferred interleaving. That's OK, but it's inaccurate to say it is not
> progress.

Let's try to use terminology with straight-forward meanings. I've yet to see
any other protocol where "progess" can also mean useless work being done.

> I didn't claim there to be a chain of unconfirmed, I claimed that there
> could be single output chain that you're RBF'ing one step per block.
> 
> E.g., it could be something like
> 
> A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo}}
> A_1 -> {A_2 w/ CSV 1 block, OP_RETURN {bar}}
> 
> such that A_i provably can't have an unconfirmed descendant. The notion
> would be that you're replacing one with another. E.g., if you're updating
> the calendar like:
> 
> 
> Version 0: A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo}}
> Version 1: A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo, bar}}
> Version 2: A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo, bar, delta}}
> 
> and version 1 gets mined, then in A_1's spend you simply shift delta to
> that (next) calendar.
> 
> A_1 -> {A_2 w/ CSV 1 block, OP_RETURN {delta}}
> 
> Thus my claim that someone sponsoring a old version only can delay by 1
> block the calendar commit.

You seem to still be confused about OpenTimestamps. There is no output chain at
all; OTS has no reason to use CheckSequenceVerify and does not. OTS
transactions are, from the point of view of the timestamp proofs, entirely
independent of one another.

Remember that OTS simply proves data in the past. Nothing more.

> > > Lastly, if you do get "necromanced" on an earlier RBF'd transaction by a
> > > third party for OTS, you should be relatively happy because it cost you
> > > less fees overall, since the undoing of your later RBF surely returned
> > some
> > > satoshis to your wallet.
> >
> > As I said above, no it doesn't.
> >
> >
> It does save money since you had to pay to RBF, the N+1st txn will be
> paying higher fee than the Nth. So if someone else sponsors an earlier
> version, then you save whatever feerate/fee bumps you would have paid and
> the funds are again in your change output (or something). You can apply
> those change output savings to your next batch, which can include any
> entries that have been dropped .

Again, that is not true. Because OTS doesn't have a chain of transactions, I'd
rather do one transaction with all pending commitments at a particular time
rather than waste money on mining two transactions for a given set of
commitments that need timestamping.

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

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