< 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