summaryrefslogtreecommitdiff
path: root/e1/cf61a597c78b42f836952b46576cf1acf27d40
blob: 5bd4b8b296f4caaa67ae96ad04922abdcdbb603c (plain)
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
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <ctpacia@gmail.com>) id 1XqLSy-0004gj-Aj
	for bitcoin-development@lists.sourceforge.net;
	Mon, 17 Nov 2014 12:31:36 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.42 as permitted sender)
	client-ip=74.125.82.42; envelope-from=ctpacia@gmail.com;
	helo=mail-wg0-f42.google.com; 
Received: from mail-wg0-f42.google.com ([74.125.82.42])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1XqLSx-0005Zd-6F
	for bitcoin-development@lists.sourceforge.net;
	Mon, 17 Nov 2014 12:31:36 +0000
Received: by mail-wg0-f42.google.com with SMTP id z12so6623661wgg.29
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 17 Nov 2014 04:31:29 -0800 (PST)
X-Received: by 10.181.27.135 with SMTP id jg7mr30702157wid.56.1416227489176;
	Mon, 17 Nov 2014 04:31:29 -0800 (PST)
Received: from [10.4.89.214] ([95.211.138.27])
	by mx.google.com with ESMTPSA id w5sm15066458wif.18.2014.11.17.04.31.27
	for <bitcoin-development@lists.sourceforge.net>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 17 Nov 2014 04:31:28 -0800 (PST)
Message-ID: <5469EAA5.1020606@gmail.com>
Date: Mon, 17 Nov 2014 07:31:33 -0500
From: Chris Pacia <ctpacia@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
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>
	<CALqxMTH3qBU88xpSu_evuBfRwMmF3cLpM=L5DUExKc--cO_O1Q@mail.gmail.com>
In-Reply-To: <CALqxMTH3qBU88xpSu_evuBfRwMmF3cLpM=L5DUExKc--cO_O1Q@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------090404020601050701080803"
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(ctpacia[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1XqLSx-0005Zd-6F
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:31:36 -0000

This is a multi-part message in MIME format.
--------------090404020601050701080803
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit


On 11/17/2014 06:20 AM, Adam Back wrote:
> b) backup: the blockchain is not an efficient reliable generic backup
> mechanism because its broadcast.  there are cheaper and relatively
> simple ways to get end2end secure backup, the main challenge of which
> is having secure keys and not forgetting them.  bitcoin already has
> that covered as its a central requirement of blockchain security.  If
> you want to archive your payment protocol receipts store them on some
> cloud storage service or disk encrypted with related keys.  for
> example tahoe-lafs is optimised for the decentralised long-term
> storage kind of use.
>
This is my main concern in the context of stealth addresses. I intend to
start a larger discussion on stealth addresses, but I wont hijack the
tread.

Of course it's easy to send the necessary data out of band as opposed to
OP_RETURN. The problem is if you do that the transaction cannot not be
recovered from seed. We've been fairly successful in transitioning to HD
wallets and avoiding the need to make regular wallet backups.

If users wishes to use stealth addresses with out of band communication,
the benefits of HD would largely be lost and they would be back to
making regular backups ― this time after /every/ transaction rather than
every 100.

There are only a couple options in such cases:

1) The user could send the payment to an addresses that is derived from
seed, but now you're using even /more/ storage space than you would by
just using OP_RETURN.

2) The user can backup after every transaction, which nobody wants to do.

3) The user could use some form of a cloud backup service and place
trust in them that their servers wont go down and lose their coins.

None of those options are really that appealing. OP_RETURN seems like
the best alternative to me, at least for that use case.

--------------090404020601050701080803
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <div class="moz-cite-prefix">On 11/17/2014 06:20 AM, Adam Back
      wrote:<br>
    </div>
    <blockquote
cite="mid:CALqxMTH3qBU88xpSu_evuBfRwMmF3cLpM=L5DUExKc--cO_O1Q@mail.gmail.com"
      type="cite">
      <pre wrap="">b) backup: the blockchain is not an efficient reliable generic backup
mechanism because its broadcast.  there are cheaper and relatively
simple ways to get end2end secure backup, the main challenge of which
is having secure keys and not forgetting them.  bitcoin already has
that covered as its a central requirement of blockchain security.  If
you want to archive your payment protocol receipts store them on some
cloud storage service or disk encrypted with related keys.  for
example tahoe-lafs is optimised for the decentralised long-term
storage kind of use.

</pre>
    </blockquote>
    This is my main concern in the context of stealth addresses. I
    intend to start a larger discussion on stealth addresses, but I wont
    hijack the tread. <br>
    <br>
    Of course it's easy to send the necessary data out of band as
    opposed to OP_RETURN. The problem is if you do that the transaction
    cannot not be recovered from seed. We've been fairly successful in
    transitioning to HD wallets and avoiding the need to make regular
    wallet backups. <br>
    <br>
    If users wishes to use stealth addresses with out of band
    communication, the benefits of HD would largely be lost and they
    would be back to making regular backups ― this time after <i>every</i>
    transaction rather than every 100. <br>
    <br>
    There are only a couple options in such cases:<br>
    <br>
    1) The user could send the payment to an addresses that is derived
    from seed, but now you're using even <i>more</i> storage space than
    you would by just using OP_RETURN.<br>
    <br>
    2) The user can backup after every transaction, which nobody wants
    to do. <br>
    <br>
    3) The user could use some form of a cloud backup service and place
    trust in them that their servers wont go down and lose their coins.
    <br>
    <br>
    None of those options are really that appealing. OP_RETURN seems
    like the best alternative to me, at least for that use case. <br>
  </body>
</html>

--------------090404020601050701080803--