Actually I think I'm just going to ignore you and your merry men and get on with more interesting stuff like programming.
Unfortunately some people here are just extremely determined to "rant and shout" in multiple topics in the hope that it will garner support and I am not one of those.
|
|
|
It can be phased in, like:
if (blocknumber > 115000) maxblocksize = largerlimit
Even I can read that. Exactly my point - and if you keep on repeating that change (getting bigger and bigger) then finally the amount of time to even verify all the signatures in your megablocks in 10 minutes will be beyond the capabilities of 99% of the computing hardware available. Now that would be centralisation!
|
|
|
Unfortunately when advocates such as yourself can't actually even read the code then it is easy to see why populists pushing for bigger blocks are getting so much attention.
I would suggest that you watch the recent interviews with Adam Back and Gregory Maxwell and try to learn something (but I know that either you are just too lazy to do that or it would most likely be too difficult for you to grasp anyway).
Technology isn't always so simple (if it was then we would have no need for engineers).
|
|
|
is there a hostile take over if all the developers of blockstream and many people not related to bankers all wanted 2mb..
Of course not - but this is simply not what is happening - so a rather pointless hypothetical.
|
|
|
Claiming that a higher blocksize limit would *increase* centralization is ludicrous on many levels: both illogical (negatively impacts China, where most hashpower lives), and irrelevant (who cares if it's 9 0r 6 bros, they're all buddies anyhow).
It is not ludicrous at all - in order to verify a block (as a full node) you need to verify every single signature. Those operations are not so cheap (my current laptop is actually unable to even keep up with the blockchain because it is simply not fast enough). So the more signature verification operations that are required (which is what you get with bigger blocks) the more potential nodes you are going to lose (as they will simply be unable to keep up). Is this so hard to understand?
|
|
|
adam back releases 2mb segwit, (fully compatible and communicates to lukejr, YOU, jeff, greg)
would that be a hostile takeover, would it be preventing anything in adam backs roadmap ??
You seem to imply that we *need* the 2MB blocks ASAP - yet the evidence for that is non-existent (of course it is being pushed by supporters of those trying to rest control of the project from Bitcoin Core). If Bitcoin Core ends up supporting 2MB blocks it will only be to stop Gavin and others from taking over the project. At the end of the day they might be forced into doing this but I really don't think that this is a sensible way forward.
|
|
|
They can, but they don't. What's your point?
Then blame the hashers rather than the pools. As there are far more hashers than there are pools you'd think that the hashers would perhaps care more about decentralising - but if they don't then there isn't much you can do to fix it.
|
|
|
BTW - notice that @franky1 *still refuses to show us his code*.
Does anyone on this forum actually believe the guy *can code*?
(other than function declarations in VB)
|
|
|
... increasing block sizes will actually end up centralising the mining more than anything else ...
How is this still a thing, when 9 guys control >90% of the hashpower? If you are talking about pools then you should know that the hashers can change pools at any time.
|
|
|
would that too be a hostile take over? or just moving forward and allowing decentralized implementations
There is a very good reason that the people you listed (apart from the last one) don't do that. That is because they know it is really of no benefit to the future of Bitcoin just to increase the block size.
|
|
|
maybe you need to start staying ontopic and answering questions technically. after all you are not attacking what i said about my post above about technology in 20 years etc.., you prefer to not talk about the ontopic stuff and just call me and other people shills..
Post "the real code" then @franky1 - quite frankly I am sick of your nonsense. BTW - I have received PMs from quite a few people thanking me for "calling you out" for being someone who says they can write code yet is unable to actually produce any such code that they have written. (so you are not getting away with it as you might have hoped)
|
|
|
Yes. I'm saying that's the right move. Satoshi never intended for the blocksize to be a consensus rule. We need to keep the code as simple as possible, the changes as conservative as possible. I have already made the arguments over and over.
Satoshi left - and he also left a number of flaws and issues with Bitcoin that he didn't have any answers for - so please stop your appeals to authority with him already. The reason core doesn't move to 2MB now is because it would be detrimental to blocksteam. Why is that so difficult for people to understand?
That is not the reason at all - as has been explained the "simple fix" of increasing block sizes will actually end up centralising the mining more than anything else as the time require to just verify all of the sigs will easily take more than 10 minutes unless you have extraordinary hardware.
|
|
|
2MB blocksize is the answer for now, it will be good for 2 years top, and then what? Will they agree to increase blocksize progressively or by constant number?
It is not the answer for now at all - it is an attempt at a hostile takeover of an open source project.
|
|
|
Everyone in their right mind knows that a 2MB hardfork is the right move at this juncture.
But until the business politics and corruption is exposed (and corrected), core will continue its perpetual circle jerk.
Seriously - you stoop to saying that anyone else is "not in their right mind". Why not actually try and argue about things technically rather than acting like a shill? I have already shown that @franky1 is a fraud as he can't prove he can code for shit (he can still try and show us his amazing VB "Bitcoin for dummies" code to prove me wrong whenever he likes). So I would not recommend paying any attention whatsoever to his "technical arguments" (they are just nonsense being spouted by someone that doesn't even understand how Bitcoin works).
|
|
|
140k Telsa bought with Bitcoin 2 days ago
What exactly is a Telsa? (OP please fix the spelling mistake in your topic's title)
|
|
|
Aren't we supposed to have hundreds of millions of users by then? That takes care of the incentive thing.
If we tried to scale Bitcoin by just increasing the block size then basically only a few huge data centers in the world would be able to even verify such gigantic blocks in ten minutes. So no (you have clearly misunderstood how Bitcoin works). If you support decentralisation then you should not be supporting huge block sizes.
|
|
|
Just look how micro-transactions will stop working. Isn't that one of the pillars of bitcoin?
No - it never was - back in 2012 Gavin was interviewed along with Amir and it was Amir who stated that Bitcoin was suitable for micro-transactions and immediately Gavin chimed in that it actually was not. The Satoshi design is never going to be suitable for micro-transactions (unless you want to use far less secure alts of course). Seriously - once the block reward has dwindled to very little what incentive do miners have to continue to mine if the tx fees are ridiculously low?
|
|
|
Last i read you should be able to change the whole tx which was kinda problematic because of double spending.
Oh - I hadn't realised this was the case (that makes me rather less enthusiastic about RBF - I can now envision someone creating a wallet with a "double spend" button). I dont see a link between broken ecdsa and rbf.
A double-spend attempt is a double-spend attempt but perhaps the attempt itself is made easier with RBF.
|
|
|
I think for now core should increase blocksize to 2MB and put all experimental implementations on back burner.
I think the OP is correct in stating that block size is not a "requirement" but just an implementation detail (so why we have a whole lot of people who are not even software engineers arguing about implementation details is strange unless those people are actually shills). Also - Bitcoin itself is still "experimental" so increasing block size is not without potential problems as well (such as nodes not being able to actually verify all the signatures in ten minutes).
|
|
|
My understanding was that RBF doesn't let you change the tx other than effectively its fee (i.e. inputs could be added but not outputs) - did I miss something?
|
|
|
|