[bitcoin-dev] AT/ISPs making Bitcoin Core near impossible to use as a full node via hidden private dynamic IPs, not by specifically blocking 8333 or Bitcoin as stated in original email

[Zach G via bitcoin-dev]

I sent out an email after 48 hours of dealing with trying to open up my ports 
for Bitcoin, I was quite frustrated and angry since I had to call like 10 times 
and I was making zero progress. Most of the AT people didn't give me any 
helpful clues on how to fix the situation. The original email described how 
there is a firewall in the DVR, and I thought it was blocking the ports. It is 
true there is a uncontrollable firewall in the DVR, it is false this blocks 
8333.

The actual problem is due to AT Uverse customers being forced to use a 
private dynamic IP, the IP is literally hidden from the internet, so it isn't 
possible to send any requests at it. It will literally ignore pings across all 
ports. So the solution is to switch to public static IP and make sure you allow 
incoming traffic. 

It's not so simple though, AT will not let you have a public static IP 
without paying. I've had my router reset 10 times today by AT (probably 
automatically) and it comes back with a private dynamic IP. Then I have to 
reset it to use public IP and that lasts less than an hour. It literally went 
from open to closed while typing this email... the IP address went from public 
to private dynamic. 

https://i.gyazo.com/3c732687fc3d21acb7d62f6d0e23a346.png

This is making using Bitcoin Core almost impossible. I'm at least getting some 
synch now but maybe a few days of blocks the entire day, cause I can't sit here 
all day with the computer and keep fixing it.

The proof is in the pudding, there are 37 nodes using AT in the ENTIRE world. 
AT is a massive ISP so this is strong evidence that using Bitcoin Core as a 
full node on AT is extremely difficult and actually just about impossible.

https://i.gyazo.com/90beebe056f5fc338165e8d200536c06.png

The other big ISPs have pathetic numbers also due to the same sort've things 
that AT does, but at least Comcast has 400 nodes. AT is much harder to use 
than any other ISP I've dealt with when it comes to Bitcoin Core.

I apologize for sending out the wrong info the first time, although it is still 
worth noting the DVR firewall is out of your control, which might be a problem 
if not now then in the future. In any case AT has effectively blocked full 
nodes for Bitcoin Core via the private subnet, and the disability to change it 
to public without paying $15 more per month, and buying a $15 connection 
service so they will give you that info (if you dont pay the connection 
'specialists' hang up on you). 

It is important to note this is not Bitcoin specific, but effects every program 
that depends on freely open ports. I don't think AT has anything against 
Bitcoin, it's just their security settings and policies have disabled Bitcoin 
Core for most customers. Also important to note this isn't a problem specific 
to AT, all the big ISPs are doing similar things. I believe the changes in 
ISP protocol are the main driving force behind the massive decline in Bitcoin 
nodes. Another big factor is firewalls, most people can't even remove the 
firewalls enough to open ports at will. The community needs to educate people 
on how to use Bitcoin Core when facing these intensifying security measures, or 
the decline of node numbers will continue.

 

 
___
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]

If you read between the lines of what was recently changed and why
(reducing to 2MB), it seems reasonable to assume BIP101's allowance
opens up some of the attack vector again.

On Fri, Sep 4, 2015 at 4:37 PM, Simon Liu via bitcoin-dev
 wrote:
> Maybe grab some code from BIP101 ?  It permits block messages > 2MB,
> while retaining the current limit of 2 MB imposed on other network
> messages.  The 32 MB limit was patched a few months ago.
>
> Links to code:
>
> https://www.reddit.com/r/bitcoinxt/comments/3in5mm/psa_correction_to_btcchina_letter_which_states/
>
>
>
> On 09/04/2015 12:53 AM, Andy Chase via bitcoin-dev wrote:
>> The 32Mb limit is
>> here: https://github.com/bitcoin/bitcoin/blob/master/src/serialize.h#L25
>>
>> It's to keep the message size small enough that messages can be
>> serialized in memory.
>>
>> Jeff if you decide to lift the 32MB limit (you really should, unless
>> your plan is to potentially hard force another Blocksize discussion
>> again which might be okay). I suggest having the 32MB ceiling auto-raise
>> according to a exponential factor (1.5?) starting 1 year from now.
>>
>> Basically hard limit ceiling 2016-2017: 32 MB
>> Hard limit ceiling 2018+: 32*((currentYear-2018)*1.5) MB
>>
>> The factor could be 2 like BIP-101 but I imagine you will want to be
>> more conservative. The delay time could also be longer if you think it
>> will take longer to fix the message size issue across all implementations.
>>
> ___
> 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]

Maybe grab some code from BIP101 ?  It permits block messages > 2MB,
while retaining the current limit of 2 MB imposed on other network
messages.  The 32 MB limit was patched a few months ago.

Links to code:

https://www.reddit.com/r/bitcoinxt/comments/3in5mm/psa_correction_to_btcchina_letter_which_states/



On 09/04/2015 12:53 AM, Andy Chase via bitcoin-dev wrote:
> The 32Mb limit is
> here: https://github.com/bitcoin/bitcoin/blob/master/src/serialize.h#L25
> 
> It's to keep the message size small enough that messages can be
> serialized in memory.
> 
> Jeff if you decide to lift the 32MB limit (you really should, unless
> your plan is to potentially hard force another Blocksize discussion
> again which might be okay). I suggest having the 32MB ceiling auto-raise
> according to a exponential factor (1.5?) starting 1 year from now.
> 
> Basically hard limit ceiling 2016-2017: 32 MB
> Hard limit ceiling 2018+: 32*((currentYear-2018)*1.5) MB
> 
> The factor could be 2 like BIP-101 but I imagine you will want to be
> more conservative. The delay time could also be longer if you think it
> will take longer to fix the message size issue across all implementations.
> 
___
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

[Douglas Roark via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

ACK

- -- 
- ---
Douglas Roark
Senior Developer
Armory Technologies, Inc.
d...@bitcoinarmory.com
PGP key ID: 92ADC0D7
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJV6bnBAAoJEGybVGGSrcDXoDAQAJyfypOpGjTQZFR4BAbJzOJ0
vbHv2QjBcf8/FJ7BxLyZYyIzwBBfYyacm69fETKgo2JyzfhFb3KsF7M0lsggBKRT
R5DFr6GRDXTC1p7L7II3U6oGRQ3yHbxvMyep/6CyJYGaEfdnlTinxYsb4WlFIiPh
ZMr9CH+hLHUb4s3Re5/Wl6RNz83ZNeJSAO5o2Iv/2+GCF3Iyh8UfADzDrnMOuWKE
6URhNVvCHvsxYgS/00QN8MW2Dn3txCrUEag10hJ59wlkWRDA26wHosB3m5w/arbO
3OzAkthrkImTYTCusX+Mcitvldc8J88YQD4kNOJvc472j0TTaksl/ubAvDUx1hon
aHdQqb/6A+kxhsvHox0BmUmoqDiAGsVPVJinCDVG8QRUDMVbVIhRgPLK5p9ND/Ab
B0Nm5zZgtyPnGUrY6Ci22xHmeJKcGVmYMudYEkwOOMK8x0AcnDifMu4NjWxxFwIN
Q1CSLuF7FGuAEenO9v/oZklLWrTZ4ewA4pM5uaYtTQHc3AD+Jg3/ZcmHQxDlSQMJ
EiaB5rvLXwvlLthDOtr3gEG+8f08KWl0eJijrhd6UQCvEsMje19LAXxuU49u2A3C
l1T2XzxPquGC1FfrWCwY+/pGsOaH7eNnCBBnBZGBuXWt3pFL2C0OVWPa3J9ZYj26
PYHDKl1eYP4trWGGY/T2
=G5PZ
-END PGP SIGNATURE-
___
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

[Peter Todd via bitcoin-dev]

On Thu, Sep 03, 2015 at 11:18:08PM +, 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!)

ACK

-- 
'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

[Btc Drak via bitcoin-dev]

I'm rather perplexed about this proposal. What exactly is wrong with
the existing BIPs process? I mean, it seems to me anyone can publish a
BIP pretty easily in the BIPs repository. There doesnt seems to be any
real barrier to entry whatsoever. I know there have been all manner of
aspersions, but having just written two BIPs there was no friction at
all.

Whether the ecosystem adopts a BIP is another question of course, but
that's out of scope of the BIPs project anyhow. Take BIP101
controversial as it gets, but it's there. Whether Bitcoin implementers
implement it is another kettle of fish and a matter for each project
to decide. It's absolutely NOT the realm of the BIPs project itself.
Bitcoin Core does not make any consensus critical changes with a BIP.
Where one seeks to establish certain standards, say for privacy, a BIP
would be appropriate so the ecosystem can harmonise methodology across
the board.

