Topic: I hold no view seeking information: 4 to 8 MB now. Technical Objections? (Read 2249 times)

There's nothing to check, you're just saying "it's possible" without giving reasons why.

It's possible to change the blocksize to 8MB, that doesn't make it desirable or sustainable, or at least not today. If 97.5% of the world had FTTP fibre-optic internet connections and cat 12 LTE 4G phones, then massive blocks might work. But saying "because" is not an argument.

Check this https://bitcointalksearch.org/topic/m.18685789 to see why the block size can be increased to 3MB right now.

Perhaps if I was having a pure codebase discussion as in is the specific function and the best implementation of that. Eg which call to which library may best serve.

However this  is a meta discussion about the development pathways could find the highest accord.

If I cast my language to tightly to early it may exclude prematurely, relevant views. So it's by design I leave the language open. As the discussion develops then it can be come more nuanced and precision can be effected.

I *think* I did largely address your views by withdrawing from an implementation (eg segwit), that you viewed as already encompassing solutions that forced the adoption of one camp, fair call.

I thus expanded my definitions and compass, which I think neatly demonstrates why you do not want precision as this stage, or the type of precision you refer too is orthogonal to what this thread is about, or a combination of the two.

You need to use very precise language for technical discussions. Not only is your language not very precise, but you're also repeating the broad points you already made (without taking the counter-points into account), and providing no reasoning, either

Firstly I genuinely appreciate the time you took for your input.

I am unaligned excepting as to detrimental stagnation (if this exists). I am doing this as an exercise in the search of truth.

I perhaps should not have said segwit or flextrans, so I withdraw them.

Lets take them out of the argument as they are clearly anchored to a lot of baggage.

I should say or rather recast as this a code solution that is acceptable to most parties,

Part of this seems to be to show on major part of the argument we are willing to look as an implement

[1] blocksize change,
[2] quadratic solutions, and compression of data if this can be achieved.
[3] +/-  compression [if it make it easier to agree throw it out]

The 2MB is to say we are willing to the concerned party we as community are prepared to increase the block size and sets the precedent for the future, its just shifts to a matter of degree, in the circumstances and cost of the tech of the day and the risks of over centralization, that is what  I was trying to get across.

No.



Yes.




No, Segwit does not change space efficiency, and flextrans is not even a serious proposal




No.


You're not listening, and you're mis-representing the case for improving space usage (which is the only form of scaling possible) so badly, that it's not easy to take your assessment seriously as a compromise proposal. You're also advocating a 2MB base blocksize hardfork, it's been rejected twice already (XT & Classic), and would involve an 8MB total blocksize when one factors in the corresponding witness blocksize. No.


Remember: Segwit is already a significant compromise between big blocks and 1MB forever. I'm somewhere in between big blocks and perma-1MB, and I am willing to accept Segwit, despite it's 4MB total blocksize being a concern to me.


What's happened is that the big blocks proponents just will not accept the 4MB Segwit blocksize increase, and keep pushing and pushing and pushing for as big a blocksize as they can, and never compromise anywhere (and also never hardfork the blockchain as they have constantly threatened for 2+ years). Your "compromise" just falls into the same category of rhetoric, and it's unpalatable for well grounded and argued technical reasons.

ok to draw this together

It seems
[1] a 2MB block
[2] quadratic solution of some type and :: [segwit and flex trans seem to have some options]
[3] maybe compression ::  [segwit and flex trans seem to have some options]

may be a dialogue that most parties could agree on::

Could this form a backbone to the discussion going forward?

Stripping away the emotive which may be justified but deleterious, reaching a compromise and consensus, where cooler heads prevail.

The miners, the devs, the userbase, exchanges, etc, all these parties can show now if you wish the way forward/

Sure there will be testing and things at the margins that due to unseen issues or tech requirements need to fall one way or the other.

Can we have this accord?

I think the self selecting nature of people in BTC, and realizing what it is, I think we can.

BU, Segwit, Classic, and XT are all over the news and even hit mainstream media. It has been nearly what everyone has talked about for months, practically years. Just take a look at the first page of Bitcoin Discussion and of both subreddits; BU and segwit (and previously Classic and XT) comprise a significant portion of what people are talking about. And yet a significant number of people still don't know what they are and ask questions about them, just like the OP of this thread. The current situation is comparable to said hypothetical hard fork and yet many people are still asking questions about the proposals and confused about what they are and what they do.

You have in no way addressed my counter points to your "solutions" to my objections.

