The Blocksize Debate & Concerns

[jonald_fyookball]

You mean Peter R Charlatan who came out of nowhere with his "fancy graphics"?

Peter Rizun who presented at the scaling conference and published papers on the fee market.

I will assume you are simply joking and not stooping to the level of Carlton by
accusing those who hold different opinions as scammers.

Peter, Greg, myself, and a few others discussed Peter's paper in the following
thread: https://bitcointalk.org/index.php?topic=1274102.0;all

It's a pretty good read. 

[Carlton Banks]

I will assume you are simply joking and not stooping to the level of Carlton by
accusing those who hold different opinions as scammers.

You are a scammer. You're deceiving people into accepting a damaging proposal you're promoting. Scamming. That makes you a scammer.

[DooMAD]

I will assume you are simply joking and not stooping to the level of Carlton by
accusing those who hold different opinions as scammers.

You are a scammer. You're deceiving people into accepting a damaging proposal you're promoting. Scamming. That makes you a scammer.

It's a shame when people become so entrenched in their views that anyone else who raises concerns, shares a dissenting view or dares to have a difference of opinion is dismissed as a shill/sockpuppet/scammer/liar/etc.

No independent thought, please, people.  That sort of thing isn't tolerated around here.   

For the time being, I'm happy to wait and see what effect segwit has, but I'm still highly dubious it will deliver anything like the gains its proponents are claiming.  I'm even more wary of RBF and it's clear I'm far from being the only one.  If you're not even prepared to recognise people have concerns that they feel are justified (even if you don't agree) then your sole achievement from this point forward will be to further alienate people and reinforce a toxic atmosphere of distrust on both sides.

[jonald_fyookball]

I will assume you are simply joking and not stooping to the level of Carlton by
accusing those who hold different opinions as scammers.

You are a scammer. You're deceiving people into accepting a damaging proposal you're promoting. Scamming. That makes you a scammer.

It's a shame when people become so entrenched in their views that anyone else who raises concerns, shares a dissenting view or dares to have a difference of opinion is dismissed as a shill/sockpuppet/scammer/liar/etc.
 

This guy must be REALLY fun to talk politics with. 

[Peter R]

Peter Rizun who presented at the scaling conference and published papers on the fee market.

I will assume you are simply joking and not stooping to the level of Carlton by
accusing those who hold different opinions as scammers.

Peter, Greg, myself, and a few others discussed Peter's paper in the following
thread: https://bitcointalk.org/index.php?topic=1274102.0;all

It's a pretty good read. 

I always enjoy reading your comments, jonald_fyookbool.  Please consider coming over to https://bitco.in/forum/ once and a while!

On the topic of block-size dependent orphaning risk, I remember when I first released my transaction fee market paper, Maxwell and Co. said that orphaning wasn't a deterrent against larger blocks because miners use Corallo's Relay Network and thus don't suffer block-size-dependent orphaning risk (and then later they said that we can't have bigger blocks because orphaning risk would be too high ... but let's ignore that contradiction for now).

Blockchain.info keeps tabs on orphaned blocks, and I wrote a script to scrape their site and import that raw data into Mathematica. The data goes back about two years and only appears to be missing a gap from last summer.

If the theory that larger blocks actually are more likely to be orphaned than small blocks is true, then hopefully there would be evidence of this in real orphan data. The figure below shows that indeed this does appear to be the case. Orphaned blocks are consistently larger (on average) than nearby blocks in the main chain.



Indeed, miners incur a real cost by producing extra block space; block space behaves like a normal commodity.

[jonald_fyookball]

Uh oh Peter, you better watch out man...you're posting "fancy graphics" again.
Wouldn't want anyone to think you're trying to gloss over the issues here. lol.

My understand of the whole conservation between you, me and Gregory is as follows:


1) The natural fee market depends on orphaning risk.  

2) Greg makes the argument that the relay network prevents
bigger blocks from creating more orphaning risk (
presumably because the time intsensive operations are
done pre-emptively)

3) My counter argument is: Why would the miners continue
to use the relay network if it undermines the fee market?

