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