Re: [Bitcoin-development] Block Size Increase Requirements

[Jorge Timón]

On May 31, 2015 5:08 PM, "Gavin Andresen"  wrote:
>
> On Sun, May 31, 2015 at 10:59 AM, Jorge Timón  wrote:
>>
>> Whatever...let's use the current subsidies, the same argument applies,
it's just 20 + 25 = 45 btc per block for miner B vs 27 btc for miner B.
>> Miner B would still go out of business, bigger blocks still mean more
mining and validation centralization
>
> Sorry, but that's ridiculous.
>
> If Miner B is leaving 18BTC per block on the table because they have bad
connectivity, then they need to pay for better connectivity.

Well, I was assuming they just can't upgrade their connection (without
moving thei operations to another place). Maybe that assumption is
ridiculous as well.

> If you are arguing "I should be able to mine on a 56K modem connection
from the middle of the Sahara" then we're going to have to agree to
disagree.

No, I'm not suggesting that.

> So: what is your specific proposal for minimum requirements for
connectivity to run a full node? The 20MB number comes from estimating
costs to run a full node, and as my back-and-forth to Chang Wung shows, the
costs are not excessive.

Well, you were I think assuming a new desktop connecting from somewhere in
the US. I would be more confortable with an eee pc from a hotel in India,
for example. But yeah, targeting some concrete minimum specs seems like the
right approach for deciding "how far to go when increasing centralization".

But "hitting the limit will be chaos" seems to imply that completely
removing the consensus maximum blocksize is the only logical solution. What
happens when we hit the limit next time? When do we stop kicking the can
down the road? When do we voluntarily get that "chaos"?
Again, "that's too far away in the future to worry about it" is not a very
conving answer to me.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase Requirements

[Gavin Andresen]

On Sun, May 31, 2015 at 10:59 AM, Jorge Timón  wrote:

> Whatever...let's use the current subsidies, the same argument applies,
> it's just 20 + 25 = 45 btc per block for miner B vs 27 btc for miner B.
> Miner B would still go out of business, bigger blocks still mean more
> mining and validation centralization
>
Sorry, but that's ridiculous.

If Miner B is leaving 18BTC per block on the table because they have bad
connectivity, then they need to pay for better connectivity.

If you are arguing "I should be able to mine on a 56K modem connection from
the middle of the Sahara" then we're going to have to agree to disagree.

So: what is your specific proposal for minimum requirements for
connectivity to run a full node? The 20MB number comes from estimating
costs to run a full node, and as my back-and-forth to Chang Wung shows, the
costs are not excessive.

-- 
--
Gavin Andresen
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase Requirements

[Jorge Timón]

Whatever...let's use the current subsidies, the same argument applies, it's
just 20 + 25 = 45 btc per block for miner B vs 27 btc for miner B.
Miner B would still go out of business, bigger blocks still mean more
mining and validation centralization. The question is how far I we willing
to go with this "scaling by sacrificing decentralization", but the answer
can't be "that's to far away in the future to worry about it, right now as
far as we think we can using orphan rate as the only criterion".
On May 31, 2015 4:49 PM, "Gavin Andresen"  wrote:

> On Sun, May 31, 2015 at 10:46 AM, Jorge Timón  wrote:
>
>> Here's a thought experiment:
>>
>> Subsidy is gone, all the block reward comes from fees.
>>
> I wrote about long-term hypotheticals and why I think it is a big mistake
> to waste time worrying about them here:
>http://gavinandresen.ninja/when-the-block-reward-goes-away
>
>
> --
> --
> Gavin Andresen
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase Requirements

[Gavin Andresen]

On Sun, May 31, 2015 at 10:46 AM, Jorge Timón  wrote:

> Here's a thought experiment:
>
> Subsidy is gone, all the block reward comes from fees.
>
I wrote about long-term hypotheticals and why I think it is a big mistake
to waste time worrying about them here:
   http://gavinandresen.ninja/when-the-block-reward-goes-away


-- 
--
Gavin Andresen
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase Requirements

[Jorge Timón]

On May 30, 2015 10:38 PM, "Gavin Andresen"  wrote:
>
> Mining is a competitive business, the marginal miner will ALWAYS be going
out of business.
>
> That is completely independent of the block size, block subsidy, or
transaction fees.

No, the later determines who can be profitable.
Here's a thought experiment:

Subsidy is gone, all the block reward comes from fees.
Miner A has great connectivity and mines 20 MB blocks, with an average of
20 btc per block.
Miner B has a connectivity such that 2 MB blocks puts it on a reasonable
orphan rate, so it gets an average of 2 btc per block mined.
But the difficulty is the same for all and it can rise up to miner A
breaking even after energy costs.
Will miner B be profitable with this setup? The answer is no and miner B
will just go out of business. In that sense too, bigger blocks mean more
mining centralization.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase Requirements

[Gavin Andresen]

On Sun, May 31, 2015 at 3:05 AM, Peter Todd  wrote:

> Yeah, I'm pretty surprised myself that Gavin never accepted the
> compromises offered by others in this space for a slow growth solution
>

What compromise? I haven't seen a specific proposal that could be turned
into a pull request.




> Something important to note in Gavin Andresen's analysises of this issue
> is that he's using quite optimistic scenarios for how nodes are
> connected to each other.


NO I AM NOT.

I simulated a variety of connectivities; see the .cfg files at
  https://github.com/gavinandresen/bitcoin_miningsim

The results I give in the "are bigger blocks better" blog post are for
WORST CASE connectivity (one dominant big miner, multiple little miners,
big miner connects to only 30% of little miners, but all the little miners
connected directly to each other).


> For instance, assuming that connections between
> miners are direct is a very optimistic assumption


Again, I did not simulate all miners directly connected to each other.

I will note that miners are VERY HIGHLY connected today. It is in their
best interest to be highly connected to each other.


> that depends on a
> permissive, unregulated, environment where miners co-operate with each
> other - obviously that's easily subject to change!


Really? How is that easily subject to change? If it is easily subject to
change, do bigger blocks have any effect? Why are 1MB blocks not subject to
change?

I talk about "what if your government bans Bitcoin entirely" here:
   http://gavinandresen.ninja/big-blocks-and-tor

... and the issues are essentially the same, independent of block size.


-- 
--
Gavin Andresen
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase Requirements

[Peter Todd]

On Sat, May 30, 2015 at 07:42:16AM +0800, Chun Wang wrote:
> Hello. I am from F2Pool. We are currently mining the biggest blocks on
> the network. So far top 100 biggest bitcoin blocks are all from us. We
> do support bigger blocks and sooner rather than later. But we cannot
> handle 20 MB blocks right now. I know most blocks would not be 20 MB
> over night. But only if a small fraction of blocks more than 10 MB, it
> could dramatically increase of our orphan rate, result of higher fee
> to miners. Bad miners could attack us and the network with artificial
> big blocks. As yhou know, other Chinese pools, AntPool, BW, they
> produces ASIC chips and mining mostly with their own machines. They do
> not care about a few percent of orphan increase as much as we do. They
> would continue their zero fee policy. We would be the biggest loser.
> As the exchanges had taught us, zero fee is not health to the network.
> Also we have to redevelop our block broadcast logic. Server bandwidth
> is a lot more expensive in China. And the Internet is slow. Currently
> China has more than 50% of mining power, if block size increases, I
> bet European and American pools could suffer more than us. We think
> the max block size should be increased, but must be increased
> smoothly, 2 MB first, and then after one or two years 4 MB, then 8 MB,
> and so on. Thanks.

Great to hear from you!

Yeah, I'm pretty surprised myself that Gavin never accepted the
compromises offered by others in this space for a slow growth solution,
rather than starting with over an order of magnitude blocksize increase.
This is particularly surprising when his own calculations - after
correcting an artithmetic error - came up with 8MB blocks rather than
20MB.

Something important to note in Gavin Andresen's analysises of this issue
is that he's using quite optimistic scenarios for how nodes are
connected to each other. For instance, assuming that connections between
miners are direct is a very optimistic assumption that depends on a
permissive, unregulated, environment where miners co-operate with each
other - obviously that's easily subject to change! Better block
broadcasting logic helps this in the "co-operation" case, but there's
not much it can do in the worst-case.


Unrelated: feel free to contact me directly if you have any questions
re: the BIP66 upgrade; I hear you guys were planning on upgrading your
mining nodes soon.

-- 
'peter'[:-1]@petertodd.org
0db932d1cbd04a29d8e55989eda3f096d3ab8e8d95eb28e9


signature.asc
Description: Digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase Requirements

[gb]

Linear growth is indeed the 'simplest' model for growth so removes
concerns of complexity using such a growth model. Seems like it might be
a safe compromise between exponential growth, zero growth and buys some
time to observe the longer term scale network behaviour. 

A simple linear growth 'hard' technical limit could also be used
conjunction with the simple periodic soft dynamic limit adjustment (e.g.
1.5x of moving average) as discussed recently. So that the combination
provides for growth, with fee pressure, up until if/when the technical
hard limit is hit. And if we keep hitting the hard limit that signals a
market demand for ancillary layers to be built out, that has been
missing until now.

On Sun, 2015-05-31 at 01:05 +0300, Alex Mizrahi wrote:
>  
> 
> Why 2 MB ?
> 
> 
> Why 20 MB? Do you anticipate 20x transaction count growth in 2016?
> 
> 
> Why not grow it by 1 MB per year?
> This is a safer option, I don't think that anybody claims that 2 MB
> blocks will be a problem.
> And in 10 years when we get to 10 MB we'll get more evidence as to
> whether network can handle 10 MB blocks.
> 
> 
> So this might be a solution which would satisfy both sides:
>   *  people who are concerned about block size growth will have an
> opportunity to stop it before it grows too much (e.g. with a soft
> fork),
>   *  while people who want bigger blocks will get an equivalent of 25%
> per year growth within the first 10 years, which isn't bad, is it?
> 
> 
> So far I haven't heard any valid arguments against linear growth.
> --
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development



--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase Requirements

[Alex Mizrahi]

>
> Stop trying to dictate block growth limits.  Block size will be determined
> by competition between miners and availability of transactions, not through
> hard-coded limits.
>
Do you even game theory, bro? It doesn't work that way.

Mike Hearn described the problem in this article:
https://medium.com/@octskyward/hashing-7d04a887acc8

But the solution he's proposing is ridiculously bad and unsound: he expects
business owners to donate large sums of money towards mining. If it comes
to this, what sane business owner will donate, say, 100 BTC to miners
instead of seeking some alternatives? Proof-of-stake coins are already
there. I'm well aware of theoretical issues with PoS security, but those
theoretical issues aren't as bad as donation-funded cryptocurrency security.

But you know what works? Mining fees + block size limit.
Users and merchants are interested in their transactions being confirmed,
but block size limit won't allow it to turn into a race to bottom.
This is actually game-theoretically sound.


>   I see now the temporary 1MB limit was a mistake.  It should have gone in
> as a dynamic limit that scales with average block size.
>
This means that miners will control it, and miners couldn't care less about
things like decentralization and about problems of ordinary users. This
means that in this scenario Bitcoin will be 100% controlled by few huge-ass
mining operations.

Possibly a single operation. We already saw GHASH.IO using 51% of total
hashpower. Is that what you want?

Miners are NOT benevolent. This was already demonstrated. They are greedy.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase Requirements

[Alex Mizrahi]

> Why 20 MB? Do you anticipate 20x transaction count growth in 2016?
>
> Do you anticipate linear growth?
>

It's safe to say that absolutely nobody can predict the actual growth with
any degree of an accuracy.
I believe that linear growth compares very favorably to other alternatives:

1. Exponential growth: Linear growth is better at modelling diminishing
returns, that is, risk that it grows too much is much smaller. At the same
time initially it will grow faster than reasonable exponential models.
   E.g. linear year-over-year relative growth:100% 50% 33% 25% ...10%
   While exponential one which gives the same result in 10 years:
   25% 25% ... 25%
   This is on the same scale, but exponential starts slower than we want at
start (1.25 MB will be too little for 2016 as we already see fully filled 1
MB blocks), but goes a bit too fast in the long term. It's highly unlikely
we'll see bandwidth growing 10x each 10 years in the long term.

2. Single step increase: an obvious advantage is that linear growth gives
us time to adapt to near realities, time to change something if there is an
unwanted effects, etc. At the same a single step is not a long-term
solution.
While a slow-but-steady growth might be.

3. Adaptive solutions (e.g. limit depends on the last N blocks or something
of that nature):
  The problem with them is that they are  rather complex, and also:
  3.1. prone to manipulation: somebody might try to push the limit if it
will favor him in future
  3.2. possibility of a positive feedback loop.
  3.3. possibility of an unhealthy game-theoretic dynamics

The main problem is that we do not understand game theoretic aspects of
bitcoin mining in presence of various real-world factors such as block
propagation delays. Thus we can't design a proper adaptive solution.


There is no perfect solution to this problem as we cannot predict the
future and our understanding is limited.
But among the 5 alternatives (linear, exponential, single step, adaptive,
no limit), linear seems to be the best option at this point as it's both
quite safe and doesn't stunt growth too much.

> bitcoin is really really small right now, any sign of real adoption could
make it grow 100x or even more in a matter of weeks.

This is certainly possible, but the thing is:

1) this can't be predicted;
2) this will be a serious problem for many bitcoind installations;
3) it's not necessarily a healthy thing, perhaps it will grow 100x in a
matter of weeks, and then will go to zero in matter of weeks as well.

So I don't think that sudden growth spurts is something we should take into
account on the planning stage. If anything we'd like to prevent them from
happening, slow growth is usually better.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase Requirements

[Raystonn]

Stop trying to dictate block growth limits.  Block size will be determined by competition between miners and availability of transactions, not through hard-coded limits.  I see now the temporary 1MB limit was a mistake.  It should have gone in as a dynamic limit that scales with average block size.  The static limit has led to the mistaken impression that this was some sort of guarantee or contract with miners.  That was not intended.

On 30 May 2015 3:07 pm, Alex Mizrahi  wrote: Why 2 MB ?Why 20 MB? Do you anticipate 20x transaction count growth in 2016?Why not grow it by 1 MB per year?This is a safer option, I don't think that anybody claims that 2 MB blocks will be a problem.And in 10 years when we get to 10 MB we'll get more evidence as to whether network can handle 10 MB blocks.So this might be a solution which would satisfy both sides:  *  people who are concerned about block size growth will have an opportunity to stop it before it grows too much (e.g. with a soft fork),  *  while people who want bigger blocks will get an equivalent of 25% per year growth within the first 10 years, which isn't bad, is it?So far I haven't heard any valid arguments against linear growth.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase Requirements

[Brian Hoffman]

> Why 20 MB? Do you anticipate 20x transaction count growth in 2016?


Do you anticipate linear growth?

> On May 30, 2015, at 6:05 PM, Alex Mizrahi  wrote:
> 
>  
>> Why 2 MB ?
> 
> Why 20 MB? Do you anticipate 20x transaction count growth in 2016?
> 
> Why not grow it by 1 MB per year?
> This is a safer option, I don't think that anybody claims that 2 MB blocks 
> will be a problem.
> And in 10 years when we get to 10 MB we'll get more evidence as to whether 
> network can handle 10 MB blocks.
> 
> So this might be a solution which would satisfy both sides:
>   *  people who are concerned about block size growth will have an 
> opportunity to stop it before it grows too much (e.g. with a soft fork),
>   *  while people who want bigger blocks will get an equivalent of 25% per 
> year growth within the first 10 years, which isn't bad, is it?
> 
> So far I haven't heard any valid arguments against linear growth.
> --
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase Requirements

[Alex Mizrahi]

> Why 2 MB ?
>

Why 20 MB? Do you anticipate 20x transaction count growth in 2016?

Why not grow it by 1 MB per year?
This is a safer option, I don't think that anybody claims that 2 MB blocks
will be a problem.
And in 10 years when we get to 10 MB we'll get more evidence as to whether
network can handle 10 MB blocks.

So this might be a solution which would satisfy both sides:
  *  people who are concerned about block size growth will have an
opportunity to stop it before it grows too much (e.g. with a soft fork),
  *  while people who want bigger blocks will get an equivalent of 25% per
year growth within the first 10 years, which isn't bad, is it?

So far I haven't heard any valid arguments against linear growth.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase Requirements

[Gavin Andresen]

On Sat, May 30, 2015 at 3:32 PM, Matt Corallo 
wrote:

> If, for example, the majority of miners are in China (they are), and
> there is really poor connectivity in and out of China (there is) and a
> miner naively optimizes for profit, they will create blocks which are
> large and take a while to relay out of China. By simple trial-and-error
> an individual large miner might notice that when they create larger
> blocks which fork off miners in other parts of the world, they get more
> income. Obviously forking off 50% of the network would be a rather
> extreme situation and assumes all kinds of simplified models, but it
> shows that the incentives here are very far from aligned, and your
> simplified good-behavior models are very far from convincing.
>

"good behavior" models? I intentionally modeled what should be a worst-case.

If you have a specific network topology you want to model, please email me
details and I'll see what worst case is. Or, even better, take my
simulation code and run it yourself (it's C++, easy to compile, easy to
modify if you think it is too simple).

I get frustrated with all of the armchair "but what if..."
how-many-miners-can-dance-on-the-head-of-a-pin arguments.



> > I'll talk about transaction fees in a second, but there are several
> > problems with this already. As pointed out in the original mail, gfw
> has
> > already been known to interfere with Bitcoin P2P traffic. So now by
> > "little" miners, you mean any miner who is not located in mainland
> > China? Whats worse, the disadvantage is symmetric - little miners
> are at
> > a disadvantage when *anyone* mines a bigger block


No, they're not. They are only at a disadvantage when THEY mine bigger
blocks.

I guess I wasn't clear in the "do bigger miners have an advantage" blog
post.


> ... I mentioned this in my
> original email as something which doesnt make me comfortable with 20MB
> blocks, but something which needs simulation and study, and might
> actually be just fine!
>

I spent last week doing simulation and study. Please, do your own
simulation and study if you don't trust my results. There are big
full-scale-bitcoin-network-simulations spinning up that should have results
in a month or two, also, but there will ALWAYS be "but we didn't think
about what if THIS happens" scenarios that can require more simulation and
study.


>
> > Do you have another explanation for why miners choose to leave
> > fee-paying transactions in their mempool and create small blocks?
>
> Defaults? Dumb designs? Most miners just use the default 750K blocks, as
> far as I can tell, other miners probably didnt see transactions relayed
> across several hops or so, and a select few miners are doing crazy
> things like making their blocks fit in a single packet to cross the gfw,
> but that is probably overkill and not well-researched.
>

Last night's transaction volume test shows that most miners do just go
along with defaults:
  http://bitcoincore.org/~gavin/sizes_358594.html

> I'm not suggesting that we increase the blocksize sufficiently such that
> > transaction fees are not the way in which miners make their money.
> >
> > I'm suggesting the blocksize be increased to 20MB (and then doubled
> > every couple of years).
>
> Do you have convincing evidence that at 20MB miners will be able to
> break even on transaction fees for a long time? (The answer is no
> because no one has any idea how bitcoin transaction volumes are going to
> scale, period.)
>


Mining is a competitive business, the marginal miner will ALWAYS be going
out of business.

That is completely independent of the block size, block subsidy, or
transaction fees.

The question is "will there be enough fee+subsidy revenue to make it
unprofitable for an attacker to buy or rent enough hashpower to
double-spend."

It is obvious to me that bigger blocks make it more likely the answer to
that question is "yes."



>
> > And "in which miners make their money" is the wrong metric-- we want
> > enough mining so the network to be "secure enough" against double-spends.
>
> Sure, do you have a value of hashpower which is "secure enough" (which
> is a whole other rabbit hole to go down...).
>

Mike Hearn wrote about that just a couple days ago:
  https://medium.com/@octskyward/hashing-7d04a887acc8
(See "How much is too much" section)


> > Even if we end up in a world where only big companies can run full nodes
> > (and I am NOT NOT NOT NOT NOT proposing any such thing), there is a
> > difference-- you don't need permission to "open up a bank" on the
> > Bitcoin network.
> >
>
> Oh? You mention at http://gavinandresen.ninja/bigger-blocks-another-way
> that "I struggle with wanting to stay true to Satoshi’s original vision
> of Bitcoin as a system that scales up to Visa-level transaction volume".
> That is in direct contradiction.
>

I have said repeatedly that if it was left completely up to me I would go
back to Satoshi's original "there is no consensus-lev

Re: [Bitcoin-development] Block Size Increase Requirements

[Matt Corallo]

On 05/29/15 23:48, Gavin Andresen wrote:
> On Fri, May 29, 2015 at 7:25 PM, Matt Corallo  > wrote:
> 
> Sadly, this is very far from the whole story. The issue of miners
> optimizing for returns has been discussed several times during this
> discussion, and, sadly, miners who are geographically colocated who are
> optimizing for returns with a free-floating blocksize will optimize away
> 50% of the network!
> 
> 
> I must have missed that analysis-- link please?  Or summary of HOW they
> will optimize away 50% of the network?
> 
> Or are you assuming that 50% of the network is colocated... (which is a
> potential problem independent of blocksize)

If, for example, the majority of miners are in China (they are), and
there is really poor connectivity in and out of China (there is) and a
miner naively optimizes for profit, they will create blocks which are
large and take a while to relay out of China. By simple trial-and-error
an individual large miner might notice that when they create larger
blocks which fork off miners in other parts of the world, they get more
income. Obviously forking off 50% of the network would be a rather
extreme situation and assumes all kinds of simplified models, but it
shows that the incentives here are very far from aligned, and your
simplified good-behavior models are very far from convincing.

> 
> >
> > In addition, I'd expect to
> > see analysis of how these systems perform in the worst-case, not 
> just
> > packet-loss-wise, but in the face of miners attempting to break the
> > system.
> >
> >
> > See 
> http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners for
> > analysis of "but that means bigger miners can get an advantage" 
> argument.
> >
> > Executive summary: if little miners are stupid and produce huge blocks,
> > then yes, big miners have an advantage.
> 
> I'll talk about transaction fees in a second, but there are several
> problems with this already. As pointed out in the original mail, gfw has
> already been known to interfere with Bitcoin P2P traffic. So now by
> "little" miners, you mean any miner who is not located in mainland
> China? Whats worse, the disadvantage is symmetric - little miners are at
> a disadvantage when *anyone* mines a bigger block, and miners dont even
> have to be "evil" for this to happen - just optimize for profits.
> 
> 
> But the disadvantage is tiny. And essentially zero if they connect to
> your fast relay network (or anything like it).
> 

The disadvantage is small with 1MB blocks, but already non-zero. 20MB
blocks are much, much worse (lots of things here dont scale linearly,
even just transfer over a high-packet-loss-link). I mentioned this in my
original email as something which doesnt make me comfortable with 20MB
blocks, but something which needs simulation and study, and might
actually be just fine!

> 
> > But they're not, so they won't.
> 
> I dont know what you're referring to with this. Are you claiming little
> miners today optimize for relay times and have good visibility into the
> Bitcoin network and calculate an optimal block size based on this (or
> would with a 20MB block size)?
> 
> 
> Do you have another explanation for why miners choose to leave
> fee-paying transactions in their mempool and create small blocks?

Defaults? Dumb designs? Most miners just use the default 750K blocks, as
far as I can tell, other miners probably didnt see transactions relayed
across several hops or so, and a select few miners are doing crazy
things like making their blocks fit in a single packet to cross the gfw,
but that is probably overkill and not well-researched.

> > Until the block reward goes away, and assuming transaction fees become
> > an important source of revenue for miners.
> > I think it is too early to worry about that; see:
> >
> >http://gavinandresen.ninja/when-the-block-reward-goes-away
> 
> You dont make any points here with which I can argue, but let me respond
> with the reason /I/ think it is a problem worth thinking a little bit
> about...If we increase the blocksize sufficiently such that transaction
> fees are not the way in which miners make their money
> 
> 
> I'm not suggesting that we increase the blocksize sufficiently such that
> transaction fees are not the way in which miners make their money.
> 
> I'm suggesting the blocksize be increased to 20MB (and then doubled
> every couple of years).

Do you have convincing evidence that at 20MB miners will be able to
break even on transaction fees for a long time? (The answer is no
because no one has any idea how bitcoin transaction volumes are going to
scale, period.)

> And "in which miners make their money" is the wrong metric-- we want
> enough mining so the network to be "secure enough" against double-spends.

Sure, do you have a va

Re: [Bitcoin-development] Block Size Increase Requirements

[Pindar Wong]

On Sat, May 30, 2015 at 9:57 PM, Gavin Andresen 
wrote:

> On Fri, May 29, 2015 at 7:42 PM, Chun Wang <1240...@gmail.com> wrote:
>
>> Hello. I am from F2Pool. We are currently mining the biggest blocks on
>> the network.
>
>
> Thanks for giving your opinion!
>
>
>
>> Bad miners could attack us and the network with artificial
>> big blocks.
>
>
> How?
>
> I ran some simulations, and I could not find a network topology where a
> big miner producing big blocks could cause a loss of profit to another
> miner (big or small) producing smaller blocks:
>
> http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners
>
> (the 0.3% advantage I DID find was for the situation where EVERYBODY was
> producing big blocks).
>
>
>> We think
>> the max block size should be increased, but must be increased
>> smoothly, 2 MB first, and then after one or two years 4 MB, then 8 MB,
>> and so on. Thanks.
>
>
> Why 2 MB ?   You said that server bandwidth is much more expensive in
> China; what would be the difference in your bandwidth costs between 2MB
> blocks and 20MB blocks?
>

Perhaps we should arrange to run some more 'simulations' with miners from
China and elsewhere?

Let me know there's interest to do.

p.

>
>
> --
> --
> Gavin Andresen
>
>
> --
>
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase Requirements

[Gavin Andresen]

On Fri, May 29, 2015 at 7:42 PM, Chun Wang <1240...@gmail.com> wrote:

> Hello. I am from F2Pool. We are currently mining the biggest blocks on
> the network.


Thanks for giving your opinion!



> Bad miners could attack us and the network with artificial
> big blocks.


How?

I ran some simulations, and I could not find a network topology where a big
miner producing big blocks could cause a loss of profit to another miner
(big or small) producing smaller blocks:

http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners

(the 0.3% advantage I DID find was for the situation where EVERYBODY was
producing big blocks).


> We think
> the max block size should be increased, but must be increased
> smoothly, 2 MB first, and then after one or two years 4 MB, then 8 MB,
> and so on. Thanks.


Why 2 MB ?   You said that server bandwidth is much more expensive in
China; what would be the difference in your bandwidth costs between 2MB
blocks and 20MB blocks?


-- 
--
Gavin Andresen
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase Requirements

[Chun Wang]

Hello. I am from F2Pool. We are currently mining the biggest blocks on
the network. So far top 100 biggest bitcoin blocks are all from us. We
do support bigger blocks and sooner rather than later. But we cannot
handle 20 MB blocks right now. I know most blocks would not be 20 MB
over night. But only if a small fraction of blocks more than 10 MB, it
could dramatically increase of our orphan rate, result of higher fee
to miners. Bad miners could attack us and the network with artificial
big blocks. As yhou know, other Chinese pools, AntPool, BW, they
produces ASIC chips and mining mostly with their own machines. They do
not care about a few percent of orphan increase as much as we do. They
would continue their zero fee policy. We would be the biggest loser.
As the exchanges had taught us, zero fee is not health to the network.
Also we have to redevelop our block broadcast logic. Server bandwidth
is a lot more expensive in China. And the Internet is slow. Currently
China has more than 50% of mining power, if block size increases, I
bet European and American pools could suffer more than us. We think
the max block size should be increased, but must be increased
smoothly, 2 MB first, and then after one or two years 4 MB, then 8 MB,
and so on. Thanks.

On Fri, May 8, 2015 at 6:02 AM, Matt Corallo  wrote:
> OK, so lets do that. I've seen a lot of "I'm not entirely comfortable
> with committing to this right now, but think we should eventually", but
> not much "I'd be comfortable with committing to this when I see X". In
> the interest of ignoring debate and pushing people towards a consensus
> at all costs, ( ;) ) I'm gonna go ahead and suggest we talk about the
> second.
>
> Personally, there are several things that worry me significantly about
> committing to a blocksize increase, which I'd like to see resolved
> before I'd consider supporting a blocksize increase commitment.
>
>  * Though there are many proposals floating around which could
> significantly decrease block propagation latency, none of them are
> implemented today. I'd expect to see these not only implemented but
> being used in production (though I dont particularly care about them
> being all that stable). I'd want to see measurements of how they perform
> both in production and in the face of high packet loss (eg across the
> GFW or in the case of small/moderate DoS). In addition, I'd expect to
> see analysis of how these systems perform in the worst-case, not just
> packet-loss-wise, but in the face of miners attempting to break the system.
>
>  * I'd very much like to see someone working on better scaling
> technology, both in terms of development and in terms of getting
> traction in the marketplace. I know StrawPay is working on development,
> though its not obvious to me how far they are from their website, but I
> dont know of any commitments by large players (either SPV wallets,
> centralized wallet services, payment processors, or any others) to
> support such a system (to be fair, its probably too early for such
> players to commit to anything, since anything doesnt exist in public).
>
>  * I'd like to see some better conclusions to the discussion around
> long-term incentives within the system. If we're just building Bitcoin
> to work in five years, great, but if we want it all to keep working as
> subsidy drops significantly, I'd like a better answer than "we'll deal
> with it when we get there" or "it will happen, all the predictions based
> on people's behavior today say so" (which are hopefully invalid thanks
> to the previous point). Ideally, I'd love to see some real free pressure
> already on the network starting to develop when we commit to hardforking
> in a year. Not just full blocks with some fees because wallets are
> including far greater fees than they really need to, but software which
> properly handles fees across the ecosystem, smart fee increases when
> transactions arent confirming (eg replace-by-fee, which could be limited
> to increase-in-fees-only for those worried about double-spends).
>
> I probably forgot one or two and certainly dont want to back myself into
> a corner on committing to something here, but those are a few things I
> see today as big blockers on larger blocks.
>
> Luckily, people have been making progress on building the software
> needed in all of the above for a while now, but I think they're all
> very, very immature today.
>
> On 05/07/15 19:13, Jeff Garzik wrote:> On Thu, May 7, 2015 at 3:03 PM,
> Matt Corallo > > wrote:
> -snip-
>>> If, instead, there had been an intro on the list as "I think we should
>>> do the blocksize increase soon, what do people think?", the response
>>> could likely have focused much more around creating a specific list of
>>> things we should do before we (the technical community) think we are
>>> prepared for a blocksize increase.
>>
>> Agreed, but that is water under the bridge at this point.  You - rightly
>> - opened the topi

Re: [Bitcoin-development] Block Size Increase Requirements

[Matt Corallo]

On 05/29/15 22:36, Gavin Andresen wrote:
> Matt brought this up on Twitter, I have no idea why I didn't respond
> weeks ago (busy writing blog posts, probably):
> 
> On Thu, May 7, 2015 at 6:02 PM, Matt Corallo  > wrote:
> 
> 
> 
>  * Though there are many proposals floating around which could
> significantly decrease block propagation latency, none of them are
> implemented today.
> 
> 
> If block propagation isn't fixed, then mines have a strong incentive to
> create smaller blocks.
> 
> So the max block size is irrelevant, it won't get hit.

Sadly, this is very far from the whole story. The issue of miners
optimizing for returns has been discussed several times during this
discussion, and, sadly, miners who are geographically colocated who are
optimizing for returns with a free-floating blocksize will optimize away
50% of the network!

> 
> In addition, I'd expect to
> see analysis of how these systems perform in the worst-case, not just
> packet-loss-wise, but in the face of miners attempting to break the
> system.
> 
> 
> See http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners for
> analysis of "but that means bigger miners can get an advantage" argument.
> 
> Executive summary: if little miners are stupid and produce huge blocks,
> then yes, big miners have an advantage.

I'll talk about transaction fees in a second, but there are several
problems with this already. As pointed out in the original mail, gfw has
already been known to interfere with Bitcoin P2P traffic. So now by
"little" miners, you mean any miner who is not located in mainland
China? Whats worse, the disadvantage is symmetric - little miners are at
a disadvantage when *anyone* mines a bigger block, and miners dont even
have to be "evil" for this to happen - just optimize for profits.

> But they're not, so they won't.

I dont know what you're referring to with this. Are you claiming little
miners today optimize for relay times and have good visibility into the
Bitcoin network and calculate an optimal block size based on this (or
would with a 20MB block size)?

> Until the block reward goes away, and assuming transaction fees become
> an important source of revenue for miners.
> I think it is too early to worry about that; see:
> 
>http://gavinandresen.ninja/when-the-block-reward-goes-away

You dont make any points here with which I can argue, but let me respond
with the reason /I/ think it is a problem worth thinking a little bit
about...If we increase the blocksize sufficiently such that transaction
fees are not the way in which miners make their money, then either
miners are not being funded (ie hashpower has to drop to very little),
or the only people mining/funding miners are large orgs who are
"running" Bitcoin (ie the web wallets, payment processors, big
merchants, and exchanges of the world). Sadly, this is no longer a
decentralized Bitcoin and is, in fact, pretty much how the banking world
works today.

I'm not sure who, if anyone, claims Bitcoin is novel or interesting for
any reason other than its decentralization properties, and, in a world
which you are apparently proposing, the "natural" course of things is to
very strongly centralize.

>  * I'd very much like to see someone working on better scaling
> technology, both in terms of development and in terms of getting
> traction in the marketplace. 
> 
> 
> Ok. What does this have to do with the max block size?
> 
> Are you arguing that work won't happen if the max block size increases?

Yes, I am arguing that by increasing the blocksize the incentives to
actually make Bitcoin scale go away. Even if amazing technologies get
built, no one will have any reason to use them.

>   * I'd like to see some better conclusions to the discussion around
> 
> long-term incentives within the system.
> 
> 
> Again, see http://gavinandresen.ninja/when-the-block-reward-goes-away
> for what I think about that.

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase Requirements

[Gavin Andresen]

Matt brought this up on Twitter, I have no idea why I didn't respond weeks
ago (busy writing blog posts, probably):

On Thu, May 7, 2015 at 6:02 PM, Matt Corallo 
wrote:

>
>
>  * Though there are many proposals floating around which could
> significantly decrease block propagation latency, none of them are
> implemented today.


If block propagation isn't fixed, then mines have a strong incentive to
create smaller blocks.

So the max block size is irrelevant, it won't get hit.


> In addition, I'd expect to
> see analysis of how these systems perform in the worst-case, not just
> packet-loss-wise, but in the face of miners attempting to break the system.
>

See http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners
for analysis of "but that means bigger miners can get an advantage"
argument.

Executive summary: if little miners are stupid and produce huge blocks,
then yes, big miners have an advantage.

But they're not, so they won't.

Until the block reward goes away, and assuming transaction fees become an
important source of revenue for miners.
I think it is too early to worry about that; see:

   http://gavinandresen.ninja/when-the-block-reward-goes-away


>  * I'd very much like to see someone working on better scaling
> technology, both in terms of development and in terms of getting
> traction in the marketplace.


Ok. What does this have to do with the max block size?

Are you arguing that work won't happen if the max block size increases?

  * I'd like to see some better conclusions to the discussion around

> long-term incentives within the system.


Again, see http://gavinandresen.ninja/when-the-block-reward-goes-away for
what I think about that.

-- 
--
Gavin Andresen
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase Requirements

[Tier Nolan]

On Sat, May 16, 2015 at 5:39 AM, Stephen 
wrote:

> I think this could be mitigated by counting confirmations differently. We
> should think of confirmations as only coming from blocks following the
> miners' more strict rule set. So if a merchant were to see payment for the
> first time in a block that met their own size restrictions but not the
> miners', then they would simply count it as unconfirmed.
>

In effect, there is a confirm penalty for less strict blocks.  Confirms =
max(miner_confirms, merchant_confirms - 3, 0)

Merchants who don't upgrade end up having to wait longer to hit
confirmations.

If they get deep enough in the chain, though, the client should probably
> count them as being confirmed anyway, even if they don't meet the client
> nodes' expectation of the miners' block size limit. This happening probably
> just means that the client has not updated their software (or
> -minermaxblocksize configuration, depending on how it is implemented) in a
> long time.
>

That is a good idea.  Any parameters that have miner/merchant differences
should be modifiable (but only upwards) in the command line.

"Why are my transactions taking longer to confirm?"

"There was a soft fork to make the block size larger and your client is
being careful.  You need to add "minermaxblocksize=4MB" to your
bitcoin.conf file."

Hah, it could be called a "semi-hard fork"?
--
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

Re: [Bitcoin-development] Block Size Increase Requirements

[Tier Nolan]

On Sat, May 9, 2015 at 4:08 AM, Peter Todd  wrote:

> > I wonder if having a "miner" flag would be good for the network.
>
> Makes it trivial to find miners and DoS attack them - a huge risk to the
> network as a whole, as well as the miners.
>

To mitigate against this, two chaintips could be tracked.  The miner tip
and the client tip.

Miners would build on the miner tip.  When performing client services, like
wallets, they would use the client tip.

The client would act exactly the same as any node, the only change would be
that it gives miner work based on the mining tip.

If the two tips end up significantly forking, there would be a warning to
the miner and perhaps eventually refuse to give out new work.

That would happen when there was a miner level hard-fork.


> That'd be an excellent way to double-spend merchants, significantly
> increasing the chance that the double-spend would succeed as you only
> have to get sufficient hashing power to get the lucky blocks; you don't
> need enough hashing power to *also* ensure those blocks don't become the
> longest chain, removing the need to sybil attack your target.
>

To launch that attack, you need to produce fake blocks.  That is
expensive.

Stephen Cale's suggestion to wait more than one block before counting a
transaction as confirmed would also help mitigate.
--
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

Re: [Bitcoin-development] Block Size Increase Requirements

[Stephen]

Comments in line:

> On May 8, 2015, at 11:08 PM, Peter Todd  wrote:
> 
> Makes it trivial to find miners and DoS attack them - a huge risk to the
> network as a whole, as well as the miners.
> 
> Right now pools already get DoSed all the time through their work
> submission systems; getting DoS attacked via their nodes as well would
> be a disaster.

It seems that using a -miner flag to follow rules about smaller blocks would 
only reveal miner nodes if one sent the node a solved block that that was valid 
in every way except the block size. While not impossible, I wouldn't call this 
trivial, as it still requires wasting an entire block's worth of energy. 

>> When in "miner mode", the client would reject 4MB blocks and wouldn't build
>> on them.  The reference client might even track the miner and the non-miner
>> chain tip.
>> 
>> Miners would refuse to build on 5MB blocks, but merchants and general users
>> would accept them.
> 
> That'd be an excellent way to double-spend merchants, significantly
> increasing the chance that the double-spend would succeed as you only
> have to get sufficient hashing power to get the lucky blocks; you don't
> need enough hashing power to *also* ensure those blocks don't become the
> longest chain, removing the need to sybil attack your target.
> 

I think this could be mitigated by counting confirmations differently. We 
should think of confirmations as only coming from blocks following the miners' 
more strict rule set. So if a merchant were to see payment for the first time 
in a block that met their own size restrictions but not the miners', then they 
would simply count it as unconfirmed. 

If they get deep enough in the chain, though, the client should probably count 
them as being confirmed anyway, even if they don't meet the client nodes' 
expectation of the miners' block size limit. This happening probably just means 
that the client has not updated their software (or -minermaxblocksize 
configuration, depending on how it is implemented) in a long time. 

I actually like Tier's suggestion quite a bit. I think we could have the 
default client limit set to some higher number, and have miners agree out of 
band on the latest block size limit. Or maybe even build in a way to vote into 
the blockchain. 

Best, 
Stephen
--
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

Re: [Bitcoin-development] Block Size Increase

[Angel Leon]

> Personally, for privacy reasons I do not want to leave a footprint in the
blockchain for each pizza. And  why should this expense be good for trivial
things of everyday life?

Then what's the point?
Isn't this supposed to be an Open transactional network, it doesn't matter
if you don't want that, what matters is what people want to do with it, and
there's nothing you can do to stop someone from opening a wallet and buying
a pizza with it, except the core of the problem you ask yourself about,
which is, the minute this goes mainstream and people get their wallets out
the whole thing will collapse, regardless of what you want the blockchain
for.

Why talk about the billions of unbanked and all the romantic vision if you
can't let them use their money however they want in a decentralized
fashion. Otherwise let's just go back to centralized banking because the
minute you want to put things off chain, you need an organization that will
need to respond to government regulation and that's the end for the
billions of unbanked to be part of the network.


http://twitter.com/gubatron

On Wed, May 13, 2015 at 6:37 AM, Oliver Egginger  wrote:

> 08.05.2015 at 5:49 Jeff Garzik wrote:
> > To repeat, the very first point in my email reply was: "Agree that 7 tps
> > is too low"
>
> For interbank trading that would maybe enough but I don't know.
>
> I'm not a developer but as a (former) user and computer scientist I'm
> also asking myself what is the core of the problem? Personally, for
> privacy reasons I do not want to leave a footprint in the blockchain for
> each pizza. And why should this expense be good for trivial things of
> everyday life?
>
> If one encounters the block boundary, he or she will do more effort or
> give up. I'm thinking most people will give up because their
> transactions are not really economical. It is much better for them to
> use third-partys (or another payment system).
>
> And that's where we are at the heart of the problem. The Bitcoin
> third-party economy. With few exceptions this is pure horror. More worse
> than any used car dealer. And the community just waits that things get
> better. But that will never happen of its own accord. We are living in a
> Wild West Town. So we need a Sheriff and many other things.
>
> We need a small but good functioning economy around the blockchain. To
> create one, we have to accept a few unpleasant truths. I do not know if
> the community is ready for it.
>
> Nevertheless, I know that some companies do a good job. But they have to
> prevail against their dishonest competitors.
>
> People take advantage of the blockchain, because they no longer trust
> anyone. But this will not scale in the long run.
>
> - oliver
>
>
>
>
>
>
>
>
>
> --
> 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
>
--
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

Re: [Bitcoin-development] Block Size Increase

[Oliver Egginger]

08.05.2015 at 5:49 Jeff Garzik wrote:
> To repeat, the very first point in my email reply was: "Agree that 7 tps
> is too low"  

For interbank trading that would maybe enough but I don't know.

I'm not a developer but as a (former) user and computer scientist I'm
also asking myself what is the core of the problem? Personally, for
privacy reasons I do not want to leave a footprint in the blockchain for
each pizza. And why should this expense be good for trivial things of
everyday life?

If one encounters the block boundary, he or she will do more effort or
give up. I'm thinking most people will give up because their
transactions are not really economical. It is much better for them to
use third-partys (or another payment system).

And that's where we are at the heart of the problem. The Bitcoin
third-party economy. With few exceptions this is pure horror. More worse
than any used car dealer. And the community just waits that things get
better. But that will never happen of its own accord. We are living in a
Wild West Town. So we need a Sheriff and many other things.

We need a small but good functioning economy around the blockchain. To
create one, we have to accept a few unpleasant truths. I do not know if
the community is ready for it.

Nevertheless, I know that some companies do a good job. But they have to
prevail against their dishonest competitors.

People take advantage of the blockchain, because they no longer trust
anyone. But this will not scale in the long run.

- oliver








--
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

Re: [Bitcoin-development] Block Size Increase

[Andrew]

On Sat, May 9, 2015 at 12:53 PM, Justus Ranvier 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 05/09/2015 02:02 PM, Andrew wrote:
> > The nice thing about 1 MB is that you can store ALL bitcoin
> > transactions relevant to your lifetime (~100 years) on one 5 TB
> > hard drive (1*6*24*365*100=5256000). Any regular person can run a
> > full node and store this 5 TB hard drive easily at their home. With
> > 10 MB blocks you need a 50 TB drive just for your bitcoin
> > transactions! This is not doable for most regular people due to
> > space and monetary constraints. Being able to review all
> > transactions relevant to your lifetime is one of the key important
> > properties of Bitcoin. How else can people audit the financial
> > transactions of companies and governments that are using the
> > Bitcoin blockchain? How else can we achieve this level of
> > transparency that is essential to keeping corrupt
> > governments/companies in check? How else can we keep track of our
> > own personal transactions without relying on others to keep track
> > of them for us? As time passes, storage technology may increase,
> > but so may human life expectancy. So yes, in this sense, 1 MB just
> > may be the magic number.
>
> How many individuals and companies do you propose will ever use
> Bitcoin (order of magnitude estimates are fine)
>
> Whatever number you select above, please describe approximately how
> many lifetime Bitcoin transactions each individual and company will be
> capable of performing with a 1 MB block size limit.
>

