Jim Phillips [ARCHIVE] on Nostr: 📅 Original date posted:2015-05-26 📝 Original message:I think all the ...

📅 Original date posted:2015-05-26
📝 Original message:I think all the suggestions recommending cutting the block time down also
suggest reducing the rewards to compensate.

--
*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 Tue, May 26, 2015 at 12:43 AM, gabe appleton <gappleto97 at gmail.com>
wrote:

> 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 at 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 at 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 at 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 at ergophobia.org>
>>>> Sent: ‎26/‎05/‎2015 12:53 PM
>>>> To: Thy Shizzle <thyshizzle at outlook.com>
>>>> Cc: Mike Hearn <mike at plan99.net>; Bitcoin Dev
>>>> <bitcoin-development at 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 at 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 at ergophobia.org>
>>>> Sent: ‎26/‎05/‎2015 12:27 PM
>>>> To: Mike Hearn <mike at plan99.net>
>>>> Cc: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
>>>> Subject: Re: [Bitcoin-development] No Bitcoin For You
>>>>
>>>>
>>>> On Mon, May 25, 2015 at 1:36 PM, Mike Hearn <mike at 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 at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150526/909baed8/attachment.html>;