< phantomcircuit>
sipa: is the block/headers synchronziation strategy documented anywhere?
< phantomcircuit>
(mostly im interested in the intended operation)
< sipa>
phantomcircuit: it's complicated...
< phantomcircuit>
sipa, that's uh
< phantomcircuit>
sipa, can you explain it to me?
< sipa>
yes
< sipa>
during initial sync, we send a getheaders to one peer only; outside of it we send it to all
< sipa>
from headers responses we learn what blocks peers have
< sipa>
and then in sendmessages determine which blocks to fetch from whom, subject to various conditions
< sipa>
that's the parallel fetch
< sipa>
there is also the direct fetch, in response to a block 'inv', which (a) sends a getheaders from that inv (b) sends a getdata if we believe we're close to being synced
< sipa>
and then there is bip130, which introduces direct fetch in response to headers
< sipa>
phantomcircuit: for more detail i need to look at the code
< phantomcircuit>
sipa, ok that's helpful
< sipa>
an invariant is that we never send a second request for a block that is already in flight, but we have timeouts that will disconnect (but not ban) a peer that takes too long
< gmaxwell>
with compact blocks that could potentially be relaxed in the future. fetching a redundant compact block is not going to push you over being able to keep up with the network.
< gmaxwell>
nor would a redundant blocktxn so long as it was less than half the block worth of data.
< GitHub139>
[bitcoin] fanquake opened pull request #8252: [trivial] Add aarch64 to depends .gitignore (master...depends-aarch-gitignore) https://github.com/bitcoin/bitcoin/pull/8252
<@wumpus>
yes, well, that stuff was inherited from the wx client, I agree it would be better in terms of UIMessage, UIQuestion, the MODAL stuff is only used within the GUI code itself so could use something else
<@wumpus>
(the problem there is that paymentserver wasn't designed in the typical qt way with a model and view, so instead of displaying a alert directly, which would be weird in server code, it works around that by abusing the core->ui messaging system :-)
<@wumpus>
so once you start refactoring you'll probably bump against all kinds of things which grew over time and don't exactly fit into the new, cleaned vision
<@wumpus>
paymentserver should have a dedicated signal for messages to the user
<@wumpus>
(and the GUI should subscribe to that)
< sipa>
there are 9 call sites to ThreadSafeMessageBox
< sipa>
that's more than i expected, but not particularly much either
<@wumpus>
must of the calls are InitMessage/InitWarnings
<@wumpus>
InitError*
< sipa>
i call those as a single call site
< sipa>
*count
<@wumpus>
I know, but I mean, all in al the function is used quite a lot
< sipa>
right
<@wumpus>
ideally the core would communicate with the GUI through status codes/bits instead of sending whole messages
<@wumpus>
I mean, the user-facing text belongs in the GUI
<@wumpus>
the _(...) workaround which is hooked by the GUI is pretty weird
< sipa>
yes
<@wumpus>
then again, it was never really urgent to change, at least it works
<@wumpus>
these are things you can spent weeks on, without anything affecting the user-facing side
< randy-waterhouse>
so git head should run fine on on testnet3 without any additional config changes or needs to go on segnet?
< gmaxwell>
yes, though there may not be enough testnet nodes with it yet that you can get it to work right without an addnode.
< gmaxwell>
One of the todos coming out of the meeting this week was to get more segwit testnet nodes up.
< randy-waterhouse>
k, thnx ... what is the "Rewinding" part doing?
< gmaxwell>
What it says-- segwit has been active on testnet for a couple months-- but your node wasn't able to verify the segwit rules... so it's undoing the chain and revalidating it to make sure there were no violations since it activated.
< gmaxwell>
If you had been running segwit code on testnet before it activated you wouldn't have expirenced that.
< randy-waterhouse>
ok, looks like I'm gonna need some addnodes, can I find a list of seggers?
< randy-waterhouse>
or is it segwitters?
< randy-waterhouse>
nm ... found one randomly
< randy-waterhouse>
119.246.245.241
< sipa>
i think we should call transactions with an invalid witness segfaults
< randy-waterhouse>
please no segfaults
< randy-waterhouse>
and here come the blocks ... my blockchain will never be the same again
< randy-waterhouse>
feels like I just exited something