< 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>
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
< 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
< 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.
< 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
< 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
< 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
< 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"
< 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
< 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.
< 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.