Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Andy Chase via bitcoin-dev]

As posted:

**Enforcement/Organization** I agree with your comments. I don't believe in
setting up an organization to manage this process (would be too much power
and not really needed because the internet is pretty good at information
sharing). Therefore, I designed it around the assumption that participation
is voluntary. This means that it's hard to enforce rules like forcing
groups to see the other side. Groupthink/Echo chambers is real and is bad
but it's hard to change human nature.

In regards to enforcement, I believe that the best approach would be to
motivate committees to produce the best opinion they can (and also proof of
stake, another weak point in this proposal), as the better they can do this
the more likely the community will accept their opinion as valid and
important.

Indeed, I believe that without an organization managing the process, it's
up to each individual reader of each BIP/Opinions set to make the decision
on whether or not there is clear and true community acceptance.



**Committee versus another approach**

Pros of using Committees:

* Committees are used today in many fields with a range of success. Lots of
previous work to work off of here, history is established.
* Many segments already have committee-like structures (Merchants produce
shared signed documents, miners often represent themselves, User groups
have representatives like voting on subreddit moderators, Core Devs have
Core Devs)
* Committees can filter a range of opinions down to a yes/no
* Committees have real people that can be talked to, contacted, etc.
* Much easier to proof stake in a range (People generally accept the
Bitcoin Core has 70-90% of the market share) vs someone trying to proof
they make up (.01% of the Bitcoin user-base)
* Committees have some stability, encourages experience and expertise
(Committee members can be knowledgeable in their area and adequately
understand BIPs)

Cons:

* Fear of committees working in the dark, censoring opinions (i.e. "Dark
smokey room of fat cats") (Possible solution: make committee power fluid
i.e. easily abandon-able: miners can change pools, users can change client
forks, change merchants, users can re-group, encourage transparency)
* More centralized, centralization of power (generally bad) (Possible
solution: encourage smaller committees)
* Centralization pressure (groups may seek to consolidate to gain power)
(Possible solution: Segmentation)
* Encourages groupthink, political maneuvers, turns good people into
politicians, mud-tossing

**Another possible approach: micro votes**

Pros:

* Each user can represent themselves, no censorship
* People feel more involved and empowered

Cons:

* How to prove and prevent manipulation?
* Only motivated people will contribute. Motivated people may be motivated
for bad reasons.


On Thu, Sep 3, 2015 at 5:43 PM, Bryan Bishop  wrote:

> On Thu, Sep 3, 2015 at 7:30 PM, Andy Chase via bitcoin-dev
>  wrote:
> > I wrote the BIP mostly to stir the pot on ideas of governance
>
> Some quick comments:
>
> I have some objects that I am not ready to put into words, but I do
> think there are easily some major objections to committee design. If I
> vanish and never respond with my objections, perhaps there's an IETF
> RFC about this already
>
> Something that may mitigate my possible objections would be some
> mandatory requirement about ecosystem echo-chambers making many
> attempts and efforts at steelman representations of alternative
> viewpoints. Understanding objections at a fundamental level, enough to
> make strong steelman statements, is very important to ensure that the
> competing opinions are not censored from consideration. Pathological
> integration and internalization of these steelman arguments can be
> very useful, even if the process looks unusual.
>
> Your process does not have to replace any particular BIP process
> as-is, but rather could be an alternative that proceeds on its own
> perhaps indefinitely without replacement. I don't think too many BIP
> processes are necessarily incompatible except by namespace collision.
>
> https://gist.github.com/andychase/dddb83c294295879308b#gistcomment-1566432
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 100 specification

[Peter Todd via bitcoin-dev]

On Thu, Sep 03, 2015 at 01:34:54PM -0700, Dave Scotese via bitcoin-dev wrote:
> I have seen "1M" mean 1,000,000 bytes as well as 1,048,576bytes and
> 1,024,000 bytes.  I believe the best policy is to use "megabyte" to mean
> 2^20 (1,048,576) bytes.  Kb always means 1024 bytes, even when a lot people
> round it, so I like the K spec best.  I also see value in having human
> readable data.  The spec should nail down these details.

The IEC standard is to use the prefix MiB for 2^20 bytes:

https://en.wikipedia.org/wiki/Binary_prefix

-- 
'peter'[:-1]@petertodd.org
10f9e95aff6454fedb9d0a4b92a4108e9449c507936f9f18


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

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Andy Chase via bitcoin-dev]

> Any such a BIP like this needs to
> document the natural forces involved in real-world acceptance, not try to
lay
> down "rules" that people are expected to follow.

