< sipa>
jnewbery: i was starting to respond to you, but to the last point "We already have control to make a BIP9 deployment active at a certain height in regtest using -vbparams. What advantages do you see for making a deployment buried instead of just activated at a height?" -> -vbparams doesn't permit having segwit active before block 432
2017-10-08
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #11463: BIP148 user activated activation of segwit (master...bip-segwit-flagday) https://github.com/bitcoin/bitcoin/pull/11463
< bitcoin-git>
[bitcoin] jackpot1136 opened pull request #11463: BIP148 user activated activation of segwit (master...bip-segwit-flagday) https://github.com/bitcoin/bitcoin/pull/11463
< gmaxwell>
luke-jr: yes for HB BIP152 we don't to validation except hashing!
< gmaxwell>
I think the interaction isn't too bad, for this purpose a BIP152 CB HB block is relaying you the header of its parent.
< sdaftuar>
luke-jr: even with bip152 the headers need to be valid
< gmaxwell>
luke-jr: the only place that happens in the protocol is HB BIP152 messages.
< jonasschnelli>
tloriato: AFAIK BIP45 is the only "standard" to create multisig addresses with a set of given pubkeys.
< tloriato>
Good afternoon. I was looking into BIP45, that tries to standardize the Structure for Deterministic P2SH Multisignature Wallets, but I've read the emails discussing it and seems to have a little or disagreement between the need for this particular BIP. I'm wondering if there is another standard way to generate a Deterministic Multisig Wallet? I was inclined to generate a standard Mnemonic (BIP39) and split it using Shamir
2017-10-04
< jonasschnelli>
BlueMatt: yeah. Happy to pull-in a cleanup into bip159 PR
2017-10-03
< cfields>
sipa: what do you think about a NODE_FULL (or so) flag which indicates that the node can validate the entire chain? That way (say in a year or two from now), we can require NODE_FULL, prefer NODE_NETWORK, and tolerate NODE_NETWORK_LIMITED ? I really don't like the outbound selection policy wonkyness that bip159 gives us.
< jtimon>
re https://github.com/bitcoin/bitcoin/pull/11398 I wonder if we should always leave at least the last bip9/bip8 deployment there to make sure we're using the rpc part of bip9
< bitcoin-git>
[bitcoin] jtimon opened pull request #11426: BIP90: Make buried deployments slightly more easily extensible (master...e16-bip90-extensible) https://github.com/bitcoin/bitcoin/pull/11426
< jl2012>
gmaxwell: "technically we could make mainnet activate segwit at the same time as p2sh" not easy since miners included witness commitment before segwit activation. Those blocks are invalid under BIP141
< jonasschnelli>
sipa: re #11167, is it a problem that you can send to BIP173 addresses when IsWitness is diabled? "addwitnessaddress" rejects while sendtoaddress doesn't... I guess since it's active on mainnet this doesn't matter anymore?
2017-09-22
< achow101>
sipa: oh, ok. I don't see that in the BIPs though..
2017-09-21
< ThomasV>
gmaxwell: we were also considering an import format along the lines of bip124
< gmaxwell>
well sipa's bip173 patch doesn't have the error finder in it.
< gmaxwell>
jonasschnelli: another thing in the GUI is that we should eventually have a BIP173 error hinter. We need a monospace text entry field that can be told to underline characters or something like that.
< tloriato>
Hello! I was looking for how I could import a BIP32 Extended Key into the Bitcoin Core wallet? I've tried the RPC Documentation but got no luck there.
< gmaxwell>
(my motivator is primarily mining off blocksat, but this could eventually make a BIP152 HB mode like transmission smaller and faster too)
< BashCo>
I understand Core was in a tight spot re BIP148. People said it had to come from the users, and it did. Thankfully it was a great success.
< sontol>
had you kept mum about ASICBOOST and propose BIP149-like activation proposal animosity towards Bitmain won't go through the roof
< sontol>
Even if that will result in something that you don't plan for (e.g BIP148)
< OdaNobunaga>
I think it would be great to have a way of following core devs's discussions regarding protocol changes, like the table that listed devs' opinions regarding BIP148, 149, segwit2x etc.
< gmaxwell>
Says one thing, does another-- which will drive the headline; rather than the message of the complete arc which is user empowering. It'll just be "core backs down and does BIP9 anyways".
< CodeShark>
perhaps BIP9 will be used again - but for now, BIP9 feels very demoralizing to many users
< OdaNobunaga>
Regarding the "will Core use BIP9 again" thing, I agree there's a huge disconnect between what the community (on slack and to a lesser extent reddit) thinks of what core will do (never do it again) vs. your idea of using BIP9 with BIP8 as fallback
< gmaxwell>
Again, a direct response to BIP148 (they even said so in the announcement! :) )
< gmaxwell>
For example, one of your top contributors (who sent me some very nasty remarks) told me that Bitcoin Core was _never_ going to force a segwit activation and so BIP148 was the _only_ option.
< gmaxwell>
NYA was specifically created to take BIP148's success and turn it into something else.
< gmaxwell>
NYA wouldn't have even existed if not for BIP149.
< CodeShark>
bip8 would have allowed the nya to dominate headlines
< gmaxwell>
In doing it furthered a conflicting message. BIP9 was never 'miners choose'. It's just an activiation mechenism.
< gmaxwell>
CodeShark: I think people on slack echochambered themself into a corner about that. The obvious thing to do after BIP9 was BIP8, just as part of the process.
< CodeShark>
I think we all agree that BIP9 for segwit caused some serious problems
< CodeShark>
things can always change. I think the overarching goal here is to convey that users choose consensus rules, not miners. and bip9 sends conflicting messages
< CodeShark>
but if the situation changes, perhaps bip9 becomes viable again
< gmaxwell>
absolutely, but saying that we would not use BIP9 again is an error. I expect we would with an explicit stated outright plan to BIP8 after if user adoption was very strong but miners did not activate. These are technical details, sure. But unfortunately what got quoted was that BIP9 wouldn't be used again.
< CodeShark>
whether we use BIP8 or BIP9 or something else isn't nearly as important - although I do think it's important that users feel empowered to resist hostile miners
< gmaxwell>
CodeShark: that most of the slack people are effectively not involved in the project itself in any serious ongoing capacity, including not hanging out here. It has serious negative results, like you carrying around a we'd never use BIP9 message again, which is entirely not what I'm thinking and I doubt its what other people are thinking.
2017-09-12
< meshcollider>
morcos: by tripling, do you mean one P2PKH, one P2SH and one BIP173?
2017-09-10
< kanzure>
if a bip125-replaceable transaction's replacement does not have sufficient fee as defined by bip125, does the replacement become a valid replacement if the replacement gets a descendant that pays sufficient fee (child pays for parent)?
2017-09-09
< meshcollider>
I was only thinking about the security of importing the seed, not about bip44 itself hence my confusion
< gmaxwell>
BIP44 basically violates bip32 by applying public derrivation to all cases, it should only be used in cases where export is not permitted; which is plausable for hardware wallets.
< meshcollider>
as long as they support the same seed -> master key in bip32 and tree structure in bip44
< gmaxwell>
meshcollider: bip39 is a bad spec, disavowed by some of its authors even. Among other issues it has no facilities for versioning, which is a critical flaw.
2017-09-08
< jonasschnelli>
with a dummy key/address generated in bip32.org or so
< esotericnonsense>
from BIP141 i interpret 'base tx size' as tx.serialize() (because it is equivalent to tx.serialize_without_witness()), and tx.serialize_with_witness() as being total transaction size BIP141
< gmaxwell>
Esp for BIP173; the transition can't really be done abruptly unless its seriously delayed.
< instagibbs>
morcos, most are doing bip49 I think, which only is about nested
< gmaxwell>
sipa: we should have specified this as part of the segwit bips then. :( but okay, it could be done.
< gmaxwell>
why are we expanding scope to recieve BIP173 addresses. I think we should not make this scope expansion now.
2017-08-30
< instagibbs>
bip49, minus the bip44 part?
2017-08-29
< instagibbs>
ok, not knowledgeable enough to really dive into improvements, was having a discussion that revolved around bip125/Core design of replacement
< sipa>
luke-jr: with BIP152, the size hardly matters, except if you're ridiculously bandwidth constraint to the point you'd be unable to keep a node synced in the first place
2017-08-22
< rubensayshi>
yea Proposed sounds like the right status for BIP173 and for people to starting deploying (wallet support for) it
< sipa>
bip173 was written with many reference implementations at the time of publishing already, in the hope of not needing any significant change afterwards
< sipa>
rubensayshi: oh, BIP2 has a "proposed" status
< rubensayshi>
yea which BIP2 addresses to prevent that from happening once they reach Final
< sipa>
rubensayshi: i think there have been too many cases of bips fundamentally changing after initial publishing
< sipa>
rubensayshi: i personally have no intention of changing bip173 anymore
< rubensayshi>
but lets say BIP39 (*hint hint that actually did change under my feet while it was Final, but lets not side step too much*)
< rubensayshi>
hmm, when will BIP173 move from Draft to Final?
2017-08-16
< gmaxwell>
as any whitepeer would still be able to request anythign we have. (in your BIP150 world that phone would be authenticated, presumably)
< jonasschnelli>
(in an ideal BIP150 world)
< sipa>
so, i'd like to suggest that bip159 only defines 1 bit, corresponding to 144/288 blocks
< jonasschnelli>
last updates on BIP159: threat bits independently, fingerprinting protection
<@wumpus>
#topic bip159: (NODE_NETWORK_LIMITED service bits)
< sipa>
do we want to discuss bip159 more?
< gribble>
https://github.com/bitcoin/bitcoin/issues/10387 | Implement BIP159, define and signal NODE_NETWORK_LIMITED (pruned peers) by jonasschnelli · Pull Request #10387 · bitcoin/bitcoin · GitHub
< * jonasschnelli>
puts Implement BIP159 / #10387 on the list
< praxeology>
Is it just BIP143 + SIGHASH_FORKID = 0x40 ?
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #10957: Avoid returning a BIP9Stats object with uninitialized values (master...bip9status) https://github.com/bitcoin/bitcoin/pull/10957
< bitcoin-git>
bitcoin/master a46a671 MarcoFalke: Merge #10957: Avoid returning a BIP9Stats object with uninitialized values...
< bitcoin-git>
bitcoin/master 3eb53b8 practicalswift: Avoid returning a BIP9Stats object with uninitialized values...
< luke-jr>
I assumed jonasschnelli meant implement BIP37 client-side
< gmaxwell>
yea, if we had BIP150 I wouldn't mind random extensions there even without bips. if you're only using it between trusted adjcencies the criteria is different.
< wumpus>
if not you'd have to wait for BIP150 (authentication)
< wumpus>
then again BIP37 works now, that's a point, step-by-step evolution usually means that things keep moving instead of being blocked by big moves
< jonasschnelli>
I guess there are still usecases for BIP37 once BIP150 is life (trusted peers)
< wumpus>
if only to be able to refer to it in bips.md and such
< jonasschnelli>
CodeShark: why would it get deprecated (you mean dep. bip37 in favor of client side filtering)?
< gmaxwell>
(not due to it itself, but due to increasing the scope of BIP37)
< jonasschnelli>
BIP151 encryption question: the current definition says, that encryption negotiation has to be done before the version handshake (I guess it makes sense to have the enc.negotiation first). But how should a peer know if the other peer supports BIP151. Try and reconnect? Service bit fetch-able via relay, seeds (meh!)?
< venzen>
My bad for not comprehending this sooner - I was somehow understanding "effective" block size limit increase from BIP141 and related explanations
< kallewoof>
sipa: since it kind of overlapped with BIP154 (anti-DoS via POW) I am interested in the work in replacing the misbehaving stuff with how useful a node has been that you mentioned before. Is there any work being done on this currently?
< kallewoof>
Will re-read BIPs though, while at it.
< sipa>
it's similar to BIP37's MSG_FILTERED_BLOCK btw
< gmaxwell>
we might end up inadvertantly rescuing them with a more rapid adoption of BIP173 though then there is the same idiocy that may happen four months from now. :( and maybe we should hold back posting the BIP173 integration from core so that it's distinct from the next of these dumb forks.
2017-08-03
< gmaxwell>
It also suggests that BIP173 support's test plan should include testing it with other witness version numbers. :)
< sipa>
so, bip173 specifies how to translate address strings to witness version/program, and defers to bip141 for encoding that to scriptPubKeys
< wumpus>
#topic bip173 unit tests issue
< sipa>
short topic: bip173 unit tests issue
< wumpus>
do we need any updates to bips.md for 0.15?
< luke-jr>
where are we at with a 0.14.3 with BIP148? I'm going to miss next meeting most likely again :/
2017-07-30
< bitcoin-git>
[bitcoin] practicalswift opened pull request #10957: Do not return a BIP9Stats object with uninitialized values (master...bip9status) https://github.com/bitcoin/bitcoin/pull/10957
< sipa>
the fix for #10924 is easy: we need to add P2WSH/P2WPKH to CTxDestination, which is needed anyway for bip173 support
< gmaxwell>
BIP173 is worse becuase it's just not implemented at all... I wouldn't even suggest it except for the nice property of being able to say "any segwit version can send to BC addresses".
< jtimon>
so what about 0.15.1 -> segwit wallet, 0.15.2 - > send to bip173, optionally receive ?
< wumpus>
creating bip173 receiving addresses should be optional, to not confuse too much, especially as long as vrutally no other wallets have support for it
< gmaxwell>
jonasschnelli: BIP173 is native segwit, we have tests for native segwit... what BIP173 adds is just an address encoding for it, so that it can be made user accessible.
< gmaxwell>
jonasschnelli: we can recieve BIP173 payments with some hidden options. (I believe the code is still there-- we have tests for that already)
< wumpus>
sending obvs is optional in itself, you don't *need* tos send to BIP173 addresses, and if you do you know what you're doing. I mean about receiving.
< jonasschnelli>
BIP173 sending only is kinda hard(er) to test without the rec. part
< gmaxwell>
So there are two things I think are potential for scope, SW wallet (getnewaddress returns p2sh embedded SW), and BIP173 sending. We don't have to do them at the same time but it would be nice to be able to say that any SW enabled wallet can send to 173 style addresses.
< gmaxwell>
There are two questions: segwit wallet, and sending to BIP173. I consider the second less important, it's also more work (because it isn't already dormant in the codebase).
< gmaxwell>
BlueMatt: if we do BIP173 support it would just be sending to.
< gmaxwell>
to BIP173 style addresses. Maybe we could consider short cycling 0.16
2017-07-22
< morcos>
My general view is that the more we think the miners are going to properly enforce BIP91, the more we want to make a patch/release that does so
< praxeology>
BIP91 rules are not/never were my rules. I only heard about it yesterday when I was checking up on BIP 148 status
< btcdrak>
I agree this situation is ideal. If BIP91 had the same activation date as BIP148 it could have piggypacked and there would be significant node enforcement. But in 24 hours, I dont see how we can make this better at all. Asking exchanges et al to run a quick untested patch (by Core's standards) for what doesnt seem like an emergency (at least to me), seems irresponsible.
< btcdrak>
I've asked several pools and based on what they say at least, much more than 51% of the hashrate is running BIP91 enforcement code either btc1 or segsignal. They understand they must enforce the rule.
< luke-jr>
too many people disagree with the adjusted-BIP148 it seems, to reduce to a binary choice there
< luke-jr>
at least if it's simply BIP148 or non-BIP148, *users* will be on one or the other
< luke-jr>
gmaxwell: less likely than if 30% run BIP148-adapted-to-BIP91, 30% run BIP148-as-is, and 40% run non-BIP148
< luke-jr>
given the short time period and risk of splitting up enforcement too much, I currently favour just deployment of BIP148 as-is. not perfect, but I think it's the least-risky all things considered
< luke-jr>
gmaxwell: BIP148's patch is only larger for safety and unit tests. it's much smaller than BIP91 without those.
2017-07-21
< bitcoin-git>
[bitcoin] achow101 opened pull request #10900: [0.14] Enforce segsignal activation height and rules (0.14...early-uasf-bip91) https://github.com/bitcoin/bitcoin/pull/10900
< Murch>
praxeology: BIP91 requires every block to signal bit1.
< [\\\]>
just as long as there is an info tip or link to what bip91 is
< praxeology>
Emergency BIP91 Release
< sipa>
but the reason for having bip91 enforcement in the client is not to make a minority chain win
< sipa>
praxeology: which may mean that when bip91 activates, many forks are seen on the network, even if everyone totally intends the 91 chain to win
< sipa>
praxeology: a significant amount of hashrate may be spy mining, the amount actually enforcing bip91, even if they intend to, may be low and/or unmeasurable
< Murch>
Providing a patch to Core that includes enforcement of BIP91 would give many users the option to support a defacto activated softfork that they currently can only enforce by running third party software.
< Murch>
While in sentiment large parts of the community support segwit activation and a majority of that would probably be willing to go along with BIP91, the node count doesn't yet reflect that.
< Murch>
praxeology: That's not correct. It looks likely that BIP91 will have a majority in mining support, however due to the quick rollout it has hardly any node infrastructure.
< sturles>
Re reorgs related to BIP91, will -walletnotify trigger if a transacttion changes status from confirmed to unconfirmed due to a reorg?
< gmaxwell>
I would prefer to do the BIP148 based approach, but its a larger patch, unfortunately.
< Murch>
morcos: Yeah, I agree that a release would be good. Another option would be to update BIP148 to start at the activation height of BIP91 activation instead of August 1st.
< Murch>
morcos: Right now we're looking at an activation of BIP91 at Sunday morning at ~2am PDT (5am EDT). Likely if any reorgs happen then right at the start.
< lejitz>
gmaxwell: Clearly, having everyone enforce BIP91 is the way to go if it can be done in time. But if you can't get the econ nodes enforcing BIP91 before enforcement begins, then it is difficult to get people to begin enforcing at all, because they won't want to be the one to go first in the event that the a fork occurs right after they patch/upgrade. If upgrading must occur after BIP91 activates, then the
< sipa>
lejitz: the worst forking will likely be right when bip91 activates...
< morcos>
but why don't we decide to release a BIP148 patch then
< sipa>
morcos: lejitz is arguing (i think?) for starting bip91 enforcement at another time
< morcos>
in which case running a BIP91 node makes it safe to accept payments
< morcos>
gmaxwell: I think the point is that we as a community could decide that BIP91 is the new rules of Bitcoin
< sipa>
lejitz: it is a realistic chance that the eventual chain will not have bip91 enforcement, and won't have segwit activated
< lejitz>
@sipa @achow101 Not enforced, complied with, meaning signaled bit 1. If every block since BIP91's activation (from a post activation perspective) signaled bit 1, then it's been complied with. The enforcement from the patch could be conditioned on that observation.
< sipa>
lejitz: we can't observe whether bip91 is being enforced
< lejitz>
achow101: No, the patches enforcement is conditioned on BIP91 being enforced until the chosen enforcement time of the patch.
< achow101>
lejitz: that assumes that bip91 will be enforced from activation, but that is an assumption we cannot make
< lejitz>
achow101: If most of the econ nodes can upgrade before BIP91 activation, then it is not a problem. But if it is afterwards, I can't see any of them wanting to risk being forked off the network while waiting for others to upgrade (who wants to go first?). As long as no fork has already occurred, then it is not a problem to join in enforcement later, but nobody knows what happens in the meantime while
< lejitz>
everyone tries to coordinate. To solve this problem (assuming most econ nodes can't quickly upgrade before 91 activation), the patch can pick an arbitrary time/block height to start enforcing, so long as every block between BIP91 activation and the patches enforcement time has signaled bit 1. Everyone can take a few days to upgrade, knowing they will remain in consensus if there is a fork in the meantime.
< Murch>
sipa: Well. We're currently running vanilla Core, and we're worried about customer funds getting entangled in reorgs that would supposedly be impossible if BIP91 were actually properly enforced.
< achow101>
enforcing at the bip 148 activation time means that we would be enforcing with the bip148 clients.
< 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..
2017-07-20
< 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
2017-07-19
< 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 #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
< 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.
2017-07-17
< 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
2017-07-14
< instagibbs>
Murch, there are none right now AFAIK. BIP49 I think is the only proposed one for Mycelium or something
2017-07-13
< 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."
2017-07-12
< 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
2017-07-10
< 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?
< 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"?
2017-06-29
< 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.
< 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/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.
< 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"