Yes, the two dimensions are orthogonal: BIP 100 support and actual size
voting. However there seem to be a few pools which simply vote to support
BIP100, without specifying a desired block size [1], hence I started
tracking both on the same chart, maybe I'll split them into different
charts to
Github:
https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki
pre
BIP: 1xx
Title: Dynamically Controlled Bitcoin Block Size Max Cap
Author: Upal Chakraborty bitc...@upalc.com
Status: Draft
Type: Standards Track
Created: 2015-08-24
/pre
==Abstract==
Proposal 1 looks good, but tx fee collected can be manipulated by
miners. I like the idea next block collect the tx fee from previous
block.
On Tue, Aug 25, 2015 at 5:07 PM, Upal Chakraborty via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Github:
This BIP has been assigned BIP112 by the BIP repository maintainer. I
have updated the pull request accordingly.
Regarding the suggestion to cannibalise version, by your own
disadvantage list, we would lose fine grained control over txins which
neuters the usefulness considerably. Also using
To follow up on this, let's say that you want to be able to have up to 1
year relative lock-times. This choice is somewhat arbitrary and what I
would like some input on, but I'll come back to this point.
* 1 bit is necessary to enable/disable relative lock-time.
* 1 bit is necessary to
On Tue, Aug 25, 2015 at 11:08 PM, Mark Friedenbach via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Assuming a maximum of 1-year relative lock-times. But what is an
appropriate maximum to choose? The use cases I have considered have only
had lock times on the order of a few days
On Tue, Aug 25, 2015 at 04:26:23PM -0400, Matt Whitlock wrote:
On Tuesday, 25 August 2015, at 1:16 pm, Peter Todd via bitcoin-dev wrote:
What would you think of an approach like John Dillon's proposal to
explicitly give the economic majority of coin holders a vote for the max
blocksize?
On Tuesday, 25 August 2015, at 1:16 pm, Peter Todd via bitcoin-dev wrote:
What would you think of an approach like John Dillon's proposal to
explicitly give the economic majority of coin holders a vote for the max
blocksize? Miners could still vote BIP100 style for what max they were
willing
On Wed, Aug 26, 2015 at 05:44:46AM +0800, Chun Wang wrote:
On Wed, Aug 26, 2015 at 5:18 AM, Simon Liu via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
I don't think this would work.
If the rule is that one user can only have one vote, how do you prevent
a user running
As I understand Github is not to be used for the high-level discussion
of a draft BIP so I will post my thoughts here (is this specified
somewhere? Can we specify this in BIP-0001?).
- I have some concerns about the structure and the wording of this
proposal. I think both the structure and
On Tuesday, 25 August 2015, at 1:37 pm, Peter Todd wrote:
On Tue, Aug 25, 2015 at 04:26:23PM -0400, Matt Whitlock wrote:
On Tuesday, 25 August 2015, at 1:16 pm, Peter Todd via bitcoin-dev wrote:
What would you think of an approach like John Dillon's proposal to
explicitly give the
just as in democracy in general
One should be clear that Bitcoin is by no possible measure a democracy.
The proposed vote is on what goes into a particular github repository.
The outcome is ultimately controlled by those with control of that
repository.
Bitcoin is an anarchy by design. People
On Wed, Aug 26, 2015 at 5:18 AM, Simon Liu via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
I don't think this would work.
If the rule is that one user can only have one vote, how do you prevent
a user running multiple nodes?
The vote is not counted by nodes, but bitcoin amount,
I don't think this would work.
If the rule is that one user can only have one vote, how do you prevent
a user running multiple nodes?
Also, how do you verify that a node is indeed a fully validating node
with its own copy of the blockchain?
On 08/25/2015 01:37 PM, Peter Todd via bitcoin-dev
14 matches
Mail list logo
