Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wd48t-0004Mb-7Z for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 20:51:43 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.43 as permitted sender) client-ip=209.85.219.43; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f43.google.com; Received: from mail-oa0-f43.google.com ([209.85.219.43]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wd48s-0005Zu-D5 for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 20:51:43 +0000 Received: by mail-oa0-f43.google.com with SMTP id eb12so1651231oac.2 for ; Wed, 23 Apr 2014 13:51:37 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.132.236 with SMTP id ox12mr2413479oeb.81.1398286297038; Wed, 23 Apr 2014 13:51:37 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.96.180 with HTTP; Wed, 23 Apr 2014 13:51:36 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 Apr 2014 22:51:36 +0200 X-Google-Sender-Auth: iGZrvBtOxsjMJb1ZotjYc8cJ9P4 Message-ID: From: Mike Hearn To: Adam Ritter Content-Type: multipart/alternative; boundary=047d7b41cd280786b204f7bbe61b 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: 1Wd48s-0005Zu-D5 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 20:51:43 -0000 --047d7b41cd280786b204f7bbe61b Content-Type: text/plain; charset=UTF-8 On Wed, Apr 23, 2014 at 10:44 PM, Adam Ritter wrote: > Isn't a faster blockchain for transactions (maybe as a sidechain) solving > the problem? If there would be a safe way for 0-confirmation transactions, > the Bitcoin blockchain wouldn't even be needed. > The 10 minute average comes from a desire to balance wasted work due to natural chain splits with latency. With a very fast block interval you end up with lots of forks and things take longer to converge, also, it can make attacks easier because an attacker is building on his own blocks so he doesn't suffer propagation delays and the attendant splits. It's not clear you can just make a faster block chain. 10 minutes is somewhat arbitrary, it could be 5 minutes and the system would still work, but it probably can't be 5 seconds. Unfortunately for best physical-world usability you really need very fast payments. A few seconds is competitive with modern credit cards. The new contactless cards seem to be able to reliably manage <1 sec which is impressive. Waiting for blocks in a block chain can't really work. Waiting for propagation can work and has been working so far. Hence, the question of how that mechanism can be kept working in the face of malicious miners, before you end up having to fall back to trusted third parties and recentralisation. --047d7b41cd280786b204f7bbe61b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 23, 2014 at 10:44 PM, Adam Ritter <aritter@gmail.com> wrote:
Isn't a faster blockcha= in for transactions (maybe as a sidechain) solving the problem? If there wo= uld be a safe way for 0-confirmation transactions, the Bitcoin blockchain w= ouldn't even be needed.

The 10 minute average comes from a desire = to balance wasted work due to natural chain splits with latency. With a ver= y fast block interval you end up with lots of forks and things take longer = to converge, also, it can make attacks easier because an attacker is buildi= ng on his own blocks so he doesn't suffer propagation delays and the at= tendant splits.

It's not clear you can just make a faster block cha= in. 10 minutes is somewhat arbitrary, it could be 5 minutes and the system = would still work, but it probably can't be 5 seconds.=C2=A0
<= br>
Unfortunately for best physical-world usability you really need = very fast payments. A few seconds is competitive with modern credit cards. = The new contactless cards seem to be able to reliably manage <1 sec whic= h is impressive. Waiting for blocks in a block chain can't really work.= Waiting for propagation can work and has been working so far. Hence, the q= uestion of how that mechanism can be kept working in the face of malicious = miners, before you end up having to fall back to trusted third parties and = recentralisation.
--047d7b41cd280786b204f7bbe61b--