Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Mike Hearn
Hey Matt,

OK, let's get started 

However, there hasnt been any discussion on this
 mailing list in several years as far as I can tell.


Probably because this list is not a good place for making progress or
reaching decisions. Those are triggered by pull requests (sometimes).

If you're wondering why now, that's probably my fault. A few days ago
Wladimir posted a release timeline. I observed to Wladimir and Gavin in
private that this timeline meant a change to the block size was unlikely to
get into 0.11, leaving only 0.12, which would give everyone only a few
months to upgrade in order to fork the chain by the end of the winter
growth season. That seemed tight.

Wladimir did not reply to this email, unfortunately. Perhaps he would like
the issue to go away. It won't - if Bitcoin continues on its current growth
trends it *will* run out of capacity, almost certainly by some time next
year.

What we need to see right now is leadership and a plan, that fits in the
available time window.


 Certainly a consensus in this kind of technical community should be a
 basic requirement for any serious commitment to blocksize increase.


I'm afraid I have come to disagree. I no longer believe this community can
reach consensus on anything protocol related. Some of these arguments have
dragged on for years. Consensus isn't even well defined - consensus of who?
Anyone who shows up? And what happens when, inevitably, no consensus is
reached? Stasis forever?


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


I disagree. When the money supply eventually dwindles I doubt it will be
fee pressure that funds mining, but as that's a long time in the future,
it's very hard to predict what might happen.


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


Many do because free transactions are broken - the relay limiter means
whether a free transaction actually makes it across the network or not is
basically pot luck and there's no way for a wallet to know, short of either
trying it or actually receiving every single transaction and repeating the
calculations. If free transactions weren't broken for all non-full nodes
they'd probably be used a lot more.


 This allows the well-funded Bitcoin ecosystem to continue building
 systems which rely on transactions moving quickly into blocks while
 pretending these systems scale.


I have two huge problems with this line of thinking.

Firstly, no, the Bitcoin ecosystem is not well funded. Blockstream might
be, but significant numbers of users are running programs developed by tiny
startups, or volunteers who don't have millions in venture capital to play
with.

Arm-twisting the ecosystem into developing complicated Rube Goldberg
machines in double quick time, just to keep the Bitcoin show on the road,
is in fact the opposite of decentralisation - it will effectively exclude
anyone who isn't able to raise large amounts of corporate funding from
writing code that uses the Bitcoin network. Decentralisation benefits from
simplicity, and bigger blocks are (in Gavin's words) the simplest thing
that will work.

My second problem is the claim that everyone is playing pretend about
Bitcoin, except you guys. I would put it another way - I would say those
people are building products and getting users, by making reasonable
engineering tradeoffs and using systems that work. Yes, one day those
systems might have to change. That's the nature of scaling. It's the nature
of progress. But not today. Probably not tomorrow either.

What I would like to see from Blockstream is a counter-proposal. So far you
have made lots of vague comments that we all agree with - yes,
decentralisation is good, yes some block size limit must exist, if only
because computers are finite machines.

What I don't see from you yet is a *specific and credible plan* that fits
within the next 12 months and which allows Bitcoin to keep growing. Not
some vague handwave like let's all use the Lightning network (which does
not exist), or let's do more research (Gavin has done plenty of
research), or but what about the risks (Bitcoin is full of risks). A
plan, with dates attached, and a strong chance of actually being deployed
in time.
--
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

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread 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

2015-05-07 Thread 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

2015-05-07 Thread Jeff Garzik
On Thu, May 7, 2015 at 3:31 PM, Alan Reiner etothe...@gmail.com 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


[Bitcoin-development] Fwd: Block Size Increase

2015-05-07 Thread Gavin Andresen
On Thu, May 7, 2015 at 1:26 PM, Matt Corallo bitcoin-l...@bluematt.me
wrote:

 I think this is a huge issue. You've been wandering around telling
 people that the blocksize will increase soon for months


I think the strongest thing I've ever said is:

There is consensus that the max block size much change sooner or later.
There is not yet consensus on exactly how or when. I will be pushing to
change it this year.

This is what I will be pushing to change it this year looks like.

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

2015-05-07 Thread 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

2015-05-07 Thread 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

2015-05-07 Thread Jeff Garzik
On Thu, May 7, 2015 at 3:03 PM, Matt Corallo bitcoin-l...@bluematt.me
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

2015-05-07 Thread 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

2015-05-07 Thread 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 m...@plan99.net:

 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

2015-05-07 Thread 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 btcd...@gmail.com wrote:

 On Thu, May 7, 2015 at 7:40 PM, Gavin Costin slashdevn...@hotmail.com
 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

2015-05-07 Thread 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 m...@plan99.net
Date:  Friday, 8 May, 2015 2:06 am
To:  Btc Drak btcd...@gmail.com
Cc:  Bitcoin Dev bitcoin-development@lists.sourceforge.net
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

2015-05-07 Thread 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

2015-05-07 Thread 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

2015-05-07 Thread Btc Drak
On Thu, May 7, 2015 at 6:43 PM, Mike Hearn m...@plan99.net 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

2015-05-07 Thread 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

2015-05-07 Thread 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

2015-05-07 Thread Jorge Timón
On Thu, May 7, 2015 at 6:59 PM, Gavin Andresen gavinandre...@gmail.com 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

2015-05-07 Thread 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

2015-05-07 Thread 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

2015-05-07 Thread 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

2015-05-07 Thread Btc Drak
On Thu, May 7, 2015 at 7:40 PM, Gavin Costin slashdevn...@hotmail.com
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

2015-05-07 Thread 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

2015-05-07 Thread 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

2015-05-07 Thread Btc Drak
On Thu, May 7, 2015 at 5:11 PM, Mike Hearn m...@plan99.net 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 Requirements

2015-05-07 Thread 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

2015-05-07 Thread 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

2015-05-07 Thread 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 because wallets are
 including far greater fees 

[Bitcoin-development] Assurance contracts to fund the network with OP_CHECKLOCKTIMEVERIFY

2015-05-07 Thread Tier Nolan
One of the suggestions to avoid the problem of fees going to zero is
assurance contracts.  This lets users (perhaps large merchants or
exchanges) pay to support the network.  If insufficient people pay for the
contract, then it fails.

Mike Hearn suggests one way of achieving it, but it doesn't actually create
an assurance contract.  Miners can exploit the system to convert the
pledges into donations.

https://bitcointalk.org/index.php?topic=157141.msg1821770#msg1821770

Consider a situation in the future where the minting fee has dropped to
almost zero.  A merchant wants to cause block number 1 million to
effectively have a minting fee of 50BTC.

He creates a transaction with one input (0.1BTC) and one output (50BTC) and
signs it using SIGHASH_ANYONE_CAN_PAY.  The output pays to OP_TRUE.  This
means that anyone can spend it.  The miner who includes the transaction
will send it to an address he controls (or pay to fee).  The transaction
has a locktime of 1 million, so that it cannot be included before that
point.

This transaction cannot be included in a block, since the inputs are lower
than the outputs.  The SIGHASH_ANYONE_CAN_PAY field mean that others can
pledge additional funds.  They add more input to add more money and the
same sighash.

There would need to be some kind of notice boeard system for these pledges,
but if enough pledge, then a valid transaction can be created.  It is in
miner's interests to maintain such a notice board.

The problem is that it counts as a pure donation.  Even if only 10BTC has
been pledged, a miner can just add 40BTC of his own money and finish the
transaction.  He nets the 10BTC of the pledges if he wins the block.  If he
loses, nobody sees his 40BTC transaction.  The only risk is if his block is
orphaned and somehow the miner who mines the winning block gets his 40BTC
transaction into his block.

The assurance contract was supposed to mean If the effective minting fee
for block 1 million is 50 BTC, then I will pay 0.1BTC.  By adding his
40BTC to the transaction the miner converts it to a pure donation.

The key point is that *other* miners don't get 50BTC reward if they find
the block, so it doesn't push up the total hashing power being committed to
the blockchain, that a 50BTC minting fee would achieve.  This is the whole
point of the assurance contract.

OP_CHECKLOCKTIMEVERIFY could be used to solve the problem.

Instead of paying to OP_TRUE, the transaction should pay 50 BTC to 1
million OP_CHECKLOCKTIMEVERIFY OP_TRUE and 0.01BTC to OP_TRUE.

This means that the transaction could be included into a block well in
advance of the 1 million block point.  Once block 1 million arrives, any
miner would be able to spend the 50 BTC.  The 0.01BTC is the fee for the
block the transaction is included in.

If the contract hasn't been included in a block well in advance, pledgers
would be recommended to spend their pledged input,

It can be used to pledge to many blocks at once.  The transaction could pay
out to lots of 50BTC outputs but with the locktime increasing by for each
output.

For high value transactions, it isn't just the POW of the next block that
matters but all the blocks that are built on top of it.

A pledger might want to say I will pay 1BTC if the next 100 blocks all
have at least an effective minting fee of 50BTC
--
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 Requirements

2015-05-07 Thread Matt Corallo
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 bitcoin-l...@bluematt.me
 mailto:bitcoin-l...@bluematt.me 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 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.

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

2015-05-07 Thread 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 bitcoin-l...@bluematt.me
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

2015-05-07 Thread 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 etothe...@gmail.com 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




 --
 One dashboard for servers and applications 

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Mike Hearn

 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:

https://medium.com/@octskyward/bitcoin-s-seasonal-affective-disorder-35733bab760d

It's a fairly simple estimate based on previous growth patterns.

Because I love wild guesses and mine is that full 1 MB blocks will not
 happen until June 2017.


OK, it could be. But do you think this debate will play out significantly
differently if you are right, I am wrong, and we have this discussion next
summer instead? Because in several years of watching these debates, I
haven't seen much change in them.


 We've successfully reached consensus for several softfork proposals
 already.


Are you sure about that?

What if Gavin popped up right now and said he disagreed with every current
proposal, he disagreed with side chains too, and there would be no
consensus on any of them until the block size limit was raised.

