Re: [Bitcoin-development] Block Size Increase

[Pieter Wuille]

On Thu, May 7, 2015 at 12:12 AM, Matt Corallo 
wrote:

> Recently there has been a flurry of posts by Gavin at
> http://gavinandresen.svbtle.com/ which advocate strongly for increasing
> the maximum block size. However, there hasnt been any discussion on this
> mailing list in several years as far as I can tell.
>

Thanks for bringing this up. I'll try to keep my arguments brief, to avoid
a long wall of text. I may be re-iterating some things that have been said
before, though.

I am - in general - in favor of increasing the size blocks: as technology
grows, there is no reason why the systems built on them can't scale
proportionally. I have so far not commented much about this, in a hope to
avoid getting into a public debate, but the way seems to be going now,
worries me greatly.

* Controversial hard forks. I hope the mailing list here today already
proves it is a controversial issue. Independent of personal opinions pro or
against, I don't think we can do a hard fork that is controversial in
nature. Either the result is effectively a fork, and pre-existing coins can
be spent once on both sides (effectively failing Bitcoin's primary
purpose), or the result is one side forced to upgrade to something they
dislike - effectively giving a power to developers they should never have.
Quoting someone: "I did not sign up to be part of a central banker's
committee".

* The reason for increasing is "need". If "we need more space in blocks" is
the reason to do an upgrade, it won't stop after 20 MB. There is nothing
fundamental possible with 20 MB blocks that isn't with 1 MB blocks.
Changetip does not put their microtransactions on the chain, not with 1 MB,
and I doubt they would with 20 MB blocks. The reason for increase should be
"because we choose to accept the trade-offs".

* Misrepresentation of the trade-offs. You can argue all you want that none
of the effects of larger blocks are particularly damaging, so everything is
fine. They will damage something (see below for details), and we should
analyze these effects, and be honest about them, and present them as a
trade-off made we choose to make to scale the system better. If you just
ask people if they want more transactions, of course you'll hear yes. If
you ask people if they want to pay less taxes, I'm sure the vast majority
will agree as well.

* Miner centralization. There is currently, as far as I know, no technology
that can relay and validate 20 MB blocks across the planet, in a manner
fast enough to avoid very significant costs to mining. There is work in
progress on this (including Gavin's IBLT-based relay, or Greg's block
network coding), but I don't think we should be basing the future of the
economics of the system on undemonstrated ideas. Without those (or even
with), the result may be that miners self-limit the size of their blocks to
propagate faster, but if this happens, larger, better-connected, and more
centrally-located groups of miners gain a competitive advantage by being
able to produce larger blocks. I would like to point out that there is
nothing evil about this - a simple feedback to determine an optimal block
size for an individual miner will result in larger blocks for better
connected hash power. If we do not want miners to have this ability, "we"
(as in: those using full nodes) should demand limitations that prevent it.
One such limitation is a block size limit (whatever it is).

* Ability to use a full node. I very much dislike the trend of people
saying "we need to encourage people to run full nodes, in order to make the
network more decentralized". Running 1000 nodes which are otherwise unused
only gives some better ability for full nodes to download the block chain,
or for SPV nodes to learn about transactions (or be Sybil-attacked...).
However, *using* a full node for validating your business (or personal!)
transactions empowers you to using a financial system that requires less
trust in *anyone* (not even in a decentralized group of peers) than
anything else. Moreover, using a full node is what given you power of the
systems' rules, as anyone who wants to change it now needs to convince you
to upgrade. And yes, 20 MB blocks will change people's ability to use full
nodes, even if the costs are small.

* Skewed incentives for improvements. I think I can personally say that I'm
responsible for most of the past years' performance improvements in Bitcoin
Core. And there is a lot of room for improvement left there - things like
silly waiting loops, single-threaded network processing, huge memory sinks,
lock contention, ... which in my opinion don't nearly get the attention
they deserve. This is in addition to more pervasive changes like optimizing
the block transfer protocol, support for orthogonal systems with a
different security/scalability trade-off like Lightning, making full
validation optional, ... Call me cynical, but without actual pressure to
work on these, I doubt much will change. Increasing the size of blocks now
will si

Re: [Bitcoin-development] Block Size Increase

