Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin

[Jeff Garzik via bitcoin-dev]

On Sun, Dec 20, 2015 at 11:35 AM, Peter Todd <p...@petertodd.org> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
>
>
> On 20 December 2015 08:30:45 GMT-08:00, Chris Pacia <ctpa...@gmail.com>
> wrote:
> >On Dec 20, 2015 6:34 AM, "Jeff Garzik via bitcoin-dev" <
> >bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >> 2) This reverses the useful minimization attribute of HD wallets -
> >"just
> >backup the seed"
> >
> >It would be nice if the bip37 filter matching algorithm was extended to
> >serve up the proof.
> >
> >And if server-based wallets did the same it would preserve the "just
> >backup
> >the seed" functionality.
>
> Exactly! The information will be out there - "just backup the seed"
> requires someone to have the exact same data needed to generate the
> TXO-unspent proof that my proposal requires to spend an old txout.
>
> tl;dr: jgarzik is incorrect; theres no difference at all from the status
> quo.
>

The data stored in the legacy case makes it possible to sign and send a
transaction without any connection to a network.  The data stored in the
upgraded case, absent grandfathering, requires significant network sync at
a minimum.

The user experience and security parameters are different.

Thus, issue/recommendation #1.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Increasing the blocksize as a (generalized) softfork.

[Jeff Garzik via bitcoin-dev]

On Sun, Dec 20, 2015 at 12:21 PM, joe2015--- via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Remember this is proposed as an alternative to hardforks, which is also a
> "nuclear option".  Hardforks carry significant risks such as permanently
> splitting Bitcoin into two chains if global consensus is never reached.  A
> (generalized) softfork avoids this problem.


Current hard fork implementations include / will include miner lock-in,
just like any soft fork.  They will not activate if global consensus is not
reached.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin

[Jeff Garzik via bitcoin-dev]

On Sun, Dec 20, 2015 at 6:24 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> What I proprosed is that a consensus-critical maximum UTXO age be part
> of the protocol; UTXO's younger than that age are expected to be cached.
> For UTXO's older than that age, they can be dropped from the cache,
> however to spend them you are required to provide the proof, and that
> proof counts as blockchain space to account for the fact that they do
> need to be broadcast on the network.


Yes, this is almost what -has- to happen in the long term.

Ideally we should start having wallets generate those proofs now, and then
introduce the max-age as a second step as a planned hard fork a couple
years down the line.

However,
1) There is also the open question of "grandfathered" UTXOs - for those
wallets generated in 2009, buried in a landfill and then dug out 10 years
ago

2) This reverses the useful minimization attribute of HD wallets - "just
backup the seed"
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Jeff Garzik via bitcoin-dev]

On Fri, Dec 18, 2015 at 2:56 AM, Pieter Wuille <pieter.wui...@gmail.com>
wrote:

> On Fri, Dec 18, 2015 at 6:11 AM, Jeff Garzik <jgar...@gmail.com> wrote:
> >> You present this as if the Bitcoin Core development team is in charge
> >> of deciding the network consensus rules, and is responsible for making
> >> changes to it in order to satisfy economic demand. If that is the
> >> case, Bitcoin has failed, in my opinion.
> >
> > Diverging from the satoshi block size change plan[1] and current
> economics
> > would seem to require a high level of months-ahead communication to
> users.
>
> I don't see any plan, but will you say the same thing when the subsidy
>

Yes, I forgot the link:

[1] https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366



> dwindles, and mining income seems to become uncertain? It will equally
> be an economic change, which equally well will have been predictable,
> and it will equally well be treatable with a hardfork to increase the
> subsidy.
>

That is a red herring.  Nobody I know has proposed this, and I am opposed
to changing that fundamental.

It is well known that the 1M limit was never intended to stay, unlike 21M
coin limit etc.

1M was set high in the beginning because it is a DoS engineering limit, not
an [accidental] economic policy tool.




> But I am not against a block size increase hard fork. My talk on
> segregated witness even included proposed pursuing a hard fork at a
> slightly later stage.
>

Great!



> But what you're arguing for is that - despite being completely
> expected - blocks grew fuller, and people didn't adapt to block size
> pressure and a fee market, so the Core committee now needs to kick the
> can down the road, because we can't accept the risk of economic
> change. That sounds very much like a bailout to me.
>

I am arguing for continuing what we know works.  We are 100% certain
blocks-not-full-on-avg works, where a "buffer" of space exists between avg
block size and hard limit.

Any other avenue is by definition speculation and risk.  You _think_ you
know what a healthy fee market _should_ be.  Massive damage occurs to
bitcoin if you are wrong - and I listed several

vis expectation, there is clear consensus and expectation that block size
would increase, from 2010 onward.  It was always a question of _when_ not
if.

Sticking with 1M presents clear risk of (a) economic fracture and (b)
community fracture.  It quite clearly risks massive change to an unknown
system at an unknown, unpredictable date in the future.

BIP 102 presents an expected upgrade at a predictable date in the future.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

[Jeff Garzik via bitcoin-dev]

On Thu, Dec 17, 2015 at 1:46 PM, jl2012  wrote:

> This is not correct.
>
> As only about 1/3 of nodes support BIP65 now, would you consider CLTV tx
> are less secure than others? I don't think so. Since one invalid CLTV tx
> will make the whole block invalid. Having more nodes to fully validate
> non-CLTV txs won't make them any safer. The same logic also applies to SW
> softfork.
>


Yes - the logic applies to all soft forks.  Each soft fork degrades the
security of non-upgraded nodes.

The core design of bitcoin is that trustless nodes validate the work of
miners, not trust them.

Soft forks move in the opposite direction.  Each new soft-forked feature
leans very heavily on miner trust rather than P2P network validation.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

[Jeff Garzik via bitcoin-dev]

On Wed, Dec 16, 2015 at 5:09 PM, Jeff Garzik <jgar...@gmail.com> wrote:

> SW presents a blended price and blended basket of two goods.  You can
> interact with the Service through the blended price, but that does not
> erase the fact that the basket contains two separate from similar resources.
>
> A different set of economic actors uses one resource, and/or both.  There
> are explicit incentives to shift actors from solely using one resource to
> using both.
>

Illustration:  If SW is deployed via soft fork, the count of nodes that
validate witness data is significantly lower than the count of nodes that
validate non-witness data.  Soft forks are not trustless operation, they
depend on miner trust, slowly eroding the trustless validation of older
nodes over time.

Higher security in one data area versus another produces another economic
value distinction between the two goods in the basket, and creates a "pay
more for higher security in core block, pay less for lower security in
witness" dynamic.

This economic distinction is not present if SW is deployed via hard fork.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Jeff Garzik via bitcoin-dev]

On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille <pieter.wui...@gmail.com>
wrote:

> On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > 2) If block size stays at 1M, the Bitcoin Core developer team should
> sign a
> > collective note stating their desire to transition to a new economic
> policy,
> > that of "healthy fee market" and strongly urge users to examine their fee
> > policies, wallet software, transaction volumes and other possible User
> > impacting outcomes.
>
> You present this as if the Bitcoin Core development team is in charge
> of deciding the network consensus rules, and is responsible for making
> changes to it in order to satisfy economic demand. If that is the
> case, Bitcoin has failed, in my opinion.
>

Diverging from the satoshi block size change plan[1] and current economics
would seem to require a high level of months-ahead communication to users.




> all. Yes, old full nodes after a soft fork are not able to fully
> validate the rules new miners enforce anymore, but they do still
> verify the rules that their operators opted to enforce. Furthermore,
> they can't be prevented. For that reason, I've proposed, and am
> working hard, on an approach that includes Segregated Witness as a
> first step. It shows the ecosystem that something is being done, it
> kicks the can down the road, it solves/issues half a dozen other
> issues at the same time, and it does not require the degree of
> certainty needed for a hardfork.
>

Segregated Witness does not kick the can, it solves none of the problems
#1, #3 - #8 explicitly defined and listed in email #1.

1)  A plan of "SW + no hard fork" is gambling with ECE risk, gambling there
will be no Fee Event, because the core block size is still heavily
contended -- 100% contended at time out SW rollout.

2) We are only 100% certain that bitcoin works in the
blocks-not-full-on-avg state, where there is a healthy buffer between the
hard limit and the average block size.

There is remains major ECE risk due to the core block size freeze, possibly
pushing the system into a new, untried economic state and causing major
market and actor disruption.  Users of the Service can still drift randomly
and unpredictably into a Fee Event.

SW mitigates this
- only after several months
- only assuming robust adoption rates by up-layer ecosystem software, and
- only assuming transaction volume growth is flat or sub-linear

Those conditions *must* go as planned to fulfill "SW kicked the can" -- a
lot of if's.

As stated, SW is orthogonal to the drift-into-uncharted-waters problem
outlined in email #1, which a short term bump does address.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Jeff Garzik via bitcoin-dev]

On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille <pieter.wui...@gmail.com>
wrote:

> On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > 2) If block size stays at 1M, the Bitcoin Core developer team should
> sign a
> > collective note stating their desire to transition to a new economic
> policy,
> > that of "healthy fee market" and strongly urge users to examine their fee
> > policies, wallet software, transaction volumes and other possible User
> > impacting outcomes.
>
> You present this as if the Bitcoin Core development team is in charge
> of deciding the network consensus rules, and is responsible for making
> changes to it in order to satisfy economic demand. If that is the
> case, Bitcoin has failed, in my opinion.
>

This circles back to Problem #1:   Avoidance of a choice is a still a
choice - failing to ACK a MAX_BLOCK_SIZE increase still creates very real
Economic Change Event risk.

And #3:  If the likely predicted course is that Bitcoin Core will not
accept a protocol change changing MAX_BLOCK_SIZE via hard fork in the short
term, the core dev team should communicate that position clearly to users
and media.

Hitting a Fee Event is market changing, potentially reshuffling economic
actors to a notable degree.  Maintaining a short term economic policy of
fixed 1M supply in the face of rising transaction volume carries risks that
should be analyzed and communicated.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

[Jeff Garzik via bitcoin-dev]

1. Summary

Segregated Witness (SegWitness, SW) is being presented in the context of
Scaling Bitcoin.  It has useful attributes, notably addressing a major
malleability vector, but is not a short term scaling solution.


2. Definitions

Import Fee Event, ECE, TFM, FFM from previous email.

Older clients - Any software not upgraded to SW

Newer clients - Upgraded, SW aware software


Block size - refers to the core block economic resource limited by
MAX_BLOCK_SIZE.  Witness data (or extension block data) is excluded.
Requires a hard fork to change.

Core block - Current bitcoin block, with upper bound MAX_BLOCK_SIZE.  Not
changed by SW.


Extended transaction - Newer, upgraded version of transaction data format.

Extended block - Newer, upgraded version of block data format.


EBS - Extended block size.  Block size seen by newer clients.


3. Context of analysis

One proposal presents SW *in lieu of* a hard fork block size increase.
This email focuses directly on that.

Useful features outside block size context, such as anti-malleability or
fraud proof features, are not covered in depth.


4.1.  Observations on data structure formats and views

SW creates two *views* of each transaction and block.  SW has blocks and
extended blocks.  Similarly, there exists transactions and extended
transactions.

This view is rendered to clients depending on compatibility level.  Newer
clients see extended blocks and extended transactions.  Older clients see
blocks (limit 1M), and do not see extended blocks.  Older clients see
upgraded transactions as unsigned, anyone-can-pay transactions.

Each extended transaction exists in two states, one unsigned and one
signed, each of which passes validation as a valid bitcoin transaction.


4.2.  Observations on behavior of older transaction creation

Transactions created by older clients will not use the extended transaction
format.  All data is stored the standard 1M block as today.


4.3.  Observations on new block economic model

SW complicates block economics by creating two separate, supply limited
resources.

The core block economic resource is heavily contended.  Older clients use
core blocks exclusively.  Newer clients use core blocks more
conservatively, storing as much data as possible in extended blocks.

The extended block economic resource is less heavily contended, though that
of course grows over time as clients upgrade.

Because core blocks are more heavily contended, it is presumed that older
clients will pay a higher fee than newer clients (subject to elasticity
etc.).


5.1.  Problem:  Pace of roll-out will be slow - Whole Ecosystem must be
considered.

The current apparent proposal is to roll out Segregated Witness as a soft
fork, and keep block size at 1M.

The roll-out pace cannot simply be judged by soft fork speed - which is
months at best.  Analysis must the layers above:  Updating bitcoin-core
(JS) and bitcoinj (Java), and then the timelines to roll out those updates
to apps, and then the timeline to update those apps to create extended
transactions.

Overall, wallet software and programmer libraries must be upgraded to make
use of this new format, adding many more months (12+ in some stacks) to the
roll out timeline.  In the meantime, clients continue to contend entirely
for core block space.


5.2.  Problem:   Hard fork to bigger block size Just Works(tm) with most
software, unlike SW.

A simple hard fork such as BIP 102 is automatically compatible with the
vast range of today's ecosystem software.

SW requires merchants to upgrade almost immediately, requires wallet and
other peripheral software upgrades to make use of.  Other updates are
opt-in and occur more slowly.  BIP 70 processors need some updates.

The number of LOC that must change for BIP 102 is very small, and the
problem domain well known, versus SW.


5.3.  Problem:   Due to pace, Fee Event not forestalled.

Even presuming SW is merged into Bitcoin Core tomorrow, this does not
address the risk of a Fee Event and associated Economic Change in the
coming months.


5.4.  Problem:   More complex economic policy, new game theory, new bidding
structure risks.

Splitting blocks into two pieces, each with separate and distinct behaviors
and resource values, creates *two fee markets.*

Having two pricing strata within each block has certainly feasible - that
is the current mining policy of (1) fee/KB followed by (2) priority/age.

Valuable or not - e.g. incentivizing older clients to upgrade - the fact
remains that SW creates a more-complex bidding structure by creating a
second economic resource.

*This is clearly a change to a new economic policy* with standard risks
associated with that.  Will that induce an Economic Change Event (see def
last email)?  *Unlikely*, due to slow rollout pace.


5.5.  Problem:  Current SW mining algorithm needs improvement

Current SW block template maker does a reasonable job, but makes some naive
assumptions about the fee market across an entire extended block.  

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

[Jeff Garzik via bitcoin-dev]

On Wed, Dec 16, 2015 at 3:59 PM, Pieter Wuille <pieter.wui...@gmail.com>
wrote:

> On Wed, Dec 16, 2015 at 9:38 PM, Jeff Garzik via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > 4.3.  Observations on new block economic model
> >
> > SW complicates block economics by creating two separate, supply limited
> > resources.
>
> Not correct. I propose defining the virtual_block_size as base_size +
> witness_size * 0.25, and limiting virtual_block_size to 1M. This
> creates a single variable to optimize for. If accepted, miners are
> incentived to maximize fee per virtual_block_size instead of per size.
>

It is correct.  There are two separate sets of economic actors and levels
of contention for each set of space.

That is true regardless of the proposed miner selection algorithm.



> > 5.4.  Problem:   More complex economic policy, new game theory, new
> bidding
> > structure risks.
> >
> > Splitting blocks into two pieces, each with separate and distinct
> behaviors
> > and resource values, creates two fee markets.
>
> I believe you have misunderstood the proposal in that case.
>

See above.  There are two separate and distinct resource velocities and
demand levels in reality.  That creates two markets regardless of miner
selection algorithm in the block maker.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Jeff Garzik via bitcoin-dev]

On Wed, Dec 16, 2015 at 4:24 PM, Jorge Timón  wrote:

> Assuming we adopt bip102, eventually you will be able to say exactly the
> same about 2 MB. When does this "let's not change the economics" finishes
> (if ever)?
>

The question is answered in the original email.

In the short term, the risk of a Fee Event and lack of solid post-Fee-Event
economic plan implies "short term bump" reduces those risks.

It is also true - as noted in [1], a bump does create the danger of long
term moral hazard.

This is why a bump should be accompanied with at least a weak public
commitment to flexcap or a similar long term proposal, as the original
email recommended.  Communicate clearly the conditions for future change,
then iterate as needs and feedback indicate.



[1] http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

[Jeff Garzik via bitcoin-dev]

Maybe a new analogy helps.

SW presents a blended price and blended basket of two goods.  You can
interact with the Service through the blended price, but that does not
erase the fact that the basket contains two separate from similar resources.

A different set of economic actors uses one resource, and/or both.  There
are explicit incentives to shift actors from solely using one resource to
using both.

The fact that separate sets of economic actors and incentives exist is
sufficient to prove it is indeed a basket of goods, not a single good.


On Wed, Dec 16, 2015 at 4:36 PM, Pieter Wuille 
wrote:

> Thus, the miners' best strategy is to accept the witness transactions,
> as it allows 100/110=9090 transactions rather than
> 100/200=5000.
>

Under your blended algorithm, this seems reasonable as a first pass.



> In fact, the optimal fee maximizing strategy is always to maximize fee
> per virtual size.
>

This is a microscopic, not macroscopic analysis.  Externalities and long
term incentives can severely perturb or invalidate that line of thinking.

Typical counter-example:  Many miners are perfectly happy with very low
fees to encourage long term growth of their bitcoin income through network
effect growth -- rendering fee micro-optimizations largely in the realm of
DoS prevention rather than miner incentive.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

[Jeff Garzik via bitcoin-dev]

On Wed, Dec 16, 2015 at 5:09 PM, Jeff Garzik <jgar...@gmail.com> wrote:

> SW presents a blended price and blended basket of two goods.  You can
> interact with the Service through the blended price, but that does not
> erase the fact that the basket contains two separate from similar resources.
>

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

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

[Jeff Garzik via bitcoin-dev]

On Wed, Dec 16, 2015 at 9:44 PM, Eric Lombrozo  wrote:

> At least SW *is* a scaling solution (albeit most of the important benefits
> are long term). The issue of fee events has nothing to do with scaling - it
> has to do with economics...specifically whether we should be subsidizing
> transactions, who should pay the bill for it, etc. My own personal opinion
> is that increasing validation costs works against adoption, not for
> it...even if it artificially keeps fees low - and we'll have to deal with a
> fee event sooner or later anyhow. You may disagree with my opinion, but
> please, let's stop confounding the economic issues with actual scaling.
>

At least on my part, the title of the 1st email was "It's economics & ..."
and focused on (a) economics and (b) transition issues.  There was no
confounding.  There was a list of real problems and risks taken when 1M is
not lifted in the short term.

Thus "SW is orthogonal" in these emails, because these problems remain
regardless of SW or no, as the 1st email outlined.

The 2nd email addresses the specific assertion of "no 1M hard fork needed,
because SW."
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

[Jeff Garzik via bitcoin-dev]

On Wed, Dec 16, 2015 at 3:50 PM, Matt Corallo 
wrote:

> A large part of your argument is that SW will take longer to deploy than a
> hard fork, but I completely disagree. Though I do not agree with some
> people claiming we can deploy SW significantly faster than a hard fork,
> once the code is ready (probably a six month affair) we can get it deployed
> very quickly. It's true the ecosystem may take some time to upgrade, but I
> see that as a feature, not a bug - we can build up some fee pressure with
> an immediate release valve available for people to use if they want to pay
> fewer fees.
>

That's taking a big risk.  "Build up some fee pressure" is essentially
risking a Fee Event if uptake is slower than planned, or traffic is greater
than expected.



>
> On the other hand, a hard fork, while simpler for the ecosystem to upgrade
> to, is a 1-2 year affair (after the code is shipped, so at least 1.5-2.5
> from today if we all put off heads down and work). One thing that has
> concerned me greatly through this whole debate is how quickly people seem
> to think we can roll out a hard fork. Go look at the distribution of node
> versions on the network today and work backwards to get nearly every node
> upgraded... Even with a year between fork-version-release and
> fork-activation, we'd still kill a bunch of nodes and instead of reducing
> their security model, lead them to be outright robbed.
>

A hard fork will never achieve 100%  There are many credible folks and
estimates who feel a May hard fork is reasonable and doable.

Further, hard forks restore the full trustless nature of the post-hard-fork
nodes.  Soft forks continually erode that.  That's why SW should come via
hard fork.  The end result is more secure - 100% validation of witness
transactions.

If regular hard fork plans are proposed in public, many months in advance,
there is plenty of time for the community to react.  Hard forks create a
more predictable market and environment for Users, and a more secure
network.

Further, even if you believe SW makes hard fork unnecessary, it is the
responsible thing to code and communicate to users the plan for a Fee Event
just in case SW uptake and extension block use does not match theoretical
projections of SW proponents.

Finally, SW does not eliminate and is orthogonal to Short Term Problem #1
(orig. email - drift into ECE)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Jeff Garzik via bitcoin-dev]

All,

Following the guiding WP principle of Assume Good Faith, I've been trying
to boil down the essence of the message following Scaling Bitcoin.  There
are key bitcoin issues that remain outstanding and pressing, that are*
orthogonal to LN & SW*.

I create multiple proposals and try multiple angles because of a few,
notable systemic economic and analysis issues - multiple tries at solving
the same problems.  Why do I do what I do -- Why not try to reboot... just
list those problems?

Definitions:

FE - "Fee Event", the condition where main chain MSG_BLOCK is 95+% to hard
limit for 7 or more days in row, "blocks generally full"   This can also be
induced by a miner squeeze (collective soft limit reduction).


Service - a view of bitcoin as a decentralized, faceless, multi-celled,
amorphous automaton cloud, that provides services in exchange for payment

Users - total [current | future] set of economic actors that pay money to
the Service, and receive value (figuratively or literally) in return

Block Size - This is short hand for MAX_BLOCK_SIZE, the hard limit that
requires, today, a hard fork to increase (excl. extension blocks etc.)


Guiding Principle:

Keep the Service alive, secure, decentralized, and censorship resistant for
as many Users as possible.


Observations on block size (shorthand for MAX_BLOCK_SIZE as noted above):

This is economically modeled as a supply limited resource over time.  On
average, 1M capacity is available every 10 minutes, with variance.


Observations on Users, block size and modern bidding process:

A supermajority of hashpower currently evaluates for block inclusion based,
first-pass, on tx-fee/KB.  Good.

The Service is therefore responsive to the free market and some classes of
DoS.  Good.

Recent mempool changes float relay fee, making the Service more responsive
to fast moving markets and DoS's.  Good progress.


Service provided to Users can be modeled at the bandwidth resource level as
bidding for position in a virtual priority queue, where up-to-1M bursts are
cleared every 10 min (on avg etc.).  Not a perfectly fixed supply,
definitionally, but constrained within a fixed range.


Observations on the state of today's fee market:

On average, blocks are not full.  Economically, this means that fees trend
towards zero, due to theoretically unlimited supply at <1M levels.

Of course, fees are not zero.  The network relay anti-flood limits serve as
an average lower limit for most transactions (excl direct-to-miner).
Wallet software also introduces fee variance in interesting ways.  All this
fee activity is range-bound on the low end.

Let the current set of Users + transaction fee market behavior be TFM
(today's fee market).
Let the post-Fee-Event set of Users + transaction fee market behavior be
FFM (future fee market).

*Key observation:   A Bitcoin Fee Event (see def. at top) is an Economic
Change Event.*

An Economic Change Event is a period of market chaos, where large changes
to prices and sets of economic actors occurs over a short time period.

A Fee Event is a notable Economic Change Event, where a realistic
projection forsees higher fee/KB on average, pricing some economic actors
(bitcoin projects and businesses) out of the system.

*It is a major change to how current Users experience and pay for the
Service*, state change from TFM to FFM.

The game theory bidding behavior is different for a mostly-empty resource
versus a usually-full resource.  Prices are different.  Profitable business
models are different.  Users (the set of economic actors on the network)
are different.


Observation:  Contentious hard fork is an Economic Change Event.

Similarly, a fork that partitions economic actors for an extended period or
permanently is also an Economic Change Event, shuffling prices and economic
actors as the Service dynamically readjusts on both sides of the partition,
and Users-A and Users-B populations change their behavior.



Short-Term Problem #1:  No-action on block size increase leads to an
Economic Change Event.


Failure to increase block size is not obviously-conservative, it is a
conscious choice, electing for one economic state and set of actors and
prices over another.  Choosing FFM over TFM.

*It is rational to reason that maintaining TFM is more conservative* than
enduring an Economic Change Event from TFM to FFM.

*It is rational to reason that maintaining similar prices and economic
actors is less disruptive.*

Failure to increase block size will lead to a Fee Event sooner rather than
later.

Failure to plan ahead for a Fee Event will lead to greater market chaos and
User pain.


Short-Term Problem #2:  Some Developers wish to accelerate the Fee Event,
and a veto can accomplish that.

In the current developer dynamics, 1-2 key developers can and very likely
would veto any block size increase.

Thus a veto (e.g. no-action) can lead to a Fee Event, which leads to
pricing actors out of the system.

A block size veto wields outsize economic power, 

Re: [bitcoin-dev] Standard BIP Draft: Turing Pseudo-Completeness

[Jeff Garzik via bitcoin-dev]

There is no need for a BIP draft.  "Turing complete" is just a fancy,
executive-impressing term for "it can run any computer program", or put
even more simply, "it can loop"

Furthermore, the specification of such a language is trivial.  It is the
economics of validation that is the complex piece.  Proving whether or not
a program will halt as expected - The Halting Problem - is near impossible
for most complex programs.  As a result, your proof is... running the
program.  That produces enormous validation consequences and costs for
generic-execution scripts when applied to a decentralized network of
validation P2P nodes.

If you need that capability, it is just as easy to use a normal C/C++/etc.
computer language, with your preferred algorithm libraries and development
tools.

See https://github.com/jgarzik/moxiebox for a working example of provable
execution.



On Thu, Dec 10, 2015 at 9:35 AM, Luke Durback via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hello Bitcoin-Dev,
>
> I hope this isn't out of line, but I joined the mailing list to try to
> start a discussion on adding opcodes to make Script Turing Pseudo-Complete
> as Wright suggested is possible.
>
> ---
>
> In line with Wright's suggestion, I propose adding a return stack
> alongside the, already existing, control stack.
>
> The principle opcodes (excluding conditional versions of call and
> return_from) needed are
>
> OP_DEFINITION_START FunctionName:  The code that follows is the definition
> of a new function to be named TransactionSenderAddress.FunctionName.  If
> this function name is already taken, the transaction is marked invalid.
> Within the transaction, the function can be called simply as FunctionName.
>
> OP_DEFINITION_END:  This ends a function definition
>
> OP_FUNCTION_NAME FunctionName:  Gives the current transaction the name
> FunctionName (this is necessary to build recursive functions)
>
> ---
>
> OP_CALL Namespace.FunctionName Value TransactionFee:  This marks the
> transaction as valid.  It also pushes the current execution location onto
> the return stack, debits the calling transaction by the TransactionFee and
> Value, and creates a new transaction specified by Namespace.FunctionName
> with both stacks continued from before (this may be dangerous, but I see no
> way around it) with the specified value.
>
> OP_RETURN_FROM_CALL_AND_CONTINUE:  This pops the top value off the return
> stack and continues from the specified location with both stacks in tact.
>
> ---
>
> It would also be useful if a transaction can create another transaction
> arbitrarily, so to prepare for that, I additionally propose
>
> OP_NAMESPACE:  Pushes the current namespace onto the control stack
>
> This, combined with the ability to make new transactions arbitrarily would
> allow a function to pay its creator.
>
>
>
> I understand that this isn't all that is needed, but I think it's a
> start.  I hope this proposal has met you all well,
>
> Luke Durback
>
> ___
> 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

[bitcoin-dev] Scaling Bitcoin - summarizing non-jgarzik block size BIPs

[Jeff Garzik via bitcoin-dev]

To collect things into one place, I was asked by Kanzure to cover
non-jgarzik block size BIPs in a quick summary, and the Scaling Bitcoin
conf folks have graciously allocated a bit of extra time for this.

e.g. BIP 100.5, 103, 105, 106 - "the serious ones"

If there is some input people would like to add to the meat grinder prior
to Dec 7, email j...@bloq.com

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

Re: [bitcoin-dev] Test Results for : Datasstream Compression of Blocks and Tx's

[Jeff Garzik via bitcoin-dev]

Thanks for providing an in-depth, data driven analysis.

It is surprising that zlib provides better compression at the high end.  I
wonder if that is due to our specific data patterns - many zeroes - which
probably puts us into the zlib dictionary fast path.



On Sat, Nov 28, 2015 at 4:41 PM, Peter Tschipper via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi All,
>
> Here are some final results of testing with the reference implementation
> for compressing blocks and transactions. This implementation also
> concatenates blocks and transactions when possible so you'll see data sizes
> in the 1-2MB ranges.
>
> Results below show the time it takes to sync the first part of the
> blockchain, comparing Zlib to the LZOx library.  (LZOf was also tried but
> wasn't found to be as good as LZOx).  The following shows tests run with
> and without latency.  With latency on the network, all compression
> libraries performed much better than without compression.
>
> I don't think it's entirely obvious which is better, Zlib or LZO.
> Although I prefer the higher compression of Zlib, overall I would have to
> give the edge to LZO.  With LZO we have the fastest most scalable option
> when at the lowest compression setting which will be a boost in performance
> for users that want peformance over compression, and then at the high end
> LZO provides decent compression which approaches Zlib, (although at a
> higher cost) but good for those that want to save more bandwidth.
>
> Uncompressed 60ms Zlib-1 (60ms) Zlib-6 (60ms) LZOx-1 (60ms) LZOx-999
> (60ms) 219 299 296 294 291 432 568 565 558 548 652 835 836 819 811 866
> 1106 1107 1081 1071 1082 1372 1381 1341 1333 1309 1644 1654 1605 1600 1535
> 1917 1936 1873 1875 1762 2191 2210 2141 2141 1992 2463 2486 2411 2411 2257
> 2748 2780 2694 2697 2627 3034 3076 2970 2983 3226 3416 3397 3266 3302 4010
> 3983 3773 3625 3703 4914 4503 4292 4127 4287 5806 4928 4719 4529 4821 6674
> 5249 5164 4840 5314 7563 5603 5669 5289 6002 8477 6054 6268 5858 6638 9843
> 7085 7278 6868 7679 11338 8215 8433 8044 8795
>
> These results from testing on a highspeed wireless LAN (very small latency)
>
> Results in seconds
>
>
>
>
> Num blocks sync'd Uncompressed Zlib-1 Zlib-6 LZOx-1 LZOx-999 1 255 232
> 233 231 257 2 464 414 420 407 453 3 677 594 611 585 650 4 887
> 782 795 760 849 5 1099 961 977 933 1048 6 1310 1145 1167 1110 1259
> 7 1512 1330 1362 1291 1470 8 1714 1519 1552 1469 1679 9 1917
> 1707 1747 1650 1882 10 2122 1905 1950 1843 2111 11 2333 2107 2151
> 2038 2329 12 2560 2333 2376 2256 2580 13 2835 2656 2679 2558 2921
> 14 3274 3259 3161 3051 3466 15 3662 3793 3547 3440 3919 16
> 4040 4172 3937 3767 4416 17 4425 4625 4379 4215 4958 18 4860 5149
> 4895 4781 5560 19 5855 6160 5898 5805 6557 20 7004 7234 7051 6983
> 7770
>
> The following show the compression ratio acheived for various sizes of
> data.  Zlib is the clear
> winner for compressibility, with LZOx-999 coming close but at a cost.
>
> range Zlib-1 cmp%
> Zlib-6 cmp% LZOx-1 cmp% LZOx-999 cmp% 0-250b 12.44 12.86 10.79 14.34
> 250-500b  19.33 12.97 10.34 11.11 600-700 16.72 n/a 12.91 17.25 700-800
> 6.37 7.65 4.83 8.07 900-1KB 6.54 6.95 5.64 7.9 1KB-10KB 25.08 25.65 21.21
> 22.65 10KB-100KB 19.77 21.57 14.37 19.02 100KB-200KB 21.49 23.56 15.37
> 21.55 200KB-300KB 23.66 24.18 16.91 22.76 300KB-400KB 23.4 23.7 16.5 21.38
> 400KB-500KB 24.6 24.85 17.56 22.43 500KB-600KB 25.51 26.55 18.51 23.4
> 600KB-700KB 27.25 28.41 19.91 25.46 700KB-800KB 27.58 29.18 20.26 27.17
> 800KB-900KB 27 29.11 20 27.4 900KB-1MB 28.19 29.38 21.15 26.43 1MB -2MB
> 27.41 29.46 21.33 27.73
> The following shows the time in seconds to compress data of various
> sizes.  LZO1x is the
> fastest and as file sizes increase, LZO1x time hardly increases at all.
> It's interesing
> to note as compression ratios increase LZOx-999 performs much worse than
> Zlib.  So LZO is faster
> on the low end and slower (5 to 6 times slower) on the high end.
>
> range Zlib-1 Zlib-6 LZOx-1 LZOx-999 cmp% 0-250b0.001 0 0 0 250-500b
> 0 0 0 0.001 500-1KB 0 0 0 0.001 1KB-10KB0.001 0.001 0 0.002
> 10KB-100KB   0.004 0.006 0.001 0.017 100KB-200KB  0.012 0.017 0.002 0.054
> 200KB-300KB  0.018 0.024 0.003 0.087 300KB-400KB  0.022 0.03 0.003 0.121
> 400KB-500KB  0.027 0.037 0.004 0.151 500KB-600KB  0.031 0.044 0.004 0.184
> 600KB-700KB  0.035 0.051 0.006 0.211 700KB-800KB  0.039 0.057 0.006 0.243
> 800KB-900KB  0.045 0.064 0.006 0.27 900KB-1MB   0.049 0.072 0.006 0.307
>
> ___
> 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] Contradiction in BIP65 text?

[Jeff Garzik via bitcoin-dev]

On Fri, Nov 13, 2015 at 4:48 PM, xor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> This clearly says that funds can be frozen.
> Can the BIP65-thing be used to freeze funds or can it not be?
>


This language definitely trips up or worries several folks - it's been
mentioned a few times before.

The user _chooses_ to freeze _their own_ funds.  It is not an unwilling act
of force, which many assume when they see the phrase "freeze funds."
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db

[Jeff Garzik via bitcoin-dev]

On Wed, Oct 28, 2015 at 4:28 PM, Sean Lynch  wrote:

> On Fri, Oct 23, 2015 at 1:23 AM Lucas Betschart via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Facebook has a LevelDB fork which is maintained.
>> It's called RocksDB and the API seems to be nearly the same as for
>> LevelDB, thus maybe easy to replace: http://rocksdb.org/
>> https://github.com/facebook/rocksdb
>>
>> Although I don't know if we might have some negative effects for our
>> use-case since RocksDB was optimized for big databases running on multiple
>> cores.
>>
>
> While RocksDB is pretty decent, note that it's optimized for flash. Not
> sure how well it will work on spinning disks.
>

That's OK for our purposes.  We have a huge database which already
incentivized having zero seek time.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Proposed list moderation policy and conduct

[Jeff Garzik via bitcoin-dev]

Introduction
---
This mailing list, bitcoin-dev, aim to facilitate constructive discussion
of issues related to technical development of the bitcoin protocol and the
Bitcoin Core reference implementation.  We can achieve this, in part, by
behaving well towards each other, so that the broadest diversity of
participants - both amateur and professional, new and experienced - feel
that the lists are welcoming and useful.

This proposed policy helps maintain that environment by capturing the
conduct we aspire to when we participate in discussions on bitcoin-dev.

We Strive To:
-

*Be friendly and patient*

1. Many of us are volunteers, and so a sense of fun is part of why we do
what we do. Be positive and engaging, rather than snarky.
2. If someone asks for help it is because they need it. Politely suggest
specific documentation or more appropriate venues where appropriate. Avoid
aggressive or vague responses.

*Be civil and considerate*

1. Disagreement is no excuse for poor conduct or personal attacks. A
community where people feel uncomfortable is not a productive one.
2. If you would not feel comfortable saying something to a co-worker or
acquaintance, it is probably not appropriate on this list either.

*Assume good faith*

1. Remember that protocol & engineering questions are often very complex
and difficult to assess. If you disagree, please do so politely, by
disputing logical errors and factual premises rather than by attacking
individuals.
2. If something seems outrageous, check that you did not misinterpret it.
Ask for clarification, rather than assuming the worst.
3. For more, read https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith

*Respect time and attention*

1. List members are often busy people. As a result, we value concision and
clarity. Emails that are brief and to the point take more time to write,
but are repaid many times over when other members of the list make the same
effort.
2. Conversations should remain focused and on-topic. If you must change the
topic, start a new thread by changing the topic line of your emails. Also,
avoid flooding the list with long threads by reading the entire thread
first, instead of responding quickly to many emails in a short period of
time.
3. New members are welcome, but should be careful to respect the time and
energy of long-time list members by doing research in FAQs and with search
engines before asking questions.
4. Off-topic threads will be directed to other venues.

*Disclose potential conflicts*

1. List discussions often involve interested parties. We expect
participants to be aware when they are conflicted due to employment or
other projects they are involved in, and disclose those interests to other
project members.
2. When in doubt, over-disclose. Perceived conflicts of interest are
important to address, so that the lists’ decisions are credible even when
unpopular, difficult or favorable to the interests of one group over
another.



Interpretation
--

This policy is not exhaustive or complete. It is not a rulebook; it serves
to distill our common understanding of a collaborative, shared environment
and goals. We expect it to be followed in spirit as much as in the letter.

Enforcement
---

Most members of the bitcoin-dev community already comply with this policy,
not because of the existence of the policy, but because they have long
experience participating in open source communities where the conduct
described above is normal and expected. However, failure to observe the
code may be grounds for reprimand, probation, or removal from the lists.

If you have concerns about someone’s conduct:

* *Direct contact*: it is always appropriate to email a list member,
mention that you think their behavior was out of line, and (if necessary)
point them to this document.

* *On-list*: discussing conduct on-list, either as part of another message
or as a standalone thread, is always acceptable. Note, though, that
approaching the person directly can be better, as it tends to make them
less defensive, and it respects the time of other list members, so you
probably want to try direct contact first.

* *Moderators*: You can reach the list moderators through the addresses
they use for on-list communication.


Moderators
--
The selection of moderators is intended to be a mix from various projects
and roles, and expressly intended to avoid cases where the set of
(moderators) equals the set of (bitcoin core committers) or similar.

TBD
Jeff Garzik
[btcdrak?  Johnathan?   Others were listed in the IRC meeting, but the
bitcoinstats site is down right here]



Further Context
---

Other resources, while not formally part of this code of conduct, can
provide useful context and guidance for good behavior.

1. Chapter 6 of Producing OSS, by OSI board member Karl Fogel, describes
common best practices for mailing list participation,
particularly [“You Are What You Write”](

Re: [bitcoin-dev] Fwd: Bitcoin Core 0.12.0 release schedule

[Jeff Garzik via bitcoin-dev]

On Thu, Oct 1, 2015 at 5:41 AM, Marcel Jamin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I guess the question then becomes why bitcoin still is <1.0.0
>

I've said the same thing years ago.  Originally the "1.0" was a target for
whenever "client mode" as planned by Satoshi was implemented, making the
Bitcoin Core implementation feature-complete for as a minimum
working/viable project.

Ultimately it is not so important and tends to generate a lot of discussion
 - so maybe we should just do the emacs thing and go from 0.12 to 12.0 for
next version.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Scheduling refactors (was Re: Bitcoin Core 0.12.0 release schedule)

[Jeff Garzik via bitcoin-dev]

On Thu, Sep 24, 2015 at 7:25 AM, Wladimir J. van der Laan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 2015-11-01
> ---
> - Open Transifex translations for 0.12
> - Soft translation string freeze (no large or unnecessary changes)
> - Finalize and close translation for 0.10
>
> 2015-12-01
> ---
> - Feature freeze
> - Translation string freez



Proposed:   Schedule a time window for merging big refactors such as
libconsensus - assuming its ready as discussed per current plan - such as
October 25-31 or November 1-7.

(and implicitly, do not merge big refactors into 0.12 outside that window)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Crossing the line? [Was: Re: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!]

[Jeff Garzik via bitcoin-dev]

To reduce the list noise level, drama level and promote inclusion, my own
personal preference (list admin hat: off, community member hat: on) is for
temporal bans based on temporal circumstances.  Default to
pro-forgiveness.  Also, focus on disruption of the list as a metric, rather
than focusing on a specific personality.

I do think we're at a bit of a point where we're going around in circles.

Given the current reddit hubbub, a bit of a cooling off period is IMO
advisable before taking any further action.



On Thu, Oct 1, 2015 at 12:08 AM, Tao Effect via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Dear list,
>
> Mike has made a variety of false and damaging statements about Bitcoin, of
> which this is but one:
>
> On Sep 30, 2015, at 2:01 PM, Mike Hearn via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I coined the term SPV so I know exactly what it means, and bitcoinj
> implements it, as does BreadWallet (the other big SPV implementation).
>
>
> On his website Vinumeris.com he writes:
>
> Vinumeris was founded in 2014 by Mike Hearn, one of the developers of the
> Bitcoin digital currency system.
>
>
> On plan99.net there are several embedded videos that refer to him a “core
> developer” of Bitcoin. And now it seems he is claiming to be Satoshi.
>
> It seems to me that Mike’s emails, false statements (like the one above
> about coining SPV), arguments, and his attempts to steal control of Bitcoin
> via the contentious Bitcoin XT fork, represent actions that have been
> harming and dividing this community for several years now.
>
> In many communities/tribes, there exists a line that, once crossed,
> results in the expulsion of a member from the community.
>
> So, two questions:
>
> 1. Does the Bitcoin-devs mailing list have such a line?
> 2. If so, does the community feel that Mike Hearn has crossed it? (I
> personally feel he has. Multiple times.)
>
> Thanks for your thoughts,
> Greg Slepak
>
> --
> Please do not email me anything that you are not comfortable also sharing with
> the NSA.
>
>
> ___
> 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] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

[Jeff Garzik via bitcoin-dev]

On Wed, Sep 30, 2015 at 1:11 PM, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Several people have asked several times now: given the very real and
> widely acknowledged downsides that come with a soft fork, *what* is the
> specific benefit to end users of doing them?
>

Field experience shows it successfully delivers new features to end users
without a global software upgrade.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Design Competition

[Jeff Garzik via bitcoin-dev]

This sounds like a cool competition; it is also off-topic for this mailing
list, which is focused on bitcoin protocol and reference implementation
development.


On Wed, Sep 30, 2015 at 2:37 AM, Richard Olsen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> All,
>
> We are looking for participants in a Bitcoin related competition: the aim
> is to build a trading platform (initially for foreign exchange, other
> assets will follow) which lets participants settle their trades through the
> blockchain via coloured coins. To facilitate a quicker trade
> reconciliation, the use of a sidechain is a suggestion but by no means a
> requirement. There will be an online briefing event today where we will
> outline the requirements in more detail, though much of it we have posted
> on our website www.lykkex.com .
>
> As we want this to be a community driven effort rather than something
> turning into a proprietary technology, all contributions will be made
> available under a MIT license on Github.
>
> I look forward to answering your questions at the online briefing event
> or over email,
>
> Thank you and kind regards,
> Richard Olsen
>
>
> ___
> 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] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

[Jeff Garzik via bitcoin-dev]

On Wed, Sep 30, 2015 at 3:56 PM, Mike Hearn  wrote:

> Field experience shows it successfully delivers new features to end users
>> without a global software upgrade.
>>
>
> The global upgrade is required for all full nodes in both types. If a full
> node doesn't upgrade then it no longer does what it was designed to do; if
> the user is OK with that, they should just run an SPV wallet or use
> blockchain.info or some other mechanism that consumes way fewer resources.
>
> But if you want the software you installed to achieve its stated goal, you
> *must* upgrade. There is no way around that.
>

It is correct that security is slightly reduced for full nodes that have
not upgraded.  It is not correct that the choice is binary, full node or
SPV.

Any user running a not-upgraded full node still retains protection against
many attacks outside the subset related to the feature being introduced.

The field observable end result is that we do receive new features, secured
by hashpower and user full nodes, via soft fork, without a global flag day
upgrade.

Yes, a flag day hard fork upgrade is cleaner and results in higher security
due to the entire network validating the new rules.  However, the
difficulty of executing hard forks would mean fewer total features to
users, if that route were chosen instead.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] libconsensus and bitcoin development process

[Jeff Garzik via bitcoin-dev]

There seemed to be some agreement on IRC - after a bit of haranguing by
myself :) -- that large refactors should (a) occur over a small window of
time and (b) have a written plan beforehand.



On Tue, Sep 22, 2015 at 7:49 PM, Dave Scotese <dscot...@litmocracy.com>
wrote:

> If I'm reading this situation correctly, Jeff is basically pointing out
> that developers need more links (hooks, rungs, handholds, data points,
> whatever you want to call them) so that they can see all the things his
> email insinuated are missing (a plan, order, sense, etc.).  He didn't say
> these things were missing, but that it kind of feels like it from the
> 10,000 foot view.
>
> If you use Google to search the list, as in < lists.linuxfoundation.org libconsensus plan>> you DO NOT get the page
> Jorge gave.  He wrote that page, so he had a good idea what to search for
> to find it again.  I just want to recommend that when you describe the work
> you're doing on bitcoin, imagine several different ways people might try to
> find this description in the future and make them work.  In other words,
> Jorge could have put "A plan for abstracting out libconsensus" in the email
> where he wrote "Here are some things that need to happen first..."
>
> Likewise, if Jeff had searched for < libconsensus plan>> (maybe he did, but he didn't list any results), he may
> have found enough clues to see Jorge's overall plan.  The "site:" keyword
> on Google fascinated me when I discovered it, so I let it inspire this
> email :-)
>
> Maybe someone can explain this if I have it wrong: A few people are able
> to pull code into Bitcoin/bitcoin.  Isn't is possible that those few people
> can agree to merge in a lot of refactor-hell PRs for those making the
> requests, but postpone them to that one-week-per-month that someone
> suggested?  The idea of letting that "hell" come in (predictable) waves is
> excellent and I was hoping to see some agreement.  But I don't know who
> those few are, so even if they all wrote "Yeah, we'll do that," I wouldn't
> recognize that I got what I wanted.
>
> notplato
>
> On Tue, Sep 22, 2015 at 11:12 AM, Jorge Timón <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Tue, Sep 15, 2015 at 6:10 AM, Jeff Garzik via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > [collating a private mail and a github issue comment, moving it to a
>> > better forum]
>> >
>> > On libconsensus
>> > ---
>> > In general there exists the reasonable goal to move consensus state
>> > and code to a specific, separate lib.
>> >
>> > To someone not closely reviewing the seemingly endless stream of
>> > libconsensus refactoring PRs, the 10,000 foot view is that there is a
>> > rather random stream of refactors that proceed in fits and starts
>> > without apparent plan or end other than a one sentence "isolate
>> > consensus state and code" summary.
>> >
>> > I am hoping that
>> > * There is some plan
>> > * We will not see a five year stream of random consensus code movement
>> > patches causing lots of downstream developer headaches.
>> >
>> > I read every code change in every pull request that comes into
>> > github/bitcoin/bitcoin with three exceptions:
>> > * consensus code movement changes - too big, too chaotic, too
>> > frequent, too unfocused, laziness guarantees others will inevitably
>> > ACK it without me.
>> > * some non-code changes (docs)
>> > * ignore 80% of the Qt changes
>> >
>> > As with any sort of refactoring, they are easy to prove correct, easy
>> > to reason, and therefore quick and easy to ACK and merge.
>> >
>> > Refactors however have a very real negative impact.
>> > bitcoin/bitcoin.git is not only the source tree in the universe.
>> > Software engineers at home, at startups, and at major companies are
>> > maintaining branches of their own.
>> >
>> > It is very very easy to fall into a trap where a project is merging
>> > lots of cosmetic changes and not seeing the downstream ripple effects.
>> > Several people complained to me at the conference about all the code
>> > movement changes breaking their own work, causing them to stay on
>> > older versions of bitcoin due to the effort required to rebase to each
>> > new release version - and I share those complaints.
>> >
>> > Complex code changes with longer development cycles than simple code
>> > movement patches keep breaking.  It is very

[bitcoin-dev] On bitcoin-dev list admin and list noise

[Jeff Garzik via bitcoin-dev]

This was discussed in IRC, but (did I miss it?) never made it to the list
outside of being buried in a longer summary.

There is a common complain that bitcoin-dev is too noisy.  The response
plan is to narrow the focus of the list to near term technical changes to
the bitcoin protocol and its implementations (bitcoin core, btcd, ...)

Debates over bitcoin philosophy, broader context, etc. will start seeing
grumpy list admins squawk about "off-topic!"

It is a fair criticism, though, that "take it elsewhere!" needs to have
some place as a suggested destination.  The proposal is to create a second
list, bitcoin-tech-discuss or perhaps just 'bitcoin', with a more general
rubric.  This split has served IRC well and generally manages to keep the
noise down to a productive level.  We want this list to achieve that same
goal; if bitcoin-dev is not productive then it's not useful.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin mining idea

[Jeff Garzik via bitcoin-dev]

On Tue, Sep 29, 2015 at 7:16 PM, Milly Bitcoin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 9/29/2015 7:02 PM, Jonathan Toomim (Toomim Bros) wrote:
>
>> Making statements about a developer's personal character is also
>> off-topic for this list.
>>
>
> If that were true then probably 20-30% of the posting here would be
> off-topic.  lol.


Yes - that is the reason why a discussion list is being created, as an
outlet for off-topic discussions.  The consensus of the developers that
created this bitcoin-dev list a short time ago is of being turned off due
to the off-topic noise, impacting productivity.

Since 2011 and bitcoin-development, the list was always intended to focus
on the highly technical bits of the core software, and avoid wandering into
never-ending philosophical discussions.  Example:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2011-June/thread.html








>
>
> Russ
>
>
> ___
> 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] Bitcoin Core 0.12.0 release schedule

[Jeff Garzik via bitcoin-dev]

ACK


On Thu, Sep 24, 2015 at 7:25 AM, Wladimir J. van der Laan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hello all,
>
> The next major release of Bitcoin Core, 0.12.0 is planned for the end of
> the year. Let's propose a more detailed schedule:
>
> 2015-11-01
> ---
> - Open Transifex translations for 0.12
> - Soft translation string freeze (no large or unnecessary changes)
> - Finalize and close translation for 0.10
>
> 2015-12-01
> ---
> - Feature freeze
> - Translation string freeze
>
> In December at least I will probably not get much done code-wise (Scaling
> Bitcoin Hongkong, 32C3, end of year festivities, etc), and I'm sure I'm not
> the only one, so let's leave that for last pre-RC bugfixes and polishing.
>
> 2016-01-06
> ---
> - Split off `0.12` branch from `master`
> - Start RC cycle, tag and release `0.12.0rc1`
> - Start merging for 0.13 on master branch
>
> 2016-02-01
> ---
> - Release 0.12.0 final (aim)
>
> Wladimir
>
>
> ___
> 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

[bitcoin-dev] Scaling Bitcoin conference micro-report

[Jeff Garzik via bitcoin-dev]

During Scaling Bitcoin, Bitcoin Core committers and notable contributors
got together and chatted about where a "greatest common denominator" type
consensus might be.  The following is a without-attribution (Chatham House)
summary.  This is my own personal summary of the chat; any errors are my
own; this is _not_ a consensus statement or anything formal.

- Background (pre-conference, was on public IRC): "net-utxo", calculating
transaction size within block by applying a delta to transaction size based
on the amount of data added, or removed, from the UTXO set.  Fee is then
evaluated after the delta is applied.  This aligns user incentives with
UTXO resource usage/cost.  Original idea by gmaxwell (and others??).

- Many interested or at least willing to accept a "short term bump", a hard
fork to modify block size limit regime to be cost-based via "net-utxo"
rather than a simple static hard limit.  2-4-8 and 17%/year were debated
and seemed "in range" with what might work as a short term bump - net after
applying the new cost metric.

- Hard fork method:  Leaning towards "if (timestamp > X)" flag day hard
fork Y months in the future.  Set high bit in version, resulting in a
negative number, to more cleanly fork away.  "miner advisement" - miners,
as they've done recently, signal non-binding (Bitcoin Core does not examine
the value) engineering readiness for a hard fork via coinbase moniker.
Some fork cancellation method is useful, if unsuccessful after Z time
elapses.

- As discussed publicly elsewhere, other forks may be signaled via setting
a bit in version, and then triggering a fork'ing change once a threshold is
reached.

Chat participants are invited to reply to this message with their own
corrections and comments and summary in their view.

For the wider community, take this as one of many "inputs" described at
Scaling Bitcoin.  Over the next few months developers and the community
should evaluate everything discussed and work towards some concrete
proposal(s) that are implemented, tested and simulated in December in Hong
Kong.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] libconsensus and bitcoin development process

[Jeff Garzik via bitcoin-dev]

inuous
> integration so authors can get it right easily. It can be just like a
> Travis check.
>
> With respect to the 3rd kind of refactoring, we need to set some standards
> and goals and aim for some kind of consistency. Refactoring needs to fulfil
> certain goals and criterion otherwise contributors will always find a
> reason to fiddle over and over forever. Obvious targets here can be things
> like proper encapsulation and separation of concerns.
>
> Overall, refactoring should be merged quickly, but only on a schedule so
> it doesn't cause major disruption to others.
>
> Obviously the third kind of refactoring more complex and time consuming
> and will need to occur over time, but it should happen in defined steps. As
> Jeff said, one week a month, or maybe one month a release. In any case,
> refactoring changes should be quickly accepted or rejected by the project
> maintainer and not left hanging.
>
> Finally, refactoring should *always* be uncontroversial because
> essentially functionality is not changing. If functionality changes (e.g.
> you try to sneak in a big fix or feature tweak "because it's small") the PR
> should be rejected outright. Additionally, if we break down refactoring
> into the three kinds stated above, peer review will be much more
> straightforward.
>
>
>
> On Tue, Sep 15, 2015 at 5:10 AM, Jeff Garzik via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> [collating a private mail and a github issue comment, moving it to a
>> better forum]
>>
>> On libconsensus
>> ---
>> In general there exists the reasonable goal to move consensus state
>> and code to a specific, separate lib.
>>
>> To someone not closely reviewing the seemingly endless stream of
>> libconsensus refactoring PRs, the 10,000 foot view is that there is a
>> rather random stream of refactors that proceed in fits and starts
>> without apparent plan or end other than a one sentence "isolate
>> consensus state and code" summary.
>>
>> I am hoping that
>> * There is some plan
>> * We will not see a five year stream of random consensus code movement
>> patches causing lots of downstream developer headaches.
>>
>> I read every code change in every pull request that comes into
>> github/bitcoin/bitcoin with three exceptions:
>> * consensus code movement changes - too big, too chaotic, too
>> frequent, too unfocused, laziness guarantees others will inevitably
>> ACK it without me.
>> * some non-code changes (docs)
>> * ignore 80% of the Qt changes
>>
>> As with any sort of refactoring, they are easy to prove correct, easy
>> to reason, and therefore quick and easy to ACK and merge.
>>
>> Refactors however have a very real negative impact.
>> bitcoin/bitcoin.git is not only the source tree in the universe.
>> Software engineers at home, at startups, and at major companies are
>> maintaining branches of their own.
>>
>> It is very very easy to fall into a trap where a project is merging
>> lots of cosmetic changes and not seeing the downstream ripple effects.
>> Several people complained to me at the conference about all the code
>> movement changes breaking their own work, causing them to stay on
>> older versions of bitcoin due to the effort required to rebase to each
>> new release version - and I share those complaints.
>>
>> Complex code changes with longer development cycles than simple code
>> movement patches keep breaking.  It is very frustrating, and causes
>> folks to get trapped between a rock and a hard place:
>> - Trying to push non-trivial changes upstream is difficult, for normal
>> and reasonable reasons (big important changes need review etc.).
>> - Maintaining non-trivial changes out of tree is also painful, for the
>> aforementioned reasons.
>>
>> Reasonable work languishes in constant-rebase hell, and incentivizes
>> against keeping up with the latest tree.
>>
>>
>> Aside from the refactor, libconsensus appears to be engineering in the
>> dark.  Where is any sort of plan?  I have low standards - a photo of a
>> whiteboard or youtube clip will do.
>>
>> The general goal is good.   But we must not stray into unfocused
>> engineering for a non-existent future library user.
>>
>> The higher priority must be given to having a source code base that
>> maximizes the collective developers' ability to maintain The Router --
>> the core bitcoin full node P2P engine.
>>
>> I recommend time-based bursts of code movement changes.  See below;
>> for example, just submit &

[bitcoin-dev] libconsensus and bitcoin development process

[Jeff Garzik via bitcoin-dev]

[collating a private mail and a github issue comment, moving it to a
better forum]

On libconsensus
---
In general there exists the reasonable goal to move consensus state
and code to a specific, separate lib.

To someone not closely reviewing the seemingly endless stream of
libconsensus refactoring PRs, the 10,000 foot view is that there is a
rather random stream of refactors that proceed in fits and starts
without apparent plan or end other than a one sentence "isolate
consensus state and code" summary.

I am hoping that
* There is some plan
* We will not see a five year stream of random consensus code movement
patches causing lots of downstream developer headaches.

I read every code change in every pull request that comes into
github/bitcoin/bitcoin with three exceptions:
* consensus code movement changes - too big, too chaotic, too
frequent, too unfocused, laziness guarantees others will inevitably
ACK it without me.
* some non-code changes (docs)
* ignore 80% of the Qt changes

As with any sort of refactoring, they are easy to prove correct, easy
to reason, and therefore quick and easy to ACK and merge.

Refactors however have a very real negative impact.
bitcoin/bitcoin.git is not only the source tree in the universe.
Software engineers at home, at startups, and at major companies are
maintaining branches of their own.

It is very very easy to fall into a trap where a project is merging
lots of cosmetic changes and not seeing the downstream ripple effects.
Several people complained to me at the conference about all the code
movement changes breaking their own work, causing them to stay on
older versions of bitcoin due to the effort required to rebase to each
new release version - and I share those complaints.

Complex code changes with longer development cycles than simple code
movement patches keep breaking.  It is very frustrating, and causes
folks to get trapped between a rock and a hard place:
- Trying to push non-trivial changes upstream is difficult, for normal
and reasonable reasons (big important changes need review etc.).
- Maintaining non-trivial changes out of tree is also painful, for the
aforementioned reasons.

Reasonable work languishes in constant-rebase hell, and incentivizes
against keeping up with the latest tree.


Aside from the refactor, libconsensus appears to be engineering in the
dark.  Where is any sort of plan?  I have low standards - a photo of a
whiteboard or youtube clip will do.

The general goal is good.   But we must not stray into unfocused
engineering for a non-existent future library user.

The higher priority must be given to having a source code base that
maximizes the collective developers' ability to maintain The Router --
the core bitcoin full node P2P engine.

I recommend time-based bursts of code movement changes.  See below;
for example, just submit & merge code movement changes on the first
week of every 2nd month.  Code movement changes are easy to create
from scratch once a concrete goal is known.  The coding part is
trivial and takes no time.

As we saw in the Linux kernel - battle lessons hard learned - code
movement and refactors have often unseen negative impact on downstream
developers working on more complicated changes that have more positive
impact to our developers and users.


On Bitcoin development release cycles & process
--

As I've outlined in the past, the Linux kernel maintenance phases
address some of these problems.  The merge window into git master
opens for 1 week, a very chaotic week full of merging (and rebasing),
and then the merge window closes.  Several weeks follow as the "dust
settles" -- testing, bug fixing, moving in parallel OOB with
not-yet-ready development.  Release candidates follow, then the
release, then the cycle repeats.

IMO a merge window approach fixes some of the issues with refactoring,
as well as introduces some useful -developer discipline- into the
development process.  Bitcoin Core still needs rapid iteration --
another failing of the current project -- and so something of a more
rapid pace is needed:
- 1st week of each month, merge changes.  Lots of rebasing during this week.
- remaining days of the month, test, bug fix
- release at end of month

If changes are not ready for merging, then so be it, they wait until
next month's release.  Some releases have major features, some
releases are completely boring and offer little of note.  That is the
nature of time-based development iteration.  It's like dollar cost
averaging, a bit.


And frankly, I would like to close all github pull requests that are
not ready to merge That Week.  I'm as guilty of this as any, but that
stuff just languishes.  Excluding a certain category of obvious-crap,
pull requests tend to default to a state of either (a) rapid merging,
(b) months-long issues/projects, (c) limbo.

Under a more time-based approach, a better pull request process would be to
* Only 

Re: [bitcoin-dev] BIP 100 specification

[Jeff Garzik via bitcoin-dev]

Thanks - several good suggestions, including some in common.  Will comment
& revise today.

Currently in "collecting" mode, to avoid duplicative comments in multiple
locales.



On Thu, Sep 3, 2015 at 3:57 AM, <jl2...@xbt.hk> wrote:

> Some comments:
>
>
>- The 75% rule is meaningless here. Since this is a pure relaxation of
>rules, there is no such thing as "invalid version 4 blocks"
>
>
>-
>
>The implication threshold is unclear. Is it 95% or 80%?
>
>- Softfork requires a very high threshold (95%) to "attack" the
>   original fork. This makes sure that unupgraded client will only see the 
> new
>   fork.
>   - In the case of hardfork, however, the new fork is unable to
>   attack the original fork, and unupgraded client will never see the new
>   fork. The initiation of a hardfork should be based on its acceptance by 
> the
>   economic majority, not miner support. 95% is an overkill and may 
> probably
>   never accomplished. I strongly prefer a 80% threshold rather than 95%.
>
>
>- As I've pointed out, using 20-percentile rather than median creates
>an incentive to 51% attack the uncooperative minority.
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010690.html
>
> Having said that, I don't have a strong feeling about the use of
> 20-percentile as threshold to increase the block size. That means the block
> size is increased only when most miners agree, which sounds ok to me.
>
> However, using 20-percentile as threshold to DECREASE the block size could
> be very dangerous. Consider that the block size has been stable at 8MB for
> a few years. Everyone are happy with that. An attacker would just need to
> acquire 21% of mining power to break the status quo and send us all the way
> to 1MB. The only way to stop such attempt is to 51% attack the attacker.
> That'd be really ugly.
>
> For technical and ethical reasons, I believe the thresholds for increase
> and decrease must be symmetrical: increase the block size when the
> x-percentile is bigger than the current size, decrease the block size when
> the (100-x)-percentile is smaller than the current size. The overall effect
> is: the block size remains unchanged unless 80% of miners agree to.
>
>- Please consider the use of "hardfork bit" to signify the hardfork:
>
>
> https://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_hardfork_bit_jl2012_at_xbthk_jul_23_2015/
>
> https://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki
>
>- Or, alternatively, please combine the hardfork with a softfork. I'm
>rewriting the specification as follow (changes underlined):
>
>
>1. Replace static 1M block size hard limit with a floating limit
>("hardLimit").
>2.
>
>hardLimit floats within the range 1-32M, inclusive.
>
>3.
>
>Initial value of hardLimit is 1M, preserving current system.
>
>4. Changing hardLimit is accomplished by encoding a proposed value
>within a block's coinbase scriptSig.
>   1. Votes refer to a byte value, encoded within the pattern
>   "/BV\d+/" Example: /BV800/ votes for 8,000,000 byte hardLimit. If
>   there is more than one match with with pattern, the first match is 
> counted.
>   2. Absent/invalid votes and votes below minimum cap (1M) are
>   counted as 1M votes. Votes above the maximum cap (32M) are counted as 
> 32M
>   votes.
>   3. A new hardLimit is calculated at each difficult adjustment
>   period (2016 blocks), and applies to the next 2016 blocks.
>   4. Calculate hardLimit by examining the coinbase scriptSig votes of
>   the previous 12,000 blocks, and taking the 20th percentile and 80th
>   percentile.
>   5. New hardLimit is the median of the followings:
>  1. min(current hardLimit * 1.2, 20-percentile)
>  2. max(current hardLimit / 1.2, 80-percentile)
>  3. current hardLimit
>   5. version 4 block: the coinbase of a version 4 block must match
>this pattern: "/BV\d+/"
>6. 70% rule: If 8,400 of the last 12,000 blocks are version 4 or
>greater, reject invalid version 4 blocks. (testnet4: 501 of last 1000)
>7. 80% rule ("Point of no return"): If 9,600 of the last 12,000 blocks
>are version 4 or greater, reject all version <= 3 blocks. (testnet4: 750 of
>last 1000)
>8. Block version number is calculated after masking out high 16 bits
>(final bit count TBD by versionBits outcome).
>
> Jeff Garzik via bitcoin-dev 於 2015-09-02 23:33 寫到:
> > BIP 100 initial public draft:
> > https://github.com/

Re: [bitcoin-dev] block size - pay with difficulty

[Jeff Garzik via bitcoin-dev]

Expanding on pay-with-diff and volatility (closing comment),

Users and miners will have significant difficulty creating and/or
predicting a stable block size (and fee environment) with pay-with-diff
across the months.  The ability of businesses to plan is low.  Chaos and
unpredictability are bad in general for markets and systems.  Thus the
binary conclusion of "not get used" or "volatility"






On Thu, Sep 3, 2015 at 10:31 AM, Jeff Garzik <jgar...@gmail.com> wrote:

> It's written as 'a' and/or 'b'.  If you don't have idle hashpower, then
> paying with difficulty requires some amount of collusion ('a')
>
> Any miner paying with a higher difficulty either needs idle hashpower, or
> self-increase their own difficulty at the possible *opportunity cost* of
> losing an entire block's income to another miner who doesn't care about
> changing the block size.  The potential loss does not economically
> compensate for size increase gains in most cases, when you consider the
> variability of blocks (they come in bursts and pauses) and the fee income
> that would be associated.
>
> Miners have more to lose paying with diff than they gain -- unless the
> entire network colludes out-of-band with ~90% certainty, by collectively
> agreeing to increase the block period by collectively agreeing with
> pay-with-diff until the globally desired block size is reached.  At that
> level of collusion, we can create far more simple schemes to increase block
> size.
>
> Pay-with-diff will either not get used, or lead to radical short term
> block size (and thus fee) volatility.  It is complex & difficult for all
> players to reason, and a Rational game theory choice can be to avoid
> paying-for-diff even when the network desperately needs an upgrade.
>
>
>
>
>
>
> On Thu, Sep 3, 2015 at 2:57 AM, Gregory Maxwell <gmaxw...@gmail.com>
> wrote:
>
>> On Thu, Sep 3, 2015 at 4:05 AM, Jeff Garzik via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > (b) requiring miners to have idle
>> > hashpower on hand to change block size are both unrealistic and
>> potentially
>>
>> I really cannot figure out how you could characterize pay with
>> difficty has in any way involving idle hashpower.
>>
>> Can you walk me through this?
>>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 100 specification

[Jeff Garzik via bitcoin-dev]

A discussion of rolling out BIP 100 will not be avoided :)

It is a hard fork; it would be silly to elide discussion of these key
issues.

I don't get the community's recent interest in avoiding certain topics.



On Thu, Sep 3, 2015 at 7:20 AM, Btc Drak <btcd...@gmail.com> wrote:

