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 864C5FF for ; Thu, 30 Jul 2015 08:21:07 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 668A98D for ; Thu, 30 Jul 2015 08:21:06 +0000 (UTC) Received: by pdbnt7 with SMTP id nt7so20684037pdb.0 for ; Thu, 30 Jul 2015 01:21:06 -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=i2qtKS/f1iggfje5rccLIhcEv4t7sp8IqYPM0kzm5Ho=; b=kwInZRcO3cq+lEI2+r1UehNP69nFNZZFz3DA7zJIgqBXSARzvZNgoEJDHxR5cdBBBq YLEA7UKpNBiEFUIMLzoDw6GPDq0xDa1uXCE0iLdItPh9kCys2+qI8+z0uBhARMkbq+WO 6u5Xyui71wAwU3zJMZD86Wfoi3nGJHQqsmkANQ+osENt+6Pgv2O2f7j8g7ocTvOO+yCn VGYE7a6tJ6vcLTGP2fG5J+msxbkd7rBz/AyVNxpxOiNdeByqwpjDjWZLezbl9CP9M3Cm D+16I22mX8d9yiQqnWw7f5SnnvLILujb8JP7VMdJwjLKk0JEPwikrgxtm7gIGJih0Hcg RshA== X-Received: by 10.70.103.98 with SMTP id fv2mr83164518pdb.9.1438244466117; Thu, 30 Jul 2015 01:21:06 -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 v3sm755654pdp.8.2015.07.30.01.21.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Jul 2015 01:21:04 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_92CCBEA4-6237-4C46-9A6B-65935BBCC262"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Eric Lombrozo In-Reply-To: Date: Thu, 30 Jul 2015 01:21:02 -0700 Message-Id: <74767203-7F7A-4848-9923-DE1DE60A28B4@gmail.com> References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com> <37D282C2-EF9C-4B8B-91E8-7D613B381824@phauna.org> <55B94FAD.7040205@mail.bihthai.net> 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 08:21:07 -0000 --Apple-Mail=_92CCBEA4-6237-4C46-9A6B-65935BBCC262 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I usually avoid troll-infested Dunning-Kruger-gone-wild fests like = reddit, so I=E2=80=99ll leave that to others. But I do want to clarify a couple things here, though, Andrew. 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: - 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. - 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. > 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 --Apple-Mail=_92CCBEA4-6237-4C46-9A6B-65935BBCC262 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 iQIcBAEBCgAGBQJVud5uAAoJEJNAI64YFENUz/cQALrf9GmKH3pHTc8nLfqYxlNq I2fnHEbVp7MdbXj0gLITBfXbajghrSNTeLaIVkV0h9wiRytUdIBEh/6nHtoMo4GL 0qlHuteapyeXYKyy2cWUw4GTEcNGM2X4AcBJzyj6h7ouJw+OaiXmTxe1ArrXZfea 9Rx63RBbXLeYY3w2lqw+JA/hmPnEr60IJhCYuXjq5MPGjK0+ms6MeryLj14aC1ut LxXVBCEUOAv4WziCrNl4Co6QOLY+GFlXV0GoOmF1cY1xJiX/gd2suLZs1bJFsGyR 6VdXfTX7ccYxwebGjI3cBfo6zNAPWIfS9XgO5g1QwlEtrX1Y4NnT9hOO1KwfvENi /5IGOWZKtm1aYS00CgQClhTyQ4cs9esI032gN6G4Wj4QmtjbtLdH1QEMl+VGoXcg NT73fCDEvnSJVJGL7OosVIKOGZlgywfDnY1P6LbOzpnIK1n0EPSxxZXmshxsPoD8 9VxesunM6mX8zZInNayW+YATLBKYV0VvCJKc81qisOtqBCzGBgzjt9zh6RaoSUHh X5+7L6pLhAKatDNyM11mAS+Yvw7QKcic7qfs1FBxYdZ3VWMw1p8WEssqmzvDG9XT w4nkphYBkIcfw9zDUx3aWCqDJzyeRlRA48/gSTGlzl0UsTHT3U80kuCGV6xLKjAt yTUH24tuy9Wx7ZZ/iW6z =zED1 -----END PGP SIGNATURE----- --Apple-Mail=_92CCBEA4-6237-4C46-9A6B-65935BBCC262--