>
> If you want me to take your proposal seriously, you need to justify why
> 60% full is a good answer
>
Sure thing Gavin.
If you want blocks to be at least 60% full...
First off, I do not want blocks to be at least 60% full, so let me try and
explain where I got this number from
- The ide
On Tue, Sep 8, 2015 at 1:28 PM, Danny Thorpe wrote:
> What of this prior effort, proposing B-with-horizontal-bar (Ƀ)?
> http://bitcoinsymbol.org/
>
> They argue that B-with-2-vertical-bars is easily confused with the Thai
> Bhat currency symbol, which is a B with a single vertical bar.
>
Actuall
What of this prior effort, proposing B-with-horizontal-bar (Ƀ)?
http://bitcoinsymbol.org/
They argue that B-with-2-vertical-bars is easily confused with the Thai
Bhat currency symbol, which is a B with a single vertical bar.
I'm not terribly fond of the B-with-horizontal-bar as a symbol, but it d
>
> 3) Let me put it another way, I've read that both Gavin and yourself are
> favorable to a dynamic limit on the block size. In your view, what is
> missing from this proposal, or what variables should be adjusted, to get
> the rules to a place where you and other Core developers would seriously
I rather like this idea, I like that we're taking block scaling back to a
technical method rather than political. BIP100 is frightening to me as it
gives a disproportionate amount of power to the miners, who can already
control their own blocksize with a soft cap. It also seems silly to worry
abo
1) It's not really clear to me how that would work, but assuming it does
then it will go into a basket of attacks that are possible but unlikely due
to the economic disincentives to do so.
2) That said, is the Achilles heal of this proposal the lack of a mechanism
to lower the block size?
3) Let
> A selfish mining attack would have to be performed for at least 2000 blocks
> over a period of 4 weeks in order to achieve a meager 10% increase in the
> block size.
You seem to be analysing a different attack - I mean that if someone
has enough hashrate to do a selfish mining attack, then set
>
> The maximum block-size is one that can be filled at zero-cost by
> miners, and so allows some kinds of amplification of selfish-mining
> related attacks
A selfish mining attack would have to be performed for at least 2000 blocks
over a period of 4 weeks in order to achieve a meager 10% increa
Agreed. For this reason, the scaling BIPs which don't allow for easy gaming
such as BIP101, your proposal or Pieter's are preferable for their
predictability and simplicity. Changing the fundamental rules for Bitcoin
is supposed to be hard - why give this power up to a subsection of the
ecosystem i
The maximum block-size is one that can be filled at zero-cost by
miners, and so allows some kinds of amplification of selfish-mining
related attacks.
Adam
On 8 September 2015 at 13:28, Ivan Brightly via bitcoin-dev
wrote:
> This is true, but miners already control block size through soft caps.
This is true, but miners already control block size through soft caps.
Miners are fully capable of producing smaller blocks regardless of the max
block limit, with or without collusion. Arguably, there is no need to ever
reduce the max block size unless technology advances for some reason
reverse c
> but allow meaningful relief to transaction volume pressure in response to
> true market demand
If blocksize can only increase then it's like a market that only goes
up which is unrealistic. Transaction will volume ebb and flow
significantly. Some people have been looking at transaction volume
c
Hi everyone,
I know many of us feel that the last thing the Bitcoin community needs is
another BIP related to the block size, but after a lot of reading and
commenting, I'd like to throw this idea out there.
I've already written it up as a BIP and would like some constructive
feedback/suggestions
13 matches
Mail list logo
