Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 2B244C002C; Mon, 11 Apr 2022 13:18:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 1A021817AF; Mon, 11 Apr 2022 13:18:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gmx0KJQmiq4; Mon, 11 Apr 2022 13:18:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) by smtp1.osuosl.org (Postfix) with ESMTPS id 0325F80B3F; Mon, 11 Apr 2022 13:18:23 +0000 (UTC) Received: by mail-lf1-x129.google.com with SMTP id bq30so13821208lfb.3; Mon, 11 Apr 2022 06:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5a7RWW2ubf1hUxB5/VOvfkXvueXIHxHw9YWNiT2yu2E=; b=cj+LRXW5iKU1Zog748Q9WgD6wG+rxemeKjgDkrkwMplFOhQjaXIy3aoiG1LKSoRgx5 bgHBzGOsjGMuFGb1kH68nonZCEsI8pDa6fV4xpdZWNiRPs1uw3ZsNhX0PlSi+ax92SNk MVVhyOD8eZ/iUYLFrWuDolSEEe5zLQjtq3J7H/lDeJROZgWqY6QO967DqES6kp6tUIle 5EFXT+t+Ni8rS8GRuPiB8n4hgeGETo6sPJsbVIjxQmUYTciMzkx0mapukDcpyj/TeJoe vvXgm3eEe/7MMsuaWe/yrOPsz59Tho9AGHcV1UwPSERN0sD3cVAlpfXYFawgiXD+7hE9 dNjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5a7RWW2ubf1hUxB5/VOvfkXvueXIHxHw9YWNiT2yu2E=; b=E3rSsLSZNDJVCrWNihHFcAnzotuvqFTUHgBM77NBFlTGl7XHpStgcnSxgXfjHEDVeT Pw4anq+Sm5ljd8mV0pBcPeYdZ67wEuaOD+Uz22MJ4eIsCSQMDUwq9WsbS7cIJkxG9SZM Dcrx1ibBGpxV2Ayi1YsyCLfbeRccPjzQ3TvCWx2KDKPHDlxMP0Y2VbT6LBcXz+EdV6o0 /qAJepJsimGAuQ5wVuJgsnk5L524xBZcBlkv1e6HAMYOfk5Tn8ilA36SSK0B4r4zKoYH 0+a9Hhuh/ZCiK0nXiZcIgd5UMi4RIFgjLWnqaCkVQz925SxJUYGCurCuqOoYWOjyOOzj AQug== X-Gm-Message-State: AOAM532ePLOF9RlhER+Ee91AwLVty+DePVp+GyQNb/6SHHPtmvD63jS4 IlQGC17cCTSH6zpO9CEDs31fwAHTOsXi81x6j1rm0/a3Kw4= X-Google-Smtp-Source: ABdhPJzSi/xlgY+vFSaVdC2anEeCESQy8ns6fMd7uhyc30XodopIZKkQ9p7DcH9SM2S0fud3PJHghkISLJ9MZMLMPZI= X-Received: by 2002:ac2:4c41:0:b0:46b:8bc6:4607 with SMTP id o1-20020ac24c41000000b0046b8bc64607mr9974468lfk.516.1649683101710; Mon, 11 Apr 2022 06:18:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeremy Rubin Date: Mon, 11 Apr 2022 09:18:10 -0400 Message-ID: To: Peter Todd Content-Type: multipart/alternative; boundary="00000000000044fc7705dc60c74d" Cc: Bitcoin Protocol Discussion , lightning-dev , Jeremy Subject: Re: [bitcoin-dev] [Pre-BIP] Fee Accounts X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2022 13:18:25 -0000 --00000000000044fc7705dc60c74d Content-Type: text/plain; charset="UTF-8" > nonsense marketing I'm sure the people who are confused about "blockchain schemes as \"world computers\" and other nonsense marketing" are avid and regular readers of the bitcoin devs mailing list so I offer my sincerest apologies to all members of the intersection of those sets who were confused by the description given. > useless work progress is not useless work, it *is* useful work in this context. you have committed to some subset of data that you requested -- if it was 'useless', why did you *ever* bother to commit it in the first place? However, it is not 'maximally useful' in some sense. However, progress is progress -- suppose you only confirmed 50% of the commitments, is that not progress? If you just happened to observe 50% of the commitments commit because of proximity to the time a block was mined and tx propagation naturally would you call it useless? > Remember that OTS simply proves data in the past. Nothing more. > OTS doesn't have a chain of transactions Gotcha -- I've not been able to find an actual spec of Open Time Stamps anywhere, so I suppose I just assumed based on how I think it *should* work. Having a chain of transactions would serve to linearize history of OTS commitments which would let you prove, given reorgs, that knowledge of commit A was before B a bit more robustly. > 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 This sounds like a personal preference v.s. a technical requirement. You aren't doing any extra transactions in the model i showed, what you're doing is selecting the window for the next based on the prior conf. See the diagram below, you would have to (if OTS is correct) support this sort of 'attempt/confirm' head that tracks attempted commitments and confirmed ones and 'rewinds' after a confirm to make the next commit contain the prior attempts that didn't make it. [.........................................................................] ------^ confirm head tx 0 at height 34 ------------------------^ attempt head after tx 0 -----------^ confirm head tx 1 at height 35 --------------------------^ attempt head after tx 1 ------------^ confirm head tx 2 at height 36 -------------------------------^ attempt head after tx 2 -------------------------------^ confirm head tx 3 at height 37 you can compare this to a "spherical cow" model where RBF is always perfect and guaranteed inclusion: [.........................................................................] ------^ confirm head tx 0 at height 34 -------------------------^ confirm head tx 1 at height 35 -----------^ confirm head at tx 1 height 36 -----------------^ confirm head tx 3 at height 37 The same number of transactions gets used over the time period. --00000000000044fc7705dc60c74d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0nonsense=C2= =A0marketing

