path: root/44/91c2a733e0ddb0345948d65093630c30d934d6

Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <daniel.krawisz@thingobjectentity.net>)
	id 1Wd4U0-0005nx-FB for bitcoin-development@lists.sourceforge.net;
	Wed, 23 Apr 2014 21:13:32 +0000
X-ACL-Warn: 
Received: from mail-yh0-f44.google.com ([209.85.213.44])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Wd4Tx-0001sE-7a
	for bitcoin-development@lists.sourceforge.net;
	Wed, 23 Apr 2014 21:13:32 +0000
Received: by mail-yh0-f44.google.com with SMTP id f10so1449452yha.31
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 23 Apr 2014 14:13:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type;
	bh=bJiG22We18rznDFGgCtlDJcATEIsydBhCJEBv5XtnwU=;
	b=Qi5bFekUWUxEdSVCp/X9VxMOPHOyIfxc9uP0FaqrzYAcYv0SUSt+y6EHXXMHKs2S2C
	m1nzj8YeE+7GQq0zMZOlmplFRKPrmnEe4XMji6+hRR9msfKHj9iT9eWUCv092PFyBS8y
	jAhAm66jGY7JSqZMymW1UpFJ2cXjFl5RJg+csWbi40G4q/LFDraoUe2PVherwPM1hAN+
	oQM75HV7TChyuKKDc/16PiBMOdyYYOcjTozmvC7sKksXKRTSbijRZi+KH0J6mMRg4bPf
	iUnG+hACCjfLRG1ZkWq5dKSjTxgoP7yRPMM78GjIfYb2Dr7EbBpxNcOrk39n93wjj93d
	P9fQ==
X-Gm-Message-State: ALoCoQlRE+866UTf4e4vi3yvuDSi71eqAsCQxF8oIVq1kVcgSsTI1XqWcWogHKgmweC/sbd9JQRo
X-Received: by 10.236.83.66 with SMTP id p42mr14895225yhe.122.1398285750078;
	Wed, 23 Apr 2014 13:42:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.170.55.199 with HTTP; Wed, 23 Apr 2014 13:41:50 -0700 (PDT)
In-Reply-To: <CANEZrP0fUhiFeH4A1Y9sLCORpggJs3dxHz+exgpKaLQe9rgFeA@mail.gmail.com>
References: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>
	<CAAS2fgTS65b0mfJakEA5s3xJHuWU2BDW8MbEVgMFMNz8YAmEiA@mail.gmail.com>
	<CANEZrP15DDdfT+o5jVKMO=tGTvHYx53yzhXfaVyzq7imfwJsZQ@mail.gmail.com>
	<CAAS2fgTJpFQKeVTQsAeqe0UK-2XhrLZG4oocEHM11_spWLtrEA@mail.gmail.com>
	<CANEZrP0fUhiFeH4A1Y9sLCORpggJs3dxHz+exgpKaLQe9rgFeA@mail.gmail.com>
From: Daniel Krawisz <daniel.krawisz@thingobjectentity.net>
Date: Wed, 23 Apr 2014 15:41:50 -0500
Message-ID: <CA+nkog349i3VQMUW_JmxX29-tOvzprtT6vcjFayNJgRt0vSCtg@mail.gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=90e6ba47613b6dc46804f7bbc556
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1Wd4Tx-0001sE-7a
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: Wed, 23 Apr 2014 21:13:32 -0000

--90e6ba47613b6dc46804f7bbc556
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The memory pool is just talk. There is no expectation that the memory pool
has to satisfy some standard as to what will eventually exist in the block
chain, and there are any number of ways that people could communicate
transactions to one another without putting them in the memory pool. The
memory pool can't be treated like a contract because there is no
cryptography to enforce it--there is no contract until the transactions
appear in the block chain, inherently.

Mike Hearn's proposal is nonsense because it requires miners to develop a
concensus on which blocks in the block chain are dishonest. There is no way
to prove cryptographically that a block is dishonest because the block
chain itself is the concensus system--before there is concensus, there is
no concept of dishonesty, at least as far as double-spending goes. In order
to decide that a block is dishonest and reallocate the coinbase, a prior
consensus mechanism would be required. Of course, such a consensus
mechanism would also be subject to attacks just like the block chain.

Maxwell's proposal is very good. One only trusts the oscar not to double
spend, which is perfectly reasonable if oscar is a well-known service.
Normal everyday wallets for immediate payments would simply require a
little more infrastructure.

Daniel Krawisz


On Wed, Apr 23, 2014 at 2:59 PM, Mike Hearn <mike@plan99.net> wrote:

