From: gabe appleton <gappleto97@gmail•com>
To: Jim Phillips <jim@ergophobia•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] No Bitcoin For You
Date: Tue, 26 May 2015 01:43:17 -0400 [thread overview]
Message-ID: <CANJO25LfwscmT06gwk3D==+=Cj6eBt9dUCHwyrGAs6U9Eoi5Uw@mail.gmail.com> (raw)
In-Reply-To: <CANe1mWw2os6GUbRiyegn=Z+2ZM_J8x76rD4uh_0C3z+ix8aK+A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 11425 bytes --]
Sync time wouldn't be longer compared to 20MB, it would (eventually) be
longer under either setup.
Also, and this is probably a silly concern, but wouldn't changing block
time change the supply curve? If we cut the rate in half or a power of two,
that affects nothing, but if we want to keep it in round numbers, we need
to do it by 10, 5, or 2. I feel like most people would bank for 10 or 5,
both of which change the supply curve due to truncation.
Again, it's a trivial concern, but probably one that should be addressed.
On May 25, 2015 11:52 PM, "Jim Phillips" <jim@ergophobia•org> wrote:
> Incidentally, even once we have the "Internet of Things" brought on by 21,
> Inc. or whoever beats them to it, I would expect the average home to have
> only a single full node "hub" receiving the blockchain and broadcasting
> transactions created by all the minor SPV connected devices running within
> the house. The in-home full node would be peered with high bandwidth
> full-node relays running at the ISP or in the cloud. There are more than
> enough ISPs and cloud compute providers in the world such that there should
> be no concern at all about centralization of relays. Full nodes could some
> day become as ubiquitous on the Internet as authoritative DNS servers. And
> just like DNS servers, if you don't trust the nodes your ISP creates or
> it's too slow or censors transactions, there's nothing preventing you from
> peering with nodes hosted by the Googles or OpenDNSs out there, or running
> your own if you're really paranoid and have a few extra bucks for a VPS.
>
> --
> *James G. Phillips IV*
> <https://plus.google.com/u/0/113107039501292625391/posts>
> <http://www.linkedin.com/in/ergophobe>
>
> *"Don't bunt. Aim out of the ball park. Aim for the company of immortals."
> -- David Ogilvy*
>
> *This message was created with 100% recycled electrons. Please think
> twice before printing.*
>
> On Mon, May 25, 2015 at 10:23 PM, Jim Phillips <jim@ergophobia•org> wrote:
>
>> I don't see how the fact that my 2Mbps connection causes me to not be a
>> very good relay has any bearing on whether or not the network as a whole
>> would be negatively impacted by a 20MB block. My inability to rapidly
>> propagate blocks doesn't really harm the network. It's only if MOST relays
>> are as slow as mine that it creates an issue. I'm one node in thousands
>> (potentially tens or hundreds of thousands if/when Bitcoin goes
>> mainstream). And I'm an individual. There's no reason at all for me to run
>> a full node from my home, except to have my own trusted and validated copy
>> of the blockchain on a computer I control directly. I don't need to act as
>> a relay for that and as long as I can download blocks faster than they are
>> created I'm fine. Also, I can easily afford a VPS server or several to run
>> full nodes as relays if I am feeling altruistic. It's actually cheaper for
>> me to lease a VPS than to keep my own home PC on 24/7, which is why I have
>> 2 of them.
>>
>> And as a business, the cost of a server and bandwidth to run a full node
>> is a drop in the bucket. I'm involved in several projects where we have
>> full nodes running on leased servers with multiple 1Gbps connections. It's
>> an almost zero cost. Those nodes could handle 20MB blocks today without
>> thinking about it, and I'm sure our nodes are just a few amongst thousands
>> just like them. I'm not at all concerned about the network being too
>> centralized.
>>
>> What concerns me is the fact that we are using edge cases like my home PC
>> as a lame excuse to debate expanding the capacity of the network.
>>
>> --
>> *James G. Phillips IV*
>> <https://plus.google.com/u/0/113107039501292625391/posts>
>> <http://www.linkedin.com/in/ergophobe>
>>
>> *"Don't bunt. Aim out of the ball park. Aim for the company of
>> immortals." -- David Ogilvy*
>>
>> *This message was created with 100% recycled electrons. Please think
>> twice before printing.*
>>
>> On Mon, May 25, 2015 at 10:02 PM, Thy Shizzle <thyshizzle@outlook•com>
>> wrote:
>>
>>> Indeed Jim, your internet connection makes a good reason why I don't
>>> like 20mb blocks (right now). It would take you well over a minute to
>>> download the block before you could even relay it on, so much slow down in
>>> propagation! Yes I do see how decreasing the time to create blocks is a bit
>>> of a band-aid fix, and to use tge term I've seen mentioned here "kicking
>>> the can down the road" I agree that this is doing this, however as you say
>>> bandwidth is our biggest enemy right now and so hopefully by the time we
>>> exceed the capacity gained by the decrease in block time, we can then look
>>> to bump up block size because hopefully 20mbps connections will be baseline
>>> by then etc.
>>> ------------------------------
>>> From: Jim Phillips <jim@ergophobia•org>
>>> Sent: 26/05/2015 12:53 PM
>>> To: Thy Shizzle <thyshizzle@outlook•com>
>>> Cc: Mike Hearn <mike@plan99•net>; Bitcoin Dev
>>> <bitcoin-development@lists•sourceforge.net>
>>>
>>> Subject: Re: [Bitcoin-development] No Bitcoin For You
>>>
>>> Frankly I'm good with either way. I'm definitely in favor of faster
>>> confirmation times.
>>>
>>> The important thing is that we need to increase the amount of
>>> transactions that get into blocks over a given time frame to a point that
>>> is in line with what current technology can handle. We can handle WAY more
>>> than we are doing right now. The Bitcoin network is not currently Disk,
>>> CPU, or RAM bound.. Not even close. The metric we're closest to being
>>> restricted by would be Network bandwidth. I live in a developing country.
>>> 2Mbps is a typical broadband speed here (although 5Mbps and 10Mbps
>>> connections are affordable). That equates to about 17MB per minute, or 170x
>>> more capacity than what I need to receive a full copy of the blockchain if
>>> I only talk to one peer. If I relay to say 10 peers, I can still handle 17x
>>> larger block sizes on a slow 2Mbps connection.
>>>
>>> Also, even if we reduce the difficulty so that we're doing 1MB blocks
>>> every minute, that's still only 10MB every 10 minutes. Eventually we're
>>> going to have to increase that, and we can only reduce the confirmation
>>> period so much. I think someone once said 30 seconds or so is about the
>>> shortest period you can practically achieve.
>>>
>>> --
>>> *James G. Phillips IV*
>>> <https://plus.google.com/u/0/113107039501292625391/posts>
>>> <http://www.linkedin.com/in/ergophobe>
>>>
>>> *"Don't bunt. Aim out of the ball park. Aim for the company of
>>> immortals." -- David Ogilvy *
>>>
>>> *This message was created with 100% recycled electrons. Please think
>>> twice before printing.*
>>>
>>> On Mon, May 25, 2015 at 9:30 PM, Thy Shizzle <thyshizzle@outlook•com>
>>> wrote:
>>>
>>> Nah don't make blocks 20mb, then you are slowing down block
>>> propagation and blowing out conf tikes as a result. Just decrease the time
>>> it takes to make a 1mb block, then you still see the same propagation times
>>> today and just increase the transaction throughput.
>>> ------------------------------
>>> From: Jim Phillips <jim@ergophobia•org>
>>> Sent: 26/05/2015 12:27 PM
>>> To: Mike Hearn <mike@plan99•net>
>>> Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
>>> Subject: Re: [Bitcoin-development] No Bitcoin For You
>>>
>>>
>>> On Mon, May 25, 2015 at 1:36 PM, Mike Hearn <mike@plan99•net> wrote:
>>>
>>> This meme about datacenter-sized nodes has to die. The Bitcoin wiki
>>> is down right now, but I showed years ago that you could keep up with VISA
>>> on a single well specced server with today's technology. Only people living
>>> in a dreamworld think that Bitcoin might actually have to match that level
>>> of transaction demand with today's hardware. As noted previously, "too many
>>> users" is simply not a problem Bitcoin has .... and may never have!
>>>
>>>
>>> ... And will certainly NEVER have if we can't solve the capacity
>>> problem SOON.
>>>
>>> In a former life, I was a capacity planner for Bank of America's
>>> mid-range server group. We had one hard and fast rule. When you are
>>> typically exceeding 75% of capacity on a given metric, it's time to expand
>>> capacity. Period. You don't do silly things like adjusting the business
>>> model to disincentivize use. Unless there's some flaw in the system and
>>> it's leaking resources, if usage has increased to the point where you are
>>> at or near the limits of capacity, you expand capacity. It's as simple as
>>> that, and I've found that same rule fits quite well in a number of systems.
>>>
>>> In Bitcoin, we're not leaking resources. There's no flaw. The system
>>> is performing as intended. Usage is increasing because it works so well,
>>> and there is huge potential for future growth as we identify more uses and
>>> attract more users. There might be a few technical things we can do to
>>> reduce consumption, but the metric we're concerned with right now is how
>>> many transactions we can fit in a block. We've broken through the 75%
>>> marker and are regularly bumping up against the 100% limit.
>>>
>>> It is time to stop debating this and take action to expand capacity.
>>> The only questions that should remain are how much capacity do we add, and
>>> how soon can we do it. Given that most existing computer systems and
>>> networks can easily handle 20MB blocks every 10 minutes, and given that
>>> that will increase capacity 20-fold, I can't think of a single reason why
>>> we can't go to 20MB as soon as humanly possible. And in a few years, when
>>> the average block size is over 15MB, we bump it up again to as high as we
>>> can go then without pushing typical computers or networks beyond their
>>> capacity. We can worry about ways to slow down growth without affecting the
>>> usefulness of Bitcoin as we get closer to the hard technical limits on our
>>> capacity.
>>>
>>> And you know what else? If miners need higher fees to accommodate the
>>> costs of bigger blocks, they can configure their nodes to only mine
>>> transactions with higher fees.. Let the miners decide how to charge enough
>>> to pay for their costs. We don't need to cripple the network just for them.
>>>
>>> --
>>> *James G. Phillips IV*
>>> <https://plus.google.com/u/0/113107039501292625391/posts>
>>>
>>> *"Don't bunt. Aim out of the ball park. Aim for the company of
>>> immortals." -- David Ogilvy *
>>>
>>> *This message was created with 100% recycled electrons. Please think
>>> twice before printing.*
>>>
>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
> 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
>
>
[-- Attachment #2: Type: text/html, Size: 17456 bytes --]
next prev parent reply other threads:[~2015-05-26 5:43 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-26 3:02 Thy Shizzle
2015-05-26 3:23 ` Jim Phillips
2015-05-26 3:49 ` Jim Phillips
2015-05-26 5:43 ` gabe appleton [this message]
2015-05-26 8:29 ` Jim Phillips
-- strict thread matches above, loose matches on Subject: below --
2015-05-26 2:51 Thy Shizzle
2015-05-26 2:30 Thy Shizzle
2015-05-26 2:41 ` gabe appleton
2015-05-26 2:53 ` Jim Phillips
2015-05-14 15:22 Tom Harding
2015-05-17 2:31 ` Ryan X. Charles
2015-05-25 18:36 ` Mike Hearn
2015-05-26 2:26 ` Jim Phillips
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANJO25LfwscmT06gwk3D==+=Cj6eBt9dUCHwyrGAs6U9Eoi5Uw@mail.gmail.com' \
--to=gappleto97@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jim@ergophobia$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox