< Murch> In order to protect ourselves from reorgs, wouldn't we want to enforce BIP91 starting with BIP91 activation?
< lejitz> There seems to be a bit of a false dichotomy in that any mandate to start signaling bit 1 in Core must begin on either the BIP91 block height, or the BIP148 activation time. BIP91 feels rushed, while BIP148 leaves time for potential shenanigans or accidents. If more time is needed than BIP91 allows, why not just start enforcing bit 1 as soon as you can (even before Aug. 1 or after BIP91)?
< BlueMatt> sipa: i belive the suggestion was to enable it on the now-locked bip91 activation block
< luke-jr> (note this would also help avoid the propagation/partitioning risk BIP91 currently has)
< luke-jr> would anyone object to an emergency 0.14.3 with BIP148 modified to activate at the same height as BIP91? the downside is that there's only 1-2 days for people to upgrade to it, so we'd need to forego RCs (although most of the code has been tested in the UASF repo) and probably release today or tomorrow..


< sipa> bip9 specifies that there should
< kanzure> should there be a reorgs warning about bip91 and possible partial activation
< cfields> instagibbs: whew, good thing we don't have to talk about a UASF to activate BIP91 :p


< jonasschnelli> But thats far in future (net refactor, Bip151, Bip150 and maybe then).
< jonasschnelli> eck: look at the overview. Bip62 is "Withdrawn"
< eck> I am trying to understand the BIP process, and I'm confused how I can tell which BIPs were actually deployed
< bitcoin-git> [bitcoin] achow101 opened pull request #10875: BIP 91 deployment parameters (master...bip91-dep-params) https://github.com/bitcoin/bitcoin/pull/10875
< bitcoin-git> [bitcoin] achow101 opened pull request #10874: [RPC] getblockchaininfo: Loop through the bip9 soft fork deployments instead of hard coding (master...getblockchaininfo-bip9-loop) https://github.com/bitcoin/bitcoin/pull/10874


< jtimon> jonasschnelli: I'm having problems explaining my suggestion in https://github.com/bitcoin/bips/pull/555
< Guest38971> Understood my question was hypethical. My main concern is if I am running my node how can I test BIP148 suppost. I found a link that allows me to download bitcoin core with BIP148 support, but I did not know if this was trustworthy. Thank you
< sipa> Bitcoin Core at this point does not support BIP148
< Guest38971> lets say I wanted my node to support bip148. What do I need to configure in order to allow this? I am currently running bitcoin core 0.14.2 am I just ammending a line of code into the config file? I just need a reference if possible or is it advised to just wait for a release from bitcoin core?. I do not know if this is the proper channel for this so I apologize in advance. Thank you very much for the help.


< luke-jr> BIP148, but I assume if the hold-outs on that had changed their mind, they'd say so :/ so probably nothing to do / discuss there


< instagibbs> Murch, there are none right now AFAIK. BIP49 I think is the only proposed one for Mycelium or something


