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 ) 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 ; 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: References: From: Daniel Krawisz Date: Wed, 23 Apr 2014 15:41:50 -0500 Message-ID: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
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'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.

Mike Hearn'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.

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

Daniel K= rawisz


On Wed, Apr 23, 2014 at 2:59 PM, Mike He= arn <mike@plan99.net> wrote:
What you're talking about is just = disagreement about the content of
the memory pool

That's the sa= me thing. Whilst you're mining your double spend tx, it's in your m= empool 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 and th= eirs 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 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.
=C2=A0
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 c= orrupt? What if they offer to be corrupt as a service?

Let'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's who are trustworthy and once to a group of miners who are no= t?

The point of the broadcast network and mining is so the= re 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.
=C2=A0
value retail transactions= =E2=80=94 the fact that any cheating by oscar is
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 negat= ive consequence to them, despite that preventing double spending is their s= ole task. Why would Oscar be different to GHash.io?

Trying to solve the problem of dishonest miners is effe= ctively trying to solve the "automatically find trusted third parties&= quot; 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.n= et/sfu/ExoPlatform
_______________________________________________ Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--90e6ba47613b6dc46804f7bbc556--