< bitcoin-git>
[bitcoin] promag opened pull request #11316: [qt] Add use available balance in send coins dialog (master...2017-09-add-use-available-balance) https://github.com/bitcoin/bitcoin/pull/11316
< esotericnonsense>
er, this seems like the most reasonable place to ask, apologies if not - what's the deal with slack.bitcoincore.org?
< esotericnonsense>
(or bitcoincore.org in general; is it endorsed?)
< achow101>
esotericnonsense: bitcoincore.org is the bitcoin core's website
< achow101>
the slack channel is Bitcoin Core's slack channel. It's mostly for random shit, not development
< achow101>
go there for laughs and trolling
< esotericnonsense>
slack is invented for random shit
< * esotericnonsense>
is currently trying to figure out the irc gateway to avoid falling into the trap of pressing the meme buttons
< esotericnonsense>
:) thanks
< gmaxwell>
17:54:01 < achow101> the slack channel is Bitcoin Core's slack channel.
< gmaxwell>
No it is a _community_ slack which is almost completely unused by actual developers.
< gmaxwell>
I know you and luke use it, most of the developers do not.
< gmaxwell>
A wish btcdrak would close it, it has caused a lot of drama and harm.
< StopAndDecrypt_>
gmaxwell, difference between this and #bitcoin-dev ?
< gmaxwell>
it was created against active opposition by a number of developers.
< esotericnonsense>
it is currently breaking my irc client enumerating the 6000+ users in every chat
< sipa>
#bitcoin-dev is about bitcoin; #bitcoin-core-dev is about development of one specific software project
< achow101>
gmaxwell: it was created by an admin of bitcoincore.org
< achow101>
it is arguably created by "Bitcoin Core"
< gmaxwell>
StopAndDecrypt_: We used to use bitcoin-dev. Then one day Mike Hearn was a real jerk, in particular faulting wumpus for being 'indecisive', wumpus told him to cut it out, mike kept it up. Wumpus banned him. (so much for indecisive). Then out of nowhere jgarzik, who for who knows what reason still had access, unbanned mike hearn. So most of the developers simply left.
< gmaxwell>
sipa: I don't think thats fair to say, -- a channel for bitcoin that hardly has any of the most active people isn't much of one.
< esotericnonsense>
i've disconnected now because it basically dosed my irc bouncer, that was shortlived
< meshcollider>
yeah that was the first channel I joined, but its pretty inactive, that's why sipa pointed me to this one instead
< gmaxwell>
it's confusing to people for sure. It's not completely inactive though, a while back I was going to close it down if it went a week with no discussion but it didn't quite make it.
< esotericnonsense>
my interpretation was that this channel was for direct work on the bitcoin codebase whilst bitcoin-dev was for general bitcoin-related development e.g. wallets, merchant integration, etc
< esotericnonsense>
but yeah, it's pretty dead in there
< gmaxwell>
esotericnonsense: it can't be that without the most active developers involved, and at the time people with admin access there were behaving disrespectfully to these people. (Access is since changed.) None of us have much interest in wheel warring, if a venue has become unproductive for us to use, we won't use it. For something like a bitcoin tech discussion if the most active of the tech peo
< gmaxwell>
ple leave, it's going to die.
< esotericnonsense>
indeed
< gmaxwell>
There is this open venue toxic culture problem, where people will show up and behave abusively, and if you kick them out it's ZOMG CENSORSHIP but if you don't kick them out, competent people just won't bother with the place and thus it eventually dies.
< gmaxwell>
big reason I opposed the slack, beyond it being a commercial propritary venue and primarily web only, is that it was creating yet another venue where either your tolerate abuse or suffer drama when you punt people.
< aj>
slack's theoretically a bit more friendly to less technical people than irc, so i kinda liked the thought for that, but i think they're all secluded in private dragonsden channels or whatever now leaving the public ones for full-time drama
< sipa>
i think it's fine for communities to use slack as a medium if they like to do so... i just don't think it should be 'officially' bitcoin core's slack
< aj>
yeah... when it was started the meme it was trying to address was "core is great, it just doesn't communicate well", but without dev participation slack doesn't really solve that problem much...
< gmaxwell>
aj: we should have just put embedded web irc links on the site. e.g. the webchat link at the top https://opus-codec.org/development/
< gmaxwell>
arguably web slack is nicer, but it would avoid fragmenting the community.
< meshcollider>
why not remove the slack from the site then?
< gmaxwell>
ACK
< meshcollider>
btcdrak will not like that though
< StopAndDecrypt_>
anybody who needs to communicate and has value to contribute would know how to at least establish contact
< StopAndDecrypt_>
communication isnt difficult, its a litmus test, i dont even code
< aj>
gmaxwell: plus a link to the botbot archives; it'd only miss out on push notifications then
< aj>
meshcollider: the website's managed by github, a pull request with a bunch of dev acks seems like a reasonable thing to do to me
< meshcollider>
drak is like lead maintainer of that repo though isnt he
< gmaxwell>
StopAndDecrypt_: well we also want to talk to users! and some aren't going to figure out how to get on IRC. I think the freenode webchat is sufficient.
< aj>
meshcollider: yeah; wumpus is lead maintainer of the bitcoin repo, doesn't mean either of them don't care what other people think
< instagibbs>
bitcoincore.org is mostly a venue for posting FAQs, blog post versions of announcements for releases and the like
< StopAndDecrypt_>
gmaxwell, well yeah, there's people who want to reach in, and then there's reaching out for feedback. reddit helps, but nobody should feel obligated to post on reddit, especially when a lot of it is just to dismiss some wild claim being made. it's helpfull though.
< CodeShark>
the Core slack is a necessary outlet for shits and giggles...and a tremendous amount of great comms have taken place there, albeit not always in the general chat channel
< CodeShark>
I have been able to get a hold of a LOT of people through that Slack that would not come on IRC
< CodeShark>
most of it via other channels or private chats
< CodeShark>
without it it would have been near impossible to coordinate several important efforts
< gmaxwell>
CodeShark: I think it is toxic for our community. Case in point: people like you that we never see here, and yet many people think you are a high profile developer.
< gmaxwell>
Because of your much higher level of activity on the slack.
< CodeShark>
the communications are necessary
< CodeShark>
without them, people just make shit up...and it's often unfavorable
< CodeShark>
and there's a lot more to the Bitcoin Core project than just submitting pull requests and doing code review
< gmaxwell>
CodeShark: Which is why having the split is not acceptable.
< CodeShark>
I was working on my own Bitcoin implementation and codebase prior to this whole hard forking insanity and decided to volunteer most of my time to help Bitcoin Core instead. prior to that I use to come here more, but I realized that many people still needed basic information
< sipa>
sure, but why does that need to happen under the "Bitcoin Core" name?
< gmaxwell>
I'm thankful for your help but the lack of communication is a serious problem.
< CodeShark>
for better or worse that was the brand that people recognized. I would prefer people make the distinction between implementation and consensus rule definitions, but that's just not how much of the public perception works right now
< CodeShark>
have tried hard to change that, but there's tremendous resistance
< CodeShark>
FWIW, now that segwit is active I'd rather shift efforts back to building stuff rather than putting out fires
< gmaxwell>
That response is a bit shocking.
< CodeShark>
not sure what lack of communication you're referring to - you mean the fact I don't come here nearly as much as I did a couple years ago?
< gmaxwell>
Because what it sounds like is that the focus is actually a "bitcoiners for sanity" which then borrowed our project's name and reputation, but doesn't actually care to advance its positions or even communicate closely with it.
< CodeShark>
I try my best to keep abreast of important developments within Bitcoin Core and do my best to communicate them
< CodeShark>
and get paid $0 for it
< 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.
< gmaxwell>
So it's going to be an inevitable messaging circus when we do.
< CodeShark>
I wasn't the only one that carried that message
< gmaxwell>
I've been thankful for the positive contributions for sure! but the disconnection is a serious liability.
< CodeShark>
many contributors seem to feel that way
< gmaxwell>
let me guess, luke-jr. ... The slack needs to go away.
< CodeShark>
the slack is necessary as an outlet for people
< sipa>
CodeShark: the fact that you have that impressions and i don't probably means there is a communications failure :)
< CodeShark>
ok, then perhaps we can do more to fix that
< gmaxwell>
There appears to be a serious split brain problem.
< CodeShark>
it's hard to shift gears, sure
< gmaxwell>
I've spent time talking to some other people who are mostly in the slack and hearing radically different views on things.
< CodeShark>
I just saw Bitcoin Core viciously attacked a couple years ago and hostile parties form...and did whatever I could to communicate basic principles. it's impossible to get everyone aligned on all the details, but the priority was around trying to at least have a coherent overarching message
< sipa>
a message that includes "nobody wants a full mempool" ?
< CodeShark>
that was not my message...
< CodeShark>
but in the big scheme of things at this moment, it is a detail that is still hard to communicate
< gmaxwell>
I'm not criticising the helpful moves, but we can't afford a split brain.
< CodeShark>
I believe #bitcoin-core-dev should focus more on tech developments and code. we have other channels for things like media strategy
< sipa>
today seems to be an exception, the topic here is hardly ever about anything else
< CodeShark>
indeed - so if you want tighter coordination on other stuff I would suggest participating in these other channels more. I don't want to spam this channel with issues that are not directly related to engineering
< gmaxwell>
I don't think it's acceptable for the comms stuff to continue with virtually no input from the people actively involved with the software project, under the projects name.
< gmaxwell>
The liability is simply too great. Plus it's an outright misrepresentation.
< CodeShark>
you know how to reach me - I always value your input
< gmaxwell>
Permitting that kind of thing is 80% of why gavin turned into such a circus, we are making the same mistake again but scaled up.
< gmaxwell>
The fact that the people involved don't suck doesn't make it that much better. :)
< CodeShark>
I just wanted to build good products atop bitcoin and decided to support the Bitcoin Core project however I could because it's the most stable, most reliable, most secure implementation of validation and relay
< CodeShark>
I would prefer to continue building good products
< CodeShark>
I didn't ask for these other jobs
< gmaxwell>
In any case, I think my core ask is rally simple: lets end the splitbrainness. I'm not asking you to stop your advocacy, I'm generally thankful for it.
< sipa>
CodeShark: gmaxwell is not saying "CodeShark is doing a bad job"; he's saying "it's scary that there is a disconnect between these two communities"
< gmaxwell>
But if things are going to operate under the projects name they must be at least somewhat coordinated with the project contributors. Having a totally siloed comms enviroment makes that almost impossible.
< gmaxwell>
what sipa said!
< CodeShark>
ok, fixing this disconnect is a reasonable goal
< gmaxwell>
I think you've done an amazing job and considering how little communications there are I'm surprised that there have been so few wtf-is-he-saying events, a testament to your skills.
< gmaxwell>
yea! that is all I'm really going for.
< CodeShark>
in any case, there's going to be a tremendous amount of bullshit lobbed around - it's part of the curse of being one of the people who most knows about a subject. most of what you hear other people say about it is wrong
< CodeShark>
so it's important to set priorities and figure out what messages are most important to get out...and to just accept that there will be some noise no matter what
< CodeShark>
but I'm willing to do what I can to help improve this
< CodeShark>
most of the technical inaccuracies people lob around ultimately don't really have much of an impact because they aren't the ones actually working on the code
< CodeShark>
but there are some high level narratives that are key - such as the notion that changing consensus rules is inherently hard, incompatibilities that partition the network lead to chain splits, etc...
< 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
< CodeShark>
and that deterrents exist against hostile miners
< 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>
things can always change. I think the overarching goal here is to convey that users choose consensus rules, not miners. and bip9 sends conflicting messages
< CodeShark>
but if the situation changes, perhaps bip9 becomes viable again
< CodeShark>
I think we all agree that BIP9 for segwit caused some serious problems
< mryandao>
why not just run a XMPP bridge?
< gmaxwell>
CodeShark: I don't agree.
< 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.
< gmaxwell>
In doing it furthered a conflicting message. BIP9 was never 'miners choose'. It's just an activiation mechenism.
< gmaxwell>
And it's still by far the safest one.
< gmaxwell>
It can be delayed, but we should have a position that consensus rule changes take non-trivial amounts of time.
< CodeShark>
safe as long as miners don't use it to hold a popular upgrade hostage subject to insane shifting demands
< gmaxwell>
No. Safe even if they do.
< gmaxwell>
Segwit being activated in under a year is really really fast. It's much faster than major changes happen in widespread internet protocols that don't have consensus implications or the same consequences of failure.
< CodeShark>
I think we'll have to agree to disagree here. I believe ceding the narrative and going on the defensive was far riskier.
< gmaxwell>
No, I don't think we will. On this point I think my comments are reflecting the shared view of the project.
< gmaxwell>
(though obviously I haven't polled everyone for their latest views)
< CodeShark>
bip8 would have allowed the nya to dominate headlines
< gmaxwell>
Ah, no that isn't my point, my point is that slack communities narative about segwit delays was wrong from the start.
< gmaxwell>
NYA wouldn't have even existed if not for BIP149.
< gmaxwell>
We should have just taken a consistent position that delays are normal and expected and if miners won't activate something users near univerally want, too bad.
< gmaxwell>
NYA was specifically created to take BIP148's success and turn it into something else.
< gmaxwell>
On the plus side, it let us keep a narative high ground of not supporting hasty changes just because we're impatient.
< CodeShark>
tried that...but everyone was getting impatient for segwit activation and further revelations regarding some miner motives made status quo intenable
< CodeShark>
*untenable
< gmaxwell>
that was a direct response to the slack echo chamber.
< CodeShark>
I believe a chain split was imminent. We got BCH
< 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>
Again, a direct response to BIP148 (they even said so in the announcement! :) )
< gmaxwell>
If there hadn't been that community schism people wouldn't have been left with any doubt that it would get activated.
< CodeShark>
probably the best possible outcome we could have gotten
< gmaxwell>
Regardless of hindsight, there has been significant miscommunication and misunderstanding which is avoidable.
< CodeShark>
it was mostly about empowering users over miners when it comes to consensus rule changes
< CodeShark>
but sure, perhaps we can do better in the future
< OdaNobunaga>
I've been following the various the "bitcoin core" slack on a daily basis (mostly its various UASF channels) since last March, and I think that there's a lot of amplification going on, but at the same time the most vocal contributors there are well aware that they're an extreme minority and that they can't possibly have everything go their way; I w
< OdaNobunaga>
ould say that part of that amplification is kind of self-deprecatory.
< OdaNobunaga>
But the I've been surprised to see it being called "the bitcoin core slack" as the discussion there mostly isn't technical, and its biggest contributors aren't core devs
< OdaNobunaga>
So yeah the slack may have a branding problem
< gmaxwell>
I tried before to get it braned as the NotBitcoinCore slack. :)
< OdaNobunaga>
I think that if we want the discussion there to remain mostly unmoderated, it will fatally remain troll-heavy, and so devs/sensible people won't use it too much
< gmaxwell>
but even absent the branding problem, it still has the problem of splitting the community. :(
< CodeShark>
I would like to give a name to the movement that favors the conservative approach to consensus rule changes and general avoidance of incompatibilities unless the technical benefits greatly outweigh the costs...and to distinguish it from the Bitcoin Core FOSS project
< OdaNobunaga>
So it can either be a meme echo chamber or a serious place for discussion
< CodeShark>
but it's been very hard to do this...and for the time being we were fighting a common enemy
< OdaNobunaga>
On the Slack we kind of call that the "user driven" bitcoin (I've seen that being used a few times)
< gmaxwell>
OdaNobunaga: IRC has many channels.
< gmaxwell>
many of the developers are usually in #bitcoin.
< OdaNobunaga>
CodeShark: Yes, there should be a name for this movement, I absolutely agree.
< OdaNobunaga>
Perhaps there could be different moderation rules for different channels on the slack
< gmaxwell>
please get bitcoin core's name off it before doing anything else with moderation... so tired of being blamed for moderation actions in stuff we have no control over.
< OdaNobunaga>
gmaxwell I agree
< gmaxwell>
FWIW, I think if someone wants to create new low noise venues the right way isn't with moderation, but invite-only write access.
< gmaxwell>
The hysteria about people being blocked comes from a false expectation that they have a prior right to say whatever they want. I have a weakly tested hypothesis that this issue doesn't exist for venue were ability to post isn't automatic.
< CodeShark>
gmaxwell: FWIW I vehemently opposed much of the moderation policy that took place there...but just found ways to work around it. now that segwit is active on mainnet I think we have more options here
< CodeShark>
perhaps a rebranding is in order
< gmaxwell>
which would still leave us with a split community. Why is it that you don't see this as a problem
< CodeShark>
depends on how it's done
< CodeShark>
I see the Bitcoin Core software project as part of a wider movement
< gmaxwell>
one which you seem to be interested in usurping by using our name, to be blunt.
< CodeShark>
not at all
< gmaxwell>
That how its playing out.
< OdaNobunaga>
I agree with gmaxwell, it's hard to see what the slack has to do with bitcoin core
< CodeShark>
I have barely been in the slack recently
< gmaxwell>
In one week in 2011 the dev channel here had 191 distinct after talkers, last week it had 52. There is a direct decline in participation by different parties on IRC correlated with the introduction of the slack.
< gmaxwell>
(I just picked the first week in the top of one of my 2011 logs)
< OdaNobunaga>
CodeShark: Perhaps we should come up with a word to refer to the "decentralisation first"/user-driven/cypherpunk movement within bitcoin, and rename the slack after it
< CodeShark>
gmaxwell: I think it was just a temporary situation
< CodeShark>
crisis mode
< gmaxwell>
OdaNobunaga: the whole thing is the _fking_ bitcoin project, dude. Bitcoin.
< CodeShark>
but not everyone agrees on what Bitcoin is
< gmaxwell>
The software project here is the _bitcoin_ project, Bitcoin core is the name of the reference client, it's not the only thing the project does.
< CodeShark>
I could have used my company name instead to promote crap - but I wanted to help the Bitcoin Core project. this isn't about me
< gmaxwell>
So what you're doing, ape with ak47 style, is setting up a schism between the people working on the system, who've been the same people working it since 2011... and a newer community in a different venue that excludes most of those folks.
< gmaxwell>
It's all largely okay now, but it's a bad setup.
< gmaxwell>
It's basically asking for gavin like drama squared.
< gmaxwell>
You've said that you respected my opinion, but I've raised these concerns many times.
< CodeShark>
I would prefer to step back from this role and work on building shit
< CodeShark>
but until I stepped into it, we had people like roger dictating narrative
< gmaxwell>
This seems to be unrelated to my comments.
< CodeShark>
not sure I understand your critique
< gmaxwell>
It isn't a complaint about you, it's a complaint about the split community and the insistance on keeping it.
< CodeShark>
ideally we could separate implementation from consensus rules from the sociopolitical movement
< gmaxwell>
lets imagine for a moment that roger ver ran that slack... and wasn't, so far, doing anything with it... just letting it be. Would you not be concerned that _the_ meeting place for all those people was in his hands?
< CodeShark>
for better or worse, it all sort of concentrated around the Bitcoin Core project because that's where the best protocol experts were
< gmaxwell>
CodeShark: yea great, so you're basically trying to setup the "sociopolitical movement" that doesn't include its longest standing members.
< CodeShark>
no, far from that
< gmaxwell>
As far as I am concerned: It is the _bitcoin project_. As far as I am concerned there is no bitcoin core project. Bitcoin Core is a piece of software.
< CodeShark>
the higher the stakes, the more people will try to divide us
< gmaxwell>
... why would they have to, 'we' seem to be dividing ourselves just fine, and you seem to be insisting on preserving the divide.
< CodeShark>
how?
< gmaxwell>
"ideally we could separate"
< CodeShark>
but we can't get everyone to agree on everything
< CodeShark>
the best we can do is get them to agree on some basic stuff
< CodeShark>
and that's even asking for a lot
< gmaxwell>
That doesn't have anything to do with getting rid of the split community venues or not.
< CodeShark>
trying to force people to stick together even if they disagree is unhealthy, IMHO
< CodeShark>
there are different economic interests, different visions, different understandings (and there's also a lot of FUD)
< CodeShark>
about the best option we had to keep the network together is to help promote the Bitcoin Core project since it is by far the most responsible and most reliable when it comes to avoiding consensus failures
< gmaxwell>
So you are trying to say that the slack disagrees with the community here and most of the people actually writing the software and supporting it all these years?
< CodeShark>
most of the disagreements are ultimately immaterial, IMHO - there's a strong alliance in terms of overall general vision and philosophy
< CodeShark>
perhaps the branding is still an issue
< OdaNobunaga>
During last spring and summer the mood on the slack was "Core is too soft", "merge UASF already", but overall they support the vision of core devs
< gmaxwell>
Who knows if they do.
< gmaxwell>
Since the communication isn't actually there.
< CodeShark>
I think I've had good communications with many of the people who have been in the Slack
< OdaNobunaga>
If we're talking public relations and community mood, it's what's being said publicly that matters
< CodeShark>
and I agree with OdaNobunaga's assessment
< gmaxwell>
CodeShark: yes with _YOU_. You whom we were already criticizing for being a bit disconnected!
< CodeShark>
you know how to get a hold of me
< gmaxwell>
I know how to speak to a brick wall too.
< gmaxwell>
Both currently appear to be acomplishing about equal amounts.
< CodeShark>
I'll be totally blunt here - I deeply respect your domain knowledge and breadth of understanding and have learned tremendously from you...but I also strongly disagree with the public relations strategy the Bitcoin Core project had a couple years ago
< gmaxwell>
OdaNobunaga: point there being that they might not have actually been saying those things if they would like, you know, actually talk to people. I recently had a long conversation with someone who has mostly been on slack for the past couple months and there was a lot of mutual surprise at what people were thinking.
< gmaxwell>
CodeShark: if you "strongly disagree" then you have no business using our name and speaking for it.
< gmaxwell>
That is just dishonest.
< CodeShark>
I always say I'm speaking for myself
< CodeShark>
when it comes to controversial issues
< CodeShark>
and I always try to give credit to all the top contributors as best as I can
< CodeShark>
I have invested FAR more of my time promoting Bitcoin Core than Ciphrex in the last two years
< CodeShark>
and get paid nothing for it
< CodeShark>
using the name was because otherwise what am I promoting? for better or worse, the Bitcoin Core project was where the greatest protocol expertise was concentrated
< 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
< CodeShark>
perhaps BIP9 will be used again - but for now, BIP9 feels very demoralizing to many users
< CodeShark>
it makes them feel powerless against hostile miners
< OdaNobunaga>
So yeah there's not a very good communication between core and the venues on this issue (and other protocol level issues)
< CodeShark>
the technical details of activation mechanisms took a back seat to giving users more of a voice
< gmaxwell>
CodeShark: your uncoordinated comments on that will _directly_ goof up efforts to do otherwise. Instead of having a consistent, empowering, position, we're now forced into a mess.
< CodeShark>
howso?
< 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>
actively alienating people doesn't help either, gmaxwell
< gmaxwell>
Splitting the community does exactly that!
< CodeShark>
especially people who have proven helpful, even if they don't always agree on everything or even understand everything
< CodeShark>
it wasn't me who split the community
< CodeShark>
I did everything I could to help heal it
< CodeShark>
including traveling around the entire world at my own expense to talk to all the major players
< 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>
what.. no you're confused about what I meant there.
< gmaxwell>
By splitting the community I mean creating a parallel and seperate Bitcoin Core chat community and directing traffic there instead of where the actual bitcoin project people are.
< gmaxwell>
Thats the split I'm referring to.
< CodeShark>
I think drak is the one you need to talk to ;)
< gmaxwell>
It results in not having a consistent and widely understood set of expectations about how things progress.
< gmaxwell>
You're the one that showed up here vigorously arguing not to fix it, which is why it's you I'm arguing with. Not otherwise!
< CodeShark>
I'm just a guest like anyone else on the Core slack
< gmaxwell>
OdaNobunaga: Tables don't replace actually talking to each other.
< gmaxwell>
:)
< CodeShark>
I have no moderator privileges, do not administer it in any way
< gmaxwell>
OdaNobunaga: you don't learn that people are in no way timid from a table. :)
< OdaNobunaga>
Yeha I'm thinking more of a kind of wiki of devs' opinions and debates than a table
< gmaxwell>
OdaNobunaga: well the debates are mostly on IRC, you're welcome to also join them! :)
< OdaNobunaga>
Perhaps I could work on something like that
< OdaNobunaga>
Yes of course, but even the enlightened hodler would probably want something more simple and less time consuming than following the debates, perhaps we need a layer of vulgarisation and popularisation between these debates and the general public
< gmaxwell>
OdaNobunaga: absolutely. well in theory thats what industry press is supposed to do.
< OdaNobunaga>
Yeah but I think it's too low granularity and doesn't transcribe nuances well
< CodeShark>
there are very few good journalists out there - they usually go with whatever story they are first presented with and don't do much research
< OdaNobunaga>
Though I would love to see Bitcoinmagazine doing something like that
< CodeShark>
it takes a proactive approach to make sure they use good sources
< gmaxwell>
CodeShark: I'm not trying to show any lack of thanks for your help; But I am very concerned with the ongoing splitting and isolation created by having this core slack with few people active in core around it. That isn't your doing, but you started the conversation defending it... so thats the only reason I'm arguing with you about it.
< gmaxwell>
CodeShark: sorry if I made you feel unappricated. But your comments also did the same to me; e.g. not showing understanding of my concern, and seemingly being okay with isolating the "sociopolitical movement" from me, because apparently I'm guilty of the crime of being a bit fluent in software. :)
< CodeShark>
I think it's good for there to be forums where people can discuss stuff that isn't necessarily deep down in the code and can congregate for the sense of feeling as part of a larger community
< CodeShark>
or if not good, at least a necessary part of the human condition
< CodeShark>
and fighting against this is fighting against human nature
< gmaxwell>
Good thing I never said anything of the sort!
< gmaxwell>
There are dozens of non-technical bitcoin channels on IRC-- ones that also get participation from many of the longest standing bitcoin users and technical contributors too.
< gmaxwell>
My interest in Bitcoin is primarily political, the same is true for (I assume) most of the technical contributors.
< gmaxwell>
The greatest insult rbtc uses against me is "You're a great coder."
< CodeShark>
I'm not trying to say you should only focus on code. on the contrary, I think you're a great source of inspiration to the movement when you do things like give public talks or write good blog posts
< midnightmagic>
God I hate reading that one..
< CodeShark>
I think you should write more blog posts and give more talks and do more videos and interviews and argue less on reddit ;)
< gmaxwell>
Too bad hundreds of people never get to talk to me because they've been siphoned off into a Bitcoin Core chat group that I'm not in.
< * midnightmagic>
randomly hugs everybody
< CodeShark>
gmaxwell: you chose not to participate in that slack group
< gmaxwell>
I choose to not screw over my community by personally contributing to the split!
< midnightmagic>
Each individual, non-correlatable channel of communication divides attention from the others. :-( I would argue it's not much of a choice anyway due to the security implications in Slack.
< midnightmagic>
*gently and with good cheer argue
< intcat>
gmaxwell: nobody is preventing you from joining the slack, you can even do it with an irc client ;)
< gmaxwell>
03:57:35 < gmaxwell> I choose to not screw over my community by personally contributing to the split!
< intcat>
meanwhile people like me who prefer connecting to irc over tor so as to not expose IP to anyone lurking in bitcoin-related channels and suffering frequent disconnects as a result cant unfortunately follow all discussion here
< gmaxwell>
And trying to move everyone there wouldn't be realistic or wise, because web chat is really hated by many people; and because it's a commercial platform with an unknown lifetime, which might well just decide to sell that slack to ver tomorrow for all we know, and all the other assorted issues.
< gmaxwell>
intcat: you can plumb your tor circuts through more reliable nodes to reduce that problem FWIW.
< gmaxwell>
I've generally found that in most interesting channels there is far too much volume to read the backscroll in any case, you can just read the last bit and get linked things as needed.
< midnightmagic>
intcat: The IRC bridge fails to post updates to comments. At best, it is a dim and opaque link into the slack chat.
< intcat>
midnightmagic: i suppose... if the argument is about being excluded from conversations its better than nothing though
< midnightmagic>
intcat: There are ways of achieving reliability over Tor but your latency suffers a lot. :-(
< * esotericnonsense>
feels like this isn't an issue unique to the current situation, there must be other examples of where slack has reduced participation by developers
< esotericnonsense>
you would see similar effects if you had say a reddit /r/bitcoincoredev group vs. a mailing list or a usenet group, i personally just don't feel it lends itself as readily to constructive discussion
< esotericnonsense>
not because of the audience, more the sort of 'social norms' that evolve as a result of the interface itself
< molz>
gmaxwell, the Core slack has bridges to this channel and #bitcoin-dev, many people on the slack read these channels and more informed of what's going on with the development than you know, and if not for the slack, these people would never join IRC or know what's going on with the bitcoin development
< esotericnonsense>
why are the ircc bridges are omnidirectional? is it a restriction in slack itself or was that chosen?
< esotericnonsense>
argh. why are the irc bridges omnidirectional*
< gmaxwell>
molz: that kind of thing doesn't work, there are incredible misconceptions that come from just not talking. As far as never find it... http://webchat.freenode.net/?channels=bitcoin works pretty well for public chat.
< gmaxwell>
molz: and clearly they often _don't_ know whats going on, since getting glimpses of a highly technical channel, just isn't the same as joining people for casual chat.
< molz>
gmaxwell, what would you suggest? you want to close the core slack and force everyone to join IRC? the only channel they can talk is #bitcoin but even that channel is not for everything one can discuss
< gmaxwell>
molz: there are lots of channels, and people can create more. As far as what I suggest, I don't know, thats why it's a discussion-- but I think the current situation is double plus ungood.
< molz>
gmaxwell, i'm a long time IRC fan, and i can appreciate what IRC can do, i still suggest people to seek tech help on IRC if no one can help them on the slack, but there's one thing i've noticed: not many people like being on IRC with just tech
< molz>
s/tech/text
< Chicago>
Excuse my cynicism, but I look at Slack the same way as systemd. They both fit a need for some people but are being overwhelmingly adopted and pushed out to the masses as the one true way, needlessly. No doubt if you want to capture new eyeballs, its hard to avoid Slack -- but if people are taught how to use an IRC client, they tend to use it rather than the freenode webchat interface.
< meshcollider>
fwiw I agree with gmaxwell, and I appreciate the newspeak reference ;)
< meshcollider>
esotericnonsense: do you mean unidirectional?
< BashCo_>
Okay I've read the past several hours of scrollback, minus some missing chunks due to flaky internet and IRC's inherent lack of persistent messaging. Despite this, I'd like to share my opinion on the matter of disjointed yet supportive communities on separate platforms. I'll preface this by saying I'm more active on Slack than on IRC.
< BashCo_>
The 'Core' entity is bigger than just developers. Thankfully it is filled with a lot of supporters, many of whom find IRC inaccessible and unengaging. They use Slack because it provides a modern interface accessible on various platforms, including mobile.
< BashCo_>
Slack offers message persistence without the hassle of an IRC bouncer, and superior media integration. Freenode webchat and desktop clients are woefully inadequate IMHO. Plus the privacy implications of using freenode, which automatically shares your IP address unless you research how to request unaffiliated.
< BashCo_>
For end users, Slack provides a better experience hands down. It's not intended primarily for developers, but for community members, although devs are strongly encouraged to pop in every once in a while. I do wish that there was an equivalent FOSS solution.
< BashCo_>
https://rocket.chat is pretty comparable to Slack and open source. It would require hosting and maintenance, and we would need to migrate the Slack userbase which is not impossible.
< BashCo_>
The reason for the decline in IRC participation is likely because it's seen as an outmoded form of communication. It has its strengths, but they do not outweigh the benefits provided to end users on modern platforms.
< BashCo_>
I'm also puzzled by the notion that the Slack channel is bad for the 'Core' brand. Sure there was some some silly dragonsden drama, but most people saw that it was basically fabricated. Dragonsden has actually morphed into a meme that some people are proud to be a part of. Really the channel just provides a better signal-to-noise ratio.
< BashCo_>
If you think the Slack is toxic for our community, then I think you're missing out on a lot of great interaction, and that perspective is short-sighted IMO. Furthermore, I don't see any proposed solution beyond attempting to herd 6000 accounts into this dev channel (dev channel, not community channel. topic encourages observation.). Good luck conducting weekly dev meetings with all that noise. Imagine if all of reddit/Twitter ha
< BashCo_>
ppened on github/mailinglist.
< BashCo_>
Lots of talk about communication problems, but the reality is that Core devs have a massive audience that several devs are not embracing simply because the audience prefers a platform that mets their comfort standards. If Slack has inaccurate information, it's partly because devs are choosing not to engage with that audience. Go to the audience.
< BashCo_>
The 'split communities' (IRC/Slack/Twitter/reddit/etc) are a simple reality that we have to come to terms with. Maybe it's unfortunate that 'Core' is in the Slack team name, but plain 'Bitcoin' is apparently being squatted. Even that would not solve anything since most people will still prefer Slack over IRC. /sorryforflood
< pigeons>
I don't buy the non-technical users don't like irc thing, look at DALnet
< Chicago>
... and the minute an IRC based community capitulates to Slack, along will come the Slack killer and a new platform with another closed system and closed protocol will demand your participation.
< BashCo_>
I'm reasonably technical and I explained that Slack is superior in ways that are appealing to end users. The proprietary nature is unfortunate, hence my rocket.chat suggestion.
< bitcoin-git>
[bitcoin] sdaftuar opened pull request #11319: [qa] Fix error introduced into p2p-segwit.py, and prevent future similar errors (master...2017-09-fix-p2p-segwit) https://github.com/bitcoin/bitcoin/pull/11319
< sontol>
sorry to disturb you all
< sontol>
but I feel the need to defend Eric
< sontol>
(ironically I never used the slack, I just happen to see the convo in time)
< sontol>
I think it is really important to educate people on the hard facts
< sontol>
Even if that will result in something that you don't plan for (e.g BIP148)
< sontol>
gmaxwell: please don't act as if you're innocent in this case
< sontol>
had you kept mum about ASICBOOST and propose BIP149-like activation proposal animosity towards Bitmain won't go through the roof
< sontol>
and people would be calmer
< sontol>
I'd also appreciate it if the current contributors stop pulling the age card (I've been doing this longer than you so my opinion carries more weight)
< sontol>
That's the same trick that was pulled by Gavin's supporters
< sontol>
I'd worry that this same trick would be used against let's say Alex Morcos (sorry to use your name, just an example)
< midnightmagic>
not the best place for it, dude.
< MarcoFalke>
I feel like this conversation should be held in another place
< sontol>
yeah I know
< sontol>
normally I keep mum
< sontol>
but since this happen here
< sontol>
I feel it is necessary to bring it here
< sontol>
I will keep quiet
< sontol>
after this
< midnightmagic>
He's over in #bitcoin too, last I checked.
< achow101>
MarcoFalke: ah, I didn't realize wumpus might still be traveling
< bitcoin-git>
[bitcoin] dooglus opened pull request #11320: Include the wallet name in log messages relating to wallets (master...wallet_name_in_log) https://github.com/bitcoin/bitcoin/pull/11320
< BlueMatt>
BashCo: a large part of what led to the xt issue was people speaking "on behalf of the technical project" saying things that were 180deg from what people who actually contributed to the technical project viewed...148 is an example of what happens in situations like that, many people seem to still think that 148 was somehow connected to or pushed by core contributors, when, in fact, it was pretty much luke and a bunch of people in the
< BlueMatt>
"Core Slack" (which is not connected to Core)
< BlueMatt>
it is very dangerous for these things to coninute to be needlessly linked
< BlueMatt>
and the "splitbrain community" issues greg raised are also critical here - as the Bitcoin community grows Bitcoin becomes harder to change, and thats good, but it should not do so needlessly simply because parts of the community do not sufficiently communicate with other parts
< BlueMatt>
while I understand the migration from Reddit and IRC to some extent, pushing folks towards Slack has, in large part, simply added yet another disconnected venue for Bitcoin discussion, creating yet another fork of the community whcih does not sufficiently communicate with other parts
< achow101>
BlueMatt: I think that a lot of people on slack wouldn't be engaged in the community otherwise. I think many users find slack to be more user friendly than IRC with more features that they want to use (e.g. ability to post images)
< achow101>
s/the community/any bitcoin related discussion community/
< BlueMatt>
yes, there is a tradeoff to be made here
< BlueMatt>
I absolutely agree there is some value in it, but some active steps should be taken to a) make clear this is not somehow a community related to bitcoin core (the technical project) and b) try to enforce lack of splitbrain
< BlueMatt>
I dont know what all the steps are for b, but its something we should be cautiously aware of and try to address
< achow101>
It's hard to avoid splitbrain when there are multiple distinct communities
< OdaNobunaga>
It's been suggested (today on the slack) to rebrand the slack into something not connected to core, for example "bitcoincommunity" or something like that (the bitcoin subdomain of slack is already taken)
< BashCo>
Before saying the Slack isn't connected to Core, we would need to define the Core entity. It's often said that Core as an entity has indistinct boundaries by design. By saying Slack is not 'connected' to Core, you're defining a hard boundary which happens to exclude thousands of people.
< luke-jr>
BlueMatt: more Core developers supported 148 than opposed it
< luke-jr>
(but more importantly, it shouldn't matter)
< luke-jr>
BashCo: Core isn't an entity at all
< luke-jr>
it's code
< 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.
< BashCo>
luke-jr: you're referring to the codebase. I think Core is more than that. Core also includes email contributions and community support.
< BashCo>
If Slack isn't connected to Core, I wonder if anyone will spearhead a robust rocket.chat server as an 'official' Core community, or if devs really expect their supporters to just lurk on IRC.
< luke-jr>
BashCo: I don't agree. The latter is simply the Bitcoin community.
< BashCo>
yeah fair enough. The Bitcoin community also has ambiguously defined boundaries. Lucky for Core, a large contingent of those communities support Core. That's why I think it's short sighted to pressure those communities to disband in favor of inferior platforms.
< luke-jr>
I don't agree IRC is inferior ;)
< BashCo>
Instead, I think those who are 'connected to Core' should go to their audience and engage directly.
< BashCo>
I know, and I understand why many here agree with you. But the fact remains that there are too many disadvantages for most users who are otherwise quite happy on their platform of choice.
< OdaNobunaga>
Slack is much better than IRC if you want to engage with an audience of mostly non-technical/not-so-technical people
< BashCo>
Keep in mind that a lot of people within the community try to avoid participating on Github, mailing lists, and core-dev because they're viewed as developer sanctuaries. Not a place for memes, emojis and lame jokes with friends.
< esotericnonsense>
i agree with luke on the boundary. it seems rather odd to me. i'm not sure that watercooler chat needs to be 'officially sanctioned'
< BashCo>
can a non-entity officially sanction anything?
< esotericnonsense>
i'm struggling to find accurate wording here
< harding>
It seems to me that the desire is not to drive all users to the same interactive communication platform, but rather for all developers to communicate with each other (and users) from the same platform to ensure the opinions expressed there are represenative of the whole project (including disagreements, nuances, and other important details).
< esotericnonsense>
yes, indeed
< esotericnonsense>
the problem seems to be that slack naturally attracts more casual users and irc naturally attracts development (with overlap of course). this doesn't seem surprising to me, it matches what I see in other communities
< esotericnonsense>
it seems to me that outreach from one group to the other has to be deliberate and won't happen accidentally simply as a result of that
< esotericnonsense>
in particular dev work benefits from a reduction in noise, irc can be distracting enough as it is!
< BashCo>
So how to bridge that divide? Devs have opportunities to write blogs, reddit posts, podcast interviews, schmooze in Slack and get down to business in IRC. But some devs shy away from those avenues for understandable reasons.
< BashCo>
I guess my point is that those connected to Core can bring their voice to disjointed communities through various means.
< chainhead>
Rename it to Core Community slack
< harding>
BashCo: isn't that treating the symptom, when the problem is the disjointed communities in the first place? I believe the argument here, which I agree with, is that communication is going from users <-> some devs <-> rest of the devs, where it should really be going from users <-> all devs.
< BashCo>
gmaxwell's meetup vid covering 0.15 was really popular. a 'sunday talk show' circuit covering various bitcoin media outlets could get a great response, but I understand it has the negative effect of placing devs on pedestals and creating PR spokesmen.
< esotericnonsense>
i agree with harding. there's always going to be a reduction in information transfer that way.
< esotericnonsense>
i suppose my personal view is that if you are interested and want to know about something, the onus is on you to find the relevant channels and use them, if they'
< esotericnonsense>
if they're actually inaccessible (work going on behind closed doors) that is a different matter entirely, but i'm not seeing that
< BashCo>
harding: I don't know how to get all redditors, Tweeters, Slackers, bloggers, etc to a single platform, so I'm treating that problem as incurable.
< MarcoFalke>
Indeed, and some devs prefer not to, as well
< harding>
BashCo: as I said above, I think the desire is not to get all Bitcoin users on the same platform; merely to get all developers on the same platform.
< harding>
That way there's a single source of reference for communication with the project.
< bitcoin-git>
bitcoin/master fadd0c1 MarcoFalke: [qa] zapwallettxes: Wait up to 3s for mempool reload
< bitcoin-git>
bitcoin/master 8df48b3 MarcoFalke: Merge #11308: [qa] zapwallettxes: Wait up to 3s for mempool reload...
< harding>
interactive communication *
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #11308: [qa] zapwallettxes: Wait up to 3s for mempool reload (master...Mf1709-qaZap3s) https://github.com/bitcoin/bitcoin/pull/11308
< BashCo>
esotericnonsense: on the other hand, if you're displeased with your supporters, the onus is on you to seek them out and educate them. Besides, it's not so much that they want to chat with devs, but to chat with fellow supporters.
< MarcoFalke>
harding: I don't think there should be a "single source of reference for communication"
< MarcoFalke>
some devs might prefer not to communicate with users or communicate with them by other means
< BashCo>
harding: I think it's up to those connected with the Core non-entity to find a way to amplify their message across all platforms.
< harding>
MarcoFalke: is your argument that devs shouldn't be forced to participate on IRC (which I agree with) or that it's bad for there to be a single place (perhaps with multiple channel) where devs do all of their interactive communication?
< MarcoFalke>
Both
< harding>
BashCo: so he who self-promotes the best represents the project the most? That doesn't sound desirable to me.
< harding>
MarcoFalke: I can't think of a compelling reason why a single congregating point for interactive discussion about the project would be bad. Could you explain more about why you think that?
< BashCo>
harding: that's the conundrum. there can't be any 'official' Core communities (or spokesmen) which are not sanctioned by the intentionally ambiguous Core non-entity which may or may not have the ability to sanction anything at all.
< chainhead>
A single point can't be everything to everyone, it makes sense to have different communications channels to suit different types of audiences
< chainhead>
Personally I'm banned from Core Slack but I still think it makes sense to exist, and having a single community would also mean then I would be banned from everywhere
< harding>
BashCo: that's an argument about what it is or is not possible to enforce. I think the important point is about what contributors to the Bitcoin Core project, mainly developers, choose to do regarding interactive communication.
< afk11>
harding, it might be a problem if it's touch to connect from your phone..
< afk11>
tough*
< MarcoFalke>
harding: It would force anyone who wanted to participate to that single place. So contributors to the project who prefer not to "register" with that place are excluded. Also, it gives the impression that dicsussion that happens in other places is consequently unrelated to the project
< BashCo>
agreed. my personal opinion is that there are opportunities for developers to do more on that front. But I've seen a lot of reluctance in that regard, primarily because devs don't want to be viewed as spokesmen for the project.
< harding>
MarcoFalke: there are no means for enforcement, and likely any contributor who has trouble connecting to IRC in a manner they find suitable need only ask for help and some gracious person will provide it. Regarding your second point, I think that's an advantage at avoiding having a small group of contributors speak inappropriately for the larger share of contributors.
< harding>
BashCo: indeed no one decent wants to be *the* spokesperson for the project, but I think many contributors are comfortable talking about the project when surrounded by other contributors who will correct any inaccuracies. That's an advantage of having a single point of congregation for interactive communication.
< esotericnonsense>
hm. i think i've managed to dump core by sending an odd RPC request somehow.
< BashCo>
harding: there's a notable personality who expressed interest in hosting as many Core devs as possible on a weekly podcast. I think it was a 5-min interview with one dev (or more) per week. This would allow many contributors to speak about the project without a single spokesperson emerging. I think it's a good opportunity but that recurrent dev participation would be hard to muster.
< BlueMatt>
<luke-jr> BlueMatt: more Core developers supported 148 than opposed it <-- you keep saying that, I'm still far from convinced it is true
< bitcoin-git>
bitcoin/master 0063d2c John Newbery: [tests] Make p2p-leaktests.py more robust
< bitcoin-git>
bitcoin/master 42973f8 MarcoFalke: Merge #11078: [tests] Make p2p-leaktests.py more robust...
< chainhead>
It doesn't really matter too much either way
< harding>
BashCo: I think I must've made my point poorly, because that's the exact opposite of what I intended to encourage. Certainly, people who want to do podcasts should feel free to do them, but the current problem isn't too few separate opinions but too many, or rather that individual opinions are being presented outside of the context of general group opinion.
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #11078: [tests] Make p2p-leaktests.py more robust (master...p2p_leaktests_robust) https://github.com/bitcoin/bitcoin/pull/11078
< BashCo>
then maybe a blog where each dev makes PRs until wumpus merges them, but only after consensus has been reached.
< BashCo>
it's difficult to distill the general opinion of a non-entity.
< wxxs>
BashCo: how about a decentralized solution with an intermediary layer of volunteer spokesmen, who are good at interacting with users and filtering the noise
< BashCo>
wxxs: sounds great to me. a git blog with several spokesmen who can convey and elaborate on that message to various platforms? I don't know if that meets harding's criteria though.
< esotericnonsense>
is libevent only used for RPC/rest/torcontrol?
< bitcoin-git>
[bitcoin] theuni opened pull request #11323: mininode: add an optimistic write and disable nagle (master...optimistic-mininode) https://github.com/bitcoin/bitcoin/pull/11323
< cfields_>
jnewbery: you may be interested in ^^. I have no clue if that's safe with asyncore.
< jnewbery>
cfields_ : I'll take a look. I wouldn't call myself an asyncore expert (nor do I want to become one - it's pretty strongly deprecated in favour of asyncio), but I can definitely kick the tires.
< cfields_>
jnewbery: ah, good to know.
< MarcoFalke>
jnewbery: I'd Concept ACK an pull getting rid of it ;)
< MarcoFalke>
s/an/a/g
< jnewbery>
MarcoFalke : I'd love to, but I think we've had enough refactor churn in the test_framework for the time being!
< jnewbery>
once everything's settled for a bit I might take a shot at it
< cfields_>
jnewbery: well that PR (which presumably asyncio would nullify) shaves a nice chunk of time off of the tests. So it wouldn't be purely a refactor, at least.
< jnewbery>
cfields_ : yes, sounds good. I was referring to ripping out asyncore and replacing with asyncio as being a bit too churny at this point. Definite concept ACK for any small change that can shave minutes of test runs.
< BlueMatt>
are there any known bugs in 0.15 that -resetguisettings will fix that result in a segfault on startup on linux?
< achow101>
BlueMatt: related to 11117?
< BlueMatt>
in 15?
< achow101>
sorry, 11171
< BlueMatt>
I was under the impression that was windows only?
< achow101>
It was experienced on windows, but that does not mean it was limited to that
< achow101>
it looks like it could have been a qt issue
< achow101>
so possibly affecting all platforms
< gmaxwell>
sdaftuar: I have a suggestion for a bit of a change to how #10200 works. "Pipeline mode". When CNB is called, it generates a template and then uses your comparison function to decide between a new template and a cached one. If it uses the cached one, it does not need to perform a TBV at all. It returns the result. If fees increased at all, It TBVs and caches the new template.
< gmaxwell>
sdaftuar: so this would serve the dual purpose of getting TBV out of the critical path.
< gmaxwell>
On a cold start it could just return the template with new transactions, or it could do what your code currently does if the additional complexity isn't great.
< sdaftuar>
gmaxwell: i had some thoughts along those lines as well, but i wasn't sure how to square that with the caching that gbt already does
< sdaftuar>
introduce two caches i guess?
< gmaxwell>
yes, I think so. That outer cache is just to prevent outside stuff from DOS attacking by accident. It could be made much shorter.
< gmaxwell>
I was thinking about this because I'm working on some new block relay stuff where you send a template, then template differentials as it changes, then a template differential to the full block when it eventually shows up. And for that it would be useful if templates were changing less often, and also if the one you were using was a slightly old one.
< gmaxwell>
(my motivator is primarily mining off blocksat, but this could eventually make a BIP152 HB mode like transmission smaller and faster too)
< sdaftuar>
with the cache approach you're suggesting, you would scrap the time-based logic altogether in addPackageTransactions, is that right?
< sdaftuar>
i think the downside to that is that the first template after a block is found might needlessly include recent transactions
< sdaftuar>
i kind of thought that the gbt caller could already do the caching that i think you're suggesting
< gmaxwell>
Yes, -- so my thought on that was is that we'd scrap that, however it could be kept for the first one on a cold cache but I am not sure if its worth the code complexity.
< sdaftuar>
i think scrapping it is fine, but i also think we could scrap all of this and just suggest that gbt callers do it. or move it all into gbt...
< sdaftuar>
maybe that's the easiest thing
< gmaxwell>
sdaftuar: well the gbt caller can't create a new non-TBV template and see if it pays a lot more fees. If you mean the GBT layer caching, it could, but there are often many callers... and that also requires them to be well behaved.
< sdaftuar>
oh, i see
< gmaxwell>
(I think expecting them to be well behaved is a bad idea, someone will spin up three pool daemons, they'll run in a fairly tight loop and prevent bitcoin from processing blocks, and wonder why they're getting orphan blocks)
< sdaftuar>
yeah i never really knew how pool servers worked; allowing randoms to hit your RPC seems like a bad idea! but good to know if that's what people are doing.
< gmaxwell>
but that GBT layer cache could be just a half-second thing, just to cap the number of new templates we construct per second.
< sdaftuar>
ok yeah i think your suggestion sounds pretty good -- eliminating TBV except when the fees are enough to warrant an update seems like an easy win here, and mostly accomplishes the other goal as well.
< gmaxwell>
For the first output after a block we could also produce an empty template, but I'm really not too keen on that. But yes, I thought this was a nice way to get two benefits at once.
< sdaftuar>
(i am also not keen on the empty template thing)
< gmaxwell>
we could also return a non-TBVed template in that case; which is really 90% of the time, and we'd still catch a bad template and shut down while caching.
< gmaxwell>
not that running TBV in the background will be trivial.
< goatpig>
is compressed keys in sw scripts invalid or just non standard?
< goatpig>
err uncompressed
< sipa>
nonstandard
< goatpig>
thanks
< BlueMatt>
(but dont do it - its likely to become invalid sooner or later)
< gmaxwell>
goatpig: why do you ask?
< goatpig>
out of curiosity
< goatpig>
hasving some fun on the testnet
< sipa>
testnet also enforces this rule
< goatpig>
ive noticed
< sipa>
the term 'standardness' has been used for two different things, non-mandatory script validity rules (of which this is one) which can't be disabled, and the actual IsStandard() function (which is only enforced on mainnet)
< goatpig>
well i was thinking about it more in the sense of "wont be propagated but can be mined" and "cant be mined"