[Justus Ranvier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/07/2015 03:49 AM, 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"

..for some very strange definitions of "good".

That paper may present valid game theory, yet game theory has a
well-known limitation when it comes to predicting real world behavior
in that the predictions are only as good as the simplified model those
predictions are based on is accurate.

At the very least, we should wait to draw any conclusions from that
paper until it has been sanity checked by a praxeological review.
-BEGIN PGP SIGNATURE-

iQIcBAEBAgAGBQJVStYTAAoJECpf2nDq2eYjqzAQAJkLwVq3cJxaP5MirS6j+SkN
NuRIQS8EzJkvojZvHCSRz3xPZpl9Cx2T6/hsLjIfzvMuDHKsaOkkLlL0q95ekv4T
acfami64326DFAxiO0ptspPjCRipagmjSEwZGZwC/QZtTdnt+N9LsH0SFDP6hxbY
Kf11LRd11Ap4v/VnBg/zb4daZnVm0k0nfZxK4rG1zN14r5JEu6eiodUBZc6e4qih
LmopoddIwJS4MY1GoR2kCehAbJseZZyQQmHFEX1Vhc74ETGXWApfgF0tpo6ZMutd
OT0WGhCpj4yG1u5bRaiNnsOy9WcBTKzDOLZUVVh/GhUGHWUulZu8ujYrX7Q6GR5S
VPvOOL6Ts/RGEAE1UWKzHfPjrLZAHKgLAzBjm6o1ZXdBcnV+FsThNvd7fxHvaJsO
pWGSu8qDmN/wH657Tphbthb4T/awnuf4rO6oBP+OGu+ydPIlIlt6rM2E4Bq366yy
CJbzSR3x/P7fRmT2bbSg4rxTDyLFJpNIWOcNaMRBeO69OdNZxlranvFvEl/6FfqK
GO/LPQiYCe/+yhXgUJzzlYpayPiPFWCg0FxwQ+xl1josTsrfPE4BUivkZvIlqOIY
LX1fDHt/IIUNp8OUkY2eERxeB//dlY55nP7VGUEJLNnBkXuoBd70lMtGXxtgvw2M
Wy5VER9CiEOUMMwzWi3Q
=8mit
-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

[Peter Todd]

On Wed, May 06, 2015 at 11:41:37PM +, Matt Corallo wrote:
> Yes, but this does NOT make an actual policy. Note that the vast
> majority of miners already apply their own patches to Bitcoin Core, so
> applying one more is not all that hard. When blocks start to become
> limited (ie there is any fee left on the table by transactions not
> included in a block) there becomes incentive for miners to change that
> behavior pretty quick. Not just that, the vast majority of the hashpower
> is behind very large miners, who have little to no decentralization
> pressure. This results in very incompatible incentives, mainly that the
> incentive would be for the large miners to interconnect in a private
> network and generate only maximum-size blocks, creating a strong
> centralization pressure in the network.

I'll also point out that miners with the goal of finding more blocks
than their competition - a viable long-term strategy to increase market
share and/or a short-term strategy to get more transaction fees -
actually have a perverse incentive(1) to ensure their blocks do *not*
get to more than ~30% of the hashing power. The main thing holding them
back from doing that is that the inflation subsidy is still quite high -
better to get the reward now than try to push your competition out of
business.

It's plausible that with a limited blocksize there won't be an
opportunity to delay propagation by broadcasting larger blocks - if
blocks propagate in a matter of seconds worst case there's no
opportunity for gaming the system. But it does strongly show that we
must build systems where that worst case propagation time in all
circumstances is very short relative to the block interval.

1) 
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03200.html

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


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 Wed, May 06, 2015 at 10:12:14PM +, Matt Corallo wrote:
> Personally, I'm rather strongly against any commitment to a block size
> increase in the near future. Long-term incentive compatibility requires
> that there be some fee pressure, and that blocks be relatively
> consistently full or very nearly full. What we see today are
> transactions enjoying next-block confirmations with nearly zero pressure
> to include any fee at all (though many do because it makes wallet code
> simpler).

Agreed.

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"

Abstract


We study the economics of Bitcoin transaction fees in a simple static
partial equilibrium model with the specificity that the system security
is directly linked to the total computational power of miners. We show
that any situation with a fixed fee is equivalent to another situation
with a limited block size. In both cases, we give the optimal value of
the transaction fee or of the block size. We also show that making the
block size a non binding constraint and, in the same time, letting the
fee be fixed as the outcome of a decentralized competitive market cannot
guarantee the very existence of Bitcoin in the long-term.

-http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2400519

In short, without either a fixed blocksize or fixed fee per transaction
Bitcoin will will not survive as there is no viable way to pay for PoW
security. The latter option - fixed fee per transaction - is non-trivial
to implement in a way that's actually meaningful - it's easy to give
miners "kickbacks" - leaving us with a fixed blocksize.

> This allows the well-funded Bitcoin ecosystem to continue building
> systems which rely on transactions moving quickly into blocks while
> pretending these systems scale. Thus, instead of working on technologies

I think this lack of understanding of the limitations of blockchain tech
is very dangerous, never mind, downright misleading. I keep running into
startups at conferences with completely unrealistic ideas about how
large they'll be able to grow their on-blockchain businesses. For
example, a few weeks ago at the Stanford blockchain conference I spoke
to a company planning on using multisig escrow contracts to settle
financial instruments, and expected to be doing about as many
transactions/day on the blockchain for their business within a year or
so as all other Bitcoin users currently do combined. These guys quite
frankly had no understanding of the issues, and had apparently based
their plans on the highly optimistic Bitcoin wiki page on
scalability.(1) (I'd fix this now, but the wiki seems to not be allowing
logins)

