the blocksize debate is going on for years now. many people think it shouldnt change even if transaction backlog starts to grow. and now you are telling me that its just fear mongering when i say its nearly impossible to change the bitcoin protocol? c'mon... i didnt say that the whole world will adopt bitcoin tomorrow. i think its just shortsighted to think an algorithm would work. and "cross the bridge when we come to it": well you want to change a p2p system without warning its users beforehand? a protocol change needs time... if the utxo is 1gb its too late  The more important point here is that to prepare Bitcoin to handle the transactions needed in the event of adoption on the scale you propose we'd pretty much have to lift the limit entirely. I think I have demonstrated in the previous post why that is not quite an option. you have demonstrated that bitcoin is doomed to get centralized even with 1mb blocks. we already see the first signs - even with a huge blockreward. i told you the only solution i see (home mining): which has nothing to do with blocksize. Mining centralization is somewhat of a mixed bag. While it will happen given the inherent economies of scale the most important thing is that we have a strong and diversified network of nodes who can put a check on these miners. That's essentially what they're for. Without a blocksize you pretty much leave the nodes to the mercy of miners. |
|
|
|
the blocksize debate is going on for years now. many people think it shouldnt change even if transaction backlog starts to grow. and now you are telling me that its just fear mongering when i say its nearly impossible to change the bitcoin protocol? c'mon... i didnt say that the whole world will adopt bitcoin tomorrow. i think its just shortsighted to think an algorithm would work. and "cross the bridge when we come to it": well you want to change a p2p system without warning its users beforehand? a protocol change needs time... if the utxo is 1gb its too late The more important point here is that to prepare Bitcoin to handle the transactions needed in the event of adoption on the scale you propose we'd pretty much have to lift the limit entirely. I think I have demonstrated in the previous post why that is not quite an option. |
|
|
|
Home mining is destined to be a thing of the past. Even the most dedicated hobbyist will be run out of the game. You can't imagine a situation where they will stay relevant and therefore by looking for their own best interest will put a check on large scale operations. That's just not how it works.
i dont think any big mining cooperation can compete with millions of home-miners which mine using a by-product because they need the heat. because they can mine for freeThat's very cool. Unfortunately these do not exist yet. Until they do we will need a limit on the block size. |
|
|
|
But of course it has to do with blocksize.
Blocksize is a check on economies of scale so as to level the playing ground. It is absolutely necessary while Bitcoin is still relatively small. Without it the entities with the most resources will make use of the technology available to run out of the market any smaller players.
that is only true if the entity with the most resources has more than 51%. otherwise i expect smaller players to team up in such cases and ignore blocks as soon as a big player start to behave badly. it is in their best interest to do that. we can see this with: most home miners go to the biggest pool like flies going to the brightest light. but - until now - whenever a pool got to much hashing power the community realized that it is bad and hashing power got more distributed again. You don't seem to grasp the impact of this. In this outcome there is no "smaller players". There is an unlimited amount of capital which can and WILL be leveraged to install hashing facilities that can and will accept big blocks. The competition in that scenario is not between large miners and smaller ones, it's between large miners only. What you get is a handful of giant corporations running mega mining operations coupled with node datacenters that essentially make smaller players irrelevant. Home mining is destined to be a thing of the past. Even the most dedicated hobbyist will be run out of the game. You can't imagine a situation where they will stay relevant and therefore by looking for their own best interest will put a check on large scale operations. That's just not how it works. |
|
|
|
It seems to me you are making two assumptions that do not appear necessarily true to me.
The first is that propagation times are not subject to change (improve). What happens when IBLT is implemented and propagation is constant? There are a handful of other improvements that can decrease propagation time and it WILL get worst as big miners improve connectivity between each other. The incentive to mine smaller blocks then kind of disappears and so does the cost to publish larger blocks to a certain extent.
true, also the (existing) miners-overlay-network which is used by most pools already submit headers first. - still, miners have to validate transactions - they have to receive it (ok its hard to not receive something) - they know that if they allow small fee transactions they'll get more small-fee transactions in the future. this seems to be a prisoners dilemma while its not: they rely on bitcoin to continue to exist, because they are invested in it and no company would destroy their own market. Second is a most common fallacy that suggest all miners are the same, that their decisions can be projected as a group and not as individuals. That is absolutely wrong. Cost per transactions differ from one miner to the others and bigger miners will have incentive to mine bigger blocks and eventually suffocate smaller miners who cannot keep up with their resources.
yes and thats bad. but i dont think this has much to do with blocksizes. atm most mining is done in china for this exact reason: this wont change with bigger blocks. imho: in the long run bitcoin can only stay decentralized when many households have a miner at home. eg an electric heating device (preferably solo with a bitcoin node integrated in any router; bandwidth subsidized by telco like many do with their video-platforms [at least in germany]). we just need devices which mine as a by-product. But of course it has to do with blocksize. Blocksize is a check on economies of scale so as to level the playing ground. It is absolutely necessary while Bitcoin is still relatively small. Without it the entities with the most resources will make use of the technology available to run out of the market any smaller players. What you are proposing is indeed interesting but we can absolutely not make decisions based on such abstract potential. |
|
|
|
The issue with a large increase is it creates a slippery slope. Raising the blocksizing is essentially subsidizing transactions. If we persist on doing that someone WILL take advantage of the free space. Now what happens if 8MB blocks get filled up way before the intended increase? It is not an improbable scenario that we could see bigger block get filled surprisingly quickly & the increase will have been more or less for nothing.
miners have an incentive to make smaller blocks as they are transmitted faster and reduce their orphan rate. so they wont include no-fee-transactions forever. as blockreward gets reduced miners are forced to calculate their cost per transaction (cpu and bandwith wise) they wont allow freebies. It seems to me you are making two assumptions that do not appear necessarily true to me. The first is that propagation times are not subject to change (improve). What happens when IBLT is implemented and propagation is constant? There are a handful of other improvements that can decrease propagation time and it WILL get worst as big miners improve connectivity between each other. The incentive to mine smaller blocks then kind of disappears and so does the cost to publish larger blocks to a certain extent. Second is a most common fallacy that suggest all miners are the same, that their decisions can be projected as a group and not as individuals. That is absolutely wrong. Cost per transactions differ from one miner to the others and bigger miners will have incentive to mine bigger blocks and eventually suffocate smaller miners who cannot keep up with their resources. |
|
|
|
You're missing the point. What in heaven's name justifies implementing 8GB blocks? By your logic, we can just have 64GB blocks and even more prohibitive costs to running nodes. After all, who cares, right?
Certainly, current transaction volume doesn't suggest this is necessary at all. Why aim for Moore's Law? Let's observe how robust scalability is on a more conservative basis, and keep limit increases in line with actual transaction growth (rather than this fantasy that Moore's Law = bitcoin adoption rising exponentially, endlessly).
i am not suggesting going to 8gb blocks now... 8mb and doubling every two years as with a lower soft-limit is good... Maybe you can address this? The issue with a large increase is it creates a slippery slope. Raising the blocksizing is essentially subsidizing transactions. If we persist on doing that someone WILL take advantage of the free space. Now what happens if 8MB blocks get filled up way before the intended increase? It is not an improbable scenario that we could see bigger block get filled surprisingly quickly & the increase will have been more or less for nothing.
If we take the decision to continue subsidizing transactions right now because of pressure from certain groups we will inevitably create a precedent and reinforce the belief of users that they somehow have a RIGHT for block space and therefore make it forever more difficult to refuse it. Imagine the subsequent pressure if Bitcoin grows by a couple orders of magnitude and users start seeing their transaction fees go up when they were told it would forever be nearly free.
This here is an opportunity to put a check on these false expectations and discourage business plans that were planning to unnecessarily fill up the blocks w/ their own transactions. People need to understand that there is cost to having this system run securely and we should stop trying to externalize them.
|
|
|
|
Unlike your opinion, hardware evolves you know  That's very cute, but it's not an adequate response. Firstly, yes, hardware evolves. At what rate over time, and when does the exponential trend end? We don't know. Moore's Law is an unscientific observation -- a theory -- and one that is breaking down: http://thenextweb.com/insider/2015/07/16/intel-quietly-admits-that-its-struggling-with-moores-law/Further, if block size capacity is inadequate, it is linked to growth in transaction volume and thus, network adoption. Why is this [unproven, unscientific] theory regarding growth in processor capacity being used as a basis for predicting bitcoin adoption? It's already quite a leap to say that growth rates in processing capacity are uniformly applicable to all technologies.....But then to try to take it much further even, and apply that logic to a network of people? Very basic logical failures. Those who act like we can plan for all contingencies today in regards to hardware and bandwidth advancements, network security in the case of exponentially increasing block size, any the many problems that will come along whether we have thought of them or not are fooling themselves. It seems many fancy themselves visionaries around here -- but I don't see the foresight to warrant it. if we would have 8GB blocks right now you can have that: - run your own node on a server (eg hetzner 50€/month+300€ traffic) - run electrum-server there - use electrum from home to connect there which basically means it is possible RIGHT NOW. eg even if you think that bandwith doesnt change for the next years at all bitcoin would still be usable. ofc not anybody could afford 350€/monthly. but they might just use spv clients Are you sure about this? Do you have tests to prove it? http://log.bitcoin-assets.com/?date=19-08-2015#1244354 |
|
|
|
^ you're on ignore btw
And I'll be putting you on ignore along with all the greedy elitist-chain parasites quoted here once larger blocks are implemented and your agenda becomes a lost cause. I'd block you now, but in order to call out the BS, I need to be able to see it. well damn I couldn't ask for more than to be enshrined alongside such Bitcoin visionaries. go right ahead ! |
|
|
|
The longest proof of work chain is the consensus mechanism.
You keep spreading this falsehood. While it is not exactly wrong, it's not perfectly right either.
Not really. "the longest chain" is ambiguous. It should really be "the longest valid chain", and then you need to define which coin's concept of "validity" you're using. Every client follows the longest valid chain - that's precisely how they decide which chain to follow.
So assuming the question is "will my node follow the longest valid Bitcoin chain?", then the answer is "no" for XT once BIP101 is activated. At that point XT stops following the longest valid Bitcoin chain and starts following the longest valid XT chain, whereas the answer is "yes" for Bitcoin.
 It's my understanding that neither of these assertions is true in Bitcoin XT. XT changes the consensus mechanism significantly: Another less cited new feature of the XT client is a change to chain selection/consensus rules. XT clients don't follow the longest chain, they follow the chain with the highest XT checkpoint embedded into it.
Exactly what is a checkpoint and how is it embedded in the blockchain? How does the XT wallet decide which chain to embed a checkpoint into, and how does it decide what height to embed a checkpoint at? How does the XT wallet decide the frequency and time to embed checkpoints at? There is only one thing you really need to know: checkpoint is not Bitcoin. Checkpoint is an attempt a rewriting history. One of Hearn's favorite tool. |
|
|
|
The longest proof of work chain is the consensus mechanism.
You keep spreading this falsehood. While it is not exactly wrong, it's not perfectly right either.
Not really. "the longest chain" is ambiguous. It should really be "the longest valid chain", and then you need to define which coin's concept of "validity" you're using. Every client follows the longest valid chain - that's precisely how they decide which chain to follow.
So assuming the question is "will my node follow the longest valid Bitcoin chain?", then the answer is "no" for XT once BIP101 is activated. At that point XT stops following the longest valid Bitcoin chain and starts following the longest valid XT chain, whereas the answer is "yes" for Bitcoin.
|
|
|
|
This post shows the probability that BIP101 becomes the longest chain is 0: "We believe a substantial part of full nodes right now would not be able to support blocks of this size simply because of hardware limitations. Similarly, we do not support propositions to fork client software as we believe this move may have potential negative consequences for the entire bitcoin ecosystem. - Valery Vavilov BitFury
Unlike your opinion, hardware evolves you know I'm sure you are qualified to speak hardware with the folks at BitFury. I suggest you go ahead and write them an email and try to change their mind. Until then... #REKT |
|
|
|
There should be more than one implementation of the bitcoin protocol.
Also, there might be legitimate use cases for "enterprise" style full nodes etc.
I could think of a thousand reasons why XT could be useful, but the most important ones will likely be the ones I can't imagine right now.
Exactly. What is wrong with the goal of decentralizing development across multiple competing implementations?  I'm just going to quote myself since you didn't seem to bother replying in the other thread. 2. You absolutely don't understand or are being willingly misleading about this "centralization" issue. There is quite simply no other choice but for us to support a centralized (read unique) consensus code. That's pretty much the only way Bitcoin works. It happens that the core developers have historically been the one trusted with maintaining this code and updating it. Several implementations have been built around this consensus code. Most of them have little support for very valid reason: their implementation is generally considered less tested and therefore potentially less secure than core implementation. Now should we blame core for attracting the most competent developers in the space? Would it be rational to ask of them to each start dividing their work between different implementations just for the sake of "decentralization"?
The centralization issue you refer to is nothing more than a lack of man power. That is, only a scarce amount of people are reliable and technically able enough to handle the highly fragile development of Bitcoin. It is no wonder the guys currently leading core are some of the world's most advanced experts in their own field. This expertise cannot be easily replaced or dismissed "because decentralization". It is absolutely unproductive and irresponsible to try to advance decentralization of Bitcoin development by encouraging incapable people to start messing around with their own implementations and risk breaking consensus.
|
|
|
|
This post shows the probability that BIP101 becomes the longest chain is 0: "We believe a substantial part of full nodes right now would not be able to support blocks of this size simply because of hardware limitations. Similarly, we do not support propositions to fork client software as we believe this move may have potential negative consequences for the entire bitcoin ecosystem. - Valery Vavilov BitFury
|
|
|
|
So... you're getting get 2MB, not much more. I hope this can satisfy your urge for transactions!
Wait... So you are now on our side  How did that happen? On the road to Damascus? Someone call cointelegraph.com - "brg444 in pro big block shocker"  There is a distinction here. It's going to be bigger blocks, nothing outrageous like 20mb or 8mb the XT team was pushing for.
I'm not sure you can find a post from me here arguing we should keep block size at 1mb forever but feel free to looks into my post history if you care. You are now going through the denial phase of your grief. hhhrrrmmfff... I never said I was against bigger blocks... Some of my best friends are bigger blocks... hhrrrmmppff Lambchop are you not satisfied trolling the speculation section you have to spread your ignorance here as well?  |
|
|
|
Also, unlike the childish rethoric of poors vs rich or smallblockers vs. blockstream brought to you by very naive people, Mike & Gavin have pretty much revealed themselves as indeed very dangerous for Bitcoin. That's a difference and it needs to be addressed. AFAIK none of the small blocks proponent have put the ecosystem at risk like these two clowns did.
Yes, XT has already lost:
You continue to be a source of comedy gold. You have been played for a fool, and now you are out on your own, alone, with nothing to fight. The debate will continue without you - we are now deciding what size the increase will be. We? It seems to me team Blockstream is leading the debate as we speak! Who do you represent? The 8MBers? Ewww. You may be right, this block size capitulation makes their humiliation complete For your argument to make any sense you'd have to present actual proofs that the developers were ever against increasing the block size and swore to keep 1mb forever
|
|
|
|
So... you're getting get 2MB, not much more. I hope this can satisfy your urge for transactions!
Wait... So you are now on our side How did that happen? On the road to Damascus? Someone call cointelegraph.com - "brg444 in pro big block shocker" There is a distinction here. It's going to be bigger blocks, nothing outrageous like 20mb or 8mb the XT team was pushing for.
I'm not sure you can find a post from me here arguing we should keep block size at 1mb forever but feel free to looks into my post history if you care. |
|
|
|
Also, unlike the childish rethoric of poors vs rich or smallblockers vs. blockstream brought to you by very naive people, Mike & Gavin have pretty much revealed themselves as indeed very dangerous for Bitcoin. That's a difference and it needs to be addressed. AFAIK none of the small blocks proponent have put the ecosystem at risk like these two clowns did.
Yes, XT has already lost:
You continue to be a source of comedy gold. You have been played for a fool, and now you are out on your own, alone, with nothing to fight. The debate will continue without you - we are now deciding what size the increase will be. We? It seems to me team Blockstream is leading the debate as we speak! Who do you represent? The 8MBers? Ewww. |
|
|
|
It's not fully over yet. The big spam attack still has to happen in september, it may cause panic again and get some random newbies that are clueless supporting XT or BIP101. Only after the spam attacks are over we will be able to say the hijacking attempt is over and buried, until then lets keep our eyes open.
It is over. A majority of the mining network is now backing BIP100 and a certain significant portion are outright against 8MB increase. BIP100 is still vaporware and the industry (market makers and payment processors) are still firmly supporting BIP101 which have a functioning code already. The race isn't over at all. Read above, BIP101 is broken. Bitfury is against it. It has near epsilon chances of getting adopted. Better get with da program! BIP100 is getting a formal proposition in probably no later than two weeks. Decision will likely hang between this and Gmax's yet-to-be-seen flex cap proposal. |
|
|
|
|
Show Posts
