From: "Jorge Timón" <jtimon@monetize•io>
To: Troy Benjegerdes <hozer@hozed•org>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Embedded consensus system upgrade procedures
Date: Sat, 15 Feb 2014 15:43:08 +0100 [thread overview]
Message-ID: <CAC1+kJNnK0qAT+gY98GKgcXkUjVeZUL3Uj3LRHq8a+JPCxZCtw@mail.gmail.com> (raw)
In-Reply-To: <20140209190249.GG3180@nl.grid.coop>
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 <hozer@hozed•org> 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=121051231&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jorge Timón
http://freico.in/
prev parent reply other threads:[~2014-02-15 14:43 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
2014-02-15 14:43 ` Jorge Timón [this message]
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=CAC1+kJNnK0qAT+gY98GKgcXkUjVeZUL3Uj3LRHq8a+JPCxZCtw@mail.gmail.com \
--to=jtimon@monetize$(echo .)io \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=hozer@hozed$(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