I would expect at least 10 billion people (directly or indirectly) to be
using it at once for at least 100 years. But I think it's pointless to
guess how many will use it, but rather make the system ready for 10 billion
people. The point is that for small transactions, they will be done
off-chain. The actual Bitcoin blockchain will only show very large
transactions (such as a military purchasing a new space shuttle) or
aggregate transactions (i.e. a transaction consisting of multiple smaller
transactions done off-chain). There can also be multiple layers of chains
creating a tree-like structure. Each chain above will validate the
aggregate transactions of the chain below. You can think of the Bitcoin
blockchain as the "hypervisor" that manages all the other chains. While
your coffee purchase 4 days ago may not be directly visible within the
Bitcoin blockchain (the main chain), you can trace it down the sequence of
chains until you find it. Same with that fancy dinner your government MP
paid for using public funds. You don't have to store a copy of all
transactions that occurred for each chain in existence, but rather just the
transactions for the chains that you use or are relevant to you.

As you see, this kind of system is totally transparent to all users and
totally flexible (you can choose your sub chains). The flexibility also
allows you to have arbitrarily fast transactions (choose a chain or
lightning channel attached to that chain that supports it), and you can
enjoy a wide variety of features from other chains, like using one chain
that is known to have good anonymity properties.


> -BEGIN PGP SIGNATURE-
>
> iQIcBAEBAgAGBQJVTgNcAAoJECpf2nDq2eYjM8AP/2kwSF+HMPR1KdaZsATL4rog
> xSS97Q5iEX8StA61jUqHQmpXL5pG6z5DeeKT/liwcMnYnVqOEOLvoVctr3gXfgRz
> 9GJeTOlmN5l9xBeX/nWa0A2ql0kWZpYolBS1FwYadWReAD8R0X9UeBd9YXLZNy33
> Ow9JjwRjKHhsuyrlMP8pRDKlGPoa/U+2aW4FwiysMLa0Gu6dbFjTrp3bHw4Fccpi
> X0E/aDN68U4FV+lZ4NzkMsBK9VARzmC8KI0DQ540pqfkcnyoYf0VERl/gslPWhfq
> t6Rqa7vHHMqFe82lgCd3ji8Qhsz8oBrDS4u4jqwATvgihgImOB6K85JoKmf3y2JS
> jByjMGd4Ep0F80Z2MRhi6HuEoRU69uY2u6l9bZxMjzvLX8sG6QTNk3uLMS3ARXcY
> JBjZ/g13DXgcRj01fq05CHbCTJYZgTA9pRZTY+ZKH4r0mu86b9ua7hjvyKHS6q54
> uaFmRkNcnKlpCY+fvH/JUdvvmwrA0ETUdHhRyk8vzWIMi+aH4//GwrCmBNRrugzv
> 9JtQ1BC+tQqtSX2VkFEhAVISitgkBqurVVlGk18FvVKPFO8cnFS/6NWoPE0WLLzW
> 2pTuhEPjdz9UAHD3RW601rb4C0LbuwVlGO4tYBjyqCmk/vBlES2XIjQKctXZLBEy
> eLgn3gMwEXUTU6UdGyvb
> =RPhK
> -END PGP SIGNATURE-
>
>
> --
> 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
>
>


-- 
PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
--
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 v

Re: [Bitcoin-development] Block Size Increase

[Justus Ranvier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/09/2015 02:02 PM, Andrew wrote:
> The nice thing about 1 MB is that you can store ALL bitcoin
> transactions relevant to your lifetime (~100 years) on one 5 TB
> hard drive (1*6*24*365*100=5256000). Any regular person can run a
> full node and store this 5 TB hard drive easily at their home. With
> 10 MB blocks you need a 50 TB drive just for your bitcoin
> transactions! This is not doable for most regular people due to
> space and monetary constraints. Being able to review all
> transactions relevant to your lifetime is one of the key important 
> properties of Bitcoin. How else can people audit the financial
> transactions of companies and governments that are using the
> Bitcoin blockchain? How else can we achieve this level of
> transparency that is essential to keeping corrupt
> governments/companies in check? How else can we keep track of our 
> own personal transactions without relying on others to keep track
> of them for us? As time passes, storage technology may increase,
> but so may human life expectancy. So yes, in this sense, 1 MB just
> may be the magic number.

How many individuals and companies do you propose will ever use
Bitcoin (order of magnitude estimates are fine)

Whatever number you select above, please describe approximately how
many lifetime Bitcoin transactions each individual and company will be
capable of performing with a 1 MB block size limit.

-BEGIN PGP SIGNATURE-

iQIcBAEBAgAGBQJVTgNcAAoJECpf2nDq2eYjM8AP/2kwSF+HMPR1KdaZsATL4rog
xSS97Q5iEX8StA61jUqHQmpXL5pG6z5DeeKT/liwcMnYnVqOEOLvoVctr3gXfgRz
9GJeTOlmN5l9xBeX/nWa0A2ql0kWZpYolBS1FwYadWReAD8R0X9UeBd9YXLZNy33
Ow9JjwRjKHhsuyrlMP8pRDKlGPoa/U+2aW4FwiysMLa0Gu6dbFjTrp3bHw4Fccpi
X0E/aDN68U4FV+lZ4NzkMsBK9VARzmC8KI0DQ540pqfkcnyoYf0VERl/gslPWhfq
t6Rqa7vHHMqFe82lgCd3ji8Qhsz8oBrDS4u4jqwATvgihgImOB6K85JoKmf3y2JS
jByjMGd4Ep0F80Z2MRhi6HuEoRU69uY2u6l9bZxMjzvLX8sG6QTNk3uLMS3ARXcY
JBjZ/g13DXgcRj01fq05CHbCTJYZgTA9pRZTY+ZKH4r0mu86b9ua7hjvyKHS6q54
uaFmRkNcnKlpCY+fvH/JUdvvmwrA0ETUdHhRyk8vzWIMi+aH4//GwrCmBNRrugzv
9JtQ1BC+tQqtSX2VkFEhAVISitgkBqurVVlGk18FvVKPFO8cnFS/6NWoPE0WLLzW
2pTuhEPjdz9UAHD3RW601rb4C0LbuwVlGO4tYBjyqCmk/vBlES2XIjQKctXZLBEy
eLgn3gMwEXUTU6UdGyvb
=RPhK
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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

Re: [Bitcoin-development] Block Size Increase

[Andrew]

The nice thing about 1 MB is that you can store ALL bitcoin transactions
relevant to your lifetime (~100 years) on one 5 TB hard drive
(1*6*24*365*100=5256000). Any regular person can run a full node and store
this 5 TB hard drive easily at their home. With 10 MB blocks you need a 50
TB drive just for your bitcoin transactions! This is not doable for most
regular people due to space and monetary constraints. Being able to review
all transactions relevant to your lifetime is one of the key important
properties of Bitcoin. How else can people audit the financial transactions
of companies and governments that are using the Bitcoin blockchain? How
else can we achieve this level of transparency that is essential to keeping
corrupt governments/companies in check? How else can we keep track of our
own personal transactions without relying on others to keep track of them
for us? As time passes, storage technology may increase, but so may human
life expectancy. So yes, in this sense, 1 MB just may be the magic number.

Assuming that we have a perfectly functional off-chain transaction system,
what do we actually gain by going from 1 MB to 1000 MB (my approximate
limit for regular users having enough processing power)? If there is no
clear and substantial gain, then it is foolish to venture into this
territory, i.e. KEEP IT AT 1 MB! For example Angel said he wants to see
computers transacting with computers at super speeds. Why do you need to do
this on the main chain? You will lose all the transparency of the current
system, an essential feature.


On Fri, May 8, 2015 at 10:36 PM, Angel Leon  wrote:

> I believe 100MB is still very conservative, I think that's barely 666 tps.
>
> I also find it not very creative that people are imagining these limits
> for 10 billion people using bitcoin, I think bitcoin's potential is
> realized with computers transacting with computers, which can eat those 666
> tps in a single scoup (what if bittorrent developers got creative with
> seeding, or someone created a decentralized paid itunes on top of bitcoin,
> or the openbazaar developers actually pulled a decentralized amazon with no
> off-chain transaction since they want the thing to be fully decentralized,
> bitcoin would collapse right away)
>
> I truly hope people see past regular people running nodes at home, that's
> never going to happen. This should be about the miner's networking, storage
> and cpu capacity. They will have gigabit access, they will have shitload of
> storage, and they already have plenty of processing power, all of which are
> only going to get cheaper.
>
> In order to have the success we all dream we'll need gigabit blocks. Let's
> hope adoption remains slow.
>
> http://twitter.com/gubatron
>
> On Fri, May 8, 2015 at 1:51 PM, Alan Reiner  wrote:
>
>> Actually I believe that side chains and off-main-chain transactions will
>> be a critical part for the overall scalability of the network.  I was
>> actually trying to make the point that (insert some huge block size here)
>> will be needed to even accommodate the reduced traffic.
>>
>> I believe that it is definitely over 20MB. If it was determined to be 100
>> MB ten years from now, that wouldn't surprise me.
>>
>> Sent from my overpriced smartphone
>> On May 8, 2015 1:17 PM, "Andrew"  wrote:
>>
>>>
>>>
>>> On Fri, May 8, 2015 at 2:59 PM, Alan Reiner  wrote:
>>>

 This isn't about "everyone's coffee".  This is about an absolute
 minimum amount of participation by people who wish to use the network.   If
 our goal is really for bitcoin to really be a global, open transaction
 network that makes money fluid, then 7tps is already a failure.  If even 5%
 of the world (350M people) was using the network for 1 tx per month
 (perhaps to open payment channels, or shift money between side chains),
 we'll be above 100 tps.  And that doesn't include all the non-individuals
 (organizations) that want to use it.

>>>
 The goals of "a global transaction network" and "everyone must be able
 to run a full node with their $200 dell laptop" are not compatible.  We
 need to accept that a global transaction system cannot be fully/constantly
 audited by everyone and their mother.  The important feature of the network
 is that it is open and anyone *can* get the history and verify it.  But not
 everyone is required to.   Trying to promote a system wher000e the history
 can be forever handled by a low-end PC is already falling out of reach,
 even with our miniscule 7 tps.  Clinging to that goal needlessly limits the
 capability for the network to scale to be a useful global payments system

>>>
>>> These are good points and got me thinking (but I think you're wrong). If
>>> we really want each of the 10 billion people soon using bitcoin once per
>>> month, that will require 500MB blocks. That's about 2 TB per month. And if
>>> you relay it to 4 peers, it's 10 TB per month. Which I suppose is doable

Re: [Bitcoin-development] Block Size Increase Requirements

[Peter Todd]

On Fri, May 08, 2015 at 08:47:52PM +0100, Tier Nolan wrote:
> On Fri, May 8, 2015 at 5:37 PM, Peter Todd  wrote:
> 
> > The soft-limit is there miners themselves produce smaller blocks; the
> > soft-limit does not prevent other miners from producing larger blocks.
> >
> 
> I wonder if having a "miner" flag would be good for the network.

Makes it trivial to find miners and DoS attack them - a huge risk to the
network as a whole, as well as the miners.

Right now pools already get DoSed all the time through their work
submission systems; getting DoS attacked via their nodes as well would
be a disaster.

> When in "miner mode", the client would reject 4MB blocks and wouldn't build
> on them.  The reference client might even track the miner and the non-miner
> chain tip.
> 
> Miners would refuse to build on 5MB blocks, but merchants and general users
> would accept them.

That'd be an excellent way to double-spend merchants, significantly
increasing the chance that the double-spend would succeed as you only
have to get sufficient hashing power to get the lucky blocks; you don't
need enough hashing power to *also* ensure those blocks don't become the
longest chain, removing the need to sybil attack your target.

-- 
'peter'[:-1]@petertodd.org
04bd67400df7577a30e6f509b6bd82633efeabe6395eb65a


signature.asc
Description: Digital signature
--
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

Re: [Bitcoin-development] Block Size Increase

[Raystonn]

Replace by fee is the better approach.  It will ultimately replace zombie transactions (due to insufficient fee) with potentially much higher fees as the feature takes hold in wallets throughout the network, and fee competition increases.  However, this does not fix the problem of low tps.  In fact, as blocks fill it could make the problem worse.  This feature means more transactions after all.  So I would expect huge fee spikes, or a return to zombie transactions if fee caps are implemented by wallets.
-Raystonn

On 8 May 2015 1:55 pm, Mark Friedenbach  wrote:The problems with that are larger than time being unreliable. It is no longer reorg-safe as transactions can expire in the course of a reorg and any transaction built on the now expired transaction is invalidated.On Fri, May 8, 2015 at 1:51 PM, Raystonn  wrote:Replace by fee is what I was referencing.  End-users interpret the old transaction as expired.  Hence the nomenclature.  An alternative is a new feature that operates in the reverse of time lock, expiring a transaction after a specific time.  But time is a bit unreliable in the blockchain
--
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

Re: [Bitcoin-development] Block Size Increase (Raystonn)

[Damian Gomez]

Hello,

I was reading some of the thread but can't say I read the entire thing.

I think that it is realistic to cinsider a nlock sixe of 20MB for any block
txn to occur. THis is an enormous amount of data (relatively for a netwkrk)
in which the avergage rate of 10tps over 10 miniutes would allow for
fewasible transformation of data at this curent point in time.

Though I do not see what extra hash information would be stored in the
overall ecosystem as we begin to describe what the scripts that are
atacrhed tp the blockchain would carry,

I'd therefore think that for the remainder of this year that it is possible
to have a block chain within 200 - 300 bytes that is more charatereistic of
some feasible attempts at attaching nuanced data in order to keep propliifc
the blockchain but have these identifiers be integral OPSIg of the the
entiore block. THe reasoning behind this has to do with encryption
standards that can be added toe a chain such as th DH algoritnm keys that
would allow for a higher integrity level withinin the system as it is.
Cutrent;y tyh prootocl oomnly controls for the amount of transactions
through if TxnOut script and the publin key coming form teh lcoation of the
proof-of-work. Form this then I think that a rate of higher than then
current standard of 92bytes allows for GPUS ie CUDA to perfirm its standard
operations of  1216 flops   in rde rto mechanize a new personal identity
within the chain that also attaches an encrypted instance of a further
categorical variable that we can prsribved to it.

I think with the current BIP7 prootclol for transactions there is an area
of vulnerability for man-in-the-middle attacks upon request of  bitcin to
any merchant as is. It would contraidct the security of the bitcoin if it
was intereceptefd iand not allowed to reach tthe payment network or if the
hash was reveresed in orfr to change the value it had. Therefore the
current best fit block size today is between 200 - 300 bytws (depending on
how exciteed we get)



Thanks for letting me join the conversation
I welcomes any vhalleneged and will reply with more research as i figure
out what problems are revealed in my current formation of thoughts (sorry
for the errors but i am just trying to move forward ---> THE DELRERT KEY
LITERALLY PREVENTS IT )


_Damian
--
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

Re: [Bitcoin-development] Block Size Increase

[Mark Friedenbach]

Transactions don't expire. But if the wallet is online, it can periodically
choose to release an already created transaction with a higher fee. This
requires replace-by-fee to be sufficiently deployed, however.

On Fri, May 8, 2015 at 1:38 PM, Raystonn .  wrote:

> I have a proposal for wallets such as yours.  How about creating all
> transactions with an expiration time starting with a low fee, then
> replacing with new transactions that have a higher fee as time passes.
> Users can pick the fee curve they desire based on the transaction priority
> they want to advertise to the network.  Users set the priority in the
> wallet, and the wallet software translates it to a specific fee curve used
> in the series of expiring transactions.  In this manner, transactions are
> never left hanging for days, and probably not even for hours.
>
> -Raystonn
>  On 8 May 2015 1:17 pm, Aaron Voisine  wrote:
>
> As the author of a popular SPV wallet, I wanted to weigh in, in support of
> the Gavin's 20Mb block proposal.
>
> The best argument I've heard against raising the limit is that we need fee
> pressure.  I agree that fee pressure is the right way to economize on
> scarce resources. Placing hard limits on block size however is an
> incredibly disruptive way to go about this, and will severely negatively
> impact users' experience.
>
> When users pay too low a fee, they should:
>
> 1) See immediate failure as they do now with fees that fail to propagate.
>
> 2) If the fee lower than it should be but not terminal, they should see
> degraded performance, long delays in confirmation, but eventual success.
> This will encourage them to pay higher fees in future.
>
> The worst of all worlds would be to have transactions propagate, hang in
> limbo for days, and then fail. This is the most important scenario to
> avoid. Increasing the 1Mb block size limit I think is the simplest way to
> avoid this least desirable scenario for the immediate future.
>
> We can play around with improved transaction selection for blocks and
> encourage miners to adopt it to discourage low fees and create fee
> pressure. These could involve hybrid priority/fee selection so low fee
> transactions see degraded performance instead of failure. This would be the
> conservative low risk approach.
>
> Aaron Voisine
> co-founder and CEO
> breadwallet.com
>
>
>
> --
> 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
>
>
--
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

Re: [Bitcoin-development] Block Size Increase

[Mark Friedenbach]

The problems with that are larger than time being unreliable. It is no
longer reorg-safe as transactions can expire in the course of a reorg and
any transaction built on the now expired transaction is invalidated.

On Fri, May 8, 2015 at 1:51 PM, Raystonn  wrote:

> Replace by fee is what I was referencing.  End-users interpret the old
> transaction as expired.  Hence the nomenclature.  An alternative is a new
> feature that operates in the reverse of time lock, expiring a transaction
> after a specific time.  But time is a bit unreliable in the blockchain
>
--
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

Re: [Bitcoin-development] Block Size Increase

[Raystonn]

Replace by fee is what I was referencing.  End-users interpret the old 
transaction as expired.  Hence the nomenclature.  An alternative is a new 
feature that operates in the reverse of time lock, expiring a transaction after 
a specific time.  But time is a bit unreliable in the blockchain

-Raystonn


On 8 May 2015 1:41 pm, Mark Friedenbach  wrote:
>
> Transactions don't expire. But if the wallet is online, it can periodically 
> choose to release an already created transaction with a higher fee. This 
> requires replace-by-fee to be sufficiently deployed, however.
>
> On Fri, May 8, 2015 at 1:38 PM, Raystonn .  wrote:
>>
>> I have a proposal for wallets such as yours.  How about creating all 
>> transactions with an expiration time starting with a low fee, then replacing 
>> with new transactions that have a higher fee as time passes.  Users can pick 
>> the fee curve they desire based on the transaction priority they want to 
>> advertise to the network.  Users set the priority in the wallet, and the 
>> wallet software translates it to a specific fee curve used in the series of 
>> expiring transactions.  In this manner, transactions are never left hanging 
>> for days, and probably not even for hours.
>>
>> -Raystonn
>>
>> On 8 May 2015 1:17 pm, Aaron Voisine  wrote:
>>>
>>> As the author of a popular SPV wallet, I wanted to weigh in, in support of 
>>> the Gavin's 20Mb block proposal.
>>>
>>> The best argument I've heard against raising the limit is that we need fee 
>>> pressure.  I agree that fee pressure is the right way to economize on 
>>> scarce resources. Placing hard limits on block size however is an 
>>> incredibly disruptive way to go about this, and will severely negatively 
>>> impact users' experience.
>>>
>>> When users pay too low a fee, they should:
>>>
>>> 1) See immediate failure as they do now with fees that fail to propagate.
>>>
>>> 2) If the fee lower than it should be but not terminal, they should see 
>>> degraded performance, long delays in confirmation, but eventual success. 
>>> This will encourage them to pay higher fees in future.
>>>
>>> The worst of all worlds would be to have transactions propagate, hang in 
>>> limbo for days, and then fail. This is the most important scenario to 
>>> avoid. Increasing the 1Mb block size limit I think is the simplest way to 
>>> avoid this least desirable scenario for the immediate future.
>>>
>>> We can play around with improved transaction selection for blocks and 
>>> encourage miners to adopt it to discourage low fees and create fee 
>>> pressure. These could involve hybrid priority/fee selection so low fee 
>>> transactions see degraded performance instead of failure. This would be the 
>>> conservative low risk approach.
>>>
>>> Aaron Voisine
>>> co-founder and CEO
>>> breadwallet.com
>>
>>
>> --
>> 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
>>
>
--
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

Re: [Bitcoin-development] Block Size Increase

[Raystonn .]

I have a proposal for wallets such as yours.  How about creating all transactions with an expiration time starting with a low fee, then replacing with new transactions that have a higher fee as time passes.  Users can pick the fee curve they desire based on the transaction priority they want to advertise to the network.  Users set the priority in the wallet, and the wallet software translates it to a specific fee curve used in the series of expiring transactions.  In this manner, transactions are never left hanging for days, and probably not even for hours.
-Raystonn

On 8 May 2015 1:17 pm, Aaron Voisine  wrote:As the author of a popular SPV wallet, I wanted to weigh in, in support of the Gavin's 20Mb block proposal.The best argument I've heard against raising the limit is that we need fee pressure.  I agree that fee pressure is the right way to economize on scarce resources. Placing hard limits on block size however is an incredibly disruptive way to go about this, and will severely negatively impact users' experience.When users pay too low a fee, they should:1) See immediate failure as they do now with fees that fail to propagate.2) If the fee lower than it should be but not terminal, they should see degraded performance, long delays in confirmation, but eventual success. This will encourage them to pay higher fees in future.The worst of all worlds would be to have transactions propagate, hang in limbo for days, and then fail. This is the most important scenario to avoid. Increasing the 1Mb block size limit I think is the simplest way to avoid this least desirable scenario for the immediate future.We can play around with improved transaction selection for blocks and encourage miners to adopt it to discourage low fees and create fee pressure. These could involve hybrid priority/fee selection so low fee transactions see degraded performance instead of failure. This would be the conservative low risk approach.Aaron Voisineco-founder and CEObreadwallet.com
--
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

