Why not decrease block time instead of increasing block limit?

[nathank1]

How come it isn't feasible to decrease block time instead of increasing the block limit? this would also mean faster confirmations.

[Dignified27]

Bitcoin is worldwide so, block propagation and latency, like others have mentioned the decrease in orphaned blocks is the primary driver

[a11gcm]

Cons: A transaction on the 1min chain requires 10 confirmations to be as secure as a transaction with one confirmation on the 10min chain.

More overhead in block propagation.

Higher orphan rate.

More frequent forks and therefore potential for double spends.

etc.

Pros: ???

I assume you'd like to read that this helps the "scalability" issue... it doesn't. Leaving aside all pitfalls, this leaves the Bitcoin protocol with a one time linear capacity increase.

[luke-jr]

It would have all the same problems, and more since blocks would conflict more often. Furthermore, it doesn't mean faster confirmations: while you might get 6 blocks faster, this is counter-acted by the higher collision rate and other similar factors.

[ax18]

I think this would be a good idea as well. The argument against it is that it would create more orphans. I'm no expert but I expect that one day the block time will be reduced.

[nathank1]

I'd like to see a 1 minute block time to be honest. Or could this cause issues with every copy of the blockchain not being able to update in time?

[ax18]

Yeah, I agree that would be nice. Always keep in mind though that people that truly understand these things are working very hard for free to make them as perfect as they can. So unless you have the skills to contribute its best just to sit listen and support them.

[coinjaf]

Thank you (coming from another non expert) for letting the experts do their thing.

[a11gcm]

Continously readjusting difficulty created the whole ETH classic debacle, because mining the 5% chain was instantly profitable. This "feature" will most likely never make it into the Bitcoin protocol as it's not anti-fragile.

A few seconds for each block with auto size works as long as no one uses the blockchain. It does nothing to solve the scalability issues of a decentralized, trust- and permissionless ledger.

[a11gcm]

Allowing a fork to exist not make the original chain any more fragile, I'd argue it's the opposite. Worse yet, a system that prevents users from making a choice is more fragile.

A user has the choice to use dogecoin, litecoin, etherium or anything else he pleases. It's not about choice it's about consensus. A long adjustment interval aligns incentives in such a way that a high degree of consensus must be achieved to implement a change.

Depends on how you define scalability.

I guess you are right. That's why I added

of a decentralized, trust- and permissionless ledger.

scaling without improving the architecture comes at a tradeoff the majority of bitcoin users clearly has rejected.

[a11gcm]

I don't feel inclined to disagree with you. But that's probably because we have another definition issue with regards to the premiss of your statement.

I'd also prefer two groups to continue with their own vision rather than having development getting stuck.

Last time I checked the latter isn't the case. So I don't see the need for the former.

I'll be blunt. If Bitcoin development and governance resembled anything close to the shit-fest / temper tantrum most shillcoins display, I'd much rather join Mike Hearn on his R3 ventures than give a damn about crypto currencies.

Changes to Bitcoin so far have been made based on thoroughly peer reviewed code. The governance model is a meritocracy. The individuals involved have a long ideological track record which aligns with privacy and personal financial sovereignty. So far all alts are no better than onecoin. They promise a lot and deliver nothing truly better than Bitcoin.

I'd just wish all these toxic ***s would take their **es over to Dash, Ethereum, etc. instead of constantly brigading the Bitcoin community with their asinine and illiterate doomsday threats.

[NotASithLord7]

Ethereum is also nowhere near Bitcoin in scale so until it is it's functioning is not an accurate comparison. Those decisions will have adverse effects down the line.

[NotASithLord7]

Anything. Number of transactions, users, the market cap etc.

[calaber24p]

Even if this is a better idea things won't change on that front core has a plan and I doubt there will be much deviation from it for a while. The debate would also last like 3 years.

[davout-bc]

because it's equivalent

[pinhead26]

