Re: [bitcoin-dev] BIP Process: Status, comments, and copyright licenses

[Mustafa Al-Bassam via bitcoin-dev]

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 mailing list
with "public discussion medium" where "medium" can be defined as
something like any discussion forum frequented by the wider development
community, like the pull requests section of the BIP repo, conferences, etc.

On 02/02/16 15:58, Gavin Andresen via bitcoin-dev wrote:
> On Mon, Feb 1, 2016 at 5:53 PM, Luke Dashjr via bitcoin-dev
>  > wrote:
>
> I've completed an initial draft of a BIP that provides
> clarifications on the
> Status field for BIPs, as well as adding the ability for public
> comments on
> them, and expanding the list of allowable BIP licenses.
>
> 
> https://github.com/luke-jr/bips/blob/bip-biprevised/bip-biprevised.mediawiki
>
> I plan to open discussion of making this BIP an Active status
> (along with BIP
> 123) a month after initial revisions have completed. Please
> provide any
> objections now, so I can try to address them now and enable
> consensus to be
> reached.
>
>  
>
> I like the more concrete definitions of the various statuses.
>
> I don't like the definition of "consensus".  I think the definition
> described gives too much centralized control to whoever controls the
> mailing list and the wiki.
>
> -- 
> --
> Gavin Andresen
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 2 promotion to Final

[Mustafa Al-Bassam via bitcoin-dev]

> 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 desirable goods and services in
exchange for bitcoin payments, as well as Bitcoin holders who wish to
spend or would spend their bitcoins (including selling for other
currencies) differently in the event of such a hard-fork.
What if one shop owner, for example, out of thousands, doesn't adapt the
hard-fork? It is expected, and should perhaps be encouraged, for a small
minority to not accept a hard fork, but by the wording of the BIP
("entire Bitcoin economy"), one shop owner can veto a hard-fork.

Mustafa

On 08/03/16 19:04, Luke Dashjr via bitcoin-dev wrote:
> It has been about 1 month since BIP 2 finished receiving comments, so I 
> believe it is an appropriate time to begin the process of moving it to Final 
> Status. Toward this end, I have opened a pull request:
>
> https://github.com/bitcoin/bips/pull/350
>
> The current requirement for this is that "the reference implementation is 
> complete and accepted by the community". Given the vagueness of this 
> criteria, 
> I intend to move forward applying BIP 2's more specific criteria to itself:
>
>> A process BIP may change status from Draft to Active when it achieves rough
>> consensus on the mailing list. Such a proposal is said to have rough
>> consensus if it has been open to discussion on the development mailing list
>> for at least one month, and no person maintains any unaddressed
>> substantiated objections to it. Addressed or obstructive objections may be
>> ignored/overruled by general agreement that they have been sufficiently
>> addressed, but clear reasoning must be given in such circumstances.
> Furthermore, there is a reference implementation in the mentioned PR.
>
> Please review the latest draft BIP and provide any objections ASAP.
> If there are no outstanding objections on 2016 April 9th, I will consider the 
> current draft to have reached rough consensus and update its Status to Final 
> by merging the PR.
>
> Thanks,
>
> Luke
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Services bit for xthin blocks

[Tier Nolan via bitcoin-dev]

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 reasons that are too numerous to describe
> here but should be obvious to anyone who has been aware of the last year of
> Bitcoin history.
>

One of the advantages with the BIP process is that it means that there are
hashlocked descriptions of the specs available for people to implement
against.

The BIP process is not the same as getting a PR accepted into core.  It is
not a veto based process.  If you write the BIP and it doesn't have any
serious technical problems, then it will be accepted into the BIP repo.

Getting it marked as "final" is harder but I don't think that matters
much.  I don't think that core would actually use a service bit that was
claimed in a BIP, even if the BIP wasn't final.  Maybe in 20 years if thin
blocks aren't being used, they might recycle it.  It would be pretty
obviously an aggressive act otherwise.

The NODE_GETUTXO bit is a perfect example of that.  They don't think it is
a good idea, but they still accepted the claim on the bit, because there
are nodes actually using it.

On the other hand, the BIP git repository is hosted on the /bitcoin github
site, so in that context it can be seen as linked with core.  I wouldn't be
surprised if that specific objection was raised when it was moved from the
wiki to github.  Luke may be willing to change that if you think that would
be worth changing?

With regards to the proposal, the description on the forum link isn't
sufficient for an alternative client to implement it.  I had a look at the
thread and I think that this is the implementation?

https://github.com/ptschip/bitcoinxt/commit/7ea5854a3599851beffb1323544173f03d45373b

Is the intention here to simply reserve the bit for thin blocks usage or to
define the specification for inter-operation with other clients?

Perhaps there could be a process for claiming service bits as it can be
useful to claim a bit in advance of actually finalizing the feature.

- Claim bit with a reasonable justification (good faith intent to implement
and the bit is useful for the feature)
- Within 3 months have a finalized description of the feature that lets
other clients implement it
- Within 6 months have working software that deploys the feature
- After 6 months of it actually being in active use, the bit is "locked"
and stays assigned to that feature

There could be an expiry process if it ends up not being used after all.
Requiring a public description of the feature seems like a reasonable
requirement in exchange for the community assigning the service bit, but we
don't want to go to far.  There is no point in having lots of free bits
that end up never being used.  Worst case, the addr message could be
updated to add more bits.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

[Dave Hudson via bitcoin-dev]

> 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 working working out a timeframe
>> over which to run the derivative calculations.
> 
> From a measurement theory perspective this is straightforward.  Each block is 
> a
> measurement, and error propagation can be performed to derive an error on the
> derivatives.

Sure, but I think there are 2 problems:

1) My guess is that errors over anything but a long period are probably too 
large to be very useful.

2) We don't have a strong notion of time that is part of the consensus.  Sure, 
blocks have timestamps but they're very loosely controlled (can't be more than 
2 hours ahead of what any validating node thinks the time might be).  
Difficulty can't be calculated based on anything that's not part of the 
consensus data.

> The statistical theory of Bitcoin's block timing is known as a Poisson Point
> Process: https://en.wikipedia.org/wiki/Poisson_point_process or temporal point
> process.  If you google those plus "estimation" you'll find a metric shit-ton 
> of
> literature on how to handle this.

Strictly it's a non-homogeneous Poisson Process, but I'm pretty familiar with 
the concept (Google threw one of my own blog posts back at me: 
http://hashingit.com/analysis/27-hash-rate-headaches, but I actually prefer 
this one: http://hashingit.com/analysis/30-finding-2016-blocks because most 
people seem to find it easier to visualize).

>> The problem is the measurement of the hashrate, which is pretty inaccurate at
>> best because even 2016 events isn't really enough (with a completely constant
>> hash rate running indefinitely we'd see difficulty swings of up to +/- 5% 
>> even
>> with the current algorithm).  In order to meaningfully react to a major loss
>> of hashing we'd still need to be considering a window of probably 2 weeks.
> 
> You don't want to assume it's constant in order to get a better measurement.
> The assumption is clearly false.  But, errors can be calculated, and 
> retargeting
> can take errors into account, because no matter what we'll always be dealing
> with a finite sample.

Agreed, it's a thought experiment I ran in May 2014 
(http://hashingit.com/analysis/28-reach-for-the-ear-defenders).  I found that 
many people's intuition is that there would be little or no difficulty changes 
in such a scenario, but the intuition isn't reliable.  Given a static hash rate 
the NHPP behaviour introduces a surprisingly large amount of noise (often much 
larger than any signal over a period of even weeks).  Any measurements in the 
order of even a few days has so much noise that it's practically unusable.  I 
just realized that unlike some of my other sims this one didn't make it to 
github; I'll fix that later this week.


Cheers,
Dave
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

[Paul Sztorc via bitcoin-dev]

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.] It is possible that miners expect to breakeven before the halving.
[2.] It is also possible that miners earnestly believe that there will
be no problem -- however:
...  [2a.] This belief may be mistaken.
...  [2b.] Miners may be counting on Core Devs to fix any problems that
come up with anything, this one included.

Also, [3.] many miners believe that the price will increase around the
time of the halving, either for market-microstructure reasons or
marketing reasons. I, personally, think that the price is as likely to
go down as up.

On 3/9/2016 1:30 PM, Dave Hudson via bitcoin-dev wrote:
> These same miners were mining with a coin price around $250 last year so in 
> terms of profitability I'm pretty sure that one around $400 won't be a huge 
> concern.
For some miners, currently it costs $X in electricity per coin mined,
and $400 / 2 is less than X. I do not know how representative this
information is.

