1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <hozer@grid.coop>) id 1WCZef-0008ID-8M
for bitcoin-development@lists.sourceforge.net;
Sun, 09 Feb 2014 19:03:01 +0000
X-ACL-Warn:
Received: from nl.grid.coop ([50.7.166.116])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1WCZea-0007HO-Qt for bitcoin-development@lists.sourceforge.net;
Sun, 09 Feb 2014 19:03:01 +0000
Received: from localhost (localhost [127.0.0.1]) (uid 1000)
by nl.grid.coop with local; Sun, 09 Feb 2014 13:02:49 -0600
id 000000000006A340.0000000052F7D0D9.000062C2
Date: Sun, 9 Feb 2014 13:02:49 -0600
From: Troy Benjegerdes <hozer@hozed.org>
To: Peter Todd <pete@petertodd.org>
Message-ID: <20140209190249.GG3180@nl.grid.coop>
References: <20140209171214.GA20126@savin> <201402091725.42306.luke@dashjr.org>
<20140209181132.GF3180@nl.grid.coop> <20140209183831.GA8878@savin>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <20140209183831.GA8878@savin>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1WCZea-0007HO-Qt
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: <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: Sun, 09 Feb 2014 19:03:01 -0000
> > 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.
|
