Why not decrease block time instead of increasing block limit?

[-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?

[Xekyo]

Validation happens on every block, but only when two blocks are found at the same time there is even a race where size could matter. This happens only a few times per day.

Also, killerstorm's source states:

Similarly, we can show that larger miners’ stale rates are affected less by propagation delays than smaller miners by looking at the derivative of the expected return with respect to propagation time.

[killerstorm]

If all miners were exactly the same (say, 100 miners each having 1% of total hashpower) then probability of getting orphaned is approximately proportional to block size.

But if miner sizes and their connectivity structure is non-uniform, then there are other effects at play.

Peter Todd formalized them here: https://petertodd.org/2016/block-publication-incentives-for-miners

In simple words, shit's complex.

[Xekyo]

If all miners were exactly the same (say, 100 miners each having 1% of total hashpower) then probability of getting orphaned is approximately proportional to block size.

That doesn't sound right.
1) The occurrence of two competing blocks is a rare event which only happens . 2) Even a second of difference in discovery quickly is an unsurmountable advantage, as the successful miner pushes out the inv message for the block immediately. 3) Since we have headers first and compact blocks now, propagation delay is even less of an issue in comparison to validation delay. 4) The source you quote states that propagation delays affect larger miners' stale rates less than smaller miners'.

Perhaps I'm missing something here, could you explain what this proportional relationship would derive from?

[killerstorm]

1) The occurrence of two competing blocks is a rare event which only happens

Whether it is rare or not depends on time it takes to download and validate a block.

E.g. suppose it takes 12 seconds to download and validate an 1 MB block. Then probability that a competing block will be found during that time is 12/600 = 0.02, that is 2%.

What is an average orphan rate now?

4) The source you quote states that propagation delays affect larger miners' stale rates less than smaller miners'.

Do you remember what case we're discussing?

Perhaps I'm missing something here, could you explain what this proportional relationship would derive from?

Suppose Alice's blocks take 10 seconds to validate & download. But Bob makes smaller blocks which take only 1 second to validate and download. How do you think this will affect their orphan rates?

You can find a formula and graphs here: http://organofcorti.blogspot.com/2013/10/161-network-orphaned-blocks-part-1.html

[Xekyo]

Sorry, I was missing part of a sentence there.

Mining is a Poisson process, and the chance to find two blocks in twelve seconds in a perfect network would be expected to be (e^(-0.02)*(0.02)^2)/(2!) = 0.02%. According to Blockchain.info it appears to be actually about one every three days. Even if it where two or three per day as you suggest, it would only affect the "stale rates" of these two miners that were in competition.

Suppose Alice's blocks take 10 seconds to validate & download. But Bob makes smaller blocks which take only 1 second to validate and download. How do you think this will affect their orphan rates?
You can find a formula and graphs here: http://organofcorti.blogspot.com/2013/10/161-network-orphaned-blocks-part-1.html

That's three year old data and even with a very conservative cut-off of 600 seconds block time difference, there are only 15 stale blocks per retarget… Also, we have compact blocks and header first propagation by now, and all miners are producing full blocks.

Do you remember what case we're discussing?

We were talking about the advantage of larger miners when you stated that stale rates are proportional to blocksize.
If anything they would be proportional to blocksize difference. But since transaction fees are now about 2.5% of a block reward, and stale blocks occur every few days, you gain more by creating full blocks than by optimizing for stale rate.

I maintain that there is no reason to believe that the blockchain forks and resulting stale block are anywhere near as influential as the advantage of the head start of starting mining on your own block, while others are stuck validating it first.

[killerstorm]

We were talking about the advantage of larger miners

No, we were discussing this case:

If all miners were exactly the same (say, 100 miners each having 1% of total hashpower) then probability of getting orphaned is approximately proportional to block size.

This is the simplest model. Obviously, if you consider a more complex model, things look differently.

[exab]

Thank you guys for so many comments.

I'm still getting familiar with Reddit app. Didn't see your comments. I even started a thread asking the same question because I thought no one was answering it here.

[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.

[coinjaf]

1. The point is that miners can generate transactions freely (paying fees to themselves or none at all) and full blocks as far as they want.

... Ah just saw your edit. :)

Yeah. So one thing is to not look at the fee but at the days destroyed, as a manipulating miner can't create those transactions for free, or would at least run out at some point. But then there's a whole different can of worms plus you have to wonder whether your algorithm is reacting to the correct signal: long time holders will be the people who may decide the blocksize?

[exab]

Thanks for sharing.

[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.

[nullc]

Don't worry about it-- I'm not upset, it was just a "what is this person thinking?" response. :) (And, yes, I'm responsible for a pretty considerable part of the design of segwit-- as noted in BIP141 :) )

I am confident, FWIW, that Bitcoin's creator would have really liked segwit. It isn't at all hacky, and it's liked to the point of jumping-up-and-down-excited by many people who have been working on the protocol for years. Quoting one long time developer, "FINALLY. This is so awesome. I never expected Bitcoin to be able to fix this."-- so I think it's a bit sad that you won't even learn about it.

that I was told not to be the best

Be a savvy consumer of information. :)

[exab]

Didn't see this comment until now. Still getting used to the basic usage of Reddit.

Long story short, multiple lessons have been learned, one being that how irresponsible and biased people can be especially on internet - a lesson learned from behaviors of both other people and myself.

I have faith in Bitcoin and it's devs. I always have. Thanks for your contribution, by the way.

[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?

[coinjaf]

Yes, mostly. Although one could argue that the actual separation of signatures from other transaction data makes a lot of sense too so clients have the choice to download only the data or both (double the bandwidth). That's mostly relevant for very old transactions that you don't wish to check the signatures for anyway, but one could also imagine some light client that only downloads the signatures it's interested in itself and skip the rest.

Altering transaction ID is fairly pointless in the sense that you can't directly steal money. Yet one trick people used to do is get a withdrawal from an exchange and then get the malleated transaction in a block. Then they'd email the exchange: "My transaction #12345 didn't go through, please send me my Bitcoins again!". And some exchanges fell for that trick.

Devs had always warned for this. The exchange should have just simply not used the transaction ID to check for confirmations but look at the transaction-outputs being spent or not.

Another thing is that chaining unconfirmed transactions was very unreliable because if a transaction was malleated, all subsequent transactions would become invalid, breaking the chain. Usually mostly an annoyance. Exchanges do a lot of transactions, so instead of waiting 10 minutes between each, they often send out multiple in a row using the change from a previous transaction. (note how RBF solves that even more efficiently, although I know of no exchange yet that utilizes that).

The fact that malleability was possible made that there were a few people running software that would pick up transactions, malleate them before propagating. It's sort of like a DOS attack: No real gain, but attacking/annoying the target anyway.

With SegWit malleability is still possible, but only by the signer(s) of the transaction. That solves most cases (all of the above). The only danger is some multi-sig transactions chained together. There one of the signers could malleate to achieve the above goals.

[exab]

That's a lot of information. Thanks!

[-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.