Would you say, oh, OK, guess that's it then. There's no consensus so might
as well scrap all those proposals, as they'll never happen anyway. Bye bye
side chains whitepaper.



 I just hope that by  What we need to see right now is leadership you
 don't mean something like when Gaving and Mike agree it's enough to
 deploy a hardfork when you go from vague to concrete.


No. What I meant is that someone (theoretically Wladimir) needs to make a
clear decision. If that decision is Bitcoin Core will wait and watch the
fireworks when blocks get full, that would be showing leadership .
albeit I believe in the wrong direction. It would, however, let people know
what's what and let them start to make longer term plans.

This dillydallying around is an issue - people just make vague points that
can't really be disagreed with (more nodes would be nice, smaller pools
would also be nice etc), and nothing gets done.


 no bitcoin long term it's broken long term but that's far away in the
 future so let's just worry about the present.


I never said Bitcoin is broken in the long term. Far from it - I laid out
my ideas for what will happen when the block subsidy dwindles years ago.

But yes, it's hard for me to care overly much about what happens 30 years
from now, for the same reason you probably care more about what happens
tomorrow than what happens after you are dead. The further into the future
you try and plan, the less likely your plans are to survive unscathed.


 What you want to avoid at all cost (the block size actually being
 used), I see as the best opportunity we have to look into the future.


I think I see one of the causes of disagreement now.

I will write more on the topic of what will happen if we hit the block size
limit soon, maybe this evening. I have some other tasks to do first.

Regardless, I don't believe we will get any useful data out of such an
event. I've seen distributed systems run out of capacity before. What will
happen instead is technological failure followed by rapid user abandonment
that pushes traffic back below the pressure threshold  and those users
will most likely not come back any time soon.


 Ok, this is my plan: we wait 12 months, hope that your estimations are
 correct (in case that my guess was better than yours, we keep waiting
 until June 2017) and start having full blocks and people having to
 wait 2 blocks for their transactions to be confirmed some times.


I disagree that'd be the outcome, but good, this is progress. Now we need
to hear something like that from Wladimir, or whoever has the final say
around here.

With respect to the fee market: I think it's fairer to say Gavin wants a
market to exist, and he also wants supply to be plentiful. 20mb limit
doesn't actually mean every block will be 20mb the day after, no more than
they're all 1mb today. Miners may discover that if they go beyond 5mb they
have too many orphans and then propagation speed will have to be optimised
to break through the next bottleneck. Scaling is always about finding the
next bottleneck and removing it, ideally, before you hit it.
--
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

2015-05-07 Thread Jorge Timón
On Thu, May 7, 2015 at 1:29 PM, Mike Hearn m...@plan99.net wrote:
 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:

 https://medium.com/@octskyward/bitcoin-s-seasonal-affective-disorder-35733bab760d

 It's a fairly simple estimate based on previous growth patterns.

Ok, thanks.

 We've successfully reached consensus for several softfork proposals
 already.


 Are you sure about that?

Yes, Peter Todd gave more details.

 What if Gavin popped up right now and said he disagreed with every current
 proposal, he disagreed with side chains too, and there would be no consensus
 on any of them until the block size limit was raised.

 Would you say, oh, OK, guess that's it then. There's no consensus so might
 as well scrap all those proposals, as they'll never happen anyway. Bye bye
 side chains whitepaper.

Well, yes, it is true that universally uncontroversial (which is
what I think the requirement should be for hard forks) is a vague
qualifier that's not formally defined anywhere.
I guess we should only consider rational arguments. You cannot just
nack something without further explanation.
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.
In the same way, when people use fallacies (purposely or not) we must
expose that and say this fallacy doesn't count as an argument.
But yeah, it would probably be good to define better what constitutes
a sensible objection or something. That doesn't seem simple though.

 I just hope that by  What we need to see right now is leadership you
 don't mean something like when Gaving and Mike agree it's enough to
 deploy a hardfork when you go from vague to concrete.


 No. What I meant is that someone (theoretically Wladimir) needs to make a
 clear decision. If that decision is Bitcoin Core will wait and watch the
 fireworks when blocks get full, that would be showing leadership .
 albeit I believe in the wrong direction. It would, however, let people know
 what's what and let them start to make longer term plans.

 This dillydallying around is an issue - people just make vague points that
 can't really be disagreed with (more nodes would be nice, smaller pools
 would also be nice etc), and nothing gets done.

Well, there's two different things here.
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).
But what the bitcoin network itself does it's very different because
unlike the bitcoin core software project, the Bitcoin network is
decentralized.
If the people with commit access go nuts and decide something that's
clearly stupid or evil, people can just fork the project because it is
free software.
You cannot be forced to use specific features of free software, you
can always remove them and recompile, that's the whole point.
So, no, there's no authority to decide on hardforks and that's why I
think that only clearly uncontroversial things can get through as
hardforks.

 What you want to avoid at all cost (the block size actually being
 used), I see as the best opportunity we have to look into the future.


 I think I see one of the causes of disagreement now.

 I will write more on the topic of what will happen if we hit the block size
 limit soon, maybe this evening. I have some other tasks to do first.

 Regardless, I don't believe we will get any useful data out of such an
 event. I've seen distributed systems run out of capacity before. What will
 happen instead is technological failure followed by rapid user abandonment
 that pushes traffic back below the pressure threshold  and those users
 will most likely not come back any time soon.

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?

 Ok, this is my plan: we wait 12 months, hope that your estimations are
 correct (in case that my guess was better than yours, we keep waiting
 until June 2017) and start having full blocks and people having to
 wait 2 blocks for their transactions to be confirmed some times.


 I disagree that'd be the outcome, but good, this is progress. Now we need to
 hear something like that from Wladimir, or whoever has the final say around
 here.

As said above there's no authority to decide on what Bitcoin the p2p
network does. Again, that's the whole point.
But, yes, I agree that both sides understanding each other better is progress.

 With respect to the fee market: I think it's fairer to say Gavin wants a
 market to exist, and he also wants supply to be plentiful. 20mb limit
 doesn't actually mean every block will be 20mb the day after, no more than
 they're all 1mb today. Miners may discover that if they go beyond 5mb 

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 11:25:04AM +0200, Mike Hearn wrote:
  Certainly a consensus in this kind of technical community should be a
  basic requirement for any serious commitment to blocksize increase.
 
 
 I'm afraid I have come to disagree. I no longer believe this community can
 reach consensus on anything protocol related. Some of these arguments have
 dragged on for years. Consensus isn't even well defined - consensus of who?
 Anyone who shows up? And what happens when, inevitably, no consensus is
 reached? Stasis forever?

Care to be specific?

We've made lots of protocol related changes, as well as non-consensus
policy changes, often in quite short timeframes, and with little drama.
For instance BIP66 adopting is progressing smoothly, and itself was very
quickly developed as part of a broader response to a serious OpenSSL
flaw. My own BIP65 is getting wide consensus with little drama and good
peer review, and that's happening even without as much attention paid to
it from myself as I should have been giving it. The BIP62 malleability
softfork is going more slowly, but that's because peer review is finding
issues and fixing them - something to be expected in an environment
where we simply must be cautious.

As for the v0.11 release, it will have pruning, perhaps the biggest
change to the way Bitcoin Core works that we've ever made. Equally it's
notable how many people collaborated on the implementation of pruning,
again with little drama.

Sure, some stuff has been hard to get consensus on. But those things
carry high risks, and involve code and practices known to be dangerous.
In most cases we've found out the lack of consensus was spot on, and
controversial changes turn out later to have severe security
vulnerabilities. I read that as a sign that the peer review and
consensus building process works just fine.

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


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

2015-05-07 Thread Andrew
I'm mainly just an observer on this. I mostly agree with Pieter. Also, I
think the main reason why people like Gavin and Mike Hearn are trying to
rush this through is because they have some kind of apps that depend on
zero conf instant transactions, so this would of course require more
traffic on the blockchain. I think people like Gavin or Mike should state
clearly what kind of (rigorous) system for instant transactions is
satisfactory for use in their applications. Be it lightning or something
similar, what is good enough? And no zero conf is not a real secure system.
Then once we know what is good enough for them (and everyone else), we can
implement it as a soft fork into the protocol, and it's a win win situation
for both sides (we can also benefit from all the new users people like Mike
are trying bring in).

On Thu, May 7, 2015 at 10:52 AM, Jorge Timón jti...@jtimon.cc wrote:

 On Thu, May 7, 2015 at 11:25 AM, Mike Hearn m...@plan99.net wrote:
  I observed to Wladimir and Gavin in private that this timeline meant a
 change to the block size was unlikely to get into 0.11, leaving only 0.12,
 which would give everyone only a few months to upgrade in order to fork the
 chain by the end of the winter growth season. That seemed tight.

 Can you please elaborate on what terrible things will happen if we
 don't increase the block size by winter this year?
 I assume that you are expecting full blocks by then, have you used any
 statistical technique to come up with that date or is it just your
 guess?
 Because I love wild guesses and mine is that full 1 MB blocks will not
 happen until June 2017.

  What we need to see right now is leadership and a plan, that fits in the
  available time window.
 
 
  Certainly a consensus in this kind of technical community should be a
  basic requirement for any serious commitment to blocksize increase.
 
 
  I'm afraid I have come to disagree. I no longer believe this community
 can
  reach consensus on anything protocol related. Some of these arguments
 have
  dragged on for years. Consensus isn't even well defined - consensus of
 who?
  Anyone who shows up? And what happens when, inevitably, no consensus is
  reached? Stasis forever?

 We've successfully reached consensus for several softfork proposals
 already.
 I agree with others that hardfork need to be uncontroversial and there
 should be consensus about them.
 If you have other ideas for the criteria for hardfork deployment all I'm
 ears.
 I just hope that by  What we need to see right now is leadership you
 don't mean something like when Gaving and Mike agree it's enough to
 deploy a hardfork when you go from vague to concrete.


  Long-term incentive compatibility requires that there be some fee
  pressure, and that blocks be relatively consistently full or very nearly
  full.
 
 
  I disagree. When the money supply eventually dwindles I doubt it will be
 fee
  pressure that funds mining, but as that's a long time in the future, it's
  very hard to predict what might happen.

 Oh, so your answer to bitcoin will eventually need to live on fees
 and we would like to know more about how it will look like then it's
 no bitcoin long term it's broken long term but that's far away in the
 future so let's just worry about the present.
 I agree that it's hard to predict that future, but having some
 competition for block space would actually help us get more data on a
 similar situation to be able to predict that future better.
 What you want to avoid at all cost (the block size actually being
 used), I see as the best opportunity we have to look into the future.

  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).
 
 
  Many do because free transactions are broken - the relay limiter means
  whether a free transaction actually makes it across the network or not is
  basically pot luck and there's no way for a wallet to know, short of
 either
  trying it or actually receiving every single transaction and repeating
 the
  calculations. If free transactions weren't broken for all non-full nodes
  they'd probably be used a lot more.

 Free transactions are a gift from miners that run an altruistic policy.
 That's great but we shouldn't rely on them for the future. They will
 likely disappear at some point and that's ok.
 In any case, he's not complaining about the lack of free transactions,
 more like the opposite.
 He is saying that's very easy to get free transactions in the next
 block and blocks aren't full so there's no incentive to include fees
 to compete for the space.
 We can talk a lot about a fee market and build a theoretically
 perfect fee estimator but we won't actually have a fee market until
 there's some competition for space.
 Nobody will pay for space that's abundant just like people don't pay
 for the air they breath.

  What I don't see from you yet is a specific and 

