On Thu, Jun 18, 2015 at 4:54 AM, odinn odinn.cyberguerri...@riseup.net wrote:
Recently I saw the following video:
https://www.youtube.com/watch?v=8JmvkyQyD8wt=47m58s
For those loosely following the technical issues from outside development
circles, but who may be pressed into a voting/adoption
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.
Ben,
How does your wallet calculate the fee that should be paid to miners? Do
they automatically adjust when transactions take a long time to be
confirmed? And how does it respond when transactions are not mined
successfully, such as when blocks are full?
I strongly urge Gavin to withdraw from
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
Thanks for setting this up, Warren!
On Thu, Jun 18, 2015 at 9:57 PM, Warren Togami Jr. wtog...@gmail.com
wrote:
After discussions in #bitcoin-dev in the past day we decided it would be a
bad idea to link the old and new lists in some way during a transition
period. We decided we are better
Nice insight Peter,
This further confirms the real problem, which doesn't have much to do with
blocksize but rather the connectivity of nodes in countries with
not-so-friendly internet policies and deceptive connectivity.
On Thu, Jun 18, 2015 at 6:00 PM, Tom Harding t...@thinlink.com wrote:
After discussions in #bitcoin-dev in the past day we decided it would be a
bad idea to link the old and new lists in some way during a transition
period. We decided we are better off announcing the switchover very soon,
and after that point all posts to the old list will be rejected with a
BTW, if you are posting from a less popular mail server your initial post
to the new list may be delayed by 5+ minutes due to greylisting. If your
sending SMTP server is behaving properly then posts after the first should
go through without delay.
Warren
On Thu, Jun 18, 2015 at 6:57 PM, Warren
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
On 06/12/2015 06:51 PM, Pieter Wuille wrote:
However, it does very clearly show the effects of
larger blocks on centralization pressure of the system.
On 6/14/2015 10:45 AM, Jonas Nick wrote:
This means that your scenario is not the result of a cartel but the result of
a long-term network
-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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The purpose of this post is to present an inquiry related to the
possible narrowing of scope of what sort of proposals are likely to
bear fruit at this stage. The inquiry or question is, Are there
some proposals that are more likely to succeed, in
33 matches
Mail list logo