< April 2024 >
Su Mo Tu We Th Fr Sa 1 2 3 4 5 6
7 8 91011121314151617181920
21 22 23 24 25 26 27
28 29 30
2017-12-27
< sipa>
but electrum does not follow bip44 afaik
< cluelessperson>
gmaxwell: Another idea comes to mind. Suppose I should focus on writing up a list of reasons *why* I felt I'd want to change the wallet.dat structure. Part of it was to make it portable, modifiable, and allow users to just insert new keys at whim, from Electrum, BIP39, xpriv, xpub, WIF, mini, etc.
2017-12-20
< maaku>
I've moved some discussion regarding implementation of BIPs 98, 116, and 117 to #bitcoin-mast
< bitcoin-git>
[bitcoin] jnewbery opened pull request #11817: [tests] Change bip68-112-113-p2p to use BitcoinTestFramework (master...refactor_bip68-112-113-p2p) https://github.com/bitcoin/bitcoin/pull/11817
2017-11-23
< jonasschnelli>
The "just works" approach is very important and a reason why I try to kick BIP150/151 forward even with the fact that it's already sort of possible with stunnel, VPN, TOR
< jonasschnelli>
BIP150/151 would work towards trustworthy direct connections
< jonasschnelli>
a) you use BIP150 (or other enc/auth) via p2p and use SPV BF on your phone/remove client
< Provoostenator>
(assuming BIP150/151 for the sake of argument)
< jonasschnelli>
sipa: is that scheme: (k1+H(k2,R1))*G = k1*G+H(k2,R1)*G = R1+H(k2,R1)*G compatible with BIP32?
< gmaxwell>
jonasschnelli: the other thing is this KDF scheme. Basically, I want to address the problem that you want to enter a password protected seed on a hardware wallet and not expose the password or seed to an untrusted host... but the hardware wallet does not have enough CPU power to do a meaningful KDF (the 2000 rounds in BIP39 is basically pointless)
< jcorgan>
physical damage aside, i'm still not sure if any proper bip32 hd-wallet seed/hierarchy designs have emerged
2017-11-16
< jonasschnelli>
I'm not sure if a plain text seed dump (or BIP39) is something you want in a bank tresor
< jonasschnelli>
Somethine we (HWW company) do discuss regularly is how we can make the backup situation better.. a lot of things are involved. Bip39, sdcard, shamir's secret, notary services, etc.
< jonasschnelli>
PBKDF2 with 2048 rounds seems not ideal (BIP39)
< jonasschnelli>
gmaxwell: I'm happy to hear your bip39 successor HWW KDF idea...
< gmaxwell>
achow101: unless I'm confused (always likely) it's just a minor fixup of BIP39.
< gmaxwell>
achow101: ugg electrum itself. can't encode arbritary data, so it can't work with existing wallets. at least it's better than bip39.
< gmaxwell>
achow101: not bip39 as it's a brainwallet scheme that can't encode arbritary data, but yes.
< achow101>
gmaxwell: recovery code as in something like bip39?
< 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>
but if the situation changes, perhaps bip9 becomes viable again
< 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
< 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 3eb53b8 practicalswift: Avoid returning a BIP9Stats object with uninitialized values...
< bitcoin-git>
bitcoin/master a46a671 MarcoFalke: Merge #10957: 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: 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.
< 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
< 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>
gmaxwell: I think the point is that we as a community could decide that BIP91 is the new rules of Bitcoin
< morcos>
in which case running a BIP91 node makes it safe to accept payments
< 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.
< lejitz>
achow101: No, the patches enforcement is conditioned on BIP91 being enforced until the chosen enforcement time of the patch.
< sipa>
lejitz: we can't observe whether bip91 is being enforced
< 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"