[Bitcoin-development] Embedded consensus system upgrade procedures

[Bitcoin-development] Embedded consensus system upgrade procedures

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 4110 bytes --]

The Problem
===========

We have an embedded consensus system and we want to be able to upgrade
it with new rules. There inevitably will be a transition period where
some users use clients that interpret the new rules, while others only
interpret the old rules. Since we only rely on the host consensus system
for timestamped proof-of-publication the the miner-vote soft-fork
upgrade mechanism;(1) there are no validating miners in the system to
whome trust can be outsourced.

We have a problem: messages encoding actions, such as moving as asset
from one owner to another, can be published on the the blockchain
according to new and old rules simultaneously, double-spending the
asset. Potentially a user with the old v1 software may be tricked into
accepting an asset when the consensus of the v2 software is that the
asset has already been spent, and the v1-visible transaction is invalid.


Solution
========

Split actions into a separate "decrement" and "increment" operations,
and ensure that v1 software can see the "decrement" of a balance, spend
of a transaction output etc. even if it does not see the corresponding
increment operation. This solves the double-spend problem and ensures v1
users can't be ripped off. With obvious analogy to the PoW case, we will
refer to this general principle as a embedded consensus system
soft-fork.

Note how with the Colored Coins technology this principle happens
implicitly and with miner validation: colored coins are valid
transaction outputs known to the host consensus system and moving them
from one owner to another is guaranteed to result in the desctruction of
the colored coin from the point of view of any older software version.
Older software that does not support the newer colored coin kernel
specified by the new asset definition will simply see the respective
coins be destroyed in invalid transactions. Note how this implies that
asset definitions created by issuers should be careful to ensure that
kernels chosen should be designed such that the actioned specified by
one kernel can-not be interpreted differently by another; kernels should
be clearly incompatible with each other.


Balance-based systems
=====================

Mastercoin is a balance-based system where transactions increment and
decrement balances. Being balance-based, and lacking pruning, an even
simplier "scorched earth" approach will be used where each address is
associated with a maximum version number seen by transactions signed by
the address. Addresses with a max version number higher than what the
software understands are considered to be null and have no value of any
kind. (counterparty would be wise to do the same)


Upgrading implementation
========================

Implementations should record in their databases the blockhash
associated with transactions that were not recognized yet affected the
state of the consensus. For instance a colored coin implementation
should record the blockhash and transaction ID where a given coin was
destroyed in an invalid transaction; after upgrading these "last
transaction understood" markers can be used to replay blockchain data to
arrive at the new consensus.

Similarly in the case of the Mastercoin system balances associated with
addresses that have been frozen should be still allowed to increment so
that replaying blockchain data from the last recognized transaction
arrives at a upgraded consensus.

As an aside, any embedded consensus system would be wise to have a way
of generating a master digest representing the state of the consensus in
the database. The Bitcoin Core gettxoutsetinfo command is a good model,
which provides hash_serialized, a digest representing the entire UTXO
set. In all systems this is useful for ensuring that different
implementations and instances have in fact arrived at a consensus.


1) BIP-16, Pay to Script Hash,
   https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki

-- 
'peter'[:-1]@petertodd.org
000000000000000075829f6169c79d7d5aaa20bfa8da6e9edb2393c4f8662ba0

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

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

[Luke-Jr]

On Sunday, February 09, 2014 5:12:14 PM Peter Todd wrote:
> We have an embedded consensus system and we want to be able to upgrade
> it with new rules.

This asserts a central authority and gives developers too much power.

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

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]

On Sun, Feb 09, 2014 at 05:25:41PM +0000, Luke-Jr wrote:
> On Sunday, February 09, 2014 5:12:14 PM Peter Todd wrote:
> > We have an embedded consensus system and we want to be able to upgrade
> > it with new rules.
> 
> This asserts a central authority and gives developers too much power.

Please, the rule change only can happen if users accept it.

If anything my proposed mechanism makes it even harder for developers to
impose anything by fiat: the spending your digital asset under new rules
decreases the amount available of it to trade with users who chose to
accept only the old rules. Since there is no safety concern involved,
the process is safe for both groups, developers can't plea to the
community that "OMG the sky will fall and you'll be all defrauded if you
don't upgrade right now!!!" Instead they'll be forced to make it clear
that if the community doesn't accept the new rules, whatever assets
you've moved to the new system may become forever worthless.

-- 
'peter'[:-1]@petertodd.org
000000000000000075829f6169c79d7d5aaa20bfa8da6e9edb2393c4f8662ba0

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

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

[Troy Benjegerdes]

On Sun, Feb 09, 2014 at 05:25:41PM +0000, Luke-Jr wrote:
> On Sunday, February 09, 2014 5:12:14 PM Peter Todd wrote:
> > We have an embedded consensus system and we want to be able to upgrade
> > it with new rules.
> 
> This asserts a central authority and gives developers too much power.

I don't quite see how, There is nothing that 'forces' me to upgrade,
unless I have chosen to run an operating system (MacOS, Windows, Android)
that have automatic don't-ask-the-user update mechanisms.

The bigger problem with 'asset transfer' of assets which do not exist 
soley in the blockchain is including the consensus of relevant local and
distributed legal jurisdictions.

For example, just because the 'colored coin' and blockchain consensus is
that I 'electronically' signed a mortgage document giving some random 
internet company the rights to foreclose on my home does not mean that 
my local county Judge or Sheriff are going to do anything if the internet
company cannot produce the original paper document with ink signature.

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.

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

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2762 bytes --]

On Sun, Feb 09, 2014 at 12:11:32PM -0600, Troy Benjegerdes wrote:
> On Sun, Feb 09, 2014 at 05:25:41PM +0000, Luke-Jr wrote:
> > On Sunday, February 09, 2014 5:12:14 PM Peter Todd wrote:
> > > We have an embedded consensus system and we want to be able to upgrade
> > > it with new rules.
> > 
> > This asserts a central authority and gives developers too much power.
> 
> I don't quite see how, There is nothing that 'forces' me to upgrade,
> unless I have chosen to run an operating system (MacOS, Windows, Android)
> that have automatic don't-ask-the-user update mechanisms.
> 
> The bigger problem with 'asset transfer' of assets which do not exist 
> soley in the blockchain is including the consensus of relevant local and
> distributed legal jurisdictions.
> 
> For example, just because the 'colored coin' and blockchain consensus is
> that I 'electronically' signed a mortgage document giving some random 
> internet company the rights to foreclose on my home does not mean that 
> my local county Judge or Sheriff are going to do anything if the internet
> company cannot produce the original paper document with ink signature.
> 
> 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.

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.

Peter Todd
Chief Scientist
Mastercoin


Anyway, the best we can do is build good tools. Dwelling on the
underlying metaphysical nature of what those tools may or may not do
from a social perspective is frankly off-topic on this email list.

-- 
'peter'[:-1]@petertodd.org
000000000000000075829f6169c79d7d5aaa20bfa8da6e9edb2393c4f8662ba0

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

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

[Troy Benjegerdes]

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

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

[Jorge Timón]

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/