That's my goal: to take the hodgepodge of we already use for acceptance,
and apply rules that allow true acceptance to be identified in a clearer
way.

If people don't follow the "rules" then the system simply won't work, this
is mentioned in the last section.

On Thu, Sep 3, 2015 at 5:41 PM, Luke Dashjr  wrote:

> On Friday, September 04, 2015 12:30:50 AM Andy Chase via bitcoin-dev wrote:
> > Here's a BIP. I wrote the BIP mostly to stir the pot on ideas of
> > governance, but I’m moderately serious about it.
>
> Sigh. There is *no governance at all*. Any such a BIP like this needs to
> document the natural forces involved in real-world acceptance, not try to
> lay
> down "rules" that people are expected to follow.
>
> For hardforks, that means economic consensus. For softforks, miner
> majority.
> For basically anything else, real-world implementation and use (by any
> significant quantity of people).
>
> Luke
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Bryan Bishop via bitcoin-dev]

On Thu, Sep 3, 2015 at 7:30 PM, Andy Chase via bitcoin-dev
 wrote:
> I wrote the BIP mostly to stir the pot on ideas of governance

Some quick comments:

I have some objects that I am not ready to put into words, but I do
think there are easily some major objections to committee design. If I
vanish and never respond with my objections, perhaps there's an IETF
RFC about this already

Something that may mitigate my possible objections would be some
mandatory requirement about ecosystem echo-chambers making many
attempts and efforts at steelman representations of alternative
viewpoints. Understanding objections at a fundamental level, enough to
make strong steelman statements, is very important to ensure that the
competing opinions are not censored from consideration. Pathological
integration and internalization of these steelman arguments can be
very useful, even if the process looks unusual.

Your process does not have to replace any particular BIP process
as-is, but rather could be an alternative that proceeds on its own
perhaps indefinitely without replacement. I don't think too many BIP
processes are necessarily incompatible except by namespace collision.

https://gist.github.com/andychase/dddb83c294295879308b#gistcomment-1566432

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Luke Dashjr via bitcoin-dev]

On Friday, September 04, 2015 12:30:50 AM Andy Chase via bitcoin-dev wrote:
> Here's a BIP. I wrote the BIP mostly to stir the pot on ideas of
> governance, but I’m moderately serious about it.

Sigh. There is *no governance at all*. Any such a BIP like this needs to 
document the natural forces involved in real-world acceptance, not try to lay 
down "rules" that people are expected to follow.

For hardforks, that means economic consensus. For softforks, miner majority. 
For basically anything else, real-world implementation and use (by any 
significant quantity of people).

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

[bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Andy Chase via bitcoin-dev]

Here’s a BIP. I wrote the BIP mostly to stir the pot on ideas of governance, 
but I’m moderately serious about it. This is set in Markdown for readability, 
but here’s the BIP-0001 Medawiki version: 
https://gist.github.com/andychase/dddb83c294295879308b 



  Title: BIP Acceptance Process
  Author: Andy Chase
  Status: Draft
  Type: Process
  Created: 2015-08-31

Abstract


The current process for accepting a BIP is not clearly defined. While
BIP-0001 defines the process for writing and submitting a Bitcoin
improvement proposal to the community it does not specify the precise
method for which BIPs are considered accepted or rejected.

This proposal sets up a method for determining BIP acceptance.

This BIP has two parts:

-   It sets up a process which a BIP goes through for comments
  and acceptance.
  -   The Process is:
  -   BIP Draft
  -   Submitted for comments (2 weeks)
  -   Waiting on opinion (two weeks)
  -   Accepted or Deferred
-   It sets up committees for reviewing comments and indicating
  acceptance under precise conditions.
  -   Committees are authorized groups that represent client authors,
  miners, merchants, and users (each as a segment). Each one must
  represent at least 1% stake in the Bitcoin ecosystem.

BIP acceptance is defined as at least 70% of the represented percentage
stake in 3 out of the 4 Bitcoin segments.

Copyright
=

This document is placed into the public domain.

Motivation
==

BIPs represent important improvements to Bitcoin infrastructure, and in
order to foster continued innovation, the BIP process must have clearly
defined stages and acceptance acknowledgement.

Rationale
=

A committee system is used to organize the essential concerns of each
segment of the Bitcoin ecosystem. Although each segment may have many
different viewpoints on each BIP, in order to seek a decisive yes/no on
a BIP, a representational authoritative structure is sought. This
structure should be fluid, allowing people to move away from committees
that do not reflect their views and should be re-validated on each BIP
evaluation.

Weaknesses
==

