Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

>>2.1MB capacity in August via segwit, with 4MB weight, and 4.2MB capacity in December with 8MB<< I'm not sure how many people to not of the draft BIP I submitted to the list in early April. It was essentially a combination of Gavin's BIP 109, Adam's 2-4-8 idea, and something I added to SegWit

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

>>>Take a quick look at the COOP proposal...it gets us to 4mb blocks in 4 yearsgradually, no massive fee swings.<<< How is that captured in the COOP BIP? I can see Luke's 2MB cap referenced in the BIP, but I don't see anything in the text that would indicate a gradual increase of any sort.

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

What I mean is that spoonet and other HF improvements, and a slower timeline needs to be folded in ...before the HF activation date - to make it far more likely that the community adopts the whole proposal and the chain doesn't fragment. If you try to push a 2mb with no safety checks and nothing

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

>From me to you ...this proposal doesn't lock in anything. We could just merge it with some small pushback - allow segwit to activate in Aug, then "upgrade" the hard fork to be "spoonet in 18 months" instead. On Fri, Mar 31, 2017 at 11:03 PM, Samson Mow via bitcoin-dev <

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

Miner signalling is not enough to avoid two forks - as has been proven in the past (e.g. when miners signaled they were fully validating blocks when there we in fact only validating headers). To really protect against two forks happening, the code needs to detect this happening (i.e. monitor the

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

Not sure to get how you are answering the question > If the original blockchain hard-forks to re-adjust the difficulty, then it will just represent an alt-coin having 5% of Bitcoin community, and it can't affect Bitcoin (the segwit2mb fork). destroys the whole thing Because if the nodes don't

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

Responding between lines... On Wed, Apr 5, 2017 at 11:27 PM, Erik Aronesty wrote: > I personally appreciate the minimal changes, and often encourage > development to be done this way - when it needs to be released quickly. > But does this need to be released quickly? > >

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

The 95% miner signaling is important to prevent two Bitcoin forks, such as what happened with Ethereum HF and Ethereum Classic. Bitcoin has a very slow difficulty re-targeting algorithm. A fork that has just 95% miner support will initially (for 2016 blocks) be 5% slower (an average block every

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

I personally appreciate the minimal changes, and often encourage development to be done this way - when it needs to be released quickly. But does this need to be released quickly? - maybe the proposal should be renamed segwit 8mb and be discussed solely in terms of block weights. - a high

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

Just saying that we can talk in terms of weight alone after segwit. 8 mb weight is much more clear than 2 mb size to me. 2 mb size seems to obfuscate the actual new limit with the proposed hf, which simply 8 mb weight. On 2 Apr 2017 12:03 pm, "Natanael" wrote: > My point,

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

My point, if you missed it, is that there's a mathematical equivalence between using two limits (and calculating the ratio) vs using one limit and a ratio. The output is fully identical. The only difference is the order of operations. Saying there's no blocksize limit with this is pretty

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

On Sat, Apr 1, 2017 at 5:34 PM, Natanael wrote: > Den 1 apr. 2017 16:07 skrev "Jorge Timón" : > On Sat, Apr 1, 2017 at 3:15 PM, Natanael wrote: >> Den 1 apr. 2017 14:33 skrev "Jorge Timón via bitcoin-dev" >>

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

Den 1 apr. 2017 16:07 skrev "Jorge Timón" : On Sat, Apr 1, 2017 at 3:15 PM, Natanael wrote: > > > Den 1 apr. 2017 14:33 skrev "Jorge Timón via bitcoin-dev" > : > > Segwit replaces the 1 mb size limit with a weight

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

> Remember that the "hashpower required to secure bitcoin" is determined > as a percentage of total Bitcoins transacted on-chain in each block Can you explain this statement a little better? What do you mean by that? What does the total bitcoins transacted have to do with hashpower required?

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

On Sat, Apr 1, 2017 at 3:15 PM, Natanael wrote: > > > Den 1 apr. 2017 14:33 skrev "Jorge Timón via bitcoin-dev" > : > > Segwit replaces the 1 mb size limit with a weight limit of 4 mb. > > > That would make it a hardfork, not a

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

Den 1 apr. 2017 14:33 skrev "Jorge Timón via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: Segwit replaces the 1 mb size limit with a weight limit of 4 mb. That would make it a hardfork, not a softfork, if done exactly as you say. Segwit only separates out signature data. The 1 MB

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

Segwit replaces the 1 mb size limit with a weight limit of 4 mb. After segwit there's no need for MAX_BLOCK_BASE_SIZE anymore, let alone MAX_BLOCK2_BASE_SIZE. Thus, by "hf to 2 mb" it seems you just really mean hardforking from 4 mb weight to 8 mb weight. I would also use the hardfork bit (sign

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

Some people have asked me for the current implementation of this patch to review. I remind you that the current patch does not implement the hard-fork signaling, as requested by Matt. The Segwit2Mb patch can be found here: https://github.com/SergioDemianLerner/bitcoin/commits/master For now, the

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

Even if the proposal involves a political compromise, any change to the code must be technically evaluated. The patch was made to require the least possible time for auditing. I'm talking about reviewing 120 lines of code (not counting comments or space) which 30 of them are changes to constants.

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

A compromise for the sake of compromise doesn't merit technical discussions. There are no benefits to be gained from a 2MB hard-fork at this time and it would impose an unnecessary cost to the ecosystem for testing and implementation. On Fri, Mar 31, 2017 at 3:13 PM, Sergio Demian Lerner via

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

On Fri, Mar 31, 2017 at 6:22 PM, Matt Corallo wrote: > Hey Sergio, > > You appear to have ignored the last two years of Bitcoin hardfork > research and understanding, recycling instead BIP 102 from 2015. There > are many proposals which have pushed the state of hard

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

Praxelogy_guy, Yes I understand that segwit2mb represents a "potential" 4Mb block size increase. But Segwit does not immediately lead to 2 Mb blocks, but can only achieve close to a 2Mb increase if all Bitcoin wallets switch to segwit, which will take a couple of years. Therefore I don't expect

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

Sergio Demian Lerner: Please confirm that you understand that: The current SegWit being proposed comes bundled with an effective 2MB block size increase. Are you proposing the remove this bundled policy change, and then have a different BIP that increases the block size? Not quite clear if you

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

Hey Sergio, You appear to have ignored the last two years of Bitcoin hardfork research and understanding, recycling instead BIP 102 from 2015. There are many proposals which have pushed the state of hard fork research much further since then, and you may wish to read some of the posts on this

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

Hey Sergio, You appear to have ignored the last two years of Bitcoin hardfork research and understanding, recycling instead BIP 102 from 2015. There are many proposals which have pushed the state of hard fork research much further since then, and you may wish to read some of the posts on this

[bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

Hi everyone, Segwit2Mb is the project to merge into Bitcoin a minimal patch that aims to untangle the current conflict between different political positions regarding segwit activation vs. an increase of the on-chain blockchain space through a standard block size increase. It is not a new