{"type":"rich","version":"1.0","author_name":"npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krq","author_url":"https://nostr.ae/npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krq","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-07-30\n📝 Original message:I usually avoid troll-infested Dunning-Kruger-gone-wild fests like reddit, so I’ll leave that to others.\n\nBut I do want to clarify a couple things here, though, Andrew.\n\nFirst 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:\n\n- Regardless of what that X is, it isn’t 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’s 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’s 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’t seem very many people in this space quite grasp this paradigm shift yet.\n\n- 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…and 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.\n\n\n\u003e On Jul 29, 2015, at 9:51 PM, Andrew LeCody via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e tl;dr\n\u003e $100 worth of hardware and $1/mo of expenses, should be able to run a full\n\u003e Bitcoin node until 2020 with BIP101-size blocks.\n\u003e \n\u003e ----\n\u003e \n\u003e I got into Bitcoin in the summer of 2010. I'm not a cryptographer, up until\n\u003e recently my profession has been as a server administrator or systems\n\u003e engineer.\n\u003e \n\u003e I'd like to take a second to address the concern that larger blocks would\n\u003e make it harder to run a full node on limited hardware and would therefore\n\u003e hurt decentralization. I run two nodes today, one on server-grade hardware\n\u003e at a datacenter and another on a mini-ITX Atom (dual core) system at my\n\u003e home.\n\u003e \n\u003e I detailed the operational costs of my home node today on reddit:\n\u003e https://www.reddit.com/r/Bitcoin/comments/3f0h8e/mike_h_shuts_down_eric_ls_attempt_to_rewrite/ctkigpr\n\u003e \n\u003e If I was a new user, wanting to run a full node. The most cost effective\n\u003e way would likely be with a Raspberry Pi 2 and a 2TB external HDD. Total\n\u003e cost about $100, including charger, microSD card, etc. That is less than\n\u003e the cost of a TREZOR hardware wallet. As far as home projects go, not\n\u003e terribly expensive.\n\u003e \n\u003e Next, it will need power. According to the Wikipedia article, the rpi 2\n\u003e model B uses 3.5 watts of power max. The 2TB external drive will draw about\n\u003e 5 watts at max. That's a total of 8.5 watts or 6.205 Kwh per month. In my\n\u003e area (North Texas) power is about $0.10/Kwh, which means my little node\n\u003e costs $0.62 per month in power.\n\u003e \n\u003e Last, lets look at bandwidth. It's difficult to quantify bandwidth cost in\n\u003e the same way because this is a home connection, mainly because I don't know\n\u003e how to price in the loss of enjoyment if the system impacts my Internet\n\u003e usage to a noticeable degree. Luckily, I have some real world data from my\n\u003e existing home node. Here is the last month:\n\u003e http://imgur.com/YmJwQpN\n\u003e \n\u003e This system averages 120 Kbps in and 544 Kbps out. Note, this data is\n\u003e somewhat skewed, because the system is also used for seeding torrents of\n\u003e various open source projects. The Bitcoin node itself is typically\n\u003e connected to about 20 peers at any given time (maxconnections=20).\n\u003e \n\u003e Subjectively, my wife and I have never noticed any degradation of\n\u003e performance due to my home server using too much bandwidth. I think it's\n\u003e safe to say that I can treat the bandwidth is uses as effectively free,\n\u003e since it's piggybacking on a connection I would be paying for even if I was\n\u003e not running a Bitcoin node. The bandwidth usage of this Bitcoin node could\n\u003e increase significantly, without any noticeable impact. If it did, I could\n\u003e always lower maxconnections back to 8.\n\u003e \n\u003e The only real constraint seems to be hard drive space, as the full\n\u003e blockchain and indexes take up about 50GB of space currently. If BIP101 is\n\u003e implemented, 2TB of storage should be enough for me to continue running my\n\u003e hypothetical $100 node until about 2020.\n\u003e \n\u003e It seems to me that at least for the next 5 years, the \"small devices\" of\n\u003e today can easily run Bitcoin nodes with BIP101-size blocks, with very\n\u003e little operational cost.\n\u003e \n\u003e If anyone would like more detailed data on my existing nodes, please let me\n\u003e know and I'll attempt to provide it (so long as it doesn't impact my\n\u003e privacy of course).\n\u003e \n\u003e On Wed, Jul 29, 2015 at 10:49 PM Adam Back via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e\u003e I dont think people consider other blockchains as a competitive\n\u003e\u003e threat.  A PoW-blockchain is a largely singleton data structure for\n\u003e\u003e security reasons (single highest hashrate), it is hard for an\n\u003e\u003e alternative chain to bootstrap or provide meaningful security.\n\u003e\u003e Secondly the world largely lacks expertise to maintain a blockchain to\n\u003e\u003e bitcoin's security level, perhaps you can see a hint of this in the\n\u003e\u003e recently disclosed security vulnerability by Pieter Wuille and Gregory\n\u003e\u003e Maxwell.  Calls to this as an argument are not resonating and probably\n\u003e\u003e not helping your argument.  Bitcoin has security properties, and a\n\u003e\u003e competing system cant achieve better properties by bypassing security,\n\u003e\u003e any blockchain faces the same fundamental security / decentralisation\n\u003e\u003e limitations.\n\u003e\u003e \n\u003e\u003e Secondly Bitcoin can obviously compete with itself with different\n\u003e\u003e parameters and defacto *does* today.  I think it is a safe estimate\n\u003e\u003e that \u003e 99% of Bitcoin transactions right now are happening in Bitcoin\n\u003e\u003e related systems with various degrees of audit, reconciliation,\n\u003e\u003e provable reserves etc.  I think we can expect this to continue and\n\u003e\u003e become more secure via more reconciliation, and longer term via\n\u003e\u003e lightning or Bitcoin sidechains with different parameters.  It is a\n\u003e\u003e different story to have a single central system (Bitcoin with\n\u003e\u003e parameters changed to the point of centralisation failure) vs having\n\u003e\u003e multiple choices, because some transactions can more easily use\n\u003e\u003e relatively centralised systems (eg micropayments), and more\n\u003e\u003e interestingly the combination of a secure and decentralised layer 1\n\u003e\u003e plus choices of less decentralised layer 2 options, can be interesting\n\u003e\u003e because the layer 2 is provided cover from attack.  There is less to\n\u003e\u003e be gained by attacking relatively centralised layer 2 because any\n\u003e\u003e payments at risk of policy abuse (which is typically a small subset)\n\u003e\u003e can easily switch to layer 1.  That in itself makes layer 2\n\u003e\u003e transactions also less susceptible to policy abuse.  Further lightning\n\u003e\u003e it appears from work so far should add significant scale while\n\u003e\u003e retaining trustlessness and a good degree of decentralisation.\n\u003e\u003e \n\u003e\u003e Finally you seem to be focusing on \"artificial\" limits where that is\n\u003e\u003e not the issue under consideration.  The limits are technical and\n\u003e\u003e relating to decentralisation and security.  I wont go over them again\n\u003e\u003e as this topic has been covered many times in recent months.  Any chain\n\u003e\u003e that tried to go to extreme parameters (very low block intervals, or\n\u003e\u003e very large blocksizes) would have the same decentralisation problems\n\u003e\u003e as Bitcoin would if it did the same thing.  There are a number of alt\n\u003e\u003e coins that have failed as a result of poor parameter choices, there\n\u003e\u003e are inherent security limits.\n\u003e\u003e \n\u003e\u003e Adam\n\u003e\u003e \n\u003e\u003e ps Etiquette note for yourself and others: please dont be repetitive\n\u003e\u003e or attempt to be forceful.  Many people have spent many years\n\u003e\u003e understanding this very complex system, from my own experience it is\n\u003e\u003e rare indeed to think of an entirely new concept or analysis, that\n\u003e\u003e hasnt' been long considered and put to bed 3 or 4 years ago.\n\u003e\u003e Thoughtful polite and constructive comments are welcome but I\n\u003e\u003e recommend to not start from an assumption that you have a clear and\n\u003e\u003e better insight than the entire technical community, because I have to\n\u003e\u003e say from my own experience that is very rarely the case.  It can be\n\u003e\u003e useful to test theories on #bitcoin IRC channel to find out what has\n\u003e\u003e been already concluded, find the references and avoid having to have\n\u003e\u003e that hashed out on this list which is trying to be focussed on\n\u003e\u003e technical solutions.\n\u003e\u003e \n\u003e\u003e \n\u003e\u003e On 29 July 2015 at 16:10, Raystonn . via bitcoin-dev\n\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e\u003e Cheapest way to send value? Is this what Bitcoin is trying to do? So\n\u003e\u003e\u003e\u003e all of the smart contract, programmable money, consensus coding and\n\u003e\u003e\u003e\u003e tremendous developer effort is bent to the consumer demand for cheaper\n\u003e\u003e\u003e\u003e fees. Surely thou jests!\n\u003e\u003e\u003e \n\u003e\u003e\u003e \n\u003e\u003e\u003e These other features can be replicated into any alternative blockchain,\n\u003e\u003e\u003e including those with lower fees.  In the open-source world of\n\u003e\u003e\u003e cryptocurrency, no feature will remain a value-add for very long after it\n\u003e\u003e\u003e has been identified to be such.  Anything adding value will quickly be\n\u003e\u003e\u003e absorbed into competing alternative blockchains.  That will leave\n\u003e\u003e economic\n\u003e\u003e\u003e policy as the distinguishing factor.\n\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e ... it is not the case ... that reluctance to concede\n\u003e\u003e\u003e\u003e blocksize is an attempt to constrain capacity. Greg Maxwell thoroughly\n\u003e\u003e\u003e\u003e explained in this thread that the protocol's current state of\n\u003e\u003e\u003e\u003e development relies on  blocksize for security and, ultimately, as a\n\u003e\u003e\u003e\u003e means of protecting its degree of decentralization.\n\u003e\u003e\u003e \n\u003e\u003e\u003e \n\u003e\u003e\u003e A slow or lack of increase to maximum transaction rate will cause\n\u003e\u003e pressure\n\u003e\u003e\u003e on fees.  Whether this is the desired goal is not relevant.  Everyone has\n\u003e\u003e\u003e agreed this will be the outcome.  As to a smaller block size being needed\n\u003e\u003e\u003e for additional decentralization, one must simply ask how much we are all\n\u003e\u003e\u003e willing to pay for that additional decentralization.  It is likely that\n\u003e\u003e the\n\u003e\u003e\u003e benefit thereto will have to be demonstrated by some power attacking and\n\u003e\u003e\u003e destroying a less decentralized currency before the benefit of this\n\u003e\u003e feature\n\u003e\u003e\u003e is given monetary value by the market.  Until then, value will bleed to\n\u003e\u003e the\n\u003e\u003e\u003e network with the least friction, because it will have the greatest\n\u003e\u003e ability\n\u003e\u003e\u003e to grow its network effect.  That means the blockchain with adequate\n\u003e\u003e\u003e features and cheapest fees will eventually have the largest market share.\n\u003e\u003e\u003e \n\u003e\u003e\u003e \n\u003e\u003e\u003e -----Original Message----- From: Venzen Khaosan\n\u003e\u003e\u003e Sent: Wednesday, July 29, 2015 3:11 PM\n\u003e\u003e\u003e To: Raystonn .\n\u003e\u003e\u003e Cc: bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure\n\u003e\u003e\u003e isn'ttemporary\n\u003e\u003e\u003e \n\u003e\u003e\u003e -----BEGIN PGP SIGNED MESSAGE-----\n\u003e\u003e\u003e Hash: SHA1\n\u003e\u003e\u003e \n\u003e\u003e\u003e Raystonn, I'm aware that you're addressing your question to Greg\n\u003e\u003e\u003e Maxwell, however a point you keep stating as fact calls for reference:\n\u003e\u003e\u003e \n\u003e\u003e\u003e On 07/30/2015 04:28 AM, Raystonn . via bitcoin-dev wrote:\n\u003e\u003e\u003e [snip]\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e How do you plan to address the bleeding of value from Bitcoin to\n\u003e\u003e\u003e\u003e alternative lower-fee blockchains created by the artificially-high\n\u003e\u003e\u003e\u003e bitcoin transaction fees when users begin looking for the cheapest\n\u003e\u003e\u003e\u003e way to send value?\n\u003e\u003e\u003e \n\u003e\u003e\u003e Cheapest way to send value? Is this what Bitcoin is trying to do? So\n\u003e\u003e\u003e all of the smart contract, programmable money, consensus coding and\n\u003e\u003e\u003e tremendous developer effort is bent to the consumer demand for cheaper\n\u003e\u003e\u003e fees. Surely thou jests!\n\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e Modern economic study has shown that liquidity moves to the\n\u003e\u003e\u003e\u003e location of least friction.\n\u003e\u003e\u003e \n\u003e\u003e\u003e Modern economic study? Can you please provide a link or reference to\n\u003e\u003e\u003e the study you are referring to.\n\u003e\u003e\u003e \n\u003e\u003e\u003e \"liquidity moves to the location of least friction\"\n\u003e\u003e\u003e \n\u003e\u003e\u003e This sounds like \"econo-speak\" and makes no sense. The definition of\n\u003e\u003e\u003e Liquidity is the degree to which an asset/security can be bought or\n\u003e\u003e\u003e sold in the market without affecting the price.\n\u003e\u003e\u003e \n\u003e\u003e\u003e That is why bitcoin is said to have low liquidity: buying or selling\n\u003e\u003e\u003e only 100 BTC visibly affects the exchange price. You probably mean\n\u003e\u003e\u003e \"people like cheap fees\", which is true, but as others have said,\n\u003e\u003e\u003e because of Bitcoin's powerful features, they are willing to pay higher\n\u003e\u003e\u003e fees and wait longer for transactions to execute.\n\u003e\u003e\u003e \n\u003e\u003e\u003e As for your public cross-examination of Greg Maxwell, your case seems\n\u003e\u003e\u003e to  be made on the assumption that limiting the size of the blockchain\n\u003e\u003e\u003e is an attempt to artificially raise tx fees, but it is not the case\n\u003e\u003e\u003e (as you and others repeatedly argue) that reluctance to concede\n\u003e\u003e\u003e blocksize is an attempt to constrain capacity. Greg Maxwell thoroughly\n\u003e\u003e\u003e explained in this thread that the protocol's current state of\n\u003e\u003e\u003e development relies on  blocksize for security and, ultimately, as a\n\u003e\u003e\u003e means of protecting its degree of decentralization.\n\u003e\u003e\u003e \n\u003e\u003e\u003e Surely, this is an obvious concern even for those who are campaigning\n\u003e\u003e\u003e for the hare-brained ideal of making Bitcoin a \"faster, cheaper\n\u003e\u003e\u003e alternative\" to visa or paypal? If we lose decentralization, we lose\n\u003e\u003e\u003e the whole thing, right? Incorrect or correct?\n\u003e\u003e\u003e -----BEGIN PGP SIGNATURE-----\n\u003e\u003e\u003e Version: GnuPG v1\n\u003e\u003e\u003e \n\u003e\u003e\u003e iQEcBAEBAgAGBQJVuU+rAAoJEGwAhlQc8H1m9nkH/00xXJ53H4qvHjPrdNRniwvB\n\u003e\u003e\u003e RXi96QjbnVj/fxU2J2TBPYF1LxJ13avyL58bbaJF7GKqcpoYNZArCKLQyGaZGCTp\n\u003e\u003e\u003e h7Oe/0S+b1QCrvxcVK8Ikeb7a1h9wnhAPf1FvAWoJ1cFGx/qGHetKqx1dQTWkVWz\n\u003e\u003e\u003e Mp17vjaofmp2OhBzh0Smj+wV9hXn9w9giZKc6UGvC0Qc7Rf3GL/YVJzM2CZNvlLS\n\u003e\u003e\u003e YhQSqnnqduugYztqLV/NvNExF41zC2IMyNmA41q46v/nh8stNSIcJleD39csNMfx\n\u003e\u003e\u003e BXjrlnPfZ+JI4RhiH3I0qjOYWPtBH9od788DY509EOn3MT4vU+EVcQaxyuFqZyw=\n\u003e\u003e\u003e =lQvy\n\u003e\u003e\u003e -----END PGP SIGNATURE-----\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e \n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 842 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150730/e5b0540c/attachment.sig\u003e"}