+Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]

+ helo=mx.sourceforge.net)

+ by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)

+ (envelope-from <gacrux@gmail.com>) id 1We1Vz-0003pO-K2

+ for bitcoin-development@lists.sourceforge.net;

+ Sat, 26 Apr 2014 12:15:31 +0000

+Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com

+ designates 209.85.223.182 as permitted sender)

+ client-ip=209.85.223.182; envelope-from=gacrux@gmail.com;

+ helo=mail-ie0-f182.google.com;

+Received: from mail-ie0-f182.google.com ([209.85.223.182])

+ by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)

+ (Exim 4.76) id 1We1Vy-0006ow-Nl

+ for bitcoin-development@lists.sourceforge.net;

+ Sat, 26 Apr 2014 12:15:31 +0000

+Received: by mail-ie0-f182.google.com with SMTP id tp5so1494044ieb.41

+ for <bitcoin-development@lists.sourceforge.net>;

+ Sat, 26 Apr 2014 05:15:25 -0700 (PDT)

+X-Received: by 10.42.23.82 with SMTP id r18mr12618367icb.43.1398514525188;

+ Sat, 26 Apr 2014 05:15:25 -0700 (PDT)

+Received: from [192.168.1.150] (60-240-212-53.tpgi.com.au. [60.240.212.53])

+ by mx.google.com with ESMTPSA id kr5sm5598943igb.9.2014.04.26.05.15.23

+ for <bitcoin-development@lists.sourceforge.net>

+ (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);

+ Sat, 26 Apr 2014 05:15:24 -0700 (PDT)

+Message-ID: <535BA357.6050607@gmail.com>

+Date: Sat, 26 Apr 2014 22:15:19 +1000

+From: Gareth Williams <gacrux@gmail.com>

+User-Agent: Mozilla/5.0 (X11; Linux x86_64;

+ rv:24.0) Gecko/20100101 Thunderbird/24.4.0

+MIME-Version: 1.0

+To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>

+References: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com> <CAE28kUQ9WOnHuFR6WYeU6rep3b74zDweTPxffF0L6FjZObXE6A@mail.gmail.com> <CANEZrP3WBWi5h04yyQ115vXmVHupoj5MG+-8sx=2zEcCT5a9hg@mail.gmail.com> <CAC1+kJNE+k4kcTj3Ap0-A=PdD1=+-k5hN4431Z99A+S7M3=BoQ@mail.gmail.com> <CANEZrP3obO9rXKcX+G7bs2dd3AqEFOsO8pCUF6orrkGeZyr9Ew@mail.gmail.com> <CAC1+kJPxwTm6qvh2GYT2XMJAPD5O4WHLOGBTRmchRmZ2wS4MSg@mail.gmail.com> <CANEZrP2PZFVvH3oJyLW80e9W_Fa4bvqQ25E7T-ZFFuG9u-q1hQ@mail.gmail.com> <5359E509.4080907@gmail.com> <CANEZrP0bKe-=T5ps0myLZjo60tv2mkm3Bw0o4e-9y7zb1h5eDg@mail.gmail.com> <535A60FE.10209@gmail.com>

+ <CANEZrP0y45eSVgbzXYmvYy1WEQNyd=tmC2EpZgGSB28poXSzDw@mail.gmail.com>

+In-Reply-To: <CANEZrP0y45eSVgbzXYmvYy1WEQNyd=tmC2EpZgGSB28poXSzDw@mail.gmail.com>

+X-Enigmail-Version: 1.6

+OpenPGP: id=378E4544

+Content-Type: multipart/signed; micalg=pgp-sha1;

+ protocol="application/pgp-signature";

+ boundary="O7chOWSpdbRDjH3BGHXGQPMNDBijLurjC"

+X-Spam-Score: -1.6 (-)

+X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.

+ See http://spamassassin.org/tag/ for more details.

+ -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for

+ sender-domain

+ 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider

+ (gacrux[at]gmail.com)

+ -0.0 SPF_PASS SPF: sender matches SPF record

+ -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from

+ author's domain

+ 0.1 DKIM_SIGNED Message has a DKIM or DK signature,

+ not necessarily valid

+ -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature

+X-Headers-End: 1We1Vy-0006ow-Nl

+Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage

+ Finney attacks

+X-BeenThere: bitcoin-development@lists.sourceforge.net

+X-Mailman-Version: 2.1.9

+Precedence: list

+List-Id: <bitcoin-development.lists.sourceforge.net>

+List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,

+ <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>

+List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>

+List-Post: <mailto:bitcoin-development@lists.sourceforge.net>

+List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>

+List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,

+ <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>

+X-List-Received-Date: Sat, 26 Apr 2014 12:15:31 -0000

+

+This is an OpenPGP/MIME signed message (RFC 4880 and 3156)

+--O7chOWSpdbRDjH3BGHXGQPMNDBijLurjC

+Content-Type: text/plain; charset=UTF-8

+Content-Transfer-Encoding: quoted-printable

+

+On 26/04/14 01:28, Mike Hearn wrote:

+> When you have a *bitcoin* TXn buried under 100 blocks you can be da=

+mn

