*Proposal*: Verify whether 50% Tx mined from SegWit activation block to
block 63 are SegWit Tx. If yes, increase legacy max block size to 2MB
and SegWit max block size to 8MB.
*Implementation*: This proposal either needs to be implemented in next
release of Bitcoin Core or require SegWit activ
Hello,
First of all, I'm not sure if it is the right place to ask for such help.
But, I thought, someone might just help out.
I'm looking for two graphs to analyze the effectiveness of BIP 106, which
can be found at
https://github.com/bitcoin/bips/blob/master/bip-0106.mediawiki.
Blockchain.info c
Tue, Aug 25, 2015 at 5:07 PM, Upal Chakraborty via bitcoin-dev
> wrote:
> > Github:
> >
> https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki
> >
> >
> > BIP: 1xx
> > Title: Dynamically Controlled Bitcoin Block S
Can we please keep this mail chain discussion specific to the proposed
draft -
https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki
?
I understand, voting process is an important subject of discussion. But,
that may be discussed in a separate mail chain.
On Wed, A
Github:
https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki
BIP: 1xx
Title: Dynamically Controlled Bitcoin Block Size Max Cap
Author: Upal Chakraborty
Status: Draft
Type: Standards Track
Created: 2015-08-24
==Abstract==
This BIP proposes replacin
I have tried to solve the maximum block size debate in two different
proposal.
i. Depending only on previous block size calculation.
ii. Depending on previous block size calculation and previous Tx fee
collected by miners.
Proposal 1: Depending only on previous block size calculation
If more t
Regarding...
i.
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010493.html
ii.
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010499.html
Could we please keep the conversation specific to the proposal presented at
http://upalc.com/maxblocksize.php ? If you f
size limit at the "high water mark"
> indefinitely, even though periods of decreased transaction volume?
>
> I'd argue to remove the reduction step, making the max block size
> calculation a monotonic increasing function. Cut the complexity in half.
>
> -Danny
>
&
Regarding:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html
I am arguing with the following statement here...
*I see problems to this approach. The biggest one I see is that a miner
> with 11% of hash power could sabotage block size increases by only ever
> mining e
I have tried to solve the maximum block size debate, depending on the
previous block size calculation.
Requesting for comment - http://upalc.com/maxblocksize.php
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfounda
10 matches
Mail list logo
