< December 2024 >
Su Mo Tu We Th Fr Sa 1234567891011 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31
2017-07-21
< 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: 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
< 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>
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.
< 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
< 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"
< 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
2017-06-03
< 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).
2017-06-01
< 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?
2017-05-28
< 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?
2017-05-27
< 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
< 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...
< 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>
I think we could deploy the proposed fix to covert asicboost with bip8 pretty fast, but maybe still not august
< 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>
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>
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>
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>
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/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
< jtimon>
pre-bip149 won't think segwit is activated
< luke-jr>
yes, in general; but segwit is more complicated than merely another bip9 deployment
< 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
< 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
< 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.
< luke-jr>
gmaxwell: I don't see a reason in this, to make BIP148 fail and split the chain.
< gmaxwell>
it's perhaps an argument that the BIP9 timeout default should be more like 2 or three years.
< 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
< 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
2017-05-15
< sipa>
bip152 often relays blocks in a few kb
< sipa>
look at BIP152
2017-05-10
< 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
2017-05-06
< sipa>
though it is a bit complicated since bip66
2017-05-04
< sipa>
BlueMatt: and it is reason why bip32 has hardened keys
2017-05-03
< 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?
2017-04-30
< 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
< emucode>
I mean, include UASF, BIP148, of segwit
2017-04-13
< 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)