< jtimon> so in case they don't do it with segwit inactive is a bug, otherwise is expected behaviour, right?
< jtimon> english speakers: sorry for the double negations, I didn't lacked no ineducation
< gmaxwell> jtimon: segwit is active on testnet.
< gmaxwell> It's expected behavior on testnet that nodes will not fetch blocks from non-segwit peers, because non-segwit peers cannot provide witnesses, which are required, since segwit is active.
< jtimon> oh, right, the assumptions to reproduce the error aren't even possible on testnet3 right now, thanks for clarifying
< sipa> jtimon: ?
< sipa> what is 'the error' you're referring to?
< jtimon> the potential error was segwit nodes not downloading blocks from non-segwit nodes when segwit is not active, which cannot be reproduced in testnet3 as pointed out by greg
< sipa> nobody is talking about the case where segwit is not active
< jtimon> sorry then
< jtimon> I can't believe I didn't mentioned #9279, next meeting
< gribble> https://github.com/bitcoin/bitcoin/issues/9279 | Consensus: Move CFeeRate out of libconsensus by jtimon · Pull Request #9279 · bitcoin/bitcoin · GitHub
< gmaxwell> luke-jr: can you explain to me how your size proof deals with blocksizes that aren't a power of two. I'm too intellectually lazy to read that out of your document, and its not obvious to me how you'd deal with it except something like "don't count the minimum size for segments of the tree which are elided so that you can't look for duplication.
< phantomcircuit> gmaxwell, we're only using openssl for secp256k1 tests now right?
< sipa> and as RNG
< phantomcircuit> oh right
< gmaxwell> and for payment protocol in QT
< sipa> and in payment protocol processing
< sipa> !hi5
< gribble> Error: "hi5" is not a valid command.
< phantomcircuit> yeah so openssl appears to be trying to change their license in a way that appears uh
< phantomcircuit> questionable
< phantomcircuit> iono just mentioning it
< achow101> they're moving to apache 2.0
< phantomcircuit> achow101, > If we do not hear from you, we will assume that you have no objection.
< phantomcircuit> k
< achow101> where do you see that?
< gmaxwell> yea, thats ... uh.
< phantomcircuit> achow101, it's in the email they sent to all contributors
< luke-jr> gmaxwell: the minimum 60 bytes is only assumed up to the last full tx proof, or 1 greater than the half-way point
< gmaxwell> luke-jr: couldn't I just create a block that had 2^n+1 transactions for some n and then provide a full proof for the 'last' transaction (really one long past the end).
< luke-jr> gmaxwell: that's the part I haven't solved yet. I *think* it's sufficient to simply forbid any duplicate hashes building to the root?
< sipa> yup
< sipa> that's exactly what you should do
< gmaxwell> luke-jr: yes, but you don't see the whole tree. I think it's sufficient to not count minimum size for txn where you possibly couldn't see duplication.
< gmaxwell> e.g. say you should a full proof for the coinbase, and nothing else, but perhaps the last 1/4th of the block was a duplicated branch.
< luke-jr> that's why only 1/2+1 gets the min size counted
< gmaxwell> if you only show the hashes along the path to the coinbase you could only count half the number of minimum transactions.
< gmaxwell> okay. sounds good.
< luke-jr> if you prove the full tx at/near the end, though, you'd encounter a duplicate hash somewhere building upward
< gmaxwell> yes, I think thats right, okay, so you can count all minimum up to the last shown transaction, and half that beyond that.
< gmaxwell> that does make my proposed optimization process suboptimal.
< luke-jr> can you count half beyond it? I was assuming min(half+1, lastFullProven)
< gmaxwell> (since there is an advantage in making one of the full txn shown be late in the block.
< luke-jr> it's probably better than what I have now
< luke-jr> currently I'm just adding them largest first
< bitcoin-git> [bitcoin] NicolasDorier opened pull request #10068: [WIP] FundRawTransaction accepts preset non-wallet inputs (master...nonwalletinputs) https://github.com/bitcoin/bitcoin/pull/10068
< NicolasDorier> is there a C++ guru in the room ?? I am having this mem fault:
< NicolasDorier> after doing what I thought pretty harmless
< NicolasDorier> txout = anotherTxOut
< NicolasDorier> it seems that it is not possible because CScript operator= is exploding
< NicolasDorier> which kind of amaze me, as I don't see how such a thing is possible
< NicolasDorier> realloc invalid pointer
< dcousens> NicolasDorier: aye, trying to figure it out myself
< NicolasDorier> the pointer not being null
< wumpus> BlueMatt: yes I'll create a project (if no one has done so yet)
< luke-jr> NicolasDorier: run it in valgrind if you can; random memory corruption can manifest in weird ways
< luke-jr> NicolasDorier: pastebin the patch? :p
< NicolasDorier> luke-jr: My code https://github.com/bitcoin/bitcoin/pull/10068 the innocent looking faulty line is https://github.com/bitcoin/bitcoin/pull/10068/files#diff-b2bb174788c7409b671c46ccc86034bdL2118 that you can hit by running sendtoaddress
< NicolasDorier> I don't know valgrind, better than gdb ?
< NicolasDorier> dcousens: might be some unrelated problem of memory corruption ? I will try to make an easy repro
< luke-jr> NicolasDorier: valgrind is for memory stuff
< NicolasDorier> it fails deterministicallly here though
< NicolasDorier> ha
< NicolasDorier> ok I'll try that
< NicolasDorier> dcousens: seems the problem was my code.
< NicolasDorier> I was in the thought that
< NicolasDorier> the two fields
< NicolasDorier> would be initialized by their default ctor
< NicolasDorier> and thus set to Null
< NicolasDorier> I mean SetNull would be called on them
< NicolasDorier> luke-jr: awesome tool thanks.
< NicolasDorier> nop atcually was not the problem
< wumpus> created the project. Any proposed pulls from last meeting (or the one before that) that I missed? https://github.com/bitcoin/bitcoin/projects/8
< NicolasDorier> wumpus: proposed pulls for what ?
< wumpus> NicolasDorier: for priority review (some people were asking for this at the meeting)
< NicolasDorier> ah ok thought it was about proposals for 0.15
< wumpus> well, in a way it is, but 0.15 is still too far away to have a review crunch now
< wumpus> this is not about last minute merges to any release but about what is blocking people now
< NicolasDorier> wumpus: the merge of the leveldb fix to bitcoin
< NicolasDorier> well no actually it is not like it blocks me
< NicolasDorier> AH I found out my bug. Very interesting. My class was named CCoin, but there is another CCoin in rest.cpp
< NicolasDorier> strangely
< NicolasDorier> I had no compile error problem
< NicolasDorier> even if both CCoin had completely different methods and fields
< NicolasDorier> but on runtime
< NicolasDorier> the other CCoin was linked oO
< NicolasDorier> so basically what I compiled was not what was linked or some strange stuff like that
< NicolasDorier> changing the name of the class completely fixed the problem
< luke-jr> O.o
< dcousens> NicolasDorier: o.O
< NicolasDorier> yeah... what tip me off is when I was using gdb, but the debugger was going into the CCoin of rest.cpp
< NicolasDorier> no idea how it could compile since after I was calling methhods only from my new CCoin class
< dcousens> NicolasDorier: CCoin::operator= (this=0x7fffdb7fc9f0) at ./wallet/wallet.h:459 - is a blank line for me, guessing you had modifications there for sure
< dcousens> esp. since CCoin doesn't even have a operator= in that file
< NicolasDorier> operator= was not defined
< NicolasDorier> it was the default operator= which should just copy
< NicolasDorier> in C++ it exists by default
< sipa> NicolasDorier: if you'd have had the two CCoin class definitions included within one module, compilation would fail
< NicolasDorier> rest.h was not included into wallet.cpp where I was using my CCoin
< NicolasDorier> so there wwas no conflict as far as wallet.cpp was concerned
< sipa> and neither of these has virtual methods?
< sipa> i'm confused actually... if it compiled, i would expect it to work
< NicolasDorier> nop
< dcousens> NicolasDorier: are you certain that was the issue? not just some compilational coincidence?
< NicolasDorier> yes... well I was bit surprised as well
< sipa> the linker would have failed if there was a duplicate definition for some method that wasn't inlined
< sipa> and if they were inlined, the one you expect would be inlined
< NicolasDorier> dcousens: ah maybe a .o outdated or something like that ?
< NicolasDorier> I indeed did not made a make clean
< dcousens> NicolasDorier: indeed, it was going to be my first suggestion `make clean` haha
< NicolasDorier> mmh possible. But strange, it is not like I played with ./configure :/
< NicolasDorier> my methods were inlined
< luke-jr> sipa: would it? I would think the same signature would overwrite silently (and that this is relied on for templates)?
< luke-jr> otoh, I think I may have seen errors like that before
< jouke> ~/win 24
< jouke> srsly
< jouke> I need to get an other irc client.
< bitcoin-git> [bitcoin] NicolasDorier opened pull request #10069: [QA] Fix typo in fundrawtransaction test (master...patch-3) https://github.com/bitcoin/bitcoin/pull/10069
< bitcoin-git> [bitcoin] laanwj closed pull request #10051: adhere to `-whitelist` for outbound connection (master...whitelist-outbound) https://github.com/bitcoin/bitcoin/pull/10051
< bitcoin-git> [bitcoin] laanwj reopened pull request #10051: adhere to `-whitelist` for outbound connection (master...whitelist-outbound) https://github.com/bitcoin/bitcoin/pull/10051
< dcousens> NicolasDorier: beat me to saying it
< dcousens> `rawtx` and `rawTx`
< dcousens> lol
< NicolasDorier> took me an hour to understand wtf was going on
< dcousens> can they not be broken out into different scope?
< dcousens> i mean, different PR, but still
< NicolasDorier> what do you mean ?
< dcousens> NicolasDorier: save re-writing the whole thing, I wonder if you could do the equivalent of introducing a block scope
< NicolasDorier> rewriting the whole thing ?
< dcousens> NicolasDorier: dw, I just meant to avoid the error in future
< NicolasDorier> I don't follow you
< NicolasDorier> ah I did not knew block scope existed in python actually :p
< dcousens> `rawtx` ideally would have thrown "undefined" error if there was an actual typo
< dcousens> NicolasDorier: iirc they are function scoped anyway
< wumpus> block scope doesn't exist inpython just function scope
< NicolasDorier> ha it is possible if broken into functions yes. But I think just better to use rawtx or rawTx everywhere consistently
< wumpus> (although there are "with ..." constructs that can be used to do a kind of block scope, this is not what they're intended for :-)
< wumpus> yes just use a consistent name
< NicolasDorier> might do that in a separate PR
< dcousens> wumpus: indeed that was my second thought
< wumpus> I'd prefer to do it in the same PR, just fix the underlying issue that caused this typo in the same go
< wumpus> I much prefer that to just fixing a symptom :)
< jonasschnelli> NicolasDorier: can you write a description/motivation for #10068?
< gribble> https://github.com/bitcoin/bitcoin/issues/10068 | [Wallet] FundRawTransaction accepts preset non-wallet inputs by NicolasDorier · Pull Request #10068 · bitcoin/bitcoin · GitHub
< NicolasDorier> Yes I am doing right now
< bitcoin-git> [bitcoin] laanwj closed pull request #9983: tests: Convert selected tests to using named RPC arguments (master...2017_03_rpc_tests_named_arguments) https://github.com/bitcoin/bitcoin/pull/9983
< NicolasDorier> jonasschnelli: Just did
< jonasschnelli> NicolasDorier: I haven't really understand the use case so far.. but what's the reason for using fundraw if it's not your inputs? Why not directly add the inputs in createraw?
< jonasschnelli> IMO fundraw can topup a tx with some pre-filled inputs
< NicolasDorier> jonasschnelli: right now fundraw can't topup a tx with pre filled inputs
< NicolasDorier> if the pre filled inputs are not belonging to the wallet
< jonasschnelli> NicolasDorier: oh... I think my initial version did support that...
< jonasschnelli> Ah... that's a point
< NicolasDorier> it was in a TODO
< jonasschnelli> Heh.. at least there was once a plan to do that... okay. I got your point. Thanks for explaining.
< NicolasDorier> I added "pre filled input" in my description
< NicolasDorier> it was indeed unclear
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/a230b0588788...ca209230c8e7
< bitcoin-git> bitcoin/master 232b666 John Newbery: Allow test cases to be skipped...
< bitcoin-git> bitcoin/master 0c1ade6 John Newbery: Skip rpcbind_test if OS/network requirements are not met.
< bitcoin-git> bitcoin/master ca20923 MarcoFalke: Merge #10053: [test] Allow functional test cases to be skipped...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #10053: [test] Allow functional test cases to be skipped (master...skiptests) https://github.com/bitcoin/bitcoin/pull/10053
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ca209230c8e7...a0b1e57b20a1
< bitcoin-git> bitcoin/master 88e3aa0 John Newbery: Run extended tests once daily
< bitcoin-git> bitcoin/master a0b1e57 MarcoFalke: Merge #10052: [test] Run extended tests once daily in Travis...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #10052: [test] Run extended tests once daily in Travis (master...traviscronjobs) https://github.com/bitcoin/bitcoin/pull/10052
< bitcoin-git> [bitcoin] jnewbery opened pull request #10072: Remove sources of unreliablility in extended functional tests (master...extended_test_unreliablility) https://github.com/bitcoin/bitcoin/pull/10072
< cfields> BlueMatt: ping
< BlueMatt> yo
< cfields> BlueMatt: looks like #9605 is hitting the cpu hard
< gribble> https://github.com/bitcoin/bitcoin/issues/9605 | Use CScheduler for wallet flushing, remove ThreadFlushWalletDB by TheBlueMatt · Pull Request #9605 · bitcoin/bitcoin · GitHub
< cfields> not sure how i didn't notice pre-merge :(
< BlueMatt> thats...strange
< BlueMatt> wtf
< BlueMatt> grrr, if there's more bugs in cscheduler.....
< BlueMatt> I assume its in the scheduler thread?
< cfields> unsure where the overhead is, figured i'd poke you first for ideas
< cfields> i'm not managing to hit it while it's busy with gdb, so not sure yet
< BlueMatt> you should be able to see it with top H
< BlueMatt> (if its scheduler thread)
< cfields> cool!
< cfields> yep
< cfields> (how have i not known this?!)
< BlueMatt> i dont know
< sipa> what? top supports threads?
< BlueMatt> yes!
< sipa> TIL.
< BlueMatt> press H while its running to flip
< sipa> i always used htop for that
< bitcoin-git> [bitcoin] jnewbery opened pull request #10073: Actually run assumevalid.py (master...improveassumevalid) https://github.com/bitcoin/bitcoin/pull/10073