<@wumpus>
luke-jr: does #11026 have any user-visible effect? I think it's correct, but the outcome in both cases is the same, doesn't seem like something high-priority to backport :)
<@wumpus>
btw; -acceptnonstdtxn looks like another case similar to #10357, where a chain parameter has migrated back to a global to be able to override it
<@wumpus>
we really need a better way to override (part of) the chain parameters during initialization that doesn't friggin move everything back to globals and cancels out the whole idea of the chain parameters project
< bitcoin-git>
bitcoin/master e666efc Russell Yanofsky: Get rid of redundant RPC params.size() checks...
< bitcoin-git>
bitcoin/master e067673 Russell Yanofsky: Avoid treating null RPC arguments different from missing arguments...
< bitcoin-git>
bitcoin/master fd5d71e Russell Yanofsky: Update developer notes after params.size() cleanup
< bitcoin-git>
[bitcoin] laanwj closed pull request #11050: Avoid treating null RPC arguments different from missing arguments (master...pr/narg) https://github.com/bitcoin/bitcoin/pull/11050
<@wumpus>
if we're not going to make chainparams mutable we should at least move all those things to a 'validation parameters' structure instead of a grab-bag of loose globals IMO
< bitcoin-git>
bitcoin/master b82c55a practicalswift: Add attribute [[noreturn]] (C++11) to functions that will not return...
< bitcoin-git>
bitcoin/master 2ab7c63 Wladimir J. van der Laan: Merge #10843: Add attribute [[noreturn]] (C++11) to functions that will not return...
< bitcoin-git>
[bitcoin] laanwj closed pull request #10843: Add attribute [[noreturn]] (C++11) to functions that will not return (master...noreturn) https://github.com/bitcoin/bitcoin/pull/10843
<@wumpus>
so if there are PRs that are ready to be merged (have lots of review) like 10843, do let me know, I cannot monitor all PRs
< bitcoin-git>
bitcoin/master c06755f practicalswift: wallet: Fix memory leak when loading a corrupted wallet file
< bitcoin-git>
bitcoin/master fc5c237 Wladimir J. van der Laan: Merge #11007: wallet: Fix potential memory leak when loading a corrupted wallet file...
< jonasschnelli>
Hmm.. my 0.15.0rc2 GUI on OSX stopped syncing at 480831 (tried to catch up 1 week)
< jonasschnelli>
Is there a simple way to get the sighash by providing a 1. rawtx, 2. inputindex, 3. scriptPubKey?
< rubensayshi>
hmm, when will BIP173 move from Draft to Final?
< sipa>
jonasschnelli: for segwit, you also need the amount
< jonasschnelli>
yes. Good point.
< jonasschnelli>
There is no RPC interface call I can use? (currently hacking in)
< sipa>
no
< jonasschnelli>
Ok
< sipa>
rubensayshi: when it's in use, i guess
< sipa>
luke-jr: should a BIP be marked final before it's in use, but after there are no plans to change it anymore?
< rubensayshi>
I'd say yea
< rubensayshi>
cuz why would I implement it as wallet dev if there's no guarentee it's final
< wumpus>
because you want to be part of the process forming it?
< rubensayshi>
I might just be creating a huge mess for myself by implementing a BIP that can still change
< wumpus>
if you find issues when it's final, it's too bad
< rubensayshi>
this one not so much
< rubensayshi>
but lets say BIP39 (*hint hint that actually did change under my feet while it was Final, but lets not side step too much*)
< wumpus>
the idea is that people start implementing it before it's final, to know for sure whether it works for their use cases
< rubensayshi>
you can get screwed pretty badly if the BIP changes and while you intended to be compatible you're now not and have to migrate
< sipa>
rubensayshi: i personally have no intention of changing bip173 anymore
< wumpus>
yes, for key generation for wallets I agree, you'd want it to be final at least before releasing or deploying to production
< wumpus>
but for P2P protocols it's different...
< wumpus>
anyhow it's up to you
< wumpus>
but when it's final and you find any issues, it means a new BIP must be created to amend it
< sipa>
it's an annoying situation indeed; i wish there was a state "no intent to change"
< rubensayshi>
true, ofc ppl should implement / test it before then
< rubensayshi>
just bringing it up for discussion
< wumpus>
and most issues are found at implementation time, or after
< rubensayshi>
because putting it into prod when there's a chance it might still change doesn't feel very good either
< wumpus>
implementing doesn't mean the same as putting it into production, you can have an impementation on a branch or something
< wumpus>
just for testing
< rubensayshi>
but if nobody dares to put it into prod, then how can it ever reach Final?
< wumpus>
I think that's a hypothetical question
< sipa>
rubensayshi: i plan to try to get the next bitcoin corelease (after 0.15) to implement support for it
< sipa>
regardless of bip status
< rubensayshi>
well, there's a process here that I guess could still use some polishing
< wumpus>
people are not robots, have a finite lifetime, so under that time pressure someone will deploy it at some time - if they need it at all
< sipa>
i agree
< sipa>
rubensayshi: i think there have been too many cases of bips fundamentally changing after initial publishing
< sipa>
i think the intent is that even draft does indicate some form of confidence in not changing
< rubensayshi>
yea which BIP2 addresses to prevent that from happening once they reach Final
< rubensayshi>
the addresses require widespread deployment of support for it before people can really start using it, it's kinda hard for it to be used and reach Final without people feeling certain it will be Final and should be deployed
< rubensayshi>
chicken & egg issue
< wumpus>
yes, at some point it's better to create a new BIP
< sipa>
rubensayshi: oh, BIP2 has a "proposed" status
< sipa>
i think that is applicable
< sipa>
A BIP may only change status from Draft (or Rejected) to Proposed, when the author deems it is complete, has a working implementation (where applicable), and has community plans to progress it to the Final status.
< wumpus>
could try an initial phase where they're used on testnet only?
< sipa>
bip173 was written with many reference implementations at the time of publishing already, in the hope of not needing any significant change afterwards
< wumpus>
what the trial period would be like really depends on the kind of BIP, but usually testnet will be useful for that
< sipa>
so maybe it could have been "proposed" from the start
< wumpus>
yes
< rubensayshi>
yea Proposed sounds like the right status for BIP173 and for people to starting deploying (wallet support for) it
< luke-jr>
[15:01:57] <sipa> luke-jr: should a BIP be marked final before it's in use, but after there are no plans to change it anymore? <-- no, that's what the Proposed status is for
< luke-jr>
jonasschnelli: right, the stats RPC is more recent, but it breaks your current Qt stats branch because the interface changed.. at the moment, I am planning to put the older code in Knots 0.15.0, but if you have a newer RPC+Qt version, I can update it
< luke-jr>
wumpus: no user-visible effect, but it'd make Knots slightly easier to assemble I think :p
< jonasschnelli>
luke-jr: indeed. Currently I'm rebasing the gui one on top of the newer RPC one
< edin00n>
Why do people use expensive GPUs for Bitcoin mining and not CPU
< BlueMatt>
edin00n: ot, take it to #bitcoin
< edin00n>
Thank's
< jimpo>
Is it true that headers for side branches are stored in the block index DB and loaded into mapBlockIndex on init regardless of how old the side branch is?
< jimpo>
Is something similar not possible by sending an empty getheaders locator with a stop hash on an old side branch?
< BlueMatt>
jimpo: (limited by what we will accept - after ibd we wont accept things that are older than checkpoints....this is really one of the more important, if not only important left reason for keeping checkpoints)
< jimpo>
I don't fully understand, BlueMatt. Can you point me at the code that checks for requests before checkpoints?
< BlueMatt>
jimpo: yes, probably worth just using locator if its a month back (or returning from genesis if they were dumb and didnt give us a locator)
< BlueMatt>
I'm sure there are more of these issues lurking...
< BlueMatt>
jimpo: hmm, no, i meant we wont actually add to mapBlockIndex (see AcceptBlockHeader) if its pre-checkpoints after we've done initial-headers-sync
< jimpo>
Ah, got it
< jimpo>
So do you think it's worth putting together a change to ignore getheaders locators for a header on a side branch older than a month? Happy to put that together if so.
< BlueMatt>
yea, probably
< BlueMatt>
i mean dont ignore the locator
< BlueMatt>
just scan further back in the locator
< BlueMatt>
(ie pretend we dont have that header)
< bitcoin-git>
[bitcoin] practicalswift opened pull request #11110: script: Avoid implicit casts from bool to CScriptNum (master...implicit-casts-from-bool-to-cscriptnum) https://github.com/bitcoin/bitcoin/pull/11110
< bitcoin-git>
[bitcoin] practicalswift opened pull request #11112: developer-notes: By default, declare single-argument constructors `explicit`. (master...declare-single-argument-constructors-explicit) https://github.com/bitcoin/bitcoin/pull/11112
< bitcoin-git>
[bitcoin] jimpo opened pull request #11113: [net] Ignore getheaders requests for very old side blocks. (master...net-getheaders-fingerprint) https://github.com/bitcoin/bitcoin/pull/11113
< bitcoin-git>
[bitcoin] instagibbs closed pull request #11049: coincontrol can filter for segwit inputs, expose fundraw option (master...segwitfundraw) https://github.com/bitcoin/bitcoin/pull/11049