Re: [Bitcoin-development] Mechanics of a hard fork

2015-05-07 Thread Pieter Wuille
On May 7, 2015 3:08 PM, Roy Badami r...@gnomon.org.uk wrote:

 On Thu, May 07, 2015 at 11:49:28PM +0200, Pieter Wuille wrote:
  I would not modify my node if the change introduced a perpetual 100 BTC
  subsidy per block, even if 99% of miners went along with it.

 Surely, in that scenario Bitcoin is dead.  If the fork you prefer has
 only 1% of the hash power it is trivially vulnerably not just to a 51%
 attack but to a 501% attack, not to mention the fact that you'd only
 be getting one block every 16 hours.

Yes, indeed, Bitcoin would be dead if this actually happens. But that is
still where the power lies: before anyone (miners or others) would think
about trying such a change, they would need to convince people and be sure
they will effectively modify their code.

-- 
Pieter
--
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] Mechanics of a hard fork

2015-05-07 Thread Cameron Garnham
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

While being in the Bitcoin community for a long time, I haven't been
so directly involved in the development.  However I wish to suggest a
different pre-hard-fork soft-fork approach:


Set a 'block size cap' in the similar same way as we set difficulty.

Every 2016 blocks take the average size of the blocks and multiply the
size by 1.5x, rejecting blocks that are larger than this size, for the
next 2016 period.

I would of-course suggest that we keep the limits at min 100kb and max
(initially) 990kb (not 1mb on purpose, as this should become the new
limit), rounding up to the nearest 10kb.

A: we don't have pressure at the 1mb limit, (we reduce the limit in a
flexible manner to 990kb).

B: we can upgrade the network to XYZ hard-limit, then slowly raze the
soft-limit after being sure the network, as-a-whole is ready.

If we on-day remove the block-size limit, this rule will stop a rouge
miner from making 10mb, or 100mb blocks, or 1gb blocks.

This could be implemented by the miners without breaking any of the
clients, and would tend to produce a better dynamic fee pressure.


This will give the mechanics to the miners to create consensus to
agree what block-sizes they believe are best for the network, and
allows the block-sizes to dynamically grow in response to larger demand.



On 5/8/2015 10:35 AM, Pieter Wuille wrote:
 On May 7, 2015 3:08 PM, Roy Badami r...@gnomon.org.uk wrote:
 
 On Thu, May 07, 2015 at 11:49:28PM +0200, Pieter Wuille wrote:
 I would not modify my node if the change introduced a perpetual
 100 BTC subsidy per block, even if 99% of miners went along
 with it.
 
 Surely, in that scenario Bitcoin is dead.  If the fork you prefer
 has only 1% of the hash power it is trivially vulnerably not just
 to a 51% attack but to a 501% attack, not to mention the fact
 that you'd only be getting one block every 16 hours.
 
 Yes, indeed, Bitcoin would be dead if this actually happens. But
 that is still where the power lies: before anyone (miners or
 others) would think about trying such a change, they would need to
 convince people and be sure they will effectively modify their
 code.
 
 
 
 --
- 

 
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
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlVMKZYACgkQBJ8cMDO159aTiQEApTITEBrhE1DRbj/w+GncNeqB
0hGvmIBa1z0hGww0kaMBAOhxjn/K5leRJgdt1fKhNEDKKHdeCOIX3QRgry90D3NO
=p0+H
-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


Re: [Bitcoin-development] Solution for Block Size Increase

2015-05-07 Thread Thy Shizzle
Nicolas, can you think if there would be a problem with allowing blocks to be 
created faster instead of increasing block size? So say if difficulty was 
reduced to allow block creation every 2 minutes instead of 10 minutes, can you 
think of any bad outcome from this (I know this is different to what you are 
saying) but I'm thinking if we allow 1mb blocks to be built faster, that way 
transactions are processed quicker  thus gaining a higher tps rate, i'd think 
no hard fork need occur right?

Is there any downsides that you can see? Obviously miners need yo update, but I 
mean if they don't it just means they potentially take too long to make blocks 
and thus loose out in reward so there is the incentive for them to update to 
the easier difficulty, while still allowing blocks done on the harder 
difficulty for backwards compatibility.

Thoughts?

From: Nicolas DORIERmailto:nicolas.dor...@gmail.com
Sent: ‎8/‎05/‎2015 9:17 AM
To: 
bitcoin-development@lists.sourceforge.netmailto:bitcoin-development@lists.sourceforge.net
Subject: [Bitcoin-development] Solution for Block Size Increase

Executive Summary:

I explain the objectives that we should aim to reach agreement without
drama, controversy, and relief the core devs from the central banker role.
(As Jeff Garzik pointed out)
Knowing the objectives, I propose a solution based on the objectives that
can be agreed on tomorrow, would permanently fix the block size problem
without controversy and would be immediately applicable.

The objectives:

There is consensus on the fact that nobody wants the core developers to be
seen as central bankers.
There is also consensus that more decentralization is better than less.
(assuming there is no cost to it)

This means you should reject all arguments based on economical, political
and ideological principles about what Bitcoin should become. This includes:

1) Whether Bitcoin should be storage of value or suitable for coffee
transaction,
2) Whether we need a fee market, block scarcity, and how much of it,
3) Whether we need to periodically increase block size via some voodoo
formula which speculate on future bandwidth and cost of storage,

Taking decisions based on such reasons is what central bankers do, and you
don’t want to be bankers. This follow that decisions should be taken only
for technical and decentralization considerations. (more about
decentralization after)

Scarcity will evolve without you taking any decisions about it, for the
only reason that storage and bandwidth is not free, nor a transaction,
thanks to increased propagation time.
This backed in scarcity will evolve automatically as storage, bandwidth,
encoding, evolve without anybody taking any decision, nor making any
speculation on the future.

Sadly, deciding how much decentralization should be in the system by
tweaking the block size limit is also an economic decision that should not
have its place between the core devs. This follow :

4) Core devs should not decide about the amount of suitable
decentralization by tweaking block size limit,

Still, removing the limit altogether is a no-no, what would happen if a
block of 100 GB is created? Immediately the network would be decentralized,
not only for miners but also for bitcoin service providers. Also, core devs
might have technical consideration on bitcoin core which impose a temporary
limit until the bug resolved.

The solution:

So here is a proposal that address all my points, and, I think, would get a
reasonable consensus. It can be published tomorrow without any controversy,
would be agreed in one year, and can be safely reiterated every year.
Developers will also not have to play politics nor central banker. (well,
it sounds to good to be true, I waiting for being wrong)

The solution is to use block voting. For each block, a miner gives the size
of the block he would like to have at the next deadline (for example, 30
may 2015). The rational choice for them is just enough to clear the memory
pool, maybe a little less if he believes fee pressure is beneficial for
him, maybe a little more if he believes he should leave some room for
increased use.
At the deadline, we take the median of the votes and implement it as a new
block size limit. Reiterate for the next year.

Objectives reached:


   - No central banking decisions on devs shoulder,
   - Votes can start tomorrow,
   - Implementation has only to be ready in one year, (no kick-in-the-can)
   - Will increase as demand is growing,
   - Will increase as network capacity and storage is growing,
   - Bitcoin becomes what miners want, not what core devs and politician
   wants,
   - Implementation reasonably easy,
   - Will get miner consensus, no impact on existing bitcoin services,


Unknown:

   - Effect on bitcoin core stability (core devs might have a valid
   technical reason to impose a limit)
   - Maybe a better statistical function is possible

Additional input for the debate:

Some people were 

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread 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

2015-05-07 Thread Jeff Garzik
On Thu, May 7, 2015 at 9:40 PM, Tom Harding t...@thinlink.com 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

2015-05-07 Thread 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

2015-05-07 Thread 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] Mechanics of a hard fork

2015-05-07 Thread Adam Back
Well this is all very extreme circumstances, and you'd have to assume no
rational player with an interest in bitcoin would go there, but to play
your analysis forward: users are also not powerless at the extreme: they
could change the hash function rendering current deployed ASICs useless in
reaction for example, and reset difficulty at the same time, or freeze
transactions until some minimum hashrate is reached.  People would figure
out what is the least bad way forward.