We'd do a lot of startups a lot of good to give them accurate, and
honest, advice about the scalability of the system. The wiki definitely
isn't that. Neither is the bitcoin.org developer documentation(2), which
doesn't mention scalability at all.

> which bring Bitcoin's trustlessness to systems which scale beyond a
> blockchain's necessarily slow and (compared to updating numbers in a
> database) expensive settlement, the ecosystem as a whole continues to
> focus on building centralized platforms and advocate for changes to
> Bitcoin which allow them to maintain the status quo[1].

Even a relatively small increase to 20MB will greatly reduce the number
of people who can participate fully in Bitcoin, creating an environment
where the next increase requires the consent of an even smaller portion
of the Bitcoin ecosystem. Where does that stop? What's the proposed
mechanism that'll create an incentive and social consensus to not just
'kick the can down the road'(3) and further centralize but actually
scale up Bitcoin the hard way? The only proposal that I've seen that
attempts to do this is John Dillon's proof-of-stake blocksize vote(4),
and that is far from getting consensus.

1) https://en.bitcoin.it/wiki/Scalability
2) https://bitcoin.org/en/developer-guide
3) http://gavinandresen.ninja/it-must-be-done-but-is-not-a-panacea
4) 
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html

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


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

[Gregory Maxwell]

On Wed, May 6, 2015 at 10:12 PM, Matt Corallo 
wrote: > Recently there has been a flurry of posts by Gavin at >
http://gavinandresen.svbtle.com/ which advocate strongly for increasing >
the maximum block size. However, there hasnt been any discussion on this >
mailing list in several years as far as I can tell.

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.

So please forgive me for the more than typical disorganization in this
message; I've been caught a bit flatfooted on this and I'm trying to
catch up. I'm juggling a fair amount of sudden pressure in my mailbox,
and trying to navigate complex discussions in about eight different
forums concurrently.

There have been about a kazillion pages of discussion elsewhere
(e.g. public IRC and Bitcointalk; private discussions in the past),
not all of which is well known, and I can't hope to summarize even a
tiny fraction of it in a single message-- but that's no reason to not
start on it.

> Block size is a question to which there is no answer, but which >
certainly has a LOT of technical tradeoffs to consider.

There are several orthogonal angles from which block size is a concern
(both increases and non-increases). Most of them have subtle implications
and each are worth its own research paper or six, so it can be difficult
to only touch them slightly without creating a gish gallop that is hard
to respond to.

We're talking about tuning one of the fundamental scarcities of the
Bitcoin Economy and cryptosystem--leaving the comfort of "rule by
math" and venturing into the space of political decisions; elsewhere
you'd expect to see really in-depth neutral analysis of the risks and
tradeoffs, technically and economically.  And make no mistake: there
are real tradeoffs here, though we don't know their exact contours.

Fundamentally this question exposes ideological differences between people
interested in Bitcoin.  Is Bitcoin more of a digital gold or is it more
of a competitor to Square?  Is Bitcoin something that should improve
personal and commercial autonomy from central banks?  From commercial
banks? Or from just the existing status-quo commercial banks?   What are
people's fundamental rights with Bitcoin?  Do participants have a
right to mine? How much control should third parties have over their
transactions?  How much security must be provided? Is there a deadline
for world domination or bust?  Is Bitcoin only for the developed world?
Must it be totally limited by the most impoverished parts of the world?

Bitcoin exists at the intersection of many somewhat overlapping belief
systems--and people of many views can find that Bitcoin meets their
needs even when they don't completely agree politically.  When Bitcoin
is changed fundamentally, via a hard fork, to have different properties,
the change can create winners or losers (if nothing else, then in terms
of the kind of ideology supported by it).

There are non-trivial number of people who hold extremes on any of
these general belief patterns; Even among the core developers there is
not a consensus on Bitcoin's optimal role in society and the commercial
marketplace.