Re: [Bitcoin-development] Block Size Increase

[Aaron Voisine]

As the author of a popular SPV wallet, I wanted to weigh in, in support of
the Gavin's 20Mb block proposal.

The best argument I've heard against raising the limit is that we need fee
pressure.  I agree that fee pressure is the right way to economize on
scarce resources. Placing hard limits on block size however is an
incredibly disruptive way to go about this, and will severely negatively
impact users' experience.

When users pay too low a fee, they should:

1) See immediate failure as they do now with fees that fail to propagate.

2) If the fee lower than it should be but not terminal, they should see
degraded performance, long delays in confirmation, but eventual success.
This will encourage them to pay higher fees in future.

The worst of all worlds would be to have transactions propagate, hang in
limbo for days, and then fail. This is the most important scenario to
avoid. Increasing the 1Mb block size limit I think is the simplest way to
avoid this least desirable scenario for the immediate future.

We can play around with improved transaction selection for blocks and
encourage miners to adopt it to discourage low fees and create fee
pressure. These could involve hybrid priority/fee selection so low fee
transactions see degraded performance instead of failure. This would be the
conservative low risk approach.

Aaron Voisine
co-founder and CEO
breadwallet.com
--
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

Re: [Bitcoin-development] Block Size Increase Requirements

[Tier Nolan]

On Fri, May 8, 2015 at 5:37 PM, Peter Todd  wrote:

> The soft-limit is there miners themselves produce smaller blocks; the
> soft-limit does not prevent other miners from producing larger blocks.
>

I wonder if having a "miner" flag would be good for the network.

Clients for general users and merchants would have a less strict rule than
the rule for miners.  Miners who don't set their miners flag might get
orphaned off the chain.

For example, the limits could be setup as follows.

Clients: 20MB
Miners: 4MB

When in "miner mode", the client would reject 4MB blocks and wouldn't build
on them.  The reference client might even track the miner and the non-miner
chain tip.

Miners would refuse to build on 5MB blocks, but merchants and general users
would accept them.

This allows the miners to soft fork the limit at some point in the future.
If 75% of miners decided to up the limit to 8MB, then all merchants and the
general users would accept the new blocks.  It could follow the standard
soft fork rules.

This is a more general version of the system where miners are allowed to
vote on the block size (subject to a higher limit).

A similar system is where clients track all header trees.  Your wallet
could warn you that there is an invalid tree that has > 75% of the hashing
power and you might want to upgrade.
--
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

Re: [Bitcoin-development] Block Size Increase

[Alan Reiner]

Actually I believe that side chains and off-main-chain transactions will be
a critical part for the overall scalability of the network.  I was actually
trying to make the point that (insert some huge block size here) will be
needed to even accommodate the reduced traffic.

I believe that it is definitely over 20MB. If it was determined to be 100
MB ten years from now, that wouldn't surprise me.

Sent from my overpriced smartphone
On May 8, 2015 1:17 PM, "Andrew"  wrote:

>
>
> On Fri, May 8, 2015 at 2:59 PM, Alan Reiner  wrote:
>
>>
>> This isn't about "everyone's coffee".  This is about an absolute minimum
>> amount of participation by people who wish to use the network.   If our
>> goal is really for bitcoin to really be a global, open transaction network
>> that makes money fluid, then 7tps is already a failure.  If even 5% of the
>> world (350M people) was using the network for 1 tx per month (perhaps to
>> open payment channels, or shift money between side chains), we'll be above
>> 100 tps.  And that doesn't include all the non-individuals (organizations)
>> that want to use it.
>>
>
>> The goals of "a global transaction network" and "everyone must be able to
>> run a full node with their $200 dell laptop" are not compatible.  We need
>> to accept that a global transaction system cannot be fully/constantly
>> audited by everyone and their mother.  The important feature of the network
>> is that it is open and anyone *can* get the history and verify it.  But not
>> everyone is required to.   Trying to promote a system wher000e the history
>> can be forever handled by a low-end PC is already falling out of reach,
>> even with our miniscule 7 tps.  Clinging to that goal needlessly limits the
>> capability for the network to scale to be a useful global payments system
>>
>
> These are good points and got me thinking (but I think you're wrong). If
> we really want each of the 10 billion people soon using bitcoin once per
> month, that will require 500MB blocks. That's about 2 TB per month. And if
> you relay it to 4 peers, it's 10 TB per month. Which I suppose is doable
> for a home desktop, so you can just run a pruned full node with all
> transactions from the past month. But how do you sync all those
> transactions if you've never done this before or it's been a while since
> you did? I think it currently takes at least 3 hours to fully sync 30 GB of
> transactions. So 2 TB will take 8 days, then you take a bit more time to
> sync the days that passed while you were syncing. So that's doable, but at
> a certain point, like 10 TB per month (still only 5 transactions per month
> per person), you will need 41 days to sync that month, so you will never
> catch up. So I think in order to keep the very important property of anyone
> being able to start clean and verify the thing, then we need to think of
> bitcoin as a system that does transactions for a large number of users at
> once in one transaction, and not a system where each person will make a
> ~monthly transaction on. We need to therefore rely on sidechains,
> treechains, lightning channels, etc...
>
> I'm not a bitcoin wizard and this is just my second post on this mailing
> list, so I may be missing something. So please someone, correct me if I'm
> wrong.
>
>>
>>
>>
>> On 05/07/2015 03:54 PM, Jeff Garzik wrote:
>>
>>  On Thu, May 7, 2015 at 3:31 PM, Alan Reiner  wrote:
>>
>>
>>>  (2) Leveraging fee pressure at 1MB to solve the problem is actually
>>> really a bad idea.  It's really bad while Bitcoin is still growing, and
>>> relying on fee pressure at 1 MB severely impacts attractiveness and
>>> adoption potential of Bitcoin (due to high fees and unreliability).  But
>>> more importantly, it ignores the fact that for a 7 tps is pathetic for a
>>> global transaction system.  It is a couple orders of magnitude too low for
>>> any meaningful commercial activity to occur.  If we continue with a cap of
>>> 7 tps forever, Bitcoin *will* fail.  Or at best, it will fail to be
>>> useful for the vast majority of the world (which probably leads to
>>> failure).  We shouldn't be talking about fee pressure until we hit 700 tps,
>>> which is probably still too low.
>>>
>>  [...]
>>
>>  1) Agree that 7 tps is too low
>>
>>  2) Where do you want to go?  Should bitcoin scale up to handle all the
>> world's coffees?
>>
>>  This is hugely unrealistic.  700 tps is 100MB blocks, 14.4 GB/day --
>> just for a single feed.  If you include relaying to multiple nodes, plus
>> serving 500 million SPV clients en grosse, who has the capacity to run such
>> a node?  By the time we get to fee pressure, in your scenario, our network
>> node count is tiny and highly centralized.
>>
>>  3) In RE "fee pressure" -- Do you see the moral hazard to a software-run
>> system?  It is an intentional, human decision to flood the market with
>> supply, thereby altering the economics, forcing fees to remain low in the
>> hopes of achieving adoption.  I'm pro-bitcoin and obviously want to se

Re: [Bitcoin-development] Block Size Increase

[Andrew]

On Fri, May 8, 2015 at 2:59 PM, Alan Reiner  wrote:

>
> This isn't about "everyone's coffee".  This is about an absolute minimum
> amount of participation by people who wish to use the network.   If our
> goal is really for bitcoin to really be a global, open transaction network
> that makes money fluid, then 7tps is already a failure.  If even 5% of the
> world (350M people) was using the network for 1 tx per month (perhaps to
> open payment channels, or shift money between side chains), we'll be above
> 100 tps.  And that doesn't include all the non-individuals (organizations)
> that want to use it.
>

> The goals of "a global transaction network" and "everyone must be able to
> run a full node with their $200 dell laptop" are not compatible.  We need
> to accept that a global transaction system cannot be fully/constantly
> audited by everyone and their mother.  The important feature of the network
> is that it is open and anyone *can* get the history and verify it.  But not
> everyone is required to.   Trying to promote a system wher000e the history
> can be forever handled by a low-end PC is already falling out of reach,
> even with our miniscule 7 tps.  Clinging to that goal needlessly limits the
> capability for the network to scale to be a useful global payments system
>

These are good points and got me thinking (but I think you're wrong). If we
really want each of the 10 billion people soon using bitcoin once per
month, that will require 500MB blocks. That's about 2 TB per month. And if
you relay it to 4 peers, it's 10 TB per month. Which I suppose is doable
for a home desktop, so you can just run a pruned full node with all
transactions from the past month. But how do you sync all those
transactions if you've never done this before or it's been a while since
you did? I think it currently takes at least 3 hours to fully sync 30 GB of
transactions. So 2 TB will take 8 days, then you take a bit more time to
sync the days that passed while you were syncing. So that's doable, but at
a certain point, like 10 TB per month (still only 5 transactions per month
per person), you will need 41 days to sync that month, so you will never
catch up. So I think in order to keep the very important property of anyone
being able to start clean and verify the thing, then we need to think of
bitcoin as a system that does transactions for a large number of users at
once in one transaction, and not a system where each person will make a
~monthly transaction on. We need to therefore rely on sidechains,
treechains, lightning channels, etc...

I'm not a bitcoin wizard and this is just my second post on this mailing
list, so I may be missing something. So please someone, correct me if I'm
wrong.

>
>
>
> On 05/07/2015 03:54 PM, Jeff Garzik wrote:
>
>  On Thu, May 7, 2015 at 3:31 PM, Alan Reiner  wrote:
>
>
>>  (2) Leveraging fee pressure at 1MB to solve the problem is actually
>> really a bad idea.  It's really bad while Bitcoin is still growing, and
>> relying on fee pressure at 1 MB severely impacts attractiveness and
>> adoption potential of Bitcoin (due to high fees and unreliability).  But
>> more importantly, it ignores the fact that for a 7 tps is pathetic for a
>> global transaction system.  It is a couple orders of magnitude too low for
>> any meaningful commercial activity to occur.  If we continue with a cap of
>> 7 tps forever, Bitcoin *will* fail.  Or at best, it will fail to be
>> useful for the vast majority of the world (which probably leads to
>> failure).  We shouldn't be talking about fee pressure until we hit 700 tps,
>> which is probably still too low.
>>
>  [...]
>
>  1) Agree that 7 tps is too low
>
>  2) Where do you want to go?  Should bitcoin scale up to handle all the
> world's coffees?
>
>  This is hugely unrealistic.  700 tps is 100MB blocks, 14.4 GB/day --
> just for a single feed.  If you include relaying to multiple nodes, plus
> serving 500 million SPV clients en grosse, who has the capacity to run such
> a node?  By the time we get to fee pressure, in your scenario, our network
> node count is tiny and highly centralized.
>
>  3) In RE "fee pressure" -- Do you see the moral hazard to a software-run
> system?  It is an intentional, human decision to flood the market with
> supply, thereby altering the economics, forcing fees to remain low in the
> hopes of achieving adoption.  I'm pro-bitcoin and obviously want to see
> bitcoin adoption - but I don't want to sacrifice every decentralized
> principle and become a central banker in order to get there.
>
>
>
>
> --
> 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
> ___

Re: [Bitcoin-development] Block Size Increase Requirements

[Peter Todd]

On Fri, May 08, 2015 at 12:03:04PM +0200, Mike Hearn wrote:
> >
> >  * Though there are many proposals floating around which could
> > significantly decrease block propagation latency, none of them are
> > implemented today.
> 
> 
> With a 20mb cap, miners still have the option of the soft limit.

The soft-limit is there miners themselves produce smaller blocks; the
soft-limit does not prevent other miners from producing larger blocks.

As we're talking about ways that other miners can use 20MB blocks to
harm the competition, talking about the soft-limit is irrelevant.
Similarly, as security engineers we must plan for the worst case; as
we've seen before by your campaigns to raise the soft-limit(1) even at a
time when the vast majority of transaction volume was from one user
(SatoshiDice) soft-limits are an extremely weak form of control.

For the proposes of discussing blocksize increase requirements we can
stop talking about the soft-limit.

1) https://bitcointalk.org/index.php?topic=149668.0

-- 
'peter'[:-1]@petertodd.org
09344ba165781ee352f93d657c8b098c8e518e6011753e59


signature.asc
Description: Digital signature
--
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

Re: [Bitcoin-development] Block Size Increase

[Jeff Garzik]

On Fri, May 8, 2015 at 10:59 AM, Alan Reiner  wrote:

>
> This isn't about "everyone's coffee".  This is about an absolute minimum
> amount of participation by people who wish to use the network.   If our
> goal is really for bitcoin to really be a global, open transaction network
> that makes money fluid, then 7tps is already a failure.  If even 5% of the
> world (350M people) was using the network for 1 tx per month (perhaps to
> open payment channels, or shift money between side chains), we'll be above
> 100 tps.  And that doesn't include all the non-individuals (organizations)
> that want to use it.
>
> The goals of "a global transaction network" and "everyone must be able to
> run a full node with their $200 dell laptop" are not compatible.  We need
> to accept that a global transaction system cannot be fully/constantly
> audited by everyone and their mother.  The important feature of the network
> is that it is open and anyone *can* get the history and verify it.  But not
> everyone is required to.   Trying to promote a system where the history can
> be forever handled by a low-end PC is already falling out of reach, even
> with our miniscule 7 tps.  Clinging to that goal needlessly limits the
> capability for the network to scale to be a useful global payments system
>
>
To repeat, the very first point in my email reply was: "Agree that 7 tps is
too low"  Never was it said that bit

Therefore a reply arguing against the low end is nonsense, and the relevant
question remains on the table.

How high do you want to go - and can Layer 1 bitcoin really scale to get
there?

It is highly disappointing to see people endorse "moar bitcoin volume!"
with zero thinking behind that besides "adoption!"  Need to actually
project what bitcoin looks like at the desired levels, what network
resources are required to get to those levels -- including traffic to serve
those SPV clients via P2P -- and then work backwards from that to see who
can support it, and then work backwards to discern a maximum tps.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
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

Re: [Bitcoin-development] Block Size Increase

[Alan Reiner]

On 05/08/2015 01:13 AM, Tom Harding wrote:
> On 5/7/2015 7:09 PM, Jeff Garzik wrote:
>> G proposed 20MB blocks, AFAIK - 140 tps
>> A proposed 100MB blocks - 700 tps
>> For ref,
>> Paypal is around 115 tps
>> VISA is around 2000 tps (perhaps 4000 tps peak)
>>

For reference, I'm not "proposing" 100 MB blocks right now.  I was
simply suggesting that if Bitcoin is to *ultimately* achieve the goal of
being a globally useful payment rails, 7tps is embarrassingly small. 
Even with off-chain transactions.  It should be a no-brainer that block
size has to go up.

My goal was to bring some long-term perspective into the discussion.  I
don't know if 100 MB blocks will *actually* be necessary for Bitcoin in
20 years, but it's feasible that it will be.  It's an open, global
payments system.  Therefore, we shouldn't be arguing about whether 1 MB
blocks is sufficient--it's very clearly not.  And admitting this as a
valid point is also an admission that not everyone in the world will be
able to run a full node in 20 years.

I don't think there's a solution that can accommodate all future
scenarios, nor that we can even find a solution right now that avoids
more hard forks in the future.   But the goal of "everyone should be
able to download and verify the world's global transactions on a
smartphone" is a non-starter and should not drive decisions. 

--
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

Re: [Bitcoin-development] Block Size Increase

[Alan Reiner]

This isn't about "everyone's coffee".  This is about an absolute minimum
amount of participation by people who wish to use the network.   If our
goal is really for bitcoin to really be a global, open transaction
network that makes money fluid, then 7tps is already a failure.  If even
5% of the world (350M people) was using the network for 1 tx per month
(perhaps to open payment channels, or shift money between side chains),
we'll be above 100 tps.  And that doesn't include all the
non-individuals (organizations) that want to use it.

The goals of "a global transaction network" and "everyone must be able
to run a full node with their $200 dell laptop" are not compatible.  We
need to accept that a global transaction system cannot be
fully/constantly audited by everyone and their mother.  The important
feature of the network is that it is open and anyone *can* get the
history and verify it.  But not everyone is required to.   Trying to
promote a system where the history can be forever handled by a low-end
PC is already falling out of reach, even with our miniscule 7 tps. 
Clinging to that goal needlessly limits the capability for the network
to scale to be a useful global payments system



On 05/07/2015 03:54 PM, Jeff Garzik wrote:
> On Thu, May 7, 2015 at 3:31 PM, Alan Reiner  > wrote:
>  
>
> (2) Leveraging fee pressure at 1MB to solve the problem is
> actually really a bad idea.  It's really bad while Bitcoin is
> still growing, and relying on fee pressure at 1 MB severely
> impacts attractiveness and adoption potential of Bitcoin (due to
> high fees and unreliability).  But more importantly, it ignores
> the fact that for a 7 tps is pathetic for a global transaction
> system.  It is a couple orders of magnitude too low for any
> meaningful commercial activity to occur.  If we continue with a
> cap of 7 tps forever, Bitcoin *will* fail.  Or at best, it will
> fail to be useful for the vast majority of the world (which
> probably leads to failure).  We shouldn't be talking about fee
> pressure until we hit 700 tps, which is probably still too low. 
>
>  [...]
>
> 1) Agree that 7 tps is too low
>
> 2) Where do you want to go?  Should bitcoin scale up to handle all the
> world's coffees? 
>
> This is hugely unrealistic.  700 tps is 100MB blocks, 14.4 GB/day --
> just for a single feed.  If you include relaying to multiple nodes,
> plus serving 500 million SPV clients en grosse, who has the capacity
> to run such a node?  By the time we get to fee pressure, in your
> scenario, our network node count is tiny and highly centralized.
>
> 3) In RE "fee pressure" -- Do you see the moral hazard to a
> software-run system?  It is an intentional, human decision to flood
> the market with supply, thereby altering the economics, forcing fees
> to remain low in the hopes of achieving adoption.  I'm pro-bitcoin and
> obviously want to see bitcoin adoption - but I don't want to sacrifice
> every decentralized principle and become a central banker in order to
> get there.
>

--
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

Re: [Bitcoin-development] Block Size Increase

[Thomas Zander]

On Wednesday 6. May 2015 21.49.52 Peter Todd wrote:
> I'm not sure if you've seen this, but a good paper on this topic was
> published recently: "The Economics of Bitcoin Transaction Fees"


The obvious flaw in this paper is that it talks about a block size in todays 
(trivial) data-flow economy and compares it with the zero-reward situation 
decades from now.

Its comparing two things that will never exist at the same time (unless 
Bitcoin fails).
-- 
Thomas Zander

--
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

Re: [Bitcoin-development] Block Size Increase Requirements

[Mike Hearn]

>
>  * Though there are many proposals floating around which could
> significantly decrease block propagation latency, none of them are
> implemented today.


With a 20mb cap, miners still have the option of the soft limit.

I would actually be quite surprised if there were no point along the road
from 1mb to 20mb where miners felt a need to throttle their block sizes
artificially, for the exact reason you point out: propagation delays.

But we don't *need* to have fancy protocol upgrades implemented right now.
All we need is to demolish one bottleneck (the hard cap) so we can then
move on and demolish the next one (whatever that is, probably faster
propagation). Scaling is a series of walls we punch through as we encounter
them. One down, onto the next. We don't have to tackle them all
simultaneously.

FWIW I don't think the GFW just triggers packet loss, these days. It's
blocked port 8333 entirely.

 * I'd very much like to see someone working on better scaling
> technology ... I know StrawPay is working on development,
>

So this request is already satisfied, isn't it? As you point out, expecting
more at this stage in development is unreasonable, there's nothing for
anyone to experiment with or commit to.

They have code here, by the way:

   https://github.com/strawpay

You can find their fork of MultiBit HD, their implementation library, etc.
They've contributed patches and improvements to the payment channels code
we wrote.


>  * I'd like to see some better conclusions to the discussion around
> long-term incentives within the system.
>

What are your thoughts on using assurance contracts to fund network
security?

I don't *know* if hashing assurance contracts (HACs) will work. But I don't
know they won't work either. And right now I'm pretty sure that plain old
fee pressure won't work. Demand doesn't outstrip supply forever - people
find substitutes.
--
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

Re: [Bitcoin-development] Block Size Increase

[Mike Hearn]

>
> Alan argues that 7 tps is a couple orders of magnitude too low


By the way, just to clear this up - the real limit at the moment is more
like 3 tps, not 7.

The 7 transactions/second figure comes from calculations I did years ago,
in 2011. I did them a few months before the "sendmany" command was
released, so back then almost all transactions were small. After sendmany
and as people developed custom wallets, etc, the average transaction size
went up.
--
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

Re: [Bitcoin-development] Block Size Increase Requirements

[Arkady]

--[remove this line and above]--
On Thu, 7 May 2015, Gregory Maxwell wrote:

> Date: Thu, 7 May 2015 00:37:54 +
> From: Gregory Maxwell 
> To: Matt Corallo 
> Cc: Bitcoin Dev 
> Subject: Re: [Bitcoin-development] Block Size Increase
> 
> Thanks Matt; I was actually really confused by this sudden push with
> not a word here or on Github--so much so that I responded on Reddit to
> people pointing to commits in Gavin's personal repository saying they
> were reading too much into it.

I saw this. I was also pointing this out to the people who were asking 
me. A
commit to a personal repository does not at first seem more than
experimental. sipa commits weird/neat things to private branches all the
time, after all.

> to share behavior. In the case of mining, we're trying to optimize the
> social good of POW security. (But the analogy applies in other ways 
> too:

About the only argument IMO in favour of block size increases is to 
assume
that making more room in a block will make it attractive to use for more
people at some point in the future: increasing transaction velocity,
increasing economy size, increasing value overall.

> increases to the chain side are largely an externality; miners enjoy 
> the
> benefits, everyone else takes the costs--either in reduced security or
> higher node operating else.)

