I don’t think the issue is between larger blocks on the one hand and things
like lightning on the other - these two ideas are quite orthogonal.
Larger blocks aren’t really about addressing basic scalability concerns - for
that we’ll clearly need architectural and algorithmic improvements…and
Yeah, but increasing block-size is not a longterm solution.
Are you sure? That sort of statement is hard to answer because it doesn't
say what you think long term is, or how much you expect Bitcoin to grow.
Satoshi thought it was a perfectly fine long term solution because he
thought hardware
When is the right time to allow space pressure to rise that ratio?
When the subsidy is at 1.5625, for example, it may be too late to
I don¹t believe we have to decide, the miners will do that and are doing
that already.
start a non-catastrophic transition from subsidies to fees.
I don't claim
Yeah, but increasing block-size is not a longterm solution. Necessary
higher fees are a logical consequence of lower subsidies. Bitcoin was
basically free to use at the beginning because miners got paid with
new coins at the expense of those who already hold coins. Eventually
there needs to be a
Benjamin,
Timeframe for network congestion and users experiencing service
degradation = between now and middle of next year.
Timeframe for transaction fees topping block reward fees = many years in
the future, based on current ratio of block reward to fees.
What is the more pressing requirement
On Fri, Jun 19, 2015 at 4:37 AM, Mike Hearn m...@plan99.net wrote:
Or alternatively, fix the reasons why users would have negative
experiences with full blocks
It's impossible, Mark. *By definition* if Bitcoin does not have
sufficient capacity for everyone's transactions, some users who
Or alternatively, fix the reasons why users would have negative
experiences with full blocks
It's impossible, Mark. *By definition* if Bitcoin does not have sufficient
capacity for everyone's transactions, some users who were using it will be
kicked out to make way for the others. Whether
And allegations that the project is run like wikipedia or an edit war
are verifyably untrue.
Check the commit history.
This was a reference to a post by Gregory on Reddit where he said if Gavin
were to do a pull request for the block size change and then merge it, he
would revert it. And I
If you think it's not clear enough, which may explain why you did not even
attempt to follow it for your block size increase, feel free to make
improvements.
As the outcome of a block size BIP would be a code change to Bitcoin Core,
I cannot make improvements, only ask for them. Which is
On Thu, Jun 18, 2015 at 5:00 AM, Mike Hearn m...@plan99.net wrote:
Dude, calm down.
Well hold on, his concerns are real and he seems perfectly calm to me and
others apparently.
and Gavin already said long ago he wouldn't just commit something, even
though he has the ability to do so.
So I'm *not* the decider for anything that concerns the behavior of
the global consensus, and I cannot be, as I have explained in the
previous post.
The person who decides if a pull request is accepted is a decider and
significantly affects the behavior of the global consensus. The only
On Thu, Jun 18, 2015 at 6:31 AM, Mike Hearn m...@plan99.net wrote:
The first issue is how are decisions made in Bitcoin Core? I struggle to
explain this to others because I don't understand it myself. Is it a vote
of people with commit access? Is it a 100% agreement of core developers
and if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
This kind of thing always happens as projects become larger and more
diverse. Something that was once a small group turns into a big
group of diverse stakeholders. When it gets too big for the
informal processes then some people get upset and
So then: make a proposal for a better process, post it to this list.
Alright. Here is a first cut of my proposal. It can be inserted into an
amended BIP 1 after What belongs in a successful BIP?. Let me know what
you think.
The following section applies to BIPs that affect the block chain
You misunderstand what I am saying. I am not saying I have a specific
process that should be followed, I am saying that whatever the process
is then it should be formalized or at least written down. That way the
stakeholders have something to work with and keeps people on track.
Since some
On Thu, Jun 18, 2015 at 9:07 AM, justusranv...@riseup.net wrote:
On 2015-06-18 14:53, Jeff Garzik wrote:
Consensus changes - worded another way - change Bitcoin's Constitution -
The Rules that everyone in the system is -forced- to follow, or be ignored
by the system.
Bitcoin does not and
On Thu, Jun 18, 2015 at 06:05:58PM +0200, Mike Hearn wrote:
Once a draft BIP has been submitted to bitcoin-development for
consideration, the Bitcoin Core maintainer will deliver a preliminary
yes/no verdict within three weeks. This verdict may be informed by the
debate that has taken part in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2015-06-18 16:28, Jeff Garzik wrote:
This is an engineering list. The quote precisely describes how the
bitcoin
consensus system functions.
Users' choice is largely binary: Follow the rules, or bitcoin software
ignores you.
Software
On 06/18/2015 06:33 PM, Mark Friedenbach wrote:
* Get safe forms of replace-by-fee and child-pays-for-parent
finished and in 0.12.
* Develop cross-platform libraries for managing micropayment
channels, and get wallet authors to adopt
* Use fidelity bonds, solvency proofs, and other
On 18 June 2015 at 12:00, Mike Hearn m...@plan99.net wrote:
Dude, calm down. I don't have commit access to Bitcoin Core and Gavin
already said long ago he wouldn't just commit something, even though he has
the ability to do so.
So why did I say it? Because it's consistent with what I've
Not that I know how to do this, but would you be willing to attempt some
other method of measuring just how much of a super-majority we have
before deploying code? Maybe that information would be helpful for
everyone. Obviously such a poll couldn't be perfect, but maybe better than
the
2) Changes to the consensus rules: As others have said, this isn't
anyone's decision for anyone else. It's up to each individual user as
to what code they run and what rules they enforce. So then why is
everyone so up in arms about what Mike and Gavin are proposing if
everyone is free to
Let me take a pass at explaining how I see this.
1) Code changes to Bitcoin Core that don't change consensus: Wladimir is
the decider but he works under a process that is well understood by
developers on the project in which he takes under reasonable consideration
other technical opinions and
On Thu, Jun 18, 2015 at 1:42 PM, Alex Morcos mor...@gmail.com wrote:
Let me take a pass at explaining how I see this.
1) Code changes to Bitcoin Core that don't change consensus: Wladimir is
the decider but he works under a process that is well understood by
developers on the project in
On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik jgar...@bitpay.com wrote:
The whole point is getting out in front of the need, to prevent
significant negative impact to users when blocks are consistently full.
To do that, you need to (a) plan forward, in order to (b) set a hard fork
date in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Regarding this proposal from Mike Hearn to remove consensus process
from the BIP, which I think is unsound philosophy. I will address
this briefly below.
On 06/18/2015 09:05 AM, Mike Hearn wrote:
So then: make a proposal for a better process, post
On Thu, Jun 18, 2015 at 3:33 PM, Mark Friedenbach m...@friedenbach.org
wrote:
On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik jgar...@bitpay.com wrote:
The whole point is getting out in front of the need, to prevent
significant negative impact to users when blocks are consistently full.
To do
Matt, I for one do not think that the block size limit should be raised at
this time. Matt Corallo also started the public conversation over this
issue on the mailing list by stating that he was not in favor of acting now
to raise the block size limit. I find it a reasonable position to take that
There's some actually proposing inaction as an outright decision, but I
more meant that at times it has felt like we would end up with inaction
through momentum, combined with adoption rate making any hard fork more
complex if it continues to be delayed.
On 18/06/2015 22:42, Matt Whitlock
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I maintain that you should apologize to those who traverse this list.
What you are saying is digging yourself a deeper hole and is not
merely embarrassing but is crossing a threshold in which you have used
words, albeit subtly, to attack a community.
I'm struggling to illustrate how incredibly low 7 transactions per
second is, not just for a payment network, but even just for a clearance
network (i.e. to balance transactions between institutions and/or
chains). As an example, the Clearing House Interbank Payments System
(CHIPS) is a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Regarding the bit on getting out in front of the need, to prevent
significant negative impacts to users I had suggested the following:
On 06/18/2015 03:52 PM, Jeff Garzik wrote:
On Thu, Jun 18, 2015 at 3:33 PM, Mark Friedenbach
m...@friedenbach.org
32 matches
Mail list logo
