Christopher Gilliard [ARCHIVE] on Nostr: 📅 Original date posted:2021-04-17 📝 Original message:Peter, thanks for the ...

📅 Original date posted:2021-04-17
📝 Original message:Peter, thanks for the links. I'm aware that there are other timestamping
aggregation services that already exist, but I had some different ideas
that integrate into some other services. Also thanks for sending the link
to the single use seal asset transfer. I will take a look at that.

On Sat, Apr 17, 2021 at 3:50 PM Peter Todd <pete at petertodd.org> wrote:

> On Sat, Apr 17, 2021 at 03:57:55AM +0000, Christopher Gilliard via
> bitcoin-dev wrote:
> > Thanks ZmnSCPxj. Yes, I agree there are many ways to embed arbitrary data
> > in the blockchain and it's not feasible to block all of them. That is why
> > it's important to, at the same time as limiting the OP_RETURN to one per
> > block, also propose and implement a layer 2 solution for timestamping
> > so people have a clear and simple upgrade path. That is what I will be
> > discussing in one of the BIPs I intend to release early next week.
>
> Note that an aggregated timestamping service already exists:
>
> https://petertodd.org/2016/opentimestamps-announcement
>
> But timestamping is useless for most things people want to do, as it can't
> commit to a unique history. It merely proves something existed in the
> past. For
> uniqueness, you need something like:
>
> https://petertodd.org/2017/scalable-single-use-seal-asset-transfer
>
>
> Anyway, at current fees being what they are there's no compelling reason
> to try
> to prevent people from embedding data in the Bitcoin block chain with
> consensus
> changes. Economics is preventing that just fine.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210417/618da7c6/attachment.html>;