📅 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>;
Christopher Gilliard [ARCHIVE] /
npub1qm…0hwnt
2023-06-07 18:31:36
in reply to nevent1q…egdc
Author Public Key
npub1qmsejphez6np2my9fu40kj9en68d5fa3s7ap4ul7eh9aeuljusgs50hwntSeen on
wss://relay.nostr.bandPublished at
2023-06-07 18:31:36Event JSON
{
"id": "f2ba171b3588bc1e0814507258017a9b37fc61fe81bcc2c63bd22d527fb43046",
"pubkey": "06e19906f916a6156c854f2afb48b99e8eda27b187ba1af3fecdcbdcf3f2e411",
"created_at": 1686162696,
"kind": 1,
"tags": [
[
"e",
"05257ee76521a4b0a7a99d485b789d700ff2df92d74daa2032d8f5697bc9d8ff",
"",
"root"
],
[
"e",
"d6edaeb72ad31c7879f70991ef70a957d21e7ff2b0000739c5f8c289618b3461",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2021-04-17\n📝 Original message:Peter, thanks for the links. I'm aware that there are other timestamping\naggregation services that already exist, but I had some different ideas\nthat integrate into some other services. Also thanks for sending the link\nto the single use seal asset transfer. I will take a look at that.\n\nOn Sat, Apr 17, 2021 at 3:50 PM Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\n\u003e On Sat, Apr 17, 2021 at 03:57:55AM +0000, Christopher Gilliard via\n\u003e bitcoin-dev wrote:\n\u003e \u003e Thanks ZmnSCPxj. Yes, I agree there are many ways to embed arbitrary data\n\u003e \u003e in the blockchain and it's not feasible to block all of them. That is why\n\u003e \u003e it's important to, at the same time as limiting the OP_RETURN to one per\n\u003e \u003e block, also propose and implement a layer 2 solution for timestamping\n\u003e \u003e so people have a clear and simple upgrade path. That is what I will be\n\u003e \u003e discussing in one of the BIPs I intend to release early next week.\n\u003e\n\u003e Note that an aggregated timestamping service already exists:\n\u003e\n\u003e https://petertodd.org/2016/opentimestamps-announcement\n\u003e\n\u003e But timestamping is useless for most things people want to do, as it can't\n\u003e commit to a unique history. It merely proves something existed in the\n\u003e past. For\n\u003e uniqueness, you need something like:\n\u003e\n\u003e https://petertodd.org/2017/scalable-single-use-seal-asset-transfer\n\u003e\n\u003e\n\u003e Anyway, at current fees being what they are there's no compelling reason\n\u003e to try\n\u003e to prevent people from embedding data in the Bitcoin block chain with\n\u003e consensus\n\u003e changes. Economics is preventing that just fine.\n\u003e\n\u003e --\n\u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210417/618da7c6/attachment.html\u003e",
"sig": "2e9918c1435ab6fb9a84d949445e931e0517455a8f44370f8963dbeba850237979aed2e9129746737c2a6339ff48a12b8a2c7509f699f512a2a2efbd4b62f264"
}