Who else but miners and pool operators will run full nodes when full 
nodes
are being shut down because they are too large and unwieldy to maintain? 
It
is already so that casual users refuse to run full nodes. This fact is
indisputable. The only question remaining is, "Do we care?" Arguments
against users who feel that the dataset is too large to run a full node,
full-time, start from a premise that these users are a static and 
irrelevant
fraction. Is this even true? "Do we care?" I do. I will shortly only be 
able
to run half the nodes I currently do thanks to the growth of the 
blockchain
at its current rate.

> One potential argument is that maybe miners would be _regulated_ to
> behave correctly. But this would require undermining the openness of 
> the
> system--where anyone can mine anonymously--in order to enforce 
> behavior,
> and that same enforcement mechanism would leave a political level to
> impose additional rules that violate the extra properties of the 
> system.

I would refuse to mine under such a regulated regime; moreover, I would
enjoy forking away from this, and, I suspect, the only miners who remain
would be those whose ultimate motivations do not coincide with the 
users.
That is, the set of miners who are users, and the set of users who are
miners, would be wholly non-intersecting.

> So far the mining ecosystem has become incredibly centralized over 
> time.

This is unfortunate but true.

> of the regular contributors to Bitcoin Core do. Many participants
> have never mined or only did back in 2010/2011... we've basically
> ignored the mining ecosystem, and this has had devastating effects,
> causing a latent undermining of the security model: hacking a dozen or
> so computers--operated under totally unknown and probably not strong
> security policies--could compromise the network at least at the tip...

The explicit form of the block dictated by the reference client and
agreed-to by the people who were sold on bitcoin near the beginning 
(myself
included) was explicitly the notion that the rules were static; that the
nature of transaction foundations and the subsidies would not be 
altered.
Here we have a hardfork being contemplated which is not only 
controversial,
but does not even address some of the highest-utility and most-requested
features in peoples' hardfork wishlists.

The fact that mining has effectively been centralized directly implies 
that
destabilizing changes that some well-heeled (and thus theoretically 
capable,
at least) people have explicitly begun plans to fork the blockchain 
about
will have an unknown, and completely unforeseen combined effect.

We can pretend that, "If merchants and miners and exchanges go along, 
then
who else matters," but the reality is that the value in bitcoin exists
because *people* use it for real transactions: Not miners, whose profits 
are
parasitically fractionally based on the quality and strength of the 
bitcoin
economy as a whole; not exchanges who lubricate transactions in service 
to
the economy; not even today's merchants whose primary means of accepting
bitcoin seems to be to convert them instantly to fiat and not 
participate
meaningfully in the economy at all; not enriched felons; but actual 
users
themselves.

> Rightfully we should be regarding this an an emergency, and probably
> should have been have since 2011.

There are two ways to look at it, assuming that the blocksize change
increases bitcoin's value to people after all: mining centralizati

Re: [Bitcoin-development] Block Size Increase

[Tom Harding]

On 5/7/2015 7:09 PM, Jeff Garzik wrote:
>
> G proposed 20MB blocks, AFAIK - 140 tps
> A proposed 100MB blocks - 700 tps
> For ref,
> Paypal is around 115 tps
> VISA is around 2000 tps (perhaps 4000 tps peak)
>
> I ask again:  where do we want to go?   This is the existential
> question behind block size.
>
> Are we trying to build a system that can handle Paypal volumes?  VISA
> volumes?
>
> It's not a snarky or sarcastic question:  Are we building a system to
> handle all the world's coffees?  Is bitcoin's main chain and network -
> Layer 1 - going to receive direct connections from 500m mobile phones,
> broadcasting transactions?
>
> We must answer these questions to inform the change being discussed
> today, in order to decide what makes the most sense as a new limit. 
> Any responsible project of this magnitude must have a better story
> than "zomg 1MB, therefore I picked 20MB out of a hat"  Must be able to
> answer /why/ the new limit was picked.
>
> As G notes, changing the block size is simply kicking the can down the
> road:
> http://gavinandresen.ninja/it-must-be-done-but-is-not-a-panacea  
> Necessarily one must ask, today, what happens when we get to the end
> of that newly paved road.
>
>

Accepting that outcomes are less knowable further into the future is not
the same as failing to consider the future at all.  A responsible
project can't have a movie-plot roadmap.  It needs to give weight to
multiple possible future outcomes.
http://en.wikipedia.org/wiki/Decision_tree

One way or another, the challenge is to decide what to do next.  Beyond
that, it's future decisions all the way down. 

Alan argues that 7 tps is a couple orders of magnitude too low for any
meaningful commercial activity to occur, and too low to be the final
solution, even with higher layers.  I agree.  I also agree with you,
that we don't really know how to accomplish 700tps right now.

What we do know is if we want to bump the limit in the short term, we
ought to start now, and until there's a better alternative root to the
decision tree, it just might be time to get moving.




--
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

Re: [Bitcoin-development] Block Size Increase

[Tom Harding]

On 5/7/2015 6:40 AM, Jorge Timón wrote:
>> Known: There's a major problem looming for miners at the next block reward
>> halving. Many are already in a bad place and without meaningful fees then
>> sans a 2x increase in the USD:BTC ratio then many will simply have to leave
>> the network, increasing centralisation risks. There seems to be a fairly
>> pervasive assumption that the 300-ish MW of power that they currently use is
>> going to pay for itself (ignoring capital and other operating costs).
> I take this as an argument for increasing fee competition and thus,
> against increasing the block size.
>

That doesn't follow.  Supposing average fees per transaction decrease
with block size, total fees / block reach an optimum somewhere.  While
the optimum might be at infinity, it's certainly not at zero, and it's
not at all obvious that the optimum is at a block size lower than 1MB.



--
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

Re: [Bitcoin-development] Block Size Increase

[Peter Todd]

On Thu, May 07, 2015 at 03:31:46PM -0400, Alan Reiner wrote:
> We get asked all the time by corporate clients about scalability.  A
> limit of 7 tps makes them uncomfortable that they are going to invest
> all this time into a system that has no chance of handling the economic
> activity that they expect it handle.  We always assure them that 7 tps
> is not the final answer. 

Your corporate clients, *why* do they want to use Bitcoin and what for
exactly?

-- 
'peter'[:-1]@petertodd.org
054c9d9ae1099ef8bc0bc9b76fef5e03f7edaff66fd817d8


signature.asc
Description: Digital signature
--
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

Re: [Bitcoin-development] Block Size Increase

[Jeff Garzik]

On Thu, May 7, 2015 at 9:40 PM, Tom Harding  wrote:

> On 5/7/2015 12:54 PM, Jeff Garzik wrote:
> > 2) Where do you want to go?  Should bitcoin scale up to handle all the
> > world's coffees?
>
> Alan was very clear.  Right now, he wants to go exactly where Gavin's
> concrete proposal suggests.
>

G proposed 20MB blocks, AFAIK - 140 tps
A proposed 100MB blocks - 700 tps
For ref,
Paypal is around 115 tps
VISA is around 2000 tps (perhaps 4000 tps peak)

I ask again:  where do we want to go?   This is the existential question
behind block size.

Are we trying to build a system that can handle Paypal volumes?  VISA
volumes?

It's not a snarky or sarcastic question:  Are we building a system to
handle all the world's coffees?  Is bitcoin's main chain and network -
Layer 1 - going to receive direct connections from 500m mobile phones,
broadcasting transactions?

We must answer these questions to inform the change being discussed today,
in order to decide what makes the most sense as a new limit.  Any
responsible project of this magnitude must have a better story than "zomg
1MB, therefore I picked 20MB out of a hat"  Must be able to answer /why/
the new limit was picked.

As G notes, changing the block size is simply kicking the can down the
road: http://gavinandresen.ninja/it-must-be-done-but-is-not-a-panacea
Necessarily one must ask, today, what happens when we get to the end of
that newly paved road.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
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

Re: [Bitcoin-development] Block Size Increase

[Joel Joonatan Kaartinen]

Having observed the customer support nightmare it tends to cause for a
small exchange service when 100% full blocks happen, I've been thinking
that the limit really should be dynamic and respond to demand and the
amount of fees offered. It just doesn't feel right when it takes ages to
burn through the backlog when 100% full is hit for a while. So, while
pondering this, I got an idea that I think has a chance of working that I
can't remember seeing suggested anywhere.

How about basing the maximum valid size for a block on the total bitcoin
days destroyed in that block? That should still stop transaction spam but
naturally expand the block size when there's a backlog of real
transactions. It'd also provide for an indirect mechanism for increasing
the maximum block size based on fees if there's a lot of fees but little
bitcoin days destroyed. In such a situation there'd be incentive to pay
someone to spend an older txout to expand the maximum. I realize this is a
rather half baked idea, but it seems worth considering.

- Joel

On Thu, May 7, 2015 at 10:31 PM, Alan Reiner  wrote:

>  This *is* urgent and needs to be handled right now, and I believe Gavin
> has the best approach to this.  I have heard Gavin's talks on increasing
> the block size, and the two most persuasive points to me were:
>
> (1) Blocks are essentially nearing "full" now.  And by "full" he means
> that the reliability of the network (from the average user perspective) is
> about to be impacted in a very negative way (I believe it was due to the
> inconsistent time between blocks).  I think Gavin said that his simulations
> showed 400 kB - 600 kB worth of transactions per 10 min (approx 3-4 tps) is
> where things start to behave poorly for certain classes of transactions.
> In other words, we're very close to the effective limit in terms of
> maintaining the current "standard of living", and with a year needed to
> raise the block time this actually is urgent.
>
> (2) Leveraging fee pressure at 1MB to solve the problem is actually really
> a bad idea.  It's really bad while Bitcoin is still growing, and relying on
> fee pressure at 1 MB severely impacts attractiveness and adoption potential
> of Bitcoin (due to high fees and unreliability).  But more importantly, it
> ignores the fact that for a 7 tps is pathetic for a global transaction
> system.  It is a couple orders of magnitude too low for any meaningful
> commercial activity to occur.  If we continue with a cap of 7 tps forever,
> Bitcoin *will* fail.  Or at best, it will fail to be useful for the vast
> majority of the world (which probably leads to failure).  We shouldn't be
> talking about fee pressure until we hit 700 tps, which is probably still
> too low.
>
> You can argue that side chains and payment channels could alleviate this.
> But how far off are they?  We're going to hit effective 1MB limits long
> before we can leverage those in a meaningful way.  Even if everyone used
> them, getting a billion people onto the system just can't happen even at 1
> transaction per year per person to get into a payment channel or move money
> between side chains.
>
> We get asked all the time by corporate clients about scalability.  A limit
> of 7 tps makes them uncomfortable that they are going to invest all this
> time into a system that has no chance of handling the economic activity
> that they expect it handle.  We always assure them that 7 tps is not the
> final answer.
>
> Satoshi didn't believe 1 MB blocks were the correct answer.  I personally
> think this is critical to Bitcoin's long term future.   And I'm not sure
> what else Gavin could've done to push this along in a meaninful way.
>
> -Alan
>
>
>
> On 05/07/2015 02:06 PM, Mike Hearn wrote:
>
> I think you are rubbing against your own presupposition that people
>> must find and alternative right now. Quite a lot here do not believe there
>> is any urgency, nor that there is an immanent problem that has to be solved
>> before the sky falls in.
>>
>
>  I have explained why I believe there is some urgency, whereby "some
> urgency" I mean, assuming it takes months to implement, merge, test,
> release and for people to upgrade.
>
>  But if it makes you happy, imagine that this discussion happens all over
> again next year and I ask the same question.
>
>
>
> --
> 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 
> listBitcoin-development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> -

Re: [Bitcoin-development] Block Size Increase

[Tom Harding]

On 5/7/2015 12:54 PM, Jeff Garzik wrote:
> In the short term, blocks are bursty, with some on 1 minute intervals, 
> some with 60 minute intervals.  This does not change with larger blocks.
>

I'm pretty sure Alan meant that blocks are already filling up after long 
inter-block intervals.


>
> 2) Where do you want to go?  Should bitcoin scale up to handle all the 
> world's coffees?

Alan was very clear.  Right now, he wants to go exactly where Gavin's 
concrete proposal suggests.



--
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

Re: [Bitcoin-development] Block Size Increase Requirements

[Peter Todd]

On Thu, May 07, 2015 at 10:02:09PM +, Matt Corallo wrote:
> OK, so lets do that. I've seen a lot of "I'm not entirely comfortable
> with committing to this right now, but think we should eventually", but
> not much "I'd be comfortable with committing to this when I see X". In
> the interest of ignoring debate and pushing people towards a consensus
> at all costs, ( ;) ) I'm gonna go ahead and suggest we talk about the
> second.
> 
> Personally, there are several things that worry me significantly about
> committing to a blocksize increase, which I'd like to see resolved
> before I'd consider supporting a blocksize increase commitment.
> 
>  * Though there are many proposals floating around which could
> significantly decrease block propagation latency, none of them are
> implemented today. I'd expect to see these not only implemented but
> being used in production (though I dont particularly care about them
> being all that stable). I'd want to see measurements of how they perform
> both in production and in the face of high packet loss (eg across the
> GFW or in the case of small/moderate DoS). In addition, I'd expect to
> see analysis of how these systems perform in the worst-case, not just
> packet-loss-wise, but in the face of miners attempting to break the system.

It's really important that we remember that we're building security
software: it *must* hold up well even in the face of attack. That means
we need to figure out how it can be attacked, what the cost/profits of
such attacks are, and if the holes can be patched.  Just testing the
software with simulated loads is insufficient.

Also, re: breaking, don't forget that this may not be a malicious act.
For instance, someone can send contradictory transactions to different
parts of the network simultaneously to prevent mempool consistency -
there's no easy way to fix this. There are also cases where miners have
different policy than others, e.g. version disagreements, commercial
contracts for tx mining, etc.

Finally, remember that it's not in miners' incentives in many situations
for their blocks to propagate to more than ~30% of the hashing power.(1)

Personally, I'm really skeptical that we'll ever find a block
propagation latency reduction technique that sucesfully meets all the
above criteria without changing the consensus algorithm itself.


* How do we ensure miners don't cheat and stop validating blocks fully
before building on them? This is a significant moral hazard with larger
blocks if fees don't become significant, and can lead to dangerous
forks. Also, think of the incentives: Why would a miner ever switch from
the longest chain, even if they don't actually have the blocks to back
it up?

* We need a clear understanding of how we expect new full nodes, pruned
or not, to sync up to the blockchain. Obviously 20MB blocks
significantly increases the time and data required to sync. Are we
planning on simply giving up on full validation and trusting others for
copies of UTXO sets? Are we going to rely on UTXO commitments? What
happens if the UTXO set size itself increases greatly?

>  * I'd very much like to see someone working on better scaling
> technology, both in terms of development and in terms of getting
> traction in the marketplace. I know StrawPay is working on development,
> though its not obvious to me how far they are from their website, but I
> dont know of any commitments by large players (either SPV wallets,
> centralized wallet services, payment processors, or any others) to
> support such a system (to be fair, its probably too early for such
> players to commit to anything, since anything doesnt exist in public).

A good start would be for those players to commit to the general
principles of these systems; if they can't commit explain why.

For instance I'd be very interested in knowing if services like Coinbase
see legal issues with adopting technologies such as payment channels
between hosted wallet providers, payment processors, etc. I certainly
wouldn't be surprised if they see doing anythign not on-blockchain as a
source of legal uncertainty - based on discussions I've had with
regulatory types in this space it sounds like there's a reasonable
chance protocol details such as requiring that transactions happen on a
public blockchain will be "baked into" regulatory requirements.

>  * I'd like to see some better conclusions to the discussion around
> long-term incentives within the system. If we're just building Bitcoin
> to work in five years, great, but if we want it all to keep working as
> subsidy drops significantly, I'd like a better answer than "we'll deal
> with it when we get there" or "it will happen, all the predictions based
> on people's behavior today say so" (which are hopefully invalid thanks
> to the previous point). Ideally, I'd love to see some real free pressure
> already on the network starting to develop when we commit to hardforking
> in a year.

Agreed.

> Not just full blocks with some fees 

Re: [Bitcoin-development] Block Size Increase Requirements

[Joseph Poon]

Hi Matt,

I agree that starting discussion on how to approach this problem is
necessary and it's difficult taking positions without details on what is
being discussed.

A simple hard 20-megabyte increase will likely create perverse
incentives, perhaps a method can exist with some safe transition. I
think ultimately, the underlying tension with this discussion is about
the relative power of miners. Any transition of blocksize increase will
increase the influence of miners, and it is about understanding the
tradeoffs for each possible approach.

On Thu, May 07, 2015 at 10:02:09PM +, Matt Corallo wrote:
>  * I'd like to see some better conclusions to the discussion around
> long-term incentives within the system. If we're just building Bitcoin
> to work in five years, great, but if we want it all to keep working as
> subsidy drops significantly, I'd like a better answer than "we'll deal
> with it when we get there" or "it will happen, all the predictions based
> on people's behavior today say so" (which are hopefully invalid thanks
> to the previous point). Ideally, I'd love to see some real free pressure
> already on the network starting to develop when we commit to hardforking
> in a year. Not just full blocks with some fees because wallets are
> including far greater fees than they really need to, but software which
> properly handles fees across the ecosystem, smart fee increases when
> transactions arent confirming (eg replace-by-fee, which could be limited
> to increase-in-fees-only for those worried about double-spends).

I think the long-term fee incentive structure needs to be significantly
more granular. We've all seen miners and pools take the path of least
resistance; often they just do whatever the community tells them to
blindly. While this status quo can change in the future, I think
designing sane defaults is a good path for any possible transition.

It seems especially reasonable to maintain fee pressure for normal
transactions during a hard-fork transition. It's possible to do so using
some kind of soft-cap structure. Building in a default soft-cap of 1
megabyte for some far future scheduled fork would seem like a sane thing
to do for bitcoin-core.

It seems also viable to be far more aggressive. What's your (and the
community's) opinion on some kind of coinbase voting protocol for
soft-cap enforcement? It's possible to write in messages to the coinbase
for a enforcible soft-cap that orphans out any transaction which
violates these rules. It seems safest to have the transition has the
first hardforked block be above 1MB, however, the next block default to
an enforced 1MB block. If miners agree to go above this, they must vote
in their coinbase to do so.

There's a separate discussion about this starting on:
cae-z3oxnjayluehbu0hdwu5pkrj6fpj7yptgbmq7hkxg3sj...@mail.gmail.com

I think defaulting some kind of mechanism on reading the coinbase seems
to be a good idea, I think left alone, miners may not do so. That way,
it's possible to have your cake and eat it too, fee pressure will still
exist, while block sizes can increase (provided it's in the miners'
greater interests to do so).

The Lightning Network's security model in the long-term may rely on a
multi-tier soft-cap, but I'm not sure. If 2nd order systemic miner
incentives were not a concern, a system which has an enforced soft-cap
and permits breaching that soft-cap with some agreed upon much higher
fee would work best. LN works without this, but it seems to be more
secure if some kind of miner consensus rule is reached regarding
prioritizing behavior of 2nd-layer consensus states.

No matter how it's done, certain aspects of the security model of
something like Lightning is reliant upon having block-space
availability for transactions to enter into the blockchain in a timely
manner (since "deprecated" channel states become valid again after some
agreed upon block-time).

I think pretty much everyone agrees that the 1MB block cap will
eventually be a problem. While people may disagree with when that will
be and how it'll play out, I think we're all in agreement that
discussion about it is a good idea, especially when it comes to
resolving blocking concerns.

Starting a discussion on how a hypothetical blocksize increase will
occur and the necessary blocking/want-to-have features/tradeoffs seems
to be a great way to approach this problem. The needs for Lightning
Network may be best optimized by being able to prioritizing a large mass
of timeout transactions at once (when a well-connected node stops
communicating).

-- 
Joseph Poon

--
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

Re: [Bitcoin-development] Block Size Increase

[21E14]

I am more fazed by PR 5288 and PR 5925 not getting merged in, than by this
thread. So, casting my ballot in favor of the block size increase. Clearly,
we're still rehearsing proper discourse, and that ain't gonna get fixed
here and now.

On Thu, May 7, 2015 at 9:29 PM, Matt Corallo 
wrote:

>
>
> On 05/07/15 19:34, Mike Hearn wrote:
> > The appropriate method of doing any fork, that we seem to have been
> > following for a long time, is to get consensus here and on IRC and on
> > github and *then* go pitch to the general public
> >
> >
> > So your concern is just about the ordering and process of things, and
> > not about the change itself?
>
> No, I'm very concerned about both.
>
> > I have witnessed many arguments in IRC about block sizes over the years.
> > There was another one just a few weeks ago. Pieter left the channel for
> > his own sanity. IRC is not a good medium for arriving at decisions on
> > things - many people can't afford to sit on IRC all day and
> > conversations can be hard to follow. Additionally, they tend to go
> circular.
>
> I agree, thats why this mailing list was created in the first place
> (well, also because bitcointalk is too full of spam, but close enought :))
>
> > That said, I don't know if you can draw a line between the "ins" and
> > "outs" like that. The general public is watching, commenting and
> > deciding no matter what. Might as well deal with that and debate in a
> > format more accessible to all.
>
> Its true, just like its true the general public can opt to run any
> version of software they want. That said, the greater software
> development community has to update /all/ the software across the entire
> ecosystem, and thus provide what amounts to a strong recommendation of
> which course to take. Additionally, though there are issues (eg if there
> was a push to remove the total coin limit) which are purely political,
> and thus which should be up to the greater public to decide, the
> blocksize increase is not that. It is intricately tied to Bitcoin's
> delicate incentive structure, which many of the development community
> are far more farmiliar with than the general Bitcoin public. If there
> were a listserv that was comprised primarily of people on
> #bitcoin-wizards, I might have suggested a discussion there, first, but
> there isnt (as far as I know?).
>
> > If, instead, there had been an intro on the list as "I think we
> should
> > do the blocksize increase soon, what do people think?"
> >
> >
> > There have been many such discussions over time. On bitcointalk. On
> > reddit. On IRC. At developer conferences. Gavin already knew what many
> > of the objections would be, which is why he started answering them.
> >
> > But alright. Let's say he should have started a thread. Thanks for
> > starting it for him.
> >
> > Now, can we get this specific list of things we should do before we're
> > prepared?
>
> YesI'm gonna split the topic since this is already far off course
> for that :).
>
> > A specific credible alternative to what? Committing to blocksize
> > increases tomorrow? Yes, doing more research into this and developing
> > software around supporting larger block sizes so people feel
> comfortable
> > doing it in six months.
> >
> >
> > Do you have a specific research suggestion? Gavin has run simulations
> > across the internet with modified full nodes that use 20mb blocks, using
> > real data from the block chain. They seem to suggest it works OK.
> >
> > What software do you have in mind?
>
> Let me answer that in a new thread :).
>
>
> --
> 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
>
--
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

Re: [Bitcoin-development] Block Size Increase

[Matt Corallo]

On 05/07/15 19:34, Mike Hearn wrote:
> The appropriate method of doing any fork, that we seem to have been
> following for a long time, is to get consensus here and on IRC and on
> github and *then* go pitch to the general public
> 
> 
> So your concern is just about the ordering and process of things, and
> not about the change itself?

No, I'm very concerned about both.

> I have witnessed many arguments in IRC about block sizes over the years.
> There was another one just a few weeks ago. Pieter left the channel for
> his own sanity. IRC is not a good medium for arriving at decisions on
> things - many people can't afford to sit on IRC all day and
> conversations can be hard to follow. Additionally, they tend to go circular.

I agree, thats why this mailing list was created in the first place
(well, also because bitcointalk is too full of spam, but close enought :))

> That said, I don't know if you can draw a line between the "ins" and
> "outs" like that. The general public is watching, commenting and
> deciding no matter what. Might as well deal with that and debate in a
> format more accessible to all.

Its true, just like its true the general public can opt to run any
version of software they want. That said, the greater software
development community has to update /all/ the software across the entire
ecosystem, and thus provide what amounts to a strong recommendation of
which course to take. Additionally, though there are issues (eg if there
was a push to remove the total coin limit) which are purely political,
and thus which should be up to the greater public to decide, the
blocksize increase is not that. It is intricately tied to Bitcoin's
delicate incentive structure, which many of the development community
are far more farmiliar with than the general Bitcoin public. If there
were a listserv that was comprised primarily of people on
#bitcoin-wizards, I might have suggested a discussion there, first, but
there isnt (as far as I know?).

> If, instead, there had been an intro on the list as "I think we should
> do the blocksize increase soon, what do people think?"
> 
> 
> There have been many such discussions over time. On bitcointalk. On
> reddit. On IRC. At developer conferences. Gavin already knew what many
> of the objections would be, which is why he started answering them.
> 
> But alright. Let's say he should have started a thread. Thanks for
> starting it for him.
> 
> Now, can we get this specific list of things we should do before we're
> prepared?

YesI'm gonna split the topic since this is already far off course
for that :).

> A specific credible alternative to what? Committing to blocksize
> increases tomorrow? Yes, doing more research into this and developing
> software around supporting larger block sizes so people feel comfortable
> doing it in six months. 
> 
> 
> Do you have a specific research suggestion? Gavin has run simulations
> across the internet with modified full nodes that use 20mb blocks, using
> real data from the block chain. They seem to suggest it works OK.
> 
> What software do you have in mind?

Let me answer that in a new thread :).

--
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

Re: [Bitcoin-development] Block Size Increase

[Jérémie Dubois-Lacoste]

> I have written up an explanation of what I think will happen if we run out
> of capacity:
>
>https://medium.com/@octskyward/crash-landing-f5cc19908e32
Looks like a solid description of what would happen.

I fail to see how this description wouldn't be applicable also to a
20MB-network in some time in the future, say ~3 years from now, if
Bitcoin keeps taking off.
If you agree that it will be harder in the future to change the block
limit again, and we switch to hardcoded 20MB, then aren't we just
going from an immediate relief to a future larger blockage?



>
> Now I'm going to go eat some dinner :)
>
> --
> 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
>

--
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

Re: [Bitcoin-development] Block Size Increase

[Bernard Rihn]

It seems to me like some (maybe most) of the pressure is actually external
from companies that might release something that dramatically increases
"adoption" & transaction rates (and that the data on historic rate of
adoption & slumps is somewhat disconnected from their interests in a quick
roll-out)?

It seems like the question actually becomes what is our maximum acceptable
cost (hardware capex & bandwidth & power opex) associated with running a
full node without hardware acceleration and with hardware acceleration
(something which presumably "doesn't exist" yet)? Are we making the
assumption that hardware acceleration for confirmation will become broadly
available and that the primary limiter will become anonymous bandwidth?

Excuse my ignorance, but I imagine somebody must have already looked at
confirmation times vs. block size for various existing hardware platforms
(like at least 3 or 4? maybe a minnowboard, old laptop, and modern desktop
at least?)? Is there an easy way to setup bitcoind or some other script to
test this? (happy to help)

Re Moore's law: yeah, some say stuff like 5nm may never happen. We're
already using EUV with plasma emitters, immersed reflective optics, and
double-patterning... and in storage land switching to helium. Things may
slow A LOT over the next couple decades and I'd guess that a quadratic
increase (both in storage & compute) probably isn't a safe assumption.

On Thu, May 7, 2015 at 11:46 AM, Btc Drak  wrote:

> On Thu, May 7, 2015 at 7:40 PM, Gavin Costin 
> wrote:
>
>> Can anyone opposed to this proposal articulate in plain english the worst
>> case scenario(s) if it goes ahead?
>>
>> Some people in the conversation appear to be uncomfortable, perturbed,
>> defensive etc about the proposal …. But I am not seeing specifics on why it
>> is not a feasible plan.
>>
>
> See this response:
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07462.html
>
>
>
> --
> 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
>
>
--
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

Re: [Bitcoin-development] Block Size Increase

[Justus Ranvier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/07/2015 09:54 PM, Jeff Garzik wrote:
> By the time we get to fee pressure, in your scenario, our network 
> node count is tiny and highly centralized.

Again, this assertion requires proof.

Simply saying things is not the same as them being true.

-BEGIN PGP SIGNATURE-

iQIcBAEBAgAGBQJVS8QWAAoJECpf2nDq2eYj+/4P/2JXxo2RDAg0ptd9aUYVvzp9
KhL33cdmK8kbKBFOVcOuIrlQRzZn9iydIPC165Y40Y6Wrtgw2PoXctuqdQdXaSZI
M3bHuM7mweHyb3xBHNaNHIxfwrMjQQAdOTGO7PZusghDYz2QEj44dhIcNOzO7uTD
fXkhzgJfwu0l0Wqn3v/R9amRUWLE5nlM566xJ2sVtlfBMEyzR5L1GwX1lKNhxeO8
qvkgegsF2Usjz9pIUMSGFxSWZQuTSjHbhbh28JaT/wi6DI3pcTV0FPw95IPImqUh
rbIqcPh43omXrHKEHV/FB+XMItD3VvR9dxogYaFZLv1EU2gnF2IM0cw5a/oyHr+L
C920uEbXrvrMEJw1ftvxQyu6NY5c3/5iVMqz773oQSjOihkZ8P1JvxQnldU6mcoU
RaKM13cxgjSkCqJ5R1iIldFQPCLLWUKJDkPEnGlwdLPF/vwhnCt1PZJTB5hqoCgC
ab5yBVLpLgo7sbizOeX/R3WGp3NjGXDQC93Af/Vr37uiu1ZT+1P1Ow86hsZTRx6b
4d25tSGg7Tw3Bs/YOhJ9AKtlN092Y8/WBMscQu6MaFt6I/1OMX9OVH+veEj/VjwB
L/dxWTRdC0HEKiYv+EuESIRoyTLlCHKBUDBgKbYSMjetg6WW64hYrpxNX7TH20o6
00bWPVV2PcEWuCc230UF
=1bK6
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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

Re: [Bitcoin-development] Block Size Increase

[Btc Drak]

On Thu, May 7, 2015 at 5:11 PM, Mike Hearn  wrote:

> Right now there is this nice warm fuzzy notion that decisions in Bitcoin
>> Core are made by consensus. "Controversial" changes are avoided. I am
>> trying to show you that this is just marketing.
>
>
Consensus is arrived when the people who are most active at the time
(active in contributing to discussions, code review, giving opinions etc.)
agreed to ACK. There are a regular staple of active contributors. Bitcoin
development is clearly a meritocracy. The more people participate and
contribute the more weight their opinions hold.


> Nobody can define what these terms even mean. It would be more accurate to
>> say decisions are vetoed by whoever shows up and complains enough,
>> regardless of technical merit. After all, my own getutxo change was merged
>> after a lot of technical debate (and trolling) . then unmerged a day
>> later because "it's a shitstorm".
>
>
I am not sure that is fair, your PR was reverted because someone found a
huge exploit in your PR enough to invalidate all your arguments used to get
it merged in the first place.


> So if Gavin showed up and complained a lot about side chains or whatever,
> what you're saying is, oh that's different. We'd ignore him. But when
> someone else complains about a change they don't like, that's OK.
>
> Heck, I could easily come up with a dozen reasons to object to almost any
> change, if I felt like it. Would I then be considered not a part of the
> consensus because that'd be convenient?
>

I don't think it's as simple as that. Objections for the sake of
objections, or unsound technical objections are going to be seen for what
they are. This is a project with of some of the brightest people in the
world in this field. Sure people can be disruptive but their reputation
stand the test of time.

The consensus system might not be perfect, but it almost feels like you
want to declare a state of emergency and suspend all the normal review
process for this proposed hard fork.
--
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

Re: [Bitcoin-development] Block Size Increase

[Jeff Garzik]

On Thu, May 7, 2015 at 3:31 PM, Alan Reiner  wrote:

>  (1) Blocks are essentially nearing "full" now.  And by "full" he means
> that the reliability of the network (from the average user perspective) is
> about to be impacted in a very negative way
>

Er, to be economically precise, "full" just means fees are no longer zero.
Bitcoin behaves as it always has.  It is no longer basically free to dump
spam into the blockchain, as it is today.

In the short term, blocks are bursty, with some on 1 minute intervals, some
with 60 minute intervals.  This does not change with larger blocks.



> (2) Leveraging fee pressure at 1MB to solve the problem is actually really
> a bad idea.  It's really bad while Bitcoin is still growing, and relying on
> fee pressure at 1 MB severely impacts attractiveness and adoption potential
> of Bitcoin (due to high fees and unreliability).  But more importantly, it
> ignores the fact that for a 7 tps is pathetic for a global transaction
> system.  It is a couple orders of magnitude too low for any meaningful
> commercial activity to occur.  If we continue with a cap of 7 tps forever,
> Bitcoin *will* fail.  Or at best, it will fail to be useful for the vast
> majority of the world (which probably leads to failure).  We shouldn't be
> talking about fee pressure until we hit 700 tps, which is probably still
> too low.
>
 [...]

1) Agree that 7 tps is too low

2) Where do you want to go?  Should bitcoin scale up to handle all the
world's coffees?

This is hugely unrealistic.  700 tps is 100MB blocks, 14.4 GB/day -- just
for a single feed.  If you include relaying to multiple nodes, plus serving
500 million SPV clients en grosse, who has the capacity to run such a
node?  By the time we get to fee pressure, in your scenario, our network
node count is tiny and highly centralized.

3) In RE "fee pressure" -- Do you see the moral hazard to a software-run
system?  It is an intentional, human decision to flood the market with
supply, thereby altering the economics, forcing fees to remain low in the
hopes of achieving adoption.  I'm pro-bitcoin and obviously want to see
bitcoin adoption - but I don't want to sacrifice every decentralized
principle and become a central banker in order to get there.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
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

Re: [Bitcoin-development] Block Size Increase

[Jérémie Dubois-Lacoste]

Any proposal to switch to a new hardcorded value so we have time to
*really* figure out later what's next and all implications, is a road
to a gigantic issue later when we want to switch to that "next".

Sure we would have more time to think about, research all
implications, simulate, discuss, etc. But the ability then to agree
enough on a change to roll it out successfully will be much smaller,
because of the economy being built on top of Bitcoin being much larger
and the technical specifications of Bitcoin being closer to a complete
freeze.

What I'm trying to say is that we should look at long term lasting
solutions even if it takes more effort and time right now and puts the
network into some "troubles" for a while, because they're short term
"troubles". (You define "troubles", depending on which side you stand
at the moment...).

I personally believe in adaptive block size mechanisms, because:

(i) common sense tells me harcoding is never a solution for a system
whose usage is for many aspects unpredictable
(ii) we can't rely on human consensus to adapt it (seeing the mess
 it is already this time).

It would have the advantage to place this block size issue entirely as
part of the algorithmic contract you agree on when you use Bitcoin,
similar to the difficulty adapation or the block reward.


Jérémie


2015-05-07 21:37 GMT+02:00 Mike Hearn :
>
>> These statements may even be true, but they're no logical conclusions
>> even if they seem obvious to you.
>> I don't think those claims are strictly true, specially because they
>> involve predictions about what people will do.
>> But if they're true they require some proof or at least some explanation.
>
>
> Thank you for your patience, Jorge.
>
> I have written up an explanation of what I think will happen if we run out
> of capacity:
>
>https://medium.com/@octskyward/crash-landing-f5cc19908e32
>
> Now I'm going to go eat some dinner :)
>
> --
> 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
>

--
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

Re: [Bitcoin-development] Block Size Increase

[Mike Hearn]

> These statements may even be true, but they're no logical conclusions
> even if they seem obvious to you.
> I don't think those claims are strictly true, specially because they
> involve predictions about what people will do.
> But if they're true they require some proof or at least some explanation.
>

Thank you for your patience, Jorge.

I have written up an explanation of what I think will happen if we run out
of capacity:

   https://medium.com/@octskyward/crash-landing-f5cc19908e32

Now I'm going to go eat some dinner :)
--
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

Re: [Bitcoin-development] Block Size Increase

[Mike Hearn]

>
> The appropriate method of doing any fork, that we seem to have been
> following for a long time, is to get consensus here and on IRC and on
> github and *then* go pitch to the general public


So your concern is just about the ordering and process of things, and not
about the change itself?

I have witnessed many arguments in IRC about block sizes over the years.
There was another one just a few weeks ago. Pieter left the channel for his
own sanity. IRC is not a good medium for arriving at decisions on things -
many people can't afford to sit on IRC all day and conversations can be
hard to follow. Additionally, they tend to go circular.

That said, I don't know if you can draw a line between the "ins" and "outs"
like that. The general public is watching, commenting and deciding no
matter what. Might as well deal with that and debate in a format more
accessible to all.


> If, instead, there had been an intro on the list as "I think we should
> do the blocksize increase soon, what do people think?"


There have been many such discussions over time. On bitcointalk. On reddit.
On IRC. At developer conferences. Gavin already knew what many of the
objections would be, which is why he started answering them.

But alright. Let's say he should have started a thread. Thanks for starting
it for him.

Now, can we get this specific list of things we should do before we're
prepared?


> A specific credible alternative to what? Committing to blocksize
> increases tomorrow? Yes, doing more research into this and developing
> software around supporting larger block sizes so people feel comfortable
> doing it in six months.


Do you have a specific research suggestion? Gavin has run simulations
across the internet with modified full nodes that use 20mb blocks, using
real data from the block chain. They seem to suggest it works OK.

What software do you have in mind?
--
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

Re: [Bitcoin-development] Block Size Increase

[Alan Reiner]

This *is* urgent and needs to be handled right now, and I believe Gavin
has the best approach to this.  I have heard Gavin's talks on increasing
the block size, and the two most persuasive points to me were:

(1) Blocks are essentially nearing "full" now.  And by "full" he means
that the reliability of the network (from the average user perspective)
is about to be impacted in a very negative way (I believe it was due to
the inconsistent time between blocks).  I think Gavin said that his
simulations showed 400 kB - 600 kB worth of transactions per 10 min
(approx 3-4 tps) is where things start to behave poorly for certain
classes of transactions.  In other words, we're very close to the
effective limit in terms of maintaining the current "standard of
living", and with a year needed to raise the block time this actually is
urgent.

(2) Leveraging fee pressure at 1MB to solve the problem is actually
really a bad idea.  It's really bad while Bitcoin is still growing, and
relying on fee pressure at 1 MB severely impacts attractiveness and
adoption potential of Bitcoin (due to high fees and unreliability).  But
more importantly, it ignores the fact that for a 7 tps is pathetic for a
global transaction system.  It is a couple orders of magnitude too low
for any meaningful commercial activity to occur.  If we continue with a
cap of 7 tps forever, Bitcoin *will* fail.  Or at best, it will fail to
be useful for the vast majority of the world (which probably leads to
failure).  We shouldn't be talking about fee pressure until we hit 700
tps, which is probably still too low. 

You can argue that side chains and payment channels could alleviate
this.  But how far off are they?  We're going to hit effective 1MB
limits long before we can leverage those in a meaningful way.  Even if
everyone used them, getting a billion people onto the system just can't
happen even at 1 transaction per year per person to get into a payment
channel or move money between side chains.

We get asked all the time by corporate clients about scalability.  A
limit of 7 tps makes them uncomfortable that they are going to invest
all this time into a system that has no chance of handling the economic
activity that they expect it handle.  We always assure them that 7 tps
is not the final answer. 

Satoshi didn't believe 1 MB blocks were the correct answer.  I
personally think this is critical to Bitcoin's long term future.   And
I'm not sure what else Gavin could've done to push this along in a
meaninful way.

-Alan


On 05/07/2015 02:06 PM, Mike Hearn wrote:
>
> I think you are rubbing against your own presupposition that
> people must find and alternative right now. Quite a lot here do
> not believe there is any urgency, nor that there is an immanent
> problem that has to be solved before the sky falls in.
>
>
> I have explained why I believe there is some urgency, whereby "some
> urgency" I mean, assuming it takes months to implement, merge, test,
> release and for people to upgrade.
>
> But if it makes you happy, imagine that this discussion happens all
> over again next year and I ask the same question.
>
>
>
> --
> 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

--
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

Re: [Bitcoin-development] Block Size Increase

[Matt Corallo]

On 05/07/15 11:29, Mike Hearn wrote:
> Can you please elaborate on what terrible things will happen if we
> don't increase the block size by winter this year?
> 
> 
> I was referring to winter next year. 0.12 isn't scheduled until the end
> of the year, according to Wladimir. I explained where this figure comes
> from in this article:

On a related note, I'd like to agree strongly with Peter Todd that we
should get away from doing forks-only-in-releases. We can add code to do
a fork and then enable it in 0.11.1 or 0.11.11 if Gavin prefers more 11s.

--
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

Re: [Bitcoin-development] Block Size Increase

[Jeff Garzik]

On Thu, May 7, 2015 at 3:03 PM, Matt Corallo 
wrote:
> More generally, consider the situation we're in now. Gavin is going off
> pitching this idea to the general public (which, I agree, is an
> important step in pulling off a hardfork) while people who actually
> study the issues are left wondering why they're being ignored (ie why is
> there no consensus-building happening on this list?).

This sub-thread threatens to veer off into he-said-she-said.

> If, instead, there had been an intro on the list as "I think we should
> do the blocksize increase soon, what do people think?", the response
> could likely have focused much more around creating a specific list of
> things we should do before we (the technical community) think we are
> prepared for a blocksize increase.

Agreed, but that is water under the bridge at this point.  You - rightly -
opened the topic here and now we're discussing it.

Mike and Gavin are due the benefit of doubt because making a change to a
leaderless automaton powered by leaderless open source software is breaking
new ground.  I don't focus so much on how we got to this point, but rather,
where we go from here.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
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

Re: [Bitcoin-development] Block Size Increase

[Matt Corallo]

Replies inline.

On 05/07/15 17:43, Mike Hearn wrote:
> The only answer to this that anyone with a clue should give is "it
> will very, very likely be able to support at least 1MB blocks
> roughly every 10 minutes on average for the next eleven years, and
> it seems likely that a block size increase of some form will happen
> at some point in the next eleven years", anything else is dishonest.
> 
> 
> Matt, you know better than that. Gavin neither lacks clue nor is he
> dishonest. 

No, I dont think Gavin is being deliberately dishonest, and I'm rather
confident he phrased everything in a way that is technically true (ie
the quote in his response). However, others have definitely not taken
away the correct interpretation of what he said, and this is a serious
problem. Setting expectations correctly as this is a very contentious
issue and one that does not appear to be reaching consensus quickly in
the technical community is important.
More generally, consider the situation we're in now. Gavin is going off
pitching this idea to the general public (which, I agree, is an
important step in pulling off a hardfork) while people who actually
study the issues are left wondering why they're being ignored (ie why is
there no consensus-building happening on this list?).


> He has been working on the assumption that other developers are
> reasonable, and some kind of compromise solution can be found that
> everyone can live with. Hence trying to find a middle ground, hence
> considering and writing articles in response to every single objection
> raised. Hence asking for suggestions on what to change about the plan,
> to make it more acceptable. What more do you want, exactly?

The appropriate method of doing any fork, that we seem to have been
following for a long time, is to get consensus here and on IRC and on
github and *then* go pitch to the general public (either directly or by
releasing software) that they should upgrade. I admit that hardforks are
a bit different in that the level of software upgrade required means
additional lead time, but I'm not sure that means starting the
public-pitching phase before there is any kind of consensus forming
(actually, I'd point out that to me there seems to be rahter clear
consensus outside of you and Gavin that we should delay increasing block
size).
As far as I can tell, there has been no discussion of block sizes on
this list since 2013, and while I know Gavin has had many private
conversations with people in this community about the block size, very
little if any of it has happened in public.
If, instead, there had been an intro on the list as "I think we should
do the blocksize increase soon, what do people think?", the response
could likely have focused much more around creating a specific list of
things we should do before we (the technical community) think we are
prepared for a blocksize increase.

> And I'll ask again. Do you have a *specific, credible alternative*?
> Because so far I'm not seeing one.

