< cfields>
gitian builders: v0.15.1 detached sigs are pushed
< meshcollider>
cfields: sweet. I'll have to wait til I get home though
< cfields>
meshcollider: no rush :)
< bitcoin-git>
[bitcoin] MeshCollider opened pull request #11651: refactor: Make all #includes relative to project root (rebased) (master...201711_absolute_includes) https://github.com/bitcoin/bitcoin/pull/11651
< bitcoin-git>
[bitcoin] fanquake closed pull request #11053: refactor: Make all #includes relative to project root (master...2017_08_includes_absolute) https://github.com/bitcoin/bitcoin/pull/11053
< LumberCartel>
exit70: This is probably where you want to start looking into the source code for Bitcoin: https://www.github.com/bitcoin/
< LumberCartel>
exit70: There's a bot here named bitcoin-git that announces pull requests and the status updates. So lurking here can be educational too. (Welcome, by the way.)
< bitcoin-git>
bitcoin/master 620bae3 Matt Corallo: Require a steady clock for bench with at least micro precision
< bitcoin-git>
bitcoin/master fe503e1 Wladimir J. van der Laan: Merge #11646: Require a steady clock for bench with at least micro precision...
< bitcoin-git>
[bitcoin] laanwj closed pull request #11646: Require a steady clock for bench with at least micro precision (master...2017-11-11562-cleanups) https://github.com/bitcoin/bitcoin/pull/11646
< cluelessperson>
Does anyone have any logs of dropped transactions from nodes?
< cluelessperson>
My understanding is that nodes have an expiry setting and I'd be interested to review dropped/failed transactions, if they exist.
< bitcoin-git>
[bitcoin] practicalswift opened pull request #11652: Add missing locks to init.cpp (in AppInitMain + ThreadImport) and validation.cpp (master...init-and-validation-locks) https://github.com/bitcoin/bitcoin/pull/11652
< wumpus>
I don't, but IIRC there are people logging all transactions, that's a huge amount of data though
< gmaxwell>
cluelessperson: expirations are rare, we might have just had some this week, but most of the prior year probably none.
< wumpus>
oh you mean dropped from the mempool, I interpreted it as dropped on receive
< gmaxwell>
cluelessperson: the only time anything would get expired is when this graph doesn't ever make it to zero for a width of two weeks: https://jochen-hoenicke.de/queue/#all looks like there was a period in june.
< gmaxwell>
wumpus: ah, I see how you read it, yes I thought he was asking about mempool expiration.
< gmaxwell>
sipa: ^ that is super yuckky. the generic dummysigner thing would be so much better.
< bitcoin-git>
[bitcoin] practicalswift opened pull request #11654: Initialize recently introduced non-static class member lastCycles to zero in constructor (master...uninitialized-members) https://github.com/bitcoin/bitcoin/pull/11654
< bitcoin-git>
[bitcoin] practicalswift opened pull request #11655: Explicitly state assumption that state.m_chain_sync.m_work_header != nullptr in ConsiderEviction(…) (master...m_chain_sync.m_work_header) https://github.com/bitcoin/bitcoin/pull/11655
< cluelessperson>
wumpus: gmaxwell Well I have >14TB ready to start logging data
< cluelessperson>
I was thinking about recording debug logs
< wumpus>
the bitcoin core debug log doesn't contain raw transaction data
< wumpus>
you could add that but that'd be quite inefficient - either dumping to a binary file, or to zmq and logging externally would be more efficient
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #9939: Cache vout IsMine() value on `CWallet::AvailableCoins()` (master...enhancement/cache-wallet-available-coins-output-ismine) https://github.com/bitcoin/bitcoin/pull/9939
< Murch>
sipa: The release notes make it sound that whenever there is a block interval greater than 30 minutes, one of your outbound peers gets replaced. And the peer that relayed you a block first is never affected. I am wondering whether that would allow you to replace all outbound peers of nodes.
< sdaftuar>
Murch: we have limitations in place to prevent that from happening.
< sdaftuar>
Murch: first, the mechanism is that we connect to a 9th peer (rather than disconnect one of our existing at the beginning)
< sdaftuar>
that 9th peer shouldn't be connected for very long before we decide whether we need to evict someone because we have more than 8 outbound peers (there's a 45 second timer)
< sdaftuar>
and we resolve ties by disconnecting our newest peer. so if the 9th peer tells us nothing new, it gets evicted.
< sdaftuar>
after an eviction, we don't try connecting to a new 9th peer until the stale tip check fires again (that runs every 10 minutes)
< sdaftuar>
finally, we protect 4 of our existing peers from eviction under this algorithm
< sdaftuar>
so at worst, half your peers could be taken over this way
< Murch>
sdaftuar: Thanks for the explanation, that sounds very reasonable. It seems someone else already had the same concern. ;)
< cluelessperson>
I'm sorry to annoy you, does anyone have a potential idea of when bitcoin core will support segwit addresses?
< achow101>
cluelessperson: soon(tm)
< cluelessperson>
How can I help?
< BlueMatt>
when sipa finds time to write up the approach doc, everyone else has time to review and debate it, then folks review the pr for full-segwit-wallet-support, then it gets merged, then there is an 0.16rc cycle, then 0.16 ships :p
< achow101>
cluelessperson: whenever #11403 is merged
< BlueMatt>
i believe if you use master right now you can send to segwit addresses, just not receive on them? though probably dont do that, master is scary
< BertrandRussell>
BlueMatt you can receive on segwit address using core, but you have to use the addwitnessaddress rpc call to generate the receiving address
< sipa>
BlueMatt: you can receive on them, but you need addwitnessaddress
< BertrandRussell>
master supports BIP173 addresses but 0.15.1 does not (only P2SH)
< BlueMatt>
only p2sh-wrapped, though
< BlueMatt>
i thought he meant bech32
< sipa>
BlueMatt: no, you can receive on bech32 in master now
< BertrandRussell>
master supports bech32/BIP173
< achow101>
BlueMatt: addwitnessaddress has an option for p2sh or bech32