From: Troy Benjegerdes <hozer@hozed•org>
To: Peter Todd <pete@petertodd•org>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Embedded consensus system upgrade procedures
Date: Sun, 9 Feb 2014 13:02:49 -0600 [thread overview]
Message-ID: <20140209190249.GG3180@nl.grid.coop> (raw)
In-Reply-To: <20140209183831.GA8878@savin>
> > 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.
next prev parent reply other threads:[~2014-02-09 19:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-09 17:12 Peter Todd
2014-02-09 17:25 ` Luke-Jr
2014-02-09 18:09 ` Peter Todd
2014-02-09 18:11 ` Troy Benjegerdes
2014-02-09 18:38 ` Peter Todd
2014-02-09 19:02 ` Troy Benjegerdes [this message]
2014-02-15 14:43 ` Jorge Timón
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=20140209190249.GG3180@nl.grid.coop \
--to=hozer@hozed$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pete@petertodd$(echo .)org \
/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