Also the current beaten state of Monero (€ 2.5 million mktcap) shows that:

- the market never gave any 1%+ chance for Monero achieving anything in the first place;
- anything can make it go up from here, even something totally unrelated to anonymity;
- a very small number of people can keep it in the current value as a community coin, regardless what BTC does.

It was a jump a few months back when it was just an iffy concept - that is a few days ago when 3 of the core devs signed onto blockstream. Now its implementation is all but inevitable (imo). So, no its not much of a jump. It's essentially a recap of the first comment I made in this thread which started people talking about sidechains in the first place.

I'm interested by the sudden appearance of a wizard amongst us, are you trying to encourage a fantasy theme running through the kingdom?

-- This is equivalent to saying there is no reason to use Monero in the first place. Everyone there was there because they believed in a pure anonymous coin and the market it served. However now with that possibility achieved via sidechains, there remains no reason to be in Monero any longer (imo).

My sentiments exactly.  I have actually found this whole thread to be quite heartening.

NewLiberty - you have done a good job tirelessly advocating for a certain approach.  It almost seems as if every even-numbered post is yours, and every odd-numbered post is from a different poster who steps up to the plate to explain to you the flaws in your position.  You seem like a perfectionist, which in general isn't a bad thing at all.  But action is needed now, even if we don't have some perfect 'forever' solution. Fortunately we don't need a 100% consensus to move forward, just an undefined super-majority.  I'd guess we have it around the 20MB / 40% concept.

My personal opinion is 20MB /40% is a kick-ass combo.  Between that, the headers-first downloading, the O(1) miner backbone system, and (hopefully) sidechains, we are looking at the most important set of technical improvements since bitcoin started.

Breaking News: Silk Road shut down, FBI illegally seizes millions in bitcoins, suspected DPR arrested!

Makes sense when SN is dead, doesn't it?

Dangers of lack of trust in administration become apparent in humanitarian crises. If you see your leader as the equivalent of Dada, you probably aren't going to be too willing to accept a mandated injection or even follow basic procedures pushed by their health organizations. Without a free flow of global, neutral communication easily accessible, you're stuck with whatever the government says (with medical care generally an arm of the government), whatever the mass media says, and whatever your neighbors speculate based on what That Guy heard about That Other Guy who prayed to God and was cured by crucifying an albino goat, so if you distrust the government and believe the media just repeats talking points, you better hope you have smart neighbors with a background in infectious diseases.

With recent cures and vaccines, these are things you can't even trust in even if you did have faith in the government. Right now, it'd be a bad choice to take a vaccine, I think, given how few, as a %, are dying. This'll be changing soon as we already passed the point where this could simply be quarantined away, but nobody knows the long-term effects of these new cures and vaccines, and since if an effective vaccine is found, probably everyone in affected areas will be told to receive it if it's mass-produced cheaply. A relatively tiny %death can kill millions, ignoring the possibility of it having a %chance of spreading a mutated form. Given #infected + time = more opportunities for mutations, the probability of of a mutation able to resist whatever comes out to cure or vaccinate against the strain we assume we need to worry about is always increasing, so we have a wicked problem -- the longer a cure or vaccine is tested, the more people will die and the better chance that this becomes an endemic or the cure/vaccine turns out ineffective against a new strain which spread during testing, but injecting without adequate tests can cause more deaths than not injecting - and we can't know which route's better until the governments commit to a plan and see it through.

But clearly some blocks are already full right up to the 1MB limit.  I've been doing transactional systems for 30+ years; the serious trouble will start when the average over reasonable periods of time, e.g. an hour or so but not more than a day, begins to approach ~70%.

http://en.wikipedia.org/wiki/Little's_law

Per https://blockchain.info/charts/n-transactions?showDataPoints=true&timespan=1year&show_header=true&daysAverageString=1&scale=0&format=csv&address=, Nov. 28, 2013 had the most transactions in a day, i.e. 102010.  From https://blockchain.info/block-height/271850 to https://blockchain.info/block-height/272030, i.e. 180 blocks that day, one wonders what the block size distribution looked like.  Gosh, it would be useful to have the size of the pool of waiting transactions at that time.

Per https://blockchain.info/charts/n-transactions-per-block?showDataPoints=false&timespan=1year&show_header=true&daysAverageString=1&scale=0&format=csv&address=, we had an average of 560 transactions per block (only the 8th highest day so far).  Feb. 27, 2014 had the highest average transactions per block of 618 so far.

April 3, 2014 had the highest average block size at 0.365623MB.  Arg, a day is too long.  I just bet the hourly average peaks around 70% of 1MB.

Does *anyone* have a record of the pool or waiting transactions?  That's our key.  When there are ~2,000 transactions in the queue waiting then we would expect a full 1MB block to be coming out next.  When there are ~4,000 transactions in the queue waiting then we would expect two full 1MB blocks to be coming out next.  In this state, transactions can expect to take ~20 minutes to confirm.  ~6,000 waiting -> 30 minute confirmation times.  And so on.

7t/s * 60s/m = 420t/m, 420t/m * 10m/block = 4200t/block.  That does not match observations:  Observations reveal only about 2000t/block.  2000t/block * 1block/10m = 200t/m, 200t/m * 1m/60s ~= 3.3t/s.  Who thinks we can squeeze 4200t/block?  3.3t/s * 86400s/d = 285,120t/d.  Trouble is closer than we thought.  70% * 285.120t/d = 199,584t/d.

Gentlemen, I've seen this too many times before; when the workload grows to somewhere north of 200,000t/d we *will* begin to see the pool of waiting transactions grow to tens of thousands and confirmation times will be well over an hour.

Increase the MAX_BLOCKSIZE as soon as is reasonable.  20MB, 32MB, whatever.  Then enhance the code to segment blocks to exceed the API limit after that.

Thanks for posting this. I sent an email and I encourage others to send it or use it as a template for your own personalized missive to Ben Lawsky.

https://vimeo.com/108437163

What terrible spokesperson these guys are.

"Bitcoin's monetary policy could change" Really !? Just cause you dropped a couple millions on Coinbase certainly does not make you an authority to speak on Bitcoin and utter such nonsense.

This video is so disappointing

You can ignore them. Many US Federal buildings refuse USD and only take credit cards or personal checks.

What is legal tender in the U.S.? To my knowledge only U.S. Dollars are legal tender. It should come as no surprise that bitcoin can't be used to pay taxes. 

1) What is the maximum value for MAX_BLOCKSIZE functionally possible given the APIs being used?

2) What is the maximum value which has been tested successfully?  Have any sizes been tested that fail?

3) Why not just set it to that value once right now (or soon) to the value which works and leave it at that?
       3.1) What advantage is there to delaying the jump to maximum tested value?

No miner is consistently filling up even the tiny 1MB blocks possible now.  We see no evidence of self-dealing transactions.  What are we afraid of?

Heck, jump to 20MB and grow it at 40% for 20 years; that's fine with me *but* be prepared to alter that if there be a need.  How will we know we need to jump it up faster?  A few blocks at the current maximum is hardly a reason to panic but when the pool of transactions waiting to be blocked starts to grow without any apparent limit then we've waited too long.

If government goes for core dev team it will kill it easily. You don't need to attack the application, get people who works on it and you are done.
You don't even need to kill it. Just install enough hooks and backdoors and whole purpose is defeated. No one really checks what is running except few developers, there are no audits or checks and balances to insure code integrity.