The status of a BIP is not really determined by anyone, it's by
adoption - that's where consensus happens. There's a little legroom
around this but I'm not entirely sure what you are trying to solve.
Yes the process is loose, but is it broken? There have been a flood of
BIPs added recently with zero bureaucracy or friction.

BIP0001 is the BIP that defines the BIP process. Interestingly enough
the only BIP that might be controversial is in fact a BIP to change
the way BIPs are handled!

So I'd really prefer to start this conversation with a breakdown of
what you think is broken first before tackling what may or may not
need fixing. I would be very cautious bringing "administrative"
burdens to the process or evicting common sense from the proceedings.
Much of the debates around consensus building seem to negate the
importance of common sense and the simple fact that "it's obvious when
you see it".

I'm sure there can be improvements, but for me personally, I need to
see what is broken before I can make any judgement on a potential way
forward, and if it's not broken, we should leave it alone.


On Fri, Sep 4, 2015 at 5:40 AM, Andy Chase via bitcoin-dev
 wrote:
> 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 

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

[Luke Dashjr via bitcoin-dev]

On Friday, September 04, 2015 5:48:48 PM Justus Ranvier wrote:
> On 09/03/2015 07:06 PM, Luke Dashjr via bitcoin-dev wrote:
> > 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/
> 
> What benefit is created by delegating the BIP-43 namespace management to
> that company in particular?

Feel free to create a company-independent repository instead.
Although I don't think SLIPs are intended to be biased toward their company.

> BIP-43 as it is currently composed provides the convenient feature of
> purpose codes matching the BIP number. Moving purpose codes to a
> separate namespace add complexity to its usage for no discernible benefit.

This is not Bitcoin's problem... Polluting the BIP repository with N non-
Bitcoin related specifications would be.

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

[Andy Chase via bitcoin-dev]

Thanks for your thoughts.

My proposal isn't perfect for sure. There's likely much better ways to do
it. But to be clear what I'm trying to solve is basically this:

Who makes high-level Bitcoin decisions? Miners, client devs, merchants, or
users? Let's set up a system where everyone has a say and clear acceptance
can be reached.

---

My motivation for writing this proposal is stated right at the start:
> "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."

BIPs are considered "accepted" right now based on an undefined system,
quite honestly. Btc Drak: What's the system for accepting a BIP? Words like
"consensus" come up but they aren't defined. My goal is to define a system
that makes finding "consensus" (I like the word "acceptance" better) in a
clear and fair way.

I.e. what's broken?

* Being sure that a proposal is widely accepted or rejected
* Preventing deadlock (i.e. one person's weak objections preventing
acceptance)
* Receiving feedback from important segments like user groups,
merchants/exchanges, etc. in a systematic and clear way instead of going
and forth or having "oracles" on technical advisory boards.

> Yes the process is loose, but is it broken?

Yes/No. Work gets done with the current process. Work can get done with
this process. The goal is for this process is to be safer/clearer/better
defined way.

> There have been a flood of
> BIPs added recently with zero bureaucracy or friction.

As we move forward, we want to balance the powers in such a way that we may
want to pause a bit before we accept each proposal. 2 weeks for comments +
2 weeks for opinions will slow things down, but it shouldn't stall
meaningful work. I used 4 weeks for the process with the understanding that
most proposals are clear and easily acceptable. Controversial proposals
will likely need more time and thus will likely have be submitted at least
twice to discover a clear response.

"Accepting" a BIP means just that: It's accepted. What's acceptance mean?
This proposal provides an answer.

Client implementations, users, miners, and merchants can feel safe
implementing and using a feature that has clear acceptance. This process
isn't meant to force anything on client implementors, users, miners, or
merchants.

On Fri, Sep 4, 2015 at 12:20 PM, Btc Drak  wrote:

