📅 Original date posted:2022-04-15
📝 Original message:
On Mon, Apr 11, 2022 at 09:18:10AM -0400, Jeremy Rubin wrote:
> > 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.
Of course, uninformed people _do_ read all kinds of technical materials. And
more importantly, those technical materials get quoted by journalists,
scammers, etc.
> > 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?
Please don't trim quoted text to the point where all context is lost. Lots of
people read this mailing list and doing that isn't helpful to them.
> > 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
The technical spec of OpenTimestamps is of course the normative validation
source code, currently python-opentimestamps, similar to how the technical spec
of Bitcoin is the consensus parts of the Bitcoin Core codebase. The explanatory
docs are linked on https://opentimestamps.org under the "How It Works" section.
It'd be good to take the linked post in that section and turn it into better
explanatory materials with graphics (esp interactive/animated graphics).
> 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'll reply to this as a separate email as this discussion - while useful - is
getting quite off topic for this thread.
> > 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.
...the model you showed is wrong, as there is no reason to have a linearized
transaction history. OpenTimestamps proofs don't even have the concept of
transactions: the proof format proves that data existed prior to a merkle root
of a particular Bitcoin block. Not a Bitcoin transaction.
> 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.
None of the above has anything to do with how OpenTimestamps works.
Anyway, getting back to the topic at hand, I remain of the opinion that in the
unlikely event that fee accounts is ever implemented, it should be opt-in.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220415/3d390f28/attachment-0001.sig>;
Peter Todd [ARCHIVE] /
npub1m2…a2np2
2023-06-09 13:05:49
in reply to nevent1q…rwph
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-09 13:05:49Event JSON
{
"id": "94c44da741b4cffff8e84203ac53563439b5a714b36ef52205e675cff87c637d",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686315949,
"kind": 1,
"tags": [
[
"e",
"f5566a6718d36fcb17a247b051b47bb1d176e05351f8735d2c3340058f71c38d",
"",
"root"
],
[
"e",
"6cdb6793d18cc03854c6411f77885763c4bb2bcbe474b7881e406b23def9a630",
"",
"reply"
],
[
"p",
"372c316761360b4ea20f2d7e81a59363b7e45b8e945a5381c3122049c2c4b84a"
]
],
"content": "📅 Original date posted:2022-04-15\n📝 Original message:\nOn Mon, Apr 11, 2022 at 09:18:10AM -0400, Jeremy Rubin wrote:\n\u003e \u003e nonsense marketing\n\u003e \n\u003e I'm sure the people who are confused about \"blockchain schemes as \\\"world\n\u003e computers\\\" and other nonsense\n\u003e marketing\" are avid and regular readers of the bitcoin devs mailing list so\n\u003e I offer my sincerest apologies to all members of the intersection of those\n\u003e sets who were confused by the description given.\n\nOf course, uninformed people _do_ read all kinds of technical materials. And\nmore importantly, those technical materials get quoted by journalists,\nscammers, etc.\n\n\u003e \u003e useless work\n\u003e \n\u003e progress is not useless work, it *is* useful work in this context. you have\n\u003e committed to some subset of data that you requested -- if it was 'useless',\n\u003e why did you *ever* bother to commit it in the first place? However, it is\n\u003e not 'maximally useful' in some sense. However, progress is progress --\n\u003e suppose you only confirmed 50% of the commitments, is that not progress? If\n\u003e you just happened to observe 50% of the commitments commit because of\n\u003e proximity to the time a block was mined and tx propagation naturally would\n\u003e you call it useless?\n\nPlease don't trim quoted text to the point where all context is lost. Lots of\npeople read this mailing list and doing that isn't helpful to them.\n\n\u003e \u003e Remember that OTS simply proves data in the past. Nothing more.\n\u003e \u003e OTS doesn't have a chain of transactions\n\u003e Gotcha -- I've not been able to find an actual spec of Open Time Stamps\n\nThe technical spec of OpenTimestamps is of course the normative validation\nsource code, currently python-opentimestamps, similar to how the technical spec\nof Bitcoin is the consensus parts of the Bitcoin Core codebase. The explanatory\ndocs are linked on https://opentimestamps.org under the \"How It Works\" section.\nIt'd be good to take the linked post in that section and turn it into better\nexplanatory materials with graphics (esp interactive/animated graphics).\n\n\u003e anywhere, so I suppose I just assumed based on how I think it *should*\n\u003e work. Having a chain of transactions would serve to linearize history of\n\u003e OTS commitments which would let you prove, given reorgs, that knowledge of\n\u003e commit A was before B a bit more robustly.\n\nI'll reply to this as a separate email as this discussion - while useful - is\ngetting quite off topic for this thread.\n\n\u003e \u003e I'd rather do one transaction with all pending commitments at a\n\u003e particular time\n\u003e rather than waste money on mining two transactions for a given set of\n\u003e commitments\n\u003e \n\u003e This sounds like a personal preference v.s. a technical requirement.\n\u003e \n\u003e You aren't doing any extra transactions in the model i showed, what you're\n\u003e doing is selecting the window for the next based on the prior conf.\n\n...the model you showed is wrong, as there is no reason to have a linearized\ntransaction history. OpenTimestamps proofs don't even have the concept of\ntransactions: the proof format proves that data existed prior to a merkle root\nof a particular Bitcoin block. Not a Bitcoin transaction.\n\n\u003e See the diagram below, you would have to (if OTS is correct) support this\n\u003e sort of 'attempt/confirm' head that tracks attempted commitments and\n\u003e confirmed ones and 'rewinds' after a confirm to make the next commit\n\u003e contain the prior attempts that didn't make it.\n\u003e \n\u003e [.........................................................................]\n\u003e ------^ confirm head tx 0 at height 34\n\u003e ------------------------^ attempt head after tx 0\n\u003e -----------^ confirm head tx 1 at height 35\n\u003e --------------------------^ attempt head after tx 1\n\u003e ------------^ confirm head tx 2 at height 36\n\u003e -------------------------------^\n\u003e attempt head after tx 2\n\u003e -------------------------------^\n\u003e confirm head tx 3 at height 37\n\u003e \n\u003e you can compare this to a \"spherical cow\" model where RBF is always perfect\n\u003e and guaranteed inclusion:\n\u003e \n\u003e \n\u003e [.........................................................................]\n\u003e ------^ confirm head tx 0 at height 34\n\u003e -------------------------^ confirm head tx 1 at height 35\n\u003e -----------^ confirm head at tx 1\n\u003e height 36\n\u003e -----------------^\n\u003e confirm head tx 3 at height 37\n\u003e \n\u003e The same number of transactions gets used over the time period.\n\nNone of the above has anything to do with how OpenTimestamps works.\n\nAnyway, getting back to the topic at hand, I remain of the opinion that in the\nunlikely event that fee accounts is ever implemented, it should be opt-in.\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220415/3d390f28/attachment-0001.sig\u003e",
"sig": "e9b19a495faa2cdeb5b5544a5b0c77bf461e027cb631315f0bd6a0a9ea1b13889b9039e82136ef1be8c470e9389f8754fcaecaa36cf437e895f84190a0615ade"
}