Adam
On May 7, 2015 3:09 PM, Roy Badami r...@gnomon.org.uk wrote:

 On Thu, May 07, 2015 at 11:49:28PM +0200, Pieter Wuille wrote:
  I would not modify my node if the change introduced a perpetual 100 BTC
  subsidy per block, even if 99% of miners went along with it.

 Surely, in that scenario Bitcoin is dead.  If the fork you prefer has
 only 1% of the hash power it is trivially vulnerably not just to a 51%
 attack but to a 501% attack, not to mention the fact that you'd only
 be getting one block every 16 hours.

 
  A hardfork is safe when 100% of (economically relevant) users upgrade. If
  miners don't upgrade at that point, they just lose money.
 
  This is why a hashrate-triggered hardfork does not make sense. Either you
  believe everyone will upgrade anyway, and the hashrate doesn't matter. Or
  you are not certain, and the fork is risky, independent of what hashrate
  upgrades.

 Beliefs are all very well, but they can be wrong.  Of course we should
 not go ahead with a fork that we believe to be dangerous, but
 requiring a supermajority of miners is surely a wise precaution.  I
 fail to see any realistic scenario where 99% of miners vote for the
 hard fork to go ahead, and the econonomic majority votes to stay on
 the blockchain whose hashrate has just dropped two orders of magnitude
 - so low that the mean time between blocks is now over 16 hours.

 
  And the march 2013 fork showed that miners upgrade at a different
 schedule
  than the rest of the network.
  On May 7, 2015 5:44 PM, Roy Badami r...@gnomon.org.uk wrote:
 
  
On the other hand, if 99.99% of the miners updated and only 75% of
merchants and 75% of users updated, then that would be a serioud
 split of
the network.
  
   But is that a plausible scenario?  Certainly *if* the concensus rules
   required a 99% supermajority of miners for the hard fork to go ahead,
   then there would be absoltely no rational reason for merchants and
   users to refuse to upgrade, even if they don't support the changes
   introduces by the hard fork.  Their only choice, if the fork succeeds,
   is between the active chain and the one that is effectively stalled -
   and, of course, they can make that choice ahead of time.
  
   roy
  
  
  
 --
   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

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

2015-05-07 Thread Jeff Garzik
I have a lot more written down, a WIP; here are the highlights.

- The 1MB limit is an ancient anti-spam limit, and needs to go.

- The 1MB limit is economically entrenched at this point, and cannot be
removed at a whim.

- This is a major change to the economics of a $3.2B system.  This change
picks winners and losers.  There is attendant moral hazard.

- The core dev team is not and should not be an FOMC.

- The bar for major economic change to a $3.2B system should necessarily
be high.  In the more boring world of investments, this would accompanied
by Due Diligence including but not limited to projections for success,
failure scenarios, upside risks and downside risks.  Projections and
fact-based simulations.

- There are significant disruption risks on the pro (change it) and con
(keep 1MB) sides of the debate.

- People are privately lobbying Gavin for this.  That is the wrong way to
go.   I have pushed for a more public debate, and public endorsements (or
condemnations) from major miners, merchants, payment processors,
stackholders, ...   It is unfair to criticize Gavin to doing this.
--
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

2015-05-07 Thread Bryan Bishop
On Thu, May 7, 2015 at 9:05 AM, Mike Hearn m...@plan99.net 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.

Hmm, git repositories don't quite work like that. Instead, you should
imagine everyone having a local copy of the git repository. Each
developer synchronizes their git repository with other developers.
They merge changes from specific remote branches that they have
received. Each developer has their own branch and each developer is
the single decision maker for the artifact that they compile.

- 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-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 04:05:41PM +0200, Mike Hearn wrote:
 Peter:   your hypocrisy really is bottomless, isn't it? You constantly
 claim to be a Righteous Defender of Privacy, but don't even hesitate before
 publishing hacked private emails when it suits you.

 Satoshi's hacker had no illusions about your horrible personality, which is
 why he forwarded that email to you specifically. He knew you'd use it. You
 should reflect on that fact. It says nothing good about you at all.

As you know I was forwarded that email first, and because I *do* respect
your privacy I consulting with you via private IRC chat first, and as
you wished I didn't publish it. The hacker presumably gave up waiting
for me to do so and published it themselves seven months ago; to make
that clear I linked the source(1) of the email in my message. Those
emails simply are no longer private.

Frankly personal attacks like this - your hypocrisy really is
bottomless, isn't it?, Satoshi's hacker had no illusions about your
horrible personality - simply don't belong on this mailing list and I
think we would all appreciate an apology.

1) https://www.reddit.com/r/Bitcoin/comments/2g9c0j/satoshi_email_leak/

-- 
'peter'[:-1]@petertodd.org
12a3e40d5ee5c7fc2fb8367b720a9d499468ceb25366c1f3


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

2015-05-07 Thread Jorge Timón
On Thu, May 7, 2015 at 1:55 PM, Dave Hudson d...@hashingit.com wrote:
 Known: There has been a steady trend towards the mean block size getting
 larger. See
 https://blockchain.info/charts/avg-block-size?timespan=allshowDataPoints=falsedaysAverageString=7show_header=truescale=0address=

Looking at this graph and in retrospective, we shouldn't have removed
the standard policy limit without observing the supposedly disastrous
effects of hitting the limit first.
Removing the standard limit would have been trivial (bdb issues aside)
at any point after seeing the effects.

 Known: If we reach the point where all blocks are 1M bytes then there's a
 major problem in terms of transaction confirmation. I published an analysis
 of the impact of different mean block sizes against confirmation times:
 http://hashingit.com/analysis/34-bitcoin-traffic-bulletin. The current 35%
 to 45% mean block size doesn't have a huge impact on transaction
 confirmations (assuming equal fees for all) but once we're up at 80% then
 things start to get unpleasant. Instead of 50% of first confirmations taking
 about 7 minutes they instead take nearer to 19 minutes.

Well, this is only for first confirmations of free transaction.
A higher fee should increase your probabilities, but if you're sending
free transactions you may not care about them taking longer to be
included.

 Known: There are currently a reasonably large number of zero-fee
 transactions getting relayed and mined. If things start to slow down then
 there will be a huge incentive to delay them (or drop them altogether).

Well, maybe instant and free it's not a honest form of bitcoin
marketing and it just has to disappear.
Maybe we just need to start being more honest about pow being good for
processing micro-transactions: it is not.
Hopefully lightning will be good for that.
Free and fast in-chain transactions is something temporary that we
know will eventually disappear.
If people think it would be a adoption disaster that it happens soon,
then they could also detail an alternative plan to roll that out
instead of letting it happen.
But if the plan is to delay it forever...then I'm absolutely against.

 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.

 Known: the orphan rate is still pretty-high even with everyone's fast
 connections. If we assume that 20M byte blocks become possible then that's
 likely to increase.

 Unknown: What are the security implications for larger blocks (this one (at
 least) can be simulated though)? For example, could large blocks with huge
 numbers of trivial transactions be used to put other validators at a
 disadvantage in a variant of a selfish mining attack? I've seen objections
 that such bad actors could be blacklisted in the future but it's not clear
 to me how. A private mining pool can trivially be made to appear like 100
 pools of 1% of the size without significantly affecting the economics of
 running that private mine.

No blacklisting, please, that's centralized.
In any case, a related known: bigger blocks give competitive advantage
to bigger miners.

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

2015-05-07 Thread Mike Hearn

 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.


 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.

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.


 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.

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.



Peter:   your hypocrisy really is bottomless, isn't it? You constantly
claim to be a Righteous Defender of Privacy, but don't even hesitate before
publishing hacked private emails when it suits you.

Satoshi's hacker had no illusions about your horrible personality, which is
why he forwarded that email to you specifically. He knew you'd use it. You
should reflect on that fact. It says nothing good about you at all.
--
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] Mechanics of a hard fork

2015-05-07 Thread Pieter Wuille
I would not modify my node if the change introduced a perpetual 100 BTC
subsidy per block, even if 99% of miners went along with it.

A hardfork is safe when 100% of (economically relevant) users upgrade. If
miners don't upgrade at that point, they just lose money.

This is why a hashrate-triggered hardfork does not make sense. Either you
believe everyone will upgrade anyway, and the hashrate doesn't matter. Or
you are not certain, and the fork is risky, independent of what hashrate
upgrades.

And the march 2013 fork showed that miners upgrade at a different schedule
than the rest of the network.
On May 7, 2015 5:44 PM, Roy Badami r...@gnomon.org.uk wrote:


  On the other hand, if 99.99% of the miners updated and only 75% of
  merchants and 75% of users updated, then that would be a serioud split of
  the network.

 But is that a plausible scenario?  Certainly *if* the concensus rules
 required a 99% supermajority of miners for the hard fork to go ahead,
 then there would be absoltely no rational reason for merchants and
 users to refuse to upgrade, even if they don't support the changes
 introduces by the hard fork.  Their only choice, if the fork succeeds,
 is between the active chain and the one that is effectively stalled -
 and, of course, they can make that choice ahead of time.

 roy


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


[Bitcoin-development] Solution for Block Size Increase

2015-05-07 Thread Nicolas DORIER
Executive Summary:

I explain the objectives that we should aim to reach agreement without
drama, controversy, and relief the core devs from the central banker role.
(As Jeff Garzik pointed out)
Knowing the objectives, I propose a solution based on the objectives that
can be agreed on tomorrow, would permanently fix the block size problem
without controversy and would be immediately applicable.

The objectives:

There is consensus on the fact that nobody wants the core developers to be
seen as central bankers.
There is also consensus that more decentralization is better than less.
(assuming there is no cost to it)

This means you should reject all arguments based on economical, political
and ideological principles about what Bitcoin should become. This includes:

1) Whether Bitcoin should be storage of value or suitable for coffee
transaction,
2) Whether we need a fee market, block scarcity, and how much of it,
3) Whether we need to periodically increase block size via some voodoo
formula which speculate on future bandwidth and cost of storage,

Taking decisions based on such reasons is what central bankers do, and you
don’t want to be bankers. This follow that decisions should be taken only
for technical and decentralization considerations. (more about
decentralization after)

Scarcity will evolve without you taking any decisions about it, for the
only reason that storage and bandwidth is not free, nor a transaction,
thanks to increased propagation time.
This backed in scarcity will evolve automatically as storage, bandwidth,
encoding, evolve without anybody taking any decision, nor making any
speculation on the future.