I'm sure the people who a= re confused about "blockchain schemes as \"world computers\"= and other nonsense
marketing" are avid and regular readers of the bitcoin devs mailing list so = I offer my sincerest apologies to all members of the intersection of those = sets who were confused by the description given.

<= span class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri= f;font-size:small;color:rgb(0,0,0)">>=C2=A0useless = work

progress is not useless work, it *is* useful = work in this context. you have committed to some subset of data that you re= quested -- if it was 'useless', why did you *ever* bother to commit= it in the first place? However, it is not 'maximally useful' in so= me sense. However, progress is progress -- suppose you only confirmed 50% o= f the commitments, is that not progress? If you just happened to observe 50= % of the commitments commit because of proximity to the time a block was mi= ned and tx propagation naturally would you call it useless?

>=C2=A0= Remember that OTS simply proves data in the past. Noth= ing more.
>=C2=A0OTS doesn't have a chain of = transactions
Gotcha -- I've not been able to find an a= ctual spec of Open Time Stamps anywhere, so I suppose I just assumed based = on how I think it *should* work. Having a chain of transactions would serve= to linearize history of OTS commitments which would let you prove, given r= eorgs, that knowledge of commit A was before B a bit more robustly.=C2=A0

>=C2=A0=C2=A0I'd rath= er do one transaction with all = pending commitments at a particular time
rather than waste money on mi= ning two transactions for a given set of
commitments

This sounds lik= e a personal preference v.s. a technical requirement.<= /div>

You aren't doing any extra transactions i= n the model i showed, what you're doing is selecting the window for the= next based on the prior conf.

<= /font>
See the diagram below, you would have to (if OTS is correct) suppo= rt this sort of 'attempt/confirm' head that tracks attempted commit= ments and confirmed ones and 'rewinds' after a confirm to make the = next commit contain the prior attempts that didn't make it.

[..................................= .......................................]
=C2=A0-----= -^ confirm head tx 0 at height 34
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 ------------------------^ attempt head after tx 0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-----------^ conf= irm head tx 1 at height 35
<= span class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri= f;font-size:small;color:rgb(0,0,0)"> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --------------------------^ attempt = head after tx 1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ------------^ confirm head tx 2 a= t height 36
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0-------------------------------^ attempt head after tx = 2
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 -------------------------------^ confirm head tx 3 at height 37<= /span>

you can compare this to a "spherical cow" model where RBF = is always perfect and guaranteed inclusion:
=

[....................................................................= .....]
=C2=A0------^ confirm = head tx 0 at height 34
=C2= =A0 =C2=A0 =C2=A0 =C2=A0-------------------------^ confirm=C2=A0= head tx 1 at height 35
<= span class=3D"gmail_default"> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0-----------^ confirm head at tx 1 height 36
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0----------------= -^ confirm head tx 3 at height 37

The same number of transactions gets used ov= er the time period.


--00000000000044fc7705dc60c74d--