< achow101>
what's everyone's thoughts on bip 148 and 149?
< 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
< Chris_Stewart_5>
unless they fail somehow silently by not having nodes upgrade
< Chris_Stewart_5>
If I understand BIP148 correctly, it is advocating for oprhaning > 50% of the hash rates blocks?
< 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>
Would there be any harm in writing code to provide to miners to *avoid* selecting segwit txs to put in their blocks? That way miners that don't support segwit for whatever reason won't select them for their blocks? Or is that already the case?
< sipa>
that's already the case
< sipa>
if you connect miner software that doesn't support segwit to bitcoind, GBT will only include non-segwit txn
< sipa>
(since 0.14)
< luke-jr>
Chris_Stewart_5: no, it's advocating for 100% of the hashrate to signal segwit
< bitcoin-git>
bitcoin/master fac79e4 MarcoFalke: qa: Warn when specified test is not found
< bitcoin-git>
bitcoin/master 5411997 Wladimir J. van der Laan: Merge #10374: qa: Warn when specified test is not found...
< bitcoin-git>
[bitcoin] laanwj closed pull request #10374: qa: Warn when specified test is not found (master...Mf1705-qaWarnTestNotFound) https://github.com/bitcoin/bitcoin/pull/10374
< paveljanik>
jtimon, ping
< paveljanik>
jtimon, GetDustThreshold's dustRelayFee is shadowing global ::dustRelayFee, but is always called with it as an argument. Do you prefer removing it and use ::dustRelayFee instead or renaming the argument name to prevent shadowing warnings?
< bitcoin-git>
bitcoin/master 2f84cf6 Wladimir J. van der Laan: tests: Correct testcase in script_tests.json for large number OP_EQUAL...
< bitcoin-git>
bitcoin/master 0542978 Wladimir J. van der Laan: Merge #10405: tests: Correct testcase in script_tests.json for large number OP_EQUAL...
< bitcoin-git>
[bitcoin] laanwj closed pull request #10405: tests: Correct testcase in script_tests.json for large number OP_EQUAL (master...2017_05_scriptnum_test) https://github.com/bitcoin/bitcoin/pull/10405
< wumpus>
gmaxwell: any idea what caused the corruption?
< wumpus>
darn it's in a log file, ideally it would regard CRC errors in the log simply as truncation
< gmaxwell>
I think likely just many unclean power offs..
< gmaxwell>
I think it does at a lower sanity checking level.
< wumpus>
there's nothing to be done if a corruption happens in a ldb, but in the log it would be fine to just roll back for our use case
< wumpus>
right
< bitcoin-git>
[bitcoin] fanquake closed pull request #9091: Optimize sending of getheaders when pindexLast is an ancestor of pindexBestHeader (master...OptimizeMoreGetheaders) https://github.com/bitcoin/bitcoin/pull/9091
< fanquake>
wumpus got a utACK from cfields on #7522, did you want to merge it?
< gribble>
https://github.com/bitcoin/bitcoin/issues/7522 | Bugfix: Only use git for build info if the repository is actually the right one by luke-jr · Pull Request #7522 · bitcoin/bitcoin · GitHub
< wumpus>
fanquake: I wasn't sure there, because I'm fairly sure that argument was only added recently
< wumpus>
then again if that function, nor any of its callees use the chain info, and there are no plans to, there's no use in passing it
< wumpus>
maybe we should ask jtimon
< wumpus>
not that I'd mind just merging it, but I don't want to sabotage anyone's work in progress
< wumpus>
ok I see sdaftuar added it and now is ok with removing it
< fanquake>
wumpus ok. I'll ping him in that PR.
< wumpus>
fanquake: not necessary, I think
< wumpus>
he's not involved with this one
< fanquake>
wumpus All good then. #10388 should also be ok to merge.
< gribble>
https://github.com/bitcoin/bitcoin/issues/10388 | Output line to debug.log when IsInitialBlockDownload latches to false by morcos · Pull Request #10388 · bitcoin/bitcoin · GitHub
< bitcoin-git>
bitcoin/master 65d484a Alex Morcos: Output line to debug.log when IsInitialBlockDownload latches to false
< bitcoin-git>
bitcoin/master 526e839 Wladimir J. van der Laan: Merge #10388: Output line to debug.log when IsInitialBlockDownload latches to false...
< bitcoin-git>
[bitcoin] laanwj closed pull request #10388: Output line to debug.log when IsInitialBlockDownload latches to false (master...printIBD) https://github.com/bitcoin/bitcoin/pull/10388
< bitcoin-git>
[bitcoin] fanquake closed pull request #9325: Allow first cmpctblock/blocktxn received to be processed (rather than first requested) (master...ProcessFirstCmpct) https://github.com/bitcoin/bitcoin/pull/9325
< fanquake>
Good amount of Boost code being removed pre 0.15.
< wumpus>
fanquake: yes, another (possibly exploitable) miniupnpc vuln, happy we don't have enabled by default anymore, still yes we should bump the version
< bitcoin-git>
[bitcoin] practicalswift opened pull request #10415: [fuzz] Speed up fuzzing by ~200x when using afl-fuzz (master...fast-afl-fuzzing) https://github.com/bitcoin/bitcoin/pull/10415
< SopaXorzTaker>
Uhm, guys?..
< SopaXorzTaker>
we have a problem - P2SH addresses only depend on the security of RIPEMD-160
< wumpus>
please, #bitcoin
< SopaXorzTaker>
and that means that if a preimage attack is found, it'd be trivial to make a script that would verify and return, and spend any P2SH address
< wumpus>
again, #bitcoin, this is not the place to discuss the protocol in general
< SopaXorzTaker>
banned from #bitcoin for spreading bullsh*t
< cypherbit>
join bitcoin
< jtimon>
paveljanik: morcos asked not to remove the argument, so probably just renaming the argument is the less disruptive thing
< fanquake>
jonasschnelli Your PR/Nightly build server is pretty fancy now. Good work.
< fanquake>
I can remember when it was basically a file directory. A lot more useful information now!
< timothy>
hi, I know I should download Xcode etc, but apple.com is slow from here (like 4 hour to download it) so can someone give me MacOSX10.11.sdk.tar.gz?
< luke-jr>
timothy: it's technically illegal to redistribute :/ probably better off just waiting
< luke-jr>
timothy: btw, you're the Arch package maintainer, right? I had heard the packages were outdated (but that was a while ago..)
< midnightmagic>
It's also not really worth much if you take a closed-source distribution package from some rando on IRC. :-)
< timothy>
midnightmagic: not really, in gitian files there is the sha256sum of the tar
< morcos>
paveljanik: it always took an argument, and i asked jtimon not to remove it, b/c i thought that in trying to avoid small outputs in the wallet we might want to call that function with a different argument
< jonasschnelli>
sipa: Would support for Bech32 without hrp make sense in the ref. impl?
< morcos>
i'm not positive thats how we'll end up doing it or when, so i don't feel strongly, but yeah probably easier just to rename for now
< jonasschnelli>
sipa: it's a simple change and allow to reuse Bech32 for other stuff...
< jonasschnelli>
(where size matters)
< gmaxwell>
jonasschnelli: without the HRP you'll decode strings for one application as correct for another-- mooting the fancy protection.
< jonasschnelli>
gmaxwell: A single magic 5bit value inside the Bech32 would save 1char (the separator)...
< jonasschnelli>
But maybe I'm wrong.
< jonasschnelli>
I don't say we should throw it away.. just maybe the ref. impl. could support enc/dec Bech32 without the hrp
< jonasschnelli>
(working on a use case where size really matters)
< gmaxwell>
can't you prefill the prefix?
< midnightmagic>
timothy: pretty sure it's not, unless there's some new tarball-maker for that..?
< jonasschnelli>
gmaxwell: avoiding the HRP would allow to use something like "t<14-chars-bech32>" (magic inside the Bech32 encoding) instead of "t1<14-chars-bech32"), would save one char.
< jonasschnelli>
But I guess I'm again micro-optimizing... so nm
< sipa>
jonasschnelli: i would suggest you don't change the reference implementation, but just prefix a constant HRP before calling it
< jonasschnelli>
sipa: Aha. Now I understand... yes. Much simpler.
< wumpus>
I created a new signing subkey (same master key) - hopefully this will just work, but anyhow giving a heads up here in case the verify-sigs script starts ringing alarm bells
< wumpus>
you might have to refresh my key in any case
< gmaxwell>
jonasschnelli: sorry, thats what I meant by prefill the prefix.
< 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>
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
< sipa>
achow101: done
< achow101>
ty
< sipa>
Chris_Stewart_5: signalling for BU != running BU
< achow101>
Chris_Stewart_5: they shouldn't select segwit txs though since they are non-standard under current rules
< Chris_Stewart_5>
achow101: P2SH(P2WPKH or P2WSH) would be wouldn't it?
< sipa>
Chris_Stewart_5: no
< sipa>
those still require a spend that violates the CLEANSTACK rule
< sipa>
which has been in every release since 0.11
< achow101>
the transactions creating the p2sh nested outputs themselves are find and can be mined. the spending transaction is not
< achow101>
s/find/fine/
< luke-jr>
(and mining those p2sh txs won't be a problem for the BU blocks)
< BlueMatt>
luke-jr: this is absurd, do you seriously believe the vast, vast majority of bitcoin users (incl businesses) support bip 148?
< gmaxwell>
he believes they support segwit, which is super clear at this point.
< BlueMatt>
bip 148 != segwit, they are different proposed consensus changes, despite sharing many features
< luke-jr>
BlueMatt: businesses exist to serve the users
< gmaxwell>
yea, I'm not arguing that they're the same, just trying to clarify luke's position the way I understand it.
< luke-jr>
BlueMatt: and so far, the businesses are taking a hardline position of "we will run Core only"
< gmaxwell>
Chris_Stewart_5: No it won't.
< luke-jr>
which is half the reason we need to merge it in Core
< luke-jr>
if businesses weren't being stupid about this, I'd prefer BIP148 activate without Core. but reality is what it is
< BlueMatt>
businesses are also users of the system, especially the many that do not expose bitcoin to their users, and there is clearly not vast, broad support for bip 148 in that community even *if* 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
< gmaxwell>
it's very disruptive if it isn't an overwhelming success.
< sipa>
it can only work if everyone adopts it
< sipa>
it is not our job to push for that
< luke-jr>
gmaxwell: which is why it's important to ensure it's an overwhelming success.
< BlueMatt>
it is not bitcoin core's job to merge something *until* that exists, irrespective of whether individual contributors are pushing for it
< luke-jr>
BlueMatt: until what exists?
< BlueMatt>
ovherwhelming support across the ecosystem
< luke-jr>
that pretty much exists to the extent it can without Core merging it.
< luke-jr>
businesses will run whatever Core releases, and won't run what Core won't release.
< luke-jr>
it sucks, but that's how it is right now
< sipa>
and they do that, hopefully because they believe we're making sane choices of what is included in a release
< BlueMatt>
luke-jr: ok, please go email every business you can find an email for and ask them if they support bip 148 activation on date X
< BlueMatt>
plus as many polls as you can possibly create at physical meetups
< BlueMatt>
and then get back to me
< luke-jr>
sipa: missing the point. it creates chicken-and-egg
< BlueMatt>
not entirely, the chicken-and-egg problem can be solved by active outreach
< gmaxwell>
BlueMatt: hopefully not your intent, but you did just make it sound like only business mattter.
< BlueMatt>
something that I have yet to see literally any of
< BlueMatt>
gmaxwell: fair, yes, that tis not at all my intent, hence the mention of physical meetups
< luke-jr>
BlueMatt: no, because the businesses will NEVER run BIP148 until Core merges it
< BlueMatt>
businesses do matter, but, indeed, only as much as every other group
< BlueMatt>
luke-jr: we did it with segwit and got back overwhelmingly positive response!
< BlueMatt>
prior to the parameters being merged
< luke-jr>
besides half the businesses supporting Classic back then..
< BlueMatt>
we got back 0 negative responses
< BlueMatt>
0
< BlueMatt>
on top of people doing physical outreach and talking to various groups at meetups, plus discussions with long-time bitcoin holders and investors
< gmaxwell>
BlueMatt: no, not true, we got a response from one webwallet vendor saying they prefer it be delayed a few months.
< gmaxwell>
BlueMatt: the was the only negative response.. And I got more than a 50% response rate.
< BlueMatt>
yes, sorry, we got one "please delay, because I'm worried about other people" response, though not worried about themselves, and only a request for delay, not a request for "no"
< BlueMatt>
well, ok, mostly you got, but ok :)
< gmaxwell>
no, actually it was a "we would be put at a competative disadvantage because other people integrated segwit support already and we haven't started" not "other people".
< BlueMatt>
oh, somehow i misrecalled, sorry
< luke-jr>
ok.. so because we don't have business consensus in advance, Core should take a hardline position that puts users at more risk?
< sipa>
luke-jr: i personally don't believe BIP148 will happen
< luke-jr>
sipa: it will, even if it is a minority chain splitting off
< BlueMatt>
business + broad user study
< 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>
if core merges bip148 as a default option, it will just make people run other software instead, and the same will happen
< luke-jr>
people who are making a conscious decision on what software to run, are switching to BIP148 nodes or at least uacomments
< sipa>
this is my expectation, and i certainly may be wrong
< BlueMatt>
luke-jr: do you not agree that we should be, above all, absolutely and strictly requiring consensus for any consensus rule changes?
< luke-jr>
BlueMatt: not for softforks, no. otherwise Segwit should never have been merged.
< BlueMatt>
bip 148 has many of the upgrade properties of a hf
< luke-jr>
Segwit is absolutely contentious. But it has sufficient support to merge as a softfork.
< BlueMatt>
from that perspective bip 148 is closer to a hf than a sf, by far
< sipa>
luke-jr: and bip148 obviously does not
< BlueMatt>
segwit contention is overstated, in my experience
< sipa>
luke-jr: i don't understand why we're even discussing this
< luke-jr>
I don't agree. BIP 148 only needs a majority to avoid a split.
< Anduck>
maybe core should publish two versions.
< luke-jr>
Anduck: there's an interesting idea
< BlueMatt>
Anduck: we do *not* ship code with a massive face cannon built in
< BlueMatt>
you're welcome to, however :p
< BlueMatt>
luke-jr: then you're talking about a masf again..why not tell miners to just 51% attack and turn on segwit in the current signaling, then?
< BlueMatt>
but, yea, I'm with sipa, this is fucking stupid
< Anduck>
it's indeed tough. SF-SW itself can be seen as "bad" because it relies on miners.. it's all very hard
< luke-jr>
BlueMatt: telling miners is very different from economically forcing their hand
< luke-jr>
especially when the miners are already hostile and attacking the network
< BlueMatt>
Anduck: no, its safety is somewhat redundant - if the vast, vast majority of nodes upgrade you're fine, if, otoh, the vast majority of miners upgrade, you're also fine. as things normalize (no one's gonna put money into segwit until nodes + miners are enfocing it) it'll become useable, but the fork and coin-loss risk is mitigated somewhat thanks to redundant protections there
< BlueMatt>
this it not true for bip 148, just as it is not true for a hf
< BlueMatt>
luke-jr: great, so go talk to the exchanges and merchants where miners sell their coins and tell them to switch
< BlueMatt>
I'm happy to help intro you to folks if you dont know most of them
< Anduck>
BlueMatt: yeah, that's true
< luke-jr>
BlueMatt: another dev has already tried this, and found they will only if Core releases it..
< BlueMatt>
well then they're expecting us to do the job of figuring out what the community's consensus on bitcoin's consensus rules is, and it is clearly not bip 148
< BlueMatt>
so sounds like you got a "no"
< luke-jr>
it's not clearly "yes", but it's certainly far from clearly "no"
< luke-jr>
the community seems very much in favour of it, with a positive trent
< luke-jr>
trend*
< BlueMatt>
if they're, otoh, expecting "Core" to decide consensus rules for the bitcoin ecosystem, then they can also clearly fuck off
< BlueMatt>
that is not the same as consensus?
< luke-jr>
Segwit doesn't have consensus.
< BlueMatt>
if you could honestly tell me that everyone supported bip 148, including those who support it if we merge it, then fine, but you cant
< BlueMatt>
and if you're claiming you can, please pull your head out of your ass
< luke-jr>
I'd say it seems pretty similar to segwit itself.
< BlueMatt>
you think bip 148 has the same level of support as segwit?!
< BlueMatt>
i refer you to my previous comment about bodily orifices
< luke-jr>
maybe slightly less, but it seems to be pretty close
< BlueMatt>
(and the differences between SFs and uasfs)
< Anduck>
well, it's obvious that community wants segwit. now the big question is just how to deploy it
< Anduck>
apparently masf is not working because some small part of community can keep it not happening
< BlueMatt>
well activation method is a key part of any consensus rule change proposal
< gmaxwell>
My view: Community and industry overwhelmingly want segwit. Given that
< gmaxwell>
BIP148 is also something they would want but IF and only IF most everyone
< gmaxwell>
else wants it. (because it's disruptive if partial). So there is a symmerty
< gmaxwell>
breaking problem. Either ~everyone or ~no one should want it.
< gmaxwell>
So if a sufficiently high profile group said they would do it, they'd
< gmaxwell>
probably break the symmetry. But we really don't want it to be us
< gmaxwell>
in particular because it would feed the FUD that core controls this
< gmaxwell>
or that (when really the whole thing would work because the support
< gmaxwell>
for segwit is already overwhelming). Unfortunately, everyone else
< gmaxwell>
who would be a potential symmetry breaker has a starting disadvantage:
< gmaxwell>
they're not known and trusted for pruducing software and BIP148
< gmaxwell>
needs software. We could ship BIP148 switchable and defaulted to
< gmaxwell>
off but this raises a concern why not some other change: I would
< gmaxwell>
point out that the ONLY argument against BIP148 given what we know
< gmaxwell>
is that other people might not run it and the people who do run it
< gmaxwell>
may be disrupted.. this doesn't hold for 12345MB blocks or whatever,
< gmaxwell>
as there are solid issues there indpendant of the level of
< gmaxwell>
popular support.
< gmaxwell>
I've heard directly from people trying to push for BIP148 that they
< gmaxwell>
felt undermined by the project's lack of implementation of the
< gmaxwell>
mechenism.
< BlueMatt>
I'm happy to ship code with an #ifdef NEVER_DEFINED_BIP148_IMPL_FLAG, but, otherwise, yes, totally agree with the above
< sdf_0010>
what is the reason for core not including BIP148 or similar as a switch defaulting to off?
< BlueMatt>
sdf_0010: we dont ship software with a -maybeblowmyfaceoff=true option
< BlueMatt>
sorry, we just dont
< luke-jr>
but not enforcing BIP 148 is more "blow my face off" than enforcing it :/
< luke-jr>
(also, I'm pretty sure I can find such a flag.. but not the point :p)
< sdf_0010>
it's hard to even take BlueMatt seriously if he is going to use such ridiculous language
< Anduck>
BlueMatt: bip148 version "flavor" could be handed by core anyway. just with proper warnings everywhere, and good reasoning why core is making it
< achow101>
gmaxwell: BlueMatt could you guys give me the list of emails of businesses? I would be happy to ask them if they would support BIP 148
< sdf_0010>
we don't because 'i say so' isn't really a compelling point nor is the statement that this will blow off a users face. what are you going to walk over to every user running this on their system and take a shutgun to their face?
< Anduck>
...
< BlueMatt>
Anduck: see my comment above. if the goal is to have some level of code review and assurance that it is a reasonable set of code changes, then I think we should merge it behind an ifdef flag that is never define and not defineable from configure/make. that way we can say its there, its been vetted, but its not active and not available for people unless they're gonna interpret it as consensus
< gmaxwell>
sdf_0010: he's right, and I agree in general without agreeing in this case.
< BlueMatt>
just like we merged the segwit code without activation flags on
< gmaxwell>
sdf_0010: We will not ship software that we know will screw people over. It is unethical and unprofessional to do so. Our duty of care is to ship things we have validated and believe in.
< BlueMatt>
there was no way to turn it on on mainnet (afair), but the code was all there
< sdf_0010>
this requires people to explicitly set the configuration option that they want. I can already set flags now that would 'blow up my face' ,ie change the default listening to higher than needed
< gmaxwell>
sdf_0010: Though in this case AFAIK it's a bit special in that it's FINE unless other people don't use it. So basically the only argument where it would be unsafe (and quite unsafe indeed) is if its support isn't overwhelming. Yet we believe support for the underlying feature is overwhelming.
< gmaxwell>
sdf_0010: better example is you can set dbcache higher than the amount of ram you have, and you'll crash.
< BlueMatt>
sdf_0010: do you believe we should have an option that sends your private keys to me for analysis?
< gmaxwell>
or you can set your fee levels really stupidly high.
< gmaxwell>
but thats about as close to a suicide button as I think we get.
< sdf_0010>
BlueMatt, are you evne trying to engage me with in a genuine manner?
< gmaxwell>
BlueMatt: but what say you to the point that other people would LOVE to act as that symmetry breaker, but they're hobbled because our community is the software folks?
< gmaxwell>
sdf_0010: he is, don't be fragile. :)
< BlueMatt>
sdf_0010: I was eggagerating slightly to highlight the type of issue here
< gmaxwell>
sdf_0010: bluematt wants to do the right thing, it's not a personal dispute. Don't take it that way.
< sdf_0010>
asking rhetoical questions and pretending they are equivalent to my example is highly idiotic behavior or trollish
< BlueMatt>
gmaxwell: i interpreted that to also be a "software credibility" issue, to which I'm happy to provide credibility by reviewing the code and even merging it behind ifdef comments
< gmaxwell>
achow101: pm me an email address and I'll share the contact sheet I used for segwit outreach.
< sdf_0010>
and i do believe he isn't stupid, but pretending my exmaple and his are equivilent is purely idiotic
< BlueMatt>
sdf_0010: actually, I believe they are highly analygous
< sdf_0010>
haha
< BlueMatt>
sdf_0010: maybe a better comparison is a flag to run bitcoin core on testnet but have everything pretend to be mainnet
< BlueMatt>
i assume you can picture the "how to install bitcoin core" guides where someone tells you to use that flag and then they'll tell you you've been paid
< BlueMatt>
with valueless coins, but you are nonethewiser
< BlueMatt>
gmaxwell: if that is insufficient, then we should revisit the issue at that point, I believe
< gmaxwell>
BlueMatt: so you would draw a line at ifdef vs a config option even if the config option was labeled with a big warning sign? You know we do have other dangerous options for deployment reasons, e.g. invalidateblock
< BlueMatt>
i dunno, that line is fuzzy, I'd be ok with a configure option that prints a few sentences at you and then makes you wait and then type "yes" to continue :p
< sdf_0010>
BlueMatt, that is a better example except the part where people 'pretend' because unless you really believe the people setting this config option are utterly unthinking beasts I don't see how thye would be 'pretending' anything by setting a behavior they explicitly want
< BlueMatt>
sdf_0010: users are not unthinking, but they, the vast majority at least, do *not* have more than 30 seconds to consider the issues you consider fundamental for them
< 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.
< BlueMatt>
sdf_0010: if you're not modelling your users as drunk, you're probably doing it wrong, because the reality is most of your users dont know what the fuck is going on when they first install the software, they're installing it as a part of trying to figure that out, and your software shouldnt make it easy for them to needlessly harm themselves because someone on reddit told them to set flag X while your users are still figuring out wth
< BlueMatt>
bitcoin even is
< luke-jr>
gmaxwell: partial adoption is happening regardless though
< 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>
if it's (say) 5% then it's just bad for the BIP148 users.
< morcos>
The fundamental underlying question is what is the goddamn hurry? If the community really supports a UASF for segwit, there will be ample time for that to become clear and us to design the best mechanism possible to roll it out.
< morcos>
BIP148 is essentially hot off the press, and we're already trying to merge it
< gmaxwell>
morcos: +1
< morcos>
This is premature by at least 6 months, if not a year
< gmaxwell>
morcos: we'll be 'we' you mean like luke. :P
< BlueMatt>
yea, that too
< morcos>
well, i just think it shouldn't even be a conversation at this point (about merging). Debating the overal merits makes sense
< luke-jr>
morcos: BIP148 is 2 months old, and IMO better than any hypothetical alternative; anything else will require a redeployment
< gmaxwell>
yea, I think it's useful to talk through it.. thats how you get to maturity 6months henceforth, as you suggested.
< gmaxwell>
luke-jr: as I've said before, you're really overvaluing the redeployment cost.
< gmaxwell>
Yea, sure, it'll cause developer effort but thats what we signed up for.
< luke-jr>
gmaxwell: I don't think I am. Consider how much additional work segwit required that we didn't anticipate.
< BlueMatt>
yea, luckily the parameter space here is rather well-defined and somewhat limited, so its not a particularly extended discussion, I'd hope
< gmaxwell>
luke-jr: no it was several months later than idiotic estimates.
< gmaxwell>
If you reacall I was pointing out those estimates were absurd in january.
< gmaxwell>
Did you not even listen to the example I gave you earlier about 4 byte ASNs in BGP? It took a _decade_.
< BlueMatt>
*ahem* IPv6 *ahem*
< gmaxwell>
(and FWIW, from a software implementation perspective, 4-byte was pretty similar to segwit support-- even the underlying mechenism would remind you a little of segwit)
< BlueMatt>
did you....segregate the last 2 bytes :p
< gmaxwell>
BlueMatt: well kinda, for 4-byte ASNs the traditional AS path gets placeholder ASNs in it, and then an extension field carries the real AS path data.
< luke-jr>
AFAICT that analogy is about segwit, not BIP148
< gmaxwell>
But the history there was: discussion in 2000. Initial proposal of the idea in 2001. RFC in 2007. Implemented in routers in 2011. First turned on the internet in 2012 (then, due to subtle design flaws, it partioned the internet and required hasty fixes. :) )
< gmaxwell>
luke-jr: sure but BIP148 is about segwit.
< gmaxwell>
It's about getting segwit deployed faster.
< luke-jr>
BIP148 is about segwit, but BIP148 itself is very simple
< gmaxwell>
yea, BIP148 is very simple, I agree.
< 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.
< luke-jr>
then why didn't we set the timeout later?
< gmaxwell>
even in protocols with far less demands than ours-- like BGP for example-- upgrades take a long time.
< 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>
No one thought through that for segwit (unlike most SF) it's a bit harder to just renew. Ooops.
< achow101>
gmaxwell: but to keep renewing it requires everyone to upgrade yet again
< gmaxwell>
if not for that I think we'd already have a renewal staged in master.
< gmaxwell>
achow101: yea so? they're going to do that anyways... if you're running 3 year old software you're probably having a poor time from security issues or whatever. :)
< 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: no one has to run BIP148.
< luke-jr>
gmaxwell: a non-trivial amount of the community will be doing so
< * BlueMatt>
goes back to work
< Anduck>
we see huge support (and compatibility) for segwit in the nodes network. bip-148 wouldn't disrupt them if it forces miners to activate SW. it's a leap of faith in any case.
< * morcos>
hopes BlueMatt figures out his address problems
< BlueMatt>
morcos: ugh, i started looking at other node behavior and then got distrcated by bullshit
< 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
< Anduck>
so there's quite a big active community who would then switch on it, and maybe cause a disruption. but it's then up to the community if they choose to cause this disruption or not
< Anduck>
and if all goes as planned, there won't be disruption and miners will bend. it's risky, but it's up to the users
< 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>
but this is all reality, i think. have to accept the community knowledge level and do kind of "compromise". power users/devs/companies will always be in charge of the protocol anyway, simply because 95% of users (community?) do not care
< Anduck>
bgp is not comparable to bitcoin because there's no competitor. nobody gains anything if they get bgp replaced by something else
< 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
< lichtamberg_>
As far as I can remember there was also a toggle option for the RBF feature.... And now you want to decide for the users what it's best?
< lichtamberg_>
I cannot understand why there is such a strong stand against a toggle option...
< lichtamberg_>
On one side you are asking for more community participation, and on the other side you are dismissing one of the biggest community movements which bitcoin ever had..
< 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>
in a sense, it's irresponsible to give user an option to fail horribly.
< lichtamberg_>
it's also irresponsible to remove the option if the community support is getting enough traction
< lichtamberg_>
you are only thinking about the failing part… but look on reddit
< lichtamberg_>
a not so small part of the community will go this way
< 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 as far as I know, this is the biggest community movement which we ever saw until now?
< Anduck>
like, should core offer the best and safest product available and have no comment in ANY kind of protocol updates?
< Anduck>
i think it could be an option. drop all updates from core and have a different branch, maybe "core experimentals" project or something like that. updating protocol becomes tons of harder this way, but also clarifies the roles
< 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>
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.
< Anduck>
but anyway, the current system is quite good. these are just some ideas to clarify things for the future. there are tons of things to consider but maybe the process should be started soon as updating (and even maintaining) protocol becomes harder and harder in every level
< luke-jr>
Anduck: in this case, it's not "no comment", it's actively anti-BIP148.
< Anduck>
or pro-no-disruption-to-the-system ?
< Anduck>
segwit masf was defined as only activated if miners choose so. it's disruption to change this now
< luke-jr>
Anduck: nope, Core's current anti-BIP148 position increases the disruption
< Anduck>
no matter how sane it would be if it wasn't so disruptive
< Anduck>
luke-jr: well, that's an opinion only. there are tons of factors to consider --most of them are unknown.
< Anduck>
which is why i am trying to push this "nobody knows for sure, so let community find it out, even if it's via try-and-error or some other suboptimal method"
< Anduck>
what i mean by "noboy knows for sure" i mean the things which are simply not measurable in any way, or not analyzable objectively
< 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… :)
< Anduck>
"If all core members would support BIP148, we could do it really easily" << i disagree.
< lichtamberg_>
i disagree with your disagreement :D
< lichtamberg_>
we have so much support for segwit
< lichtamberg_>
there is such a big hype about UASF
< lichtamberg_>
the only ones which are missing are: the miners (obviously) - and core
< Anduck>
could be that you're right. could be that you're not. i think hype for bip148 is largely hype only.
< Anduck>
reddit is only one small piece of the community.
< lichtamberg_>
hard to measure that, but I dont think so
< Anduck>
i don't see big companies supporting uasf either
< lichtamberg_>
they are just scared to be the first one… first mover effect..
< Anduck>
anyway i think it should be nobodys job to even try to measure these things. just lay out the options, carefully mark what everything is and what implications whichever code has (as best as possibly one can, and as objectively as possible ofc)
< Anduck>
big warnings. if people ignore it... well, that's simply too bad! worse would've been if people had no option to do the stupid thing, as there would then be party who ONLY offers the bad options
< Anduck>
we've already seen signals about this phenomenon
< Anduck>
not only in bitcoin scene, that is
< lichtamberg_>
yeah i dont know.. i hope that some of the core members are still continueing to contribute to the current process.. at the moment they are cowardly silent unfortunately… (i dont know whats happening behind the doors) - but at the moment core is letting the community alone from my point of view