< sipa> achow101: i believe they never have been
< achow101> well they're listed here: https://bitcoin.org/en/about-us#sponsorship
< shinyg> so was there a specific reason why new releases stopped coming from bitcoin.org?
< sipa> they're still published there
< sipa> but bitcoin core has its own project website now
< achow101> they're trying to separate bitcoin core from bitcoin.org as bitcoin.org is for bitcoin in general whilst bitcoin core is a specific project
< shinyg> makes sense, how about is Bitcoin Core a Solution stack or software as some describe it/
< shinyg> Maybe bitcoin is a software stack but Core is just software
< Squidicuz> sipa, cool. I take it that site is bitcoincore.org, right?
< achow101> Squidicuz: yes, bitcoincore.org is Bitcoin Core's site
< Squidicuz> just double checking. ty
< Squidicuz> :)
< tulip> shinyg: with tools like gitian there's no real need for a canonical binary source.
< Squidicuz> ...I'm a little late
< moli> sipa, hi, could you update your graph?
< sipa> which?
< achow101> bip9 bits graph
< sipa> oh, will do
< sipa> before the 18th
< moli> ah still too early? ok, thanks, sipa :)
< sipa> yes, first retarget after the 15th midnight utc
< achow101> miners can signal now, right? just that it won't matter because the retarget period is almsot over
< btcdrak> at this rate of acceleration it might just at the end of 17th...
< sipa> them signalling right now will trigger the unknown softfork warning
< achow101> oh, that's interesting
< btcdrak> sipa: would those trigger while in the defined state?
< btcdrak> oh nvm, ofc it will trigger, derp
< achow101> why would it trigger?
< achow101> oh, is it because it is still in the defined state, not started?
< sipa> indeed
< sipa> so it would be seen as signalling for an unrelated fork
< sipa> which the current software does not know about
< achow101> why are the two graphs on the segwit adoption page on opposite ends of the page? also, chrome is super not liking that sipa's website doesn't have https for those graphs
< shinyg> thanks for the replies sipa and wiki contribs achow
< * jtimon> pushed jtimon/0.13-blocksign-latest on top of jtimon/0.13-blocksign on top of jtimon/0.13-new-testchain on top of jtimon/0.13-chainparams-factory eb6c595e on top of origin/master 924745dd
< achow101> wut
< phantomcircuit> #8831
< gribble> https://github.com/bitcoin/bitcoin/issues/8831 | Replace CWalletDB::ReadKeyValue with CWallet::LoadKeyValue by pstratem · Pull Request #8831 · bitcoin/bitcoin · GitHub
< phantomcircuit> please
< phantomcircuit> someone
< phantomcircuit> review
< phantomcircuit> please
< gmaxwell> looks like some folks are signaling segwit prematurely.
< midnightmagic> :-o
< gmaxwell> Not harmful, but it's more evidence for my concern that version has been burned for consensus critical use.
< gmaxwell> I blame Luke. :P
< luke-jr> ☹
< * luke-jr> doesn't deny being at fault in part.
< gmaxwell> I think the big interface error is that mining exposes gnarly consensus internals to people who are not primarily interested in them but instead have simpler (though critical) goals like: Get mining working fast and reliably.
< gmaxwell> E.g. it's not a good seperation of concerns. I don't have any doubt that any of the pool ops couldn't be great consensus plumbers if they wanted to be, but when they're hacking on pool software that isn't what they're trying to do.
< luke-jr> yes, in hindsight it may have been better to do a more stratum-like getwork replacement in bitcoind (but that had its own share of problems)
< luke-jr> by separation of this, we did gain a few things: miners can upgrade easier now than with 0.3+tons of patching
< gmaxwell> We could be much worse off for sure.
< luke-jr> I tried to make it simpler by having a GBT client library (libblkmaker), but it seems it isn't in any real use outside of BFGMiner
< gmaxwell> One of the lessons (which I already knew from before) is that having a 'bad' interface, then a 'make it friendly' layer often doesn't work. People will either never find the friendlyness layer, or not use it because your own test cases don't (which they look at to understand the interface), will encounter some limitation in it and go raw, or otherwise insist on doing their own for some better o
< gmaxwell> r worse reason.
< gmaxwell> I explirenced this with libvorbis, which had a vorbisfile API which was 100x easier to use right than the raw interface, included with the same library... and mostly used, but still bypassed often enough to cause frequent bogus support issues that would have been avoided by using vorbisfile. ... and especially with liboggz which is a high level interface to many ogg embedded formats and ogg han
< gmaxwell> dling which handles most of the gnarly stuff, ... and which virtually no one uses... instead implementing the same functionality themselves, usually incorrectly.
< luke-jr> :/
< jl2012> which block is signalling segwit?
< gmaxwell> Then Opus (which has a much more carefully contstructed raw API) didn't ship with a opusfile (analog of the vorbisfile high level API), and relative usage of opusfile is probably 100x lower than vorbisfile. Shipping it with it as a single package makes a big difference.
< gmaxwell> jl2012: 438958 and 438914 I think.
< jl2012> oh, slush
< gmaxwell> luke-jr: in any case, the general advice I think we should follow is whe should always imagine the goals of the person using an API, and them assume that they will only correctly handle any non-trivial steps that were obvious from a statement of their goals.
< gmaxwell> Like an API for signing should not ask the signer to provide a nonce that must obey some byzantine set of security requirements. Their goal was signing, not generating random numbers. If it's easy to get it working without getting it right, it's a cointoss if they'll get it right or not. (I don't mean this in a superior or condecending way-- it's human nature to get tunnel vision around your o
< gmaxwell> wn goals).
< gmaxwell> plus, expecting people to worry about details that aren't related to their goals is a failure to respect their time.
<@wumpus> it doesn't help that 'friendly' layers have a reputation to increase overhead and make things slower, deserved or not
<@wumpus> so this may be mainly an issue for cases where there are (perceived) performance concerns, like with media APIs and mining... people always clamoring for a more 'raw' interface instead of a 'friendly' one. Same for 3D rendering with the Vulkan instead of OpenGL interface. "closer to the hardware" etc
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b42291334651...770364b8eaf7
< bitcoin-git> bitcoin/master ec34648 Russell Yanofsky: [trivial] Fix hungarian variable name...
< bitcoin-git> bitcoin/master 770364b Wladimir J. van der Laan: Merge #9160: [trivial] Fix hungarian variable name...
< bitcoin-git> [bitcoin] laanwj closed pull request #9160: [trivial] Fix hungarian variable name (master...hungarian) https://github.com/bitcoin/bitcoin/pull/9160
<@wumpus> also some attempts at friendly interfaces have actually made things harder by abstracting away details that matter, causing the API user to do brittle or nonsensical things when you see the whole picture. Or including scope/dependencies which are not necessary for a project (e.g. texture loaders for 33 image formats while the game only needs one). Good API/library design is hard and both
<@wumpus> commercial projects and open source projects have a lot of sins there
<@wumpus> the best way of 'imagining the goal of the person using the API' is probably to be a user of the API yourself, instead of just guessing to imagine what the goal of a user of the API could be. With mining we have some issues there because there are so few miners involved with development at any level :(
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/770364b8eaf7...f54e4605fc31
< bitcoin-git> bitcoin/master f734505 Jonas Schnelli: Make strWalletFile const
< bitcoin-git> bitcoin/master f54e460 Wladimir J. van der Laan: Merge #9132: Make strWalletFile const...
< bitcoin-git> [bitcoin] laanwj closed pull request #9132: Make strWalletFile const (master...2016/11/strWalletFile_const) https://github.com/bitcoin/bitcoin/pull/9132
< bitcoin-git> [bitcoin] instagibbs opened pull request #9164: [trivial] credit values are CAmount (master...intcredit) https://github.com/bitcoin/bitcoin/pull/9164
< sdaftuar> thrasher`: i don't know where that test case came from, but i do recall this github comment that may be of help: https://github.com/bitcoin/bitcoin/pull/5620#issuecomment-69351549
< jonasschnelli> This one is easy to review if someone has 2-3 minutes of boringness: https://github.com/bitcoin/bitcoin/pull/9142
< thermoman> hi there. just upgraded a 0.11.2 node to 0.13.1 and found out that RPC calls "listtransaction" doesn't work anymore
< thermoman> bitcoin-cli says can't parse reply
< thermoman> tcpdump reveals that the answer is sent to the client, looks like valid jason
< thermoman> EXCEPT: there are non-utf8 chars mixed in between in the comments associated with some TXs
< thermoman> like 0xFC for german umlaut ü (ue)
< thermoman> latin1 1byte instead of utf8 two bytes
< jonasschnelli> thermoman: I'm just trying to reproduce this
< thermoman> so now I'm stuck and luke-jr suggested starting a discussion here about how to handle non-utf8 wallets
< jonasschnelli> thermoman: Just did: sendtoaddress(getnewaddress(), 1, "Dr Schmöörenbröd, Bèrtälzç")
< jonasschnelli> listtransaction works (in Qt though): "comment": "Dr Schmöörenbröd, Bèrtälzç",
< jonasschnelli> Now testing bitcoin-cli
< jonasschnelli> works as well
< thermoman> but what about comments entered in 0.11.2 or even before?
< jonasschnelli> hmm... yes.
< jonasschnelli> Give me your wallet.dat. :)
< jonasschnelli> Let me check the code
< thermoman> with the RPC calls there the client would send umlauts as latin1 instead of utf8
< jonasschnelli> thermoman: does it work for you when you create (temporary) a new wallet and send tx with a comment with umlaute?
< thermoman> didn't try this yet
< jonasschnelli> Maybe give it a try...
< luke-jr> jonasschnelli: most likely your sendtoaddress call used UTF-8? :p
< jonasschnelli> Yeah. I guess you can get stuck with a wtx holding an latin1 char. But why does that break JSON parsing?
< jonasschnelli> Hmm.. thinking of an easy solution.. i guess there is non.
< luke-jr> because we just send the wtx comment as-is, Univalue passes it through as-is, and valid JSON may only use UTF-8
< jonasschnelli> I guess best solution is to fiddle with the BDB file directly
< jonasschnelli> remove the char there...
< jonasschnelli> But I wouldn't do that with a hex editor.
< jonasschnelli> Maybe some berkley-db tool
< thermoman> there is db_dump
< thermoman> but i'm not sure I will see the text in plain there to be edited
< rafalcpp> maybe rebuild the bitcoind with a path that replaces the comment field with empty string when generating rpc reply?
< rafalcpp> *patch
< thermoman> If there was an official patch I would like to test that
< thermoman> do I need to open an issue on github or how will this be handled the best way?
< jonasschnelli> thermoman: Yes. Opening an issue would be good.
< jonasschnelli> I guess we should patch this, though not sure what priority this will have
< jonasschnelli> Comments are used rarely, and even more rarely with non-utf8 compatible chars.
< jonasschnelli> But feel free to fix it. :)
< bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/018a4eb120dc...6eeac6e30d65
< bitcoin-git> bitcoin/master 20c3215 Gregory Sanders: credit values are CAmount
< bitcoin-git> bitcoin/master 6eeac6e Pieter Wuille: Merge #9164: [trivial] credit values are CAmount...
< bitcoin-git> [bitcoin] sipa closed pull request #9164: [trivial] credit values are CAmount (master...intcredit) https://github.com/bitcoin/bitcoin/pull/9164
< bitcoin-git> [bitcoin] instagibbs opened pull request #9165: [trivial] SendMoney: use already-calculated balance (master...triv-curbal) https://github.com/bitcoin/bitcoin/pull/9165
< thermoman> jonasschnelli, luke-jr: https://github.com/bitcoin/bitcoin/issues/9166
< timothy> drizzt@liara ~ % bitcoin-cli listtransactions '*' 2
< timothy> [
< timothy> ]
< timothy> drizzt@liara ~ %
< sipa> sdaftuar: i have a branch sharedblock2 (which is rebased on top of #8589) that includes making the orphanmap and ATMT use shared_ptrs
< gribble> https://github.com/bitcoin/bitcoin/issues/8589 | Inline CTxInWitness inside CTxIn (on top of #8580) by sipa · Pull Request #8589 · bitcoin/bitcoin · GitHub
< sdaftuar> sipa: thanks, i found it yesterday and am working off it
< thermoman> timothy: empty wallet?
< bitcoin-git> [bitcoin] morcos opened pull request #9167: IsAllFromMe (master...IsAllFromMe) https://github.com/bitcoin/bitcoin/pull/9167
< bitcoin-git> [bitcoin] mrbandrews opened pull request #9168: [qa] add assert_raises_message to check specific error message (master...ba-assert-raises) https://github.com/bitcoin/bitcoin/pull/9168
< bitcoin-git> [bitcoin] theuni opened pull request #9169: build: fix qt5.7 build under macOS (master...fix-objcxx-std) https://github.com/bitcoin/bitcoin/pull/9169
< cfields> morcos: ^^
< morcos> cfields: thanks. i did a make clean and re-autogen/configure. if that's sufficient to test it, it works
< cfields> morcos: assuming bitcoin-qt build succeeds after that, then yes, that's enough
< morcos> cfields: ha ha. yes.
< cfields> great, thanks for the quick test
< morcos> cfields: pretty please PR the prevector move commit too...
< cfields> morcos: uhm, sure. I never fully cleaned it up, but I suppose I can pr the bit that's already done
< cfields> morcos: though I should think it would matter much less after the shared_ptr merge?
< cfields> #9125, that is
< gribble> https://github.com/bitcoin/bitcoin/issues/9125 | Make CBlock a vector of shared_ptr of CTransactions by sipa · Pull Request #9125 · bitcoin/bitcoin · GitHub
< morcos> i can try again, but it has consistently made a difference to me, not sure its just in txs that it matters
< cfields> morcos: ok, i'll PR a very simplified version
< cfields> morcos: top two commits here: https://github.com/theuni/bitcoin/commits/prevector-move
< cfields> morcos: mind seeing if you get the same speedup from those? I'd be much more comfortable PRing that than the set of much bigger changes
< morcos> cfields: no problem, but will have to wait til tomorrow now...
< cfields> morcos: np