> We should avoid discussing actual hard fork/softfork deployment
> methodologies when discussing blocksize proposals because deployment
> is a separate issue. As a recent case in point, look at how BIP65
> (CHECKLOCKTIMEVERIFY) specifically avoided the issue of how to deploy.
> That lead to a focused discussion of the functionality and relatively
> quick inclusion.
>
> Deployment really is a separate issue than the mechanics of how BIP100
> will function after activation.
>
> On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Some comments:
> >
> > The 75% rule is meaningless here. Since this is a pure relaxation of
> rules,
> > there is no such thing as "invalid version 4 blocks"
> >
> > The implication threshold is unclear. Is it 95% or 80%?
> >
> > Softfork requires a very high threshold (95%) to "attack" the original
> fork.
> > This makes sure that unupgraded client will only see the new fork.
> > In the case of hardfork, however, the new fork is unable to attack the
> > original fork, and unupgraded client will never see the new fork. The
> > initiation of a hardfork should be based on its acceptance by the
> economic
> > majority, not miner support. 95% is an overkill and may probably never
> > accomplished. I strongly prefer a 80% threshold rather than 95%.
> >
> > As I've pointed out, using 20-percentile rather than median creates an
> > incentive to 51% attack the uncooperative minority.
> >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010690.html
> >
> > Having said that, I don't have a strong feeling about the use of
> > 20-percentile as threshold to increase the block size. That means the
> block
> > size is increased only when most miners agree, which sounds ok to me.
> >
> > However, using 20-percentile as threshold to DECREASE the block size
> could
> > be very dangerous. Consider that the block size has been stable at 8MB
> for a
> > few years. Everyone are happy with that. An attacker would just need to
> > acquire 21% of mining power to break the status quo and send us all the
> way
> > to 1MB. The only way to stop such attempt is to 51% attack the attacker.
> > That'd be really ugly.
> >
> > For technical and ethical reasons, I believe the thresholds for increase
> and
> > decrease must be symmetrical: increase the block size when the
> x-percentile
> > is bigger than the current size, decrease the block size when the
> > (100-x)-percentile is smaller than the current size. The overall effect
> is:
> > the block size remains unchanged unless 80% of miners agree to.
> >
> > Please consider the use of "hardfork bit" to signify the hardfork:
> >
> >
> https://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_hardfork_bit_jl2012_at_xbthk_jul_23_2015/
> >
> > https://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki
> >
> > Or, alternatively, please combine the hardfork with a softfork. I'm
> > rewriting the specification as follow (changes underlined):
> >
> > Replace static 1M block size hard limit with a floating limit
> ("hardLimit").
> >
> > hardLimit floats within the range 1-32M, inclusive.
> >
> > Initial value of hardLimit is 1M, preserving current system.
> >
> > Changing hardLimit is accomplished by encoding a proposed value within a
> > block's coinbase scriptSig.
> >
> > Votes refer to a byte value, encoded within the pattern "/BV\d+/"
> Example:
> > /BV800/ votes for 8,000,000 byte hardLimit. If there is more than one
> > match with with pattern, the first match is counted.
> > Absent/invalid votes and votes below minimum cap (1M) are counted as 1M
> > votes. Votes above the maximum cap (32M) are counted as 32M votes.
> > A new hardLimit is calculated at each difficult adjustment period (2016
> > blocks), and applies to the next 2016 blocks.
> > Calculate hardLimit by examining the coinbase scriptSig votes of the
> > previous 12,000 blocks, and taking the 20th percentile and 80th
> percentile.
> > New hardLimit is the median of the followings:
> >
> > min(current hardLimit * 1.2, 20-percentile)
> > max(current hardLimit / 1.2, 80-percentile)
> > current har

Re: [bitcoin-dev] block size - pay with difficulty

[Jeff Garzik via bitcoin-dev]

It's written as 'a' and/or 'b'.  If you don't have idle hashpower, then
paying with difficulty requires some amount of collusion ('a')

Any miner paying with a higher difficulty either needs idle hashpower, or
self-increase their own difficulty at the possible *opportunity cost* of
losing an entire block's income to another miner who doesn't care about
changing the block size.  The potential loss does not economically
compensate for size increase gains in most cases, when you consider the
variability of blocks (they come in bursts and pauses) and the fee income
that would be associated.

Miners have more to lose paying with diff than they gain -- unless the
entire network colludes out-of-band with ~90% certainty, by collectively
agreeing to increase the block period by collectively agreeing with
pay-with-diff until the globally desired block size is reached.  At that
level of collusion, we can create far more simple schemes to increase block
size.

Pay-with-diff will either not get used, or lead to radical short term block
size (and thus fee) volatility.  It is complex & difficult for all players
to reason, and a Rational game theory choice can be to avoid
paying-for-diff even when the network desperately needs an upgrade.






On Thu, Sep 3, 2015 at 2:57 AM, Gregory Maxwell <gmaxw...@gmail.com> wrote:

> On Thu, Sep 3, 2015 at 4:05 AM, Jeff Garzik via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > (b) requiring miners to have idle
> > hashpower on hand to change block size are both unrealistic and
> potentially
>
> I really cannot figure out how you could characterize pay with
> difficty has in any way involving idle hashpower.
>
> Can you walk me through this?
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 100 specification

[Jeff Garzik via bitcoin-dev]

Take a look at the latest update:

- swiped Tier Nolan verbiage, which I agree was usefully more clear
- added 'M' suffix and removed 'V' from coinbase scriptSig


On Thu, Sep 3, 2015 at 12:32 PM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 1. I think there is no need to have resolution at byte level, while
> resolution at MB level is not enough. kB would be a better choice.
>
> 2. In my specification a v4 block without a vote is invalid, so there is
> no need to consider absent or invalid votes
>
> 3. We should allow miners to explicitly vote for the status quo, so they
> don't need to change the coinbase vote every time the size is changed. They
> may indicate it by /BV/ in the coinbase, and we should look for the first
> "/BVd*/" instead of "/BVd+/"
>
> 4. Alternatively, miners may vote in different styles: /BV1234567/,
> /BV1500K/, /BV3M/. The first one means 1.234567MB, the second one is 1.5MB,
> the last one is 3MB. The pattern is "/BV(\d+[KM]?)?/"
>
> Tier Nolan via bitcoin-dev 於 2015-09-03 07:59 寫到:
>
>> On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev
>>  wrote:
>>
>> *
>>>
>>> hardLimit floats within the range 1-32M, inclusive.
>>>
>>
>> Does the 32MB limit actually still exist anywhere in the code?  In
>> effect, it is re-instating a legacy limitation.
>>
>> The message size limit is to minimize the storage required per peer.
>> If a 32MB block size is required, then each network input buffer must
>> be at least 32MB. This makes it harder for a node to support a large
>> number of peers.
>>
>> There is no reason why a single message is used for each block.  Using
>> the merkleblock message (or a different dedicated message), it would
>> be possible to send messages which only contain part of a block and
>> have a limited maximum size.
>>
>> This would allow receiving parts of a block from multiple sources.
>>
>> This is a separate issue but should be considered if moving past 32MB
>> block sizes (or maybe as a later protocol change).
>>
>> * Changing hardLimit is accomplished by encoding a proposed value
>>> within a block's coinbase scriptSig.
>>>
>>> * Votes refer to a byte value, encoded within the pattern "/BVd+/"
>>> Example: /BV800/ votes for 8,000,000 byte hardLimit. If there is
>>> more than one match with with pattern, the first match is counted.
>>>
>>
>> Is there a need for byte resolution?  Using MB resolution would use up
>> much fewer bytes in the coinbase.
>>
>> Even with the +/- 20% rule, miners could vote for the nearest MB.
>> Once the block size exceeds 5MB, then there is enough resolution
>> anyway.
>>
>> * Absent/invalid votes and votes below minimum cap (1M) are
>>>
>>> counted as 1M votes. Votes above the maximum cap (32M) are counted
>>> as 32M votes.
>>>
>>
>> I think abstains should count for the status quo.  Votes which are out
>> of range should be clamped.
>>
>> Having said that, if core supports the change, then most miners will
>> probably vote one way or another.
>>
>> New hardLimit is the median of the followings:
>>> min(current hardLimit * 1.2, 20-percentile)
>>> max(current hardLimit / 1.2, 80-percentile)
>>> current hardLimit
>>>
>>
>> I think this is unclear, though mathematically exact.
>>
>> Sort the votes for the last 12,000 blocks from lowest to highest.
>>
>> Blocks which don't have a vote are considered a vote for the status
>> quo.
>>
>> Votes are limited to +/- 20% of the current value.  Votes that are out
>> of range are considered to vote for the nearest in range value.
>>
>> The raise value is defined as the vote for the 2400th highest block
>> (20th percentile).
>>
>> The lower value  is defined as the vote for the 9600th highest block
>> (80th percentile).
>>
>> If the raise value is higher than the status quo, then the new limit
>> is set to the raise value.
>>
>> If the lower value is lower than the status quo, then the new limit is
>> set to the lower value.
>>
>> Otherwise, the size limit is unchanged.
>>
>> ___
>> 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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] BIP 100 repo

[Jeff Garzik via bitcoin-dev]

Opened a repo containing the full text of BIP 100 discussion document, in
markdown format.

The BIP 100 formal spec will be checked in here as well, before submitting
to upstream bips.git repo.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 100 repo

[Jeff Garzik via bitcoin-dev]

Oops, link paste fail.

The repo: https://github.com/jgarzik/bip100


On Wed, Sep 2, 2015 at 7:51 PM, Jeff Garzik <jgar...@gmail.com> wrote:

> Opened a repo containing the full text of BIP 100 discussion document, in
> markdown format.
>
> The BIP 100 formal spec will be checked in here as well, before submitting
> to upstream bips.git repo.
>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] block size - pay with difficulty

[Jeff Garzik via bitcoin-dev]

Schemes proposing to pay with difficulty / hashpower to change block size
should be avoided.  The miners incentive has always been fairly
straightforward - it is rational to deploy new hashpower as soon as you can
get it online.  Introducing the concepts of (a) requiring out-of-band
collusion to change block size and/or (b) requiring miners to have idle
hashpower on hand to change block size are both unrealistic and potentially
corrosive.  That potentially makes the block size - and therefore fee
market - too close, too sensitive to the wild vagaries of the mining chip
market.

Pay-to-future-miner has neutral, forward looking incentives worth
researching.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] BIP 100 specification

[Jeff Garzik via bitcoin-dev]

BIP 100 initial public draft:
https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki

Emphasis on "initial"  This is a starting point for the usual open source
feedback/iteration cycle, not an endpoint that Must Be This Way.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 100 repo

[Jeff Garzik via bitcoin-dev]

Luke,

- Definitely agree with most of your suggestions on the practical side;
several clarification could be made.
- The power to decrease the hard limit appears riskier long term in my
analysis.  This is mitigated somewhat by the ease at which miners may
locally or collectively lower the block size at any time, without a vote.


On Wed, Sep 2, 2015 at 8:17 PM, Luke Dashjr <l...@dashjr.org> wrote:

> On Wednesday, September 02, 2015 11:58:54 PM Jeff Garzik via bitcoin-dev
> wrote:
> > The repo: https://github.com/jgarzik/bip100
>
> What is the purpose of the newly added 1 MB floor? It seems clear from the
> current information available that 1 MB is presently too high for the
> limit,
> and it is entirely one-sided to only allow increases when decreases are
> much
> more likely to be needed in the short term.
>
> Must the new size limit votes use 11 bytes of coinbase? Why not just use a
> numeric value pushed after height? Since this is a hardfork, I suggest
> increasing the coinbase length to allow for 100 bytes *in addition* to the
> pushed height and size-vote.
>
> I suggest combining 2 & 4 into a single rule lifting the 1 MB limit to 32
> MB
> (or whatever value is deemed appropriate) to make it clear that the limit
> remains a part of the consensus protocol and p2p protocol limits are not to
> have an effect on consensus rules.
>
> Furthermore, I suggest modifying the voting to require 50% to set the limit
> floor. This has the effect of merely coordinating what miners can already
> effectively do today by rejecting blocks larger than some collusion-
> determined limit.
>
> Thoughts?
>
> Luke
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Questiosn about BIP100

[Jeff Garzik via bitcoin-dev]

20th percentile, though there is some argument to take the 'mode' of
several tranches


On Thu, Aug 27, 2015 at 11:07 AM, Andrew C achow...@gmail.com wrote:

 I have been reading the pdf and one thing I can't figure out is what you
 mean by most common floor. Is that the smallest block size that has a
 vote or the block size with the most votes or something else?

 On Mon, Aug 24, 2015 at 10:40 AM Jeff Garzik jgar...@gmail.com wrote:

 Great questions.

 - Currently working on technical BIP draft and implementation, hopefully
 for ScalingBitcoin.org.  Only the PDF is publicly available as of today.
 - Yes, the initial deployment is in the same manner as size votes.


 On Fri, Aug 21, 2015 at 7:38 PM, Andrew C via bitcoin-dev 
 bitcoin-dev@lists.linuxfoundation.org wrote:

 Hi all,

 Is there any client or code that currently implements BIP 100? And how
 will it be deployed? WIll the initial fork be deployed in the same manner
 that the max block size changes are deployed described in the bip?

 Thanks

 ___
 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] Questiosn about BIP100

[Jeff Garzik via bitcoin-dev]

Great questions.

- Currently working on technical BIP draft and implementation, hopefully
for ScalingBitcoin.org.  Only the PDF is publicly available as of today.
- Yes, the initial deployment is in the same manner as size votes.


On Fri, Aug 21, 2015 at 7:38 PM, Andrew C via bitcoin-dev 
bitcoin-dev@lists.linuxfoundation.org wrote:

 Hi all,

 Is there any client or code that currently implements BIP 100? And how
 will it be deployed? WIll the initial fork be deployed in the same manner
 that the max block size changes are deployed described in the bip?

 Thanks

 ___
 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] Revisiting NODE_BLOOM: Proposed BIP

[Jeff Garzik via bitcoin-dev]

I don't see any link to data backing up Bloom filter usage has declined
significantly

Is there actual data showing this feature's use is declining or
non-existent?


On Fri, Aug 21, 2015 at 1:55 AM, Peter Todd p...@petertodd.org wrote:

 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 having the
 Core implementation accept and respond to bloom filter requests from
 non-upgraded clients regardless of whether or not NODE_BLOOM was set
 until some fixed upgrade deadline in the future.


 Note that since the last time NODE_BLOOM was proposed, the landcape for
 (lite-)SPV clients has changed significantly in a few key ways:

 1) @mikehearn's [Cartographer](https://github.com/mikehearn/httpseed)
 seed protocol has been created and deployed in production to allow
 (lite-)SPV clients to find nodes supporting arbitrary service bits,
 notable NODE_GETUTXOs.

 2) Bloom filter usage has declined significantly, as lite-SPV clients
 are moving towards using centralized, trusted, servers run by the
 wallet
 authors. For instance
 [Mycelium](https://github.com/mycelium-com/wallet),
 [GreenBits](https://github.com/greenaddress/GreenBits),
 [AirBitz](
 https://www.reddit.com/r/Bitcoin/comments/3etohn/whats_wrong_with_breadwallet/ctirou5
 ),
 and [Electrum](https://electrum.org/#home) all fall in this category.

 3) Bloom filters [have been found](http://eprint.iacr.org/2014/763) to
 have severe privacy issues, offering essentially no privacy at all.
 Under many threat models a small number of trusted servers pose less
 privacy security risk than connecting to random, sybil-attackable,
 peers
 using unencrypted connections and giving those peers very accurate
 wallet contents information.

 4) Finally, Bloom filters still have [unsolved DoS attack
 issues](
 https://www.reddit.com/r/Bitcoin/comments/3hjak7/the_hard_work_of_core_devs_not_xt_makes_bitcoin/cu9xntf?context=3
 ),
 that will get significantly worse under upcoming blocksize increase
 proposals.

 Re: service bit identifier, I'd just pick 13

 -https://github.com/bitcoin/bitcoin/issues/6578#issuecomment-133226943

 --
 'peter'[:-1]@petertodd.org
 0402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d

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

Re: [bitcoin-dev] Miners are struggling with blocks far smaller than 750KB blocks and resorting to SPV mining

[Jeff Garzik via bitcoin-dev]

As jl2012 indicated, this is an insufficient analysis.

You cannot assume that because X time passed since the last block, the
miner's internal block maker has updated the template, and from there, is
shipped out to the hashers in the field.  Further, even if you update the
block template at time Y, a hasher might return with a solution for the
block at time X, and the miner will of course publish solution X.

There are several steps of latency involved, even ignoring things such as
the miner relay network or getting US pool stratum links to a sub-pool in
China.






On Mon, Aug 17, 2015 at 4:42 AM, Luv Khemani via bitcoin-dev 
bitcoin-dev@lists.linuxfoundation.org wrote:

 Hi all,

   I previously mentioned in a post that i believe that technically nodes
 are capable of handling blocks an order of magnitude larger than the
 current blocksize limit, the only missing thing was an incentive to run
 them. I have been monitoring the blockchain for the past couple of weeks
 and am seeing that even miners who have all the incentives are for whatever
 reason struggling to download and validate much smaller blocks.

 The data actually paints a very grim picture of the current
 bandwidth/validating capacity of the global mining network.

 See the following empty blocks mined despite a non-trivial elapsed time
 from the previous block just from the past couple of days alone (Data from
 insight.bitpay.com):

 EmptyBlock /Time since previous block/ Size of previous block(bytes)/Mined
 by
 
 370165  29s  720784  Antpool
 370160  31s  50129BTCChinaPool
 370076  49s  469988  F2Pool
 370059  34s  110994  Antpool
 370057  73s  131603  Antpool

 We have preceding blocks as small as 50KB with 30s passing and the miner
 continues to mine empty blocks via SPV mining.
 The most glaring case is Block 370057 where despite 73s elapsing and the
 preceding block being a mere 131KB, the miner is unable to
 download/validate fast enough to include transactions in his block. Unless
 ofcourse the miner is mining empty blocks on purpose, which does not make
 sense as all of these pools do mine blocks with transactions when the
 elapsed time is greater.

 This is a cause for great concern, because if miners are SPV mining for a
 whole minute for 750KB blocks, at 8MB blocks, the network will just fall
 apart as a significant portion of the hashing power SPV mines throughout.
 All a single malicious miner has to do is mine an invalid block on purpose,
 let these pools SPV mine on top of them while it mines a valid block free
 of their competition. Yes, these pools deserve to lose money in that event,
 but the impact of reorgs and many block orphans for anyone not running a
 full node could be disastrous, especially more so in the XT world where
 Mike wants everyone to be running SPV nodes. I simply don't see the XT fork
 having any chance of surviving if SPV nodes are unreliable.

 And if these pools go out of business, it will lead to even more mining
 centralization which is already too centralized today.

 Can anyone representing these pools comment on why this is happening? Are
 these pools on Matt's relay network?





 ___
 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] Bitcoin XT Fork

[Jeff Garzik via bitcoin-dev]

In times of controversy or flamewar on the Linux kernel mailing list,
occasionally fake Linus Torvalds or other spoofed posts would appear.  It
is the nature of email.  Just ignore it.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Minimum Block Size

[Jeff Garzik via bitcoin-dev]

minimum an interesting topic.

- Traffic levels may not produce a minimum size block
- Miners can always collude to produce a lowered maximum block size, a sort
of minimum maximum



On Sun, Aug 16, 2015 at 12:41 PM, Levin Keller via bitcoin-dev 
bitcoin-dev@lists.linuxfoundation.org wrote:

 Hey everyone,

 as with the current max block size debate I was wondering: Is anyone
 here in favor of a minimum block size (say 2 MB or so)? If so I would be
 interested in an exchange (maybe off-list) of ideas. I am in favor of a
 lower limit and am giving it quite a bit of thought at the moment.

 Cheers

 Levin

 ___
 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] Bitcoin Core and hard forks

[Jeff Garzik via bitcoin-dev]

On Wed, Jul 22, 2015 at 9:52 AM, Pieter Wuille via bitcoin-dev 
bitcoin-dev@lists.linuxfoundation.org wrote:

 Some people have called the prospect of limited block space and the
 development of a fee market a change in policy compared to the past. I
 respectfully disagree with that. Bitcoin Core is not running the Bitcoin
 economy, and its developers have no authority to set its rules. Change in
 economics is always happening, and should be expected. Worse, intervening
 in consensus changes would make the ecosystem more dependent on the group
 taking that decision, not less.


This completely ignores *reality*, what users have experienced for the past
~6 years.

Change in economics is always happening does not begin to approach the
scale of the change.

For the entirety of bitcoin's history, absent long blocks and traffic
bursts, fee pressure has been largely absent.

Moving to a new economic policy where fee pressure is consistently present
is radically different from what users, markets, and software have
experienced and *lived.*

Analysis such as [1][2] and more shows that users will hit a painful
wall and market disruption will occur - eventually settling to a new
equilibrium after a period of chaos - when blocks are consistently full.

[1] http://hashingit.com/analysis/34-bitcoin-traffic-bulletin
[2] http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent

First, users  market are forced through this period of chaos by let a fee
market develop as the whole market changes to a radically different
economic policy, once the network has never seen before.

Next, when blocks are consistently full, the past consensus was that block
size limit will be increased eventually.  What happens at that point?

Answer - Users  market are forced through a second period of chaos and
disruption as the fee market is rebooted *again* by changing the block size
limit.

The average user hears a lot of noise on both sides of the block size
debate, and really has no idea that the new let a fee market develop
Bitcoin Core policy is going to *raise fees* on them.

It is clear that
- let the fee market develop, Right Now has not been thought through
- Users are not prepared for a brand new economic policy
- Users are unaware that a brand new economic policy will be foisted upon
them



 So to point out what I consider obvious: if Bitcoin requires central
 control over its rules by a group of developers, it is completely
 uninteresting to me. Consensus changes should be done using consensus, and
 the default in case of controversy is no change.


False.

All that has to do be done to change bitcoin to a new economic policy - not
seen in the entire 6 year history of bitcoin - is to stonewall work on
block size.

Closing size increase PRs and failing to participate in planning for a
block size increase accomplishes your stated goal of changing bitcoin to a
new economic policy.

no [code] change... changes bitcoin to a brand new economic policy,
picking economic winners  losers.  Some businesses will be priced out of
bitcoin, etc.

Stonewalling size increase changes is just as much as a Ben Bernanke/FOMC
move as increasing the hard limit by hard fork.



 My personal opinion is that we - as a community - should indeed let a fee
 market develop, and rather sooner than later, and that kicking the can
 down the road is an incredibly dangerous precedent: if we are willing to
 go through the risk of a hard fork because of a fear of change of
 economics, then I believe that community is not ready to deal with change
 at all. And some change is inevitable, at any block size. Again, this does
 not mean the block size needs to be fixed forever, but its intent should be
 growing with the evolution of technology, not a panic reaction because a
 fear of change.

 But I am not in any position to force this view. I only hope that people
 don't think a fear of economic change is reason to give up consensus.


Actually you are.

When size increase progress gets frozen out of Bitcoin Core, that just
*increases* the chances that progress must be made through a contentious
hard fork.

Further, it increases the market disruption users will experience, as
described above.

Think about the users.  Please.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

[Jeff Garzik via bitcoin-dev]

I wouldn't go quite that far.  The reality is somewhere in the middle, as
Bryan Cheng noted in this thread:

Quoting BC,
 Upgrading to a version of Bitcoin Core that is incompatible with your
ideals is in no way a forced choice, as you have stated in your email;
forks, alternative clients, or staying on an older version are all valid
choices. If the majority of the network chooses not to endorse a specific
change, then the majority of the network will continue to operate just fine
without it, and properly structured consensus rules will pull the minority
along as well.

The developers *propose* a new version, by publishing a new release.  The
individual network nodes choose to accept or reject that.

So I respectfully disagree with core devs don't control the network and
core devs control the network both.

There are checks-and-balances that make the system work.  Consensus is most
strongly measured by user actions after software release.  If the
developers fail to reflect user consensus, the network will let us know.











On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev 
bitcoin-dev@lists.linuxfoundation.org wrote:

 Hi Pieter,

 I think a core area of disagreement is this:

 Bitcoin Core is not running the Bitcoin economy, and its developers have
 no authority to set its rules.

 In fact Bitcoin Core is running the Bitcoin economy, and its developers do
 have the authority to set its rules. This is enforced by the reality of
 ~100% market share and limited github commit access.

 You may not like this situation, but it is what it is. By refusing to make
 a release with different rules, people who disagree are faced with only two
 options:

 1. Swallow it even if they hate it
 2. Fork the project and fork the block chain with it (XT)

 There are no alternatives. People who object to (2) are inherently
 suggesting (1) is the only acceptable path, which not surprisingly, makes a
 lot of people very angry.

 ___
 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] SPV Mining reveals a problematic incentive issue.

[Jeff Garzik]

The miners with invalid blocks were punished with a loss of bitcoin
income...


On Sat, Jul 11, 2015 at 4:05 AM, Nathan Wilcox nat...@leastauthority.com
wrote:

 Thesis: The disincentive miners have for verifying transactions is
 problematic and weakens the network's robustness against forks.

 According to the 2015-07-04 bitcoin.org alert [1]_ so-called SPV Mining
 has become popular across a large portion of miners, and this enabled the
 consensus-violating forks to persist. Peter Todd provides an explanation
 of the incentive for SPV Mining over in another thread [2]_.

 .. [1] https://bitcoin.org/en/alert/2015-07-04-spv-mining#cause

 .. [2]
 https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg00404.html

 If there is a cost to verifying transactions in a received block, then
 there is an incentive to *not verify transactions*.  However, this is
 balanced by the a risk of mining atop an invalid block.

 If we imagine all miners verify all transactions, except Charlie the
 Cheapskate, then it's in Charlie's interest to forego transaction
 verification.  If all miners make a similar wager, then in the extreme,
 no miners verify any transactions, and the expected cost of skipping
 transaction verification becomes very high.

 Unfortunately, it's difficult to measure how many miners are not
 validating transactions, since there's no evidence of this until they
 mine atop on invalid block. Because of this, I worry that over time,
 more and more miners cut this particular corner, to save on costs.

 If true, then the network continues to grow more brittle towards the kind
 of forking-persistence behavior we saw from the July 4th (and 5th) forks.

 This gets weird.  For example, a malicious miner which suspects a large
 fraction of miners are neglecting transaction verification may choose to
 forego a block reward by throwing an erroneous transaction into their
 winning block, then, as all the SPV Miners run off along a worthless
 chain, they can reap a higher reward rate due to controlling a larger
 network capacity fraction on the valid chain.

 Can we fix this?

 --
 Nathan Wilcox
 Least Authoritarian

 email: nat...@leastauthority.com
 twitter: @least_nathan

 Standard Disclaimer: I'm behind on dev archives, irc logs, bitcointalk,
 the wiki...  if this has been discussed before I appreciate mentions of
 that fact.


 ___
 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] Why not Child-Pays-For-Parent?

[Jeff Garzik]

It sounds like you are seeking transaction expiration from the mempool, not
CPFP.



On Sat, Jul 11, 2015 at 4:30 PM, Dan Bryant dkbry...@gmail.com wrote:

 I think a compromise will be somewhere in the middle.  I think most people
 would be OK with TXs that don't have enough fees for P2P transfer to stay
 in deadmans land.  Most people are stuck in a situation where they payed
 enough to get it into (and keep it in) the pool, but not enough to get it
 out.

 If we could get CPFP that only worked on TXs that met the minimum
 threshold for peer propagation, then I think we would be in much better
 position to battle this spam flood.

 On Sat, Jul 11, 2015 at 3:28 PM, Micha Bailey michabai...@gmail.com
 wrote:

 Right. The issue (AIUI) is that, right now, even though transactions are
 evaluated for inclusion as a group with CPFP, they're not yet evaluated for
 relaying as a unit, nor can they be, because the current p2p protocol
 doesn't have a way to send multiple transactions in a single protocol
 message to signify that they should be evaluated together.




 ___
 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] Why not Child-Pays-For-Parent?

[Jeff Garzik]

This is a good explanation but it does not address reachability.  TX_a, the
first tx sent out on the network, presumably has insufficient fee to get
mined - which also means it did not necessarily even reach all miners.

Simply sending out TX_b with added fee does not guarantee that nodes
suddenly have TX_a, which they may have ignored/dropped before.



On Fri, Jul 10, 2015 at 12:28 PM, Tier Nolan tier.no...@gmail.com wrote:



 On Fri, Jul 10, 2015 at 5:09 PM, Richard Moore m...@ricmoo.com wrote:

 I was also wondering, with CPFP, should the transaction fee be based on
 total transactions size, or the sum of each transaction’s required fee? For
 example, a third transaction C whose unconfirmed utxo from transaction B
 has an unconfirmed utxo in transaction A (all of A’s inputs are confirmed),
 with each A, B and C being ~300bytes, should C’s transaction fee be 0.0001
 btc for the ~1kb it is about to commit to the blockchain, or 0.0003 btc for
 the 3 transactions it is going to commit.


 It should be whatever gives the highest fee.  In effect, child pays for
 parent creates compound transactions.

 A: 250 bytes, 0 fee
 B: 300 bytes: 0.0005 fee
 C: 400 bytes: 0.0001 fee

 There are 3 combinations to consider

 A: 0 fee for 250 bytes = 0 per byte
 AB: 0.0005 fee for 550 bytes = 0.91 uBTC per byte
 ABC: 0.0006 fee for 950 bytes = 0.63uBTC per byte

 This means that the AB combination has the best fee per byte value.  AB
 should be added to the memory pool (if 0.91 uBTC per byte is above the
 threshold).

 Once AB are added, then C can be reconsidered on its own.

 C: 0.0001 for 400 bytes = 0.25 BTC per byte

 If that is above the threshold, then C should be added.

 In practice, it isn't possible to check every combination.  If there are N
 transactions, then checking all triple combinations costs around N cubed.

 A 2 pass system could get a reasonably efficient result.

 B is 0.0005 fee for 300 bytes = 1.67 uBTC per byte and is assumed to be a
 high value transaction.

 The algorithm would be

 Pass 1:
 Process all transactions in order of BTC per byte, until block is full
 If the transaction's parents are either already in the pool or a
 previous block, add the transaction.

 Pass 1:
 Process all non-included transactions in order of BTC per byte, until
 block is full
 If the transaction's parents are either already in the pool or a
 previous block, add the transaction.

 Otherwise, consider the transaction plus all non-included ancestors as
 a single transaction
 If this combined transaction has a higher BTC per byte than the
 lowest transaction(s),
 add the combined transaction
 drop the other transaction(s)



 ___
 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] Defining a min spec

[Jeff Garzik]

On Fri, Jul 3, 2015 at 1:33 AM, Jeremy Rubin 
jeremy.l.rubin.tra...@gmail.com wrote:

 Moxie looks fantastic! The reason I thought RISC-V was a good selection is
 the very active development community which is pushing the performance of
 the ISA implementations forward. Can you speak to the health of Moxie
 development? Ultimately, ensuring support for many open architectures would
 be preferable. Are there other reasonable open-source processors that you
 are aware of?

 I would be willing to work on a design a Bitcoin specific open-hardware
 processor, up to the FPGA bound, if this would be useful for this goal.


Moxie was designed to be small and efficient from the compiler standpoint.
As a side effect, it is easy to audit from a security perspective.  It
started life as a simulator + gcc compiler backend, and then later became
an FPGA implementation.

Moxie would benefit from focused effort in building out the hardware side
to be efficient on FPGA, developing and testing multi-core support and
related efforts.  This area is less mature and could use attention.  Start
at https://github.com/atgreen/moxiedev/tree/master/moxie/cores/moxie

In terms of other projects, there are many open source processor cores at
http://opencores.org
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Defining a min spec

[Jeff Garzik]

If the freedom to pick architecture exists, Moxie is a nice, compact, easy
to audit alternative:
 http://moxielogic.org/blog/pages/architecture.html
 https://github.com/jgarzik/moxiebox

Scaling can occur at the core level, rather than hyper-pipelining, keeping
the architecture itself nice and clean and simple.



On Thu, Jul 2, 2015 at 11:13 PM, Jeremy Rubin 
jeremy.l.rubin.tra...@gmail.com wrote:

 Might I suggest that the min-spec, if developed, target the RISC-V Rocket
 architecture (running on FPGA, I suppose) as a reference point for
 performance? This may be much lower performance than desirable, however, it
 means that we don't lock people into using large-vendor chipsets which have
 unknown, or known to be bad, security properties such as Intel AMT.

 In general, targeting open hardware seems to me to be more critical than
 performance metrics for the long term health of Bitcoin, however,
 performance is still important.

 Does anyone know how the RISC-V FPGA performance stacks up to, say, a
 Raspberry Pi?

 On Thu, Jul 2, 2015 at 10:52 PM, Owen Gunden ogun...@phauna.org wrote:

 I'm also a user who runs a full node, and I also like this idea. I think
 Gavin has done some back-of-the-envelope calculations around this stuff,
 but nothing so clearly defined as what you propose.

 On 07/02/2015 08:33 AM, Mistr Bigs wrote:

 I'm an end user running a full node on an aging laptop.
 I think this is a great suggestion! I'd love to know what system
 requirements are needed for running Bitcoin Core.

 On Thu, Jul 2, 2015 at 6:04 AM, Jean-Paul Kogelman
 jeanpaulkogel...@me.com mailto:jeanpaulkogel...@me.com wrote:

 I’m a game developer. I write time critical code for a living and
 have to deal with memory, CPU, GPU and I/O budgets on a daily basis.
 These budgets are based on what we call a minimum specification (of
 hardware); min spec for short. In most cases the min spec is based
 on entry model machines that are available during launch, and will
 give the user an enjoyable experience when playing our games.
 Obviously, we can turn on a number of bells and whistles for people
 with faster machines, but that’s not the point of this mail.

 The point is, can we define a min spec for Bitcoin Core? The number
 one reason for this is: if you know how your changes affect your
 available budgets, then the risk of breaking something due to
 capacity problems is reduced to practically zero.



 ___
 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



 ___
 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] Outroduction of old non-updated full nodes through graceful degradation to SPV mode

[Jeff Garzik]

Older nodes have been phased out in the past.  For example, protocol
versions older than 209 were phased out.

Follow the yellow brick git trail starting at
18c0fa97d0408a3ee8e4cb39c08156f7667f99ac


On Sat, Jun 27, 2015 at 3:53 PM, Natanael natanae...@gmail.com wrote:

 Old versions of software that can't be sandboxed from the world by design
 must eventually die. The reason is simple - otherwise it will be abused,
 exploited and end up actively countering its own intended purpose. Either
 through security holes or other means of abusing the outdated code's
 behavior.

 Full nodes in Bitcoin validate all new transactions against their own
 embedded policies and rules. Eventually the global concensus will agree on
 a change of rules, as the current ruleset isn't perfect - this will toss
 incompatible old full nodes off the greatest-PoW blockchain. This is
 inevitable - not all instances of the software will get updated. Scanning
 the Internet for Internet accessible hardware will reveal tons of outdated
 software versions.

 There is however currently no simple way to tell a node that it is
 outdated. Even if you just incremented block versions, it will only lead to
 some kind of alert (IIRC) for some versions. I'm suggesting behaviors that
 would simplify transition to new versions over time with minimal
 disruption.

 * Expiration dates. Nodes so old that they are behind by numerous soft
 forks and likely are to be deprecated by a hard fork should switch to SPV
 mode automatically while also alerting the node owner. This behavior
 extends the lifetime while not by itself breaking anything with minimal
 disruption. It also allows node owners which look at the status of their
 nodes but don't think of updating (maybe it is automatically deployed old
 software images) to realize an update is sin necessary. SPV mode also needs
 to have an expiration date before complete node shutdown. Expiration dates
 also minimize risk for political disagreement regarding how and when to
 take any manual action to trigger necessary alerts. 3 years to SPV is a
 reasonable default IMHO, with node shutdown after 5 years. Any other
 suggestions?

 * Explicit declaration of block policy / rules in blocks, including miner
 votes for changes, and explicit declaration of incompatibility with old
 versions. Having votes visible in the blocks for implementing changes
 incompatible with the policy and rules your node runs allows it to alert
 the node owner of impending necessity to update. Switching to SPV mode
 again provides for minimal disruption. Please take note that even old SPV
 nodes may eventually be deprecated through data structure changes, this too
 should be declared and then cause alerts and halt / shutdown of those
 nodes.

 This also protects against another issue - an old abandoned node will not
 automatically trust a fresh longer chain (likely malicious) using its own
 policy if it remembers an earlier fork voting for change, instead it
 prompts for the node owner to either update (or stick to SPV on the
 new-policy chain) or to accept this fresh fork. Nodes on a chain with its
 own policy seeing a fork with a vote for change should look at the PoW
 first. If it is close, alert the user (he might have brought the node
 online just after the vote finished, to first see the fork that is on his
 old policy), so he can investigate. If the PoW is far behind it may be
 ignored, or simply logged.

 Seeing a block also explicitly declare being incompatible with the policy
 a node follows including for SPV nodes, rather than just using version
 numbers, simplifies things too. It ensures the nodes know they can't
 validate the blocks with their old code, which simultaneously ensures that
 behavior changes that doesn't violate the old validation code but yet
 causes incompatibility then will not silently fork the network, instead it
 will let the node owners know their nodes are incompatible with the main
 chain. This allows them to investigate and update of necessary.

 ---

 The primary reason for me suggesting switching to SPV mode is simple - it
 buys time for everybody. Hard forks no longer become a critical deadline
 for getting the ENTIRE network upgraded - you just need to worry about the
 miners and major players in the short term. Long term you do need
 information campaigns to get SPV fallback nodes updated, but it won't need
 to be rushed. The information campaigns no longer need to be FULLY
 completed BEFORE deployment.

 Feedback?

 - Sent from my tablet

 ___
 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 Process and Votes

[Jeff Garzik]

Ladies  gents, please do not feed the troll.  This has been explained to
Milly multiple times in the past, on previous mailing list  github with no
impact.


On Wed, Jun 24, 2015 at 7:34 PM, Milly Bitcoin mi...@bitcoins.info wrote:

  I'm sorry but that is the kind of defensive, cultish response everyone
 gets when they ask that question.  If you had a well constructed documented
 process then you would be able to point to it ... but you can't.  While
 there are a few bits and pieces scattered  about in different places there
 is no coherent plan or process.

 It is easy to make statements like consensus must be unanimous but the
 issue is that you never have true 100% consensus yet you have to move
 forward in some fashion and everyone has to run software with the same
 consensus rules.  The issue is how you move forward is the question that
 nobody wants to answer because (a) it is a hard question to answer and (b)
 developers see it as a threat to their authority/position.  If people just
 keep shutting down the discussion with a bunch of cultish stock answers
 then you are never going to move forward with developing some kind of
 process.

 From what I can see much of the discussion is personality-driven and not
 based on Computer Science or and defined process.  The issue is that a
 personality has changed so the process is perceived to be different and
 some people want to hard fork.  Previously, the cultish answer is that
 Bitcoin development is decentralized because people can fork the code.  Now
 that some developers want to fork the code suddenly it is a big problem.
 Is forking the code part of the consensus process or is it the work of the
 devil?   The fact that there is so much diverse opinion on this shows a
 defined process has never been fully vetted or understood.

 I have worked on these processes for many years for projects orders of
 magnitudes larger than Bitcoin.  I can absolutely assure you the current
 mishmash does not scale and huge amounts of time are wasted.  That should
 be readily apparent from the recent discussions and the recent concern it
 has caused from people outside the developer's inner circle.

 Lack of defined process = high risk and wasted effort.

 Russ





 On 6/24/2015 9:50 PM, Mark Friedenbach wrote:

   I'm sorry but this is absolutely not the case, Milly. The reason that
 people get defensive is that we have a carefully constructed process that
 does work (thank you very much!) and is well documented. We talk about it
 quite often in fact as it is a defining characteristic of how bitcoin is
 developed which differs in some ways from how other open source software is
 developed -- although it remains the same in most other ways.

  Changes to the non-consensus sections of Bitcoin Core tend to get merged
 when there are a few reviews, tests, and ACKs from recognized developers,
 there are no outstanding objections, and the maintainer doing the merge
 makes a subjective judgement that the code is ready.

  Consensus-changes, on the other hand, get merged into Bitcoin Core only
 after the above criteria are met AND an extremely long discussion period
 that has given all the relevant stakeholders a chance to comment, and no
 significant objections remain. Consensus-code changes are unanimous. They
 must be.

  The sort of process that exists in standards bodies for example, with
 working groups and formal voting procedures, has no place where changes
 define the nature and validity of other people's money. Who has the right
 to reach into your pocket and define how you can or cannot spend your
 coins? The premise of bitcoin is that no one has that right, yet that is
 very much what we do when consensus code changes are made. That is why when
 we make a change to the rules governing the nature of bitcoin, we must make
 sure that everyone is made aware of the change and consents to it.

  Everyone. Does this work? Does this scale? So far, it does.
 Uncontroversial changes, such as BIP 66, are deployed without issue. Every
 indication is that BIP 66 will complete deployment in the very near future,
 and we intend to repeat this process for more interesting changes such as
 BIP65: CHECKLOCKTIMEVERIFY.

  This isn't about no one stepping forward to be the decider. This is
 about no one having the right to decide these things on the behalf of
 others. If a contentious change is proposed and not accepted by the process
 of consensus, that is because the process is doing its job at rejecting
 controversial changes. It has nothing to do with personality, and
 everything to do with the nature of bitcoin itself.


 On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin  mi...@bitcoins.info
 mi...@bitcoins.info wrote:

 I have seen this question asked many times.  Most developers become
 defensive and they usually give a very vague 1-sentence answer when this
 question is asked.  It seems to be it is based on personalities rather than
 any kind of definable process.  To have that