< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d9fdac130a5e...a332a7d5a152
< bitcoin-git> bitcoin/master a3ac767 dongsamb: Fix string concatenation to os.path.join and add exception case
< bitcoin-git> bitcoin/master a332a7d MarcoFalke: Merge #11291: Fix string concatenation to os.path.join and add exception case...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #11291: Fix string concatenation to os.path.join and add exception case (master...Fix-PEP8-warnings) https://github.com/bitcoin/bitcoin/pull/11291
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a332a7d5a152...efae3663a772
< bitcoin-git> bitcoin/master 6915f93 Wladimir J. van der Laan: doc: Update OpenBSD build instructions for 6.2...
< bitcoin-git> bitcoin/master efae366 Wladimir J. van der Laan: Merge #11984: doc: Update OpenBSD build instructions for 6.2 (cont'd)...
< bitcoin-git> [bitcoin] laanwj closed pull request #11984: doc: Update OpenBSD build instructions for 6.2 (cont'd) (master...2017_12_openbsd_build_update) https://github.com/bitcoin/bitcoin/pull/11984
< fanquake> wumpus Good idea. The other two were more gui based anyways.
< wumpus> MarcoFalke: oh no you didn't just #12026
< gribble> https://github.com/bitcoin/bitcoin/issues/12026 | Prepare version scheme for 17.0 release by MarcoFalke · Pull Request #12026 · bitcoin/bitcoin · GitHub
< wumpus> as if there aren't enough virtually irrelevant issues to fight about yet
< fanquake> I tried, and failed, to redirect traffic back to where the actual discussion has already happened.
< wumpus> yes now all the armchair devs are coming out of the woodwork
< wumpus> my versionining scheme is better than your versioining scheme!
< luke-jr> seems pointless to have a PR for such a trivial thing without consensus to do it
< fanquake> Red, white or blue paint?
< wumpus> and people reading way too much in it
< wumpus> OH SO BITCOIN ISN'T BETA ANYMORE?
< wumpus> whieeeee
< fanquake> I assume this is the point everyone has been waiting for so that can actually deploy to production...
< wumpus> unleash the monster
< sipa> i tried to clarify things on twitter a bit... but i may have made things worse :(
< wumpus> yes he added a disclaimer "EDIT: Obviously, this does not mean Bitcoin Core is all of a sudden less experimental than before.". Of course, such people don't read disclaimers.
< fanquake> "While these types of posts do not get the attention they deserve" . No, they get far more attention than they deserve.
< wumpus> they get attention
< wumpus> while we still don't have segwit wallet
< fanquake> sipa clearly you
< fanquake> 've done something wrong, thats the first tweet of yours I've seen with < 1000 hearts..
< sipa> fanquake: it's buried deep in a thread
< sipa> but hey i got some nice in-person review from BlueMatt yesterday on #11304
< gribble> https://github.com/bitcoin/bitcoin/issues/11304 | Вообще не понимаю как установить на linux kali · Issue #11304 · bitcoin/bitcoin · GitHub
< sipa> no, not on that
< luke-jr> hmm, I kinda like that comment suggesting we aim for 1.0 at the 10 year anniversary :p
< wumpus> I mean all these people are clamoring for TRADE SIGNALS
< wumpus> this has nothing to do with development
< wumpus> this is more like with alts, where the devs make a big announcement and the price is pumped
< sipa> but hey i got some nice in-person review from BlueMatt yesterday on #11403
< gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
< wumpus> that's why they want the version number to bump. THey won't even be running bitcoin core, most probably.
< fanquake> Better send some anti signal
< sipa> how about we change the versioning scheme to 0.0.17?
< * sipa> hides
< luke-jr> lol
< aj> release 18.0 without telling anyone whether it's year based or not
< sipa> i can make the same argument
< sipa> "I support dropping the final 0 in 0.17.0.0, as it's clearly redundant"
< fanquake> The only thing I don't want to see are named releases.
< wumpus> it's just pointless to argue about, sucking up developer time in arguments
< aj> sipa: any summary on the in-person review?
< wumpus> fanquake: lol
< fanquake> I thought everyone at that conference was too busy hitting that red button
< wumpus> fanquake: nonono I think I"ve read at least one post proposing those, even
< sipa> aj: i learned that some of BlueMatt's concerns were legitimate; BlueMatt learned that some of his concerns weren't :)
< luke-jr> let's name the next release "fanquake"
< fanquake> please no
< luke-jr> :p
< sipa> (all relating to import/downgrade/restore scenarios, and nothing that a rescan with a later version can't fix)
< midnightmagic> "complaints to fanquake"
< sipa> wumpus: i think we should just do it, or not. i don't care either way - but letting it linger won't help
< midnightmagic> and then just replace the name with someone random in this channel each point release
< wumpus> sipa: I won't touch it with a 10 foot pole
< sipa> fair
< * sipa> hands wumpus the 11 foot pole
< wumpus> I'm not going to NACK it, but let me be clear I think it's ill-advised
< aj> wumpus: btw, i've been poking at #11862 more. if we make it so 'port=1234' only affects mainnet and you have to say '[regtest]\nport=1234' to change the regtest port (or rpcport, etc) i thought it might make sense to allow you to just say 'regtest=1 \n port=1234' without having to have the [regtest] section header. but there's a whole bunch of corner cases there that make it seem not worthwhile (and
< aj> possibly too hard to document accurately)
< gribble> https://github.com/bitcoin/bitcoin/issues/11862 | [concept] Network specific conf sections by ajtowns · Pull Request #11862 · bitcoin/bitcoin · GitHub
< fanquake> Then lets just close everything, and worry about segwit wallet
< wumpus> aj: I don't think that's worth it, no
< aj> sipa: that sounds positive!
< wumpus> aj: I'd prefer to make the logic simple but flexible
< wumpus> aj: adding [regtest] header is simple to understand and parse
< sipa> aj: i'll comment on the PR when i adress the things
< sipa> aj: wasn't there also support for regtest.port=1234 ?
< aj> sipa: yes, [regtest] foo=bar and regtest.foo=bar are equivalent in boost config parsing
< wumpus> aj: most people won't even be using the test network and regtest, adding corner cases here just adds corner cases for corner cases' sake
< wumpus> aj: if it comes for free with boost, fair enough
< fanquake> wumpus re boost #12027 is a pretty trivial merge that removes some confusion errors from the brew install log
< gribble> https://github.com/bitcoin/bitcoin/issues/12027 | [Docs] Remove boost --c++ flag from osx build instructions by fernandezpablo85 · Pull Request #12027 · bitcoin/bitcoin · GitHub
< fanquake> commit message just need ammending
< aj> wumpus: the other issue that i'm hitting now is that regtest.datadir doesn't work -- datadir is decided before the chain is selected. would be a bit more invasive (but ultimately simplify things a bit) to change that
< wumpus> aj: yes there are tons of edge cases around precedence and order of options, with regard to the -datadir and -conf and -regtest/-testnet options
< wumpus> aj: let's try to keep the order there the same
< wumpus> aj: at least don't add that to the scope of the PR
< aj> wumpus: okay, less invasive it is
< wumpus> the current order works pretty well, you can use -conf to select a configuration and set a datadir in there, as well as a netwerk
< wumpus> you can use -datadir to select a datadir and use the bitcoin.conf inside, which can also set a network
< wumpus> (this is used for the tests)
< wumpus> less invasive is better certainly as long as we don't have full test coverage for these edge cases
< wumpus> also it would mean all kinds of scenarios would need to be re-thought
< aj> wumpus: oh, any idea which options to make network-specific? i've got -wallet and -addnode, and https://github.com/bitcoin/bitcoin/pull/11741#issuecomment-347458820 suggested -port -bind -rpcport and -rpcbind ?
< wumpus> fanquake: hehe closing all PRs but segwit wallet (and related things) would make a point, at least
< wumpus> aj: I think that's a good set to start with. THe general credo would be: all options that have different default based on network.
< aj> oh good point
< fanquake> If GitHub had better tools for managing project "workflow" we could actually make something like that happen.
< luke-jr> wumpus: not a positive point, IMO
< wumpus> luke-jr: hm?
< luke-jr> wumpus: the only point I could see from closing all PRs besides a few, would be that some people are trying to force the priority for other people.
< aj> fanquake: it's got tools you can use to make tools to manage workflows at least? did you see https://gist.github.com/ajtowns/bdc91590471559b5c73682fdfa712b15 ?
< wumpus> luke-jr: I was just kidding
< fanquake> aj No, will read through it
< wumpus> luke-jr: I think it'd be an awful idea too
< midnightmagic> you could hire a temporary transition person whose primary job would be to close all PRs, then act as a strawman you could punch the crap out of while pretending to get rid of them..
< wumpus> at some point the project will outgrow the github PR way of working in any case
< wumpus> but we're not there yet
< wumpus> I think
< bitcoin-git> [bitcoin] vajdaz opened pull request #12054: Minimize to tray functionality only on Windows (master...win-only-tray) https://github.com/bitcoin/bitcoin/pull/12054
< MarcoFalke> wumpus: Yeah, sorry about that. Someone brought it to twitter, which lead to the fights. I assumed that step was uncontroversial. But meh, better close it.
< wumpus> MarcoFalke: no, let's merge it
< wumpus> MarcoFalke: just get it over with
< meshcollider> then people can stop arguing about it yeah
< wumpus> I'm sorry for contributing to the pain around it
< luke-jr> merge what?
< wumpus> #12026
< gribble> https://github.com/bitcoin/bitcoin/issues/12026 | Prepare version scheme for 17.0 release by MarcoFalke · Pull Request #12026 · bitcoin/bitcoin · GitHub
< luke-jr> no, that's stupid
< wumpus> I mean it's clear that no one likes the current versioning scheme, and people want to change it, we're never going to agree on what to change it to, so let's go with this simple change.
< luke-jr> the current one is fine, and certainly much better than that
< wumpus> sigh
< meshcollider> its really just a number, who cares, its not symbolic of any major change, its just to save the stupid 0 at the front all the time
< wumpus> yep
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/efae3663a772...db7eba6169b6
< bitcoin-git> bitcoin/master faa7ecf MarcoFalke: Prepare version scheme for 17.0 release
< bitcoin-git> bitcoin/master db7eba6 Wladimir J. van der Laan: Merge #12026: Prepare version scheme for 17.0 release...
< luke-jr> meshcollider: the 0 at the front indicates the current immaturity of the project
< luke-jr> when things get to a sensible state, it should become a 1.x.y.z
< meshcollider> btw luke-jr I liked your consensus versions page on the wiki
< wumpus> luke-jr: no one is making that decision
< bitcoin-git> [bitcoin] laanwj closed pull request #12026: Prepare version scheme for 17.0 release (master...Mf1712-version17) https://github.com/bitcoin/bitcoin/pull/12026
< wumpus> luke-jr: no one will ever agree whether 'bitcoin is ready'
< wumpus> luke-jr: we already get too many fights about that
< luke-jr> wumpus: why not?
< wumpus> with some people calling it completely useless in current state and others saying it's done don't change it anymore
< wumpus> and a whole spectrum in between
< meshcollider> wumpus: shouldnt that have waited til after 0.16 branches off
< luke-jr> and even if it were true, that's certainly no reason to set it to a 16-past-readiness stage when it clearly isn't
< sipa> wumpus: that wasn't intended to be merged now...
< sipa> (the PR also changes the number from 15 to 16)
< wumpus> there is no readyness stage, there won't be no readyness stage
< fanquake> "trades intensify"
< wumpus> sipa: oh shit
< meshcollider> wumpus: heh but now master will build as 16.99 instead of 0.15.99
< meshcollider> we skipped 0.16 release, segwit wallet is now 0.17 ;)
< sipa> meshcollider: no, 17.0
< luke-jr> wumpus: the only reason to drop the 0 is for the same marketting/pumping nonsense you were denouncing earlier
< meshcollider> sipa: oops, yes lol
< wumpus> luke-jr: which no one agreed to at the time
< wumpus> going to force-push to previous master
< luke-jr> ⁈
< MarcoFalke> s/16/15/ && git commit
< luke-jr> wumpus: so why merge pumping nonsense just because nobody explicitly agreed in the last 2 hours?
< sipa> it's just dropping a stupid zero that has no meaning
< sipa> yes, some people will misinterpreted as sign
< bitcoin-git> [bitcoin] laanwj force-pushed master from db7eba6 to efae366: https://github.com/bitcoin/bitcoin/commits/master
< luke-jr> sipa: it has meaning
< sipa> the alternative is that we never get rid of the 0
< wumpus> MarcoFalke: sorry for the inconvenience, please open a new PR
< luke-jr> we get rid of the 0 when it's reasonable to bump to 1.0..
< MarcoFalke> wumpus: No rush. Can wait until next year
< luke-jr> like any other sane versioning
< sipa> luke-jr: the whole point is that there is no "reasonable" time for that
< meshcollider> luke-jr: there will be arguments whenever anyone suggests that though
< luke-jr> sipa: but there is
< wumpus> MarcoFalke: I think it has to be done now
< sipa> we have date based releades
< wumpus> MarcoFalke: either we do it, or we never do it, I think there's a good point to not let this linger
< meshcollider> MarcoFalke: next year is in less than 24 hours in NZ ;)
< sipa> i just had a twitter fight with someone who assumed that bitcoin core could not be "ready" until it integrated lightning
< luke-jr> even if there may be arguments when it's reasonable, it clearly ISN'T reasonable TODAY
< meshcollider> sipa: heh yep I saw that
< sipa> luke-jr: it's as reasonable today as it will ever b
< sipa> everyone has different requirements for ready, and no software is ever finished
< luke-jr> sipa: today it's often that users get transactions stuck and beyond simple recovery; that's not 1.0 quality
< luke-jr> today we have no way to restore wallet backups
< wumpus> luke-jr: that will not improve from one day to another
< luke-jr> today we have no simple way to automate safe backups
< wumpus> luke-jr: there is not one *point* at which that will all be true
< sipa> and then there will be another issue
< sipa> no software is ever perfect
< wumpus> and no one will decide on that, no one wil stake their reputation on 'bitcoin is 1.0 quality now'
< luke-jr> point is that today, Core is not usable by a normal person
< wumpus> sipa: indeed
< wumpus> define 'normal person'
< sipa> luke-jr: sure
< sipa> totally agree
< sipa> it's also not the right choice for many
< wumpus> will it ever be usable by everyone? I don't think so
< luke-jr> wumpus: pick a random person off the street
< wumpus> that's not a requirement
< wumpus> you're just making up things now. Can a random person from the street program the linux kernel directly?
< luke-jr> we're not talking about programming
< luke-jr> we're talking about usage
< wumpus> bitcoin core is just the infrastructre
< sipa> would you argue that FPFA designer software cannot be 1.0 before a random person on the street can use it?
< luke-jr> random person off the street can certainly boot and use a Linux LiveCD
< wumpus> there is tons of software aimed at providing better ui and whatnot
< wumpus> sipa: exactly.
< sipa> i think it's more than infrastructure
< luke-jr> Bitcoin Core is an end-user application, not a developer application
< sipa> but it's not for everyone
< wumpus> luke-jr: then what is RPC for?
< luke-jr> if nearly everyone doesn't use a full node, Bitcoin doesn't work
< luke-jr> wumpus: RPC isn't all of Core
< luke-jr> I'd have no problem with calling bitcoind >=1.0
< sipa> yes, so?
< wumpus> I'm really so tired of this
< wumpus> sure, let's version bitcoind separately... that will make things easier
< luke-jr> there's always the "don't fix what isn't broken" option
< sipa> the 0 in front is redundant at best, and confusing at worst
< luke-jr> strongly disagree. it has a meaning and a purpose
< wumpus> no, it has no purpose
< wumpus> it will never be increased
< meshcollider> and the only ones who would really understand the "meaning and purpose" of a version number in general are other developers... no end user will read this deeply into it
< luke-jr> you're talking about increasing it NOW, so that argument makes no sense
< wumpus> we're just removing the initial 0
< wumpus> not *increasing* anything
< meshcollider> because we actually refer to the second number as the "major" version number, what is the 0 even called?
< meshcollider> the supermajor version number
< sipa> "the zero"
< wumpus> +1 for "the zero"
< luke-jr> who refers to the second as "major"? that'd be incorrect terminology
< wumpus> we all do
< sipa> everyone
< wumpus> except for you, maybe
< sipa> seriously.
< sipa> we have major releases every 6 months
< wumpus> yes
< sipa> minor releases for bigfixes and softforks
< sipa> i like bigfixes and i cannot lie
< meshcollider> e.g. quote from #11449 "Like for previous major releases I've added 6 months to the previous release schedule"
< gribble> https://github.com/bitcoin/bitcoin/issues/11449 | Release schedule for 0.16.0 · Issue #11449 · bitcoin/bitcoin · GitHub
< luke-jr> bugfixes aren't minor releases in normal versioning
< meshcollider> sipa: lol
< wumpus> we've always used that terminology
< sipa> luke-jr: yet that is how we've all been referring to it
< wumpus> so that matches better withremoving the 0
< meshcollider> we'll stick with the 6-monthly release schedule though won't we, rather than converting fully to semver?
< wumpus> what, you want to change the release schedule too now?
< meshcollider> heh no that's what I'm checking
< wumpus> oh right, sorry
< wumpus> yes, I think it makes sense to stick to that, it has worked pretty well
< wumpus> we don't need to change everything around just because a few people (most not even involved with the project) are screaming
< meshcollider> Agreed, it's just that semver has come up in discussion over these version numbers quite a lot, so people might expect us to stick to it more strongly now
< wumpus> what in 'semver' rules out a 6 month release schedule anyway?
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #12055: Prepare version scheme for upcoming release [take 2] (master...Mf1712-versionDropRedundantZero) https://github.com/bitcoin/bitcoin/pull/12055
< meshcollider> semver would only require a major release each time a breaking API change occurred, so you'd be limited to merging a breaking change once every 6 months ;)
< wumpus> don't most open source projects have a more or less tick-tock release schedule?
< wumpus> what is 'breaking' in this context?
< fanquake> I don't think we really gain much by trying to stick to some arbitrary requirements. It would seem like core isn't exactly like "other" projects.
< wumpus> changing RPC interface?
< wumpus> well, every major version wil qualify for that one :)
< meshcollider> wumpus: yes, external API
< wumpus> even if there are no P2P and consensus changes
< meshcollider> wumpus: internal changes do not matter for semver, they are patch releases. Minor changes are backwards compatible extensions of the API, and major are breaking changes to the API (no matter how small, technically)
< wumpus> ok...
< fanquake> To think about this a bit differently. What would the release schedule look like if core github had 2 or 3x the contributors for review and code that it currently has?
< wumpus> it might be possible to do more frequent releases
< wumpus> e.g. 3 month schedule instead of 6
< luke-jr> meshcollider: SemVer is not exclusively about interfaces.. any new functionality warrants a minor bump
< wumpus> but still I think the only sane way to do releases is to have them time based
< luke-jr> wumpus: I think everyone likes thaat
< fanquake> I agree, and I think that will become even more "likeable" over time
< luke-jr> wumpus: doing SemVer right would simply mean we'd go from 1.0 to 1.1 if we were backward compatible, and to 2.0 if breaking compatibility
< luke-jr> nothing to do with the schedule
< meshcollider> luke-jr: It *may* increase minor but not *must*
< luke-jr> meshcollider: patch-level increases must only be fixes, though\
< wumpus> luke-jr: but breaking *what* interface? we have many interfaces to contend with, for semver we'd have to define what interfaces count and which do not
< fanquake> Longer term releases only somethimes "suck" now because big new features can get delayed.
< luke-jr> wumpus: the root of this problem is that we haven't modularised yet (which is yet another reason to stick to 0.x)
< MarcoFalke> In the longer term, we need versions for RPC, wallet, gui, etc anyway
< meshcollider> yeah trying to version core as a whole is too unwieldy tbh
< MarcoFalke> That has nothing to do with Bitcoin Core version
< luke-jr> wumpus: once modularised, each component can have its own version, which makes things a lot more obvious
< wumpus> fanquake: yes, indeed, that's the drawback of the long duration between releases, on the other hand it makes sure things are pretty well tested on mater usually before they end up in a relesae
< meshcollider> indeed
< luke-jr> MarcoFalke: it's harder to go backward
< wumpus> we have a wallet version, and network protocol version, but yes no RPC api version. I agree those are separate from the software proejct version.
< aj> sipa: hmm. "i like bugfixes and i cannot lie: your other branches don't compile. 'cause when a patch comes in and claims it make it run fast and the travis checks pass, it gets merged"
< wumpus> this is also why I closed the PR adding the bitcoin core version to libconsensus pc
< wumpus> libconsensus should probably be versioned differently
< meshcollider> yes libconsensus should definitely follow semver because it is a library
< wumpus> yep
< wumpus> for libraries it makes perfect sense
< wumpus> for the rest it's just useless splitting hairs
< sipa> aj: haha
< luke-jr> at least the "drop the leading zero" approach enables me to just ignore it and keep using a leading zero. ;)
< meshcollider> Instead of dropping the zero, let's just rename _CLIENT_VERSION_MAJOR to _CLIENT_VERSION_THE_ZERO then ;)
< luke-jr> (and eventually the project can revert it when we're ready to get to a real 1.0)
< zelest> o/
< echeveria> at some point soon there'll be pretty good justification for dislodging the wallet from bitcoin core.
< echeveria> it's almost unusable as a wallet now, and I'm pretty tolerant of bad user experiences.
< sipa> how so?
< wumpus> it's pretty usable as a wallet IMO
< luke-jr> I find it very usable, but I'm admittedly not an ordinary user and don't use it like an ordinary user probably would want to
< wumpus> and as said, a full node without a wallet is pretty useless, unless you have other, better wallet to interface with it, which doesn't exist at the moment
< echeveria> it's by far the slowest, highest resource usage piece of software around. I can either suffer it destroying my battery life and bandwidth, or wait for it to catch up a week or two of blocks every time I want to use it.
< wumpus> there are certainly wallets with better UI, but the privacy/flexibility of bitcoin core's wallet is one of the best
< wumpus> that's because you're running a full node
< wumpus> that has nothing to do with the wallet
< luke-jr> wumpus: lots of other wallets exist
< echeveria> note that I said dislodge, not remove.
< wumpus> luke-jr: yes, but I don't think they're better
< sipa> echeveria: those are inherent to running a full node
< wumpus> luke-jr: apart from UI-niceness
< luke-jr> I agree
< sipa> echeveria: dislodging the wallet from the node won't change that
< luke-jr> I also think B-Qt's UI is the nicest ;P
< luke-jr> echeveria: that's what it means to use Bitcoin though
< wumpus> echeveria: so how would the user experience *concretely* become better with a 'dislodged' wallet?
< wumpus> echeveria: apart from the drawback of having to install two programs to have a full node with wallet
< wumpus> echeveria: I like modularization but that doesn't really solve the problem of anything being slow or such things
< wumpus> echeveria: if you want to improve the UI, just improve the uI
< wumpus> that can be done without compounding the issue and extending the scope to reorganizaing the whole project
< wumpus> which will never happen in one go
< echeveria> there's a lot of scope for being able to remotely connect to a trusted node, without giving it any key responsibility.
< sipa> echeveria: fair point
< wumpus> you could already do that though, by running a full node and connecting a SPV node to that
< luke-jr> need BIPs 150 & 151 to do that reasonably safe
< luke-jr> or Tor
< wumpus> there are SPV wallets where you can specify a trusted node
< echeveria> damn, was chewing as missed my 'inb4 bip37'.
< wumpus> in any case, this has been discussed since 2012, patches welcome
< echeveria> it takes like, 45 minutes to sync over bip37 now and it shreds the node you're connected to.
< echeveria> wumpus: I'm not demanding anything of you, or anyone.
< wumpus> more arguing doesn't change anything
< wumpus> it never did
< wumpus> no one is writing software for you for free, if you want something you need to commit to writing it, or having someone write it, or at least to reviewing the end product (there's a few PRs open that move in that direction)
< echeveria> I never asked you to.
< echeveria> I was busy making sure bip37 was disabled on my nodes, that's all.
< sipa> in any casez i agree it would be a useful evolution to running a full node separately from the wallet
< wumpus> yes, exposing bip37 to random nodes was probably not the best idea
< wumpus> it's okay for your own whitelisted wallet
< sipa> though avoiding the bandwidth issue of syncing isn't magically solved by that
< sipa> neutrino is one possibility
< wumpus> certainly not....
< wumpus> it'd just split the load over two hosts, which could be useful in some cases for some people
< wumpus> which was my point that 'dislodging' the wallet is not a panacea
< sipa> right
< wumpus> for completelness: joinmarket's wallet uses a different approach, it imports its addresses as watch-only addresses into bitcoind
< wumpus> this avoids the bandwidth issue between the bitcoind and wallet by doing the scanning server-side
< wumpus> after all, if the node is trusted, it doesn't matter that you're leaking your public addresses to it
< wumpus> -public
< wumpus> that approach also works with a pruning node, without risk that blocks that the client wallet needs have been deleted
< wumpus> (which bip37-based, or even full block SPV approaches would suffer from)
< wumpus> SPV wallets of any kind only have to sync from their birthday, so I don't see why '45 minutes to sync over bip37' unless it's an old wallet that hasn't been synced for a long time
< wumpus> there is certainly no such requirement for new wallets
< echeveria> wumpus: some of them sync from zero, not the birthday.
< wumpus> that's unnecessary
< echeveria> of course.
< wumpus> haven't seen that for a long time anyhow, most of the wallets in active use don't have that problem
< wumpus> anyhow see #10794
< gribble> https://github.com/bitcoin/bitcoin/issues/10794 | Add simple light-client mode (RPC only) by jonasschnelli · Pull Request #10794 · bitcoin/bitcoin · GitHub
< wumpus> or #9483
< gribble> https://github.com/bitcoin/bitcoin/issues/9483 | Complete hybrid full block SPV mode by jonasschnelli · Pull Request #9483 · bitcoin/bitcoin · GitHub
< xiedeacc> can someone provide some information describe segwit in detail and clear?
< xiedeacc> website or book
< xiedeacc> sorry, computer crashed
< sipa> xiedeacc: bip141, bip143, bip144
< sipa> for questions, https://bitcoin.stackexchange.com
< xiedeacc> thanks~
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/efae3663a772...63a4dc10876b
< bitcoin-git> bitcoin/master 5ec3eae Pablo Fernandez: remove brew c++ flag...
< bitcoin-git> bitcoin/master 63a4dc1 Wladimir J. van der Laan: Merge #12027: [Docs] Remove boost --c++ flag from osx build instructions...
< bitcoin-git> [bitcoin] laanwj closed pull request #12027: [Docs] Remove boost --c++ flag from osx build instructions (master...patch-1) https://github.com/bitcoin/bitcoin/pull/12027
< echeveria> uh
< echeveria> 9bf8853b3a823bbfa1e54017ae11a9e1f4d08a854dcce9f24e08114f2c921182
< echeveria> well someone just fucked up badly and mined a zero value block.
< wumpus> nice, not even the block reward
< sturles> Not seen by my node. :-/
< echeveria> uh.
< echeveria> so blockchain.info is stuck on it.
< echeveria> the block hash is 0000000000000000004b27f9ee7ba33d6f048f684aaeb0eea4befd80f1701126.
< sturles> Ah, yes. I've got that one.
< sturles> Mined by AntPool.
< echeveria> why do you say that?
< echeveria> there's nothing identifying in the coinbase nonce, and no output address.
< sturles> According to https://tradeblock.com/bitcoin
< sturles> Could be wrong. I have no idea where they get the information.
< sturles> Some pools publish the blocks they find.
< sturles> Claims to have found.
< echeveria> https://www.antpool.com/poolStats.htm < they're not claiming it
< wumpus> the vout script is weird, invalid "RSKBLOCK:\xdd\xbfQz\xdf\x8f\xfdK\xcawQP[9\xc9\x01:\r\x1f\xd4y\xfcN\x90\x1b9\xddW\xb3G\xc6$"
< sipa> rootstock?
< wumpus> gah, would have been proper to put that in a OP_RETURN instead of just using an invalid script
< echeveria> yeah, looks like a rootstock commitment. that was an expensive mistake.
< echeveria> they vaporized about $240,000. who the hell writes custom software and doesn't check that they have the payout set to something sane?
< provoostenator> Our own little DAO :-)
< provoostenator> Wasn't the previous record of not claiming a coinbase reward 1 satoshi?
< provoostenator> echeveria: do you mean someone didn't implement that BIP in time and lost funds?
< echeveria> provoostenator: read the BIP, two duplicate block rewards (2x 50 BTC) don't exist.
< provoostenator> I thought they were grandfathered in?
< echeveria> they were clobbered. they have the same hash, so spending one spends "both".
< provoostenator> Ok, I see, so those blocks are valid, but their coinbases were already worthless. So the BIP prevents miners from wasting money this way (among the other benefits explictly mentioned).
< echeveria> BIP34 specifies a soft fork that makes them unique by adding a nonce to the coinbase.
< sipa> ^ all known cases of known losses
< echeveria> needs updating for the latest 12.5 BTC loss.
< sipa> yeah.
< provoostenator> Ah yes, wonderful how block explorers have to deal with that special case: https://www.blocktrail.com/BTC/tx/d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599
< provoostenator> sipa while you're at it, maybe link to an explanation for "the coins created in the genesis block cannot be spent"?
< sipa> provoostenator: they just can't
< sipa> every version of the bitcoin full node software would have considered a spend of the genesis output as invalid; hence, it is invalid
< sipa> it may have been intentional or an oversight, but that doesn't matter
< Varunram> sipa: so, satoshi didn't add the genesis block coins to the tx db?
< provoostenator> My understanding is that it was hardcoded into the client in some later version, though by that time it was too late, because even older versions would consider spending that a hardfork, so presumably new versions also don't allow it.
< provoostenator> And about the least important thing you could possibly want to change.
< Varunram> oh, ok
< sipa> provoostenator: in early versions it was because the genesis block was never processed, so its output was never added to the txdb (precursor of the utxo set)
< sipa> in recent versions it's an explicit special case
< sipa> (introduced to prevent creating a hardfork w.r.t. older versions)
< provoostenator> Do all altcoins based on this codebase have the same behavior?
< sipa> provoostenator: no idea
< achow101> provoostenator: no, some changed it to explicitly add the genesis block output to the txdb
< lvmbdv> hello, if P2PKH was the only mechanism of payment, would keeping witness data make more sense?
< sipa> ?
< Randolf> lvmbdv: You'd probably find that the #bitcoin channel is a really great place to ask that question.
< lvmbdv> sorry, i will
< Randolf> :)
< Sentineo> but it certainly needs rephrasing ;)
< midnightmagic> sipa: sorry about that. I can put in an exception if you like
< sipa> midnightmagic: heh, no
< sipa> i should just identify
< midnightmagic> k
< sdupre> I having a C++ error making static builds. Looking for some guidance. Willing to pay.