< dcousens> what do y'all get for "bitcoin-cli getrawtransaction 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b"
< dcousens> (its the first transaction, ever, afaik)
< gmaxwell> dcousens: you should ge no result
< dcousens> gmaxwell: indeed, "No information available about transaction"
< gmaxwell> dcousens: the transaction in the genesis block was not entered into the database by the software.
< dcousens> (intentionally?)
< gmaxwell> Who knows. It's intentional now, since fixing it would be a hard fork.
< dcousens> gmaxwell: sorry, realized I made a typo and it all comes up on google now :)
< dcousens> thanks
< phantomcircuit> gmaxwell, it could be added to the txindex thing
< dcousens> phantomcircuit: the base transaction?
< dcousens> There was a number of threads that came up on google talking about it. The TLDR was that it wasn't in the txindex, so as to discourage people thinking it might actually be spendable, when its not
< dcousens> When was mempool priority broken?
< dcousens> OOI?
< Luke-Jr> dcousens: it's "broken" by mempool trimming, because the trimmer ignores it
< Luke-Jr> re Lightsword's TBV-in-another-thread stuff: any reason not to just fork() and do it that way? seems potentially more efficient
< dcousens> Luke-Jr: right, but thats only been introduced in the changes for 0.12 right
< Luke-Jr> dcousens: yes, it's fine in <0.12
< dcousens> Luke-Jr: so why is it constantly being used as an excuse for restoring priority
< dcousens> When, the changes which break priority in the first place aren't even in the wild
< dcousens> for not* restoring prio...
< Luke-Jr> dcousens: I don't support removing priority, so I'm the wrong person to ask.
< dcousens> I'm personally against restoring priority, but, you can't say "oh we just broke it, guess you can't use it now"
< Luke-Jr> it's not even that broken really
< GitHub111> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/82aff880d32f73bae28aa2cc071348ada603159b
< GitHub111> bitcoin/0.12 82aff88 Matt Corallo: Don't do mempool lookups for "mempool" command without a filter...
< GitHub147> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/075faaebf2e5...82bcf405f6db
< GitHub147> bitcoin/master 2f601d2 Wladimir J. van der Laan: test: remove necessity to call create_callback_map...
< GitHub147> bitcoin/master 82bcf40 Wladimir J. van der Laan: Merge pull request #7171...
< GitHub17> [bitcoin] laanwj closed pull request #7171: tests: remove necessity to call create_callback_map (master...2015_12_p2p_test_no_cbmap) https://github.com/bitcoin/bitcoin/pull/7171
< GitHub113> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/b2d7ada3727f026ccd83d3d64c75aab660d8053e
< GitHub113> bitcoin/0.12 b2d7ada Wladimir J. van der Laan: test: remove necessity to call create_callback_map...
< Luke-Jr> ok, finally getting some usable data on priority in the real world
< Luke-Jr> back in 2014, it looks like it was about 7% of confirmed transactions
< Luke-Jr> my node has taken the lock to sync, so it will probably progress slower now
< Luke-Jr> started it at block 300031
< Luke-Jr> http://codepad.org/VCZUhPe3 look reasonable?
< GitHub85> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/82bcf405f6db...dc0305d15aa0
< GitHub85> bitcoin/master ca188c6 Jonas Schnelli: log bytes recv/sent per command
< GitHub194> [bitcoin] laanwj closed pull request #6589: log bytes recv/sent per command (master...2015/08/throttle_prework) https://github.com/bitcoin/bitcoin/pull/6589
< GitHub85> bitcoin/master dc0305d Wladimir J. van der Laan: Merge pull request #6589...
< wumpus> 2015-12-07 13:12:52 peer=37 Reject tx code 66: : hash 57f07d10cc0374656d20746f6e20656566206e696d206c6f6f706d656d170000
< wumpus> 2015-12-07 13:12:52 peer=37 Reject tx code 66: : hash 3fd496b99b4874656d20746f6e20656566206e696d206c6f6f706d656d170000
< wumpus> interesting hashes :-)
< Luke-Jr> O.o
< Luke-Jr> are those in fact hashes?
< Luke-Jr> or just other data in place of them?
< wumpus> no, seems like a message format issue
< Luke-Jr> ok, good. if those were hashes, it'd be a little too close for comfort :x
< wumpus> (reason is empty, and part of the reason message ends up in the hash)
< wumpus> some peers consistently send these corrupted reject messages, but I can't quite figure out a pattern to it
< Luke-Jr> wumpus: if it's literally strRejectReason being empty, that's possibly my spam filter(s)
< wumpus> I found the issue, it's sneaky
< GitHub92> [bitcoin] laanwj opened pull request #7179: net: Fix sent reject messages for blocks and transactions (master...2015_12_fix_reject_message) https://github.com/bitcoin/bitcoin/pull/7179
< wumpus> you need that ^ in your -ljr backport release as well, apart from that it is 0.11.99+ only
< GitHub38> [bitcoin] laanwj opened pull request #7180: net: Account for `sendheaders` `verack` messages (master...2015_12_log_sendheaders_verack) https://github.com/bitcoin/bitcoin/pull/7180
< GitHub25> [bitcoin] laanwj opened pull request #7181: net: Add and document network messages in protocol.h (master...2015_12_network_messages) https://github.com/bitcoin/bitcoin/pull/7181
< GitHub173> [bitcoin] Xekyo opened pull request #7183: Removed obsolete lines of code, broke continuation of loop. (master...Fix-#7182) https://github.com/bitcoin/bitcoin/pull/7183
< morcos> ok i have some questions about trying to reimplement BIP 68 in a different way.
< morcos> I don't like skipping over inputs you can't find in CheckLockTime(). That doesn't really seem necessary to me. Why is the wallet even calling CheckLockTime() anyway. How does it get in your wallet and not in the mempool in the first place? I understand it could happen with some very weird reorg?
< morcos> But essentially its very very rare to have non-final txs in your wallet, as far as i can tell. So I propose skipping CheckLockTime() on them. If we want to clean that up later, then we can call CheckLockTime() on wallet txs that aren't confirmed.
< morcos> Can someone tell me if this line of thinking is wrong?
< Luke-Jr> wumpus: thanks
< * Luke-Jr> ponders if he needs to optimise this
< Luke-Jr> so far it still looks like the priority area is consistently being used
< Luke-Jr> up to block 304325 now
< GitHub170> [bitcoin] morcos opened pull request #7184: [WIP] Implement SequenceLocks functions for BIP 68 (master...alternate68) https://github.com/bitcoin/bitcoin/pull/7184
< jcorgan> set #gnuradio MLOCK +nt
< michagogo> The second logs link is broken.
< jcorgan> eh?
< jcorgan> did i type in wrong window?