From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9EE4F273 for ; Thu, 30 Jul 2015 09:15:30 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7151C10A for ; Thu, 30 Jul 2015 09:15:29 +0000 (UTC) Received: by pacan13 with SMTP id an13so20899608pac.1 for ; Thu, 30 Jul 2015 02:15:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=UvBI35AKyyVJstZXyGHBPEw54JkBLqU+Esck/C1aDAg=; b=STTVOvIyZp8iPkLtPZemREcoDxneE2rSiXl1/xJVSFKujNP1pSOLnv+2JL9nZaPy7r 5Zv/PuQBTmYoAhzd9e5x8WoZeqH5VeRw2mgTJI5MHSg1uqcTbu/NLr5jFJZ9nWolZL0S fF6weLhqoi4jThHyA+CIQBQGeRjM/H8zhfMeoaizMfpUp/Jm7WqQRm1GAPMBqgLqXE2+ I6rH6fmDyJxNFLtllCh2PiKPU4ACOTO3+oFJdEjLMTrwUQCFy60GYqPhG/4MjmfBFoIU RL2SpzyniUP5rzhhF12ssX3+CyVE18757aoEAfnGYFLQYSmXTFrfn3+XsOG6aSqqzTuQ SyXA== X-Received: by 10.66.66.166 with SMTP id g6mr105590077pat.157.1438247728935; Thu, 30 Jul 2015 02:15:28 -0700 (PDT) Received: from [192.168.1.107] (cpe-76-167-237-202.san.res.rr.com. [76.167.237.202]) by smtp.gmail.com with ESMTPSA id o7sm1033403pdi.16.2015.07.30.02.15.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Jul 2015 02:15:28 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9BF7F32D-4F3C-4FD9-9362-DA431332B06D"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Eric Lombrozo In-Reply-To: <74767203-7F7A-4848-9923-DE1DE60A28B4@gmail.com> Date: Thu, 30 Jul 2015 02:15:25 -0700 Message-Id: <4452AA7F-020C-4457-AAA0-0F6871C22458@gmail.com> References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com> <37D282C2-EF9C-4B8B-91E8-7D613B381824@phauna.org> <55B94FAD.7040205@mail.bihthai.net> <74767203-7F7A-4848-9923-DE1DE60A28B4@gmail.com> To: Andrew LeCody X-Mailer: Apple Mail (2.2098) X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 09:15:30 -0000 --Apple-Mail=_9BF7F32D-4F3C-4FD9-9362-DA431332B06D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 30, 2015, at 1:21 AM, Eric Lombrozo = wrote: >=20 > I usually avoid troll-infested Dunning-Kruger-gone-wild fests like = reddit, so I=E2=80=99ll leave that to others. >=20 > But I do want to clarify a couple things here, though, Andrew. >=20 > First of all, the issue is not about whether it is affordable for a = highly motivated, technically skilled person to continue running a node = even if we increase block size by a factor of X. This misses the point = for at least a couple reasons: >=20 > - Regardless of what that X is, it isn=E2=80=99t really going to be = what makes this technology accessible to the masses. We would likely = need the X to be in the thousands before we start to really take on = players like Visa. Despite what people might have thought in 2009, it = turns out Bitcoin is probably pretty ill-suited as a database in which = to store the entire transaction history of the entire world. It=E2=80=99s = looking to be more of a censorship-resistant dispute resolution = mechanism that provides very well-defined settlement guarantees with the = potential for encoding complex rules. It=E2=80=99s possible to build = higher level tiers on top of it that DO support high volume transaction = processing WITHOUT costing thousands of times more, and these approaches = are looking quite promising. However, it doesn=E2=80=99t seem very many = people in this space quite grasp this paradigm shift yet. >=20 > - What matters is not how a relatively small number of = well-intentioned people in the network behave. What matters is how the = network behaves as a whole=E2=80=A6and a number of the people most = intimately familiar with the inner workings of the system (some of whom = are in this thread) think that given what we now today about the Bitcoin = network, increasing block size externalizes costs in dangerous ways. = Remember that total cost includes not just equipment costs but also = things like block propagation latency and specifically identified = security risks. Some of these security risks were only appreciated = relatively recently and were completely unknown in 2009. >=20 Secondly, there are a few well-identified problems with the protocol = design that might be possible to fix that would perhaps allow us to = remove the block size limit entirely without sacrificing security. I = listed the ones that come to my mind at the beginning of this thread. I = EMPHATICALLY state that in no way am I fundamentally opposed to raising = or even getting rid of the block size limit. But I believe these = problems should be addressed first. And it=E2=80=99s easier to address = them and tackle them if we don=E2=80=99t have to worry about potential = security risks and higher costs that come from insisting on bigger = blocks right now. - Eric >> On Jul 29, 2015, at 9:51 PM, Andrew LeCody via bitcoin-dev = wrote: >>=20 >> tl;dr >> $100 worth of hardware and $1/mo of expenses, should be able to run a = full >> Bitcoin node until 2020 with BIP101-size blocks. >>=20 >> ---- >>=20 >> I got into Bitcoin in the summer of 2010. I'm not a cryptographer, up = until >> recently my profession has been as a server administrator or systems >> engineer. >>=20 >> I'd like to take a second to address the concern that larger blocks = would >> make it harder to run a full node on limited hardware and would = therefore >> hurt decentralization. I run two nodes today, one on server-grade = hardware >> at a datacenter and another on a mini-ITX Atom (dual core) system at = my >> home. >>=20 >> I detailed the operational costs of my home node today on reddit: >> = https://www.reddit.com/r/Bitcoin/comments/3f0h8e/mike_h_shuts_down_eric_ls= _attempt_to_rewrite/ctkigpr >>=20 >> If I was a new user, wanting to run a full node. The most cost = effective >> way would likely be with a Raspberry Pi 2 and a 2TB external HDD. = Total >> cost about $100, including charger, microSD card, etc. That is less = than >> the cost of a TREZOR hardware wallet. As far as home projects go, not >> terribly expensive. >>=20 >> Next, it will need power. According to the Wikipedia article, the rpi = 2 >> model B uses 3.5 watts of power max. The 2TB external drive will draw = about >> 5 watts at max. That's a total of 8.5 watts or 6.205 Kwh per month. = In my >> area (North Texas) power is about $0.10/Kwh, which means my little = node >> costs $0.62 per month in power. >>=20 >> Last, lets look at bandwidth. It's difficult to quantify bandwidth = cost in >> the same way because this is a home connection, mainly because I = don't know >> how to price in the loss of enjoyment if the system impacts my = Internet >> usage to a noticeable degree. Luckily, I have some real world data = from my >> existing home node. Here is the last month: >> http://imgur.com/YmJwQpN >>=20 >> This system averages 120 Kbps in and 544 Kbps out. Note, this data is >> somewhat skewed, because the system is also used for seeding torrents = of >> various open source projects. The Bitcoin node itself is typically >> connected to about 20 peers at any given time (maxconnections=3D20). >>=20 >> Subjectively, my wife and I have never noticed any degradation of >> performance due to my home server using too much bandwidth. I think = it's >> safe to say that I can treat the bandwidth is uses as effectively = free, >> since it's piggybacking on a connection I would be paying for even if = I was >> not running a Bitcoin node. The bandwidth usage of this Bitcoin node = could >> increase significantly, without any noticeable impact. If it did, I = could >> always lower maxconnections back to 8. >>=20 >> The only real constraint seems to be hard drive space, as the full >> blockchain and indexes take up about 50GB of space currently. If = BIP101 is >> implemented, 2TB of storage should be enough for me to continue = running my >> hypothetical $100 node until about 2020. >>=20 >> It seems to me that at least for the next 5 years, the "small = devices" of >> today can easily run Bitcoin nodes with BIP101-size blocks, with very >> little operational cost. >>=20 >> If anyone would like more detailed data on my existing nodes, please = let me >> know and I'll attempt to provide it (so long as it doesn't impact my >> privacy of course). >>=20 >> On Wed, Jul 29, 2015 at 10:49 PM Adam Back via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >>=20 >>> I dont think people consider other blockchains as a competitive >>> threat. A PoW-blockchain is a largely singleton data structure for >>> security reasons (single highest hashrate), it is hard for an >>> alternative chain to bootstrap or provide meaningful security. >>> Secondly the world largely lacks expertise to maintain a blockchain = to >>> bitcoin's security level, perhaps you can see a hint of this in the >>> recently disclosed security vulnerability by Pieter Wuille and = Gregory >>> Maxwell. Calls to this as an argument are not resonating and = probably >>> not helping your argument. Bitcoin has security properties, and a >>> competing system cant achieve better properties by bypassing = security, >>> any blockchain faces the same fundamental security / = decentralisation >>> limitations. >>>=20 >>> Secondly Bitcoin can obviously compete with itself with different >>> parameters and defacto *does* today. I think it is a safe estimate >>> that > 99% of Bitcoin transactions right now are happening in = Bitcoin >>> related systems with various degrees of audit, reconciliation, >>> provable reserves etc. I think we can expect this to continue and >>> become more secure via more reconciliation, and longer term via >>> lightning or Bitcoin sidechains with different parameters. It is a >>> different story to have a single central system (Bitcoin with >>> parameters changed to the point of centralisation failure) vs having >>> multiple choices, because some transactions can more easily use >>> relatively centralised systems (eg micropayments), and more >>> interestingly the combination of a secure and decentralised layer 1 >>> plus choices of less decentralised layer 2 options, can be = interesting >>> because the layer 2 is provided cover from attack. There is less to >>> be gained by attacking relatively centralised layer 2 because any >>> payments at risk of policy abuse (which is typically a small subset) >>> can easily switch to layer 1. That in itself makes layer 2 >>> transactions also less susceptible to policy abuse. Further = lightning >>> it appears from work so far should add significant scale while >>> retaining trustlessness and a good degree of decentralisation. >>>=20 >>> Finally you seem to be focusing on "artificial" limits where that is >>> not the issue under consideration. The limits are technical and >>> relating to decentralisation and security. I wont go over them = again >>> as this topic has been covered many times in recent months. Any = chain >>> that tried to go to extreme parameters (very low block intervals, or >>> very large blocksizes) would have the same decentralisation problems >>> as Bitcoin would if it did the same thing. There are a number of = alt >>> coins that have failed as a result of poor parameter choices, there >>> are inherent security limits. >>>=20 >>> Adam >>>=20 >>> ps Etiquette note for yourself and others: please dont be repetitive >>> or attempt to be forceful. Many people have spent many years >>> understanding this very complex system, from my own experience it is >>> rare indeed to think of an entirely new concept or analysis, that >>> hasnt' been long considered and put to bed 3 or 4 years ago. >>> Thoughtful polite and constructive comments are welcome but I >>> recommend to not start from an assumption that you have a clear and >>> better insight than the entire technical community, because I have = to >>> say from my own experience that is very rarely the case. It can be >>> useful to test theories on #bitcoin IRC channel to find out what has >>> been already concluded, find the references and avoid having to have >>> that hashed out on this list which is trying to be focussed on >>> technical solutions. >>>=20 >>>=20 >>> On 29 July 2015 at 16:10, Raystonn . via bitcoin-dev >>> wrote: >>>>> Cheapest way to send value? Is this what Bitcoin is trying to do? = So >>>>> all of the smart contract, programmable money, consensus coding = and >>>>> tremendous developer effort is bent to the consumer demand for = cheaper >>>>> fees. Surely thou jests! >>>>=20 >>>>=20 >>>> These other features can be replicated into any alternative = blockchain, >>>> including those with lower fees. In the open-source world of >>>> cryptocurrency, no feature will remain a value-add for very long = after it >>>> has been identified to be such. Anything adding value will quickly = be >>>> absorbed into competing alternative blockchains. That will leave >>> economic >>>> policy as the distinguishing factor. >>>>=20 >>>>> ... it is not the case ... that reluctance to concede >>>>> blocksize is an attempt to constrain capacity. Greg Maxwell = thoroughly >>>>> explained in this thread that the protocol's current state of >>>>> development relies on blocksize for security and, ultimately, as = a >>>>> means of protecting its degree of decentralization. >>>>=20 >>>>=20 >>>> A slow or lack of increase to maximum transaction rate will cause >>> pressure >>>> on fees. Whether this is the desired goal is not relevant. = Everyone has >>>> agreed this will be the outcome. As to a smaller block size being = needed >>>> for additional decentralization, one must simply ask how much we = are all >>>> willing to pay for that additional decentralization. It is likely = that >>> the >>>> benefit thereto will have to be demonstrated by some power = attacking and >>>> destroying a less decentralized currency before the benefit of this >>> feature >>>> is given monetary value by the market. Until then, value will = bleed to >>> the >>>> network with the least friction, because it will have the greatest >>> ability >>>> to grow its network effect. That means the blockchain with = adequate >>>> features and cheapest fees will eventually have the largest market = share. >>>>=20 >>>>=20 >>>> -----Original Message----- From: Venzen Khaosan >>>> Sent: Wednesday, July 29, 2015 3:11 PM >>>> To: Raystonn . >>>> Cc: bitcoin-dev@lists.linuxfoundation.org >>>> Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam = measure >>>> isn'ttemporary >>>>=20 >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>>=20 >>>> Raystonn, I'm aware that you're addressing your question to Greg >>>> Maxwell, however a point you keep stating as fact calls for = reference: >>>>=20 >>>> On 07/30/2015 04:28 AM, Raystonn . via bitcoin-dev wrote: >>>> [snip] >>>>>=20 >>>>> How do you plan to address the bleeding of value from Bitcoin to >>>>> alternative lower-fee blockchains created by the artificially-high >>>>> bitcoin transaction fees when users begin looking for the cheapest >>>>> way to send value? >>>>=20 >>>> Cheapest way to send value? Is this what Bitcoin is trying to do? = So >>>> all of the smart contract, programmable money, consensus coding and >>>> tremendous developer effort is bent to the consumer demand for = cheaper >>>> fees. Surely thou jests! >>>>=20 >>>>> Modern economic study has shown that liquidity moves to the >>>>> location of least friction. >>>>=20 >>>> Modern economic study? Can you please provide a link or reference = to >>>> the study you are referring to. >>>>=20 >>>> "liquidity moves to the location of least friction" >>>>=20 >>>> This sounds like "econo-speak" and makes no sense. The definition = of >>>> Liquidity is the degree to which an asset/security can be bought or >>>> sold in the market without affecting the price. >>>>=20 >>>> That is why bitcoin is said to have low liquidity: buying or = selling >>>> only 100 BTC visibly affects the exchange price. You probably mean >>>> "people like cheap fees", which is true, but as others have said, >>>> because of Bitcoin's powerful features, they are willing to pay = higher >>>> fees and wait longer for transactions to execute. >>>>=20 >>>> As for your public cross-examination of Greg Maxwell, your case = seems >>>> to be made on the assumption that limiting the size of the = blockchain >>>> is an attempt to artificially raise tx fees, but it is not the case >>>> (as you and others repeatedly argue) that reluctance to concede >>>> blocksize is an attempt to constrain capacity. Greg Maxwell = thoroughly >>>> explained in this thread that the protocol's current state of >>>> development relies on blocksize for security and, ultimately, as a >>>> means of protecting its degree of decentralization. >>>>=20 >>>> Surely, this is an obvious concern even for those who are = campaigning >>>> for the hare-brained ideal of making Bitcoin a "faster, cheaper >>>> alternative" to visa or paypal? If we lose decentralization, we = lose >>>> the whole thing, right? Incorrect or correct? >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v1 >>>>=20 >>>> iQEcBAEBAgAGBQJVuU+rAAoJEGwAhlQc8H1m9nkH/00xXJ53H4qvHjPrdNRniwvB >>>> RXi96QjbnVj/fxU2J2TBPYF1LxJ13avyL58bbaJF7GKqcpoYNZArCKLQyGaZGCTp >>>> h7Oe/0S+b1QCrvxcVK8Ikeb7a1h9wnhAPf1FvAWoJ1cFGx/qGHetKqx1dQTWkVWz >>>> Mp17vjaofmp2OhBzh0Smj+wV9hXn9w9giZKc6UGvC0Qc7Rf3GL/YVJzM2CZNvlLS >>>> YhQSqnnqduugYztqLV/NvNExF41zC2IMyNmA41q46v/nh8stNSIcJleD39csNMfx >>>> BXjrlnPfZ+JI4RhiH3I0qjOYWPtBH9od788DY509EOn3MT4vU+EVcQaxyuFqZyw=3D >>>> =3DlQvy >>>> -----END PGP SIGNATURE----- >>>> _______________________________________________ >>>> bitcoin-dev mailing list >>>> bitcoin-dev@lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>=20 >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >=20 --Apple-Mail=_9BF7F32D-4F3C-4FD9-9362-DA431332B06D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVuestAAoJEJNAI64YFENUCPgP/0AX4iCM3QKBzili7R2PdwN9 sB0o2HIxpvqTF/ZAD9MHZOOnuOrJ4giLhWmFKyiFCcsfZk500aI1KGbq/aMH6gKk J5z1tOyapAi/8E3ca5M5YnyuxLJJ6nxPXR/ip8r/LIwAHgkCgG2dJMogp7Wnvz4D CRl2WRUfARGBs8CHhO1xCROVuMsdmNy/sTUp8jec7q0o4IOoq7n+R2AqsfF7T/ii WrjxVMz1Ei1Bm65BOI6FLMPDgatp/ZpM8TWdF6IlTZYIthq8wZdD2sEVTs0Kq2xT 3t4nJfdjuFNu7ua9KjckhyniNplZiVcIdDAaUEIrO0hJP/mYLpUgpLr9xpyv5pvN bsj1WyJsZEeba6hrrXHj3Zsaojr8cHhSJB/yDXzKJcJrjeSFYHb3vimheElWFoJ7 jFwByqsWWOW/WJFZ5RkudmIwtXn/dp2Fvz9kFW5JbsEpnqjo7/X9e2adPpGSR/08 CsN0Za6+f3V8QVgJUIvF2gDvvbWuRZx+hU/Z/Wr3vV0m3QGMnv2qvBgG5MDL4wXk klAYS5NCo7VhZ0z4hkaICUnuKNaoMp+EGPwjYmOJXsAgWsx2ah9CSTWSDinjvYrF tIpfdNVvER9Mo2xJ7ECKOxZMa7e3oRxKrzd/J5/3I37dBsoNTaDg5N325k0Jrp7v Ms4F/RQnlhArwBUpABFX =oYYH -----END PGP SIGNATURE----- --Apple-Mail=_9BF7F32D-4F3C-4FD9-9362-DA431332B06D--