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. |
|
|
|
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? maybe so, wtv its just a though, i still think its cool to allow free TX however slow, and have blocksize grow such that this slow free TX is always possible. thank you for your input, as fucktarded as it is. |
|
|
|
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.
not sure how you can be into bitcoin, and at the same time be as closed minded as you are. |
|
|
|
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). |
|
|
|
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? 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 |
|
|
|
|
if we keep the 1MB limit fees go up but mining is easy even with a really crappy internet connection "more decentralized higher fee"
if we up the limit to 32MB fees remain unaffected (very low) but you need a reasonable internet connection to mine "more centralized lower fee"
what if we could use the block limit to make sure fees are always ~5cent
if the avg fee is <4 cents lower the the limit
if the avg fee is >6 cents up the limit
simple enough.
this way block limit will increase with demand and is sure to be as low as it can be to allow for free TX being processed but free TX will always take alot of time because most blocks are filled with TX that have a fee, and that's the reason poeple pay fee to make sure they get confirmed ASAP.
the balance between decentralized and low fees is always such that free TX are slow but possible
cool no?
|
|
|
|
|
green means go, buy Buy BUY!
|
|
|
|
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 |
|
|
|
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 |
|
|
|
Let's look at the symbols. 1) Bitcoin XT Allows the block size to increase exponentially to the point, where home-based nodes will no longer be able to participate in consensus. Wanna vote yourself out of Bitcoin? Great, this way! Head for the >> (e)X(i)T (check the actual logo). 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? 3) Bitcoin as Satoshi created it. Doesn't have any suffix, prefix or any other strings attached to it. That's the one that has a static limit on block size baked in, but big enough not to limit Bitcoin's growth until it is reached. I argue, that the path of the original true Bitcoin is the one, where static limit is raised to 8Mb. If we look at the table below from the perspective of a block size increase, we will see one simple truth: Option Action Result Bitcoin XT CHANGE CHANGE Bitcoin Core NO CHANGE CHANGE Bitcoin CHANGE NO CHANGE Sometimes things need to change in order to stay the same. Note, that option [NO CHANGE -> NO CHANGE] doesn't exist, that's how evolution is built into the system. Do we always need celebrity figures to provide it for us, to spoon-feed us everything we need? How many of you have built the software you are running? The instructions are out there, it's not rocket science. The path has been shown. Are you the ones to walk the talk? Time to grow up. Great, let's do the one simple change. If this post gets enough exposure, can we finally put the huge, forking mess to rest? i figure all we need is one dev to read this, then he will tell all the other devs, a few epiphanies later one line of code will be changed. |
|
|
|
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. |
|
|
|
... a jr. member makes more sense than the devs. ...
"a plaque and platinum status is whack if you're not the baddest"  By the way, I don't think that devs' i ntentions are anything else than good, but their judgments may have been overshadowed. A few millions in cash will do that to pretty much everyone in our demographic. So, they are welcome to finally see the truth and help propel Bitcoin onto the next stage of evolution. agreed, but good intentions, never did anyone any good. i'll take a bad solutions over good intentions anyday. |
|
|
|
its really sad when a jr. member makes more sense then the devs. a dead simple to solution, temporary? sure, if you consider fixed for years (aka the foreseeable future) temporary...
come on devs, think for 1 hour then change one line.
not a sad as a legendary member backing the killing of bitcoin by an alt. who's that? my bad misread n deleted k, if anything is going to kill bitcoin it will be an array of forks forced out by the core dev team's indecision. XT was a warning, time is running out. don't completely disagree, but don't see such an immediate rush needed. but if XT is adopted there will be a war. if core stays, XT will be a distant bad memory very quickly. i think everyone can live with being ~12 months away from constantly hitting the block limit on every single block. but we could see some new blockchain application which pushes us up to this point much faster, at that point core dev needs to do something fast or forks will come, then suddenly "what is bitcoin" becomes ambiguous, if there is a fork 2 version of bitcoin have ~50/50 hashing power, you might think price would cut in half, i think fungibility, and ease of use would go down the drain along with price. now imagine 3 bitcoins! what a mess! |
|
|
|
its really sad when a jr. member makes more sense then the devs. a dead simple to solution, temporary? sure, if you consider fixed for years (aka the foreseeable future) temporary...
come on devs, think for 1 hour then change one line.
not a sad as a legendary member backing the killing of bitcoin by an alt. who's that? my bad misread n deleted k, if anything is going to kill bitcoin it will be an array of forks forced out by the core dev team's indecision. XT was a warning, time is running out. |
|
|
|
its really sad when a jr. member makes more sense then the devs. a dead simple to solution, temporary? sure, if you consider fixed for years (aka the foreseeable future) temporary...
come on devs, think for 1 hour then change one line.
not a sad as a legendary member backing the killing of bitcoin by an alt. who's that? |
|
|
|
|
its really sad when a jr. member makes more sense then the devs. a dead simple to solution, temporary? sure, if you consider fixed for years (aka the foreseeable future) temporary...
come on devs, think for 1 hour then change one line.
|
|
|
|
Via this tool Satoshi Nakamoto's vote would have a lot of weight and other very rich Bitcoin Whales would have incentive not to vote because anytime you access your private keys there are risks involved.not if you know how to do it properly, it really isn't that difficult. but you're right not everyone would vote, i'd be surprised to see more than 1% of bitcoins vote, but 100,000BTC+ voting is a lot better then a poll on bitcointalk.org. all you have to do to sign a msg with 0 risk is to sign the message on a permanently-air-gapped PC. poeple have all kinds of different solutions to securing their bitcoin, most popular is paper wallet. a simple HTML page with some JS could be made, so that all they need to do is, 1) save and run this html doc on a permanently-air-gapped PC 2) plug in there private key 3) select their vote and push "sign message" button 4) save the resulting message. 5) send that message to this coin-vote.com app. 5-10mins of work. i wonder if trezor HD wallet can sign messages, that would be another very secure way of doing it. |
|
|
|
|
there is no code, this is just a proposal. the code would be reviewed by the dev team, and other followers, and i don't think he'd be able to code anything other than what he wrote in his specification. the authors opinion on what would happen if 1MB limit was to stay despite TX demand reaching much higher then 1MB, is kinda besides the point.
|
|
|
|
i'm going to build a website where we can watch in real time, the blocklimit debate destroy bitcoin, by quantifying the level of disagreement among these groups.  |
|
|
|
|
Show Posts
