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 clar
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
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
wrote:
> Github:
> https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlock
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 versi
On Tue, Aug 25, 2015 at 05:19:28PM +0800, Chun Wang via bitcoin-dev wrote:
> 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.
What would you think of an approach like John Dillon's proposal to
explicitl
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
> willin
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
> > blocksiz
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
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 wro
> 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
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, or probably
better, coin-days. It w
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 indicate
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 da
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 t
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
> 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 no
On 26 August 2015 at 01:29, Peter Todd via bitcoin-dev
wrote:
> For instance, a very simple toy example that would work is just XORing your
> vote with SHA256(the entire blockchain)
Uh, that would totally not work.
I think my proposal of using CLTV to lock coins (votes) is better.
Failing a sof
16 matches
Mail list logo