Sadly, deciding how much decentralization should be in the system by
tweaking the block size limit is also an economic decision that should not
have its place between the core devs. This follow :

4) Core devs should not decide about the amount of suitable
decentralization by tweaking block size limit,

Still, removing the limit altogether is a no-no, what would happen if a
block of 100 GB is created? Immediately the network would be decentralized,
not only for miners but also for bitcoin service providers. Also, core devs
might have technical consideration on bitcoin core which impose a temporary
limit until the bug resolved.

The solution:

So here is a proposal that address all my points, and, I think, would get a
reasonable consensus. It can be published tomorrow without any controversy,
would be agreed in one year, and can be safely reiterated every year.
Developers will also not have to play politics nor central banker. (well,
it sounds to good to be true, I waiting for being wrong)

The solution is to use block voting. For each block, a miner gives the size
of the block he would like to have at the next deadline (for example, 30
may 2015). The rational choice for them is just enough to clear the memory
pool, maybe a little less if he believes fee pressure is beneficial for
him, maybe a little more if he believes he should leave some room for
increased use.
At the deadline, we take the median of the votes and implement it as a new
block size limit. Reiterate for the next year.

Objectives reached:


   - No central banking decisions on devs shoulder,
   - Votes can start tomorrow,
   - Implementation has only to be ready in one year, (no kick-in-the-can)
   - Will increase as demand is growing,
   - Will increase as network capacity and storage is growing,
   - Bitcoin becomes what miners want, not what core devs and politician
   wants,
   - Implementation reasonably easy,
   - Will get miner consensus, no impact on existing bitcoin services,


Unknown:

   - Effect on bitcoin core stability (core devs might have a valid
   technical reason to impose a limit)
   - Maybe a better statistical function is possible

Additional input for the debate:

Some people were debating whether miners are altruist or act rationally. We
should always expect them to act rationally, but we should not forget the
peculiarity of TCP backoff game: While it is in the best interest of
players to NOT reemit TCP packet with a backoff if the ACK is not received,
everybody does it. (Because of the fallacy that changing a TCP
implementation is costless)

Often, when we think a real life situation is a prisoner dilemma problem,
it turns out that the incentives where just incorrectly modeled.

Core devs, thanks for all your work, but please step out of the banker's
role and focus on where you are the best, I speak as an entrepreneur that
doesn't want decisions about bitcoin to be taken by who has the biggest.
If the decision of the hard limit is taken for other than purely technical
decisions, ie, for the maximization of whatever metric, it will clearly put
you in banker's shoes. As an entrepreneur, I have other things to speculate
than who gets the biggest gun in the core team.
Please consider my solution,

Nicolas Dorier,
--
One 

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread 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


[Bitcoin-development] Mechanics of a hard fork

2015-05-07 Thread Roy Badami
I'd love to have more discussion of exactly how a hard fork should be
implemented.  I think it might actually be of some value to have rough
consensus on that before we get too bogged down with exactly what the
proposed hard fork should do.  After all, how can we debate whether a
particular hard fork proposal has consensus if we haven't even decided
what level of supermajority is needed to establish consensus?

For instance, back in 2012 Gavin was proposing, effectively, that a
hard fork should require a supermajority of 99% of miners in order to
succeed:

https://gist.github.com/gavinandresen/2355445

More recently, Gavin has proposed that a supermoajority of only 80% of
miners should be needed in order to trigger the hard fork.

http://www.gavintech.blogspot.co.uk/2015/01/twenty-megabytes-testing-results.html

Just now, on this list (see attached message) Gavin seems to be
aluding to some mechanism for a hard fork which involves consensus of
full nodes, and then a soft fork preceeding the hard fork, which I'd
love to see a full explanation of.

FWIW, I think 80% is far too low to establish consensus for a hard
fork.  I think the supermajority of miners should be sufficiently
large that the rump doesn't constitute a viable coin.  If you don't
have that very strong level of consensus then you risk forking Bitcoin
into two competing coins (and I believe we already have one exchange
promissing to trade both forks as long as the blockchains are alive).

As a starting point, I think 35/36th of miners (approximately 97.2%)
is the minimum I would be comfortable with.  It means that the rump
coin will initially have an average confirmation time of 6 hours
(until difficulty, very slowly, adjusts) which is probably far enough
from viable that the majority of holdouts will quickly desert it too.

Thoughs?

roy---BeginMessage---
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
---End Message---
--
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

Re: [Bitcoin-development] Mechanics of a hard fork

2015-05-07 Thread Tier Nolan
In terms of miners, a strong supermajority is arguably sufficient, even 75%
would be enough.

The near total consensus required is merchants and users.  If (almost) all
merchants and users updated and only 75% of the miners updated, then that
would give a successful hard-fork.

On the other hand, if 99.99% of the miners updated and only 75% of
merchants and 75% of users updated, then that would be a serioud split of
the network.

The advantage of strong miner support is that it effectively kills the fork
that follows the old rules.  The 25% of merchants and users sees a
blockchain stall.

Miners are likely to switch to the fork that is worth the most.  A mining
pool could even give 2 different sub-domains.  A hasher can pick which
rule-set to follow.  Most likely, they would converge on the fork which
paid the most, but the old ruleset would likely still have some hashing
power and would eventually re-target.

On Thu, May 7, 2015 at 9:00 PM, Roy Badami r...@gnomon.org.uk wrote:

 I'd love to have more discussion of exactly how a hard fork should be
 implemented.  I think it might actually be of some value to have rough
 consensus on that before we get too bogged down with exactly what the
 proposed hard fork should do.  After all, how can we debate whether a
 particular hard fork proposal has consensus if we haven't even decided
 what level of supermajority is needed to establish consensus?

 For instance, back in 2012 Gavin was proposing, effectively, that a
 hard fork should require a supermajority of 99% of miners in order to
 succeed:

 https://gist.github.com/gavinandresen/2355445

 More recently, Gavin has proposed that a supermoajority of only 80% of
 miners should be needed in order to trigger the hard fork.


 http://www.gavintech.blogspot.co.uk/2015/01/twenty-megabytes-testing-results.html

 Just now, on this list (see attached message) Gavin seems to be
 aluding to some mechanism for a hard fork which involves consensus of
 full nodes, and then a soft fork preceeding the hard fork, which I'd
 love to see a full explanation of.

 FWIW, I think 80% is far too low to establish consensus for a hard
 fork.  I think the supermajority of miners should be sufficiently
 large that the rump doesn't constitute a viable coin.  If you don't
 have that very strong level of consensus then you risk forking Bitcoin
 into two competing coins (and I believe we already have one exchange
 promissing to trade both forks as long as the blockchains are alive).

 As a starting point, I think 35/36th of miners (approximately 97.2%)
 is the minimum I would be comfortable with.  It means that the rump
 coin will initially have an average confirmation time of 6 hours
 (until difficulty, very slowly, adjusts) which is probably far enough
 from viable that the majority of holdouts will quickly desert it too.

 Thoughs?

 roy

 --
 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] Mechanics of a hard fork

2015-05-07 Thread Roy Badami

 On the other hand, if 99.99% of the miners updated and only 75% of
 merchants and 75% of users updated, then that would be a serioud split of
 the network.

But is that a plausible scenario?  Certainly *if* the concensus rules
required a 99% supermajority of miners for the hard fork to go ahead,
then there would be absoltely no rational reason for merchants and
users to refuse to upgrade, even if they don't support the changes
introduces by the hard fork.  Their only choice, if the fork succeeds,
is between the active chain and the one that is effectively stalled -
and, of course, they can make that choice ahead of time.

roy

--
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] Mechanics of a hard fork

2015-05-07 Thread Roy Badami
On Thu, May 07, 2015 at 11:49:28PM +0200, Pieter Wuille wrote:
 I would not modify my node if the change introduced a perpetual 100 BTC
 subsidy per block, even if 99% of miners went along with it.

Surely, in that scenario Bitcoin is dead.  If the fork you prefer has
only 1% of the hash power it is trivially vulnerably not just to a 51%
attack but to a 501% attack, not to mention the fact that you'd only
be getting one block every 16 hours.

 
 A hardfork is safe when 100% of (economically relevant) users upgrade. If
 miners don't upgrade at that point, they just lose money.
 
 This is why a hashrate-triggered hardfork does not make sense. Either you
 believe everyone will upgrade anyway, and the hashrate doesn't matter. Or
 you are not certain, and the fork is risky, independent of what hashrate
 upgrades.

Beliefs are all very well, but they can be wrong.  Of course we should
not go ahead with a fork that we believe to be dangerous, but
requiring a supermajority of miners is surely a wise precaution.  I
fail to see any realistic scenario where 99% of miners vote for the
hard fork to go ahead, and the econonomic majority votes to stay on
the blockchain whose hashrate has just dropped two orders of magnitude
- so low that the mean time between blocks is now over 16 hours.

 
 And the march 2013 fork showed that miners upgrade at a different schedule
 than the rest of the network.
 On May 7, 2015 5:44 PM, Roy Badami r...@gnomon.org.uk wrote:
 
 
   On the other hand, if 99.99% of the miners updated and only 75% of
   merchants and 75% of users updated, then that would be a serioud split of
   the network.
 
  But is that a plausible scenario?  Certainly *if* the concensus rules
  required a 99% supermajority of miners for the hard fork to go ahead,
  then there would be absoltely no rational reason for merchants and
  users to refuse to upgrade, even if they don't support the changes
  introduces by the hard fork.  Their only choice, if the fork succeeds,
  is between the active chain and the one that is effectively stalled -
  and, of course, they can make that choice ahead of time.
 
  roy
 
 
  --
  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

2015-05-07 Thread Alex Morcos
That strikes me as a dangerous path forward.

I don't actually think there is anything wrong with this: everybody
eventually gets tired of arguing angels-dancing-on-the-head-of-a-pin, and
we're left with the status quo