Each committee submits a declaration including their claim to represent
a certain percentage of the Bitcoin ecosystem in some way. Though
guidelines are given, it's up to each committee to prove their stake,
and it's up to the reader of the opinions to decide if a BIP was truly
accepted or rejected.

The author doesn't believe this is a problem because a BIP cannot be
forced on client authors, miners, merchants, or users. Ultimately this
BIP is a tool for determining whether a BIP is overwhelmingly accepted.
If one committee's validity claim becomes the factor that decides
whether the BIP will succeed or fail, this process simply didn't return
a clear answer and the BIP should be considered deferred.

Process
===

-   **Submit for Comments.** The first BIP champion named in the
  proposal can call a "submit for comments" at any time by posting to
  the [Dev Mailing
  List](https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 
)
  mailling with the BIP number and a statement that the champion
  intends to immediately submit the BIP for comments.
  -   The BIP must have been assigned BIP-number (i.e. been approved
  by the BIP editor) to be submitted for comments.
-   **Comments.**
  -   After a BIP has been submitted for comments, a two-week waiting
  period begins in which the community should transition from
  making suggestions about a proposal to publishing their opinions
  or concerns on the proposal.
-   **Reported Opinions.**
  -   After the waiting period has past, committees must submit a
  summary of the comments which they have received from their
  represented communities.
  -   The deadline for this opinion is four weeks after the BIP was
  submitted for comments.
  -   Committees cannot reverse their decision after the deadline, but
  at their request may flag their decision as "likely to change if
  another submit for comments is called". Committees can change
  their decision if a resubmit is called.
  -   Opinions must include:
  -   One of the following statements: "Intend to accept", "Intent
  to implement", "Decline to accept", "Intend to accept, but
  decline to implement".
  -   If rejected, the opinion must cite clear and specific
  reasons for rejecting including a checklist for what must
  happen or be change for their committee to accept
  the proposal.
  -   If accepted, the committee must list why they accepted the
  proposal and also include concerns they have or what about
  the BIP that, if things changed, would cause the committee
  to likely reverse their decision if another submit for
  comments was ca

Re: [bitcoin-dev] Proposed minor change to BIP 01 to use a PR for request assignment

[Gregory Maxwell via bitcoin-dev]

On Fri, Sep 4, 2015 at 12:17 AM, Marco Pontello  wrote:
> None that I can see.
> In fact I was just about to ask for some details about this part of the
> process, so this come just at the right time.

We used to have a WIKI page for all the BIP stuff and that worked
better IMO, the use of git(hub) for it was a step forward in a number
of ways but made the number assignment part an odd duck. We should
have fixed it then, but it wasn't obvious (enough) that it needed
fixing at the time. Live and learn.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposed minor change to BIP 01 to use a PR for request assignment

[Marco Pontello via bitcoin-dev]

None that I can see.
In fact I was just about to ask for some details about this part of the
process, so this come just at the right time.

On Fri, Sep 4, 2015 at 1:18 AM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The process in BIP01 was written when we used a different solution for
> storing and presenting BIPs.
>
> I'm thinking of suggesting that the number request process be changed
> to opening a pull req with BIP text with no number (e.g. just using
> the authors name and an index as the number) as the mechenism to
> request number assignment.
>
> Is there any reason that anyone would find this objectionable?
>
> (Please do not respond to this message with anything but a strictly
> directed answer to that question, start a new thread for a different
> subject. Thanks!)
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>



-- 
Try the Online TrID File Identifier
http://mark0.net/onlinetrid.aspx
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Alpha release of METAmarket available for download NOW for Windows and Linux. Come help us test a new standard in P2P e-commerce!

[Marc D. Wood via bitcoin-dev]

I'm pleased to announce the newest contender in the field of decentralized
e-commerce. 100% P2P and 100% customize-able. Using METAmarket, you can
create your own market where you make the rules. Open to all or Private?
Wholesale or retail? Moderated or unmoderated? Clearnet or Darknet? You
are in complete control of your local market. There are always people
looking for cheap and easy ways to trade and METAmarket uses a zero-fee
approach. All funds are secure from theft or exit scams using a P2P
Bitcoin multisig escrow between buyer and seller ONLY. (NO third parties!)
METAmarket is built directly on top of the Bitcoin and Bitmessage
reference clients, keeping security as priority #1. The future of
e-commerce under your control. The future of e-commerce is METAmarket.

http://www.notbeinggoverned.com/metamarket-whitepaper/

https://bitcointalk.org/index.php?topic=1044827.0

http://metamarket.biz/


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

