In order to produce larger blocks in the future, we'll need miners to come up with more efficient communication schemes similar to the relay network. This just allows them to produce block space for cheaper and for us to enjoy lower-cost transactions. Win-win.
(Note also that what matters is the network average, and not a few fast connections [although those fast connections do help to lower the network average.])
Peter, you know exactly what that means: centralization. They WILL get bigger and better at it, the code will improve, the costs will slowly be negligible. I'm not concerned with the miners interest but the nodes because they are the ones to whom the costs are externalized. More block space, and cheaper transactions is NOT a win-win. It is in fact a classic tragedy of the commons: the miners and those who wish to fill the block chain with all matter of things in existence have an incentive that cost users access to the governance of the network. I'm referring to a world of SPV wallets absent of privacy and ability to ensure yourself the decentralization of the network. |
|
|
|
He is describe absolutely real and existing mining configurations which promise to worsen in the future given a removal of the blocksize cap.
Then why is the network propagation impedance so high? Answer: because he's talking about something hypothetical (that is unlikely to ever happen and may not even be possible). Lies, lies and lies. You have no shame! You forced my hand here: As a more concrete example, the block relay network today communicates far less than one bit per bit of blocksize to relay a block (e.g. transmitting a 962597 byte block using 3804 bytes-- I wonder why instead you did not announce your discovery that the block relay network has beat the Shanon limit!  --- after all, by your metric it can transmit X bits of information over a channel which has _significantly_ less than X capacity). You assume miners do not have the ability to change their level centralization.
-- In fact they do, not just in theory but in pratice have responded to orphaning this way in the past; and it is one of the major concerns in this space. For example it does not reflect how hashers return work to pools _today_ (and since 2011) as they so to only by referencing the merkel
root... the pool already knows the transaction set. In that particular case it knows it because it selected it to begin with, but the same behavior holds if the hasher selects the transaction set and sends it first.
It only _very_ weakly reflects how the relay protocol works (only the selection and permutation is communicated; not the transaction data itself; for already known transactions). Even if you assume nothing more than that (in spite of the existing reality) you have not shown that the compressed data must be linear in the size of the block.
It does not reflect how P2Pool works (which also sends the transactions in advance). |
|
|
|
No. I will not sugarcoat these ideas because they are dangerous.
Making decisions on the security of a billion $ network based on targeting a certain transaction fee is the definition of "fucktarded"
BIP100 is less fucktardalishous? No, I'm increasingly getting the sense that BIP100 is equally broken. Having miners decide on the blocksize makes no sense from a game-theory point of view. The block size is there to put a check on their ambition. i agree BIP100 and this idea are on about the same level of crazy. The people running nodes have the right to claim decision over the block size as they are the ones to whom the costs are externalized. thats like saying merchant accepting VISA should determine what the fee should be, that's nutty. no. the system should somehow allow for free tx, but encourage users to pay a fee, what better way then say "sorry only room for 10 free TX in this block" and there you go, we have a way to transfer value for FREE but in the end everyone pays the tiny fee...  You've been drinking Adam? Your logic makes no sense. Does the VISA merchants pay for the deployment of the VISA network? If you answer no, as you should, you should realize why your comparison is "nutty". the system should somehow allow for free tx, but encourage users to pay a fee, what better way then say "sorry only room for 10 free TX in this block
That is EXACTLY how it works right now so... why do you wanna change it? |
|
|
|
No. I will not sugarcoat these ideas because they are dangerous.
Making decisions on the security of a billion $ network based on targeting a certain transaction fee is the definition of "fucktarded"
BIP100 is less fucktardalishous? No, I'm increasingly getting the sense that BIP100 is equally broken. Having miners decide on the blocksize makes no sense from a game-theory point of view. The block size is there to put a check on their ambition. i agree BIP100 and this idea are on about the same level of crazy. The people running nodes have the right to claim decision over the block size as they are the ones to whom the costs are externalized. |
|
|
|
The limit determines the size of the consensus network.
If nodes cannot keep up, they will be pushed out.
On one hand, operators of full nodes have the right to decide what the limit should be, on the other hand, there must be a single static limit agreed upon via consensus. Otherwise more important full nodes (large miners, exchanges, merchants) might want to increase their limit via user-definable option and begin pushing home-based full nodes out of the consensus.
8Mb is a reasonable middle point for the next 4 years.
Your post shows exceptional logic and clarity.... until the last sentence. We want to stay as close as possible to actual network demand and there are very reasonable opinions as to why blocks should get filled on average until we precipitate any change. |
|
|
|
These costs, as it has been explained to you repeatedly, are trivial given incremental centralization. In other words miners are incentivized to centralize so as to limit their orphan risks and create larger blocks.
No, Gmax has been hand-waving about some hypothetical future network configuration (that is unlike what bitcoin is or has ever been) that many people with broader knowledge of economics disagree with (assuming it's even physically possible). Right now--based on the average network propagation impedance--it would cost about 4 BTC to produce an 8 MB block, and VASTLY more to produce a 1 GB block (if the limit were removed). Connectivity would have to improve already just to make 20 MB blocks economical... You're lieing and a quick check into your email correspondence with him can confirm. He is describe absolutely real and existing mining configurations which promise to worsen in the future given a removal of the blocksize cap. |
|
|
|
No. I will not sugarcoat these ideas because they are dangerous.
Making decisions on the security of a billion $ network based on targeting a certain transaction fee is the definition of "fucktarded"
BIP100 is less fucktardalishous? No, I'm increasingly getting the sense that BIP100 is equally broken. Having miners decide on the blocksize makes no sense from a game-theory point of view. The block size is there to put a check on their ambition. |
|
|
|
The hardcoding of a blocksize is part of consensus just as they are running the same codebase overall. I question the wisdom of making that part of the code at all. However, it seems that having no limit could be problematic, and as Panther pointed out, miners do want some predictability, which is why I'm liking Bip100 more. Do you know if Jeff Garzik ever considered making it a 51% vote?
Sickpig (forum member here) suggested that the block size limit was a transport layer constraint that crept into the consensus layer. I agree. I don't think we really need a protocol enforced limit because: 1. There is a significant economic cost to producing large spam blocks as an attack. 2. There is a physical limitation to how large a block can be (due to bandwidth and other constraints). 3. The miners can enforce an effective limit anyways. BIP100 seems redundant (and dangerous if it's not based on majority votes). Let's get rid of the limit and let the miners sort it out. These costs, as it has been explained to you repeatedly, are trivial given incremental centralization. In other words miners are incentivized to centralize so as to limit their orphan risks and create larger blocks. "The miners" cannot enforce a limit. Individual miners can "vote" for a certain limit but never enforce it for the whole network. Under no block size cap, smaller miners have no control and can easily be choked out of the network by larger ones putting more hashpower in support of "their" limit. |
|
|
|
The hardcoding of a blocksize is part of consensus just as they are running the same codebase overall. I question the wisdom of making that part of the code at all. However, it seems that having no limit could be problematic, and as Panther pointed out, miners do want some predictability, which is why I'm liking Bip100 more. Do you know if Jeff Garzik ever considered making it a 51% vote?
Sickpig suggested that the block size limit was a transport layer constraint that crept into the consensus layer. I agree. I don't think we really need a protocol enforced limit because: 1. There is a significant economic cost to producing large spam blocks as an attack. 2. There is a physical limitation to how large a block can be (due to bandwidth and other constraints). 3. The miners can enforce an effective limit anyways. BIP100 seems redundant (and dangerous if it's not based on majority votes). Let's get rid of the limit and let the miners sort it out. Ok cool. Let's. Is there a BIP for this? If not, can we create one? fuck ya! miners would simply always include some maximum amount of TX to make sure other miners accept it and keep mining on top of it. https://en.bitcoin.it/wiki/Bitcoin_Improvement_ProposalsPeople wishing to submit BIPs, first should propose their idea or document to the mailing list. After discussion they should email Greg Maxwell < gmaxwell@gmail.com>. After copy-editing and acceptance, it will be published here. We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred. Having a BIP here does not make it a formally accepted standard until its status becomes Active. For a BIP to become Active requires the mutual consent of the community. Those proposing changes should consider that ultimately consent may rest with the consensus of the Bitcoin users (see also: economic majority). No limit is the most guaranteed way to turn Bitcoin into Govcoin and Peter knows this. |
|
|
|
based on the default fee settings. That being said, this doesn't seem like a bad idea at all...
So, a centralized source would declare a "default fee setting", and any time that source decided to change the default fee setting, there would be a new hard fork released that would change the blocksize calculation? No. No need for a centralized source to have a default fee setting, Bitcoin Core has it. From there, the fee could be calculated as per OP's suggestion using a method similar to the fee estimation that already exists on the reference client. Or is this impossible to implement? how about miners determine the fee by voting with the coinbase code thing! they are already in control as to what fee they require to include your TX, so make them vote and take the mean or avg or wtv of the votes, and use that as the "target fee" and have the block size calculation revolve around that. Booya we solved it, call the devs!  lmao That could work, but it would raise again the discussion about "miners already have too much control". And there would be a conflict of interests, I think, as miners profit on bigger fees... Might as well post this here... determining the block size by targeting a tx fee limit is the most fucktarded idea I've come accross with so far.
The future of fees is uncertain, and the possibility of having them raise quite a bit causes discussions on this matter... I'd classify ideas like this as extreme, on the limit. Only the future will tell us if these are "fucktarded" ideas No. I will not sugarcoat these ideas because they are dangerous. Making decisions on the security of a billion $ network based on targeting a certain transaction fee is the definition of "fucktarded" |
|
|
|
There are many alternative currencies that are technically superior to Bitcoin, some have even solved the problems of scalability and some of the aspects of governance. What Where Bitcoin does not exist in a vacuum, you might be willing to spend $100 per transaction but I do not believe that the majority would do so. The majority doesn't matter, I know your brain is poisoned with democracy but that's not how it works. In an economy the people holding the wealth, the rich, decide, whether you like it or not. Especially considering that alternatives do exist where we can transact much cheaper and also with much more anonymity. Therefore it is not a irrational fear to think that Bitcoin should compete with any other alternatives in the real world. Again I ask: What Where (okay maybe Monero for anonymity but their adaptive block size is still very much an experiment AFAIK) I would add financial freedom to this list of core values as well. I think that if we do not increase the block size it will compromise the principle of decentralization. Because reliance on third parties should be seen as a form of centralization. Well at least you get this. How is it you propose then to make everyone reliant on SPV wallets and third party services because they cannot afford to run their own nodes? I do think that it might be jumping the gun a bit, but when I am in a position where I have to choose between 8GB blocks in twenty years from now or keeping the one megabyte restriction in place, I do prefer BIP101 over the Core implementation in this case. We could careless about your decision on a false dichotomy. If there are any problems the block size can be decreased through a soft fork That will never happen for various obvious reasons. Try and understand that I have formulated this position using a realist political philosophy and that from this perspective and discipline of thought, what I am saying is not incorrect.
You've repeatedly made comments that were incorrect. |
|
|
|
Might as well post this here... determining the block size by targeting a tx fee limit is the most fucktarded idea I've come accross with so far.
|
|
|
|
By the way, I'm seeing rising interest of a flex cap which only raises the block size when fee collected in each block is higher than block reward
interesting idea. but to up the 1MB limit, we need fees at ~0.0125BTC ( ~2.5$ ) if you assume 2000tx (~1MB worth) per block. that a pretty high fee! so much for "virtual free transactions." and at that point a shit load of TX wouldnt happen on the network, this method would very quickly make bitcoin no able to handle micropayments. maybe if fee where >1BTC the limit would be pushed up would be more reasonable. Ok then maybe 0.1 block reward is better. Block reward will cut by half next year, so eventually fee will rise pass block reward, it is just a matter of time. Another concern: Block reward halving every 4 years is very drastic. When the block reward get enough small, more and more miners will be shut down, since it does not give miners enough incentive to mine when majority of coins were mined. Since early days of mining, many miners were incentivized to acquire a big enough pie of the total coin supply. But after mining reward cut by half several times, this incentive will not hold, so it is important to have decent fee income to keep the miners on board. I guess at 6.25 btc block reward the fee could be getting close to block reward its not so much the amount of BTC the block reward has that is the incentive to mine as it is the $ value that BTC amount represents. so we'd need to see price double every 4 years to keep miners happy i guess. sounds resnable. for miners to get the most out of the fee's, they should try and target a fee where 80% of current transactions would be willing to pay. you dont want fee's to high, and you don't want them too low, a fee where 80% of poeple agree with ensures the "price is right". so take the avg TX size ( i guess this would be like 0.1BTC??? ) assume 80% of people are willing to pay no more than 1%, and you get a fee of 0.001BTC ~23cents. sounds about right. full 1MB blocks would give them 2BTC full 8MB blocks would give them 16BTC conclusion, the flex cap should only raise the block size when fee collected in each block is higher than : (avg_TX_size_BTC * 0.01 * num_max_tx_pre_block)BTC this idea is pretty cool because its allows miners to collect more fee's based on supply and demand ( available space on each block ) and at the same time we can put a cap on how much they can use this excuse to up the fee. some really indepth evaluation as to what the MAX fee should be before block limit is raised should be thought up tho. this formula needs to consider what the network will need in $ terms to securely sustain itself solely on fees in the future. maybe all this can help solve the question of how big a block should be to strike the right balance between keeping mining affordable and decentralized, and at the same time provide a low cost TXs block limit debate now boils down to: how much mining centralization should we allow in the name of cheep transactions. IMO it should cost ~5cents and mining should be allowed to be as centralized as needed to provide 5cent fees. so i'm now thinking only up the limit when tx fee is (some crazy formula that allows for a MAX fee of 5-10cents) this is annoyingly interesting wasting alot of time here lately  . imagine this the limit is raised and suddenly TX fees come down do 1cent pre TX, maybe the block size should be set lower in that case so that fees are 5cents again. difficulty is retargeted to keep blocks coming out at ~10min intervals block size is retargeted to keep TX cost at ~5cents. Booya, we've solved it call the devs! lmao determining the block size by targeting a tx fee limit is the most fucktarded idea I've come accross with so far. but yes by all means, call the devs!! |
|
|
|
Time to grow up 2) Bitcoin Core
Wants to artificially cap the block size in order to popularize sidechains solution, which by design introduces systemic risks to a single transparent unified ledger, as it intends to take most of bitcoins out of circulation. "Bitcoin Core Released" anagrams to "deliBerate CoeRcions". That doesn't sound very good, does it?
 |