What gives Bitcoin value aren't its technical merits but the fact that
people believe in it.   The biggest risk here isn't that 20MB blocks will
be bad or that 1MB blocks will be bad, but that by forcing a hard fork that
isn't nearly universally agreed upon, we will be damaging that belief.   If
I strongly believed some hard fork would be better for Bitcoin, say
permanent inflation of 1% a year to fund mining, and I managed to convince
80% of users, miners, businesses and developers to go along with me, I
would still vote against doing it.  Because that's not nearly universal
agreement, and it changes what people chose to believe in without their
consent. Forks should be hard, very hard.  And both sides should recognize
that belief in the value of Bitcoin might be a fragile thing.   I'd argue
that if we didn't force through a 20MB fork now, and we ran into major
network difficulties a year from now and had no other technical solutions,
that maybe we would get nearly universal agreement, and the businesses and
users that were driven away by the unusable system would be a short term
loss in value considerably smaller than the impairment we risk by forcing a
change.



On Thu, May 7, 2015 at 10:52 AM, Gavin Andresen gavinandre...@gmail.com
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


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

2015-05-07 Thread Mike Hearn

 What gives Bitcoin value aren't its technical merits but the fact that
 people believe in it.


Much of the belief in Bitcoin is that it has a bright future. Certainly the
huge price spikes we've seen were not triggered by equally large spikes in
usage - it's speculation on that future.

I quite agree that if people stop believing in Bitcoin, that will be bad. A
fast way to bring that about will be to deliberately cripple the technology
in order to force people onto something quite different (which probably
won't be payment channel networks).


 I'd argue that if we didn't force through a 20MB fork now, and we ran into
 major network difficulties a year from now and had no other technical
 solutions, that maybe we would get nearly universal agreement


I doubt it. The disagreement seems more philosophical than technical. If
Bitcoin fell off a cliff then that'd just be taken as more evidence that
block chains don't work and we should all use some network of payment hubs,
or whatever the fashion of the day is. Or anyone who doesn't want to pay
high fees is unimportant. See all the other justifications Gavin is working
his way through on his blog.

That's why I conclude the opposite - if there is no fork, then people's
confidence in Bitcoin will be seriously damaged. If it's impossible to do
something as trivial as removing a temporary hack Satoshi put in place,
then what about bigger challenges? If the community is really willing to
drive itself off a cliff due to political deadlock, then why bother
building things that use Bitcoin at all?
--
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

2015-05-07 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/07/2015 05:04 PM, Jeff Garzik wrote:
 heh - I tend to think people here want bitcoin to succeed.  My
 statement refers to picking winners and losers from within the
 existing bitcoin community  stakeholders.

Success is not a sufficiently precise term in this context.

There is a large contingent of people for whom the definition of
Bitcoin success means serving as a stable backend which can meet the
needs of their non-Bitcoin platform - and nothing more.

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?

-BEGIN PGP SIGNATURE-

iQIcBAEBAgAGBQJVS4HiAAoJECpf2nDq2eYj23wP/j4ksm2dgzDkccMRbqFM8Pm8
oV6ImxM26bG3DJB+Rh6ttTY4DrUnZJmzQUUxfZUd3TmH/xOM4Lu35gKKhpvHTdR8
vMQz76CaTba6PzzFKC+GYyHueXLtwJxEHEZjR8m5ijPMfZoImfMbduggDaPLv/sz
AUcTDtYWBoPZ9Matms4NZIOsH1S1pHw5YjcFYgxmY6ErHZPqZjoKzcc4wZnrOU+Q
HCmiHOJ1U87jEge4QEJCXidCJFakyMTWt5P6hjdOFfky3VYmcoivYRA1ZemgyV2Y
YyLtmHBcK7k67Tczep8rjggvK2C2oJArFGPLWHZH9bxXILaNXSpZX5G5rXZjp1vm
1voc6JDaK/slXIlfG+BZ56WyprKkiFbN6u4Wd8LG5W8gKiuCyLYr2IGKz9O3fvor
NYtk6ELPfX1+0JBD0ureI7kV85D/ybNnnmMp/NyfmBKzzmqnANRrrqL5zgILuUP4
YaokcVdPpTqkN0vuAXchehEemF5MtJIYf9BayZ86ck68aMjvVJi0nX3n63f1MulP
IbRbYY/8eu1891lNIPiSzbmT0zjjplo8jYEOTg32mIvEDZAy8sWwTPYS25tPd37l
3kxRCxqS1ALbAqLZprmxQ375PigE2esXZlpBHzyY4Kf+3UD/k/X8D92vdNiF7mkS
HSA+TX4lf310Eq6Mb4LR
=5vaU
-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

2015-05-07 Thread Jeff Garzik
On Thu, May 7, 2015 at 11:12 AM, Mike Hearn m...@plan99.net wrote:


 That's why I conclude the opposite - if there is no fork, then people's
 confidence in Bitcoin will be seriously damaged.


Yes, that is a possibility.



 If it's impossible to do something as trivial as removing a temporary hack
 Satoshi put in place, then what about bigger challenges?


This is absolutely not a trivial change.

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

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

2015-05-07 Thread Jeff Garzik
On Thu, May 7, 2015 at 11:16 AM, Justus Ranvier justusranv...@riseup.net
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


Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread 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

2015-05-07 Thread Btc Drak
On Thu, May 7, 2015 at 3:05 PM, Mike Hearn m...@plan99.net 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

2015-05-07 Thread Jeff Garzik
On Thu, May 7, 2015 at 11:33 AM, Justus Ranvier justusranv...@riseup.net
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

2015-05-07 Thread 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

2015-05-07 Thread 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

2015-05-07 Thread 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

2015-05-07 Thread 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

2015-05-07 Thread 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

2015-05-07 Thread Jorge Timón
On Thu, May 7, 2015 at 4:52 PM, Gavin Andresen gavinandre...@gmail.com 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 m...@plan99.net 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

2015-05-07 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/07/2015 04:04 PM, Jeff Garzik wrote:
 - This is a major change to the economics of a $3.2B system.  This
 change picks winners and losers.  There is attendant moral hazard.

This is exactly true.

There are a number of projects which aren't Bitcoin that benefit from
filling in the gap left by Bitcoin's restricted transaction rate
capability.

If Bitcoin fills that gap, Bitcoin wins and those other projects lose.

Should decisions about Bitcoin development take into account the
desires of competing projects?

-BEGIN PGP SIGNATURE-

iQIcBAEBAgAGBQJVS3jeAAoJECpf2nDq2eYj3hMP/0yk8HxypEfNa4vZo0IcKD+p
bn2dftQsOEeOenBh8QT48vS3AhcjNkUsw722YwbKz6Znkyi2iU7njaUM9DV+QHwg
Oytmh8XVZtviLgg3854ujdj4oAWyP4DpppVTRxTDyRdSpRj+D9y6+sGFls6z0q3/
XRcKOY23zx6/qN1k5fqUncpIpYEDhpmE7cGy26Yz0G4MtuYeceHT4LdJAHHr0iFL
OY0WVM32b4F3HfkfJtt8rE0yeB7u5dbeu8KmLB0yqZQkY87sLxtT6qeoyHO6CG+N
8Iu9OWaRIZHfrZK2XlDzDKQIkTnlSxFtj4wY7/Yb4NIDO6mhMjYTSz8lWqN4ofKg
9fFHlwGS3QXXDTB+5d1IzZS5C0qF92n1NJiJjkLqhKqYuVn4U74oslZhVLxHBGHH
ZAvW09obZXi5DVzhuxPzlFkpYaB+XLdmBUPEr5hx5K4I2qiL/Nvu0h031UDcMeLm
x9mEHO5ZODlF9tWAVnM/b0VtwT9h6Q88NWe/OUQQZKp6D/Etcd3JE55GBNtNPDnE
2UubyHkNO4mbrEMluh24TvhZK3BB/lieq+kkHZCP7eC58eRY078lSF8R36XGdbn4
Pili15bYSrRrfmjDz24zhJX8759LPt2Zsf/Irc8Za4SoaEaYAqQU4vAmYlZyCNxj
EvxXAasffnjR2K3cnZxr
=YkTz
-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

2015-05-07 Thread Jeff Garzik
On Thu, May 7, 2015 at 10:38 AM, Justus Ranvier justusranv...@riseup.net
wrote:

 On 05/07/2015 04:04 PM, Jeff Garzik wrote:
  - This is a major change to the economics of a $3.2B system.  This
  change picks winners and losers.  There is attendant moral hazard.

 This is exactly true.

 There are a number of projects which aren't Bitcoin that benefit from
 filling in the gap left by Bitcoin's restricted transaction rate
 capability.

 If Bitcoin fills that gap, Bitcoin wins and those other projects lose.

 Should decisions about Bitcoin development take into account the
 desires of competing projects?


heh - I tend to think people here want bitcoin to succeed.  My statement
refers to picking winners and losers from within the existing bitcoin
community  stakeholders.

The existential question of the block size increase is larger - will
failing to increase the 1MB limit permanently stunt bitcoin's growth?
--
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

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 05:13:34PM +0200, Justus Ranvier wrote:
 On 05/07/2015 04:49 PM, Peter Todd wrote:
  
  I think we'll find an basic assumption of civility to be more 
  productive, until proven otherwise. (e.g. NSA ties)
 
 I'm not sure why you'd construe my post as having anything to do with
 accusations like NSA ties.

I'm not.

I'm saying dealing with someone with proven NSA ties is one of the few
times when I think the assumption of honest intent should be ignored in
this forum.

Altcoins and non-Bitcoin-blockchain tx systems? Assuming anything other
than honest intent isn't productive in this forum.

-- 
'peter'[:-1]@petertodd.org
0622ff7c71c105480baf123fe74df549b5a42596fd8bfbcb


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

2015-05-07 Thread Jeff Garzik
100% agree, RE hard forks should be hard.

However, it is the paradox of growth, morale and adoption that bitcoin
might never reach the point where it is saturated  expensive to the point
where larger blocks are demanded by 95%+...  simply because people and
companies chose not to adopt bitcoin in the first place due to an unmoving,
[perceived | real] scalability roadblock.


On Thu, May 7, 2015 at 11:04 AM, Alex Morcos mor...@gmail.com wrote:

 That strikes me as a dangerous path forward.

 I don't actually think there is anything wrong with this: everybody
 eventually gets tired of arguing angels-dancing-on-the-head-of-a-pin, and
 we're left with the status quo

 What gives Bitcoin value aren't its technical merits but the fact that
 people believe in it.   The biggest risk here isn't that 20MB blocks will
 be bad or that 1MB blocks will be bad, but that by forcing a hard fork that
 isn't nearly universally agreed upon, we will be damaging that belief.   If
 I strongly believed some hard fork would be better for Bitcoin, say
 permanent inflation of 1% a year to fund mining, and I managed to convince
 80% of users, miners, businesses and developers to go along with me, I
 would still vote against doing it.  Because that's not nearly universal
 agreement, and it changes what people chose to believe in without their
 consent. Forks should be hard, very hard.  And both sides should recognize
 that belief in the value of Bitcoin might be a fragile thing.   I'd argue
 that if we didn't force through a 20MB fork now, and we ran into major
 network difficulties a year from now and had no other technical solutions,
 that maybe we would get nearly universal agreement, and the businesses and
 users that were driven away by the unusable system would be a short term
 loss in value considerably smaller than the impairment we risk by forcing a
 change.



 On Thu, May 7, 2015 at 10:52 AM, Gavin Andresen gavinandre...@gmail.com
 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




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

2015-05-07 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/07/2015 04:49 PM, Peter Todd wrote:
 
 I think we'll find an basic assumption of civility to be more 
 productive, until proven otherwise. (e.g. NSA ties)

I'm not sure why you'd construe my post as having anything to do with
accusations like NSA ties.

By non-Bitcoin projects I mean any altcoin or off-chain processing
solution.

-BEGIN PGP SIGNATURE-

iQIcBAEBAgAGBQJVS4EeAAoJECpf2nDq2eYj/vcQAIUrD+ejUKHQb0k/pcPyzmvy
rl3spbbdLSFN9cBhBOgh5LaVFkCrv4/gW2X4Ih6GGYG3siXjZ2HPDXt+Zbs+bfQE
nrw+IpGTYlbnJ26cFVhZWehr45qY1kMO+DVdnKufEgfVKUdYeq/d3bwL1uru4RU6
UfWihvgGGQkjEb/5ZIpRbWmb7XRP9piZCHi0pgFSa8tNDVjbb9ucKjIfrRuRe+DK
GMhIAQLvIQK4M30SxOnMQLIe3upsQ6JzY+5M28HkcBNKgd0dpZbwByHIJh6/ELTO
Iaf08S0mCySKoZAJFEkeQ3YOgdIlZvwYsflxiEs62Mz9Mz8uuxTo6E21XyFr6iN/
XndXCzlAZBIQuiayEUL4fUM2cmeHcvhHpGNyYjBuLibuiaIzKMBzFQqEZHGA0QzH
QhptbHjTwXLxIEZy94ELH2FbQnTrnOBxOdYfmxGvlmJ0328hThW6N181L3fPHK0v
6zTChZziMhlIoZPX8AGNNsUYJFKBJs/khlbse/tQhXmm5zuIyq+Lt0nKjbhHkWJw
n9y4PHxLVtmmOvptPMm00l5/w6yb8Qmxo81d6kq75ZEupjxupHH6YwjHWTehT/x2
Pt8iMX2NWVnVwVdsaqE/rH+JrgH1Pvl7TMqXMr8d7tuSWTeTBWlrcmZbS1rl0Z3T
f8K2rBX6sBqmrD1xKDsn
=5pB6
-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

2015-05-07 Thread 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

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 10:04:21AM -0400, Jeff Garzik wrote:
 I have a lot more written down, a WIP; here are the highlights.
 
 - The 1MB limit is an ancient anti-spam limit, and needs to go.
 
 - The 1MB limit is economically entrenched at this point, and cannot be
 removed at a whim.
 
 - This is a major change to the economics of a $3.2B system.  This change
 picks winners and losers.  There is attendant moral hazard.
 
 - The core dev team is not and should not be an FOMC.
 
 - The bar for major economic change to a $3.2B system should necessarily
 be high.  In the more boring world of investments, this would accompanied
 by Due Diligence including but not limited to projections for success,
 failure scenarios, upside risks and downside risks.  Projections and
 fact-based simulations.
 
 - There are significant disruption risks on the pro (change it) and con
 (keep 1MB) sides of the debate.
 
 - People are privately lobbying Gavin for this.  That is the wrong way to
 go.   I have pushed for a more public debate, and public endorsements (or
 condemnations) from major miners, merchants, payment processors,
 stackholders, ...   It is unfair to criticize Gavin to doing this.

The hard part here will be including the players who aren't individually
major, but are collectively important; who is the community?

How do you give the small merchants a voice in this discussion? The
small time traders? The small time miners? The people in repressive
countries who are trying to transact on thier own terms?

Legality? Should people involved in 3rd world remittances be
included? Even if what they're doing is technically illegal? What about
dark markets? If DPR voiced his opinion, should we ignore it?

Personally, I'm dubious about trying to make ecosystem-wide decisions
like this without cryptographic consensus; fuzzy human social consensus
is easy to manipulate.

-- 
'peter'[:-1]@petertodd.org
13e67b343b1f6d75cc87dfb54430bdb3bcf66d8d4b3ef6b8


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

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 04:05:41PM +0200, Mike Hearn wrote:
  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.

I quite liked Wladimir's description of what someone with the ability
to merge pull requests into Bitcoin Core is:

@orionwl github.com/bitcoin/bitcoin repository admin, or maybe just 
janitor

-https://twitter.com/orionwl/status/563688293737697281

In any case, we can't force people to run Bitcoin Core - an unpopular
patch that fails to reach consensus is a strong sign that it may not get
user acceptance either - so we might as well accept that centralized
authority over the development process isn't going to fly and deal with
the sometimes messy consequences.

Like I said, you're welcome to fork the project and try to get user
acceptance for the fork.

-- 
'peter'[:-1]@petertodd.org
13e67b343b1f6d75cc87dfb54430bdb3bcf66d8d4b3ef6b8


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

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 04:38:22PM +0200, Justus Ranvier wrote:
 On 05/07/2015 04:04 PM, Jeff Garzik wrote:
  - This is a major change to the economics of a $3.2B system.  This
  change picks winners and losers.  There is attendant moral hazard.
 
 This is exactly true.
 
 There are a number of projects which aren't Bitcoin that benefit from
 filling in the gap left by Bitcoin's restricted transaction rate
 capability.
 
 If Bitcoin fills that gap, Bitcoin wins and those other projects lose.
 
 Should decisions about Bitcoin development take into account the
 desires of competing projects?

Well, basically you're asking if we shouldn't assume the people in this
discussion have honest intentions. If you want to go down that path,
keep in mind where it leads.

I think we'll find an basic assumption of civility to be more
productive, until proven otherwise. (e.g. NSA ties)

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


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

2015-05-07 Thread Gavin Andresen
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


Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 10:52:54AM -0400, Gavin Andresen wrote:
 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.

Would you please explain what you mean by a soft-fork to start
producing bigger blocks

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


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

2015-05-07 Thread 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
 justusranv...@riseup.net 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

2015-05-07 Thread 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

2015-05-07 Thread 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.net/ddm/clk/290420510;117567292;y



 ___
 Bitcoin-development mailing list
 

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Jorge Timón
On Thu, May 7, 2015 at 6:11 PM, Mike Hearn m...@plan99.net 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

2015-05-07 Thread 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

2015-05-07 Thread Wladimir J. van der Laan
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).

