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 1Z4MFZ-0007S2-Nn for bitcoin-development@lists.sourceforge.net; Mon, 15 Jun 2015 04:43:57 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.96 as permitted sender) client-ip=62.13.148.96; envelope-from=pete@petertodd.org; helo=outmail148096.authsmtp.net; Received: from outmail148096.authsmtp.net ([62.13.148.96]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Z4MFX-0002Wm-Ia for bitcoin-development@lists.sourceforge.net; Mon, 15 Jun 2015 04:43:57 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5F4hkxC013203; Mon, 15 Jun 2015 05:43:46 +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 t5F4hdsO064475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 15 Jun 2015 05:43:43 +0100 (BST) Date: Mon, 15 Jun 2015 05:43:42 +0100 From: Peter Todd To: Mike Hearn Message-ID: <20150615044342.GB13286@muck> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZoaI/ZTpAVc4A5k6" Content-Disposition: inline In-Reply-To: X-Server-Quench: 1a6aac27-1319-11e5-b396-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdwcUEkAaAgsB AmMbW1FeVF57XWc7 Yw9PbwBYfEhNXBtu UFdMSlVNFUssBGoF XkpdLRl0cwFBfTBy Z0ZjWD5aDUIrJBV/ RVNVFmwPeGZhPWUC 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: 1Z4MFX-0002Wm-Ia 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:43:57 -0000 --ZoaI/ZTpAVc4A5k6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 15, 2015 at 12:23:44AM +0200, Mike Hearn wrote: > > > > One thing that is concerning is that few in industry seem inclined to > > take any development initiatives or even integrate a library. >=20 >=20 > Um, you mean except all the people who have built more scalable wallets > over the past few years, which is the only reason anyone can even use > Bitcoin from their phone? > > Or maybe you mean initiatives like Lightning .... > except StrawPay already developed something similar to the Lightning > network (complete with a working GUI wallet) and were ignored by > Blockstream as you prefer to write your own from scratch? > > Sure, people in the industry take development initiatives. That doesn't > mean their work will be recognised on this mailing list. StrawPay hasn't published any details of their work publicly; if they wanted credit on the mailing list they should have done that. I couldn't even find any screenshots of that GUI wallet when I learned what they were doing; I went to the trouble of reaching out to them recently because I have multiple clients with a need for their technology. I'm sure we all would have appreciated and welcomed them taking the time to let us know what they were doing; it would have saved me personally a lot of time; their lack of recognition on this mailing list is both unfortunate, and a product of their actions alone. In any case, StrawPay and Lightning are complementary projects: StrawPay has limited functionality in exchange for faster deployment; Lightning has significantly more functionality in exchange for a longer deployment schedule. Both projects can and should be developed in parallel. Equally, note efforts like my own CHECKLOCKTIMEVERIFY, which will be part of StrawPay in due time. > > But it will be helpful if we expose companies to the back-pressure > > actually implied by an O(n^2) scaling protocol and don't just immediate= ly > > increase the block-size to levels that are dangerous for decentralisati= on > > security >=20 >=20 > Bitcoin does not have n-squared scaling. I really don't get where this id= ea > comes from. Computational complexity for the entire network is O(nm) where > n=3Dtransactions and m=3Dfully validating nodes. There is no fixed > relationships between those two variables. Note for instance how we're discussing what standards we need in the CryptoCurrency Security Standard for requirements for compliant companies to run full nodes for transaction verification; failure to run a full node will be considered non-compliant in much the same way that failure to secure your private keys is non-compliance. Pedantically, if you assume a diverse, decentralized ecosystem, these security standards by themselves do create fixed linear relationships between those variables, giving O(n^2) scaling. https://github.com/CryptoConsortium/CCSS/issues/15 > "Exposing the companies to back-pressure" sounds quite nice and gentle. L= et > me rephrase it to be equivalent but perhaps more direct: you mean "breaki= ng > the current software ecosystem to force people into a new, fictional syst= em > that bears little resemblance to the Bitcoin we use today, whether they > want that or not". Equally, not running full nodes bears little resemblance to the Bitcoin we use today. Either way, something must change for the number of Bitcoin users to grow. > As nothing that has been proposed so far (Lightning, merge mined chains, > extension blocks etc) has much chance of actual deployment any time soon, > that leaves raising the block size limit as the only possible path left. > Which is why there will soon be a fork that does it. I'm genuinely looking forward to a concrete fork proposal. Any ETA on when the blocksize increase code will go in Bitcoin XT? --=20 'peter'[:-1]@petertodd.org 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 --ZoaI/ZTpAVc4A5k6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJVflf7XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAxMjdhYjFkNTc2ZGM4NTFmMzc0NDI0ZjEyNjljNDcwMGNj YWJhMmM0MmQ5N2U3NzgvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udzLSgf/RSzZEwtao/tJwsnpuctzGlZl Il2McWQckGZbSU+vTaqHMecGaOgGstAiN5j1BvswZdbsm7+N9V6xWMdZoXlG+Av3 zZJRx6IDqLXNHioBi0tiPUa/gyeYPJIKRSA7R2gGeMFCwUXhxH6yDz7NEiP0Vup8 n99KNlJpUwmC/YvtwLOM0F0ZHAE2DUVXYIhlPSfDD7EYK7/ivi9XJi+aW9w4WMCk +ZAdJAo/f4uErfTRDV1+qFvtoWzoCOhpNFM8hdCwlXbifT7vNRzmLHaxn03pFNwE q3I486Qh/QVN3rmwhP3Yj9WtJ2h4XHv3oTuABu2udTABHWbfyDz79Ge+QUrsHg== =WhzY -----END PGP SIGNATURE----- --ZoaI/ZTpAVc4A5k6--