To make it clear how broad the views go, even without getting into
monetary policy... some people even argue that Bitcoin should act
as censor-resistant storage system for outlawed content; -- I think
this view is unsound, not achievable with the technology, and largely
incompatible with Bitcoin's use as a money (because it potentially
creates an externalized legal/harassment liability for node operators);
but these are my personal value judgments; the view is earnestly held
by more than a few; and that's a group that certainly wants the largest
possible blocksizes (though even then that won't be enough).

The subject is complicated even more purely on the technical side
by the fact that Bitcoin has a layered security model which is not
completely defined or understood: Bitcoin is secure if a majority of
hashrate is "honest" (where "honesty" is a technical term which means
"follows the right rules" without fail, even at a loss), but why might
it be honest? That sends us into complex economic and social arguments,
and the security thresholds start becoming worse when we assume some
miners are economically rational instead of "honest".

> increase in the near future. Long-term incentive compatibility requires
> that there be some fee pressure, and that blocks be relatively >
consistently full or very nearly full. What we see today are

To elaborate, in my view there is a at least a two fold concern on this
particular ("Long term Mining incentives") front:

One is that the long-held argument is that security of the Bitcoin system
in the long term depends on fee income funding autonomous, anonymous,
decentralized miners profitably applying enough hash-power t

Re: [Bitcoin-development] Block Size Increase

[Bryan Bishop]

On Wed, May 6, 2015 at 5:12 PM, Matt Corallo  wrote:
> the maximum block size. However, there hasnt been any discussion on this
> mailing list in several years as far as I can tell.

Well, there has been significant public discussion in #bitcoin-wizards
on irc.freenode.net which is available in public logs, specifically
about why increasing the max block size is kicking the can down the
road while possibly compromising blockchain security. There were many
excellent objections that were raised that, sadly, I see are not
referenced at all in the recent media blitz. Frankly I can't help but
feel that if contributions, like those from #bitcoin-wizards, have
been ignored in lieu of technical analysis, and the absence of
discussion on this mailing list, that I feel perhaps there are other
subtle and extremely important technical details that are completely
absent from this--and other-- proposals. I have some rather general
thoughts to offer.

Secured decentralization is the most important and most interesting
property of bitcoin. Everything else is rather trivial and could be
achieved millions of times more efficiently with conventional
technology. Our technical work should be informed by the technical
nature of the system we have constructed.

I suspect that as bitcoin continues to grow in all dimensions and
metrics, that we will see an unending wave of those who are excited by
the idea of Something Different in the face of archaic, crumbling
software and procedures in the rest of the financial world. Money has
found its way into every aspect of human life. There's no doubt in my
mind that bitcoin will always see the most extreme campaigns and the
most extreme misunderstandings. Like moths to a flame or water in the
desert, almost everyone is excited by ANY status quo change
whatsoever. This is something that we have to be vigilante about,
because their excitement is motivation to do excellent work, not
simply any work. For some who are excited about general status quo
changes that bitcoin represents, they may not mind if bitcoin
decentralization disappears and is replaced with just a handful of
centralized nodes. Whereas for development purposes we must hold
ourselves to extremely high standards before proposing changes,
especially to the public, that have the potential to be unsafe and
economically unsafe. We have examples from NASA about how to engineer
extremely fault tolerant systems, and we have examples from Linux
about how to have high standards in open-source projects. Safety is
absolutely critical, even in the face of seemingly irrational
excuberance of others who want to scale to trillions of daily coffee
transactions individually stored forever in the blockchain.

When designing bitcoin or even some other system, an important design
target is what the system should be capable of. How many transactions
should the system perform? What is the correct number of transactions
for a healthy, modern civilization to perform every day? And how fast
should that (not) grow? Should we allow for 2 billion trillion coffee
transactions every day, or what about 100 trillion transactions per
second? I suspect that these sorts of questions are entirely
unanswerable and boring. So in the absence of technical targets to
reach during the design phase, I suspect that Jeff Garzik was right
when he pointed out a few months ago that bitcoin is good at
settlement and clearing. There are many potential technical solutions
for aggregating millions (trillions?) of transactions into tiny
bundles. As a small proof-of-concept, imagine two parties sending
transactions back and forth 100 million times. Instead of recording
every transaction, you could record the start state and the end state,
and end up with two transactions or less. That's a 100 million fold,
without modifying max block size and without potentially compromising
secured decentralization.

The MIT group should listen up and get to work figuring out how to
measure decentralization and its security :-). Maybe we should be
collectively pestering Andrew Miller to do this, too. No pressure,
dude. Getting this measurement right would be really beneficial
because we would have a more academic and technical understanding to
work with. I would also characterize this as high priority next to the
"formally verified correctness proofs for Script and
libbitcoinconsensus".

Also, I think that getting this out in the open on this mailing list
is an excellent step forward.

- Bryan
http://heybryan.org/
1 512 203 0507

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

Re: [Bitcoin-development] Block Size Increase

[Tom Harding]

On 5/6/2015 3:12 PM, Matt Corallo wrote:

Long-term incentive compatibility requires
that there be some fee pressure, and that blocks be relatively
consistently full or very nearly full.


I think it's way too early to even consider a future era when the fiat 
value of the block reward is no longer the biggest-by-far mining incentive.


Creating fee pressure means driving some people to choose something 
else, not bitcoin. "Too many people using bitcoin" is nowhere on the 
list of problems today.  It's reckless to tinker with adoption in hopes 
of spurring innovation on speculation, while a "can kick" is available.


Adoption is currently at miniscule, test-flight, relatively 
insignificant levels when compared to global commerce.  As Gavin 
discussed in the article, under "Block size and miner fees… again," the 
best way to maximize miner incentives is to focus on doing things that 
are likely to increase adoption, which, in our fiat-dominated world, 
lead to a justifiably increased exchange rate.


Any innovation attractive enough to relieve the block size pressure will 
do so just as well without artificial stimulus.


Thanks for kicking off the discussion.

--
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/06/15 23:33, Tier Nolan wrote:
> On Thu, May 7, 2015 at 12:12 AM, Matt Corallo  > wrote:
> 
> The point of the hard block size limit is exactly because giving miners
> free rule to do anything they like with their blocks would allow them to
> do any number of crazy attacks. The incentives for miners to pick block
> sizes are no where near compatible with what allows the network to
> continue to run in a decentralized manner.
> 
> 
> Miners can always reduce the block size (if they coordinate). 
> Increasing the maximum block size doesn't necessarily cause an
> increase.  A majority of miners can soft-fork to set the limit lower
> than the hard limit.

Sure, of course.

> Setting the hard-fork limit higher means that a soft fork can be used to
> adjust the limit in the future. 
> 
> The reference client would accept blocks above the soft limit for wallet
> purposes, but not build on them.  Blocks above the hard limit would be
> rejected completely.

Yes, but this does NOT make an actual policy. Note that the vast
majority of miners already apply their own patches to Bitcoin Core, so
applying one more is not all that hard. When blocks start to become
limited (ie there is any fee left on the table by transactions not
included in a block) there becomes incentive for miners to change that
behavior pretty quick. Not just that, the vast majority of the hashpower
is behind very large miners, who have little to no decentralization
pressure. This results in very incompatible incentives, mainly that the
incentive would be for the large miners to interconnect in a private
network and generate only maximum-size blocks, creating a strong
centralization pressure in the network.

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

[Tier Nolan]

On Thu, May 7, 2015 at 12:12 AM, Matt Corallo 
wrote:

> The point of the hard block size limit is exactly because giving miners
> free rule to do anything they like with their blocks would allow them to
> do any number of crazy attacks. The incentives for miners to pick block
> sizes are no where near compatible with what allows the network to
> continue to run in a decentralized manner.
>

Miners can always reduce the block size (if they coordinate).  Increasing
the maximum block size doesn't necessarily cause an increase.  A majority
of miners can soft-fork to set the limit lower than the hard limit.

Setting the hard-fork limit higher means that a soft fork can be used to
adjust the limit in the future.

The reference client would accept blocks above the soft limit for wallet
purposes, but not build on them.  Blocks above the hard limit would be
rejected completely.
--
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 Whitlock]

I'm not so much opposed to a block size increase as I am opposed to a hard 
fork. My problem with a hard fork is that everyone and their brother wants to 
seize the opportunity of a hard fork to insert their own pet feature, and such 
a mad rush of lightly considered, obscure feature additions would be extremely 
risky for Bitcoin. If it could be guaranteed that raising the block size limit 
would be the only incompatible change introduced in the hard fork, then I would 
support it, but I strongly fear that the hard fork itself will become an excuse 
to change other aspects of the system in ways that will have unintended and 
possibly disastrous consequences.

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

For now, lets leave the discussion to JUST the block size increase. If
it helps - everyone should assume that their pet feature is included in
a hard fork or, if you prefer, that no other features are included in a
hard fork.

On 05/06/15 23:11, Matt Whitlock wrote:
> I'm not so much opposed to a block size increase as I am opposed to a hard 
> fork. My problem with a hard fork is that everyone and their brother wants to 
> seize the opportunity of a hard fork to insert their own pet feature, and 
> such a mad rush of lightly considered, obscure feature additions would be 
> extremely risky for Bitcoin. If it could be guaranteed that raising the block 
> size limit would be the only incompatible change introduced in the hard fork, 
> then I would support it, but I strongly fear that the hard fork itself will 
> become an excuse to change other aspects of the system in ways that will have 
> unintended and possibly disastrous consequences.
> 

--
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/06/15 22:44, Tier Nolan wrote:
> On Wed, May 6, 2015 at 11:12 PM, Matt Corallo  > wrote:
> Personally, I'm rather strongly against any commitment to a block size
> increase in the near future.
-snip-
> The question being discussed is what is the maximum block size merchants
> and users will accept.  This puts a reasonable limit on the maximum size
> miners can increase the block size to.
> 
> In effect, the block size is set by the minimum of the miner's and the
> merchants/user's size.min(miner, merchants/users).

Indeed, "the bitcoin community of users and miners can decide to do
whatever they want", but this is univeral - "they" could decide whatever
they want if "they" want to hardfork. That said, "we" should be having a
rigorous technical discussion about whether it is sane to recommend a
given course of action by releasing software which makes it happen.

> 
> This allows the well-funded Bitcoin ecosystem to continue building
> systems which rely on transactions moving quickly into blocks while
> pretending these systems scale. Thus, instead of working on technologies
> which bring Bitcoin's trustlessness to systems which scale beyond a
> blockchain's necessarily slow and (compared to updating numbers in a
> database) expensive settlement, the ecosystem as a whole continues to
> focus on building centralized platforms and advocate for changes to
> Bitcoin which allow them to maintain the status quo[1].
> 
> 
> Would you accept a rule that the maximum size is 20MB (doubling every 2
> years), but that miners have an efficient method for choosing a lower size?
> 
> If miners could specify the maximum block size in their block headers,
> then they could coordinate to adjust the block size.  If 75% vote to
> lower the size, then it is lowered and vice versa for raiding.
> 
> Every 2016 blocks, the votes are counter.  If the 504th lowest of the
> 2016 blocks is higher than the previous size, then the size is set to
> that size.  Similarly, if the 504th highest is lower than the previous
> size, it becomes the new size.
> 
> There could be 2 default trajectories.  The reference client might
> always vote to double the size every 4 years.
> 
> To handle large blocks (>32MB) requires a change to the p2p protocol
> message size limits, or a way to split blocks over multiple messages.
> 
> It would be nice to add new features to any hard-fork.
> 
> I favour adding an auxiliary header.  The Merkle root in the header
> could be replaced with hash(merkle_root | hash(aux_header)).  This is a
> fairly simple change, but helps with things like commitments.  One of
> the fields in the auxiliary header could be an extra nonce field.  This
> would mean fast regeneration of the merkle root for ASIC miners.  This
> is a pretty simple change.

The point of the hard block size limit is exactly because giving miners
free rule to do anything they like with their blocks would allow them to
do any number of crazy attacks. The incentives for miners to pick block
sizes are no where near compatible with what allows the network to
continue to run in a decentralized manner.

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

[Eric Lombrozo]

I don’t really have a strong opinion on block size either…but if we’re going to 
do a hard fork, let’s use this as an opportunity to create a good process for 
hard forks (which we’ll inevitably need to do again in the future). The change 
in block size is a very simple change that still allows us to explore all the 
complexities involved with deployment of hard forks. Let’s not just do a 
one-off ad-hoc thing.

- Eric Lombrozo

> On May 6, 2015, at 3:30 PM, slush  wrote:
> 
> I don't have strong opinion @ block size topic.
> 
> But if there'll be a fork, PLEASE, include SIGHASH_WITHINPUTVALUE 
> (https://bitcointalk.org/index.php?topic=181734.0 
> ) or its alternative. All 
> developers of lightweight (blockchain-less) clients will adore you!
> 
> slush
> 
> On Thu, May 7, 2015 at 12:12 AM, Matt Corallo  > wrote:
> Recently there has been a flurry of posts by Gavin at
> http://gavinandresen.svbtle.com/  which 
> advocate strongly for increasing
> the maximum block size. However, there hasnt been any discussion on this
> mailing list in several years as far as I can tell.
> 
> Block size is a question to which there is no answer, but which
> certainly has a LOT of technical tradeoffs to consider. I know a lot of
> people here have varying levels of strong or very strong opinions about
> this, and the fact that it is not being discussed in a technical
> community publicly anywhere is rather disappointing.
> 
> So, at the risk of starting a flamewar, I'll provide a little bait to
> get some responses and hope the discussion opens up into an honest
> comparison of the tradeoffs here. Certainly a consensus in this kind of
> technical community should be a basic requirement for any serious
> commitment to blocksize increase.
> 
> Personally, I'm rather strongly against any commitment to a block size
> increase in the near future. Long-term incentive compatibility requires
> that there be some fee pressure, and that blocks be relatively
> consistently full or very nearly full. What we see today are
> transactions enjoying next-block confirmations with nearly zero pressure
> to include any fee at all (though many do because it makes wallet code
> simpler).
> 
> This allows the well-funded Bitcoin ecosystem to continue building
> systems which rely on transactions moving quickly into blocks while
> pretending these systems scale. Thus, instead of working on technologies
> which bring Bitcoin's trustlessness to systems which scale beyond a
> blockchain's necessarily slow and (compared to updating numbers in a
> database) expensive settlement, the ecosystem as a whole continues to
> focus on building centralized platforms and advocate for changes to
> Bitcoin which allow them to maintain the status quo[1].
> 
> Matt
> 
> [1] https://twitter.com/coinbase/status/595741967759335426 
> 
> 
> --
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
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-developmen

Re: [Bitcoin-development] Block Size Increase

[slush]

I don't have strong opinion @ block size topic.

But if there'll be a fork, PLEASE, include SIGHASH_WITHINPUTVALUE (
https://bitcointalk.org/index.php?topic=181734.0) or its alternative. All
developers of lightweight (blockchain-less) clients will adore you!

slush

On Thu, May 7, 2015 at 12:12 AM, Matt Corallo 
wrote:

> Recently there has been a flurry of posts by Gavin at
> http://gavinandresen.svbtle.com/ which advocate strongly for increasing
> the maximum block size. However, there hasnt been any discussion on this
> mailing list in several years as far as I can tell.
>
> Block size is a question to which there is no answer, but which
> certainly has a LOT of technical tradeoffs to consider. I know a lot of
> people here have varying levels of strong or very strong opinions about
> this, and the fact that it is not being discussed in a technical
> community publicly anywhere is rather disappointing.
>
> So, at the risk of starting a flamewar, I'll provide a little bait to
> get some responses and hope the discussion opens up into an honest
> comparison of the tradeoffs here. Certainly a consensus in this kind of
> technical community should be a basic requirement for any serious
> commitment to blocksize increase.
>
> Personally, I'm rather strongly against any commitment to a block size
> increase in the near future. Long-term incentive compatibility requires
> that there be some fee pressure, and that blocks be relatively
> consistently full or very nearly full. What we see today are
> transactions enjoying next-block confirmations with nearly zero pressure
> to include any fee at all (though many do because it makes wallet code
> simpler).
>
> This allows the well-funded Bitcoin ecosystem to continue building
> systems which rely on transactions moving quickly into blocks while
> pretending these systems scale. Thus, instead of working on technologies
> which bring Bitcoin's trustlessness to systems which scale beyond a
> blockchain's necessarily slow and (compared to updating numbers in a
> database) expensive settlement, the ecosystem as a whole continues to
> focus on building centralized platforms and advocate for changes to
> Bitcoin which allow them to maintain the status quo[1].
>
> Matt
>
> [1] https://twitter.com/coinbase/status/595741967759335426
>
>
> --
> 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

[Tier Nolan]

On Wed, May 6, 2015 at 11:12 PM, Matt Corallo 
wrote:

> Personally, I'm rather strongly against any commitment to a block size
> increase in the near future.


Miners can already soft-fork to reduce the maximum block size.  If 51% of
miners agree to a 250kB block size, then that is the maximum block size.

The question being discussed is what is the maximum block size merchants
and users will accept.  This puts a reasonable limit on the maximum size
miners can increase the block size to.

In effect, the block size is set by the minimum of the miner's and the
merchants/user's size.min(miner, merchants/users).


> This allows the well-funded Bitcoin ecosystem to continue building
> systems which rely on transactions moving quickly into blocks while
> pretending these systems scale. Thus, instead of working on technologies
> which bring Bitcoin's trustlessness to systems which scale beyond a
> blockchain's necessarily slow and (compared to updating numbers in a
> database) expensive settlement, the ecosystem as a whole continues to
> focus on building centralized platforms and advocate for changes to
> Bitcoin which allow them to maintain the status quo[1].
>

Would you accept a rule that the maximum size is 20MB (doubling every 2
years), but that miners have an efficient method for choosing a lower size?

If miners could specify the maximum block size in their block headers, then
they could coordinate to adjust the block size.  If 75% vote to lower the
size, then it is lowered and vice versa for raiding.

Every 2016 blocks, the votes are counter.  If the 504th lowest of the 2016
blocks is higher than the previous size, then the size is set to that
size.  Similarly, if the 504th highest is lower than the previous size, it
becomes the new size.

There could be 2 default trajectories.  The reference client might always
vote to double the size every 4 years.

To handle large blocks (>32MB) requires a change to the p2p protocol
message size limits, or a way to split blocks over multiple messages.

It would be nice to add new features to any hard-fork.

I favour adding an auxiliary header.  The Merkle root in the header could
be replaced with hash(merkle_root | hash(aux_header)).  This is a fairly
simple change, but helps with things like commitments.  One of the fields
in the auxiliary header could be an extra nonce field.  This would mean
fast regeneration of the merkle root for ASIC miners.  This is a pretty
simple change.
--
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

[Bitcoin-development] Block Size Increase

[Matt Corallo]

Recently there has been a flurry of posts by Gavin at
http://gavinandresen.svbtle.com/ which advocate strongly for increasing
the maximum block size. However, there hasnt been any discussion on this
mailing list in several years as far as I can tell.

Block size is a question to which there is no answer, but which
certainly has a LOT of technical tradeoffs to consider. I know a lot of
people here have varying levels of strong or very strong opinions about
this, and the fact that it is not being discussed in a technical
community publicly anywhere is rather disappointing.

So, at the risk of starting a flamewar, I'll provide a little bait to
get some responses and hope the discussion opens up into an honest
comparison of the tradeoffs here. Certainly a consensus in this kind of
technical community should be a basic requirement for any serious
commitment to blocksize increase.

Personally, I'm rather strongly against any commitment to a block size
increase in the near future. Long-term incentive compatibility requires
that there be some fee pressure, and that blocks be relatively
consistently full or very nearly full. What we see today are
transactions enjoying next-block confirmations with nearly zero pressure
to include any fee at all (though many do because it makes wallet code
simpler).

This allows the well-funded Bitcoin ecosystem to continue building
systems which rely on transactions moving quickly into blocks while
pretending these systems scale. Thus, instead of working on technologies
which bring Bitcoin's trustlessness to systems which scale beyond a
blockchain's necessarily slow and (compared to updating numbers in a
database) expensive settlement, the ecosystem as a whole continues to
focus on building centralized platforms and advocate for changes to
Bitcoin which allow them to maintain the status quo[1].

Matt

[1] https://twitter.com/coinbase/status/595741967759335426

--
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] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)

[Tier Nolan]

On Wed, May 6, 2015 at 8:37 AM, Jorge Timón  wrote:

>
> This gives you less flexibility and I don't think it's necessary.
> Please let's try to avoid this if it's possible.


It is just a switch that turns on and off the new mode.

In retrospect, it would be better to just up the transaction version.

In transactions from v2 onwards, the sequence field means height.  That
means legacy transactions would be spendable.

This is a pure soft-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] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)

[Jorge Timón]

On Tue, May 5, 2015 at 10:38 PM, Tier Nolan  wrote:
> I think that should be greater than in the comparison?  You want it to fail
> if the the height of the UTXO plus the sequence number is greater than the
> spending block's height.

Yes, sorry, I changed it just before sending from "what needs to be
satisfied for the validation error to trigger" to "what needs to be
satisfied for the tx to be valid".
You're right.

> There should be an exception for final inputs.  Otherwise, they will count
> as relative locktime of 0x.  Is this check handled elsewhere?
>
> if (!tx.vin[i].IsFinal() && nSpendHeight < coins->nHeight +
> tx.vin[i].nSequence)
>return state.Invalid(false, REJECT_INVALID,
> "bad-txns-non-final-input");

Yes, this would be the simplest solution. Another option would be to
have a new tx version in which IsFinal(CTransaction) doesn't check the
inputs sequences to be 0x for the tx to be final.

> Is the intention to let the script check the sequence number?
>
>  OP_RELATIVELOCKTIMEVERIFY
>
> would check if  is less than or equal to the sequence number.

Yes.

> It does make sequence mean something completely different from before.
> Invalidating previously valid transactions has the potential to reduce
> confidence in the currency.

Well, the semantics of nSequence don't really change completely. In
fact, one could argue that this put it closer to its original
semantics.
But in any case, yes, already signed transaction should remain valid.
No transaction would become invalid, just non-final.
As soon as the height of its inputs plus their respective nSquences
get higher than current height they will become final again.
I cannot think of any use case where a tx becomes invalid forever.
Also, probably most people have usedrelatively low values for
nSequence given the original semantics, just like the relative lock
nSquence will likely be used as well.

> A workaround would be to have a way to enable it in the sigScript by
> extending Peter Todd's suggestion in the other email chain.
>
> <1> OP_NOP2 means OP_CHECKLOCKTIMEVERIFY (absolute)
> <2> OP_NOP2 means OP_RELATIVECHECKLOCKTIMEVERIFY
>
> <3> OP_NOP2 means OP_SEQUENCE_AS_RELATIVE_HEIGHT

To be clear, this proposal is supposed to replace RCLTV, so there
would still be 2 options. But please let's imagine we have infinite
opcodes in this thread and let the "should we design an uglier
scripting langues to save opcodes?" question in the other one.

> OP_SEQUENCE_AS_RELATIVE_HEIGHT would cause the script to fail unless it was
> the first opcode in the script.  It acts as a flag to enable using the
> sequence number as for relative block height.
>
> This can be achieved using a simple pattern match.
>
> bool CScript::IsSequenceAsRelativeHeight() const
> {
> // Extra-fast test for pay-to-script-hash CScripts:
> return (this->size() >= 4 &&
> this->at(0) == OP_PUSHDATA1 &&
> this->at(1) == 1 &&
> this->at(2) == 0xFF &&
> this->at(3) == OP_NOP2);
> }
>
> if (!tx.vin[i].IsFinal() && tx.vin[i].scriptSig.IsSequenceAsRelativeHeight()
> && nSpendHeight < coins->nHeight + tx.vin[i].nSequence)
>return state.Invalid(false, REJECT_INVALID,
> "bad-txns-non-final-input");

This gives you less flexibility and I don't think it's necessary.
Please let's try to avoid this if it's possible.


> On Mon, May 4, 2015 at 12:24 PM, Jorge Timón  wrote:
>>
>> for (unsigned int i = 0; i < tx.vin.size(); i++) {
>> // ...
>> if (coins->nHeight + tx.vin[i].nSequence < nSpendHeight)
>> return state.Invalid(false, REJECT_INVALID,
>> "bad-txns-non-final-input");
>> // ...
>> }
>
>
>
>
> --
> 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