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 1WdEYS-00036O-Iq for bitcoin-development@lists.sourceforge.net; Thu, 24 Apr 2014 07:58:48 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.50 as permitted sender) client-ip=209.85.219.50; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f50.google.com; Received: from mail-oa0-f50.google.com ([209.85.219.50]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WdEYR-0003je-GG for bitcoin-development@lists.sourceforge.net; Thu, 24 Apr 2014 07:58:48 +0000 Received: by mail-oa0-f50.google.com with SMTP id i11so2231995oag.23 for ; Thu, 24 Apr 2014 00:58:42 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.28.195 with SMTP id d3mr240907obh.19.1398326322138; Thu, 24 Apr 2014 00:58:42 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.96.180 with HTTP; Thu, 24 Apr 2014 00:58:42 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 Apr 2014 09:58:42 +0200 X-Google-Sender-Auth: 7YD1iPWWiGDXurPtKuc6Afq0BBA Message-ID: From: Mike Hearn To: Alex Mizrahi Content-Type: multipart/alternative; boundary=001a11c2cd18b6323a04f7c537d2 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: 1WdEYR-0003je-GG 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: Thu, 24 Apr 2014 07:58:48 -0000 --001a11c2cd18b6323a04f7c537d2 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 24, 2014 at 12:06 AM, Alex Mizrahi wrote: > > Different approaches have different trade-offs, and thus different areas > of applicability. > > Proof-of-work's inherent disadvantage is that it takes some time until > transaction becomes practically irreversible. On the other hand, it has > advantages like neutrality, censorship-resistance, high degree of security, > etc. > Sure, they have different tradeoffs. My assertion is this: the costs and disadvantages that come with building what is in effect an entirely parallel and separate system for stopping double spends, are much much worse than making simple tweaks to strengthen the mechanism we already have. Put another way, the cost/benefit ratio of this proposal seems much better to me than the alternatives. > In this case you get benefits of both approaches. > You also get the costs of both approaches, which are extremely significant. Censorship-resistance is irrelevant when one buys a cup of coffee with his > pocket money, isn't it? That's like saying banks can't censor you because you can always withdraw all your money in cash. But in practice: 1. That's a huge pain in the ass so nobody does it 2. Many merchants will refuse non-trivial payments in cash and demand bank money because it's simpler for them Analogously, having to wait some large expiry period to extract your money from the "double spending prevention service" (a.k.a. bitbank) is a pain in the ass, and many merchants would refuse to take your newly double spendable money even if theoretically they could, because it keeps their operations much simpler if they can just assume a sale is final and can't be reversed. So I think such a scheme would rapidly return to the a world that looks much like the one we have now. > For some reason, instead of considering these hybrid solutions (which can > also address scalability problems), you want to make PoW-based system more > complex to be applicable for real-time transaction too. > The complexity overhead is trivial - we already used coinbase scriptSigs for voting on P2SH, I'm sure it'll be used for voting on other things in future too. So that's already in place. Counting up votes and editing the UTXO set is the sort of patch one guy can create, it's not very big. And it's conceptually just the same as what miners can do today by re-orging out blocks, but with much less impact on end users and less implementation complexity (no giant reorgs that might themselves have to split recursively whilst they're being built). On the other hand, building an entirely separate system, with separate trusted companies that have trusted brand names, adding support to all the wallets, getting all sellers on board, making everything use an extended BIP 70 (as that's the only real way to implement it), trying to explain to users why they're now expected to pay extra fees when they previously didn't and then discovering that you got a choice of only a handful of double-spend-preventers everyone could agree on with little potential for more .... that's hugely complex and messy. > This will, likely, weaken advantages provided by PoW > Why? Remember deleting coinbases with nothing more than a simple majority is already possible in the existing protocol and always has been. --001a11c2cd18b6323a04f7c537d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 24, 2014 at 12:06 AM, Alex Mizrahi <alex.mizrahi@gmail.com> wrote:
Different approaches have different trade-offs, and thus different areas o= f applicability.

Proof-of-work's inherent disadvantage is that= it takes some time until transaction becomes practically irreversible. On = the other hand, it has advantages like neutrality, censorship-resistance, h= igh degree of security, etc.


Put another way, the cost/benefit ratio of this proposa= l seems much better to me than the alternatives.
=C2=A0
=
In this case you get benefits of both approaches.

You also get the costs of both appr= oaches, which are extremely significant.

=C2=A0Censorship-resistance is irrelevant when one buys a cup of coffee wit= h his pocket money, isn't it?

That'= s like saying banks can't censor you because you can always withdraw al= l your money in cash. But in practice:
  1. That's a huge pain in the ass so nobody does it
  2. Ma= ny merchants will refuse non-trivial payments in cash and demand bank money= because it's simpler for them
Analogously, having to wai= t some large expiry period to extract your money from the "double spen= ding prevention service" (a.k.a. bitbank) is a pain in the ass, and ma= ny merchants would refuse to take your newly double spendable money even if= theoretically they could, because it keeps their operations much simpler i= f they can just assume a sale is final and can't be reversed.

So I think such a scheme would rapidly return to = the a world that looks much like the one we have now.
=C2=A0
For some reason, instead of considering these hybrid solutions = (which can also address scalability problems), you want to make PoW-based s= ystem more complex to be applicable for real-time transaction too.

The complexity ove= rhead is trivial - we already used coinbase scriptSigs for voting on P2SH, = I'm sure it'll be used for voting on other things in future too. So= that's already in place. Counting up votes and editing the UTXO set is= the sort of patch one guy can create, it's not very big. And it's = conceptually just the same as what miners can do today by re-orging out blo= cks, but with much less impact on end users and less implementation complex= ity (no giant reorgs that might themselves have to split recursively whilst= they're being built).

On the other hand, building an entirely separate system= , with separate trusted companies that have trusted brand names, adding sup= port to all the wallets, getting all sellers on board, making everything us= e an extended BIP 70 (as that's the only real way to implement it), try= ing to explain to users why they're now expected to pay extra fees when= they previously didn't and then discovering that you got a choice of o= nly a handful of double-spend-preventers everyone could agree on with littl= e potential for more .... that's hugely complex and messy.
=C2=A0
This will, likely, weaken advantages provided by PoW
=

Why? Remember deleting coinbases wit= h nothing more than a simple majority is already possible in the existing p= rotocol and always has been.=C2=A0
--001a11c2cd18b6323a04f7c537d2--