4) I've seen no answer to that question.

The bottom line is that bitcoin runs by distributed consensus.
We all choose to run the code and follow the rules that make
sense.

The idea that some mining group in the future could start undermining
(no pun intended) network security by publishing blocks
with zero to little fees attached is not much different than
the idea that some mining group today could start undermining
network utility by publishing blocks with no transactions.

It's up to the community to only support pools that are acting
in the best interests of Bitcoin.  You can take this idea of
non-rational mining to the extreme and ultimately you end up
with a 51% attack, regardless of whatever fee market you have
or don't have.

[franky1]

Yes, but they still want to push their socialist free transaction cost agenda, with the side-effect of rupturing the entire network and destroying bitcoin.

But oh well if I can send my transaction with 0 cost, who cares right?

no one has said "free" transactions..
the actual debate is that we should not be pushing for excessive fees today when its not even critical for decades.

the fee:reward ratio changes SLOWLY over DECADES. there is no need to controversially keep block sizes down to force fee's up
because the better option for EVERYONE is to have low fee's to keep bitcoin feeling useful. and to slowly increase capacity which would allow more transactions of low fee's which when combined form a bigger pot of funds to help towards the fee:reward ratio change.

this again for emphasis is not a critical thing to force today.

but lets fiip the debate the other way round..
do you want to force keeping the capacity at only 2500-5000 tx a block. meaning for miners to get $10k a block. the fee needs to be $2-$4 per tx

that mindset would make bitcoin worthless for users not only due to not wanting to pay $2+ but also due to capacity limits irritating people who end up waiting hours-days for a confirm.. thus making people not use bitcoin. thus making there be no fee's for the miners to claim. meaning both users and miners disapear. and bitcoin is dead..

miners dont need fees today..
at the moment fee=bonus reward=income.
that will only flip in a couple decades.. no a couple years, so relax..

so as i said the solution is not fee war and capacity crippling.. but instead slow natural growth of capacity with a tx fee remaining low. so that miners dont get paid via $2 for 5000 people but get paid much less per person but with more people

its the same mentality of crowdfunding..
you dont go chasing a couple people for hundreds of dollars.. you ask hundreds of people for a couple dollars

[Cuidler]

I fear if a fork happens bitcoin's price will crash very hard. So yes everyone votes with his money.

Thats your opinion. I dont see much logic here though, if you mean with fork the same as me, namelly more possible onchain capacity for more possible transactions if miners have enought fee incentive for the increased orphan risk (thanks Peter R for getting hard data to easily viewable form, as usual), I dont see how it can crash the price. Simply saying potentially more people are able to use Bitcoin and full nodes still on home PCs - who would vote against Bitcoin by selling ?

[franky1]

Yea and what about orphan blocks, you just said that by ignoring the side-effects in entirety.

We can measure the risk-reward situation, but we also need to analyze side-effects as well.

Every top-down control system is inneficient since it always ignores sideeffects and unknown sideeffects, so only the market can decide what is best for bitcoin.

http://bitcoinocracy.com/arguments/the-block-size-limit-should-be-constrained-only-by-technology-that-grows-exponentially

http://bitcoinocracy.com/arguments/if-non-core-hard-fork-wins-major-holders-will-sell-btc-driving-price-into-the-ground

I fear if a fork happens bitcoin's price will crash very hard. So yes everyone votes with his money.

your opinion. and it sounds more like scare mongering rather than researched info..
by the way..
https://blockchain.info/charts/n-orphaned-blocks?timespan=2year
this may help..
https://blockchain.info/charts/avg-block-size?timespan=2year

orphans go down as blocksize goes up.

this is because miners have money on the line. they are not going to risk it, instead they are going to look for methods to be more efficient and ensure their work gets paid off..(they learned their lesson in july 2015) and became more efficient afterwards