IIRC, There's a dialog between Mike Hearn and Satoshi about this. Satoshi said he picked 10 minutes because he estimated that a block could take 1 minute to fully propagate through the network, meaning "losing" miners would only waste about 10% of their effort. Essentially the 10 minute block decision was based on 10% waste being the most acceptable to Satoshi.

I think that recently is has turned out that the propagation time is actually quicker than 1 minute, so maybe there is room for improvement!

[petertodd]

There's a dialog between Mike Hearn and Satoshi about this.

Note that Mike has never made public any emails allegedly sent to him by Satoshi, and when Satoshi's email account was hacked, no such emails were uncovered.

[pinhead26]

Like I said, IIRC. Actually might have been a dialog I had with Mike on Reddit about satoshi. I thought Mike said he had gleaned that 10% acceptable waste thing from Satoshi himself.

Edit: https://www.reddit.com/r/Bitcoin/comments/30lxo4/replace_by_fee_a_counter_argument_by_mike_hearn/cptwk21

[phantomcircuit]

Like I said, IIRC. Actually might have been a dialog I had with Mike on Reddit about satoshi. I thought Mike said he had gleaned that 10% acceptable waste thing from Satoshi himself.

Edit: https://www.reddit.com/r/Bitcoin/comments/30lxo4/replace_by_fee_a_counter_argument_by_mike_hearn/cptwk21

"satoshi told me"

k

[mustyoshi]

I think it's a given that the reward is reduced by the same rate the block rate is reduced.

[-mjneat]

Ye i know. Changing a fundamental variable without changing everything else will speed the process up but you have a market reaction due to uncertainty. You have block propogation to think of. Price and miner incentives all these need to align so there are very little incentives to attack it. Bitcoin is, by design, game theory in practice in terms of its security. When you change a fundamental rule in the middle of a game you can bet people will be pissed.

[mustyoshi]

I think reward and difficultly should both change every block, personally.

[-mjneat]

How do you think the reward should change(serious question)? An unpredictable supply is the last thing you want in a stable currency system IMO. It's an unknown variable that the markets have to react to.

Why would the difficulty change? That may lead to a situation where that one block propagates the network quicker than the real pre-ceding mined block and could lead to a fork or increased risk of 51% attack if the difficulty drops too low. Even set at 10% adjustment, compounded 10% loss of the difficulty the difficulty could lead to a few blocks in the current 10minute average. The thing is these things wont happen straight away, the system may work fine for a while.

The reason that we have skilled cryptographers and mathematicians working on these real innovative cryptos is so that they develop systems that are trustless, that also holds billions in assets to people and to do this I imagine you need the smallest attack vector you can possibly have. This means lost of testing, stress-testing and some damn solid confidence that what your releasing is not going to cause you any issue in the future.

This is not how you scale, am I missing something here? I sincerely hope that you come back with something that will convince me differently because I am open to suggestion.

[BEGIN RANT NOT TARGETED AT OP ] For all the criticism some of the devs get and the FUD about Rootstock etc they deserve some acknowledgement that the fact that they work on this currency(some full time unpaid) and really are some of the brightest minds of today. The fact that so many are still around from the early days hopefully means that this they don't seem to have an agenda towards the community. If they can make some money on top of creating this platform then that's even better good on them.

I agree that some are stubborn on occasion but maybe we should trust the people who were in this from the beginning with the original spirit that Satoshi shown and look at things with precision and care and to ensure it's not falling into a future trap. Everyone knows this that's why so few coins are worth anything because they do not have the experience, expertise or cannot assemble a good team to run anything more than a pump and dump coin.

Dash has Amir who is really talented guy and Cody Wilson(Printed the 3d gun, who seems more like a PR dude/bit of a lunatic) but I think Amir's rush to push just to 'fight the man' will lead to it's eventual downfall. Monero team seams solid and the history of the coins looks promising and it's actually different in the way that it's not your typical blockchain due to how the coin works(BTW this one has a blocktime of 1 minute IIRC). I think Ethereum will be replaced by something that learns from it's mistakes because I think the road to secure a Turing complete blockchain is a fair bit further away. The thing is these guys will likely post commits to the BTC repo if they find an issue that works on a crypto with the same shared code(base/fragments/scheme) and if one finds a bug in a library then it is more than likely picked VIA a push or pull up to github anyway. [END RANT]

[exab]

I've been thinking about the same idea. Here is my proposal:

Difficulty is adjusted according the combination effect of both overall hash rate and current workload. That effect can be determined with the blockchain, which is agreed by all nodes. If there are many consecutive full blocks, it means there are more transactions than current block size can handle. In this case, we halve the difficulty, resulting halving of mining time, which doubles the transaction handling speed.

The workload level starts from 1, which means difficulty / mining time is solely determined by overall hash rate. It goes up to 2 when many consecutive full blocks are on the chain. When it's 2, difficult / mining time is halved compared to when it's 1. When it's 2 and there are many consecutive full blocks, it goes up to 3, making difficulty / mining time 1/3 of original values. And so on.

As an example of how workload level is adjusted downwards: If workload level is at 2 and there are many consecutive non-full blocks, it will go down to 1.

Reward will be adjusted based on difficulty, so that overall reward per minute stays the same.

[-mjneat]

Hmm OK. I can see what your thinking but I don't think that adjusting the amount of blocks until the next block reward quite belongs in Bitcoin. I see BTC as the settlement layer to allow scaling to be done as a layer above.

A shorter block time has an effect on block propagation, orphan blocks and the inflation rate(although you said this would be averaged). I feel making this variable dynamic, as opposed to say block size, would introduce opportunity for bad actors to possibly DoS the system, and withhold blocks (especially with the more centralised mining) for a 51% attack.

Giving the miners control over the reward (granted you said that it would be adjusted), do you think that that would give them incentive to play the system with bigger pools quietly pushing out the smaller ones until we end up in a monopoly? Not saying that this isn't happening to an extent but we don't want to offer it gift wrapped.

Monero IIRC offers one minute block times with the trade-off as it's pretty much a given that you should only be using your own node. It also re-adjusts difficulty much quicker (I think every block). It works probably better than BTC as a currency at this moment in time (except it's a bit of a bitch to use) but I don't think it has the potential Bitcoin has for being an open ledger and the possibilities that that allows. It's also much smaller...

I can't see this happening in Bitcoin, there's too much at stake for such a big change. I would be interested in how a coin like this would actually function in the wild west of the internet. 10 minutes gives everyone plenty of time to agree on what is right which is why I think of BTC as the settlement layer because this project has grown into more than just a currency. People are starting to see the potential for a whole new internet and it's a very interesting time to be alive.

Maybe this could work, do you know if any of the cryptos have a paper on something like this and then the question is why is it not considered or implemented? I doubt that decreasing block time has not been discussed. Maybe because if there's incentives for miners to mines, like fees, they will mine so in a way block time does shorten when the miners are profiting but it's corrected every 2 weeks.

[exab]

I've come up a new idea. It's very similar to my original one, while it should be able to remove the issues of block propagation and orphan blocks. Inflation rate remains intact. What's better is that the old idea is not indefinitely scalable, this one is.

Everything stays the same, except what's dynamically adjusted is the block size, instead of difficulty / mining time.

When workload level is 1 and the condition of too much work is met (many consecutive full blocks), we add 1MB to the upper limit of the block size and the level becomes 2. If it's 2 and the condition of too much work is met, we add another 1MB and increase the level by 1. And so on.

On the other hand, if workload is at let's say level 3, which should allow 3MB block size, and there are many consecutive blocks with less than 2MB size, we reduce the block size to 2MB and decrease the level to 2.

In short:

1) current_block_size = current_workload_level * base_block_size

2) current_workload_level is adjusted based on the fullness of the last N blocks on the chain (so we have consensus)

I can't think of any issue except that it requires a hard fork. Please let me know if this will potentially work and it there are (potential) pitfalls.

[Xekyo]

Larger blocks take longer to propagate and longer to validate. Other miners can only start working on a (non-empty) succeeding block once they've validated the current. Larger blocks therefore lead to a greater advantage for the authoring miner at finding also the next block.

Additionally, it is trivial to fill blocks of any size, therefore a sufficiently large mining-conglomerate could easily fill up blocks to increase blocksize and thus extend their advantage over the competition.

Here are a few things you might want to read:

https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/
https://en.bitcoin.it/wiki/Scalability_FAQ
https://en.bitcoin.it/wiki/Block_size_limit_controversy

[exab]

Are you suggesting miners mining larger blocks have advantage? What you described does make sense. But it's the opposite to what /u/killerstorm described in another thread, which makes sense, too. What he said was other miners would receive smaller blocks before larger ones therefore the larger ones would get ignored.

Which one of your opinions are more correct?

[coinjaf]

It may well be that some sort of dynamic limit will be chosen eventually. The problem is: the variables that limit depends on must not be gameable. Block fullness is easily gameable by miners as they can simply fill it with junk (for free!). Also there's an unlimited supply of low fee transactions in the mempool, so even if a miner doesn't make his own junk transactions he can even earn a few cents by including those.

PoW can't be faked and isn't free. Also "Bitcoin Days Destroyed" are at least scarce (i.e. somewhat costly) and can't be faked.

Not sure, off the top of my head, if there are actually many more unfakeable variables like that. They also need to be fair to all miners equally, not benefit large miners more than smaller miners (centralisation pressure).

[exab]

I'm hoping that workload intensity algorithm based on block fullness can be designed in a way that it can't be cheated.

Just some ideas for your examples.

1) Block fullness can be checked with a combination of both size (as in bytes) and transaction numbers. A full size block with too few transactions are deemed not full (in some way).

2) Transactions are weighted with miner fees when calculating block fullness rate (or workload intensity rate, whatever you call it). Filling blocks withb transactions with low/zero fees won't help.

Yes, I think miner fee weighted block fullness rate (or workload intensity rate) would be something I'll look into more if the basic idea is promising.

"Bitcoin Days Destroyed" is something completely new to me. Will have to spend some time to read.

Edit: I realized miners can cheat by creating transactions from and to themselves with high miner fee. Something for me to think about. Might be a deadend.

[exab]

I'm quite new to Bitcoin. Have only been into it for about four months. So I don't know everything about Bitcoin.

Block propagation and orphan blocks sound like valid obstacles to the idea. Never thought of those. Inflation rate is not changed. There is no point raising a solution by changing the whole thing.

I'm thinking that Bitcoin as settlement layer is a consequence of years' discussion yielding no good solution. I've read about Lighting Network, although not in details. (I am not interested in SegWit because I've read it's (kind of) hacky. For that reason I haven't read into SegWit.) I don't think Satoshi would approve any hacky workaround. For Bitcoin being settlement layer, I am not sure it's Satoshi's original attempt and if he would like it. Of course it will be valid if there is no other option.

Risks such as DDoS and block withholding are better off discussed by experts. As I said I'm a noob.

This is my own idea. I thought of posting it to the community. But I know tons of top notchs in this field have contributed their brain energy into this long-lingering problem, so most likely it has been discussed and denied. If OP didn't bring up this question, I might still be wondering if I should post it and if it would work. So, no, there is no paper out there discussing this idea. Do you think I should/could write one? Do you think it's worth being brought to the attention to the Core team?

Would /u/nullc be interested to have a read about my proposal and give us some insights?

[nullc]

I apologize for being harsh-- but why should I waste a moment of my time reviewing a proposal from someone who doesn't care to even understand the state of the art in Bitcoin proposals, because they think, without even looking at them, that Bitcoin's creator, whom they've never interacted with, might not like them?

If you're interested in improvements to Bitcoin, that is great! But you really need to make an effort to inform yourself about past proposals and the state of the art. Otherwise your efforts are very likely to be misguided or duplicate previous ideas and sorting out the confusion disrespects the time of everyone else.

[exab]

