From: Chris Pacia <ctpacia@gmail•com>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
Date: Mon, 17 Nov 2014 07:31:33 -0500 [thread overview]
Message-ID: <5469EAA5.1020606@gmail.com> (raw)
In-Reply-To: <CALqxMTH3qBU88xpSu_evuBfRwMmF3cLpM=L5DUExKc--cO_O1Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1836 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 2390 bytes --]
next prev parent reply other threads:[~2014-11-17 12:31 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-16 16:21 Flavien Charlon
2014-11-16 17:24 ` Luke Dashjr
2014-11-16 18:44 ` Jorge Timón
2014-11-16 19:04 ` Jorge Timón
2014-11-17 3:19 ` Alan Reiner
2014-11-17 10:35 ` Pieter Wuille
2014-11-17 11:20 ` Adam Back
2014-11-17 12:31 ` Chris Pacia [this message]
2014-11-17 12:39 ` Pieter Wuille
2014-11-18 22:33 ` Chris Pacia
2014-11-17 11:43 ` Flavien Charlon
2014-11-17 12:00 ` Pieter Wuille
2014-11-17 12:22 ` Jorge Timón
2014-11-18 17:47 ` Btc Drak
2014-11-19 0:46 ` Flavien Charlon
2014-11-17 10:30 ` Wladimir
2014-11-20 23:39 ` Jean-Pierre Rupp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5469EAA5.1020606@gmail.com \
--to=ctpacia@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox