< jonasschnelli>
gmaxwell: some of your comments about required block limits are now working into the BIP.
< jonasschnelli>
I'm not sure about the undefined state of signalling both bits (the BIP states this mode as undefined but required to at least serve the last 90days/12'960)
< jonasschnelli>
To leave enough room for future requirements
< sipa>
jonasschnelli: thanks for working on this
< sipa>
jonasschnelli: i'm not sure that both bits available should have a meaning at all
< sipa>
as network nodes aggregate the bits they see by OR'ing them
< sipa>
a node that at some point advertizes _LOW and later advertizes _HIGH, may result in nodes aggregating it to the combination of both
< sipa>
so maybe LOW should mean "i can relay blocks and transactions at the tip, and also can be asked for blocks up to X deep", while HIGH only means "I can be asked for blocks between A and B deep"
< sipa>
typically you'd set both
< sipa>
or just LOW
< sipa>
(just an idea, see what others think)
< gmaxwell>
sipa: meh, I don't think the "I can do deep but not the tip" really makes sense, what you raise would be resolved by just defining each to be or newer and letting you combine them.
< jonasschnelli>
From a practical standpoint LOW is for the ones who prune to the minimum (current prune=550), HIGH probably for the ones who prune not to the minimum and/or use manual pruning. Also the depth value we set in HIGH will probably give those a guideline who not want to prune to the minimum
< jonasschnelli>
I agree that setting both bits could remain completely undefined
< jonasschnelli>
It just felt wasteful not to define the state when signalling both bits
< jonasschnelli>
Maybe there are some peers who run manual pruning mode but haven't pruned so far and this state could be covered by both bits?
< jonasschnelli>
What are the incentives / reasons why someone pruned to a larger target then the 550 minimum?
< jonasschnelli>
(with the current p2p signaling)
< wumpus>
the only reason I can think of is to support swapping wallets that can run a bit more out of sync
< jonasschnelli>
Good point
< gmaxwell>
jonasschnelli: having prune specified in megabytes is pretty daft.
< jonasschnelli>
He
< gmaxwell>
I think in the future we'll have a small set of options.
< jonasschnelli>
Yes
< gmaxwell>
and people will set larger ones to support the network more and due to rescans as mentioned.
< jonasschnelli>
Yes. I think the thresholds we set in the BIP may have influence what options
< sipa>
it helps to realize that effectively every reachable nodes that serves you blocks is altruistic
< jonasschnelli>
We will have / users will choose
< gmaxwell>
I think the advice in the BIP about connections is not really great advice. It's vague, and I think if followed it will cause a lot of pressure on pruned nodes (Esp because they will likely be much more rare among listening nodes for some time). The network is self balancing. If there is more demand on a node, it'll end up disconnecting some peers, and those peers will move elsewhere.
< gmaxwell>
I think nodes should likely choose uniformly among all peers offering what they need.
< jonasschnelli>
I see this point. gmaxwell: would removing the connection part in the BIP makes sense?
< sipa>
gmaxwell: i don't understand what you suggested earlier to deal with the OR'ing?
< jonasschnelli>
(Leaving it up to the impl.)
< gmaxwell>
if in the future pruned nodes become much more common as listening nodes than unpruned nodes, then it may make sense to try to avoid unpruned if you don't need them; but I don't expect that during the working life of this BIP (Basically by that point we'll have to have made other related service flag changes).
< gmaxwell>
sipa: It is a set mean the same as the 1week option.
< gmaxwell>
it's OR safe.
< sipa>
parse error
< gmaxwell>
@#$@# keyboard
< gmaxwell>
(loses long strings of text)
< sipa>
you need a new laptop
< gmaxwell>
sipa: If both are set, it means the same as the 1week option.
< gmaxwell>
Your suggestion allows a psycho signal "old but not new", which would just end up making that peer get ignored by peer selection (at best).
< sipa>
that's an option too
< sipa>
i'm just trying to not lose information by making the bits indicate orthogonal services
< gmaxwell>
I don't think we should worry too much about using bits here. We will need a new addr message in the not so far future.
< gmaxwell>
(because of HSNG and I2P)
< gmaxwell>
and we avoid using them for other things.
< sipa>
in that light, i wonder if we'll regret the choice of combining possibly 3 independent things into one bits (tx relay, block at tip relay, blocks up to a day old fetch)
< gmaxwell>
I dunno, I think block at tip relay basically needs to impliy 288 in any case, you'll need it for reorg, and the peer will not find your block announcements useful if you can't help the peer reorg.
< gmaxwell>
seems dangerous to me to introduce nodes in the topology that can't help you reorg.
< sipa>
yes, i agree
< sipa>
i'm just wondering whether maybe at some point we'll regret it due to evolutions we don't foresee now
< gmaxwell>
for sure, but then we'll change it then.
< sipa>
making the bits independent does not need to imply there is recommendation or even permission to use them in odd ways "i relay blocks at the tip, and older than 3 months, except those between 1 and 2 years old!"
< gmaxwell>
if you can signal it, everyone will need code to handle it.
< gmaxwell>
which will me realizing that the sensless combination exists in the first place.
< sipa>
which will me?
< gmaxwell>
in general I prefer to avoid even being able to encode something that makes no more sense because it guarentees more corner cases you must handle.
< wumpus>
it was assumed that app RPC-facing stuff was using ValueFromAmount, but apparently TxToUniv in core_io didn't, probably because of some dependency tangle
< wumpus>
I've checked the other remaining uses of FormatMoney afaik they're all in debug logging
< jonasschnelli>
What if the BIP would recommend (optional) to connect - once in sync – to a lower percentage (10%) of the percentage of available NODE_NETWORK_LIMITED in addrman? Probably over-specifing?
< jonasschnelli>
Nah.. nm. Let me remove that part...
< luke-jr>
jonasschnelli: dislike that it still requires 90 days for both bits set. Would prefer if it didn't imply anything more than the 2 days
< jonasschnelli>
Oh. Yes. Let me remove that part...
< jonasschnelli>
luke-jr: its removed now
< luke-jr>
jonasschnelli: rather than forbid the bits when NODE_NETWORK is set, I suggest leaving them entirely undefined in that circumstance
< jonasschnelli>
luke-jr: I don't think one should signal LIMITED and NODE_NETWORK. It may confuse primitive implementations
< luke-jr>
jonasschnelli: forbidding such primitive implementations is why to undefine it now :p
< luke-jr>
jonasschnelli: please use BIP number 159
< sdaftuar>
jonasschnelli: i think it's clearest if setting a bit has meaning independent from looking at other bits.
< sdaftuar>
eg if you want to know if a node has all historical blocks, just check NODE_NETWORK
< sdaftuar>
if you want to know if it serves recent blocks, just check NODE_LIMITED_*
< sdaftuar>
and not owrry about setting both
< jonasschnelli>
I see. Makes sense... I'll fix that
< jonasschnelli>
Fixed
< xHire>
jonasschnelli: please, what does committing a transaction in the context of fee bumping mean? (doing translation; `git blame qt/walletmodel.cpp` pointed to you :c))
< jonasschnelli>
committing means probably add the wallet and broadcast? Need to check that source code comment later. Thx
< jonasschnelli>
Add to the
< xHire>
right, that makes sense. thanks!
< sdaftuar>
gmaxwell: luke-jr: is it important that we cache the last call to CNB in getblocktemplate() and return it to callers who are calling getblocktemplate more frequently than every 5 seconds?
< sdaftuar>
i've finally gotten around to revisiting #10200, and i think it would make sense to drop that cache, and make the proposed new CNB parameters for recent transaction inclusion arguments to getblocktemplate
< sdaftuar>
(rather than bitcoind arguments, which is where that PR started)
< luke-jr>
sdaftuar: the cache is AFAIK mainly used for multiple clients calling GBT at almost the same time
< luke-jr>
I'm not sure it makes sense to expose the parameters over RPC like that anyway.
< luke-jr>
(why would a miner want to run with different configurations?)
< sdaftuar>
the CNB parameters? it seemd like it would be annoying to restart bitcoind if you wanted to change the parameter
< sdaftuar>
eg in response to network conditions
< sdaftuar>
i hadn't considered multiple rpc clients calling gbt on the same server... i figured that for a single client, cnb should be fast enough that we could just invoke it each time
< sdaftuar>
but no idea how much load it could take from multiple clients
< sdaftuar>
eh, i will punt on it for now and just leave it as a bitcoind argument i guess
< luke-jr>
sdaftuar: there are more than just mining parameters that are nice to adjust at runtime. Yet another use for a setconfig RPC..
< sdaftuar>
sure, i agree with that in general
< SopaXorzTaker>
When will the alert key be published?
< SopaXorzTaker>
(don't forget to withdraw the coins that are sitting there, devs!)
< bitcoin-git>
[bitcoin] jnewbery opened pull request #11002: [wallet] return correct error code from resendwallettransaction (master...resendwallettransaction_error_code) https://github.com/bitcoin/bitcoin/pull/11002
< jnewbery>
jonasschnelli: I agree with sdaftuar and sipa that bits should be considered independently.
< jnewbery>
it makes logic straightforward: if (NODE_NETWORK) {can serve me all blocks} else if (NODE_LIMITED_HIGH) {can serve me blocks up to 8 days} else if (NODE_LIMITED_LOW) {can serve be blocks up to 2 days} else {can't serve me blocks}
< jnewbery>
I'd remove the line "The required behaviour when signaling both bits (NODE_NETWORK_LIMITED_LOW & NODE_NETWORK_LIMITED_HIGH) is currently undefined."
< jnewbery>
I also think we should consider sipa's point about orthogonal services having their own bits (tx relay, block relay, addr relay, blocks up to 8 days). It's not like we're short of bits. And the edge-handling code isn't that difficult. For now, just reject if one but not all of them are set.
< gmaxwell>
if we reject, then we can't use them seperately in the future because older peers will ignore us.
< sipa>
jnewbery: i changed the links on the wiki to be section references rather than URLs, and added more
< eck>
i want to extend the backupwallet command so that there's a new optional argument, the file mode of the backup file. For a change like this, is it better to ask for interest on the mailing list? or should I just write the code and send a PR?
< eck>
arguably this would be better done by allowing there to be different rpcusers with different sets of permissions, but that change seems too expansive
< jnewbery>
sipa: looks good. I think everything in #9889 is now covered
< jnewbery>
gmaxwell you're right. Reject is incorrect. Should have said 'ignore bits if one but not all of them are set'
< luke-jr>
unless perhaps it's if (NODE_NETWORK) else if (NODE_LIMITED_LOW) else if (NODE_LIMITED_HIGH) …
< luke-jr>
then the LIMITED bits are properly ignored if NETWORK is set, and if both LIMITED are set, behaviour is only guaranteed as LIMITED_LOW (ie, what the BIP currently says)
< luke-jr>
(leaving the LIMITED_LOW | LIMITED_HIGH combination for a LOW + deterministic assortment of history)
< sdaftuar>
i think we should interpret bits as only being affirmative for a given property, and not denying other services. imo that is the clearest way to describe your state, even if not information maximizing.
< jnewbery>
I agree. I don't think the meaning of a single bit should be dependent on other bits
< bitcoin-git>
bitcoin/master 5e35cd9 John Newbery: [tests] Test disconnecting unsupported service bits logic....
< bitcoin-git>
bitcoin/master fa8a063 MarcoFalke: Merge #11001: [tests] Test disconnecting unsupported service bits logic....
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #11001: [tests] Test disconnecting unsupported service bits logic. (master...unsupported_service_bits_test) https://github.com/bitcoin/bitcoin/pull/11001
< Hello>
everyone, Can somebody inform me on how to check if the coin chain has split ? is there a RPC command ?
< sipa>
getchaintips
< Hello>
hey sipa thank you for the tip but it says method not found
< LordCow>
bitcoin-cli getchaintips
< Hello>
I forgot to mention I want to check this on a alt coin wallet
< Hello>
Client version is 1.0.0.0-g9ccfb23-beta
< gmaxwell>
oh jesus I broke the release notes wiki, pieter is fixing it.
< gmaxwell>
Pro tip: if you hit edit, then change the title for a page on the wiki, it nukes the history.
< gmaxwell>
(people are circulating links to the release notes wiki as if it were the 0.15 release notes, so I tried to change the title to say it's a draft)
< sipa>
Hello: then go yell at its developers
< sipa>
gmaxwell: fixed
< Hello>
Sipa: I can't yell at myself lmao
< sipa>
Hello: in any case, off topic here
< Hello>
sipa: thanks for replying have a nice day