Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.216.49 as permitted sender)
	client-ip=209.85.216.49; envelope-from=alex.mizrahi@gmail.com;
	helo=mail-qa0-f49.google.com; 
MIME-Version: 1.0
In-Reply-To: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>
References: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>
Date: Wed, 23 Apr 2014 18:04:00 +0300
Message-ID: <CAE28kUQ9WOnHuFR6WYeU6rep3b74zDweTPxffF0L6FjZObXE6A@mail.gmail.com>
From: Alex Mizrahi <alex.mizrahi@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a11c3dc48e47cab04f7b70a2b
Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage
	Finney attacks
Precedence: list

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

This is outright ridiculous.

Zero-confirmation double-spending is a small problem, and possible
solutions are known. (E.g. trusted third party + multi-sig addresses for
small-value transactions.)

On the other hand, protocol changes like described above might have
game-theoretical implications which are non-trivial and hard to understand.

The above approach works as long as the majority of hashpower is honest,
> defined to mean, working to stop double spending. This is the same security
> property as described in the white paper, thus this introduces no new
> security assumptions.
>

No. Bitcoin should work if miners are merely individually rational, i.e.
they try to maximize their pay-offs without colluding with others.

I guess word "honest" might have different meanings, that can be a source
of confusing.
1. Honest -- not trying to destroy bitcoin
2. Honest -- following rules which are not required by the protocol

--001a11c3dc48e47cab04f7b70a2b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">This is outright ridiculous.<div><br></div><div>Zero-confi=
rmation double-spending is a small problem, and possible solutions are know=
n. (E.g. trusted third party + multi-sig addresses for small-value transact=
ions.)</div>
<div><br></div><div>On the other hand, protocol changes like described abov=
e might have game-theoretical implications which are non-trivial and hard t=
o understand.</div><div><br></div><div class=3D"gmail_extra"><div class=3D"=
gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>The above approach wor=
ks as long as the majority of hashpower is honest, defined to mean, working=
 to stop double spending. This is the same security property as described i=
n the white paper, thus this introduces no new security assumptions.</div>
</div></blockquote><div><br></div><div>No. Bitcoin should work if miners ar=
e merely individually rational, i.e. they try to maximize their pay-offs wi=
thout colluding with others.</div><div><br></div><div>I guess word &quot;ho=
nest&quot; might have different meanings, that can be a source of confusing=
.</div>
<div>1. Honest -- not trying to destroy bitcoin</div><div>2. Honest -- foll=
owing rules which are not required by the protocol</div><div><br></div><div=
><br></div></div></div></div>

--001a11c3dc48e47cab04f7b70a2b--