if you like Core's quality but BU's emergent consensus for bigger blocks

[jonald_fyookball]

...then there's this:

https://bitcoinec.info/

[1714159373]

1714159373

[1714159373]

1714159373

[1714159373]

1714159373

[1714159373]

1714159373

[pixie85]

And the era of 10 new update ideas for Bitcoin every week has begun. Do we really need all that?

If we really have to update I think a small patch like this one is much better than a big one like BU. BU will never get full support, but a small patch might.

[jonald_fyookball]

And the era of 10 new update ideas for Bitcoin every week has begun. Do we really need all that?

If we really have to update I think a small patch like this one is much better than a big one like BU. BU will never get full support, but a small patch might.

It really is the best of both worlds -- the stability of the Core code and the flexibility of bigger blocks.
Heck, it even supports segwit, what more do you want?

The only people who won't like this are the hardline small blockers and the hardcore Blockstream/Core centralists.

[AngryDwarf]

...then there's this:

https://bitcoinec.info/

Posted about that in another thread. First issue thought was, this makes the 2 tier (backwards compatibility) network redundant code. Segwit as a hard fork, 1:1 weight, and emergent consensus block sizes I don't think I would have any issue with.

[jonald_fyookball]

i didn't follow you... network redundant ..come again?

[Holliday]

The only people who won't like this are the hardline small blockers and the hardcore Blockstream/Core centralists.

Don't forget the people who think Emergent Chaos is complete garbage.

[AngryDwarf]

i didn't follow you... network redundant ..come again?

Segwit as a soft fork implements a 2 tier network system, where the old nodes are filtered with compatible 1MB blocks, and the upper tier knows all about the segwit data. Simply forking 0.14 to create bitcoinEC leaves all that redundant network code in, as the EC mechanism requires a hard fork, so then you might as well implement segwit as a hard fork and get rid of all the technical debt associated with the 2 tier backwards compatibility network.

[jonald_fyookball]

i didn't follow you... network redundant ..come again?

Segwit as a soft fork implements a 2 tier network system, where the old nodes are filtered with compatible 1MB blocks, and the upper tier knows all about the segwit data. Simply forking 0.14 to create bitcoinEC leaves all that redundant network code in, as the EC mechanism requires a hard fork, so then you might as well implement segwit as a hard fork and get rid of all the technical debt associated with the 2 tier backwards compatibility network.

yes isnt that what are doing -- the whole thing would be a HF?

@Holliday:  I wasn't aware there are people like that , that aren't already part of one of the other groups I mentioned (like yourself).   But I'm sure there are a few.   Nobody said consensus would be easy I guess.

[Carlton Banks]

jonald, exactly how desperate can you get?


This is the Bitcoin wreckers playbook reaching it's latest re-iteration: coup attempt N fails, begin coup attempt N+1


Your current coup hasn't finished jonald, don't you remember? (or has it....  )

[Holliday]

@Holliday:  I wasn't aware there are people like that , that aren't already part of one of the other groups I mentioned (like yourself).   But I'm sure there are a few.   Nobody said consensus would be easy I guess.

If you read r/btc you will quickly find that there are lots of people who support a simple larger block size (therefore not Core) but are quite opposed to Emergent Chaos due to the insane amount of complexity it adds or the fact that it hands the miners even more control over the network.

Which group did you think I am in, exactly?

[AngryDwarf]

Will you also have an AD(Accept Depth) parameter like Bitcoin Unlimited?

Instead of Accept Depth we will implement a warning system to alert users if they are not on the longest chain. Implementing AD in the way BU has done appears to be fairly complicated and hard to do correctly, a warning system is simple since we only need the block headers for that.

Why bother with these user warnings, users are only interesting in following the longest chain anyway.

I agree, Acceptance Depth is not Keep It Simple Stupid. So just remove the original 1 MB anti-spam measure and allow miners to increase blocksizes with the -blockmaxsize parameter to adjust to real world demand just as they used to before the 1MB limit was reached.

But then I won't be able to install a full node on my mobile phone.  

[Lauda]

...then there's this:

https://bitcoinec.info/

I've already posted a link to this proposal. However, it looks like the code for it is just not ready yet. Wouldn't this be a *compromise* for those that think Segwit is great, but prefer a 'block size increase'?

-snip-
Your current coup hasn't finished jonald, don't you remember? (or has it....  )

I guess this would be better than a certain 'mr. Emperor' not signalling/running Segwit at all.

[Yakamoto]

...then there's this:

https://bitcoinec.info/

Looks like an interesting solution, I want to take some time to go through more of the page and read up on the entirety of the project, but overall it seems like they have a relatively decent idea of what they're doing.

I have no idea if I would mean anything even if I backed them and talked about it, but this might be worth bringing up again in block size debates.

[jonald_fyookball]

I've already posted a link to this proposal. However, it looks like the code for it is just not ready yet. Wouldn't this be a *compromise* for those that think Segwit is great, but prefer a 'block size increase'?
 

I suppose it would be.

It would be a compromise for me too though, because I'm not a fan of Segwit.