The size limit is an economic policy lever that needs to be
transitioned -away- from software and software developers, to the free
market.
Exactly right. Bitcoin does not have a free market for fee though, and
literally all the discussion so far has neglected some fundamental
aspect of this, as
Jeff,
with all due respect, but I've seen you saying this a few times
now, that this decision is oh so difficult and important.
But this is not helpful. We all know that. Even I.
Make a suggestion, or stay out of the debate!
Mats
On 06/14/2015 07:36 AM, Jeff Garzik wrote:
The choice is very
Exactly -- both block size proponents and block size change conservatives
seem to be glossing over this aspect - much to my dismay.
Choosing the size limit is choosing the size of a scarce resource. By fiat.
It is wrong to think that a technical consensus can choose what is best
here.
The
On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo elombr...@gmail.com wrote:
2) BIP100 has direct economic consequences…and particularly for miners. It
lends itself to much greater corruptibility.
What is the alternative? Have a Chief Scientist or Technical Advisory
Board choose what is a
On Sun, Jun 14, 2015 at 12:55 AM, Chun Wang 1240...@gmail.com wrote:
To tell you the truth. It is only because most miners are not located
in the West. If Slush, Eligius and BTC Guild still on top 3, the core
developers, including brain-dead Mike Hearn, would be very happy to do
BIP100 just
The choice is very real and on-point. What should the block size limit
be? Why?
There is a large consensus that it needs increasing. To what? By what
factor?
The size limit literally defines the fee market, the whole damn thing. If
software high priests choose a size limit of 300k, space is
I definitely think we need some voting system for metaconsensus…but if we’re
going to seriously consider this we should look at the problem much more
generally. Using false choices doesn’t really help, though ;)
- Eric Lombrozo
On Jun 13, 2015, at 10:13 PM, Jeff Garzik jgar...@bitpay.com
Yes, it does bother (some) people to see the consensus based system
because of the difficulties that can be associated with implementing
it. But that's the way it is. If you don't like consensus based
systems (or decentralized, distributed systems) this is probably the
wrong space for you.
Chun,
With all due respect, there are a couple major differences between BIP34 and
BIP66 on the one hand and BIP100 on the other.
1) BIP34 and BIP66 are soft forks. Miners choosing to switch to them will not
seriously impact validation rules for non-mining users that do not make the
switch.
Miner voting, while imperfect, is the least-worst of various solutions
which inject market input into the system. It is is known quantity, field
tested, and must be sustained, in public, over a time span of months. As
this thread shows, stakeholder and direct user voting is nigh impossible to
Please forgive my ignorance, but why should Bitcoin users have a say in
block size limits? It's the miners and Bitcoin node operators that bear
the burden of managing large blocks, no?
Users voting on network parameters sounds like neighbors voting on how deep
my swimming pool should be.
That’s exactly the problem with Bitcoin - it was supposed to be the case that
users ARE the miners and node operators…but…alas…
On Jun 13, 2015, at 3:20 PM, Danny Thorpe danny.tho...@gmail.com wrote:
Please forgive my ignorance, but why should Bitcoin users have a say in block
size limits?
(Sorry for spam, forgot to cc the mailing list)
RE: miner economics
Miners who have an agenda can forego fees to achieve it and create their
own txns if it is completely txn/user driven. It is better to just count
miners votes and let the user votes be their backing.
Although miners need to
On Friday, 12 June 2015, at 7:44 pm, Peter Todd wrote:
On Fri, Jun 12, 2015 at 02:36:31PM -0400, Matt Whitlock wrote:
On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote:
On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
Why should miners only be able to vote for double
For the purposes of finding the median, halve same double. It will only
change if a majority of non-apathetic votes are for halve or a majority of
non-apathetic votes are for double.
On Fri, Jun 12, 2015 at 11:54 AM, Matt Whitlock b...@mattwhitlock.name
wrote:
On Friday, 12 June 2015, at 7:44
On Fri, Jun 12, 2015 at 1:04 PM, Eric Lombrozo elombr...@gmail.com wrote:
Miners currently only collect an almost negligible portion of their
revenue from fees.
Then they shouldn't care about the block size limit, since an increase in
block size (and thus in the number of txs they get fees
On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
Why should miners only be able to vote for double the limit or halve the
limit? If you're going to use bits, I think you need to use two bits:
0 0 = no preference (wildcard vote)
0 1 = vote for the limit to remain
On Fri, Jun 12, 2015 at 02:26:20PM -0400, Matt Whitlock wrote:
On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote:
Peter it's not clear to me that your described protocol is free of miner
influence over the vote, by artificially generating transactions which they
claim in their
This is a misguided idea, to say the least. If such a mechanism of of
user input would be possible, one would use it for transaction
verification in the first place. In proof-of-stake outcomes are
determined by vote by stake (that vote has very different
characteristics than vote by compute
Peter it's not clear to me that your described protocol is free of miner
influence over the vote, by artificially generating transactions which they
claim in their own blocks, or conforming incentives among voters by opting
to be with the (slight) majority in order to minimize fees.
Wouldn't it
On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote:
Peter it's not clear to me that your described protocol is free of miner
influence over the vote, by artificially generating transactions which they
claim in their own blocks
Miners could fill their blocks with garbage transactions
21 matches
Mail list logo
