< Chris_Stewart_5> wumpus: It might be best to just merge #12775 and do the build stuff in a subsequent PR
< gribble> https://github.com/bitcoin/bitcoin/issues/12775 | Integration of property based testing into Bitcoin Core by Christewart · Pull Request #12775 · bitcoin/bitcoin · GitHub
< gmaxwell> jl2012: !! is an ideomatic way to covert a value into 0/1 in C/C++
< gmaxwell> (esp pre-C99 when there wasn't a native bool type)
< wumpus> yes, unfortunately !! is ideomatic C...
< wumpus> Chris_Stewart_5: ok!
< wumpus> C allows you even to make mistakes with booleans, it stays baffling how people get shit done with it
< gmaxwell> well where you need a value to become a 0 or 1 (e.g. turning a cast into a value for a logical operation) I don't think !! is worse than sticking a bool cast in the middle of a statement.
< wumpus> I'd say bool(x) conveys the meaning slightly better than !!x
< sipa> but it's 4 characters longer!!
< sipa> i mean
< sipa> but it's 4 characters longerbool()
< wumpus> ahhhhhhhhh
< wumpus> true, I mean bool(382472487)
< sipa> aha
< wumpus> at least it's defined, they could have done "it's implementation dependent, on some architectures it will be 0 as true and !=0 as false", after all some architectures might want to optimize for bash!
< luke-jr> wumpus: exit codes aren't booleans though
< wumpus> luke-jr: sure, exit codes aren't, but it does treat all boolean operations as if working with exit codes
< gmaxwell> XKCD386' = someone's /joke/ was wrong on the internet.
< wumpus> hehe
< sipa> Munroe's Law?
< luke-jr> XD
< Jmabsd> <crosspost from #bitcoin, please respond at #bitcoin, sorry for spam>Can I add witness data to a transaction input that is not necessarily segwit and where the witness data i'd add is unrelated to the output the input spends?</spam>
< giaki3003> Hello! I'll try and not lose connection this time :D
< giaki3003> So 2 things, thanks for bearing with me
< giaki3003> gdb doesn't run dbg files from Gitian, it complains they are of incorrect format. Any renaming I try doesn't help
< giaki3003> And... Anyone know of a pool software which runs on 0.16? Rpc calls changes and Coiniumserv, Nomp, Unomp, mpos and so on are all broken
< wumpus> strange, maybe an incompatible version of gdb
< wumpus> they did work at some point at least
< giaki3003> Which version of gdb do you recommend? I might as well try with visual studio
< meshcollider> sipa: not sure if you've said anything about it already but what do you think of boneh's multisig paper, just announced to be in asiacrypt18
< sipa> meshcollider: if you're talking about the okamoto scheme, making the signatures larger just to save an interaction round at signing seems like a bad tradeoff
< giaki3003_2> Just tried changing gdb version, same issue. Which do you usually use?
< giaki3003_2> Also any info on a supported pool software?
< jl2012> Jmabsd: no. An input may have witness only if it is native segwit or P2SH-segwit (see BIP141)
< sipa> or put differently, its witness must be empty otherwise
< gmaxwell> this got answered hors ago in #bitcoin.
< sipa> ok
< pierre_rochard> has anyone tried their hand at mocking CClientUIInterface to capture calls to uiInterface in unit tests?
< phantomcircuit> so are we trying to match the style in the surrounding code or trying to match a new spec?
< sipa> phantomcircuit: that's explicitly mentioned in the developer notes :)
< sipa> don't try to mimick surrounding code
< sipa> though you can use old style variable/class names if you'd otherwise need to rename things in unrelated parts of the code
< gmaxwell> mostly just update what you can without expanding the size of your diff.
< jl2012> if I want to know a uint256 is less than (<) another uint256, should I first convert them with UintToArith256? I find that I can directly use < to compare two uint256
< sipa> jl2012: do you want the first byte or the last byte to be more significant?
< jl2012> arith_uint256 treats the last byte more significant?
< sipa> jl2012: uint256 is essentially a byte array; comparing them will sort them lexicograohically
< sipa> arith_uint256 treats its data as a little-endian encoded number, and comparing those will first compare the last byte
< jl2012> sipa: uint256 uses memcmp, so the first byte is more significant?
< sipa> indeed, lexicographic ordering
< CubicEarth> Lightning implementations would have an easier time being compatible with pruned nodes if the lightning node could prohibit bitcoind from pruning above a height it set
< CubicEarth> it seems this would be a useful RPC ... DoNotPruneAbove
< sipa> CubicEarth: there is an RPC for manual pruning
< CubicEarth> I suppose prunblockchain is almost identical to what I was thinking...
< CubicEarth> it would be cool to have bitcoin not prune any blocks unless manually instructed, and yet also respect a storage limitation. So until manual pruning happened, it wouldn't download new blocks beyond some point.
< gmaxwell> it'll shut down when it runs out of space...
< CubicEarth> well that's good... but it'd be nicer not to fill the disk
< CubicEarth> just thinking of ways to play nice with lightning... pruning allows an easy way to use just a portion of disk space
< CubicEarth> manual pruning ensure blocks remain available for lightning to inspect
< CubicEarth> but if lightning isn't started at same time, bitcoin will go ahead and fill all space it can find