Troy Benjegerdes [ARCHIVE] on Nostr: 📅 Original date posted:2014-02-09 📝 Original message:> > The only 'assertion' ...
📅 Original date posted:2014-02-09
📝 Original message:> > 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.
📝 Original message:> > 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.