Jeremy Rubin [ARCHIVE] on Nostr: 📅 Original date posted:2022-04-11 📝 Original message:> nonsense marketing I'm ...
📅 Original date posted:2022-04-11
📝 Original message:> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220411/2492791b/attachment.html>;
📝 Original message:> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220411/2492791b/attachment.html>;