> What you're talking about is just disagreement about the content of
>>  the memory pool
>>
>
> That's the same thing. Whilst you're mining your double spend tx, it's in
> your mempool but you don't broadcast it as per normal. Then when you find
> the block you broadcast it to override everyone elses mempool. So yours a=
nd
> theirs were inconsistent.
>
> The only slight way BitUndo differs is, they provide it as a service, and
> I don't know if they inform you when they found a block (probably not), s=
o
> you have to do the purchase and then hope BitUndo finds the next block.
> Otherwise the purchase clears. But they could certainly add a
> pre-notification before they broadcast to get back to the exact scheme
> originally described, they have everything else in place.
>
>
>> Oscar himself can be implemented as a majority M parties to further
>> increase confidence
>
>
> This just brings us back to square one. Who are these parties and what if
> I pay them to be corrupt? What if they offer to be corrupt as a service?
>
>  Let's say I succeed in finding some parties who are incorruptible no
> matter how large of a percentage I offer them. At this point, why bother
> with miners at all? Why pay for double spend protection twice, once to a
> group of Oscar's who are trustworthy and once to a group of miners who ar=
e
> not?
>
> The point of the broadcast network and mining is so there can be lots of
> Oscar's and I don't have to know who they are or sign up with them or put
> any effort into evaluating their reputation.
>
>
>> value retail transactions=E2=80=94 the fact that any cheating by oscar i=
s
>> cryptographically provable (just show them the double signatures)
>> maybe be strong enough alone.
>>
>
> But as you point out, cheating my GHash.io did not result in any obvious
> negative consequence to them, despite that preventing double spending is
> their sole task. Why would Oscar be different to GHash.io?
>
> Trying to solve the problem of dishonest miners is effectively trying to
> solve the "automatically find trusted third parties" problem at scale.
>
>
> -------------------------------------------------------------------------=
-----
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

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

<div dir=3D"ltr"><div>The memory pool is just talk. There is no expectation=
 that the memory pool has to satisfy some standard as to what will eventual=
ly exist in the block chain, and there are any number of ways that people c=
ould communicate transactions to one another without putting them in the me=
mory pool. The memory pool can&#39;t be treated like a contract because the=
re is no cryptography to enforce it--there is no contract until the transac=
tions appear in the block chain, inherently. <br>

<br>Mike Hearn&#39;s proposal is nonsense because it requires miners to dev=
elop a concensus on which blocks in the block chain are dishonest. There is=
 no way to prove cryptographically that a block is dishonest because the bl=
ock chain itself is the concensus system--before there is concensus, there =
is no concept of dishonesty, at least as far as double-spending goes. In or=
der to decide that a block is dishonest and reallocate the coinbase, a prio=
r consensus mechanism would be required. Of course, such a consensus mechan=
ism would also be subject to attacks just like the block chain. <br>

<br></div><div>Maxwell&#39;s proposal is very good. One only trusts the osc=
ar not to double spend, which is perfectly reasonable if oscar is a well-kn=
own service. Normal everyday wallets for immediate payments would simply re=
quire a little more infrastructure. <br>

</div><div><div>
<div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr">Daniel K=
rawisz</div></div>
<br><br><div class=3D"gmail_quote">On Wed, Apr 23, 2014 at 2:59 PM, Mike He=
arn <span dir=3D"ltr">&lt;<a href=3D"mailto:mike@plan99.net" target=3D"_bla=
nk">mike@plan99.net</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>


<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div>What you&#39;re talking about is just =
disagreement about the content of<br>



</div>
the memory pool<br></blockquote><div><br></div></div><div>That&#39;s the sa=
me thing. Whilst you&#39;re mining your double spend tx, it&#39;s in your m=
empool but you don&#39;t broadcast it as per normal. Then when you find the=
 block you broadcast it to override everyone elses mempool. So yours and th=
eirs were inconsistent.</div>



<div><br></div><div>The only slight way BitUndo differs is, they provide it=
 as a service, and I don&#39;t know if they inform you when they found a bl=
ock (probably not), so you have to do the purchase and then hope BitUndo fi=
nds the next block. Otherwise the purchase clears. But they could certainly=
 add a pre-notification before they broadcast to get back to the exact sche=
me originally described, they have everything else in place.</div>


<div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Oscar himself can be implemented as a majority M parties to further<br=
></div>
increase confidence</blockquote><div><br></div></div><div>This just brings =
us back to square one. Who are these parties and what if I pay them to be c=
orrupt? What if they offer to be corrupt as a service?</div><div><br></div>


<div>
Let&#39;s say I succeed in finding some parties who are incorruptible no ma=
tter how large of a percentage I offer them. At this point, why bother with=
 miners at all? Why pay for double spend protection twice, once to a group =
of Oscar&#39;s who are trustworthy and once to a group of miners who are no=
t?</div>



<div><br></div><div>The point of the broadcast network and mining is so the=
re can be lots of Oscar&#39;s and I don&#39;t have to know who they are or =
sign up with them or put any effort into evaluating their reputation.</div>


<div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">value retail transactions=
=E2=80=94 the fact that any cheating by oscar is<br>
cryptographically provable (just show them the double signatures)<br>
maybe be strong enough alone.<br></blockquote><div><br></div></div><div>But=
 as you point out, cheating my GHash.io did not result in any obvious negat=
ive consequence to them, despite that preventing double spending is their s=
ole task. Why would Oscar be different to GHash.io?</div>



<div><br></div><div>Trying to solve the problem of dishonest miners is effe=
ctively trying to solve the &quot;automatically find trusted third parties&=
quot; problem at scale.</div></div></div></div>
<br>-----------------------------------------------------------------------=
-------<br>
Start Your Social Network Today - Download eXo Platform<br>
Build your Enterprise Intranet with eXo Platform Software<br>
Java Based Open Source Intranet - Social, Extensible, Cloud Ready<br>
Get Started Now And Turn Your Intranet Into A Collaboration Platform<br>
<a href=3D"http://p.sf.net/sfu/ExoPlatform" target=3D"_blank">http://p.sf.n=
et/sfu/ExoPlatform</a><br>_______________________________________________<b=
r>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div></div></div></div>

--90e6ba47613b6dc46804f7bbc556--