Re: [bitcoin-dev] RFC: HD Bitmessage address derivation based on BIP-43

[Luke Dashjr via bitcoin-dev]

On Tuesday, June 30, 2015 5:53:05 PM Justus Ranvier wrote:
> Monetas has developed a Bitmessage address derivation method from an
> HD seed based on BIP-43.
> 
> https://github.com/monetas/bips/blob/bitmessage/bip-bm01.mediawiki
>
> We're proposing this as a BIP per the BIP-43 recommendation in order
> to reserve a purpose code.

Bitmessage is not Bitcoin, thus this falls outside the scope of the BIP 
process. Since BIP 43 is still a draft, I propose modifying it to refer non-
Bitcoin purpose codes to the SLIP repository:
https://doc.satoshilabs.com/slips/

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

[bitcoin-dev] Multi-chain payment channel nodes

[Bryan Bishop via bitcoin-dev]

Here is a brief overview of a way to use something like the lightning
network, or another multi-hop payment channel network, to handle more
transactions per second.

These ideas were mentioned yesterday in #bitcoin-wizards and my email
does not significantly elaborate on any of it (search for
"cross-chain"):
http://gnusha.org/bitcoin-wizards/2015-09-01.log
http://gnusha.org/bitcoin-wizards/2015-09-02.log

Mailing list discussion of this can be found at [6] and on the forum at [7].

Summary
===

Payment channel network nodes could operate on multiple chains or
ledgers, especially if those ledgers are 2-way-peg compatible with
BTC. Payment network users may have a variety of different preferences
about security models or fees or any other number of system
properties, and this method can be more accomodating than only
offering mainnet UTXOs.

Terminology
===

During the IRC monologue I was using the word "hub" and "cross-chain
hubs" to describe a payment channel network node. Rusty Russell later
brought to my attention a good argument from Joseph Poon to prefer to
call them nodes, namely that "hub" implies centralization which isn't
really necessary to implicate in these designs. So I'll stick with
"node".

Vague requirements and scenario speculation
===

- bip70-like payment-channel-compatible wallet-to-wallet communication
protocol; useful for sender and receiver to negotiate how payment
should be routed over the payment channel network.

- assume existence of other ledgers with working 2-way-peg.

- lightning network[1], amiko pay[2], or some other payment channel
network with multi-hop payment routing

- (at least some) payment channel nodes which access more than one
blockchain or ledger system

- can be more than two chains or ledgers that the node opens channels
on or operate on (octoledger nodes?)

- node can eventually setup 2-way-pegs through moxiebox code embedded
in some opcode for a specification of an alternative federated ledger
(just kidding, there be dragons here)

Implication: Chain or ledger UTXO ambivalence
=

The sender (receiver) doesn't need to be concerned with which chain
the receiver (sender) wishes to transact with, as long as both parties
have wallets that can communicate with each other for fee negotiation
while payment channel routing happens.

Implication: UTXO preferences informed by fee pressures
===

An earlier identified implication by others has been that transaction
fee trends may influence when payment channel users choose to settle
on the main chain, because fees may be too high to make the tradeoffs
worthwhile for the user.

Transaction fee pressure on the bitcoin mainnet chain may influence
receivers, otherwise busy negotiating their payment channel payments,
to negotiate receipt of their UTXOs on alternative chains which might
be charging lower fees. Users that wish to settle to a ledger for a
lower fee can do so without paying for main chain transaction
prioritization.

(Concerns about market exchange rate of BTC even with the presence of
2-way-pegs could be alleviated by multi-chain nodes that practice
arbitrage. However, perhaps the financial markets will not bother
assigning different values to BTC-compatible UTXOs on different
sidechains? High mainnet fees may be reflected in market price
differences, maybe)

Minor lightning network protocol change
===

Add chain parameter to onion routing protocol message. Receipt of this
message was acknowledged by Rusty Russell yesterday. However, this
change alone may be insufficient to enable this described usage. Also
while I hope that onion routing continues to be the direction there's
no guarantee of course.

Other: Centralized ledgers
==

Centralized ledger operators, such as companies running spot
exchanges, could run payment channel nodes, allowing their users to
deposit and withdraw funds "immediately" subject to whether the
service provider is operating anything resembling a hot wallet. A
centralized ledger operator could be considered a valid multi-chain
destination in the above-mentioned imaginary lightning-compatible
payment protocol. Payment channel network programmers should not be
burdened with a thousand different standards for this ability, and
instead there should be an attempt at general compatibility, although
trustless implementations should be preferred if available.

Luke-Jr mentions that the same (currently imaginary) payment protocol
could also provide for user-to-user transfers on the same centralized
services, skipping the payment channels entirely.

Other
=

Here are some things that I have been meaning to look at, but haven't looked at:

- can we do probabilistic payments[3][4] over payment channels? does
it require all payments to be probabilistic payments?

- is lightning network + m

Re: [bitcoin-dev] Proposed minor change to BIP 01 to use a PR for request assignment

[Btc Drak via bitcoin-dev]

It's a good idea. It would remove friction from the process and
assignment is auditable to boot, something I've had difficulty with in
the past. Almost every time I see a BIP number I would wonder, is that
self-assigned (and thus invalid) or has it been assigned by the BIP
editor.

On Fri, Sep 4, 2015 at 12:18 AM, Gregory Maxwell via bitcoin-dev
 wrote:
> The process in BIP01 was written when we used a different solution for
> storing and presenting BIPs.
>
> I'm thinking of suggesting that the number request process be changed
> to opening a pull req with BIP text with no number (e.g. just using
> the authors name and an index as the number) as the mechenism to
> request number assignment.
>
> Is there any reason that anyone would find this objectionable?
>
> (Please do not respond to this message with anything but a strictly
> directed answer to that question, start a new thread for a different
> subject. 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

[bitcoin-dev] Proposed minor change to BIP 01 to use a PR for request assignment

[Gregory Maxwell via bitcoin-dev]

The process in BIP01 was written when we used a different solution for
storing and presenting BIPs.

I'm thinking of suggesting that the number request process be changed
to opening a pull req with BIP text with no number (e.g. just using
the authors name and an index as the number) as the mechenism to
request number assignment.

Is there any reason that anyone would find this objectionable?

(Please do not respond to this message with anything but a strictly
directed answer to that question, start a new thread for a different
subject. Thanks!)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Adhoc Bitcoin Network

[jimsmit--- via bitcoin-dev]

Hi,

Is there a feature in Bitcoin that supports adhoc networks, that merge their 
work into the main Blockchain at some point?


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

Re: [bitcoin-dev] BIP 100 specification

[Dave Scotese via bitcoin-dev]

I have seen "1M" mean 1,000,000 bytes as well as 1,048,576bytes and
1,024,000 bytes.  I believe the best policy is to use "megabyte" to mean
2^20 (1,048,576) bytes.  Kb always means 1024 bytes, even when a lot people
round it, so I like the K spec best.  I also see value in having human
readable data.  The spec should nail down these details.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 100 specification

[Oliver Petruzel via bitcoin-dev]

I agree with Simon's sentiments for question #1, and was actually going to
pose the same question. Non-votes seem like they may poison the well
mathematically, and counting them anyway seems to encourage a lack of
participation at a time when miners really need to be very much involved.
Since we're handing them even more control over the ecosystem with this
BIP, it would be nice to ensure they (all miners) seriously consider their
impact and role on a regular basis.

I'm curious why we couldn't/shouldn't simply drop the non-votes. (There may
be a great reason that I can't think of, but it's eluding me... LOL)

That said, I don't see any issue with counting votes from outside of the
range as the maximum/minimum accordingly (Simon's question #2). In fact,
such votes would be very interesting (worthy of further discussion) if they
begin to lean heavily in either direction.

V/r,
Oliver
On Sep 3, 2015 3:41 PM, "Simon Liu via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Jeff,
>
> Thoughts on this part of the proposal:
>
> "Absent/invalid votes are counted as votes for the current hardLimit.
> Out of range votes are counted as the nearest in-range value."
>
> 1. Why should an absent vote be considered a vote for the status quo?  A
> non-voter should have zero impact on the result.
>
> 2. Why should out of range votes be counted?  They're an invalid vote, a
> spoiled ballot as such, and thus it would be better if they were discarded.
>
> Regards,
> Simon
>
>
> On 09/02/2015 08:33 PM, Jeff Garzik via bitcoin-dev wrote:
> > 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
> >
> ___
> 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 100 specification

[Simon Liu via bitcoin-dev]

Hi Jeff,

Thoughts on this part of the proposal:

"Absent/invalid votes are counted as votes for the current hardLimit.
Out of range votes are counted as the nearest in-range value."

1. Why should an absent vote be considered a vote for the status quo?  A
non-voter should have zero impact on the result.

2. Why should out of range votes be counted?  They're an invalid vote, a
spoiled ballot as such, and thus it would be better if they were discarded.

Regards,
Simon


On 09/02/2015 08:33 PM, Jeff Garzik via bitcoin-dev wrote:
> 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
> 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Gregory Maxwell via bitcoin-dev]

On Thu, Sep 3, 2015 at 6:23 PM, Jorge Timón  wrote:
> Greg, I believe Jeff is focusing on BtcDrak's proposal (
> https://gist.github.com/btcdrak/1c3a323100a912b605b5 ) where the
> increased nBits are used to vote for the block size to raise
> permanently ( or until it gets voted down).
> His arguments don't seem to apply to your original proposal (where the
> size is only increased for that block).

Ah, that would clarify things for me me.

Please everyone try to speak specifically enough to catch details like that.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Btc Drak via bitcoin-dev]

Maybe Jeff can clarify but my communications with him seemed to imply
he didn't think any kind of difficulty penalty scheme is workable. I
strongly dispute that assertion.

On Thu, Sep 3, 2015 at 7:23 PM, Jorge Timón
 wrote:
> Greg, I believe Jeff is focusing on BtcDrak's proposal (
> https://gist.github.com/btcdrak/1c3a323100a912b605b5 ) where the
> increased nBits are used to vote for the block size to raise
> permanently ( or until it gets voted down).
> His arguments don't seem to apply to your original proposal (where the
> size is only increased for that block).
>
>
> On Thu, Sep 3, 2015 at 7:57 PM, Gregory Maxwell via bitcoin-dev
>  wrote:
>> On Thu, Sep 3, 2015 at 2:40 PM, Jeff Garzik  wrote:
>>> 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"
>>
>> Sorry, I'm still not following.  I agree that predictability is important.
>>
>> I don't follow where unpredictability is coming from here. Most (all?)
>> of the difficulty based adjustments had small limits on the difficulty
>> change that wouldn't have substantially changed the interblock times
>> relative to orphaning.
>>
>>> 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
>>
>> What the schemes propose is blocksize that increases fast with
>> difficulty over a narrow window. The result is that your odds of
>> producing a block are slightly reduced but the block you produce if
>> you do is more profitable: but only if there is a good supply of
>> transactions which pay real fees compariable to the ones you're
>> already taking.  The same trade-off exists at the moment with respect
>> to orphaning risk and miners still produce large blocks, producing a
>> larger block means a greater chance you're not successful (due to
>> orphaning) but you have a greater utility.  The orphing mediated risk
>> is fragile and can be traded off for centeralization advantage or by
>> miners bypassing validation, issues which at least so far we have no
>> reason to believe exist for size mediated schemes.
>>
>> As you know, mining is not a race (ignoring edge effects with
>> orphaning/propagation time). Increasing difficulty does not put you at
>> an expected return disavantage compared to other miners so long as the
>> income increases at least proportionally (otherwise pooling with low
>> diff shares would be an astronomically losing proposition :)!).
>>
>> Pay-for-size schemes have been successfully used in some altcoins
>> without the effects you're suggesting.
>> ___
>> 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] block size - pay with difficulty

[jl2012 via bitcoin-dev]

Assuming that:
1. The current block size is 1MB
2. The block reward for a full block is 25.5BTC including tx fee
3. Miner is required to pay x% of reward penalty if he is trying to 
increase the size of the next block by x%


If a miner wants to increase the block size by 1 byte, the block size 
has to increase by 0.0001%, and the penalty will be 0.255BTC/byte. 
For a typical 230byte tx that'd be 0.005865BTC, or 1.35USD at current 
rate. This is the effective minimum tx fee.




Jeff Garzik 於 2015-09-03 10:18 寫到:

Thanks for the link.  I readily admit only having given
pay-to-future-miner a little bit of thought.  Not convinced it sets a
minimal tx fee in all cases.

On Thu, Sep 3, 2015 at 12:55 AM,  wrote:


Jeff Garzik via bitcoin-dev 於 2015-09-03 00:05 寫到:


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
[1]


Ref:


https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010723.html

[2]

I explained here why pay with difficulty is bad for everyone:
miners and users, and described the use of OP_CLTV for
pay-to-future-miner

However, a general problem of pay-to-increase-block-size scheme is
it indirectly sets a minimal tx fee, which could be difficult and
arbitrary, and is against competition




Links:
--
[1] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[2]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010723.html


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

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

[Tom Harding via bitcoin-dev]

On 9/2/2015 9:05 PM, Jeff Garzik via bitcoin-dev wrote:
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.




Another market dependency is even more direct.

Blocksize that can be bought with either difficulty or bitcoin has 
incentives whose strength (though not direction) is subject to the 
exchange rate.  Hence those incentives are subject to the whims of fiat 
holders, who can push the exchange rate around.


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

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

[Jorge Timón via bitcoin-dev]

Greg, I believe Jeff is focusing on BtcDrak's proposal (
https://gist.github.com/btcdrak/1c3a323100a912b605b5 ) where the
increased nBits are used to vote for the block size to raise
permanently ( or until it gets voted down).
His arguments don't seem to apply to your original proposal (where the
size is only increased for that block).


On Thu, Sep 3, 2015 at 7:57 PM, Gregory Maxwell via bitcoin-dev
 wrote:
> On Thu, Sep 3, 2015 at 2:40 PM, Jeff Garzik  wrote:
>> 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"
>
> Sorry, I'm still not following.  I agree that predictability is important.
>
> I don't follow where unpredictability is coming from here. Most (all?)
> of the difficulty based adjustments had small limits on the difficulty
> change that wouldn't have substantially changed the interblock times
> relative to orphaning.
>
>> 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
>
> What the schemes propose is blocksize that increases fast with
> difficulty over a narrow window. The result is that your odds of
> producing a block are slightly reduced but the block you produce if
> you do is more profitable: but only if there is a good supply of
> transactions which pay real fees compariable to the ones you're
> already taking.  The same trade-off exists at the moment with respect
> to orphaning risk and miners still produce large blocks, producing a
> larger block means a greater chance you're not successful (due to
> orphaning) but you have a greater utility.  The orphing mediated risk
> is fragile and can be traded off for centeralization advantage or by
> miners bypassing validation, issues which at least so far we have no
> reason to believe exist for size mediated schemes.
>
> As you know, mining is not a race (ignoring edge effects with
> orphaning/propagation time). Increasing difficulty does not put you at
> an expected return disavantage compared to other miners so long as the
> income increases at least proportionally (otherwise pooling with low
> diff shares would be an astronomically losing proposition :)!).
>
> Pay-for-size schemes have been successfully used in some altcoins
> without the effects you're suggesting.
> ___
> 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] block size - pay with difficulty

[Gregory Maxwell via bitcoin-dev]

On Thu, Sep 3, 2015 at 2:40 PM, Jeff Garzik  wrote:
> 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"

Sorry, I'm still not following.  I agree that predictability is important.

I don't follow where unpredictability is coming from here. Most (all?)
of the difficulty based adjustments had small limits on the difficulty
change that wouldn't have substantially changed the interblock times
relative to orphaning.

> 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

What the schemes propose is blocksize that increases fast with
difficulty over a narrow window. The result is that your odds of
producing a block are slightly reduced but the block you produce if
you do is more profitable: but only if there is a good supply of
transactions which pay real fees compariable to the ones you're
already taking.  The same trade-off exists at the moment with respect
to orphaning risk and miners still produce large blocks, producing a
larger block means a greater chance you're not successful (due to
orphaning) but you have a greater utility.  The orphing mediated risk
is fragile and can be traded off for centeralization advantage or by
miners bypassing validation, issues which at least so far we have no
reason to believe exist for size mediated schemes.

As you know, mining is not a race (ignoring edge effects with
orphaning/propagation time). Increasing difficulty does not put you at
an expected return disavantage compared to other miners so long as the
income increases at least proportionally (otherwise pooling with low
diff shares would be an astronomically losing proposition :)!).

Pay-for-size schemes have been successfully used in some altcoins
without the effects you're suggesting.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 100 specification

[Peter Todd via bitcoin-dev]

On Thu, Sep 03, 2015 at 06:32:09PM +0100, Btc Drak via bitcoin-dev wrote:
> Just use a 4-byte unsigned integer where the integer is the size in
> bytes. It's concise and less complex (and less complex to implement).
> There's no need for human readable strings here.

Solid NACK on making string parsers part of the consensus critical
codebase. (WTF‽)

-- 
'peter'[:-1]@petertodd.org
0c69430beea18c71be1d34114d7e1d4023dd1ffe1d9bc7f0


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

Re: [bitcoin-dev] BIP 100 specification

[Btc Drak via bitcoin-dev]

Just use a 4-byte unsigned integer where the integer is the size in
bytes. It's concise and less complex (and less complex to implement).
There's no need for human readable strings here.

On Thu, Sep 3, 2015 at 5:35 PM, Jeff Garzik via bitcoin-dev
 wrote:
> 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
>  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 mailing list
bitcoin-dev@lists.linuxfoundation.org
h

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

Re: [bitcoin-dev] BIP 100 specification

[jl2012 via bitcoin-dev]

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

