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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YtoMJ-0001gz-0D for bitcoin-development@lists.sourceforge.net; Sun, 17 May 2015 02:31:19 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.220.46 as permitted sender) client-ip=209.85.220.46; envelope-from=ryanxcharles@gmail.com; helo=mail-pa0-f46.google.com; Received: from mail-pa0-f46.google.com ([209.85.220.46]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YtoMH-0001st-EZ for bitcoin-development@lists.sourceforge.net; Sun, 17 May 2015 02:31:18 +0000 Received: by pabru16 with SMTP id ru16so90979269pab.1 for ; Sat, 16 May 2015 19:31:11 -0700 (PDT) X-Received: by 10.68.206.7 with SMTP id lk7mr31614658pbc.52.1431829871660; Sat, 16 May 2015 19:31:11 -0700 (PDT) Received: from ?IPv6:2601:9:4680:dd0:d193:4b1c:eda4:2786? ([2601:9:4680:dd0:d193:4b1c:eda4:2786]) by mx.google.com with ESMTPSA id fp3sm5931233pdb.52.2015.05.16.19.31.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 May 2015 19:31:10 -0700 (PDT) Message-ID: <5557FD6E.2050903@gmail.com> Date: Sat, 16 May 2015 19:31:10 -0700 From: "Ryan X. Charles" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Tom Harding , bitcoin-development@lists.sourceforge.net References: <5554BDC1.6070206@thinlink.com> In-Reply-To: <5554BDC1.6070206@thinlink.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Score: -1.6 (-) 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (ryanxcharles[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1YtoMH-0001st-EZ Subject: Re: [Bitcoin-development] No Bitcoin For You 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: Sun, 17 May 2015 02:31:19 -0000 I agree with this analysis. I'm not sure if we will increase 1 MB block size or not, but with a block size that small, it is all but impossible for most people on the planet to ever own even a single utxo. At 7tps, how long would it take to give 1 utxo to all of the 7 billion people currently alive? It would take 1 billion seconds, or about 32 years.[1] So for all practical purposes, at 1 MB block size, far less than 1% of people will ever be able to own even a single satoshi. Unless those people are willing to wait around 30 years for their lightning network to settle, they will either not use bitcoin, or they will use a substitute (such as a parallel decentralized network, or a centralized service) that lacks the full trust-minimized security guarantees of the main bitcoin blockchain. I can't speak for most people, but for me personally, the thing I care most about as an individual (besides being able to send bitcoin to and from anyone on the planet) is being able to validate the blockchain. With a pruning node, this means I need to download the blockchain one time (not store it), and maintain the utxo set. The utxo set is, roughly speaking, 30 bytes per utxo, and therefore, at one utxo per person, about 7*30 billion bytes, or 210 GB. That's very achievable on the hardware of today. Of course, some individuals or companies will have far more than one utxo. Estimating an average of ten utxos per person, that will be 2.1 TB. Also very achievable on the hardware of today. I don't think every transaction in the world should be on the blockchain, but I think it should be able to handle (long-term) enough transactions that everyone can have their transactions settled on a timescale suitable for human life. 30 years is unsuitable, but 1 day would be pretty good. It would be great if I could send trillions of transactions per day on networks built on top of bitcoin, and have my transactions settle on the actual blockchain once per day. This means we would need to support about 1 utxo per person per day, or 7 billion transactions per day. That translates to about 81 thousand transactions per second [2], or approximately 10,000 times the current rate. That would be 10 GB per ten minutes, which is achievable on current hardware (albeit not yet inexpensively). Using SPV security rather than pruning security makes the cost even lower. A person relying on SPV would not have to download every 10 GB block, but only their transactions (or a small superset of them), which is already being done - scaling to 7 billion people would not require that SPV nodes perform any more computation than they already do. Nonetheless, I think pruning should be considered the default minimum, since that it what is required to get the full trust-minimized security guarantees of the blockchain. And that requires 10 GB blocks (or thereabouts). The number of people on the planet will also grow, perhaps to 14 billion people in the next few decades. However, the estimates here would still be roughly correct. 10 GB blocks, or approximately so, allows everyone in the world to have their transactions settled on the blockchain in a timely manner, whereas 1 MB blocks do not. And this is already achievable on current hardware. The most significant cost is bandwidth, but that will probably become substantially less expensive in the coming years, making it possible for everyone to inexpensively and securely send and receive bitcoin to anyone else, without having to use a parallel network with reduced security or rely on trusted third parties. [1] 10^9 / 60 / 60 / 24 / 365 ~= 32. [2] 7*10^9 / 24 / 60 / 60 ~= 81018 On 05/14/2015 08:22 AM, Tom Harding wrote: > A recent post, which I cannot find after much effort, made an > excellent point. > > If capacity grows, fewer individuals would be able to run full > nodes. Those individuals, like many already, would have to give up > running a full-node wallet :( > > That sounds bad, until you consider that the alternative is running > a full node on the bitcoin 'settlement network', while massive > numbers of people *give up any hope of directly owning bitcoin at > all*. > > If today's global payments are 100Ktps, and move to the Lightning > Network, they will have to be consolidated by a factor of 25000:1 > to fit into bitcoin's current 4tps capacity as a settlement > network. You executing a personal transaction on that network will > be about as likely as you personally conducting a $100 SWIFT > transfer to yourself today. For current holders, just selling or > spending will get very expensive! > > Forcing block capacity to stay small, so that individuals can run > full nodes, is precisely what will force bitcoin to become a > backbone that is too expensive for individuals to use. I can't > avoid the conclusion that Bitcoin has to scale, and we might as > well be thinking about how. > > There may be a an escape window. As current trends continue toward > a landscape of billions of SPV wallets, it may still be possible > for individuals collectively to make up the majority of the > network, if more parts of the network itself rely on SPV-level > security. > > With SPV-level security, it might be possible to implement a > scalable DHT-type network of nodes that collectively store and > index the exhaustive and fast-growing corpus of transaction > history, up to and including currently unconfirmed transactions. > Each individual node could host a slice of the transaction set with > a configurable size, let's say down to a few GB today. > > Such a network would have the desirable property of being run by > the community. Most transactions would be submitted to it, and > like today's network, it would disseminate blocks (which would be > rapidly torn apart and digested). Therefore miners and other full > nodes would depend on it, which is rather critical as those nodes > grow closer to data-center proportions. > > > > ------------------------------------------------------------------------------ > > > > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable > Insights Deep dive visibility with transaction tracing using APM > Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ Bitcoin-development > mailing list Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Ryan X. Charles Software Engineer @BitGo twitter.com/ryanxcharles github.com/ryanxcharles keybase.io/ryanxcharles onename.com/ryanxcharles