|
|
|
if core stays, XT will be a distant bad memory very quickly.
I concur. If people stay with Core (a solution is implemented), the XT will be forgotten along with Gavin and Hearn. You don't think they'll be welcomed back with open arms do you? Face it, Mike & Gavin are Bitcoin history at this point, a footnote at that. |
|
|
|
By the way, I'm seeing rising interest of a flex cap which only raises the block size when fee collected in each block is higher than block reward
interesting idea. but to up the 1MB limit, we need fees at ~0.0125BTC ( ~2.5$ ) if you assume 2000tx (~1MB worth) per block. that a pretty high fee! so much for "virtual free transactions." and at that point a shit load of TX wouldnt happen on the network, this method would very quickly make bitcoin no able to handle micropayments. maybe if fee where >1BTC the limit would be pushed up would be more reasonable. You are aware that a majority of transactions involving Bitcoin already occur off-chain? |
|
|
|
You make a good point that the miners want to know which blocks will be valid. I guess I'm seeing the wisdom of Bip100 where it can float but does so in an organized manner.
I don't like BIP 100 because it gives too much control over a small minority of miners. BIP 100 also does not address loan term scale-ability issues, but rather kicks the can down the road a little bit (it acts like Congress). I like BIP 101 because it immediately (nearly so) increases the maximum block size (which is needed) and causes the maximum block size to increase over time in accordance with what is roughly the rate of moores law. BIP101's proposed increases are unnecessarily large and also favors large miners. You soft-fork proposition amounts to having miners vote which is IMO never a good idea. At a certain point large miners, which should become the majority, will be incentivized to create as large a block as they can and would veto such attempt to "cancel" the increase. |
|
|
|
What if it increases 5-10x just after the halving (this is just a example; nothing might happen as well)?
I don't want any decision done based on such speculation. |
|
|
|
Blockstream does not decide if changes are made to the Bitcoin core, the community of devs does.
Yes, the blockstream controversy is likely just another conspiracy theory. Along the lines of Gavin being a CIA mole, etc. I think it's just that the "community of devs" often disagree and Wladimir doesn't want to dictate the direction. tbh there's more credibility to the "conspiracy" that Gavin has been compromised by corporate interests than anything related to Blockstream  |
|
|
|
I will believe it when the block size will be increased. Not before. I have absolutely no reasons to trust them. Believe what? Their code is already out in the open. Are you even aware that the last functioning proposal for a Lightning network implementation was created by someone outside of Blockstream? No one's asking you to trust them. I do not trust them to increase the block size, that is why it should be implemented by an alternative client. Unless the Core devs increase the blocksize, I will not trust them to do it. Especially since this has become a fundamental ideological disagreement, since not increasing the block size at all would lead to a very different future for Bitcoin compared to the future that restricting the block size would lead to. Blockstream does not decide if changes are made to the Bitcoin core, the community of devs does. |
|
|
|
|
Show Posts