< jtimon> I guess that further disproves the argument that "people that will support uasf already know about bip148 already know about it and already 'upgraded', waiting for bip149 won't result in more people or businesses on board"
< rhavar> (which imo was reckless and alarmist. If they did enough mental gymnastics to convince themselves that bip148 would split the chain, they should have at least waited to be sure that segwit2x isn't going to activate in time)
< gmaxwell> Lets only allow the characters BIP14 specifically mentions. :P
< gmaxwell> BIP14 seems to also allow \n nul and so on
< luke-jr> jonasschnelli: 2017-07-13 07:37:02 receive version message: /Satoshi:0.14.2(BIP148)/Knots:20170618/: version 70015…
< luke-jr> jonasschnelli: Core logs this regardless of whether it's !BIP148= or +BIP148 or !BIP148
< jonasschnelli> luke-jr: Your description: "Current Core strips out the !, + and = characters used by Knots to indicate whether BIP148 enforcement is enabled."


< luke-jr> if there is a 51% attack in response to BIP148, I think it's perfectly fair to not include nodes that are vulnerable to following it
< jonasschnelli> well,... until the chain split (and if), BIP148 and non BIP148 are functioning perfectly fine? not?
< cdecker> I've been asked what my DNS seed policies are regarding BIP148, and I said that I will not filter non-UASF nodes


< rodarmor> How will a current bitcoin core node interpret a block with a transaction whose version is greater than CURRENT_VERSION? I can see in the code that it's used for relay policy, and for BIP68 enforcement, is that it?


< bitcoin-git> [bitcoin] shaolinfry opened pull request #10772: Implementation of BIP8 (master...bip8-height) https://github.com/bitcoin/bitcoin/pull/10772


< instagibbs> morcos, can you give me an example of problematic behavior which doesnt just boil down to "don't do unconfirmed chaining on top of bip125 transaction"?


< gmaxwell> perhaps an input to the BIP151 stuff... that it should be possible to run it in a mode that turns off the auth for use over a domain socket at least.


< bitcoin-git> [bitcoin] sdaftuar opened pull request #10695: [qa] Rewrite BIP65 functional tests (master...2017-06-fix-bip65-test) https://github.com/bitcoin/bitcoin/pull/10695


< sipa> (peers can ask for a node's mempool using the bip35 'mempool' command, but it's never broadcast unadvertized)


< bitcoin-git> [bitcoin] jtimon closed pull request #10462: Consensus: Modified BIP8 implementation (master...b15-bip8-min) https://github.com/bitcoin/bitcoin/pull/10462


< sdaftuar> i believe i wrote a test like this in p2p-segwit (before we supported modifying bip9 parameters on the command line)


< Lightsword> so how exactly do you do BIP34 single byte encodings?
< phantomcircuit> try changing regtest to requite bip34 at height 2
< luke-jr> although I guess BIP34 was never enforced at those heights for mainnet
< sipa> using OP_n for the height in BIP34
< Lightsword> for testnets which immediately enforce BIP34


< Lightsword> what’s the function that serializes BIP34 height in core?


< jonasschnelli> I guess I took BIP44 for a start.. but it's a single const
< jonasschnelli> People want to use BIP44
< jnewbery> bip65-cltv-p2p.py bip68-112-113-p2p.py bip9-softforks.py bipdersig-p2p.py invalidblockrequest.py invalidtxrequest.py p2p-fullblocktest.py


< sipa> only works for bip125 transactions


< jtimon> yeah I assumed that was clear. I'm unconvinced a variation of bip149 cannot be merged before mov15 though, so maybe it could make it to 0.14.3
< jtimon> oh, I see, luke wants bip148 for 14.2 ?
< sipa> luke-jr: i don't "want" BIP148. I want segwit, as I think it's necessary for Bitcoin's future. BIP148 is a overly risky means of obtaining that. That does not mean I oppose it if there were tremendous support, but on itself I think it's a bad idea
< luke-jr> [10:58:08] <timothy> the UASF commits, since luke-jr is working on DoS stuff <-- for now, it may be safer to omit some of the DoS stuff; that's additional on top of BIP148 (not necessary), and has less review so far
< luke-jr> wumpus: BIP148 is a softfork. We typically consider those bugfixes and only added on minor bumps..
< wumpus> I'm sure there will be a bip148 variant of -final
< wumpus> there's no agreement to add bip148 support to core at all, and adding a major feature like that between rcs doesn't happen
< timothy> hi, do you think -bip148 option will be included in 0.14.2 final?


< bitcoin-git> [bitcoin] laanwj closed pull request #10463: Names: BIP9 vs versionbits (master...b15-bip8-cherry-reanme) https://github.com/bitcoin/bitcoin/pull/10463
< bitcoin-git> bitcoin/master 29c0719 shaolinfry: Rename -bip9params to -vbparams
< bitcoin-git> bitcoin/master b463bc9 Jorge Timón: scripted-diff: s/BIP9DeploymentInfo/VBDeploymentInfo/...
< bitcoin-git> bitcoin/master 323a46e Wladimir J. van der Laan: Merge #10463: Names: BIP9 vs versionbits...
< luke-jr> da2ce7_: I disagree that softforks can be the *cause* of a schism fork. In the case of BIP148, for example, the split is caused by miners violating the protocol rules. This is really no different than a split when the rule isn't newly added.


< gribble> https://github.com/bitcoin/bitcoin/issues/10463 | Names: BIP9 vs versionbits by jtimon · Pull Request #10463 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] earonesty opened pull request #10532: -bip148 option (master...bip148) https://github.com/bitcoin/bitcoin/pull/10532


< luke-jr> (and not required for BIP148)
< luke-jr> aj: it now has bugfixes applicable to softforks in general, not specific to BIP148
< aj> luke-jr: wow, your bip148 branch got complicated
< luke-jr> aside from BIP148, it would be helpful to get positions on the other proposals on the page
< luke-jr> okay, I've updated the wiki page with two new categories Deficient and Wanting, and reclassified BIP148 for Matt as Deficient and sipa as Wanting; hope this is accurate
< sipa> if there were pervasive support for BIp148, i would encourage it
< luke-jr> sipa: are you of a position that BIP148 should not be merged, but you don't oppose it personally?
< sipa> luke-jr: also don't equate "against merging support for BIP148 in core" with "against BIP148"
< luke-jr> BlueMatt: not doing BIP148 is objectively riskier than BIP148 itself, which has no risk at all given sufficient support.
< luke-jr> there is no comparison. Classic/XT were hardfork proposals with serious technical problems and done by trolls who wanted to "fire Core". BIP148 is a softfork proposal with no real technical problems, and widespread community support.
< luke-jr> BlueMatt: people against BIP148 on their own are a very small group


< jonasschnelli> spudowiar: for HWW support, Core needs flexible keypath (BIP44) with support for pub-key-derivation (currently only hardened derivation is supported), there is a PR from NicolasDorier (check it out).


< luke-jr> instagibbs: it was an observation on the current BIP148 PR that I'm investigating; but it applies to any softfork
< gmaxwell> BIP148 is a softfork but it creates a hardfork, its the hardfork that creates that partitioning issue.
< luke-jr> this is nothing specific to BIP148
< gmaxwell> One of the totally braindamaged element of BIP148 is that it does nothing to make the network of BIP148 users connected and it sounds like you'd like to make that even worse?


< warren> He wants conceptual feedback on BIP154 now.
< warren> I ask now because of BIP154 which does have a reference implementation for current bitcoin.
< warren> jonasschnelli: btw, what is the status of BIP150 and BIP151 for core? do folks want to wait for the network rewrite?


< jtimon> gmaxwell: updated https://github.com/bitcoin/bitcoin/pull/10462 with my proposed modifications to bip8, the first commit implements the original specification. I hope people like the changes
< bitcoin-git> [bitcoin] jtimon opened pull request #10463: Names: BIP9 vs versionbits (master...b15-bip8-cherry-reanme) https://github.com/bitcoin/bitcoin/pull/10463


< bitcoin-git> [bitcoin] jtimon opened pull request #10462: BIP8 implementation (master...b15-bip8-min) https://github.com/bitcoin/bitcoin/pull/10462
< bitcoin-git> [bitcoin] earonesty reopened pull request #10442: add a -bip148 option (master...master) https://github.com/bitcoin/bitcoin/pull/10442


< da2ce7> I'm going to try and refine this assumption with more evidence. With 33% mining support, I think that doing BIP148 is remarkably safe in the face of an active exploit.
< da2ce7> sipa, do you think that my assumption that the miners who signal for SegWit now are likely doing it because they want the partial-fix to AsicBoost Deployed? If so, would they reasonably support a BIP148 soft-fork?
< sipa> da2ce7: totally agree, i just don't think bip148 is a good or likely succesful way of doing that
< sipa> and i think bip148 is both high risk, and with very unclear support
< Chris_Stewart_5> sipa: Would worst case be similar to what happened a few years back with BIP66 (or 62)?
< da2ce7> So I mean BIP148, activating SegWit.
< Chris_Stewart_5> da2ce7: Are you talking about generically using the deployment mechanism specified in BIP148, or BIP148 itself? BIP148 only pertains to segwit IIRC
< jtimon> sipa: let's say (as an example, not an actual proposal) the asicboost fix is included in 14.3 with bip8, minimum activation by miners august, final activation dec 2017, would you say that is conservative enough?
< da2ce7> For me, BIP148 is a reasonable for an emergency soft-fork. Are we fixing an emergency security vulnerability? The more I study CVE-2017-9230, the more I'm inclined to say Yes.
< jtimon> Chris_Stewart_5: I'm all for adding a bip8 deployment for the covert asicboost fix, and its final activation can be earlier than nov 2017 I think
< sipa> and it's not just a proposal... there is software out there that implements bip148
< sipa> Chris_Stewart_5: my problem with bip148 is its deployment, not its rule changes
< Chris_Stewart_5> sipa: Would you support BIP148 that *only* solves covert ASICBOOST? No segwit stuff involved
< sipa> da2ce7: my personal opinion is that bip148 is reckless even if it succeeds...
< jtimon> I think we could deploy the proposed fix to covert asicboost with bip8 pretty fast, but maybe still not august
< da2ce7> Well, at least say: "No you are stupid! The risk of another 6 to 9 mth of Covert ASICBOOST are far-less than the risks of being seen to support BIP148".
< jtimon> oh, I didn't read this part in the bip: "This deployment is incompatible with the BIP9-segwit deployment and should not be run concurrently with it.", but I really don't understand why, please, help undesrtanding very welcomed
< da2ce7> At this hash-rate the changes of BIP148 failing are very small.
< da2ce7> It is my view that the miners who don't use covert asicboost have a very strong incentive to support the swiftest deployment of any mitigation of CVE-2017-9230, including BIP148. Hence, I expect the mining power for BIP148 to be similar to the mining power that signals for SegWit now.
< da2ce7> My personal view is that the risks involved in BIP148 (a partial fix) are less than the risks covert CVE-2017-9230 continuing for a minimum of another 6mth. So I have decided to run BIP148 on my nodes.
< da2ce7> If I disagreed with BIP148, I would checkpoint so my transactions wound't face the wipeout risk. The same if for example if BIP148 as replaced with "evil softfork".
< jtimon> that's what I said, if it gets the hashrate majority non-bip148 nodes will follow their chain, no problem
< da2ce7> Because if at any date in the future the BIP148 chain overtakes, the non-BIP148 chain will be wiped out.
< da2ce7> jtimon, what happens if it has 10%. Then all non-BIP148 nodes are zombie until they checkpoint.
< jtimon> if bip148 gets the hashrate majority we don't need to do anything
< da2ce7> That would force all the non-bip148 nodes to checkpoint for continued safe operation.
< da2ce7> On a slightly related topic, what contingency planning is there for the case that BIP148 has a non-zero hash-power?
< jtimon> well, if "a LOT of users" supported my like-bip148-but-next-week proposal
< jtimon> if I proposed something like bip148 but actiavting next week instead of august, would you ack that if some users support it?
< luke-jr> and BIP149 is NOT safer anyway.
< kanzure> luke-jr: i said "something like bip148"
< luke-jr> morcos: the ONLY way to avoid the split is to make sure BIP148 succeeds. It WILL happen. Nobody can change that.
< luke-jr> kanzure: I couldn't change BIP148 if I tried.
< morcos> luke-jr: you could help, if you wanted to avoid a split, by making the argument that at this point BIP148 doesn't HAVE to happen. Since you are such an advocate for 148, maybe others would take some advice from you if you felt another path safer
< kanzure> luke-jr: have you considered something like bip148 except with best chain tip selection weighted by segwit-signalling? instead of blanket rjeection of all blocks, you'd get competing long reorgs, which is arguably better than rejecting all blocks.
< morcos> luke-jr: sdfkjs23: Lets be clear, the resistance here isn't against UASF, or even a UASF for segwit. It's against the particular activation methodology and schedule for BIP148. It would behoove us all to try to build support from current BIP148 activists for 149 or another more cautious path
< jtimon> like bip109 was
< sipa> luke-jr: my expectation is that bip148 will not have any effect, but i hope i'm wrong
< luke-jr> petertodd: and BIP148 does, so long as people enforce it
< sdfkjs23> bip148 was brought up as the topic -- it appears the current argument against it (it is hard to follow because this changes very rapidly) is that there isn't enough 'community' support even though no one can argee on how to even measure it
< luke-jr> morcos: preference isn't the question, though. BIP148 is happening, so the question is how many will support and go along with it
< petertodd> morcos: indeed, I prefer bip149
< sipa> if it's clear that BIP148 is accepted by the ecosystem, then obviously it will be implemented
< morcos> luke-jr: I think a lot of people support the concept of a UASF, but I actually made it a point to ask people wearing UASF hats what that meant to them.. And many actively preferred BIP149 or something else to BIP148
< morcos> luke-jr: even you think only 10% of nodes are running bip148 right?
< paveljanik> luke-jr, yes. I also do not think where people get "large support" in the community for BIP148 etc.
< kanzure> gmaxwell: i think luke-jr is arguing that there is support for bip148 if default-off bip148 is merged. but only on condition of that sort of endorsement from core. seems like a chicken-egg scenario, so perhaps caution is warranted.
< luke-jr> gmaxwell: the split is LESS likely by merging BIP148; it isn't a hardfork
< jtimon> luke-jr: sdfkjs23 not merging bip148 is not taking a position against segwit or uasf, it's just being conservative
< sipa> met for BIP148
< luke-jr> gmaxwell: we don't all believe that in this case. some of us admit that it's riskier to NOT enforce BIP148
< kanzure> luke-jr: they want default-off merged and that's what will get them interested in bip148?
< jtimon> gmaxwell: the changes are just for providing warnngs in unkown deployments, like bip9 did
< gmaxwell> jtimon: I don't think we should change BIP8 generally: the reason we can do a shorter termination with SW is because we've already done one deployment-- so we know what the uptake looks like and how fast it went the first time.
< sdfkjs23> deciding what choices users do or do not get seems overly political to me, if core developers want to make a political statement that's fine, but pretending to be neutral and not allowing an optional switch for bip148 seems disingenuous
< kanzure> what was the default in the bip148 paramflag pull request?
< jtimon> alright, sent suggestions to change bip8 to the mailing list...
< luke-jr> sipa: Bitfury has already agreed to enforce BIP148 if the bit-4 thing doesn't activate Segwit by August
< morcos> luke-jr: I would hope that BIP148 and BIP149 supporters are able to agree at least that they should all support the same thing.
< sipa> luke-jr: i hope you're right, but my expectation is that every economically relevant full node will revert away from bip148 code hours after the hashrate fails to adopts it
< petertodd> luke-jr: while technically the result of bip148 may be a reorg, in practice if there is a non-trivial split the result will be two currencies, as someone will launch a currency based on a checkpoint
< morcos> luke-jr: no one even knows what bit 4 SW is? we might like it, what if its compatible with BIP141 segwit... lets not make decisions based on a single line in a medium post.
< luke-jr> in the meantime, a sizable portion of the community will be enforcing BIP148, and with success eventually replacing the non-compliant chain
< sipa> gmaxwell: i don't think it's obvious that BIP149 will happen at all
< morcos> And to be clear, I think we'd all like to activate segwit via UASF before we could do so with BIP149 (and it would be feasible I think to build support in a shorter time frame), but we just don't have the technical bandwidth to code that up safely in time.
< gmaxwell> E.g. someone managed to convince them that the project would never adopt something like BIP149.
< luke-jr> sipa: BIP148 only needs about 25% hashrate to be successful
< gmaxwell> My discussions on reddit with people promoting BIP148 seemed to be because they earniestly believed it was the only choice.
< jtimon> we can merge bip8 without merging bip149 yet, although the sooner it is released the more secure it will be
< jtimon> as said on the mailing list I think bip148 is rushed and that makes it risky, bip8 on the other hand...(although I'm writing suggestions for changing bip8)
< wumpus> let's merge BIP149 instead
< sipa> my opinion is that it would go against our principles to merge BIP148 into core
< wumpus> #topic BIP148
< luke-jr> BIP148
< bitcoin-git> [bitcoin] earonesty closed pull request #10442: add a -bip148 option (master...master) https://github.com/bitcoin/bitcoin/pull/10442


< wumpus> Gavin's tweet (combined with BIP148) seems to have the complete opposite effect of what he probably imagined.
< luke-jr> on the bright side, BIP148 is up to 10% of listening nodes
< murchandamus> gmaxwell: heh. Indeed. — Although I just realized. within six months would end just after the BIP9 timeout of segwit, perhaps they suggest to activate it right then?
< gmaxwell> Only the BIP9 part isn't triggered... so to redeploy segwit we have to also replace all those other parts, not just the bip9 bit.
< gmaxwell> Which is a simple search and replace, but only if the BIP9 activation has reached its limit... otherwise we have the potential that it might activate under either.
< gmaxwell> Segwit has the bip9 activiation, and a network service type which is used to make sure the graph of segwit capable nodes is not partitioned, and new p2p messages for transfering messages (tx, blocks, compact blocks) with witnesses if they have them.


< bitcoin-git> [bitcoin] jameshilliard opened pull request #10444: Implement BIP91 Reduced threshold Segwit MASF (0.14...segsignal-v0.14.1) https://github.com/bitcoin/bitcoin/pull/10444
< bitcoin-git> bitcoin/master 557c9a6 Matthew Zipkin: RPC: getblockchaininfo: BIP9 stats...
< jtimon> if the bip9 activation gets in, great, if not, that won't happen for pre-bip149 nodes, what am I missing?
< jtimon> "Very little research has been done into the work required to successfully and safely re-deploy segwit. " we knew bip9 deployments could be tried again if failed, I don't know what kind of research you want
< luke-jr> yes, in general; but segwit is more complicated than merely another bip9 deployment
< jtimon> pre-bip149 won't think segwit is activated
< jtimon> "there are plenty of "sharp edges" that could be encountered if we need to do it for segwit" what are those "sharp edges"? how don't they apply with the current bip9 deployment with respect to pre-sw nodes?
< luke-jr> jtimon: with a BIP148-style *UASF*, you don't find out the outcome until a miner tries to steal segwit funds
< jtimon> luke-jr: it can be made earlier by miners, that's true for bip148 as well
< jtimon> "BIP 148 is backward-compatible with segwit as already deployed in 0.13.1-0.14.1." so is bip149, bip149 is actually compatbile with pre-0.13 too
< Lauda> BIP148 is much better due to compatibility, indeed.
< da2ce7> wumpus, I agree: BIP148 may be, even then, too rushed (but I personally believe BIP148 is the safest option available, as I think there is a dramatic under estimation the damage of asicboost to Bitcoin). However, I haven't seen this considered in any of the significant anti-BIP148 responses to the mailing list. Centrally not an analysis of the tradeoffs available.
< wumpus> it can still be too rushed, even if it addresses an immediate vulnerability; it depends on what outcome is worse, having stealth asicboost run for a few months longer (while BIP149 is being deployed) or a game of BIP148 chicken (which seems unavoidable in any case...).
< da2ce7> I have gained no negative responses to my post on the mailing list about classifying asicboost as a Security Vulnerability. Yet BIP148, a rapidly deployed partial-fix is rejected by many for being 'too rushed'. I would suggest that any developers who states why it is 'too rushed' should state how the ongoing exploit of covert asicboost is the safer option.
< da2ce7> Many developers have stated that they think that BIP148 is rushed, but remain silent on the fact that Bitcoin is under active exploit.
< da2ce7> Is the fact that Bitcoin is under active exploit by the asicboost vulnerably a important consideration for the urgency of BIP148?
< jonasschnelli> I guess a confusing element is that a tx can pass IsFinalTx() (in therefore has the term "final") even if it can be replaced by opt-in-RBF/BIP125


< bitcoin-git> [bitcoin] earonesty closed pull request #10428: -bip148 option (0.14...0.14) https://github.com/bitcoin/bitcoin/pull/10428
< bitcoin-git> [bitcoin] earonesty opened pull request #10442: add a -bip148 option (master...master) https://github.com/bitcoin/bitcoin/pull/10442


< bitcoin-git> [bitcoin] earonesty reopened pull request #10428: -bip148 option (0.14...0.14) https://github.com/bitcoin/bitcoin/pull/10428
< bitcoin-git> [bitcoin] earonesty closed pull request #10428: -bip148 option (0.14...0.14) https://github.com/bitcoin/bitcoin/pull/10428
< bitcoin-git> [bitcoin] sanch0panza opened pull request #10437: Implement BIP135 (generalized versionbits) (master...bip135-core-dev-clean1) https://github.com/bitcoin/bitcoin/pull/10437
< luke-jr> https://github.com/bitcoin/bitcoin/compare/0.12…luke-jr:0.12.1+bip148 for a github diff..
< luke-jr> can anyone review my 0.12 backport of BIP148? http://codepad.org/eo2wPI8T


< bitcoin-git> [bitcoin] earonesty opened pull request #10428: -bip148 option (0.14...0.14) https://github.com/bitcoin/bitcoin/pull/10428


< jtimon> so I don't think I will run bip148 myself
< luke-jr> jtimon: well, it's already happening Aug 1 with BIP148..
< jtimon> luke-jr: aug2017 seems to soon to me, I have no problems with bip149 on the other hand
< kanzure> sounds like bip148 discussion is slightly blocked by luke-jr parental units
< luke-jr> defer BIP148 to next week?
< gmaxwell> sipa: the privacy leak from correlated data still exists in map proposals, based on what blocks you choose to scan further, though much less severe than BIP37. Keep that in mind.
< sipa> in BIP37 there was a reason to separate it, as it would be less bandwidth if you wanted a specific coutpoint, despite there being many scriptPubKeys with it
< sipa> roasbeef: yes, the reason it's in BIP37 is for bare multisig support... but i don't think that's very interesting now
< gmaxwell> jonasschnelli: the things BIP37 added largely turned out to be a mistake that really degraded BIP37 so I hope a new proposal would do less.
< gmaxwell> Usuabilty of SPV clients that scan using BIP37 is really poor though, thus the rise of electrum.
< jonasschnelli> Can we start with adding the same elements that bip37 does?
< gmaxwell> roasbeef: that was already possible with BIP37 and the prior design.
< gmaxwell> aside, I'm glad to hear this discussion has moved past just replicating the BIP37 mechenism.
< sipa> more so than bip37
< gmaxwell> what BIP37 does is very cpu expensive for the serving party, which is why it leads to dos attacks.
< luke-jr> BIP148
< BartokIT> The BIP32 allow to audit sharing the master public key
< BartokIT> I want a clarification about the BIP32, is this the correct group
< bitcoin-git> [bitcoin] laanwj closed pull request #10417: BIP 148 support (master...master-BIP148) https://github.com/bitcoin/bitcoin/pull/10417


< Anduck> could be that you're right. could be that you're not. i think hype for bip148 is largely hype only.
< Anduck> "If all core members would support BIP148, we could do it really easily" << i disagree.
< lichtamberg_> I mean.. I also have to say following… If all core members would support BIP148, we could do it really easily.. and I think everyone knows this… But: since you are scared about the core brand, you are too risk averse from my point of view and just try to hide away from it… you are really shitting your pants right now.. sorry… :)
< luke-jr> Anduck: nope, Core's current anti-BIP148 position increases the disruption
< luke-jr> Anduck: in this case, it's not "no comment", it's actively anti-BIP148.
< Anduck> e.g. core-currentrules would have masf support for segwit. core-experimentals could try to bend miners arms to do the masf, bip148-way, which could horribly fail too.
< lichtamberg_> I dont know.. in only think, that if we put it on a general level, it will take much longer than the PR for BIP148 makes sense (because 1th august will be earlier than this decision)
< Anduck> well, let's forget bip148 for a while. the big question here is what role is core having. will core only support current rules and e.g. updates via masf, or will it offer riskier (hf, bip148-like uasf) options? where's the golden line between these?
< lichtamberg_> And you are also removing the possibility to switch to the correct chain, if BIP148 really gets much traction at the end. With the toggle option, people can switch more or less easily.. without => you are forcing the users to unofficial versions.. most people dont compile bitcoin themself
< Anduck> anyway, even while bip148 may be stupidly risky, there's no point in trying to slow it down. it happens if it happens. running bitcoin node will increasingly require more knowledge of what actual rules does the code follow. there's no point in trying to oppose this from realising
< Anduck> having the option under core name simply helps people to trust the code / idea behind it to be valid. then the only thing for those people (who trust core) is to evaluate the risk of bip148 and whether they want to support it. still a big portion will not understand the risks sufficiently do choose anything
< Anduck> i think having core-supported possibility to simply switch on bip148 (with all the warnings etc) would really give users the choice. it's a fact a ton of people will never run anything not from core project. passive users would simply not switch on it, but could easily do if they wanted to. they wouldn't understand the implications though, but that's never the point
< gmaxwell> luke-jr: no one has to run BIP148.
< gmaxwell> it's perhaps an argument that the BIP9 timeout default should be more like 2 or three years.
< luke-jr> gmaxwell: I don't see a reason in this, to make BIP148 fail and split the chain.
< gmaxwell> luke-jr: because we assumed we could just keep renewing it. 1 year is what BIP9 suggest and seems like a generally reasonable quanta.
< gmaxwell> But the whole reason for BIP148 is because some people are not happy with how long segwit is taking to activate. I believe that the expectations there are unrealistic.
< gmaxwell> yea, BIP148 is very simple, I agree.
< luke-jr> BIP148 is about segwit, but BIP148 itself is very simple
< gmaxwell> luke-jr: sure but BIP148 is about segwit.
< luke-jr> AFAICT that analogy is about segwit, not BIP148
< luke-jr> morcos: BIP148 is 2 months old, and IMO better than any hypothetical alternative; anything else will require a redeployment
< morcos> BIP148 is essentially hot off the press, and we're already trying to merge it
< gmaxwell> if it's (say) 5% then it's just bad for the BIP148 users.
< gmaxwell> like if BIP148 is (say) 99% everyone is happy, even people that didn't use BIP148. If BIP148 is 0% everyone is safe (if not happy). if BIP148 is 50% then the network is split and is a mess for BIP148 and non-148 users a like.
< gmaxwell> sdf_0010: part of the problem is that a partial adoption of BIP148 isn't just bad for the people who turned the option on, it's bad for everyone.
< Anduck> BlueMatt: bip148 version "flavor" could be handed by core anyway. just with proper warnings everywhere, and good reasoning why core is making it
< sdf_0010> what is the reason for core not including BIP148 or similar as a switch defaulting to off?
< gmaxwell> I've heard directly from people trying to push for BIP148 that they
< gmaxwell> point out that the ONLY argument against BIP148 given what we know
< gmaxwell> needs software. We could ship BIP148 switchable and defaulted to
< gmaxwell> they're not known and trusted for pruducing software and BIP148
< gmaxwell> BIP148 is also something they would want but IF and only IF most everyone
< sipa> luke-jr: and bip148 obviously does not
< luke-jr> people who are making a conscious decision on what software to run, are switching to BIP148 nodes or at least uacomments
< sipa> if core merges bip148 as a default option, it will just make people run other software instead, and the same will happen
< sipa> i expect that a number of people will run it, it won't activate, they'll be forked off, and they'll revert to running non-BIP148 code within hours
< sipa> luke-jr: i personally don't believe BIP148 will happen
< luke-jr> BlueMatt: no, because the businesses will NEVER run BIP148 until Core merges it
< luke-jr> the only "opposition" (besides trolls) I see to BIP148, is the mistaken belief that it won't or can't work
< luke-jr> if businesses weren't being stupid about this, I'd prefer BIP148 activate without Core. but reality is what it is
< Chris_Stewart_5> luke-jr: My concern with implementing BIP148 is that BU (which is 40% of the hash rate) would unknowingly select segwit txs for creating a block. If they rebased onto 0.14.x GBT would not select segwit txs if it was not enabled
< bitcoin-git> [bitcoin] achow101 opened pull request #10417: BIP 148 support (master...master-BIP148) https://github.com/bitcoin/bitcoin/pull/10417
< jonasschnelli> gmaxwell. Thanks... Came to the conclusion that using the HRP (and conform to Bech32 in BIP0173) may be better then saving a single char.
< Chris_Stewart_5> "By orphaning non-signalling blocks during the last month of the BIP9 bit 1 "segwit" deployment, this BIP can cause the existing "segwit" deployment to activate without needing to release a new deployment. "
< Chris_Stewart_5> If I understand BIP148 correctly, it is advocating for oprhaning > 50% of the hash rates blocks?
< Chris_Stewart_5> So reading more about BIP8 I don't think it is necessarily a great idea to not have the possibility for a soft fork to fail


< sipa> bip152 often relays blocks in a few kb
< sipa> look at BIP152


< jl2012> Want to double check, according to BIP9, height of the first block with new rules is divisible by 2016?


< luke-jr> nah, BIPs 1/2 contradict themselves, and typical seem to be the original creation date


< sipa> though it is a bit complicated since bip66


< sipa> BlueMatt: and it is reason why bip32 has hardened keys


< abpa> Don't you have the same issue if SegWit 2 is proposed with BIP9 over again?
< luke-jr> what happens if a malicious node sends 0.14.1 a segwit block when BIP9 didn't activate? will it permanently flag it as invalid and never reconsider a stripped version?


< NicolasDorier> is there a way in Bitcoin Core to get an unused address ? I am tempted to call getnewaddress everytimes, but doing so would create big gap in by BIP32 path, which would make rescanning fail


< sipa> BlueMatt: bip50 was 30 deep, iirc


< bincap> luke-jr: laanwj was so kind and confirmed gitian for knots+bip148 https://github.com/magmaship/bitcoin-special-gitian.sigs/pull/1


< emucode> I mean, include UASF, BIP148, of segwit


< spudowiar> I don't think the keystore stores BIP32 derivation information
< spudowiar> Is there a good way to get a transaction input and find the BIP32 derivation path?
< gmaxwell> well my figuring didn't use stale rates but measurements of delays between stratum updates at pools as a function of blocksize, so I was able to come up with a constant + factor*size model for orphaning risk. This was before BIP152-- and I think we can't really measure it anymore, but I figure the before bip152 figures give a baseline for the marginal impact. my model basically assumed the comp
< gmaxwell> sdaftuar: also because of how BIP152 works it is still preferable to have less new data. E.g. having a binary "contains new stuff" vs "not" isn't ideal--- because once prefilling is in use up to 10kb will be prefilled and if there is more than that, we're likely to prefill noting (under the assumption that the block is too inconsistent to be salvagable)


< arubi> bip66 might be causing testnet failures where it works on regtest. will stop spamming :)


< instagibbs> jcorgan, some other repo's numbering of bip148
< jonasschnelli> jcorgan: I have started with BIP151... sipa also mentioned he want to work on this
< bsm117532> Is there any way for a BIP37 SPV client to obtain the coinbase transaction, if he doesn't know its txid?


< jcorgan> jonasschnelli: is there a bip150 work-in-progress branch anywhere?


< jtimon> so on the developer side, I think we can introduce a per-deployment optional field that makes a given deployment activate instead of expire according to bip9, I guess that deserves it's own bip even if it's a simple extension of bip9, but the code is also easy to add and not very disruptive, and it seems something reasonable to have
< jeremyrubin> how does it break bip34?
< sipa> well as long as you stick to the bip34 rules


< bincap> also, how to set given date of the block generation? I want to test bip148 that rejects blocks that do not signal for segwit activation


< bsm117532> My question is: does bitcoin consensus-enforce the statements in BIP16 about disallowing non-pushdata?
< sipa> read bip62
< da2ce7> In particular this pull request need code-review: https://github.com/bitcoin/bips/pull/512


< wumpus> emucode: as for existing tests, there's a test/functional/segwit.py and test/functional/bip9-softforks.py
< emucode> btcdrak: I would like to write unit test, that creates a block, we assume that current date is 2016-09-01, and in this blog it sets on or off BIP9 flag, and segwit flag, and see if that block would be rejected or accepted
< emucode> what commands available in test framework could be use for UT for BIP148?