I'm weakly against a block size increase in the near future. Some arguments 
follow. For sake of brevity, this ignores the inherent practical and political 
issues in scheduling a hardfork.

Against:

1. The everyone-verifies-everything approach inherently doesn't scale well. 
Yes, it is possible to increase the capacity, within limits, without completely 
destroying the system, but if scaling turns out to be a success, even a 20-fold 
increase is just a drop in the bucket (this will not make a decentralized 
Changetip possible). The gain will always be linear, at a total cost that 
scales in the number of (full node) users times the block size. The whole idea 
of everyone verifying the whole world's bus tickets and coffee purchases seems 
ludicrous to me. For true scaling, as well as decentralized microtransactions, 
the community needs to work on non-centralized 'level 2' protocols for 
transactions, for example the Lightning network.

  I prefer not to rely on faith that 'Moore's law' - which isn't a physical law 
but a trend - will save us. And it doesn't so much apply to communication 
bandwidth as its techniques are more diverse. E.g. for Bitsat, 20MB blocks will 
push the limit.

2a. Pushing up bandwidth and CPU usage will, inevitably, push people at the 
lower end away from running their own full nodes. Mind you, the sheer number of 
full nodes is not the issue, but Bitcoin's security model is based on being 
able to verify the shared consensus on one's own. A lot of recent development 
effort went into making the node software less heavy. Yes, one could switch to 
SPV, but that is a serious privacy compromise. In the worst case people will 
feel forced to move to webwallets.

  That was about sustained bandwidth - syncing a new node from scratch through 
the internet will become unwieldy sooner - this can be worked around with UTXO 
snapshots, but doing this in a way that doesn't completely pull the rug under 
the security model needs research (I'm aware that this could be construed the 
other way, that such a solution will be needed eventually and fast block chain 
growth just accelerates it).

2b. The bandwidth bound for just downloading blocks is ~4GB per month now, it 
will be ~52GB per month. Behind Tor and other anonimity networks, nodes will 
reveal themselves by the sheer volume of data transferred even to only download 
the block chain. This may already be the case, but will become worse. It may 
even become harmful to Tor itself.

3a. The costs are effectively externalized to users. I, hence, don't like 
calling the costs trivial. I don't like making this decision for others, I'm 
not convinced that they are trivial for everyone. Besides, this will increase 
supply of block chain space, and thus push down transaction fees, but at cost 
to *all users*, even users that hardly do any transactions. Hence it favors 
those that generate lots of transactions (is that a perverse incentive? not 
sure, but it needs to be weighted in any decision).

3b. A mounting fee pressure, resulting in a true fee market where transactions 
compete to get into blocks, results in urgency to develop decentralized 
off-chain solutions. I'm afraid increasing the block size will kick this can 
down the road and let people (and the large Bitcoin companies) relax, until 
it's again time for a block chain increase, and then they'll rally Gavin again, 
never resulting in a smart, sustainable solution but eternal awkward 
discussions like this.

4. We haven't solved the problem of arbitrary data storage, and increasing the 
block size would compound that problem. More data storage more storage 
available for the same price - and up to 20x faster growth of the UTXO set, 
which is permanent (more externalization). More opportunity for pedonazis to 
insert double-plus ungood data, exposing users to possible legal ramifications.

For:

1. First, the obvious: It gives some breathing room in a year (or whenever the 
hard fork is planned). If necessary, it will allow more transactions to be 
on-chain for a while longer while other solutions are being implemented.

2. *Allowing* 20MB blocks does not mean miners will immediately start making 
them. Many of them aren't even filling up to the 1MB limit right now, probably 
due to latency/stale block issues. This makes objection 2 milder, which is 
about *worst case* bandwidth, as well as 4, as the end result may not be 20MB 
blocks filled with arbitrary junk.

3. Investment in off-chain solutions 

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Dave Hudson

 On 7 May 2015, at 11:52, Jorge Timón jti...@jtimon.cc wrote:
 
 On Thu, May 7, 2015 at 11:25 AM, Mike Hearn m...@plan99.net wrote:
 I observed to Wladimir and Gavin in private that this timeline meant a 
 change to the block size was unlikely to get into 0.11, leaving only 0.12, 
 which would give everyone only a few months to upgrade in order to fork the 
 chain by the end of the winter growth season. That seemed tight.
 
 Can you please elaborate on what terrible things will happen if we
 don't increase the block size by winter this year?
 I assume that you are expecting full blocks by then, have you used any
 statistical technique to come up with that date or is it just your
 guess?
 Because I love wild guesses and mine is that full 1 MB blocks will not
 happen until June 2017.

I've been looking at this problem for quite a while (Gavin cited some of my 
work a few days ago) so thought I'd chime in with a few thoughts (some of which 
I've not published). I believe the major problem here is that this isn't just 
an engineering decision; the reaction of the miners will actually determine the 
success or failure of any course of action. In fact any decision forced upon 
them may backfire if they collectively take exception to it. It's worth bearing 
in mind that most of the hash rate is now under the control of relatively large 
companies, many of whom have investors who are expecting to see returns; it 
probably isn't sufficient to just expect them to do the right thing.

We're seeing plenty of full 1M byte blocks already and have been for months. 
Typically whenever we have one of the large inter-block gaps then these are 
often followed by one (and sometimes several) completely full blocks (full by 
the definition of whatever the miner wanted to use as a size limit).

The problem with this particular discussion is that there are quite a few 
knowns but an equally large number of unknowns. Let's look at them:

Known: There has been a steady trend towards the mean block size getting 
larger. See 
https://blockchain.info/charts/avg-block-size?timespan=allshowDataPoints=falsedaysAverageString=7show_header=truescale=0address=
 
https://blockchain.info/charts/avg-block-size?timespan=allshowDataPoints=falsedaysAverageString=7show_header=truescale=0address=

Known: Now the trend was definitely increasing quite quickly last year but for 
the last few months has been slowing down, however we did see pretty much a 2x 
increase in mean block sizes in 2014.

Known: For most of 2015 we've actually been seeing that rate slow quite 
dramatically, but the total numbers of transactions are still rising so we're 
seeing mean transaction sizes have been reducing, and that tallies with seeing 
more transactions per block: 
https://blockchain.info/charts/n-transactions-per-block?timespan=allshowDataPoints=falsedaysAverageString=7show_header=truescale=0address=
 
https://blockchain.info/charts/n-transactions-per-block?timespan=allshowDataPoints=falsedaysAverageString=7show_header=truescale=0address=

Unknown: Why are seeing more smaller transactions? Are we simply seeing more 
efficient use of blockchain resources or have some large consumers of block 
space going away? How much more block space compression might be possible in, 
say, the next 12 months?

Known: If we reach the point where all blocks are 1M bytes then there's a major 
problem in terms of transaction confirmation. I published an analysis of the 
impact of different mean block sizes against confirmation times: 
http://hashingit.com/analysis/34-bitcoin-traffic-bulletin 
http://hashingit.com/analysis/34-bitcoin-traffic-bulletin. The current 35% to 
45% mean block size doesn't have a huge impact on transaction confirmations 
(assuming equal fees for all) but once we're up at 80% then things start to get 
unpleasant. Instead of 50% of first confirmations taking about 7 minutes they 
instead take nearer to 19 minutes.

Known: There are currently a reasonably large number of zero-fee transactions 
getting relayed and mined. If things start to slow down then there will be a 
huge incentive to delay them (or drop them altogether).

Unknown: If block space starts to get more scarce then how will this affect the 
use of the blockchain? Do the zero-fee TXs move to some batched transfer 
solution via third party? Do people start to get smarter about how TXs are 
encoded? Do some TXs go away completely (there are a lot of long-chain 
transactions that may simply be noise creating an artificially inflated view 
of transaction volumes)?

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 

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Eric Lombrozo

 On May 7, 2015, at 4:20 AM, Wladimir J. van der Laan laa...@gmail.com wrote:
 
 For sake of brevity, this ignores the inherent practical and political issues 
 in scheduling a hardfork.

IMHO, these issues are the elephant in the room and the talk of block size 
increases is just a distraction.

- Eric Lombrozo


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-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 01:29:44PM +0200, Mike Hearn wrote:
 What if Gavin popped up right now and said he disagreed with every current
 proposal, he disagreed with side chains too, and there would be no
 consensus on any of them until the block size limit was raised.
 
 Would you say, oh, OK, guess that's it then. There's no consensus so might
 as well scrap all those proposals, as they'll never happen anyway. Bye bye
 side chains whitepaper.

If Gavin had good points to make, he'd probably eventually change
everyone's mind.

But if he fails to do that at some point he'll just get ignored and for
all practical purposes won't be considered part of the consensus. Not
unlike how if someone suggested we power the blockchain via perpetual
motion machines they'd be ignored. Bitcoin is after all a decentralized
system so all power over the development process is held only by social
consent and respect.

At that point I'd suggest Gavin fork the project and go to the next
level of consensus gathering, the community at large; I'm noticing this
is exactly what you and Gavin are doing.

Speaking of, are you and Gavin still thinking about forking Bitcoin
Core? If so I wish you the best of luck.

Sent: Wednesday, July 23, 2014 at 2:42 PM
From: Mike Hearn m...@plan99.net
To: Satoshi Nakamoto satos...@gmx.com
Subject: Thinking about a fork
I don't expect a reply, just getting some thoughts off my chest. Writing them 
down helps.

Forking Bitcoin-Qt/Core has been coming up more and more often lately in 
conversation (up from zero not that long ago). Gavin even suggested me and him 
fork it ... I pointed out that maintainers don't normally fork their own 
software :)

The problem is that the current community of developers has largely lost 
interest in supporting SPV wallets. Indeed any protocol change that might mean 
any risk at all, for anyone, is now being bogged down in endless circular 
arguments that never end. The Bitcoin developers have effectively become the 
new financial regulators: restricting options within their jurisdiction with 
someone might do something risky being used as the justification.

If alternative low-risk protocols were always easily available this would be no 
problem, but often they require enormous coding and deployment effort or just 
don't exist at all. Yet, wallets must move forward. If we carry on as now there 
simply won't be any usable decentralised wallets left and Bitcoin will have 
become an energy-wasting backbone for a bunch of banks and payment processors. 
That's so far from your original vision, it's sad.

I know you won't return and that's wise, but sometimes I wish you'd left a 
clearer design manifesto before handing the reigns over to Gavin, who is 
increasingly burned out due to all the arguments (as am I).

Source: https://www.reddit.com/r/Bitcoin/comments/2g9c0j/satoshi_email_leak/

-- 
'peter'[:-1]@petertodd.org
066f25b3196b51d30df5c1678fc206fdf55b65dd6e593b05


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] CLTV opcode allocation; long-term plans?

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 11:05:47AM +0930, Rusty Russell wrote:
 Peter Todd p...@petertodd.org writes:
  That said, if people have strong feelings about this, I would be willing
  to make OP_CLTV work as follows:
 
  nLockTime 1 OP_CLTV
 
  Where the 1 selects absolute mode, and all others act as OP_NOP's. A
  future relative CLTV could then be a future soft-fork implemented as
  follows:
 
  relative nLockTime 2 OP_CLTV
 
 Mildly prefer to put that the other way around.
 
 ie. the OP_NOP1 becomes OP_EXTENSION_PREFIX, the next op defines which
 extended opcode it is (must be a push).

There's no good way to implement that option - when the OP_NOPx is
executed all that's available to it without a lot of complex work is
what's already been pushed to the stack, not what will be pushed to the
stack in the future.

-- 
'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] CLTV opcode allocation; long-term plans?

2015-05-07 Thread Rusty Russell
Peter Todd p...@petertodd.org writes:
 That said, if people have strong feelings about this, I would be willing
 to make OP_CLTV work as follows:

 nLockTime 1 OP_CLTV

 Where the 1 selects absolute mode, and all others act as OP_NOP's. A
 future relative CLTV could then be a future soft-fork implemented as
 follows:

 relative nLockTime 2 OP_CLTV

Mildly prefer to put that the other way around.

ie. the OP_NOP1 becomes OP_EXTENSION_PREFIX, the next op defines which
extended opcode it is (must be a push).

Cheers,
Rusty.

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

2015-05-07 Thread 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

2015-05-07 Thread 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 gavinandre...@gmail.com 
 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