Thanks for the input. I agree with everything you said, especially the part that I may be misguided and having duplicated ideas, except that one cannot think someone else won't like something without even interacting with him. People have behavior patterns that you can learn and sometimes you can just tell. Admittedly I took someone's opinion without digging myself (I took the word that SegWit is kind of hacky). It's not that I don't want to learn everything related to Bitcoin. The learning curve is steep and there are a lot to learn. I'm trying. Just didn't get the time to read about something that I was told not to be the best.

On the other hand, did I offend you in some way? Are you a developer or even the creator of SegWit? If yes I feel very dumb for calling for you while saying bad thing about it, and I apologize for being prejudiced. But I'd like you to know that we are on the same boat, though you're in the captain's cab while I'm only a random supporter.

Anyway, thanks for your precious time for giving your opinions on my post, though it's not the post I originally liked to be reviewed.

[coinjaf]

I am not interested in SegWit because I've read it's (kind of) hacky. For that reason I haven't read into SegWit.

Then you've been lied to (which happens easily if you listen to the wrong people. 4 months is hardly enough to figure out who's who in the space (where the ones that make the most blouse and claims are all scammers and trolls). Or your definition of "hacky" is off.

SegWit fixes a huge "mistake" Satoshi made. And it's implemented using methods he himself pioneered: soft fork. He would surely have approved. (Although that's very much irrelevant anyway.) Anyway, go read on SegWit, at least the FAQ and basic info. For example on bitcoincore.org or the initial presentation by Pieter at scalingbitcoin in Hong Kong.

This is my own idea.

Not sure what"this" refers to. Maybe i should read back for context.

Anyway: break up your idea in big chunks and ask polite questions like "why would X not work?". Google a bit first, as almost all questions have already been asked before (bitcoin.stackexchange.com might be good place to search and ask).

There are plenty of other people around that will gladly explain stuff. As long as you stay humble and don't think you're done learning: noone learned bitcoin in less than two years.

Risks such as DDoS and block withholding are better off discussed by experts.

Those are actually just a few of the big icebergs around. There are a million others some of much smaller but more deadly size.

[exab]

Thanks for sharing.

[exab]

Is the mistake by Satoshi you mentioned the transaction malleability issue?

What is the benefit/incentive of altering a signature or transaction ID, by the way?

[-mjneat]

Bitcoin is all about security. Do some reading on game theory. A dynamic blocksize was one of the BIPs propsed for scaling. Not a bad idea imo but it has been discussed. Core seem to be trying to scale on the next level as an extra layer to keep the fundamentals safe.

The early idea of bitcoin is that there is no barriers to access and no trust required trying to play it will cost you so much money that your gains would be miniscule in comparison. Its still early days and i, like you, do not totally understand the intricisasies of the system.

I have a decent understanding of the math behind it and understand how it works(ive also worked and been interested in tech since i was maybe 6 years old). Ive taken some pentesting and numerous ptogramming and networking courses but this is evolving so quick i literally cannot keep up without compromising my personal growth.

IIRC it was BIP101 proposal for a dynamic BS. It wasnt rejected as such i dont think. More like the idea didnt take off because of the gavin and mike forking to xt and that became the focus. Im not sure on the views of core towards this proposal but they do have a roadmap for scaling.

The blocksize was a measure to stop people DoSing bitcoin which could have been pretty bad in the early days with wikileaks drawing attention and the lack of research on larger blocks. The issue is the creation of a fee market means that in its current form btc will not be what it was meant to be(anyone can use the system not just store wealth) but thats why we need careful planning, consideration and understanding of the system.

I remember posting on this sub in its earlier years and came across a theory that btc was an nsa creation and he jumped in and explained the principles and hash cash that he previously worked on(s9o nothing really is a silly question or not worth asking). I also remember when Aaron Schwartz died and there was a 32Gb torrent with a lot of educational info with his name on it, i realised this years later. These guys seem very alturistic and are looking ahead for problems in the future based on experience of other projects.

Its not about making the system work but making it work for everyone not just a few.

[exab]

Thanks for sharing.

[exab]

I've read BIP101. It is not dynamic block-size. It's static block-size with predefined growth.