>>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 tha
>>>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.
As
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 e
By "upgrade" the HF you mean activate 2X and then spoonet 18 months later
or do not activate the 2x HF at all?
On Fri, Jun 2, 2017 at 4:04 PM, Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> From me to you ...this proposal doesn't lock in anything. We could
>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 Sat, Apr 1, 2017 at 8:33 AM, Jorge Timón via bitcoin-dev <
bitcoin-dev@lists.linuxfo
>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 <
bitcoin-dev@lists.linuxf
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
ot
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 u
Ups. My mistake: the mempool will not grow 400 times, the is no square
there.
I will initially grow 20 times. Multiplied by the number of times a
transaction may need to be replaced with one with higher fees. Maybe 50
times, but not 400.
On Thu, Apr 6, 2017 at 5:42 PM, Sergio Demian Lerner <
se
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?
>
>
Segwit2mb is a last reso
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 10
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 consens
On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> The hard-fork is conditional to 95% of the hashing power has approved the
> segwit2mb soft-fork and the segwit soft-fork has been activated (which
> should occur 2016 blocks aft
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, if you missed it, is th
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
meaningles
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"
>> :
>> Segwit replaces the 1 mb size limit with a weight limit of 4 mb.
>> That would make
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 limit of 4 mb.
>
>
> That would make it a hardfork, not a softfork, if done exactly
> 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?
On
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 softfork, if done exactly as you say.
>
> Segwit only separates out si
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 limi
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 bi
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
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. A
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 bitco
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 fork research
> much further s
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 tra
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
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 mail
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 mail
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 solution
30 matches
Mail list logo