public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Aaron Voisine <voisine@gmail•com>
To: 21E14 <21xe14@gmail•com>,
	 Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Cc: joi@media•mit.edu
Subject: Re: [Bitcoin-development] Why Bitcoin is and isn't like the Internet
Date: Tue, 20 Jan 2015 23:35:50 -0800	[thread overview]
Message-ID: <CACq0ZD4WVq=J91C2r3ENfvms2QHFiw2Tck=_f=85LKetbuuC3A@mail.gmail.com> (raw)
In-Reply-To: <CAFZQHkFfpTw2rua8D21BEB9S723+VQ+8xt19AjPm0_iQSs5YuQ@mail.gmail.com>

Ultimately the only way to insure bitcoin holdings is with an insurer
who themselves holds enough bitcoin to cover replacement of insured
funds. In the existing insurance industry, this is handled through a
system of re-insurance, where smaller firms are themselves insured
against catastrophic events that might cause a large number of
simultaneous claims. At the top of the chain sits super-cat insurance
firms like Berkshire Hathaway who do actually have the reserves to pay
out in case of such a super catastrophy. This is one of the most
lucrative businesses in the world, and one that today's very large
bitcoin holders will find themselves uniquely positioned to engage in
as bitcoin grows into a major global currency.

Aaron Voisine
breadwallet.com


On Tue, Jan 20, 2015 at 10:07 PM, 21E14 <21xe14@gmail•com> wrote:
> This is a response to a wonderfully insightful recent post by Joichi Ito,
> the Director of the MIT Media Lab. In it, Dr. Ito, notably a former Board
> Member of ICANN, offered his thoughts on "Why Bitcoin is and isn't like the
> Internet" and asked a most pertinent question: "Whether there is an ICANN
> equivalent needed for Bitcoin." As suggested in recent posts to the mailing
> list, I believe there might be, but for a reason that may not seem obvious
> at first.
>
> Alan Reiner expressed the need this way: "I think one of the biggest issues
> facing Bitcoin right now is not the lack of a 'killer app.' It is lack of
> insurance options. Early adopters would like to believe that the majority of
> users will hold their own Bitcoin, but I believe that is not a realistic
> option when life-changing quantities of Bitcoin are involved. We should not
> trust Grandma to secure her own retirement savings via complicated computer
> maneuvers. More to the point, she should not trust herself or anyone else
> (sic!) to hold it unless there is a strong protection against loss events.
> Right now the solution is for Grandma to avoid keeping her money in Bitcoin.
> Bitcoin needs a strong backbone of insured storage options so that Grandma
> can confidently participate in this new technology." This is certainly an
> observation to take heed of coming from the founder of Armory Technologies.
>
> The protection against loss events ought to be understood in the broadest
> sense. What is needed is a disaster recovery mechanism. Andreas Antonopoulos
> remarks expressed this candidly last year: "Bitcoin doesn't have a middle of
> the road mediocre growth model. It basically either dies, because of a
> fundamental flaw in the Bitcoin system. Not an external factor, an internal
> factor: We blow it up by accident. And that could happen... Bitcoin will
> play out in the next three years. In the next three years we're going to see
> Bitcoin arrive on the global stage and make a substantial impact, both in
> financial terms and in political terms. It will happen. Or it will die.
> Either way. I'm not sure. In which case we'll reboot another currency."
>
> A body, not entirely unlike ICANN, can manage the nexus to the physical
> world, and help address Bitcoin's catastrophic failure modes. Bitcoin's coin
> ownership protocol would thus join the ranks of its payment protocol, coin
> issuance protocol, consensus mechanism and inflation control that pose no
> lethal threat to the ecosystem. In addition to their coin-agnostic nature, I
> suspect the high valuation of large Bitcoin hubs relative to Bitcoin's
> market cap at this stage in its lifecycle is partly reflective of the
> sneaking suspicion that a custodial bitcoin (a bitcoin attached to an
> identity) may be worth more than a non-custodial one. With this in mind,
> I'll pitch in for the ticket should Dr. Ito decide to join the next month's
> DevCore Boston conference aimed at supporting the future development of
> Bitcoin. It's an hour's walk from MIT after all.
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



  reply	other threads:[~2015-01-21  7:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-21  6:07 21E14
2015-01-21  7:35 ` Aaron Voisine [this message]
2015-01-21  8:20 ` Alon Muroch
2015-01-21 19:44   ` odinn

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='CACq0ZD4WVq=J91C2r3ENfvms2QHFiw2Tck=_f=85LKetbuuC3A@mail.gmail.com' \
    --to=voisine@gmail$(echo .)com \
    --cc=21xe14@gmail$(echo .)com \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=joi@media$(echo .)mit.edu \
    /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