On Thu, Aug 20, 2015 at 11:00:14AM +0200, Mike Hearn via bitcoin-dev wrote:
It is just that no one else is reckless enough to bypass the review process
I keep seeing this notion crop up.
I want to kill this idea right now:
- There were months of public discussion leading to up
It is just that no one else is reckless enough to bypass the review process
I keep seeing this notion crop up.
I want to kill this idea right now:
- There were months of public discussion leading to up the authoring of
BIP 101, both on this mailing list and elsewhere.
- BIP 101 was
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This is a simple post.
Who's got visualizations of votes?
One I've seen that I liked was
http://bipsxdevs.azurewebsites.net/
This just covered how developers feel about the various BIPs though.
A visualization I would like to see would include:
Hello,
BitPay seems to support BIP 101:
https://medium.com/@spair/increasing-the-block-size-limit-85ff236fc516
We do not know where this is going. But I suspect that ultimately also
the core client will increase the block size.
Bitcoin is also the subject of research. I think that research is
The idea is to come up with some sort of standardized metric so as the
tools and issues come up you are comparing similar things.
The first thing you have to do is link centralization pressure and
(pressure to merge with a big miner) to some sort of overall
decentralization metric. For
Hello,
For sake of peace, I wanted to give a chance to XT's block size growth efforts
by actually *reading* BIP101 [1] which seems to be their specification.
Thus, please read this mail as something which aims to establish peaceful
cooperation between the non-XT and XT community; not as
On 8/20/2015 3:23 AM, Milly Bitcoin via bitcoin-dev wrote:
For the 73th time or so this month on this list:
The maximum block size consensus rule limits mining centralization
(which is currently pretty bad).
Instead of posting all these messages with bald claims why don't you
work on a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
To answer your question, from my perspective, I am not opposed to
block size increase.. I am hoping it would be in the context of
something like BIP 100 as I've said before.
But I'm extremely opposed to XT.
Would I continue with bitcoin if things
Peter Todd via bitcoin-dev 於 2015-08-19 01:50 寫到:
2) nVersion mask, with IsSuperMajority()
In this option the nVersion bits set by XT/Not-Bitcoin-XT miners would
be masked away, prior to applying standard IsSuperMajority() logic:
block.nVersion ~0x2007
This means that
I dont think a libconsensus would have any kind of networking layer, nor
is C++ an antique tool set (hopefully libconsensus can avoid a boost
dependency, though thats not antique either). Ideally it would have a
simple API to give it blocks and a simple API for it to inform you of
what the current
No, the nVersion would be = 4, so that we don't waste any version values.
On Thu, Aug 20, 2015 at 10:32 AM, jl2012 via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Peter Todd via bitcoin-dev 於 2015-08-19 01:50 寫到:
2) nVersion mask, with IsSuperMajority()
In this option the
On Fri, Aug 21, 2015 at 01:48:23AM -0400, Jeff Garzik via bitcoin-dev wrote:
If this is widely deployed + enabled, what is the impact to current wallets
in use?
See my comment on the recently-opened issue, reproduced below. In short,
not all that much, especially if we adopt my suggestion of
I was looking at this site recently and it's not very clear that by
clicking the name you get their opinion. I would make that a separate
column stated, Technical Opinion.
I think you need to include more of the developers/technical people,
Adam Back, Mark Friedenback, Jorge Timons, (all of who
Thanks, btcdrak, I just added the column and you in the list. (looks nicer)
What I am calling core devs in the website is only commit access
people, should I rename this group ?
I just want a way to improve readability of the website by grouping, I am
open to all subjection on different way of
I know what you mean as I already have such a component with pluggable block
store and networking.
While you are at it you could aim for isolation of bitcoin specific decisions
and algos from generic block chain code.
The magnitude of refactoring you would have to do to get there from main.cpp
On 08/20/15 21:26, Tamas Blummer wrote:
I know what you mean as I already have such a component with pluggable
block store and networking.
I'm not suggesting pluggable networking, I'm suggesting (and I think
everyone thinks the design should be) NO networking. The API is
ValidationResult
16 matches
Mail list logo