Paul

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

[Bob McElrath via bitcoin-dev]

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 derivative calculations.

>From a measurement theory perspective this is straightforward.  Each block is a
measurement, and error propagation can be performed to derive an error on the
derivatives.

The statistical theory of Bitcoin's block timing is known as a Poisson Point
Process: https://en.wikipedia.org/wiki/Poisson_point_process or temporal point
process.  If you google those plus "estimation" you'll find a metric shit-ton of
literature on how to handle this.

> The problem is the measurement of the hashrate, which is pretty inaccurate at
> best because even 2016 events isn't really enough (with a completely constant
> hash rate running indefinitely we'd see difficulty swings of up to +/- 5% even
> with the current algorithm).  In order to meaningfully react to a major loss
> of hashing we'd still need to be considering a window of probably 2 weeks.

You don't want to assume it's constant in order to get a better measurement.
The assumption is clearly false.  But, errors can be calculated, and retargeting
can take errors into account, because no matter what we'll always be dealing
with a finite sample.

Personally I don't think difficulty target variations are such a big deal, if
the algorithm targets that over any long time interval, the average block time
is 10 min.  Bitcoin's current algorithm fails here, with increasing hashrate (as
we have), it issues coins faster than its assumed schedule.

--
Cheers, Bob McElrath

"For every complex problem, there is a solution that is simple, neat, and 
wrong."
-- H. L. Mencken 

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

[Henning Kopp via bitcoin-dev]

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 more akin to an implementation detail, as I
> consider the large-step reward reduction to be.

I do not think that a line can be drawn here. As far as I understood,
you think that the coin limit is a meaningful underlying principle
which should not be touched, whereas the halving of mining rewards is
an implementation detail. The two are very closely tied together and
changes to both of them would result in a hardfork, if I am not
mistaken.

Regarding the effects of the mining reward halving, there is a nice
paper from courtois:
http://arxiv.org/abs/1405.0534

All the best
Henning



On Thu, Mar 03, 2016 at 10:27:35AM -0800, Corey Haddad via bitcoin-dev wrote:
> Since the root cause of what you are trying to address is the reward
> having, I'd suggest considering an adjustment to the having schedule.
> Instead of their being a large supply shock every four years, perhaps the
> reward could drop every 52,500 blocks (yearly), or even at each difficulty
> adjustment, in such a way that the inflation curve is smoothed out.  The
> exponential decay rate would be preserved, so overall economic philosophy
> would be preserved.
> 
> I'm guessing hesitance to this approach would lie in a reluctance to tinker
> with Bitcoin's 'economic contract', and slippery slope concerns about might
> be the next change (21M?).  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 more akin to an implementation detail, as I
> consider the large-step reward reduction to be.
> 
> I'm not too worried about the impact of the having as is, but adjusting the
> economic parameter would be a safer and simpler way to address the concerns
> than to tinker with the difficulty targeting mechanism, which is at the
> heart of Bitcoin's security
> 
> On Wed, Mar 2, 2016 at 6:56 AM, Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> > We are coming up on the subsidy halving this July, and there have been some
> > concerns raised that a non-trivial number of miners could potentially drop
> > off
> > the network. This would result in a significantly longer block interval,
> > which
> > also means a higher per-block transaction volume, which could cause the
> > block
> > size limit to legitimately be hit much sooner than expected. Furthermore,
> > due
> > to difficulty adjustment being measured exclusively in blocks, the time
> > until
> > it adjusts to compensate would be prolonged.
> >
> > For example, if 50% of miners dropped off the network, blocks would be
> > every
> > 20 minutes on average and contain double the transactions they presently
> > do.
> > Even double would be approximately 850-900k, which potentially bumps up
> > against the hard limit when empty blocks are taken into consideration. This
> > situation would continue for a full month if no changes are made. If more
> > miners drop off the network, most of this becomes linearly worse, but due
> > to
> > hitting the block size limit, the backlog would grow indefinitely until the
> > adjustment occurs.
> >
> > To alleviate this risk, it seems reasonable to propose a hardfork to the
> > difficulty adjustment algorithm so it can adapt quicker to such a
> > significant
> > drop in mining rate. BtcDrak tells me he has well-tested code for this in
> > his
> > altcoin, which has seen some roller-coaster hashrates, so it may even be
> > possible to have such a proposal ready in time to be deployed alongside
> > SegWit
> > to take effect in time for the upcoming subsidy halving. If this slips, I
> > think it may be reasonable to push for at least code-readiness before July,
> > and possibly roll it into any other hardfork proposed before or around that
> > time.
> >
> > I am unaware of any reason this would be controversial, so if anyone has a
> > problem with such a change, please speak up sooner rather than later. Other
> > ideas or concerns are of course welcome as well.
> >
> > Thanks,
> >
> > Luke
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >

> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


-- 
Henning Kopp
Institute of Distributed Systems
Ulm University, Germany

Office: O27 - 3402
Phone: +49 731 50-24138
Web: http://www.uni-ulm.de/in/vs/~kopp

Re: [bitcoin-dev] Services bit for xthin blocks

[G. Andrew Stone via bitcoin-dev]

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
Bitcoin history.

Andrew

On Tue, Mar 8, 2016 at 12:19 PM, Luke Dashjr  wrote:

> On Tuesday, March 08, 2016 2:35:21 AM G. Andrew Stone via bitcoin-dev
> wrote:
> > Not an unreasonable request, however while I personally respect the many
> > great accomplishments of individual engineers loosely affiliated with
> > "Core", Bitcoin Unlimited has our own process for documentation and
> > discussion on an uncensored forum located here:
> > https://bitco.in/forum/threads/buip010-passed-xtreme-thinblocks.774/. We
> > would love to have any interested engineer join us there with ideas and
> > criticisms.
>
> Bitcoin-dev and the BIP process are not affiliated with Core at all. In
> fact,
> the BIP process was created by Amir Taaki, who was a libbitcoin developer
> (libbitcoin is not Core).
>
> I encourage Bitcoin Unlimited to use the BIP process for
> cross-implementation
> standards like this, as do other implementations, so that you can benefit
> from
> peer review from the wider Bitcoin development community, as well as have a
> common repository for these standards.
>
> Many BIPs are discussed on reddit in addition to this mailing list, and you
> would certainly remain free to discuss your own proposals on any forum you
> like - it isn't restricted to only this mailing list.
>
> If this is of interest, I will be happy to try to go over and assign BIP
> numbers to the current (15?) BUIPs assuming they meet the basic
> requirements
> for such assignment (see BIP 1:
> https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki). Is there
> an
> easy way to get links to each of the BUIPs? I couldn't find BUIP 1 at all,
> for
> example.
>
> Thanks,
>
> Luke
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

[Paul Sztorc via bitcoin-dev]

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
immediately preceding the halving.

However, some good news:

* For Chinese miners, power is often purchased in fixed quantities, for
long-durations (of around 12 months, and these contracts -fortunately-
do overlap the July halving). Because power is difficult to store, this
implies that miners will *need* to mine, at all times, even at a loss.
So miners may continue to mine after the halving, no matter what.

On the other hand, miners can default on these contracts by simply
declaring bankruptcy, at which point their equipment would be entirely
unusable, by anyone, for a very long time.

So the problem is less likely, but more potentially-catastrophic.

Paul

On 3/2/2016 8:06 PM, Paul Sztorc wrote:
>
> On 3/2/2016 12:53 PM, Gregory Maxwell via bitcoin-dev wrote:
>> What you are proposing makes sense only if it was believed that a very
>> large difficulty drop would be very likely.
>>
>> This appears to be almost certainly untrue-- consider-- look how long
>> ago since hashrate was 50% of what it is now, or 25% of what it is
>> now-- this is strong evidence that supermajority of the hashrate is
>> equipment with state of the art power efficiency.
> I don't understand the relevance of this.
>
> In my view, we would prefer miners to invest in hardware just a mere
> 2016 blocks away from the halving. Instead, they've made them too soon.
> Assuming that miners are already located in low-power-cost areas, the
> difficulty will be quickly rising to compensate for "state of the art
> power efficiency".
>
> So it will have canceled out by July.
>
> If anything, the more efficient miners become today, the bigger our
> potential problem in July, because chip-manufacturers may have used up
> all of the easy efficiency-increasing moves, such that investments do
> not take place in June.
>
> Paul


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev