Date: Sun, 9 Feb 2014 12:11:32 -0600
From: Troy Benjegerdes <hozer@hozed.org>
To: Luke-Jr <luke@dashjr.org>
Message-ID: <20140209181132.GF3180@nl.grid.coop>
References: <20140209171214.GA20126@savin> <201402091725.42306.luke@dashjr.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <201402091725.42306.luke@dashjr.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Embedded consensus system upgrade
 procedures
Precedence: list

On Sun, Feb 09, 2014 at 05:25:41PM +0000, Luke-Jr wrote:
> On Sunday, February 09, 2014 5:12:14 PM Peter Todd wrote:
> > We have an embedded consensus system and we want to be able to upgrade
> > it with new rules.
> 
> This asserts a central authority and gives developers too much power.

I don't quite see how, There is nothing that 'forces' me to upgrade,
unless I have chosen to run an operating system (MacOS, Windows, Android)
that have automatic don't-ask-the-user update mechanisms.

The bigger problem with 'asset transfer' of assets which do not exist 
soley in the blockchain is including the consensus of relevant local and
distributed legal jurisdictions.

For example, just because the 'colored coin' and blockchain consensus is
that I 'electronically' signed a mortgage document giving some random 
internet company the rights to foreclose on my home does not mean that 
my local county Judge or Sheriff are going to do anything if the internet
company cannot produce the original paper document with ink signature.

The only 'assertion' of central authority here is people who download and
run the code and submit to whatever the code asserts they are supposed to do.

At least with the 'central authority' of the big-business bitcoin developer
cabal I can read the code before I submit to it's central authority, and
this is a significant improvement over amgibuous legislation or proprietary
high-frequency trading algorithms.