< bitcoin-git> bitcoin/master 1f3d78b John Newbery: Wait for connection to open in bip9-softforks.py...


< RealM9> gmaxwell, I think you should review BIP148 only because of community interest. Okay, yes this BIP is only few weeks old, but why not? If there is a huge community interest, why not review it? Community is waiting for you to review. It's only few lines of code anyways. You don't have to put this BIP in next bitcoin core version. Just review it and sign binaries. People are fighting for SegWit. This would be a step further. You hav


< gmaxwell> In case "RealM9" comes back, I don't think anyone who regularly works on Bitcoin Core has even looked much at BIP148 yet.
< RealM9> So, when will you sign BIP148 binaries?


< gmaxwell> Why are we even storing seralized private keys when BIP32 is in use?
< jonasschnelli> Yes. An alternative for bip39?


< gmaxwell> stevenroose: no, it got 'activated' eons ago. then the miner signaling it mined BIP109 invalid blocks (because their implementation was broken) and forked classic off (until classic ripped out 109)
< stevenroose> gmaxwell, yeah I read about bip109 as well when I googled the versionbit. So that means that 95% of testnett blocks the last few weeks were mined by people trolling about bip109?
< jonasschnelli> The reminds me of the problem that BIP125 doesn't explicit mention a recommended nSequence nr. Electrum was using 0, Core intmax-2. (privacy)


< luke-jr> could git clone https://github.com/bitcoin/bips.wiki.git if that makes it easier