Re: [bitcoin-dev] BIP 100 specification

[Jorge Timón via bitcoin-dev]

On Sep 3, 2015 5:58 PM, "Btc Drak via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Thu, Sep 3, 2015 at 3:34 PM, Jeff Garzik  wrote:
> > 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.
>
> It's not a matter of avoiding the subject, it's a whole separate
> discussion and in the interests of efficient discussion, it is best
> done separately. There's a whole BIP dedicated to the discussion of
> consensus forks which you should probably give some input in also,
> BIP99 [1]
>
> Once we come to an agreement and can say "here's what we're doing
> about blocksize, it will be X, or we'll raise by this algo", then we
> can discuss the best way to implement the hard fork.
>
> [1] https://github.com/bitcoin/bips/pull/181

In fact, that discussion can happen in parallel. But it is more efficient
to do so in one place instead of in each of the 5+ hardfork proposals
(bip99 itself has a hardfork proposal with its code ready).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 100 specification

[Btc Drak via bitcoin-dev]

On Thu, Sep 3, 2015 at 3:34 PM, Jeff Garzik  wrote:
> 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.

It's not a matter of avoiding the subject, it's a whole separate
discussion and in the interests of efficient discussion, it is best
done separately. There's a whole BIP dedicated to the discussion of
consensus forks which you should probably give some input in also,
BIP99 [1]

Once we come to an agreement and can say "here's what we're doing
about blocksize, it will be X, or we'll raise by this algo", then we
can discuss the best way to implement the hard fork.

[1] https://github.com/bitcoin/bips/pull/181


>
>
>
> On Thu, Sep 3, 2015 at 7:20 AM, Btc Drak  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
>>  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(c

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  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 
> wrote:
>
>> On Thu, Sep 3, 2015 at 4:05 AM, Jeff Garzik via bitcoin-dev
>>  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] 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  wrote:

> On Thu, Sep 3, 2015 at 4:05 AM, Jeff Garzik via bitcoin-dev
>  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]

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,  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/jgarzik/bip100/blob/master/bip-0100.mediawiki [1]
> >
> > Emphasis on "initial"  This is a starting point for the usual open
> > source feedback/iteration cycle, not an endpoint that Must Be This
> > Way.
> >
> >
> >
> > Links:
> > --
> > [1] https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki
> >
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@l

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  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
>  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 hardLimit
> >
> > version 4 block: the coinbase of a version 4 block must match this
> pattern:
> > "/BV\d+/"
> > 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)
> > 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)
> > 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 

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

[Jeff Garzik via bitcoin-dev]

Thanks for the link.  I readily admit only having given pay-to-future-miner
a little bit of thought.  Not convinced it sets a minimal tx fee in all
cases.


On Thu, Sep 3, 2015 at 12:55 AM,  wrote:

> Jeff Garzik via bitcoin-dev 於 2015-09-03 00:05 寫到:
>
>> 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
>>
>
> Ref:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010723.html
>
> I explained here why pay with difficulty is bad for everyone: miners and
> users, and described the use of OP_CLTV for pay-to-future-miner
>
> However, a general problem of pay-to-increase-block-size scheme is it
> indirectly sets a minimal tx fee, which could be difficult and arbitrary,
> and is against competition
>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 100 specification

[Tier Nolan via bitcoin-dev]

On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>1.
>
>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).


>
>1. 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.
>
> 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.


>1. 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

Re: [bitcoin-dev] BIP 100 specification

[Btc Drak via bitcoin-dev]

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
 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 hardLimit
>
> version 4 block: the coinbase of a version 4 block must match this pattern:
> "/BV\d+/"
> 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)
> 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)
> 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/jgarzik/bip100/blob/master/bip-0100.mediawiki [1]
>>
>> Emphasis on "initial"  This is a starting point for the usual open
>> source feedback/iteration cycle, not an endpoint that Must Be This
>> Way.
>>
>>
>>
>> Links:
>> --
>> [1] https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://list

Re: [bitcoin-dev] BIP 100 specification

[jl2012 via bitcoin-dev]

 

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 "/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.
* 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 hardLimit

* version 4 block: the coinbase of a version 4 block must match this
pattern: "/BVd+/"
* 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)
* 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)
* 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/jgarzik/bip100/blob/master/bip-0100.mediawiki [1]
> 
> Emphasis on "initial" This is a starting point for the usual open
> source feedback/iteration cycle, not an endpoint that Must Be This
> Way.
> 
> 
> 
> Links:
> --
> [1] https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki
> 
> ___
> 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