, 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 which he takes under reasonable
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
Aaron,
My understanding is that Gavin and Mike are proceeding with the XT fork, I
hope that understanding is wrong.
As for improving the non-consensus code to handle full blocks more
gracefully. This is something I'm very interested in, block size increase
or not. Perhaps I shouldn't hijack
That strikes me as a dangerous path forward.
I don't actually think there is anything wrong with this: everybody
eventually gets tired of arguing angels-dancing-on-the-head-of-a-pin, and
we're left with the status quo
What gives Bitcoin value aren't its technical merits but the fact that
people
Could we see a PR that adds it to BIP 66? Perhaps we'd all agree quickly
that its so simple we can just add it...
In either case it doesn't seem strictly necessary to me that it was
non-standard before it becomes a soft-fork...
On Tue, Feb 3, 2015 at 7:00 AM, Wladimir laa...@gmail.com wrote:
Oh in just a couple of blocks, it'll give you a somewhat reasonable
estimate for asking about every confirmation count other than 1, but it
could take several hours for it to have enough data points to give you a
good estimate for getting confirmed in one block (because the prevalent
feerate is
significantly lower because there are so many fewer
transactions confirmed because of priorities. I'm certainly open to tuning
some of these variables.
On Tue, Oct 28, 2014 at 10:30 AM, Alex Morcos mor...@gmail.com wrote:
Oh in just a couple of blocks, it'll give you a somewhat reasonable
estimate
to see if it even made sense to make a PR for this or this
isn't the way we wanted to go about it.
On Tue, Oct 28, 2014 at 10:58 AM, Gavin Andresen gavinandre...@gmail.com
wrote:
On Tue, Oct 28, 2014 at 10:30 AM, Alex Morcos mor...@gmail.com wrote:
Do you think it would make sense to make that 90
I've been playing around with the code for estimating fees and found a few
issues with the existing code. I think this will address several
observations that the estimates returned by the existing code appear to be
too high. For instance see @cozz in Issue 4866
I think Mark makes some good arguments.
I realize this would only add to the confusion, but...
What if we did relabel 100 satoshis to be some new kind of unit (bit or
whatever else), with a proper 3 letter code, and then from a user
standpoint, where people are using mBTC, they could switch to
I apologize if this has been discussed many times before.
As a long term solution to malleable transactions, wouldn't it be possible
to modify the signatures to be of the entire transaction. Why do you have
to zero out the inputs? I can see that this would be a hard fork, and
maybe it would be
11 matches
Mail list logo
