Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WEgSa-0001He-U2 for bitcoin-development@lists.sourceforge.net; Sat, 15 Feb 2014 14:43:16 +0000 Received: from mail-la0-f54.google.com ([209.85.215.54]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WEgSZ-0000Lz-6u for bitcoin-development@lists.sourceforge.net; Sat, 15 Feb 2014 14:43:16 +0000 Received: by mail-la0-f54.google.com with SMTP id y1so10197038lam.13 for ; Sat, 15 Feb 2014 06:43:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=woug6vg9yiwLRKp7TMKEIFeBkWksWFGGWsYVoLmjCQ8=; b=m1BXb3A6z2YI7Dy1/TTKSt9kNFtdJjVuUkspRCIVPL7e2ld+Wo5c/qC15S4WLWOsEP /EmmP++uHDSpYjEwnehCRmOxwvl2HU3um0DRbXkdBKxZlEXJd791b7fn+d6VJBlIvmOd 9chEUPsXSKtPprkjDmXK2H3swoMXWhEKTCo+u6RfHb+YzV7LflMB0RBPANuNmgAhn/5Y Zt5lYvYm/LhzUWYHHsqZ9U0NyNA4hP029zv/yjBwr9+7h5Ct8V2aBz3TG3NwmejG16OH vAb7pF8FrGhkCDn9arFaECA0mrCmvuG8JCxM9dzOwLCnhVqGH1LNb2PhUIgnQK7ZpPor tRTQ== X-Gm-Message-State: ALoCoQk4h5rgbOnDq1NiAMtTifExTnIBgMrZoupeUf3Qa8b28VcQo41BXB/SsUyEXFnDAVhNE510 MIME-Version: 1.0 X-Received: by 10.112.201.164 with SMTP id kb4mr9284641lbc.32.1392475388493; Sat, 15 Feb 2014 06:43:08 -0800 (PST) Received: by 10.112.21.228 with HTTP; Sat, 15 Feb 2014 06:43:08 -0800 (PST) X-Originating-IP: [85.59.141.95] In-Reply-To: <20140209190249.GG3180@nl.grid.coop> References: <20140209171214.GA20126@savin> <201402091725.42306.luke@dashjr.org> <20140209181132.GF3180@nl.grid.coop> <20140209183831.GA8878@savin> <20140209190249.GG3180@nl.grid.coop> Date: Sat, 15 Feb 2014 15:43:08 +0100 Message-ID: From: =?ISO-8859-1?Q?Jorge_Tim=F3n?= To: Troy Benjegerdes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1WEgSZ-0000Lz-6u Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Embedded consensus system upgrade procedures X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 14:43:17 -0000 Not a lawyer, but I don't see what would prevent me from writing contracts = like: "I owe the holder of this contract 10 usd" (IOU) "I owe the holder of this contract 10 usd in beer" (voucher) "I owe the holder of this p2p asset 10 usd in beer" (p2p voucher) Of course, there must be a legal contract outside of the chain for this contracts to be enforceable. Some p2p assets will have them and other's won't. Say Alice pays the dinner (20 usd) and her friend Bob pays her half of the price in p2p usd not legally enforceable IOUs issued by him (10 bob:USD). That's not legally enforceable, so what? If Bob doesn't pay back Alice would lose 10 usd and would not accept bob's IOUs anymore, much like it would had happen with a verbal IOU. The difference is that Alice can sell those bob:USD to other people who trust Bob. Different p2p assets have different legal needs. In any case, I think Peter summarized it very well: "[...]no amount of code can, **by itself**, make data represent a physical or legal entity. Only consensus and/or authorities in the "real world" can do that." On 2/9/14, Troy Benjegerdes wrote: >> > 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. >> >> Standard Disclaimer: Digital asset transfer systems are fundementally >> fancy accounting systems; no amount of code can, by itself, make data >> represent a physical or legal entity. Only consensus and/or authorities >> in the "real world" can do that. Crypto-currencies are only a partial >> exception to that rule, and only because a scarce asset that can be >> transferred digitally appears to have potential to be broadly useful. > > How do I document in the embedded consensus system what the ruling in > a small-claims court about the ownership of a contested asset was? > > Good accounting systems (such as mercurial, and proper double-entry > financial accounting tools) allow reverting a bad commit, or bad data > entry, while maintaining records of the history. Not as good accounting > systems (like git) allow you to re-write history. What's the equivalent > user interface, process, and wire protocol for reversing a fraudulent > transaction while maintaining a full audit trail? > > Courts can't legislate our code, and we can't expect them to download > and trust our 'distributed de-centralized' digital asset tracking system > that will be downloaded from a single centralized developer website > unless we meet them at least halfway, and probably need to propose model > municipal and county ordinances that go along with our code releases. > >> Those considering investing in or otherwise devoting resources to the >> creation of digital asset transfer systems should be warned that their >> value in general remains unproven and losing some or all of your >> investment is very possible, even probable. I myself have doubts that >> these systems serve real-world business needs, but the only way to find >> out is to build them and see. > > I would agree 100% that we need to build them, test the code, use them, > and then *try them in court*, and make sure we can explain in very simple > plain language what an 'embedded consensus system' is to the distributed > de-centralized local court systems. > > -------------------------------------------------------------------------= ----- > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=3D121051231&iu=3D/4140/ostg= .clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --=20 Jorge Tim=F3n http://freico.in/