Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
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/Draft] BIP Acceptance Process
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] [BIP/Draft] BIP Acceptance Process
IMO trying to "set up a system" in that kind of environment is silly, The first step is to define the system that is currently in place. There is a system in place but it is just close to the vest and sometimes not discussed in public. This works when Bitcoin has a small number of stakeholder but does not work well as other parties with diverse interests get involved. You can't expect major players to invest large sums when the process is controlled by a tiny group of people where some of those people have rather unusual opinions about things and limited experience outside of technical areas within Bitcoin. You just don't have enough experience in working on large projects to understand the benefits of the proposal discussed. I suggest you look into into and get some experience instead of posting rants that highlight your inexperience. What is silly is using a process that involves hyperbolic twitter and reddit posts. Basically such a process does not replace the analysis that is done now, it just makes it transparent and attempts to make it consistent so there is not all this confusion over comparing apples and oranges. Here is link that discusses some of the benefits and limitations of doing this: http://www.jakeman.com.au/media/whats-right-with-risk-matrices. Russ ___ 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
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
>> Let the market decide How about Futarchy? On Fri, Sep 4, 2015 at 8:31 PM, Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 > > ___ > 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/Draft] BIP Acceptance Process
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
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 information > > sharing). Therefore, I designed it around the assump
Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
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 motivated people will contribute. Motivated pe
Re: [bitcoin-dev] Proposed minor change to BIP 01 to use a PR for request assignment
I think it's a reasonable approach. Once the number is assigned, the change is made and the pull request is updated. Only thing is it would be nice to be able to indicate which pull requests are number requests and which pull requests are ready for merging. Perhaps we should make a special label for number requests. - Eric -- Original Message -- From: "Gregory Maxwell via bitcoin-dev" To: "Bitcoin Dev" Sent: 9/3/2015 4:18:08 PM Subject: [bitcoin-dev] Proposed minor change to BIP 01 to use a PR for request assignment 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
Re: [bitcoin-dev] RFC: HD Bitmessage address derivation based on BIP-43
On 09/04/2015 01:21 PM, Luke Dashjr wrote: > This is not Bitcoin's problem... Polluting the BIP repository with N non- > Bitcoin related specifications would be. HD generation of keypairs from a single seed for many non-conflicting uses is a valuable and useful technique. Intentionally making a useful technology less useful because assigning non-colliding numbers is too hard is a strange approach to software engineering. -- 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] RFC: HD Bitmessage address derivation based on BIP-43
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] RFC: HD Bitmessage address derivation based on BIP-43
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] Proposed minor change to BIP 01 to use a PR for request assignment
-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] BIP 100 specification
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
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
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] AT&T/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
On Fri, Sep 4, 2015 at 11:55 AM, Zach G via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > It's not so simple though, AT&T will not let you have a public static IP > without paying. Not sure, but, what part of bitcoin development are you addressing in this email? -- buZz ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] AT&T/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
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&T 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&T 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&T will not let you have a public static IP without paying. I've had my router reset 10 times today by AT&T (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&T in the ENTIRE world. AT&T is a massive ISP so this is strong evidence that using Bitcoin Core as a full node on AT&T 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&T does, but at least Comcast has 400 nodes. AT&T 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&T 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&T 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&T, 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
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