A specific credible alternative to what? Committing to blocksize
increases tomorrow? Yes, doing more research into this and developing
software around supporting larger block sizes so people feel comfortable
doing it in six months. I acknowledge that Gavin has been putting a lot
of effort into this front, but, judging by this thread, I am far from
the only one who thinks much more needs done.

--
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

Re: [Bitcoin-development] Block Size Increase

[Ross Nicoll]

I'm presuming that schedule is just an example, as you'd end up with 
insanely large block sizes in a few years.


Absolutely, yes, an increase schedule is an option if people agree on 
it, and I think the better option, as the current limit too low, but 
jumping straight to a value big enough for "indefinitely" is a huge jump.


Gave some thought to scaling block size based on transaction fees, but 
suspect it would end up with miners sending huge fees to themselves with 
transactions that aren't relayed (so they only are actioned if they make 
it into a block that miner mines) to make the network allow bigger blocks.


Ross

On 07/05/2015 19:38, Chris Wardell wrote:
Instead of raising the block size to another static number like 20MB, 
can we raise it dynamically?


Make the max block size something like:
pow(2, nHeight/10) * 1MB;  //double every ~2 years



--
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


--
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

Re: [Bitcoin-development] Block Size Increase

[Alex Mizrahi]

Just to add to the noise, did you consider linear growth?

Unlike exponential growth, it approximates diminishing returns (i.e. tech
advances become slower with time). And unlike single step, it will give
people time to adapt to new realities.

E.g. 2 MB in 2016, 3 MB in 2017 and so on.
So in 20 years we'll get to 20 MB which "ought to be enough for anybody".
But if miners will find 20 MB blocks too overwhelming, they can limit it
through soft work, based on actual data.
--
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

Re: [Bitcoin-development] Block Size Increase

[Btc Drak]

On Thu, May 7, 2015 at 7:40 PM, Gavin Costin 
wrote:

> Can anyone opposed to this proposal articulate in plain english the worst
> case scenario(s) if it goes ahead?
>
> Some people in the conversation appear to be uncomfortable, perturbed,
> defensive etc about the proposal …. But I am not seeing specifics on why it
> is not a feasible plan.
>

See this response:
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07462.html
--
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

Re: [Bitcoin-development] Block Size Increase

[Gavin Costin]

Can anyone opposed to this proposal articulate in plain english the worst
case scenario(s) if it goes ahead?

Some people in the conversation appear to be uncomfortable, perturbed,
defensive etc about the proposal Š. But I am not seeing specifics on why it
is not a feasible plan.

From:  Mike Hearn 
Date:  Friday, 8 May, 2015 2:06 am
To:  Btc Drak 
Cc:  Bitcoin Dev 
Subject:  Re: [Bitcoin-development] Block Size Increase

> I think you are rubbing against your own presupposition that people must find
> and alternative right now. Quite a lot here do not believe there is any
> urgency, nor that there is an immanent problem that has to be solved before
> the sky falls in.

I have explained why I believe there is some urgency, whereby "some urgency"
I mean, assuming it takes months to implement, merge, test, release and for
people to upgrade.

But if it makes you happy, imagine that this discussion happens all over
again next year and I ask the same question.


-- 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

--
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

Re: [Bitcoin-development] Block Size Increase

[Ross Nicoll]

Can I just add my own support for this - as has been stated elsewhere in 
this discussion, hard forks are difficult, and risky. The earlier we 
have a decision, and the earlier the change goes into the code, the 
easier that is.


Even if the decision was the actual block size change is fine to leave 
until 2020, I'd like to see the code committed ASAP so that every new 
install, and every upgrade from there on gets the new version.


My personal opinion only is that 7 transactions a second is insanely 
limited even if the main chain does nothing but act as a backbone 
between other chains and transaction networks. I don't think that's 
overly controversial. I think 2016 is too early for a 20mb block size, 
though. I'm inclined to suggest a schedule of expansion, say to 2mb in 
2016, 4mb in 2018, 8mb in 2020 and 20mb in 2022 where it stops. The 
intent would be to provide enough size pressure to motivate scaling 
work, while not limiting Bitcoin overly.


Further, I think this highlights that we need more work on fees. Right 
now fees and transactions included are fairly naive, but I'd like to see 
the absolute block size limit as a hard upper bound, with miners 
imposing soft limits based on a balance cost of storage, number of 
outputs vs inputs (and therefore impact on the UTXOs), and risk of 
orphan blocks to determine which transactions are actually worth 
including in each block. If anyone has numbers on block size vs orphan 
rate that would be really useful, BTW.


Ross

On 07/05/2015 19:06, Mike Hearn wrote:


I think you are rubbing against your own presupposition that
people must find and alternative right now. Quite a lot here do
not believe there is any urgency, nor that there is an immanent
problem that has to be solved before the sky falls in.


I have explained why I believe there is some urgency, whereby "some 
urgency" I mean, assuming it takes months to implement, merge, test, 
release and for people to upgrade.


But if it makes you happy, imagine that this discussion happens all 
over again next year and I ask the same question.




--
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


--
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

Re: [Bitcoin-development] Block Size Increase

[Chris Wardell]

Instead of raising the block size to another static number like 20MB, can
we raise it dynamically?

Make the max block size something like:
pow(2, nHeight/10) * 1MB;  //double every ~2 years
--
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

Re: [Bitcoin-development] Block Size Increase

[Jorge Timón]

On Thu, May 7, 2015 at 6:59 PM, Gavin Andresen  wrote:
> Fee dynamics seems to come up over and over again in these discussions, with
> lots of talk and theorizing.
>
> I hope some data on what is happening with fees right now might help, so I
> wrote another blog post (with graphs, which can't be done in a mailing list
> post):
>http://gavinandresen.ninja/the-myth-of-not-full-blocks
>
> We don’t need 100% full one megabyte blocks to start to learn about what is
> likely to happen as transaction volume rises and/or the one megabyte block
> size limit is raised.

Ok, the fact that the fee increases the probability of getting
included faster already is a good thing, the graphs with the
probability of getting included in the next block were less important
to me.
Although scarce space (beyond what miners chose to limit by
themselves) would increase the fee competition, I didn't knew that
there is actually some competition happening already.
So I guess this diminishes the argument for maintaining the limits
longer to observe the results of more scarce space.
Still, I think maintaining a lower policy limit it's a good idea, even
if we decide not to use it to observe that soon.
For example, say we chose the 20 MB consensus limit, we can maintain
the policy limit at 1 MB or move it to 2 MB, and slowly moving it up
later as needed without requiring everyone to upgrade.
Of course, not all miners have to follow the standard policy, but at
least it's something.
So please take this as a suggestion to improve your proposal. You can
argue it like this "if we want to maintain the limits after the
hardfork or increase them slowly, for observing fee dynamics with more
scarce space or for any other reason, those limits can be partially
enforced by the standard policy". I mean, I think that could be a
reasonable compromise for that concrete line of arguments.

--
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

Re: [Bitcoin-development] Block Size Increase

[Mike Hearn]

>
> I think you are rubbing against your own presupposition that people must
> find and alternative right now. Quite a lot here do not believe there is
> any urgency, nor that there is an immanent problem that has to be solved
> before the sky falls in.
>

I have explained why I believe there is some urgency, whereby "some
urgency" I mean, assuming it takes months to implement, merge, test,
release and for people to upgrade.

But if it makes you happy, imagine that this discussion happens all over
again next year and I ask the same question.
--
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

Re: [Bitcoin-development] Block Size Increase

[Btc Drak]

On Thu, May 7, 2015 at 6:43 PM, Mike Hearn  wrote:
>
> And I'll ask again. Do you have a *specific, credible alternative*?
> Because so far I'm not seeing one.
>

I think you are rubbing against your own presupposition that people must
find and alternative right now. Quite a lot here do not believe there is
any urgency, nor that there is an immanent problem that has to be solved
before the sky falls in.
--
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

Re: [Bitcoin-development] Block Size Increase

[Mike Hearn]

> The only answer to this that anyone with a clue should give is "it
> will very, very likely be able to support at least 1MB blocks roughly
> every 10 minutes on average for the next eleven years, and it seems
> likely that a block size increase of some form will happen at some point in
> the next eleven years", anything else is dishonest.


Matt, you know better than that. Gavin neither lacks clue nor is he
dishonest.

He has been working on the assumption that other developers are reasonable,
and some kind of compromise solution can be found that everyone can live
with. Hence trying to find a middle ground, hence considering and writing
articles in response to every single objection raised. Hence asking for
suggestions on what to change about the plan, to make it more acceptable.
What more do you want, exactly?

And I'll ask again. Do you have a *specific, credible alternative*? Because
so far I'm not seeing one.
--
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

Re: [Bitcoin-development] Block Size Increase

[Peter Todd]

On Thu, May 07, 2015 at 12:59:13PM -0400, Gavin Andresen wrote:
> Fee dynamics seems to come up over and over again in these discussions,
> with lots of talk and theorizing.
> 
> I hope some data on what is happening with fees right now might help, so I
> wrote another blog post (with graphs, which can't be done in a mailing list
> post):
>http://gavinandresen.ninja/the-myth-of-not-full-blocks
> 
> We don’t need 100% full one megabyte blocks to start to learn about what is
> likely to happen as transaction volume rises and/or the one megabyte block
> size limit is raised.

Sounds like you're saying we are bumping up against a 1MB limit. However
other than the occasional user who has sent a transaction with an
extremely low/no fee, what evidence do we have that this is or is not
actually impacting meaningful usage form the user's point of view?

Do we have evidence as to how users are coping? e.g. do they send time
sensitive transactiosn with higher fees? Are people conciously moving
low value transactions off the blockchain? Equally, what about the story
with companies? You of course are an advisor to Coinbase, and could give
us some insight into the type of planning payment processors/wallets are
doing.  For instance, does Coinbase have any plans to work with other
wallet providers/payment processors to aggregate fund transfers between
wallet providers - an obvious payment channel application.

-- 
'peter'[:-1]@petertodd.org
0232164c96eaa6bf7cbc3dc61ea055840715b5a81ee8f6be


signature.asc
Description: Digital signature
--
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

Re: [Bitcoin-development] Block Size Increase

[Peter Todd]

On Thu, May 07, 2015 at 06:21:50PM +0200, Jorge Timón wrote:
> On Thu, May 7, 2015 at 4:52 PM, Gavin Andresen  
> wrote:
> > I would very much like to find some concrete course of action that we can
> > come to consensus on. Some compromise so we can tell entrepreneurs "THIS is
> > how much transaction volume the main Bitcoin blockchain will be able to
> > support over the next eleven years."
> 
> Mhmm, I hadn't thought about this. This makes sense and actually
> explains the urgency on taking a decision better than anything else
> I've heard.

I've spent a lot of time talking to companies about this, and the
problem is telling them that isn't actually very useful; knowing the
supply side of the equation isn't all that useful if you don't know the
demand side. Problem is we don't really have a good handle on what
Bitcoin will be used for in the future, or even for that matter, what
it's actually being used for right now.

As we saw with Satoshidice before and quite possibly will see with smart
contracts (escrows, futures, etc) it's easy for a relatively small
number of use cases to drive a significant amount of transaction volume.
Yet, as Wladimir and others point out, the fundemental underlying
architecture of the blockchain has inherently poor O(n^2) scaling, so
there's always some level of demand where it breaks, and/or incentivizes
actors in the space to push up against "safety stops" like soft
blocksize limits and get them removed.

Note how the response previously to bumping up against soft policy
limits was highly public calls(1) at the first hint of touble: "Mike
Hearn: Soft block size limit reached, action required by YOU"

1) https://bitcointalk.org/index.php?topic=149668.0

-- 
'peter'[:-1]@petertodd.org
02761482983864328320badf24d137101fab9a5861a59d30


signature.asc
Description: Digital signature
--
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

Re: [Bitcoin-development] Block Size Increase

[Matt Corallo]

On 05/07/15 14:52, Gavin Andresen wrote:
> For reference: the blog post that (re)-started this debate, and which
> links to individual issues, is here:
>   http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
> 
> In it, I asked people to email me objections I might have missed. I
> would still appreciate it if people do that; it is impossible to keep up
> with this mailing list, /r/bitcoin posts and comments, and
> #bitcoin-wizards and also have time to respond thoughtfully to the
> objections raised.

People have been sharing the same objections as on this list for months,
I'm not sure what is new here.

> I would very much like to find some concrete course of action that we
> can come to consensus on. Some compromise so we can tell entrepreneurs
> "THIS is how much transaction volume the main Bitcoin blockchain will be
> able to support over the next eleven years."

I think this is a huge issue. You've been wandering around telling
people that the blocksize will increase soon for months, when there is
very clearly no consensus that it should in the short-term future. The
only answer to this that anyone with a clue should give is "it will
very, very likely be able to support at least 1MB blocks roughly every
10 minutes on average for the next eleven years, and it seems likely
that a block size increase of some form will happen at some point in the
next eleven years", anything else is dishonest.

--
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

Re: [Bitcoin-development] Block Size Increase

[Gavin Andresen]

Fee dynamics seems to come up over and over again in these discussions,
with lots of talk and theorizing.

I hope some data on what is happening with fees right now might help, so I
wrote another blog post (with graphs, which can't be done in a mailing list
post):
   http://gavinandresen.ninja/the-myth-of-not-full-blocks

We don’t need 100% full one megabyte blocks to start to learn about what is
likely to happen as transaction volume rises and/or the one megabyte block
size limit is raised.

-- 
--
Gavin Andresen
--
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

Re: [Bitcoin-development] Block Size Increase

[John Bodeen]

If the worry about raising the block size will increase centralization,
could not one could imagine an application which rewarded decentralized
storage of block data? It could even be build aside or on top of the
existing bitcoin protocol.

See the Permacoin paper by Andrew Miller:
http://cs.umd.edu/~amiller/permacoin.pdf

Regards
--
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

Re: [Bitcoin-development] Block Size Increase

[Jorge Timón]

On Thu, May 7, 2015 at 6:11 PM, Mike Hearn  wrote:
>> It is an argument against my admittedly vague definition of
>> "non-controversial change".
>
>
> If it's an argument against something you said, it's not a straw man, right
> ;)

Yes, but it was an argument against something I didn't said ;)

> Consensus has to be defined as agreement between a group of people. Who are
> those people? If you don't know, it's impossible to decide when there is
> consensus or not.
>
> Right now there is this nice warm fuzzy notion that decisions in Bitcoin
> Core are made by consensus. "Controversial" changes are avoided. I am trying
> to show you that this is just marketing. Nobody can define what these terms
> even mean. It would be more accurate to say decisions are vetoed by whoever
> shows up and complains enough, regardless of technical merit.

Yes, that's why I drafted a definition for "uncontroversial change"
rather than "change accepted by consensus".
It will still be vague and hard to define, but consensus seems much harder.
And, yes, you're right, it is more like giving power to anyone with
valid arguments to veto hardfork changes.
But as you say, that could lead to make hardforks actually impossible,
so we should limit what constitutes a valid argument.
I later listed some examples of invalid arguments: logical fallacies,
unrelated arguments, outright lies.
Certainly I don't think technical merits should count here or that we
could veto a particular person from vetoing.
We should filter the arguments, not require an identity layer to
blacklist individuals.
We should even accept arguments from anonymous people in the internet
(you know, it wouldn't be the first time).

> Unfortunately it's hard to know what other kinds of meet-in-the-middle
> compromise could be made here. I'm sure Gavin would consider them if he
> knew. But the concerns provided are too vague to address. There are no
> numbers in them, for example:
>
> We need more research -> how much more?

Some research at all about fee market dynamics with limited size that
hasn't happened at all.
If we're increasing the consensus max size maybe we could at least
maintain the 1MB limit as a standard policy limit, so that we can
study it a little bit (like we could have done instead of removing the
initial policy limit).

> I'm not against changing the size, just not now -> then when?

I don't know yet, but I understand now that having a clearer roadmap
is what's actually urgent, not the change itself.

> I'm not wedded to 1mb, but not sure 20mb is right -> then what?

What about 2 MB consensus limit and 1 MB policy limit for now? I know
that's arbitrary too.

> Full node count is going down -> then what size do you think would fix that?
> 100kb?

As others have explained, the number of full nodes is not the
improtant part, but how easy it is to run one.
I think a modest laptop with the average internet connection of say,
India or Brazil, should be able to run a full node.
I haven't made those numbers myself but I'm sure that's possible with
1 MB blocks today, and probably with 2 MB blocks too.

> It will make mining more centralised -> how do you measure that and how much
> centralisation would you accept?

This is an excellent question for both sides.
Unfortunately I don't know the answer to this. Do you?

--
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

Re: [Bitcoin-development] Block Size Increase

[Matthew Mitchell]

One thing to add is that perhaps in a future version of Bitcoin Core,
there could be an option for users to continue using the old consensus
rules, or an option to support the new rules (an option when they update
and an ability to change in the settings). Both types of user can
benefit from the software updates and choose with a single piece of
software what they support. Information for whether or not a user is
supporting the changes could be included in the version message.
Possibly this information could be incorporated into transactions also.

If they wish to support the new rules, then their client would support
larger blocks when there is majority miner consensus, otherwise their
clients will always only support the old rules.

This way the decision is not being forced upon the user in any way.

Just an idea.

On 07/05/15 16:58, Matthew Mitchell wrote:
> In my personal opinion, this does make some sense to me, assuming I
> understood Gavin.
> 
> I suppose it could be done with a new flag (like the P2SH flag) which
> displays miner support for larger blocks. The new rules would apply when
> a large majority of miners support the new rules by counting the number
> of flagged blocks over a certain number of blocks on the network in a
> deterministic fashion.
> 
> This way miners can continue to produce blocks which are supported by
> both old and new clients. When it appears most people have migrated to
> the new client, miners can start flagging support for the new rules, and
> when a large majority of miners agree, the new rules would kick in for
> all miners/clients running the new software. Miners could therefore glue
> together the network during the migration phase until enough people have
> updated to avoid severe fork scenarios. The only problem is ensuring
> that miners will continue to support both networks for long enough to
> enable successful migration.
> 
> And if too many people disagree to make a clean hard fork (too many
> people stubbornly stick to the old rules), then it could be that the
> hard fork is aborted and everyone goes back to the old rules, or quite
> simply that the miners never give support for the new rules despite the
> mechanism being included in the new client. In those cases it would be
> as if nothing changed.
> 
> This way the hard fork would be determined by user participation as
> judged by the miners.
> 
> If it is done, I can't think of a fairer way.
> 
> Matthew Mitchell
> 
> On 07/05/15 15:52, Gavin Andresen wrote:
>> For reference: the blog post that (re)-started this debate, and which
>> links to individual issues, is here:
>>   http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
>>
>> In it, I asked people to email me objections I might have missed. I
>> would still appreciate it if people do that; it is impossible to keep up
>> with this mailing list, /r/bitcoin posts and comments, and
>> #bitcoin-wizards and also have time to respond thoughtfully to the
>> objections raised.
>>
>> I would very much like to find some concrete course of action that we
>> can come to consensus on. Some compromise so we can tell entrepreneurs
>> "THIS is how much transaction volume the main Bitcoin blockchain will be
>> able to support over the next eleven years."
>>
>> I've been pretty clear on what I think is a reasonable compromise (a
>> one-time increase scheduled for early next year), and I have tried to
>> explain why I think it it is the right set of tradeoffs.
>>
>> There ARE tradeoffs here, and the hard question is what process do we
>> use to decide those tradeoffs?  How do we come to consensus? Is it worth
>> my time to spend hours responding thoughtfully to every new objection
>> raised here, or will the same thing happen that happened last year and
>> the year before-- everybody eventually gets tired of arguing
>> angels-dancing-on-the-head-of-a-pin, and we're left with the status quo?
>>
>> I AM considering contributing some version of the bigger blocksize-limit
>> hard-fork patch to the Bitcoin-Xt fork (probably  "target a hobbyist
>> with a fast Internet connection, and assume Nelson's law to increase
>> over time), and then encouraging merchants and exchanges and web wallets
>> and individuals who think it strikes a reasonable balance to run it.
>>
>> And then, assuming it became a super-majority of nodes on the network,
>> encourage miners to roll out a soft-fork to start producing bigger
>> blocks and eventually trigger the hard fork.
>>
>> Because ultimately consensus comes down to what software people choose
>> to run.
>>
>> -- 
>> --
>> Gavin Andresen
>>
>>
>>
>> --
>> 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

Re: [Bitcoin-development] Block Size Increase

[Jorge Timón]

On Thu, May 7, 2015 at 4:52 PM, Gavin Andresen  wrote:
> I would very much like to find some concrete course of action that we can
> come to consensus on. Some compromise so we can tell entrepreneurs "THIS is
> how much transaction volume the main Bitcoin blockchain will be able to
> support over the next eleven years."

Mhmm, I hadn't thought about this. This makes sense and actually
explains the urgency on taking a decision better than anything else
I've heard.

On Thu, May 7, 2015 at 5:29 PM, Mike Hearn  wrote:
> If it's not raised, then ... well, then we're in new territory entirely.
> Businesses built on the assumption that Bitcoin could become popular will
> suddenly have their basic assumptions invalidated. Users will leave. The
> technical code change would be zero, but the economic change would be
> significant.

This, on the other hand, is a non sequitur [1], another type of fallacy.
Well, several of them, actually:

- If it's not raised, then bitcoin cannot become popular
- If it's not raised, then users will leave
- Businesses built on the assumption that Bitcoin could become popular
were also assuming that it's going to be risen.

These statements may even be true, but they're no logical conclusions
even if they seem obvious to you.
I don't think those claims are strictly true, specially because they
involve predictions about what people will do.
But if they're true they require some proof or at least some explanation.

[1] http://en.wikipedia.org/wiki/Non_sequitur_(logic)#Affirming_the_consequent

--
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

Re: [Bitcoin-development] Block Size Increase

[Justus Ranvier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/07/2015 03:35 PM, Jeff Garzik wrote:
> Raising the block size limit then becomes a *human decision* to
> favor some users over others, a *human decision* to prevent an
> active and competitive free fee market developing at 1MB, a *human
> decision* to keep transaction fees low to incentivize bitcoin
> adoption, a *human decision* to value adoption over
> decentralization.

At the moment none of the following assertions have been proven true,
yet are constantly cited as if they have been:

* A competitive fee market will develop when the transaction rate
becomes constrained by the block size limit
* More users of Bitcoin means less decentralization

Furthermore, the term "decentralization" is frequently used without
being precisely defined in a way that would allow for such proofs to
be debated.

If there's going to be a debate on those points, then the people
presenting points on both sides should take the time to show their
work and explain the methodology they used to reach their conclusions.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJVS5BXAAoJECpf2nDq2eYjC3kQAKQ0Jj8r1gjwpl813NiuatjA
nwXJ+Zn7E+cS8bYsXbaPK1uUgcSdpi/g2jgW+VuUPlqCaNo08Pbp/O7pG5ady9st
o7xJnPxttg7NO3IB7GODCJKK85uBO3dOwPp+pfs8KYCAo5PFTflpeOi4Idbd4w/R
+tvLynpSX9LIZTQaJH2KEbrYUibYHZrr8hj0net9lJP8KeqMnCuiesYzjJ4pUXyE
zN0SQ1v9QnpltbTVxRu1TdRBMjAxEHTJPg1jsv0hhGqIOQGHdwNavGq7+LJBen4T
CvT8ooTmuq0IdihOTttl9ody6Eh0tyGPlbVHiI3c2Emm0HTxz8hN9Rl4lvPgcGdi
EUW12h8ailKLg5uJL53Zp1PO6fgl0Z/WCx/zqIKRPg4lJMf5Rk5Ow86xAeIZrsbr
d/+cJZEhqzPnObxkxgTIzqtG8NHcg9dhKw1xkGAkVpMXMM7Bzdku8WCntIYU4+xI
btQQZlbc5h/S+X9Vcu0rJWmmQp2Q8xeEVGRh4hhA8LZLc1P+1eyESjAMWvsuq+rk
Wd1kPopekhOgK0zw2j55Ov+kJXVa2pDFA7TOpcqxbdLU4eauKC4D+YQlTM4qj285
vyRq+c/AwMCPiEhBeEbppgdgwrIQP9fJ7s+2TAHaWICYlTJWkLitUjN9EBwqv3Yp
LRBrgV7giz8UIrJr3hQZ
=+Qmg
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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

Re: [Bitcoin-development] Block Size Increase

[Mike Hearn]

>
> Dear list,
>
> Apparently my emails are being marked as spam, despite being sent from
> GMail's web interface.  I've pinged our sysadmin.


It's a problem with the mailing list software, not your setup. BitPay could
disable the phishing protections but that seems like a poor solution. The
only real fix is to send from a non @bitpay.com email address. Gmail or
Hotmail will work, I think. Yahoo won't: they enforce the same strict
policies than bitpay does.
--
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

Re: [Bitcoin-development] Block Size Increase

[Mike Hearn]

>
> It is an argument against my admittedly vague definition of
> "non-controversial change".
>

If it's an argument against something you said, it's not a straw man, right
;)

Consensus has to be defined as agreement between a group of people. Who are
those people? If you don't know, it's impossible to decide when there is
consensus or not.

Right now there is this nice warm fuzzy notion that decisions in Bitcoin
Core are made by consensus. "Controversial" changes are avoided. I am
trying to show you that this is just marketing. Nobody can define what
these terms even mean. It would be more accurate to say decisions are
vetoed by whoever shows up and complains enough, regardless of technical
merit. After all, my own getutxo change was merged after a lot of technical
debate (and trolling) . then unmerged a day later because "it's a
shitstorm".

So if Gavin showed up and complained a lot about side chains or whatever,
what you're saying is, oh that's different. We'd ignore him. But when
someone else complains about a change they don't like, that's OK.

Heck, I could easily come up with a dozen reasons to object to almost any
change, if I felt like it. Would I then be considered not a part of the
consensus because that'd be convenient?


> I'm sure that's not what the proponents of the size increase want, and
> I'm not defending 1 MB as a sacred limit  or anything, but my question
> is "where is the limit for them?"
>

20mb is an arbitrary number, just like 1mb. It's good enough to keep the
Bitcoin ecosystem operating as it presently does: gentle growth in usage
with the technology that exists and is implemented. Gavin has discussed in
his blog why he chose 20mb, I think. It's the result of some estimates
based on average network/hardware capabilities.

Perhaps one day 20mb will not be enough. Perhaps then the limit will be
raised again, if there is sufficient demand.

You are correct that "no limit at all" is a possible answer. More
precisely, in that case miners would choose. Gavin's original proposal was
20mb+X where X is decided by some incrementing formula over time, chosen to
approximate expected improvements in hardware and software. That was cool
too. The 20mb figure and the formula were an attempt to address the
concerns of people who are worried about the block size increase:  a
meet-in-the-middle compromise.

Unfortunately it's hard to know what other kinds of meet-in-the-middle
compromise could be made here. I'm sure Gavin would consider them if he
knew. But the concerns provided are too vague to address. There are no
numbers in them, for example:

   - We need more research -> how much more?
   - I'm not against changing the size, just not now -> then when?
   - I'm not wedded to 1mb, but not sure 20mb is right -> then what?
   - Full node count is going down -> then what size do you think would fix
   that? 100kb?
   - It will make mining more centralised -> how do you measure that and
   how much centralisation would you accept?

and so on.
--
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

Re: [Bitcoin-development] Block Size Increase

[Matthew Mitchell]

In my personal opinion, this does make some sense to me, assuming I
understood Gavin.

I suppose it could be done with a new flag (like the P2SH flag) which
displays miner support for larger blocks. The new rules would apply when
a large majority of miners support the new rules by counting the number
of flagged blocks over a certain number of blocks on the network in a
deterministic fashion.

This way miners can continue to produce blocks which are supported by
both old and new clients. When it appears most people have migrated to
the new client, miners can start flagging support for the new rules, and
when a large majority of miners agree, the new rules would kick in for
all miners/clients running the new software. Miners could therefore glue
together the network during the migration phase until enough people have
updated to avoid severe fork scenarios. The only problem is ensuring
that miners will continue to support both networks for long enough to
enable successful migration.

And if too many people disagree to make a clean hard fork (too many
people stubbornly stick to the old rules), then it could be that the
hard fork is aborted and everyone goes back to the old rules, or quite
simply that the miners never give support for the new rules despite the
mechanism being included in the new client. In those cases it would be
as if nothing changed.

This way the hard fork would be determined by user participation as
judged by the miners.

If it is done, I can't think of a fairer way.

Matthew Mitchell

On 07/05/15 15:52, Gavin Andresen wrote:
> For reference: the blog post that (re)-started this debate, and which
> links to individual issues, is here:
>   http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
> 
> In it, I asked people to email me objections I might have missed. I
> would still appreciate it if people do that; it is impossible to keep up
> with this mailing list, /r/bitcoin posts and comments, and
> #bitcoin-wizards and also have time to respond thoughtfully to the
> objections raised.
> 
> I would very much like to find some concrete course of action that we
> can come to consensus on. Some compromise so we can tell entrepreneurs
> "THIS is how much transaction volume the main Bitcoin blockchain will be
> able to support over the next eleven years."
> 
> I've been pretty clear on what I think is a reasonable compromise (a
> one-time increase scheduled for early next year), and I have tried to
> explain why I think it it is the right set of tradeoffs.
> 
> There ARE tradeoffs here, and the hard question is what process do we
> use to decide those tradeoffs?  How do we come to consensus? Is it worth
> my time to spend hours responding thoughtfully to every new objection
> raised here, or will the same thing happen that happened last year and
> the year before-- everybody eventually gets tired of arguing
> angels-dancing-on-the-head-of-a-pin, and we're left with the status quo?
> 
> I AM considering contributing some version of the bigger blocksize-limit
> hard-fork patch to the Bitcoin-Xt fork (probably  "target a hobbyist
> with a fast Internet connection, and assume Nelson's law to increase
> over time), and then encouraging merchants and exchanges and web wallets
> and individuals who think it strikes a reasonable balance to run it.
> 
> And then, assuming it became a super-majority of nodes on the network,
> encourage miners to roll out a soft-fork to start producing bigger
> blocks and eventually trigger the hard fork.
> 
> Because ultimately consensus comes down to what software people choose
> to run.
> 
> -- 
> --
> Gavin Andresen
> 
> 
> 
> --
> 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
> 



signature.asc
Description: OpenPGP digital signature
--
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

Re: [Bitcoin-development] Block Size Increase

[Jeff Garzik]

Dear list,

Apparently my emails are being marked as spam, despite being sent from
GMail's web interface.  I've pinged our sysadmin.  Thanks for letting
me know.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
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

Re: [Bitcoin-development] Block Size Increase

[Justus Ranvier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/07/2015 05:47 PM, Jeff Garzik wrote:
> Bitcoin needs to be the best it can be (Layer 1), but all solutions
> cannot and should not be implemented at Layer 1.

I can provisionally agree with that statement as long as "all
solutions cannot and should not be implemented at Layer 1" it taken to
be a hypothesis to be tested in the context of each proposed solution
rather than a law of nature.

-BEGIN PGP SIGNATURE-

iQIcBAEBAgAGBQJVS4nOAAoJECpf2nDq2eYjZGEP/jvk+RNQO+Zoyp0jc6aup5Aa
USUFk1TYBqbu47vvc3jFHc4V3/BjiwkUKp5bZ4iIxr3xWIA35CcjfpSJEIlEj0zM
OHS2j+eS0WkNWCmWgj+3sJpQBNnqLmdBOG1q6z0aBLGwG7uabo+YAhJjlP8isfcn
cBQPGjeTW82ZZLdkNaThbFr53oTYiVPNqMIIq6orUe5vetQS/zfTyowi7Y9+OT+b
FMXOEmXQTzF415LImJNXOcGFx51YkLe3SuEPEqqIX/+gOcT4HMPuKbqyAu6xXRQK
O7uI+6AjN1mX7Cvt19wYkUggJ7ddVKrHINSzOfsZ+pdF8mdY4TrdwJJhfN0+fnvo
KYW+pmEAFRMveV8SVGJpHQ/pWECKbFiz1SRnDfjlbX/C5mHiHM4EmqCxC1pVDxOU
uDukt+ZIIiP7GwPYxqSknR4lcuwsdFFJf9ldxD+ZRNsmz1l+PkaUUpdkCc9u9rUW
2IyfvPmeeVUPLP9N675kfiM3aKNO7LHN8GhSUe+1Nt/zcXg6xg0QWKdXjC8nykCa
eH9gn0QoQZaZbfKnb8DLwLjCO5LiOzQTgqdo0ZSJtV/CipqyGcBJtFYW2olG/BvO
Ns6qJKG6Ck76Tv31cu3YGpVbBjCxsIovchLh72KjQ9LscYg8y29evcFlnyagsewY
5CQJsAY8apmvNvmxAhRf
=oRV/
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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

Re: [Bitcoin-development] Block Size Increase

[Jeff Garzik]

On Thu, May 7, 2015 at 11:33 AM, Justus Ranvier 
wrote:

> In summary, I asked a question neither you, nor Peter Todd, want to
> answer and want to actively discourage people from even asking at all.
>

Incorrect; your question included built-in assumptions with which I
disagree.

Bitcoin needs to be the best it can be (Layer 1), but all solutions cannot
and should not be implemented at Layer 1.

We need to scale up both bitcoin (L1) and solutions built on top of bitcoin
(L2).
--
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

Re: [Bitcoin-development] Block Size Increase

[Btc Drak]

On Thu, May 7, 2015 at 3:05 PM, Mike Hearn  wrote:
>
> Maybe you dislike that idea. It's so  centralised. So let's say Gavin
> commits his patch, because his authority is equal to all other committers.
> Someone else rolls it back. Gavin sets up a cron job to keep committing the
> patch. Game over.
>
> You cannot have committers fighting over what goes in and what doesn't.
> That's madness. There must be a single decision maker for any given
> codebase.
>

You are conflating consensus with commit access. People with commit access
are maintainers who are *able to merge* pull requests. However, the rules
for bitcoin development are that only patches with consensus get merged. If
any of the maintainers just pushed a change without going through the whole
code review and consensus process there would be uproar, plain and simple.

Please don't conflate commit access with permission to merge because it's
just not the case. No-one can sidestep the requirement to get consensus,
not even the 5 maintainers.
--
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

Re: [Bitcoin-development] Block Size Increase

[Jeff Garzik]

Yes - but you must recognize that is precisely 50% of the picture.

Others have made different assumptions - taking the [1MB-constrained]
market *as it exists today*, rather than in some projected future.

Raising the block size limit then becomes a *human decision* to favor some
users over others, a *human decision* to prevent an active and competitive
free fee market developing at 1MB, a *human decision* to keep transaction
fees low to incentivize bitcoin adoption, a *human decision* to value
adoption over decentralization.

These statements are not value judgements - not saying you are wrong -
these are observations of some rather huge, relevant blind spots in this
debate.





On Thu, May 7, 2015 at 11:29 AM, Mike Hearn  wrote:

> It is a trivial *code* change.  It is not a trivial change to the
>> economics of a $3.2B system.
>>
>
> Hmm - again I'd argue the opposite.
>
> Up until now Bitcoin has been unconstrained by the hard block size limit.
>
> If we raise it, Bitcoin will continue to be unconstrained by it. That's
> the default "continue as we are" position.
>
> If it's not raised, then ... well, then we're in new territory
> entirely. Businesses built on the assumption that Bitcoin could become
> popular will suddenly have their basic assumptions invalidated. Users will
> leave. The technical code change would be zero, but the economic change
> would be significant.
>



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
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

Re: [Bitcoin-development] Block Size Increase

[Jorge Timón]

On Thu, May 7, 2015 at 4:05 PM, Mike Hearn  wrote:
>> If his explanation was "I will change my mind after we increase block
>>
>> size", I guess the community should say "then we will just ignore your
>> nack because it makes no sense".
>
>
> Oh good! We can just kick anyone out of the consensus process if we think
> they make no sense.
>
> I guess that means me and Gavin can remove everyone else from the developer
> consensus, because we think trying to stop Bitcoin growing makes no sense.
>
> Do you see the problem with this whole notion? It cannot possibly work.
> Whenever you try and make the idea of developer consensus work, what you end
> up with is "I believe in consensus as long as it goes my way". Which is
> worthless.

That is not what I said. Then you demonstrated that it was absurd.
That's called a straw man argument and it's a well known fallacy, it
is precisely the example of arguments that can be safely ignored.
It is an argument against my admittedly vague definition of
"non-controversial change".
More importantly, I never said anything about "removing anyone", I was
always talking about arguments and not people.
One person could use fallacious arguments to attack or defend a given
proposal and use perfectly valid ones in another, a person can even
mix valid and invalid arguments in the same mail.

>> One thing is the Bitcoin core project where you could argue that the 5
>> committers decide (I don't know why Wladimir would have any more
>> authority than the others).
>
>
> Because he is formally the maintainer.

Yes, the maintainer of the Bitcoin core free software project (I
cannot stressed this enough, that can be forked by anyone), not the
president of Bitcoin the p2p network.

> Maybe you dislike that idea. It's so  centralised. So let's say Gavin
> commits his patch, because his authority is equal to all other committers.
> Someone else rolls it back. Gavin sets up a cron job to keep committing the
> patch. Game over.
>
> You cannot have committers fighting over what goes in and what doesn't.
> That's madness. There must be a single decision maker for any given
> codebase.

I'm sure that if they become that stupid, developers would move to a
fork of the project in no time.

>> Ok, so in simple terms, you expect people to have to pay enormous fees
>> and/or wait thousands of blocks for their transactions to get included
>> in the chain. Is that correct?
>
>
> No. I'll write an article like the others, it's better than email for more
> complicated discourse.

Ok, thanks in advance.

>> As others have said, if the answer is "forever, adoption is always the
>> most important thing" then we will end up with an improved version of Visa.
>
>
> This appears to be another one of those fundamental areas of disagreement. I
> believe there is no chance of Bitcoin ending up like Visa, even if it is
> wildly successful. I did the calculations years ago that show that won't
> happen:
>
> https://en.bitcoin.it/wiki/Scalability
>
> Decentralisation is a spectrum and Bitcoin will move around on that spectrum
> over time. But claiming we have to pick between 1mb blocks and "Bitcoin =
> VISA" is silly.

Again, I didn't say any of that. My point is that a network that
becomes too "centralized" (like visa, that is centralized vs p2p, not
vs distributed) doesn't offer any security or decentralization
advantage over current networks (and of course I meant that could
happen with larger blocks, not 1 MB blocks).
I'm sure that's not what the proponents of the size increase want, and
I'm not defending 1 MB as a sacred limit  or anything, but my question
is "where is the limit for them?"
Even a limitless block size would technically work because miners
would limit it to limit the orphan rate. So "no hardcoded consensus
limit on transaction volume/block size" could be a valid answer to the
question "what is the right consensus limit to block size?" for which
there's no real right answer because there is a tradeoff between
transaction volume and centralization.

Should we maintain 1 MB forever? Probably not.
Is 20 MB a bad size? I honestly don't know.
Is this urgent? I don't think so.
Should we rush things when we don't have clear answers to many related
questions? I don't think so.

You think that it is too soon to start restricting transaction volume
in any way. You will answer why in your post.
When is the right time and what is the right limitation then?

I want to have fee competition as soon as possible, at least
temporarily. But you say that it can wait for later.
Ok, when do you think we should make that happen then?
When 20 MB are full, will that be the right time to let the fee market
develop then or will it be urgent to increase the block size again?
Should we directly remove the limit then and let miners handle it as
they want?
If so, why not now?
Maybe we can increase to 2 MB, then wait for fee competition, then
wait for 2 more subsidy halvings and then increase to 11 or 20 MB?
There's so many 

Re: [Bitcoin-development] Block Size Increase

[Justus Ranvier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/07/2015 03:27 PM, Jeff Garzik wrote:
> On Thu, May 7, 2015 at 11:16 AM, Justus Ranvier
>  wrote:
> 
>> To be extremely specific: should Bitcoin development
>> intenionally limit the network's capabilities to leave room for
>> other projects, or should Bitcoin attempt to be the best system
>> possible and let the other projects try to keep up as best they
>> can?
>> 
> 
> 
> Avoid such narrow, binary thinking.

On 05/07/2015 03:25 PM, Peter Todd wrote:
> Altcoins and non-Bitcoin-blockchain tx systems? Assuming anything 
> other than honest intent isn't productive in this forum.
> 


In summary, I asked a question neither you, nor Peter Todd, want to
answer and want to actively discourage people from even asking at all.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJVS4XZAAoJECpf2nDq2eYjwZcP/j4ypIBctC4Wt71KJCx4eJ3u
u8DQAJKKr8BfL/zDu5bwVz0qbIX1+Wv9EwkBSYuYQaLDozDCnlttptr7qNWm62QI
d5Z6HUU+g/Zbk2DSgVK57Hf3G7pzcodRq+fp6O/kNgtdE9OyZnv9giApd6F1Yy7l
wgZxjlpKGMA+qKigHSHIQyu1L2JfWjw7eEiirnDtFaCgTpJqPErigX+2eMdpj8/r
jTP3mEN2qStWYydWfYxfcM68gOZsvFiVBfT7qTkFXSeOdigC4bHMDMew9nqP1hlB
9uo/JESNQ4Z0/WHgDSn9fLbc/UX6SIPVn7vDAj7mZAeyaXYBrXhbHpdqhnOGhDmt
R9aUopGHleY44RujES1rQWSo6D8SWlbmpXThgHU5rlRFKKSCu9/s99s7kVdLFqpS
bGg42qs1LwxDiq2TuMV/9TuP10ibB4mSnKwaglcAHcrbo26ZdMF4T9YwKcEmHIrv
0hCUA0qyvKP3fqfQUVzcssJfWdvjx7/bnwLadrxSOur1IZj+2jJdzPYsT1tSiwL/
XChSN5a00LJWW5+b0ka155sEg8XcBdUECXIQtRpFedCURjeinGuMnEf6gM8NbcNS
yVm5Kptf8BO11r154J93nkc3gU4VFcxudg8smaDcq3amPDkyaNBXQm+rcwIApchL
SOzHWwxtA1q+pLHvxnlk
=Fcdg
-END PGP SIGNATURE-


0xEAD9E623.asc
Description: application/pgp-keys
--
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

Re: [Bitcoin-development] Block Size Increase

[Mike Hearn]

>
> It is a trivial *code* change.  It is not a trivial change to the
> economics of a $3.2B system.
>

Hmm - again I'd argue the opposite.

Up until now Bitcoin has been unconstrained by the hard block size limit.

If we raise it, Bitcoin will continue to be unconstrained by it. That's the
default "continue as we are" position.

If it's not raised, then ... well, then we're in new territory
entirely. Businesses built on the assumption that Bitcoin could become
popular will suddenly have their basic assumptions invalidated. Users will
leave. The technical code change would be zero, but the economic change
would be significant.
--
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

Re: [Bitcoin-development] Block Size Increase

[Jeff Garzik]

On Thu, May 7, 2015 at 11:16 AM, Justus Ranvier 
wrote:

> To be extremely specific: should Bitcoin development intenionally
> limit the network's capabilities to leave room for other projects, or
> should Bitcoin attempt to be the best system possible and let the
> other projects try to keep up as best they can?
>


Avoid such narrow, binary thinking.

Referencing the problem described in
http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent
(not the solution - block size change - just the problem, tx/block Poisson
mismatch)

This problem - block creation is bursty - is fundamental to bitcoin.
Raising block size does not fix this problem (as [1] notes), but merely
kicks the can down the road a bit, by hiding it from users a bit longer.

Bitcoin is a settlement system, at the most fundamental engineering level.
It will never be an instant payment system for all the world's coffees (or
all the world's stock trades).  It is left to "Layer 2" projects to
engineer around bitcoin's gaps, to produce an instant, secure, trustless,
egalitarian payment system using the bitcoin token.  [1] also notes this.

It is therefore not a binary decision of leaving room for other projects,
or not.  Layer-2 projects are critical to the success of bitcoin, and
complement bitcoin.






[1] http://gavinandresen.ninja/it-must-be-done-but-is-not-a-panacea

Holistic thinking implies you build a full-stack system with bitcoin
--
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