That is nonsense.  A Bitcoin fork in the context we are speaking about would be all over the news, maybe even mainstream news.
It's all anyone would talk about for weeks and months.

Anyway, I've made point that your objections are solvable.  People that don't want things to be solved will always see objections.

Bitcoin has quite a large userbase, and I'm pretty sure that a significant portion of the community would not really be aware of a hard fork (just like a significant portion of the community doesn't really seem to be aware of BU or segwit or know anything about them). Furthermore, there is an issue of transaction replay, what the new coins are listed as in exchanges, and what they are calling themselves. If both forks are calling themselves "Bitcoin" or some variation of that (e.g. "Bitcoin Original" or something), then that can be confusing. It is also especially confusing for new users who just started using Bitcoin or are about to start using Bitcoin when the fork happens as they don't know enough about what is going on to make an informed decision. Unless a hard fork actually gains consensus (i.e. practically everyone in the community agrees with it), I think there will be confusion when a hard fork happens.

They could, sure.  But I doubt there would be much confusion about what was happening.

A hard forks require not just a majority but practically everyone involved. That means it must have nearly all miners and nearly all users. Just a "clear majority" (e.g. 75%) is not enough as the remaining can still keep the original chain going, albeit rather slowly for a few weeks. Even if all of the current hash power forked away, users who did not go along with the fork can also keep the original chain going by using older mining hardware which had been previously retired.

How so?  If the hard fork was done with a clear majority of hashpower (especially via a majority of pools), the longest chain would clearly be Bitcoin.

Segwit also offers an already coded, tested, and reviewed (flextrans has not had the same level of testing and review. IIRC the current implementation has many vulnerabilities in it as well) solution to quadratic sighashing. However, changing to flextrans is a lot more work than changing to segwit. It completely rewrites the entire transaction format. Doing a complete rewrite of that in every single wallet software will take a lot of time, and there are a lot of things that can be messed up in rewriting that. As someone who has partially implemented segwit for a wallet, segwit is really not that bad to implement as it is an extension on the existing transaction format.

Limiting the transaction size is not really a solution. It also prevents people from making those large transactions which can, at times, actually be useful. For example they can be used to clean up a large amount of spam UTXOs but cost less than multiple transactions. F2pool did this with the large 1 MB transaction they made when they cleaned up a lot of small, spam UTXOs from broken brainwallets.

As I said, the concern is not just on disk space but also bandwidth.

Do you also realize that people aren't going to be buying new hard drives every year just to store the blockchain? Maintaining a growth of 1.68 TB a year would be quite burdensome on node owners as they would constantly have to get new hard drives and have the bandwidth to allow that much data to and from their node to multiple peers while still also having disk space for their personal data and bandwidth for personal use.

Altcoins don't have the same number of users, network conditions, market cap, or development situation as Bitcoin does. Bitcoin and altcoins are not comparable.

It is not an issue of "kicked off the main chain" but rather that a short-term, abrupt hard fork would almost certainly result in two chains and a lot of uncertainty about which is Bitcoin.

No technical objections, only economical ones.
You can't run bitcoin between three full nodes and support a price of hundred thousands dollars per coin.

For most of us, Carlton has been on 'ignore' for years now. He's a known troll. SegWit doesn't make transactions smaller, it just separates part out. Now, ask yourself why that is a better solution than just making the blocks bigger, and then you'll start smelling the bullshit.

how much can we do this, in your understanding? or any one else's for that matter?

It Seems segwit does allow some compression, is thier part of that codebase we can take that would not be objectionable to say the BU camp?

Or what other algorithms can we use to effect compression?

Increase the efficiency with which the transactions themselves are stored in the blocks. Don't make the blocks bigger, make the transactions smaller. I can't believe I'm the only person regularly arguing in favour of this incredibly common-sense and simple concept, which actually fulfills the definition of what the word "scaling" means.

ok i see this may be a considerable issue...what would help alleviate this, code wise apart from block size::

Sure, it's not that large when it's just one and you're downloading it as a slight addition to what it was before.

But when you're talking about downloading hundreds of gigabytes of data each year and needing to keep your node running nearly all of the time to keep up and having to have great bandwidth to handle it, that's when nodes become less accessible.

Block size increase is great for a temporary increase in transaction capacity.  But when you're talking about long-term upgrades to the protocol before Bitcoin can become even more immutable because it's sufficiently scalable, you have to consider that you can't just keep shoving up the block size.  You have to find ways to upgrade the protocol and actual system properly, otherwise you'll end up with the scenario of a few mining monopolies running full nodes and no one else.