< 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
< 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>
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
< 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
< 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...