From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wd3KD-0001sc-14 for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 19:59:21 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.179 as permitted sender) client-ip=209.85.214.179; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f179.google.com; Received: from mail-ob0-f179.google.com ([209.85.214.179]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wd3KC-0003PD-0t for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 19:59:20 +0000 Received: by mail-ob0-f179.google.com with SMTP id vb8so1581169obc.24 for ; Wed, 23 Apr 2014 12:59:14 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.55.65 with SMTP id q1mr3060626obp.70.1398283154582; Wed, 23 Apr 2014 12:59:14 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.96.180 with HTTP; Wed, 23 Apr 2014 12:59:14 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 Apr 2014 21:59:14 +0200 X-Google-Sender-Auth: 7XPWFSaq8KnNuFWsza1fmVb00Yo Message-ID: From: Mike Hearn To: Gregory Maxwell Content-Type: multipart/alternative; boundary=089e01538848b973bb04f7bb2aeb X-Spam-Score: -0.5 (/) 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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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: 1Wd3KC-0003PD-0t Cc: Bitcoin Dev 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 19:59:21 -0000 --089e01538848b973bb04f7bb2aeb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > 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 and 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), so 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 are 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 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 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. --089e01538848b973bb04f7bb2aeb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What you're talking about is= just disagreement about the content of
the memory pool

That's the same thi= ng. 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 and theirs w= ere 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 bac= k 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 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 yo= u point out, cheating my GHash.io did not result in any obvious negative co= nsequence to them, despite that preventing double spending is their sole ta= sk. 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.
--089e01538848b973bb04f7bb2aeb--