+>=20

+> sure that money is yours - but only because the rules for interpret=

+ing

+> data in the blockchain are publicly documented and (hopefully)

+> immutable. If they're mutable then the PoW alone gives me no confid=

+ence

+> that the money is really mine, and we're left with a much less usef=

+ul

+> system. This should be more sacred than the 21m limit.

+>=20

+>=20

+> Well, I think we should avoid the term "sacred" - nothing is sacred

+> because we're not building a religion here, we're engineering a tool.

+

+Are you sure there isn't room for just a touch of "religion"? :) As you

+state below, all that protects my money from confiscation is strong

+group consensus that it's mine - "a social rule, not a mathematical one."=

+

+

+Everything ultimately balances on that. People being a little bit

+"religious" about following the protocol faithfully are the linchpin of

+Bitcoin security, not PoW.

+

+

+> Consider a world in which 1 satoshi is too valuable to represent some

+> kinds of transactions, so those transactions stop happening even though=

+

+> we all agree they're useful. The obvious solution is to change the rule=

+s

+> so there can be 210 million coins and 10x everyones UTXOs at some

+> pre-agreed flag day. We probably wouldn't phrase it like that, it's

+> easier for people to imagine what's happening if it's phrased as "addin=

+g

+> more places after the decimal point" or something, but at the protocol

+> level coins are represented using integers, so it'd have to be

+> implemented as a multiply.

+

+Agree.

+

+

+> Would this be a violation of the social contract? A violation of all

+> that is sacred? I don't think so, it'd just be sensible engineering and=

+

+> there'd be strong consensus for that exactly because 21 million /is/ so=

+

+> arbitrary. If all balances and prices multiply 100-fold overnight, no

+> wealth is reallocated which would be the /actual/ violation of the

+> social contract: we just get more resolution for setting prices.

+

+Wholeheartedly agree. "21 million" is just shorthand for the

+preservation of artificial scarcity. No rational person could argue that

+what you described violates the social contract.

+

+I do see what you're driving at - that there exists a situation where it

+would be justified to change the interpretation of data in existing block=

+s.

+

+But, please consider: if I controlled a single UTXO worth 1% of the

+total money supply before your change, the network would still recognise

+that I control a single UTXO worth 1% of the total money supply after

+your change. So you haven't really changed the interpretation of

+existing blocks at all there. It's just semantics :)

+

+Contrast this with invalidating a coinbase before maturity, which

+clearly has a very real impact. At the point the vote passes, you're ***

+sidestepping the PoW mechanism and rewriting the meaning of an existing,

+validated block ***.

+

+

+> So. The thing that protects your money from confiscation is not proof o=

+f

+> work. PoW is just a database synchronisation mechanism. The thing that

+> protects your money from confiscation is a strong group consensus that

+> theft is bad. But that's a social rule, not a mathematical rule.

+

+Agree. That's my whole point :)

+

+I recognise my security is in the hands of the users (the economic

+majority.) Tomorrow they could all decide to patch their nodes to

+reallocate my UTXOs, and there's not a damn thing I could do about it,

+PoW and private keys notwithstanding. I must simply trust that they will

+not do this.

+

+So we can have:

+1. "Neutral Bitcoin", where everyone is committed to prevention of theft

+by following a simple set of mathematical rules which treat all

+validated blocks as equal.

+Or:

+2. "Political Bitcoin", where everyone is committed to prevention of

+theft based on human judgements, and the contents of some validated

+blocks are more equal than others.

+

+I recognise that the latter allows for a lot of flexibility in combating

+fraud, but with (substantial) due respect, it isn't Bitcoin.

+

+-Gareth

+

+

+--O7chOWSpdbRDjH3BGHXGQPMNDBijLurjC

+Content-Type: application/pgp-signature; name="signature.asc"

+Content-Description: OpenPGP digital signature

+Content-Disposition: attachment; filename="signature.asc"

+

+-----BEGIN PGP SIGNATURE-----

+Version: GnuPG v1.4.11 (GNU/Linux)

+Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

+

+iQEcBAEBAgAGBQJTW6NXAAoJEEY5w2E3jkVEok0IAI8HHIGvA9UIzeDaCZtdGDAn

+8xO0rwkI/d2CFDn/imSk1daLC5/EwcG1+4cba270VTJyKVq8r4tbQpvZg4/IwQLb

+qa5Mu1W8tVwIRkQ/xbfvyskbq48+eUJ7EqE1Glr9cAdsydFaOWZWomQJjTyK1xPM

+c+fP8dIbMb0AiOoZmTJp5cN54CA9b4mVL85TAcz7E6Vf8/Y4wM3GTLA4U42J9mh1

+9Sfvfe9cylhlbFhBXJlg/7JLi3W43T0T9nQYF0qjd3petcBDoE925xLQFYPcpo9a

+kJDIk8oMYX1rOGuoCHDqALu6KFdEovQG64iQLhLoOcmJ1+/vcCa9N3ZjpTOe8MM=

+=9xfv

+-----END PGP SIGNATURE-----

+

+--O7chOWSpdbRDjH3BGHXGQPMNDBijLurjC--

+

+