Here's a TL;DL transcription:

+1

This:
http://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-26

I have completely opposite view of what is beneficial to Bitcoin (Hint: open discussion and inclusiveness). After reading above I think it's better for me to move elsewhere, where it's possible to discuss openly without a big brother actively warping discussion to his own ends. (Which theymos proudly admits here)

Have fun in your little North Korea.

Yes, that is a social engineering attack, not a hack.

E-mail is not secure, everyone knows it. You should always verify important matters over some more secure medium, preferably multiple ones. Even a phone call would have been enough to prevent this.

That is false and you know it.

People are free to choose. Can you explain to me how is that in any way forcing?
If people don't like his code, then fine. They don't run it and that's it.

You fail to see that absolutely anyone is allowed to fork bitcoin. You, me, your neighbours dog. It's not even a question of debate. It's a hard irrefutable fact. The code is there on GitHub, free to fork and in the end its popularity among the network decides if that fork becomes "the Bitcoin".

Why do you guys have to turn everything into some ridicilous ad-hominems. It sounds like some poor tabloid journalism. It's like people discussing if Snowden/Assagne/Manning is naive/narcistic/criminal/gay/rapist or not instead of discussing the data they have presented us with, which is the only thing that matter. It's the same here. Personalities are irrelevant.

The code is the only thing that matters and people can choose, now and forever, like it or not.

Open source doesn't work like that. The code is OSS and anyone is able to modify it and fork it. Current developers (be it Core, XT or whatever) have no more control of it than anyone else. In the end it's always the network that decides. The control is decentralized and collective.

Only way that some goverment could have it's way is if majority of network accepted it or stubbornly kept running a client that is under govt. control. But at any time they would be free to choose otherwise.

Number of max connections can be set in ~/.bitcoin/bitcoin.conf:

If you are behind NAT it will only use 8 outbound connections unless you open/forward a port (TCP 8333) on your router for it.

Worst thing about synching is that CPU usage. I swear I could have fried eggs on my computer case while it was doing it. Had to actually open the balcony door as I feared it would overheat and shut itself down.

Seems like this bandwidth usage varies a lot. Those numbers for 31 connections were BS as I'm getting more with 20 now. (had some jumps to 25 kB/s) also updated the snippet with with 15-16 connections in previous post.

Maybe I should write a script and let it run for few hours to count averages with connections fixed to some value (I guess this can be set in config file.)

It would give a better idea of the bandwidth needs. I just have to remember not to download any pron while I'm at it.

I'm running one. Currently 31 connections, 5.5 kB/s down 9.2 kB/s up.

[edit] Killed the node while fiddling with it...so now only 15 connections.  Anyway, here's some more numbers.

5 snapshots from download and upload bandwidth:

I don't agree with this. It would be true only if average user runs 90s 56k modem.
Even 1 Mb internet connection works fine. (Though initial sync would take few days, but you only need to do that once.)

My opinion about Chinese nodes (which could take forever to sync due to great firewall) is that bitcoin shouldn't be technically limited due to Chinese government actions. Almost anyone in western countries would be abole to handle full 32 MB nodes right now. Even without a hard limit it would take years before blocks grow that large.

Funny thing is that Andresen would probably support no limit rather than BIP 101.

Core devs won't agree with each other about the scaling proposals (because they have different goals) and Wladimir doesn't make the choice (if such is against his principles), thus there is an eternal lock-up on the issue and they'll move to work on other more interesting issues.

The average transaction rate will just level out at about 0.5 MB/block or half of the current blocksize limit (like it did when majority had 250, 500 and 750kB soft limits).  Some players in the economy will just leave to another projects or quit as they lose their confidence in Bitcoin's ability to grow, which in turn causes price to start trending down. There will be other forks as people get uneasy about about profits and growth getting wasted and Bitcoin will survive.

Really? Well.. no one knows.

Btw. there's now another fork called Bitcoin Unlimited or (Bitcoin U) with no blocksize limit. I just saw it announced on reddit, but can't find the thread anymore (maybe it got deleted).

I think 48h is max. If it's not confirmed by then you should tell CloudMining to resend it. (Maybe with higher fee)

Ok, I must have misunderstood.

How would checkpoints work? (I have no clue)

Does this checkpoint basically hold a checksum of all previous transactions confirming that everything up to this point is true. If network has a checkpoint in it's blockchain (the nodes agree upon it) and you start building on it without validating the whole chain before the checkpoint, then what's the problem?

That is not true.

A pruned node downloads and validates the whole history since the genesis block. (Sync is identical to a normal node) It simply doesn't save it all to disk.

If deadweight loss becomes large enough it forms a majority that will change the protocol as needed.
If not, then part of economy will exit the market.

Why isn't Morning Day 1 video on youtube?

I don't think this Core vs XT setup is constructive at all.

We need to have them both. (and hopefully more)

This creates a chicken and egg problem. Large projects utilizing blockchain are not made because there is no room and the limit is not raised because blocks are not filled to limit.  There simply needs to be enough headroom and a clear schedule for predictability.

Jeff Garzik puts it very well here: https://www.youtube.com/watch?v=TgjrS-BPWDQ&feature=youtu.be&t=12667


My personal opinion is that a blocksize limit is not needed. Simple soft limit set in client config file would be enough. (like 250kB/500kB/750kB soft limits before). You can see from blocksize history that most people just use the default value and the transaction rate increases whenever a new client that ups the default value is released.

Before this schism most of people on BCT didn't even have a clue that a blocksize limit existed. But given how strong feelings it causes now I'd be happy to go with initial 8 MB limit with a predictable schedule. (BIP 101) I just think anything too close to actual blocksize will stifle and slow down the growth of Bitcoin.

So now everyone who has arguments supporting implementations other than Core is a secret service agent working in some hideous plan to destroy Bitcoin?
First it was Gavin and Hearn, and now even Peter R is one of them. Do you really believe this?