diff options
| author | Eric Lombrozo <elombrozo@gmail.com> | 2015-07-30 01:21:02 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-07-30 08:21:07 +0000 |
| commit | f99632629aa33f10756ba8fcd976fa7e58e5bb5a (patch) | |
| tree | 6960ba7db09e1019263bc5a4696b71bfaa638b81 | |
| parent | 14efbb5aaa22f3defe9ebc982147ae350d0c93dc (diff) | |
| download | pi-bitcoindev-f99632629aa33f10756ba8fcd976fa7e58e5bb5a.tar.gz pi-bitcoindev-f99632629aa33f10756ba8fcd976fa7e58e5bb5a.zip | |
Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
| -rw-r--r-- | 76/18cc7146425b29a388dcff5ff443e064a34b08 | 456 |
1 files changed, 456 insertions, 0 deletions
diff --git a/76/18cc7146425b29a388dcff5ff443e064a34b08 b/76/18cc7146425b29a388dcff5ff443e064a34b08 new file mode 100644 index 000000000..859f598ae --- /dev/null +++ b/76/18cc7146425b29a388dcff5ff443e064a34b08 @@ -0,0 +1,456 @@ +Return-Path: <elombrozo@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 864C5FF + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 30 Jul 2015 08:21:06 +0000 (UTC) +Received: by pdbnt7 with SMTP id nt7so20684037pdb.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <elombrozo@gmail.com> +In-Reply-To: <CAEX2NSc6FXsDLEpRq7YOxQErpBxS7tW8Afk-T9VUyeb2qS2brQ@mail.gmail.com> +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> + <CA+w+GKTfPXkVPaCC+3ZsQv=_DPMHoRwbigS40Testpyq4rZxsw@mail.gmail.com> + <D25BD175-7099-4A6B-89BB-A35E94F555A9@gmail.com> + <CA+w+GKTZV5sgXNU_xoBby1_X6eae=5_vhENmyKY0yxWHcBiU5g@mail.gmail.com> + <37D282C2-EF9C-4B8B-91E8-7D613B381824@phauna.org> + <CAAS2fgSaRqxi3X0J3F05nA-tyRRikY1whkpAOuGJJpFSAR017w@mail.gmail.com> + <COL131-DS222F0D512C6A5B47BF62C2CD8C0@phx.gbl> + <55B94FAD.7040205@mail.bihthai.net> + <COL131-DS95F86B1D5B93CE1275911CD8C0@phx.gbl> + <CALqxMTEUAtNxkYMQwA9g9xH_LiX98yYOooGjUho1T3fMY2J5jQ@mail.gmail.com> + <CAEX2NSc6FXsDLEpRq7YOxQErpBxS7tW8Afk-T9VUyeb2qS2brQ@mail.gmail.com> +To: Andrew LeCody <andrewlecody@gmail.com> +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 <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 = +<bitcoin-dev@lists.linuxfoundation.org> 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 +>> <bitcoin-dev@lists.linuxfoundation.org> 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-- + |