> I'm rather perplexed about this proposal. What exactly is wrong with
> the existing BIPs process? I mean, it seems to me anyone can publish a
> BIP pretty easily in the BIPs repository. There doesnt seems to be any
> real barrier to entry whatsoever. I know there have been all manner of
> aspersions, but having just written two BIPs there was no friction at
> all.
>
> Whether the ecosystem adopts a BIP is another question of course, but
> that's out of scope of the BIPs project anyhow. Take BIP101
> controversial as it gets, but it's there. Whether Bitcoin implementers
> implement it is another kettle of fish and a matter for each project
> to decide. It's absolutely NOT the realm of the BIPs project itself.
> Bitcoin Core does not make any consensus critical changes with a BIP.
> Where one seeks to establish certain standards, say for privacy, a BIP
> would be appropriate so the ecosystem can harmonise methodology across
> the board.
>
> The status of a BIP is not really determined by anyone, it's by
> adoption - that's where consensus happens. There's a little legroom
> around this but I'm not entirely sure what you are trying to solve.
> Yes the process is loose, but is it broken? There have been a flood of
> BIPs added recently with zero bureaucracy or friction.
>
> BIP0001 is the BIP that defines the BIP process. Interestingly enough
> the only BIP that might be controversial is in fact a BIP to change
> the way BIPs are handled!
>
> So I'd really prefer to start this conversation with a breakdown of
> what you think is broken first before tackling what may or may not
> need fixing. I would be very cautious bringing "administrative"
> burdens to the process or evicting common sense from the proceedings.
> Much of the debates around consensus building seem to negate the
> importance of common sense and the simple fact that "it's obvious when
> you see it".
>
> I'm sure there can be improvements, but for me personally, I need to
> see what is broken before I can make any judgement on a potential way
> forward, and if it's not broken, we should leave it alone.
>
>
> On Fri, Sep 4, 2015 at 5:40 AM, Andy Chase via bitcoin-dev
>  wrote:
> > 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 

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

[Peter Todd via bitcoin-dev]

On Fri, Sep 04, 2015 at 01:13:18PM -0700, Andy Chase via bitcoin-dev wrote:
> Thanks for your thoughts.
> 
> My proposal isn't perfect for sure. There's likely much better ways to do
> it. But to be clear what I'm trying to solve is basically this:
> 
> Who makes high-level Bitcoin decisions? Miners, client devs, merchants, or
> users? Let's set up a system where everyone has a say and clear acceptance
> can be reached.

It depends on a case-by-case basis.

E.g. for soft-forks miners can do what they want with little ability for
other parties to have a say. For non-consensus-related standards - e.g.
address formats - it's quite possible for a BIP to be "accepted" even if
only a small group of users use the standard. For hard-forks almost
everyone is involved, though who can stop a fork isn't as well defined.

IMO trying to "set up a system" in that kind of environment is silly,
and likely to be a bureaucratic waste of time. Let the market decide, as
has happened previously. If you're idea isn't getting acceptance, do a
better job of convincing the people who need to adopt it that it is a
good idea.

No amount of words on paper will change the fact that we can't force
people to run software they don't want to run. The entire formal part of
the BIP process is simply a convenience so we have clear, short, numbers
that we can refer to when discussing ideas and standards. The rest of
the process - e.g. what Adam Back and others have been referring to when
attempting to dissuade Hearn and Andresen - is by definition always
going to be a fuzzy, situation-specific, and generally undefined
process.

Or put another way, even if you did create your proposed process, the
first time those committees "approved" a BIP that relevant stakeholders
disagreed with, you'd find out pretty quickly that "clear acceptance" of
your 4% sample would fall apart the moment the other 96% realized what a
tiny minority was intending to do. Particularly if it was one of the
inhernet cases where the underlying math means a particular group - like
miners - has the ability to override what another group wants out of
Bitcoin.

-- 
'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

[Luke Dashjr via bitcoin-dev]

On Friday, September 04, 2015 8:13:18 PM Andy Chase via bitcoin-dev wrote:
> Who makes high-level Bitcoin decisions? Miners, client devs, merchants, or
> users? Let's set up a system where everyone has a say and clear acceptance
> can be reached.

For hardforks (removing consensus rules), economic consensus: people who 
accept payment in bitcoins weighted by their actual volume of such payments. 
A supermajority subset may arguably be sufficient for some hardforks (which 
don't violate Bitcoin's social contract) since they can effectively compel 
the remaining economy to comply.

For softforks (adding consensus rules), a majority of miners: they can "51% 
attack" miners who don't go along with it.

Anything else does not necessarily need universal agreement, so are 
completely up to the whim of individual software projects. If someone doesn't 
like a decision in Core (for example), they can safely fork the code. If any 
significant amount of people use their fork, then the BIP is accepted whether 
or not Core later adopts it.

Note this "system" is really describing a lack of a system - that is, what 
naturally must happen for changes to occur. Softforks have a relatively 
mature technical method for measuring support and deploying (which I believe 
someone else is already working on a BIP describing), but the same thing is 
impractical for hardforks. Some formal way to measure actual economic 
acceptance seems like a good idea to study, but it needs to be reasonably 
accurate so as to not change the outcome from its natural/necessary result.

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

