Re: [Bitcoin-development] Embedded consensus system upgrade procedures

[Troy Benjegerdes <hozer@hozed.org>]

> > 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.