< jl2012> does --prematurewitness work on mainnet?
< jl2012> i think it works.
< wumpus> MarcoFalke: thanks for letting me know, I'll have a look what went wrong
< wumpus> doxygen shoould be up to date again
< kallewoof> Is there a neat and tidy way to store metadata on a per address (or key) basis? CKeyMetadata does not seem to ever be updated, and CAddressBookData seems to be about accounts not addresses (at least "name" is the account name).
< kallewoof> Since accounts are about to be thrown out I don't really wanna touch the latter.
< kallewoof> And besides, I can't tell how persistent either of them are. I don't want the data to vanish suddenly.
< wumpus> kallewoof: DestData
< wumpus> it stores data on per-address/destination basis
< wumpus> this is used to store metadata such as payment requests
< kallewoof> wumpus: Ahh, thanks!
< bitcoin-git> [bitcoin] madeo opened pull request #10380: [doc] Removing comments about dirty entries on txmempool (master...master) https://github.com/bitcoin/bitcoin/pull/10380
< jl2012> Want to double check, according to BIP9, height of the first block with new rules is divisible by 2016?
< jl2012> (Not 1 before or after?)
< wumpus> jl2012: AFAIK that is correct
< bitcoin-git> [bitcoin] laanwj pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/4b766fcdd4ca...a26280bc1415
< bitcoin-git> bitcoin/master 7d92c6f fanquake: [depends] Latest config.guess and config.sub
< bitcoin-git> bitcoin/master d78269a fanquake: [depends] Boost 1.64.0
< bitcoin-git> bitcoin/master daeb767 fanquake: [depends] libevent 2.1.8-stable
< jl2012> wumpus: thanks. Say it activates at 201600, if I want to make sure my tx won't get in an earlier block, the nLockTIme should be 201599, right?
< bitcoin-git> [bitcoin] laanwj closed pull request #10325: 0.15.0 Depends Updates (master...depends-0-15-0) https://github.com/bitcoin/bitcoin/pull/10325
< wumpus> yes
< wumpus> eh I'm not entirely sure actually if nLockTime would need to be 201600 or 201599
< wumpus> I think 201599 but not 100% sure
< SopaXorzTaker> wait
< SopaXorzTaker> AntPool mine nearly empty blocks for their advantage
< SopaXorzTaker> why can't we implement proof-of-UTXO
< SopaXorzTaker> e.g. a block must include at least len(UTXO)/n transactions or 1 MB of them, either is smaller
< instagibbs> SopaXorzTaker, this is more for #bitcoin, as it's not short-term development
< SopaXorzTaker> instagibbs, this is about the core, though
< SopaXorzTaker> how do I write a BIP? *excited*
< sipa> SopaXorzTaker: this idea gets proposed about once per month for the past few years. it's utterly broken, as miners can just stuff their blocks with their own transactions
< sipa> SopaXorzTaker: and bitcoin development is not just bitcoin core development
< SopaXorzTaker> hmm
< SopaXorzTaker> maybe a subreward based on the coin age (since the input TX)?
< sipa> take it elsewhere, sorry
< SopaXorzTaker> no problem, I understand this is not the right place
< sipa> we're developing software here, not wonder idly about tweaks to the consensus protocol
< sipa> discussions like this belong on the mailing list, where they're open for everyone
< sipa> but again, such ideas really don't work
< bitcoin-git> [bitcoin] paveljanik opened pull request #10381: Shadowing is not enabled by default, update doc accordingly (master...20170510_Wshadow_not_enabled_by_default) https://github.com/bitcoin/bitcoin/pull/10381
< bitcoin-git> [bitcoin] Casimir1904 opened pull request #10382: test (master...release) https://github.com/bitcoin/bitcoin/pull/10382
< bitcoin-git> [bitcoin] Casimir1904 closed pull request #10382: test (master...release) https://github.com/bitcoin/bitcoin/pull/10382
< bitcoin-git> [bitcoin] jnewbery opened pull request #10383: [logging] log system time and mock time (master...log_mocktime) https://github.com/bitcoin/bitcoin/pull/10383
< bitcoin-git> [bitcoin] jonasschnelli opened pull request #10384: Make sure we disable NODE_BLOOM when pruning is enabled (master...2017/05/prune_bloom) https://github.com/bitcoin/bitcoin/pull/10384
< jonasschnelli> BlueMatt: but in prune, we disable NODE_NETWORK but *NOT* NODE_BLOOM
< jonasschnelli> So.. in prune mode, we can't offer bloom filtering..
< BlueMatt> that is correct
< BlueMatt> we can bloom in prune mode, though
< jonasschnelli> Not reliable...
< BlueMatt> we will still filter mempool requests and can provide filtered access to recent blocks
< BlueMatt> what do you mean not reliably? we still provide the last few blocks
< BlueMatt> and mempool
< jonasschnelli> You argument would also say that we can serve "blocks"...
< BlueMatt> hmm?
< sipa> NODE_NETWORK indicates we can serve blocks
< Eliel_> you might not be able to provide all transaction history, but you'll be able to provide all the data the light node needs to make transactions.
< sipa> NODE_BLOOM indicates we can filter whatever is served
< BlueMatt> sipa: in this case !NODE_NETWORK
< jonasschnelli> If we can't server blocks we can't filter them
< sipa> jonasschnelli: yes, so?
< BlueMatt> i mean maybe the correct response is to add the new recent blocks serve bits
< sipa> NODE_BLOOM does not mean "i provide access to all historical blocks"
< BlueMatt> and then we can do those | NODE_BLOOM
< jonasschnelli> sipa: hmm.. okay. I see your point.
< jonasschnelli> I was misinterpreting NODE_BLOOM
< BlueMatt> jonasschnelli: proposed BIP text updates? :p
< sipa> jonasschnelli: well it can be clarified in the BIP i guess
< jonasschnelli> Na... I think it's good.
< sipa> jonasschnelli: but it's the most useful interpretation
< sipa> independent bits for independent features
< BlueMatt> jonasschnelli: misunderstandings are usually an indication that the BIP text needs to be clarified
< BlueMatt> just because you can go back and read it a different way isnt a useful outcome :p
< jonasschnelli> I was a bit confused about the use case NODE_BLOOM & ~NODE_NETWORK...
< BlueMatt> great, should be clarified! :p
< sipa> jonasschnelli: there is likely none
< jonasschnelli> mempool filtering maybe
< sipa> jonasschnelli: but there likely will be a use case for NODE_BLOOM & NODE_LAST_WEEK_BLOCKS
< sipa> s/&/|/
< jonasschnelli> Yes... i was stumbled over this during my NODE_NETWORK_LIMITED work
< bitcoin-git> [bitcoin] jonasschnelli closed pull request #10384: Make sure we disable NODE_BLOOM when pruning is enabled (master...2017/05/prune_bloom) https://github.com/bitcoin/bitcoin/pull/10384
< BlueMatt> sipa: have you seen http://www.agner.org/optimize/optimizing_cpp.pdf ?
< BlueMatt> figured you might be curious given your occasional overoptimization tendancies :p
< sipa> how do you mean 'occasional'? ;)
< BlueMatt> guy also has a everything-you-didnt-want-to-know-about-x86-internals pdf on the same site
< gmaxwell> yea, his figures are pretty good.
< TD-Linux> yes, his microarchitecture guides and instruction cycle PDFs are the only such resource out there if you're doing assembly
< bitcoin-git> [bitcoin] pinheadmz opened pull request #10385: RPC: getblock returns coinbase scriptsig (master...cbtext) https://github.com/bitcoin/bitcoin/pull/10385