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-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z4Lkq-0006NV-0g for bitcoin-development@lists.sourceforge.net; Mon, 15 Jun 2015 04:12:12 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.111 as permitted sender) client-ip=62.13.148.111; envelope-from=pete@petertodd.org; helo=outmail148111.authsmtp.net; Received: from outmail148111.authsmtp.net ([62.13.148.111]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Z4Lko-000704-Jg for bitcoin-development@lists.sourceforge.net; Mon, 15 Jun 2015 04:12:11 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5F4BuDn018676; Mon, 15 Jun 2015 05:11:56 +0100 (BST) Received: from muck ([85.255.233.40]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5F4BmDO070543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 15 Jun 2015 05:11:53 +0100 (BST) Date: Mon, 15 Jun 2015 05:11:49 +0100 From: Peter Todd To: Eric Lombrozo Message-ID: <20150615041149.GA13286@muck> References: <674CED15-3F4C-4E24-BCA2-3C474CC01708@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline In-Reply-To: <674CED15-3F4C-4E24-BCA2-3C474CC01708@gmail.com> X-Server-Quench: a7df00d0-1314-11e5-b396-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdwcUEkAaAgsB AmMbW1FeUVx7XGc7 Yw9PbwBYfEhNXBtu UFdMSlVNFUssBGoF dENqLRl1dwBCezBy Z0VlWD4KWxAsdUYp QlNVFmwCeGZhPWUC AkNRcR5UcAFPdx8U a1UrBXRDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4AGTs5 ShYeBn0oGwUvZh17 dkR+Ql4B X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 85.255.233.40/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.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 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1Z4Lko-000704-Jg Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] comments on BIP 100 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: Mon, 15 Jun 2015 04:12:12 -0000 --jI8keyz6grp/JLjh Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 14, 2015 at 05:53:05PM -0700, Eric Lombrozo wrote: > I think the whole complexity talk is missing the bigger issue. >=20 > Sure, per block validation scales linearly (or quasilinearly=E2=80=A6ther= e=E2=80=99s an O(log n) term in there somewhere but it=E2=80=99s probably d= ominated by linear factors at current levels=E2=80=A6asymptotic limits don= =E2=80=99t always apply very well to finite systems). And there=E2=80=99s a= n O(n^2) bandwidth issue. >=20 > The real issue, though, is validation cost. The n in O(n) here does not r= epresent block size - it represents the size of the entire block chain for = every new validator that must be synchronized! It means we have no way to c= onstruct short proofs (or at least arguments that are computationally *hard= * to forge) without requiring the validator to maintain the complete system= state. And currently, there is no mechanism for directly compensating vali= dators. =2E..and can there be? The goal of validation after all is finding if a mistake has been made, and current production cryptography doesn't have any way to prove you have done that honestly. You need "moon math" like recursive SNARKS to do that, and it's unknown when they'll be available for production usage. When we say "compensating validators", if we're being honest with outselves what we really mean is the much more boring task of compensating servers who are giving us blockchain data. That has nothing to do with validation. A useful task would be to make an SPV archival node implementation that did no validation at all, while distributing the blockchain data linked to the longest chain. Such an implementation can and should serve SPV clients, as this is what their actual security model usually is given the lack of authentication of the identity of the server they're connecting too. Actually implementing this would be a simple matter of patching Bitcoin Core to turn off block validation. > A full validator that goes offline even for a short period of time takes = a while to fully catch up to the rest of the network - and starting up a ne= w validator from scratch will continue to be painful=E2=80=A6even for those= of us who=E2=80=99ve turned this into routine by now, let alone new nontec= hnical users. Concretely, 20MB blocks lead to 20GB/week of blocks. On my 1MB/second down internet, turning on my node after a week away would take five hours; starting up a new node after two years of 20MB blocks would take 23 days - likely longer in practice. There's serious unsolved and undiscussed devops and development issues with this. For instance, after changes to the validation code, it's routine to resync/reindex Bitcoin Core to ensure starting up a new node actually works. Even now we haven't really come to grips with what consistent 1MB blocks looks like from this point of view after a few years of usage, let another order of magnitude longer sync times. > Satoshi=E2=80=99s SPV is not a real solution - it=E2=80=99s a mere sugges= tion that wasn=E2=80=99t fully thought out at the time of the Bitcoin white= paper. Besides lacking a good validation security model, practical impleme= ntations of it weaken privacy and complicate client implementations substan= tially=E2=80=A6and the worst part, it still doesn=E2=80=99t scale all that = well. The validator still has to query every single block (even if filtered= ) back to the first transaction (which cannot be determined without doing a= blockchain scan anyway). Note how with 20MB blocks it would take up to 1TB of IO per year-synced for a bloom-filter-using wallet to sync the blockchain. We already have a bloom IO DoS attack issue - what are the consequences of making that issue 20x worse? Nobody has analysed it yet. --=20 'peter'[:-1]@petertodd.org 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 --jI8keyz6grp/JLjh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJVflCCXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAxMjdhYjFkNTc2ZGM4NTFmMzc0NDI0ZjEyNjljNDcwMGNj YWJhMmM0MmQ5N2U3NzgvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udxpmwgAj4/dftDeXs3J77oeffA//mzJ dQoTX1xsa9Sd3G9keF4QJTmvBb7iVNmRcIaF2t/O5StKfDun2gBlNTwEDm8oCvab d7l9chHZIl/Ig3pPgrW2gNZU9f0laA/aG9OGaScfW/FBsAL8hPuC7o9mznN1Ni2H monewDcP3j98uT5jwr17zYF/PM0PbRVy2Q6beLTA6fVLEA+SNSpeQ2m7lrJLHzpn UbyExAgI5F8qjAUofCL+CrEgAvoqT5mvS/YPThNg1fdui8Rhfb5nz2Fzkg8AowMh zuSsmRoCEsZyjgfI0VfNsPuqwq1Xpu4HJeJcrAHnA61VsvVRkkgKJ7CUnUvGNQ== =AP/j -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh--