+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--

+

+