From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XjzEd-0004P6-Pe for bitcoin-development@lists.sourceforge.net; Thu, 30 Oct 2014 23:34:31 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.172 as permitted sender) client-ip=209.85.213.172; envelope-from=gmaxwell@gmail.com; helo=mail-ig0-f172.google.com; Received: from mail-ig0-f172.google.com ([209.85.213.172]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XjzEc-0003SC-PN for bitcoin-development@lists.sourceforge.net; Thu, 30 Oct 2014 23:34:31 +0000 Received: by mail-ig0-f172.google.com with SMTP id a13so4326845igq.11 for ; Thu, 30 Oct 2014 16:34:25 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.31.201 with SMTP id f192mr24260428iof.41.1414712065352; Thu, 30 Oct 2014 16:34:25 -0700 (PDT) Received: by 10.107.159.3 with HTTP; Thu, 30 Oct 2014 16:34:25 -0700 (PDT) In-Reply-To: <874mul9met.fsf@rustcorp.com.au> References: <874mul9met.fsf@rustcorp.com.au> Date: Thu, 30 Oct 2014 23:34:25 +0000 Message-ID: From: Gregory Maxwell To: Rusty Russell Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.6 (-) 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 (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1XjzEc-0003SC-PN Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Increasing regularity of block times? 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, 30 Oct 2014 23:34:31 -0000 On Thu, Oct 30, 2014 at 11:18 PM, Rusty Russell wrote: > Hi all, > > I've been toying with an algorithm to place a ceiling on > confirmation latency by allowing weaker blocks after a certain time. > Hope this isn't noise, but thought someone must have considered this > before, or know of flaws in the scheme? > > Gory details: > http://rustyrussell.github.io/pettycoin/2014/10/30/More-Regular-Block-Times.html Irregularity is a required property for convergence. Imagine what would happen in a network where a blocks were produced at an exact interval: Almost everyone would produce one the exact same time, and the network would fragment and because the process would continue it would not converge. It is precisely the variance being some huge multiple of the network radius which allows the network to converge at all. When lower variance is tolerable for convergence it can be achieved by reducing the expectation. Maybe some other distribution can be proven to be convergent to, it's difficult to reason about. Bitcoin testnet implements a rule that allows lower difficulty blocks after a delay (20 minutes, in fact), but it's a testing-toy... not secure or intended to be so. At least one altcoin has copied that behavior and been exploited on account of it. If you're simply looking for faster evidence that the network is working on a particular transaction set, at some lower timescale:, then thats already possible. e.g. look into how the p2pool sharechain builds a consensus around mining work used for pooling. The same mechanism can be used to give faster transaction selection evidence. I'll dig up some citations for you later. Cheers.