for instance.. lets say the blocklimit was 2mb today.. pools are not going to jump to 2mb tomorrow... just like they didnt jump to 1mb back in 2013 when it was finally possible to go beyond the 500k DB bug of v0.7-v0.8 era and able to then utilise the  1mb maxblocksize buffer
it was slow natural growth at a pace they deemed safe. at a pace they deemed efficient

[groll]

Hello, I've been in bitcoin for 3+ years now and I would like to share my intellectual opinion about big blocks for bitcoin (2mb ,8mb ,etc) , the Bitcoin Hardfork, and about bitcoin in general and what are the concerns we need to watch out for.

Now there have been many shills, from both sides, so to just clear that out, so I want rational arguments pro/contra big blocks and hardforking bitcoin. I am personally anti-hardfork and therefore anti-big blocks, and I will demonstrate here why it is the best choice in my opinion. So stop shilling, and let's start debating this like civilized adults. I`ll present here my arguments and then you guys can respond to it. The thread will not be moderated so that I should not be accused as a shill. But I hope troll posts or low intellect posts (usually 1 liners) will be removed by forum moderators. Aso remember these are only my opinions from the knowledge I have so if I'm wrong, feel free to correct me, I`m open to criticism!



1) The sacred Bitcoin Protocol

The bitcoin protocol is like a constitution, once you start making changes in it, you will pretty much find yourself in financial tyranny, abuse of power and corruption pretty soon. Whenever things can be changed easily, they will. If there is no resistance to change, they will always happen. Therefore if the bitcoin protocol gets changed only by a small amount, some people will abuse that opportunity, and gradually add more changes, until bitcoin goes off it's original mission, and becomes centralized. Weather that be some sort of filter/blacklist/censoring system, or some sort of other oppressive patch installed into bitcoin. And then bitcoin will fail.

Of course like any constitution, changes have to happen eventually. You can't have the barbarian constitutions of the middle ages rule modern society, even if in the middle ages that was the sacred norm. Changes have to happen eventually, it is inevitable, but it has to be natural, well thought of, and based on real evidence and many many testing.

So in my opinion any change should be at least 1 generational. You don't want to change bitcoin too fast, when it's not even adopted yet by many people. Industry and tech changes too fast nowadays, but you have to slow down so that the clients can catch up. Hard fork is definitely not necessary right now (nor I think it will be in the foreseeable future), because I fear the community is still too young and prone to manipulation, therefore using this 'ring of power' is not an option.


2) Segwit

Segwit is good and necessary to fix fungibility and malleability. As a side-effect, it grows the block capacity as well. It is a temporary solution in terms of scaling the block capacity, because that is not it's goal. It's goal was only to fix malleability, which it probably will to some degree.


3) Sidechains + Lightning Network

This is the path of scaling the Core team choose. And I think it's a very elegant, decentralized approach to scaling. It is one way of doing it, and it's the most easy, immediate and fair way of doing it. Not to mention it's the most secure.

It's not a giant blob of code like ETH+ smart contracts, it's actually isolated from the bitcoin protocol. Security is only good if 1 sector is isolated from another. Think of it as a submarine, if the compartments are not isolated, then if it's breached, the water will sink the entire sub.

From transaction perspective, it can scale bitcoin really bigtime, while adding little or no centralization to the approach. Other 'classical' way would be to add an intermediary to issue IOU bitcoins that could be traded offchain. Well we know that is not an option for decentralization, so the LN is really cutting edge innovation, with little nor no centralization costs to the community.

The transactions will be instant, decentralized or semi-decentralized if you don't host the node, and would be the optimal choice given the current circumstances.

Therefore it is good to have this elegant, secure, and innovative approach to scaling. It also enables new features to bitcoin, that can be used to expand business, economy and other functions.

It is truly a piece of software art, truly crafted by the smartest people on the planet.


4) Urgent Hardfork

Well if the hardfork is really a 100% urgency like if ECDSA gets broken, then it's an urgency, and unfortunately it will have to be implemented. People will not like it, but it will be a true emergency so they will have no choice. However the probability of this is very low.

The more worrysome would be, once the devs have tasted the power of hardfork, then what? What classifies as an urgency? Can they just roll out hardfork every week when an 'urgency' becomes available? We go back to point 1), and how if things get too crazy, it can end bitcoin.

These have to be answered, and the community should always be skeptical.


5) Quantum Computers

I hear this argument many times, and it's mostly fearmongering. What if quantum computers become reality they can break bitcoin...?

Well I personally don't believe in large scale quantum computers, I think they won't ever exist, and there is plenty of evidence that supports this. Yes some laboratory theoretical computers might exist, but there are hard limits of thermodynamics that prevent the existence of large ones.

It's the same nonsense like the free energy advocates that think there is some hidden energy source, when 7th grade physics demonstrates you otherwise.

However classic computers might become one day powerful enough to find some exploit in the crypto algorithms (because brute forcing is obviously nearly-impossible).

And for that we shall react as in point 4). But not sooner than that. Bitcoin doesn't need 'what will happen if' type of patches. Bitcoin doesn't need insurance against alien invasion, we can deal with it, when the threat becomes sizeable.


6) Corruptible miners

What if the miners become untrustworthy? Low probability again, or it will be temporary. Game theory proves us that people working for incentives won't do things that will undermine the incentives. Or in other words people don't bit the hand that feeds them. If miners become shady then either they will run out of money before they can do too much evil, or they will become replaced by the honest ones, that would gain more money from mining honestly. Not to mention if they really piss off the community, everyone will just sell their coins and the mining business, as well as bitcoin will be over. If they implement capital controls to slow down the dumping, then the price will crash to 0 because nobody can buy, just as nobody can sell. Etc.. with many more theoretical attacks, but all end in disaster for the attacker.  So a miner betrayal would only be temporary at best.


7) Corruptible devs

So far we have had very honest reputable developers. What if that changes and we get replaced by corrupt ones?

Well it's like the saying goes, what you reap is what you sow. If the bitcoin community is comprised of programmers , IT experts and PC experts, then you will always find the best ones amongst them that can work on the code. If the bitcoin community will be comprised of morons, then bitcoin will end long before that.

So it's more important to keep the community healthy, because the community will supply the developers and bitcoin experts.

Also the bitcoin developers are decentralized, even if the Core team has control over the github depository, everyone can host bitcoin's source code on his server and work on the code.

The enforcing mechanism in bitcoin is the miners ,and I've explained in point 6) why miners are not prone to betrayal. So the devs incentive is to show his talent, get fame, get donations, and get careers. The miners enforce the rules, while the community decides weather they like it or not.

So if a dev becomes corrupt, he will achieve little, but will lose everything , especially his reputation.


8﴿ Corruptible community

Devs might be corrupt, miners might be, but all of them would be temporary issues. What if the community becomes corrupt?

Yes this is one of the most concerning factors, if the old guard leaves or gets bored of bitcoin, and we get replaced by 80 IQ morons , illiterate people, or just simply opportunists that dont care about bitcoin only want quick profit, then what?

Well this is one of the biggest and most realistic threats to bitcoin. If the community is dumb, it can be manipulated, and divided to be controlled. Everyone will just control the community by their own incentives and whoever can fool the most people will have control over bitcoin. It is a scary possibility.

My opinion would be a moderate adoption, with many tutorials for newbies, as teaching newbies about bitcoin and it's values. People need to feel home in bitcoin and appreciate it's qualities.

Also the old guard should never leave, if they do they are pussies, and whatever happens to bitcoin will be partially their fault. So people should educate newbies and teach them why bitcoin is the way to go.

9) Hardfork not fair for long term savers

Most bitcoin old guard, as well as new investors, want to save bitcoin for long term, usually in a secure wallet. If you roll out hard fork every year, then they will always have to uppgrade their wallets and work with sensitive information, that would expose them to unnecessary risk.

If they don't they can lose their money. What if they are not announced? What if they don't keep up with bitcoin news? You can't just push changes so fast because people will lose confidence in bitcoin's long term future.

If a person wants to put away for his kid's 18th birthday, and forget about that wallet for many years (but keep the private keys backed up and secure), he doesn't want to always be updated with all fixes and patches.

Even other softwares usually have support for 1 version of their software for many years, so why can't bitcoin be the same? It is, and that is how should it be!

So the SET & FORGET approach that most people feel comfortable with, will be violated, and it will upset many bitcoin whales.

10) Hardfork risks the entire network

Currently only 37% of the network runs the latest software, which is good, because if a bug gets discovered the other 67% will act as a backbone.

If you want to force a hardfork then everyone has to uppgrade before the grace period runs out, therefore all the network will have the same version. If a bug or malware gets discovered in the hardforked client, then the entire bitcoin network will be destroyed.

Therefore hardforks are ultra vulnerable to 0 day bugs (or undiscovered bugs). Decentralization should mean that you cannot be 100% confident of the developers, because we are all humans and we make mistakes, so even if the devs have checked the code many many times, you can still not risk the network, because  0 day bugs are very frequent, even in huge projects ( *cought* Ethereum *cought*)

I have been reading this many times and I just cant absorb it all. But whatever happens to mining or the difficulty or the blocksize the miners will continue to mine to earn some more. Its also the same to us bitcoin users even if bitcoins price will fall or rise we cannot but just use bitcoin to earn more cash. In the end its a matter of earning some cash for daily use and purchasing things.

[RealBitcoin]

Yea and what about orphan blocks, you just said that by ignoring the side-effects in entirety.

We can measure the risk-reward situation, but we also need to analyze side-effects as well.

Every top-down control system is inneficient since it always ignores sideeffects and unknown sideeffects, so only the market can decide what is best for bitcoin.

http://bitcoinocracy.com/arguments/the-block-size-limit-should-be-constrained-only-by-technology-that-grows-exponentially

http://bitcoinocracy.com/arguments/if-non-core-hard-fork-wins-major-holders-will-sell-btc-driving-price-into-the-ground

I fear if a fork happens bitcoin's price will crash very hard. So yes everyone votes with his money.

your opinion. and it sounds more like scare mongering rather than researched info..
by the way..
https://blockchain.info/charts/n-orphaned-blocks?timespan=2year
this may help..
https://blockchain.info/charts/avg-block-size?timespan=2year

orphans go down as blocksize goes up.

this is because miners have money on the line. they are not going to risk it, instead they are going to look for methods to be more efficient and ensure their work gets paid off..(they learned their lesson in july 2015) and became more efficient afterwards

for instance.. lets say the blocklimit was 2mb today.. pools are not going to jump to 2mb tomorrow... just like they didnt jump to 1mb back in 2013 when it was finally possible to go beyond the 500k DB bug of v0.7-v0.8 era and able to then utilise the  1mb maxblocksize buffer
it was slow natural growth at a pace they deemed safe. at a pace they deemed efficient

Actually there is no correlation, so i deleted that post.

We either need more data, but i doubt that we have time for that. Also if we increase it to 2mb, and then a lot of ophans will appear, it's not like we can decrease it back to 1 mb.

SO that will be a 1 way deal, therefore if a hardfork were to happen, it should be better tested out and simulated before implemented, because we cant roll back if something bad happens.

[Carlton Banks]

the actual debate is that we should not be pushing for excessive feesblocksizes today when its not even critical for decades.

FTFY


So, the banking shills you represent started flooding the Bitcoin network with low fee transactions simply to push full nodes off the network, and you really expect anyone to believe that the whole charade won't begin all over again if your 2MB2MB2MB wish came true?

You people are slowly beginning to create your own internal bitcointalk echo chamber, you can barely attract anyone to your irrelevant debates anywhere on the internet let alone on this forum. It's going to be nothing but talk (oh, and yours and Peter's pretty pictures, of course), and , as usual, no action.

Do something relevant. With anyone or to anything. I predict you will all fail for, how many times have you failed so far, Frankys? It's easier to count the successes: 0

[franky1]

Also if we increase it to 2mb, and then a lot of ophans will appear, it's not like we can decrease it back to 1 mb.

"alot" is an exaggeration. but as the increase happens slowly and naturally. pools will learn new and better ways to check their work to reduce their risk.
pools wont jump from 1mb straight to 2b of data overnight..

the blocklimit is a BUFFER.. just like the 1mb was a BUFFER when pools were making only 500k in 2013.. slowly rising ,, again SLOWLY rising til this year
so pools from day one of getting the 95%-100% consensus activation would slowly increase to 1.01mb of dta with the 2mb BUFFER enforced

SO that will be a 1 way deal, therefore if a hardfork were to happen, it should be better tested out and simulated before implemented, because we cant roll back if something bad happens.

infact many people already have implementations with the 2mb BUFFER right now. yep, live.. yep receiving and relaying blockchain data of bitcoin, not some altcoin.




as to carlton and his blockstream devotion(a corporation funded using bank money) is the "group" that has the echo chamber of circle jerking to the already converted corporate lovers
ToominCoin aka "Bitcoin_Classic" #R3KT

the real funny thing is blockstreamers cannot pretend they want decentralized independence if they call shill to who is not TEAM blockstream.. which brings me to an earlier point

as for what i have done for the community lol.. well carlton didnt answer my question about if you would do a "REKT" campaign on luke JR when he releases his "independent code" that is not blockstream/core accepted.. so you can just presume what you like about my potential answer too.

the answer is 2 possibilities
1. indeed Luke Jr would receive the noble REKT campaign because it defies blockstream investors contract, and breaches one of the conditions that would release one of the financial tranches.. so ofcourse there has to be a big push to destroy its chances of success
2. carlton will have to backtrack every statement he made and accept luke Jr's code is good and works.

EG its a "marmite" decision. you either love it or hate it..

[RealBitcoin]

as to carlton and his blockstream devotion(a corporation funded using bank money) is the "group" that has the echo chamber of circle jerking to the already converted corporate lovers
ToominCoin aka "Bitcoin_Classic" #R3KT

the real funny thing is blockstreamers cannot pretend they want decentralized independence if they call shill to who is not TEAM blockstream.. which brings me to an earlier point

as for what i have done for the community lol.. well carlton didnt answer my question about if you would do a "REKT" campaign on luke JR when he releases his "independent code" that is not blockstream/core accepted.. so you can just presume what you like about my potential answer too.

the answer is 2 possibilities
1. indeed Luke Jr would receive the noble REKT campaign because it defies blockstream investors contract, and breaches one of the conditions that would release one of the financial tranches.. so ofcourse there has to be a big push to destroy its chances of success
2. carlton will have to backtrack every statement he made and accept luke Jr's code.

EG its a "marmite" decision. you either love it or hate it..

What if the blocksize limit were chosen by each node individually?

Everyone would set the minimum = send and the maximum =receive.

So for example I would send minimum 2 mb blocks (if full), but accept maximum 6 mb blocks.

Would it work? That would make it optional for those with shitty internet to put a cap, but those that have good internet would have bigger cap (but not infinite to defend against DDOS)

[franky1]

What if the blocksize limit were chosen by each node individually?

Everyone would set the minimum = send and the maximum =receive.

So for example I would send minimum 2 mb blocks (if full), but accept maximum 6 mb blocks.

Would it work? That would make it optional for those with shitty internet to put a cap, but those that have good internet would have bigger cap (but not infinite to defend against DDOS)

changing the block limit individually, to reject blocks.. is a stupid thing to do purely for slow connections.. it basically renders the node no longer part of the network
but here is some advice.

limit the number of node CONNECTIONS and you get the desire you want.

EG someone with fast internet can have 50-100 nodes connected. (it used to be termed supernode)
EG someone with slow internet can have 1-6 nodes connected.

the point of the blocksize consensus is that everyone agrees to a certain level.. you may be asking why..
to ensure everyone accepts the same block data. and thus no rejects/orphans due to relays. (there are other ways to orphan but pools can mitigate those other risks as explained before)

so getting to your previous point. if everyone was at 2mb.. they can ALL accept any blocks of 200byte-2000000byte with no issue. meaning a 0.5mb block is accepted, a 1.001mb block is accepted a 1.9mb block is accepted

so by having "block consensus". people only then need to mess around with how many nodes they relay to and from. which can be independent. and a post on another page of this topic pointed out the 37mb/10 minute upload ability of a 0.5mbit internet connection (baseline) shows that even slow internet connections can relay to a few nodes..

by the way its worth pointing this out because even segwit goes upto 4mb(buffer) of REALDATA*.. and if you are thinking of running pruned/no-witness mode, you are no longer a full node so might aswell just run multibit or electrum or other lite clients

now preparing for your rebuttal that not everyone would accept 2mb..
this whole year has been about the 2mb buffer wont be ACTIVATED until consensus is reached. and so it wont make a difference before consensus because noone will make blocks over 1mb before consensus.. and obviously consensus is reached if it got activated which means everyone would be accepting the new buffer

*segwit keeps "base size at 1000000 meaning traditional transactions are at the same 1mb limit.. the extra 3mb is only for segwit witnesses(signatures)
which with a 1in-2out standard tx segwit doesnt offer much more capacity allowance at all, but does allow the capacity trick to be noticeable more if everyone was using multisigs or multiple inputs.. dont confuse segwits 4mb buffer as a "blocklimit" buffer of 4mb for traditional transactions.

[Carlton Banks]

now preparing for your rebuttal that not everyone would accept 2mb..
this whole year has been about the 2mb buffer wont be ACTIVATED until consensus is reached. and so it wont make a difference before consensus because noone will make blocks over 1mb before consensus.. and obviously consensus is reached if it got activated which means everyone would be accepting the new buffer

simple

Far too large a contingent would never accept Andresen, Garzik, and the rest of those cronies as the developers. Because it means 2MB + shill dev team. Not just 2MB on it's own. Fail, Franky.

[Lauda]

What if the blocksize limit were chosen by each node individually? Everyone would set the minimum = send and the maximum =receive.

No that would not work at all. We'd have nodes that have differentiating chain heights which would most likely cause a lot more problems. You can already limit the amount of bandwitdh that you want to spend though (e.g. 'blocksonly' mode).

So for example I would send minimum 2 mb blocks (if full), but accept maximum 6 mb blocks.

Additionally, after some time most blocks will be above the threshold that you set so it becomes ineffective. It just delays the inevitable.

Far too large a contingent would never accept Andresen, Garzik, and the rest of those cronies as the developers.

They used to be good, but now we see them 'contribute' rarely or wrongly (e.g. 'header first mining').

[franky1]

Far too large a contingent would never accept Andresen, Garzik, and the rest of those cronies as the developers.

They used to be good, but now we see them 'contribute' rarely or wrongly (e.g. 'header first mining').

luke Jr's independent code next month.. REKT campaign being prepared by you guys yet??

[Carlton Banks]

I still don't understand what you're talking about Franky

[RealBitcoin]

What if the blocksize limit were chosen by each node individually? Everyone would set the minimum = send and the maximum =receive.

No that would not work at all. We'd have nodes that have differentiating chain heights which would most likely cause a lot more problems. You can already limit the amount of bandwitdh that you want to spend though (e.g. 'blocksonly' mode).

So for example I would send minimum 2 mb blocks (if full), but accept maximum 6 mb blocks.

Additionally, after some time most blocks will be above the threshold that you set so it becomes ineffective. It just delays the inevitable.

Far too large a contingent would never accept Andresen, Garzik, and the rest of those cronies as the developers.

They used to be good, but now we see them 'contribute' rarely or wrongly (e.g. 'header first mining').

I see, the pesky block format is the issue in my opinion. Because it's standardized.

If the transactions were each put arbitrarly in blocks, it would be enough to just verify their hashes to see that they are original,and then there would be no need for the block format.

It would be a very big deviation from the protocol , but it would be interesting to see an altcoin try this.

So then the block sizes would vary, and each node would verify the transaction counts in them, and pass them along eachother.