< 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
< 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?
< 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] 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/&/|/
< BlueMatt>
or (NODE_BLOOM & ~NODE_NETWORK) | SERVES_RECENT_BLOCKS
< 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