It would be nice to decouple the venue, but even BIP 1 gives that
control to whoever controls the mailing list: "Following a discussion,
the proposal should be sent to the bitcoin-dev list and the BIP editor
with the draft BIP." (BIP 1)
A neater way to do it might be to replace references to the m
> the soft-fork does not become Final for as long as such a hard-fork
has potentially-majority support, or at most three months.
This wording is awkward. What is "potentially-majority"?
>A hard-fork BIP requires adoption from the entire Bitcoin economy,
particularly including those selling desirab
On Wed, Mar 9, 2016 at 6:11 PM, G. Andrew Stone via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Thanks for your offer Luke, but we are happy with our own process and,
> regardless of historical provenance, see this mailing list and the BIP
> process as very Core specific for reas
> On 9 Mar 2016, at 20:21, Bob McElrath wrote:
>
> Dave Hudson [d...@hashingit.com] wrote:
>> A damping-based design would seem like the obvious choice (I can think of a
>> few variations on a theme here, but most are found in the realms of control
>> theory somewhere). The problem, though, is
On 3/9/2016 3:18 PM, Henning Kopp via bitcoin-dev wrote:
> Hi,
>
> > However, I think it could actually increase
> > confidence in the system if the community is able to demonstrate a good
> > process for making such decisions, and show that we can separate the
> > meaningful underlying principles,
On 3/9/2016 1:30 PM, Dave Hudson via bitcoin-dev wrote:
> The hash rate has jumped up by almost 70% in the last 6 to 7 months and that
> implies some pretty serious investments by miners who are quite aware of the
> halving.
There are a few ways in which that information would be irrelevant:
[1.]
Dave Hudson [d...@hashingit.com] wrote:
> A damping-based design would seem like the obvious choice (I can think of a
> few variations on a theme here, but most are found in the realms of control
> theory somewhere). The problem, though, is working working out a timeframe
> over which to run the d
Hi,
> However, I think it could actually increase
> confidence in the system if the community is able to demonstrate a good
> process for making such decisions, and show that we can separate the
> meaningful underlying principles, such as the coin limit and overall
> inflation rate, from what is m
Hi all,
I've been following this discussion closely. Unlike most of the
developers, I'm more of an economist and game theorist than
cryptographer, and I wanted to suggest a possible compromise solution.
Brief review of discussion so far, as background;
There is a clear split in the discussion on
A damping-based design would seem like the obvious choice (I can think of a few
variations on a theme here, but most are found in the realms of control theory
somewhere). The problem, though, is working working out a timeframe over which
to run the derivative calculations.
The problem is the m
Thanks for your offer Luke, but we are happy with our own process and,
regardless of historical provenance, see this mailing list and the BIP
process as very Core specific for reasons that are too numerous to describe
here but should be obvious to anyone who has been aware of the last year of
Bitco
My recent conversations with miners revealed:
* Many have made "extra-large" hardware investments recently.
* Some wonder if we have just reached (or are quickly reaching) a
plateau of hardware-efficiency. This would mean that
hardware-investments might not be made in the critical period
immediat
Daniele Pinna via bitcoin-dev [bitcoin-dev@lists.linuxfoundation.org] wrote:
> This seems unnecessarily complicated ("don't use cannon to kill mosquito" kind
> of thing). If the community were interested in a realtime hashrate rebalancing
> proposal one could simply adjust difficulty at each new bl
13 matches
Mail list logo
