1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimon@jtimon.cc>) id 1XqLKa-0003dr-9F
for bitcoin-development@lists.sourceforge.net;
Mon, 17 Nov 2014 12:22:56 +0000
Received: from mail-wi0-f182.google.com ([209.85.212.182])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XqLKP-0003dz-4N
for bitcoin-development@lists.sourceforge.net;
Mon, 17 Nov 2014 12:22:56 +0000
Received: by mail-wi0-f182.google.com with SMTP id h11so8893873wiw.3
for <bitcoin-development@lists.sourceforge.net>;
Mon, 17 Nov 2014 04:22:39 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=dcLNRUUsVtLGLZlWs0ozHcJTLtItxTqa4ufaRKG6O0k=;
b=b5ndXOgaPj6fSuTHNJgaG3JE6/+2/xb7Ft+k71vD7tLjJr2o/B2FXMBCNXpdtPbKPC
UvszoZvJdvISaHd4FONwSGX2BFwE+yBaOfm/H9dRgNJyIJYRupNLUT5YRzHWkWxgIU7j
DUVIPxqaeEeH8OGx/oywowdnpK3sYXRLOVVu5GOX4wAC/e9z7pfufAu+VoFyTK6v4X4K
bl8WmhLvq0Z3ggVGuMx5PlmulRfYQpFr6lBSFSEUnUe7VIhe6xHaotQ/Mjm9WsBTQoLE
KkDiS3VfPRxmmXY5VBT7kH6Dg5zOjGeHwc+PJyF5JG6iTVq54I/tyNfmjofxnvQlJSGS
a4bg==
X-Gm-Message-State: ALoCoQmygyCeUbbfp/ffSqbyjdXkvQTp3W0cF8UMsoKKPfUsMJEfcL+u5GcDU3ZTIhFQVm0xhPEU
MIME-Version: 1.0
X-Received: by 10.194.241.194 with SMTP id wk2mr3303937wjc.132.1416226959077;
Mon, 17 Nov 2014 04:22:39 -0800 (PST)
Received: by 10.194.19.38 with HTTP; Mon, 17 Nov 2014 04:22:39 -0800 (PST)
X-Originating-IP: [92.251.101.114]
In-Reply-To: <CABbpET8yyZHO185Fzip61KoRTrGy4bEaoEpnzPuARfhhfPUTCg@mail.gmail.com>
References: <CABbpET9eTgk1GyxYbcG++O_rqsnfB7w5_Xp4XgE6qwkmGsm1eg@mail.gmail.com>
<201411161724.19573.luke@dashjr.org>
<CABm2gDpBOtZB01Qj3Dc3dWSpG2zLr+VPYbnwrq8YVh8qfxMW5Q@mail.gmail.com>
<CABm2gDoi1593ssoGN69E42c-N3s02yYKAqDEDA2m-e+6LqjpTQ@mail.gmail.com>
<5469692F.9030702@gmail.com>
<CAPg+sBgM4ja0Y96KekJUN7Qg=o0xa1B0VUiiPuFQTYfrupoERg@mail.gmail.com>
<CABbpET8yyZHO185Fzip61KoRTrGy4bEaoEpnzPuARfhhfPUTCg@mail.gmail.com>
Date: Mon, 17 Nov 2014 13:22:39 +0100
Message-ID: <CABm2gDrZpfQkmZXDDJY9KGAN-WiLE3g7GvZnsgoT=PXa2BhO+A@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Flavien Charlon <flavien.charlon@coinprism.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1XqLKP-0003dz-4N
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload
size
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 17 Nov 2014 12:22:56 -0000
On Mon, Nov 17, 2014 at 12:43 PM, Flavien Charlon
<flavien.charlon@coinprism.com> wrote:
> Storing only a hash
> is fine for the most basic timestamping application, but it's hardly enough
> to build something interesting.
No, storing only a hash is enough for ALL timestamping applications.
If you need to broadcast more data then we're not talking about
timestamping anymore, but rather proof of publication.
Unfortunately (and as it has been already mentioned) many applications
don't need proof of publication and yet they are just using the
blockchain as a convenient transport mechanism, but that's highly
inefficient.
It's like if you sent all your mails to all the existing email
addresses with the metadata "to be read by: destination@yourhost.com".
It wouldn't make any sense and it wouldn't scale.
A url definitely looks like something that doesn't belong in the chain.
|