[Andy Chase via bitcoin-dev]

I understand your concerns. What kinds of changes do you think should go
through a process like this? Just hard forks?

I was thinking that an advantage of making all BIPs use this process is
that it makes it familiar and well used. Kinda like a muscle grows stronger
with use. If only hard forks go through the process then there's the risk
that the process has to be spun up whenever they happen which might cause
confusion.

Another reason I was thinking is that even small, local changes, it doesn't
hurt to have a few more people take a look at it and approve it.

The bureaucracy only applies to BIPs, not PRs. There's only been 18
approved/final/accepted BIPs in 4 years since BIP-0001. That's only about
~5 per year. I get that bureaucracy is often a waste of time, but I just
don't think every second counts for these things.

On Fri, Sep 4, 2015 at 2:01 PM, Luke Dashjr  wrote:

> On Friday, September 04, 2015 8:13:18 PM Andy Chase via bitcoin-dev wrote:
> > Who makes high-level Bitcoin decisions? Miners, client devs, merchants,
> or
> > users? Let's set up a system where everyone has a say and clear
> acceptance
> > can be reached.
>
> For hardforks (removing consensus rules), economic consensus: people who
> accept payment in bitcoins weighted by their actual volume of such
> payments.
> A supermajority subset may arguably be sufficient for some hardforks (which
> don't violate Bitcoin's social contract) since they can effectively compel
> the remaining economy to comply.
>
> For softforks (adding consensus rules), a majority of miners: they can "51%
> attack" miners who don't go along with it.
>
> Anything else does not necessarily need universal agreement, so are
> completely up to the whim of individual software projects. If someone
> doesn't
> like a decision in Core (for example), they can safely fork the code. If
> any
> significant amount of people use their fork, then the BIP is accepted
> whether
> or not Core later adopts it.
>
> Note this "system" is really describing a lack of a system - that is, what
> naturally must happen for changes to occur. Softforks have a relatively
> mature technical method for measuring support and deploying (which I
> believe
> someone else is already working on a BIP describing), but the same thing is
> impractical for hardforks. Some formal way to measure actual economic
> acceptance seems like a good idea to study, but it needs to be reasonably
> accurate so as to not change the outcome from its natural/necessary result.
>
> Luke
>
___
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

[Justus Ranvier via bitcoin-dev]

On 09/03/2015 07:06 PM, Luke Dashjr via bitcoin-dev wrote:
> 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/

What benefit is created by delegating the BIP-43 namespace management to
that company in particular?

BIP-43 as it is currently composed provides the convenient feature of
purpose codes matching the BIP number. Moving purpose codes to a
separate namespace add complexity to its usage for no discernible benefit.

-- 
Justus Ranvier
Open Bitcoin Privacy Project
http://www.openbitcoinprivacyproject.org/
jus...@openbitcoinprivacyproject.org
E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623


0xEAD9E623.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP 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

[Luke Dashjr via bitcoin-dev]

On Friday, September 04, 2015 9:36:42 PM Andy Chase wrote:
> I understand your concerns. What kinds of changes do you think should go
> through a process like this? Just hard forks?

The process loses meaning if it doesn't reflect reality. So only hardforks 
should go through the hardfork process; only softforks through the softfork 
process; etc. Trying to make one-size-fits-all just means de facto accepted 
BIPs wouldn't be recognised as such because nobody cares to meet the higher 
requirements.

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

Re: [bitcoin-dev] BIP 100 specification

[Andy Chase via bitcoin-dev]

The 32Mb limit is here:
https://github.com/bitcoin/bitcoin/blob/master/src/serialize.h#L25

It's to keep the message size small enough that messages can be serialized
in memory.

Jeff if you decide to lift the 32MB limit (you really should, unless your
plan is to potentially hard force another Blocksize discussion again which
might be okay). I suggest having the 32MB ceiling auto-raise according to a
exponential factor (1.5?) starting 1 year from now.

Basically hard limit ceiling 2016-2017: 32 MB
Hard limit ceiling 2018+: 32*((currentYear-2018)*1.5) MB

The factor could be 2 like BIP-101 but I imagine you will want to be more
conservative. The delay time could also be longer if you think it will take
longer to fix the message size issue across all implementations.


On Thu, Sep 3, 2015 at 4:59 AM, Tier Nolan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> 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
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev