< bigboytimc>
hey got a quick code question for you guys
< meshcollider>
bigboytimc: "don't ask to ask, just ask" - pieter ;)
< bigboytimc>
haha sounds good, my question is just that I'm looking through the source code and I'm trying to find where the segwit extended block structure is
< bigboytimc>
I figured it'd be in primitives with block.h, but there's nothing there that looks like it
< bigboytimc>
so I guess I'm just wondering where the extended block is in the code
< echeveria>
'extended block'?
< meshcollider>
what do you mean by an extended block, the block structure hasn't really changed
< bigboytimc>
doesn't segwit include an additional structure that isn't on the blockchain?
< gmaxwell>
no.
< bigboytimc>
like the change involved moving some parts of the block into a separate structure to add more transactions?
< gmaxwell>
the blocks are totally unchanged.
< gmaxwell>
bigboytimc: nope.
< gmaxwell>
There is a new field in transactions, called the witness field, which is after the outputs and before the nlocktime.
< meshcollider>
bigboytimc: transactions are serialized and hashed in a slightly different way now, but they are still included in blocks the same as they used to be
< photonclock_>
How well is Bitcoin holding up to the mempool overflow? Is everything working as expected?
< gmaxwell>
New nodes know how to strip out this witness field from the transactions befor passing them along to old unupgraded nodes.
< gmaxwell>
photonclock_: yup. things are working very well.
< bigboytimc>
interesting, I guess reading about segwit made it sound like they took the witness stuff and added it to a different structure
< gmaxwell>
bigboytimc: there is a lot of misinformation out there.
< photonclock_>
gmax I know this is not the room for general Bitcoin chat - can I chat you up on the Bitcoin channel?
< meshcollider>
bigboytimc: there are a number of bad actors who like to mislead people into thinking segwit does things which it doesn't, mostly because they themselves are uneducated. Try http://segwit.org/
< bigboytimc>
thanks!
< meshcollider>
for this command line arg registration thing, whats the cleanest way to have a pointer to a variable whose type is not known currently
< meshcollider>
or I should just use UniValue for the globals
< instagibbs>
did someone say command line registration of args? meshcollider pointer to PR/issue?
< meshcollider>
issues 11819 and 1044 are directly related
< meshcollider>
still solidifying the approach in my head atm
< jonasschnelli>
valentinewallace: sure.. shoot your Q
< sipa>
jonasschnelli: why are you awake? :)
< jonasschnelli>
sipa: I'm usually awake at 17:26. :)
< jonasschnelli>
Don't assume I'm always in CH. :)
< sipa>
oh.
< sipa>
hawaii?
< jonasschnelli>
Jup
< SomeBuggyCode>
Hello
< SomeBuggyCode>
I just wanted to ask and see if there might be anywhere to start besides reading the bitcoin docs. Is there any good way to start contributing? Thank you
< jonasschnelli>
ryanofsky: Can you explain the benefits of 9306?
< ryanofsky>
9306 just lets you scan pcoinsTip instead of pcoinsdbview. pcoinsTip has current utxo data, pcoinsdbview has older utxo data from the time of the last flush
< jonasschnelli>
If you FlushStateToDisk(); and then loop with the curser will give you the same results?
< ryanofsky>
yeah, that should basically be the same
< jonasschnelli>
Are there any performance implications/benefits?
< ryanofsky>
meshcollider, for command line option registration, can't you require the type of the option when registering it? this would let you enforce the type during parsing
< jonasschnelli>
Scanning the whole set takes a couplf of mins here
< jonasschnelli>
*couple
< ryanofsky>
jonasschnelli, i don't know the performance tradeoffs. if calling FlushStateToDisk() is an option though, I would go with that because it seems simpler
< jonasschnelli>
ryanofsky: I'll open a PR soon (next week maybe) and happy if you have a look for possible optimisations...
< jonasschnelli>
thanks
< ryanofsky>
sounds good
< sipa>
flushing just to perform a wallet operation sounds like sething we should avoid
< meshcollider>
ryanofsky yeah that's what I thought, but I can't think of how to pass a type as a parameter in the registration
< meshcollider>
Without using a variant or univalue or whatever
< ryanofsky>
is registration just declaring a global variable? if so the type should just be part of the variable type, maybe a template argument
< meshcollider>
But you have to pass a pointer to the global variable to the arg manager right, so I'm just confused as to the best way of accepting a pointer to a variable of unknown type
< ryanofsky>
meshcollider, probably through subclassing. you could have list<unique_ptr<Option>>, with IntOption, BoolOption, StringOption subclasses, for example
< bitcoin-git>
[bitcoin] laanwj closed pull request #10051: adhere to `-whitelist` for outbound connection (master...whitelist-outbound) https://github.com/bitcoin/bitcoin/pull/10051
< DSidH>
When creating a transaction by hand, how do I decide the scriptPubKey contents? Do I just look at the first byte of the pubKeyHash and decide that its either P2PKH or P2SH ?
< DSidH>
nvm: got the answer. (yes)
< Varunram>
If I may ask, what's the reason in some of the license banners being old? (e.g. bitcoinconsensus.h has a 2009-2016 banner)
< wumpus>
Varunram: usually we do one "update copyright years" PR at the end of the yera
< wumpus>
if the file is touched that year
< Varunram>
was just curious, thanks!
< wumpus>
it's certainly allowed to update the copyright year of a file together with your change, but almost no one bothers to do that, and it might even result in merge conflicts/rebases as it's a single hotspot per file. There's just no urgency in updating them.
< Varunram>
yep, got the "don't update copyright until the file is changed" part, but just wanted to know the rationale behind it :)
< ilanosortap>
Hey guys, i would like to contribute to this project. I understand that the first step should be to build it on my system, how can i do so?
< ilanosortap>
Also, since i am beginner how can i choose bugs to work on
< goatpig>
i know, im just looking into alternate node modes and thinking forward
< jonasschnelli>
goatpig: what are you building?
< jonasschnelli>
IMO the most straight forward way if you want to run multiple wallets away from a Core node would be an RPC proxy.
< eck>
can i get any book recommendations for practical/applied cryptography for an engineer who has an undergraduate or so level of background in mathematics
< jonasschnelli>
The (new) wallet app could hold keys, and therefore do the signing. That app would create new wallets via RPC (proxy) (which would create a watch-only-wallet on your node).
< jonasschnelli>
Which would also work with pruned peers.
< jonasschnelli>
So a single pruned peer node could server (maybe) hundreds of wallets.. no index required
< jonasschnelli>
Backup recovery is only possible via UTXO-set sweep
< goatpig>
not building anything yet
< goatpig>
working on my supernode
< goatpig>
thinking of a hybrid mode where clients bootstrap on a public supernode then run off of a lite bitcoin node
< jonasschnelli>
goatpig: what is a supernode?
< jonasschnelli>
what is a lite bitcoin node?
< goatpig>
db that tracks all blockchain history undiscrimnately
< goatpig>
can handle any arbitrary history request quickly
< arubi>
I can just feed it any blockchain and it would index it?
< luke-jr>
archive node?
< goatpig>
basically yes
< jonasschnelli>
goatpig: fully indexed? Like an electrum server?
< luke-jr>
oh
< goatpig>
yes
< arubi>
well, sounds like free for all dos
< jonasschnelli>
Okay. Yes. Pretty inefficient if you just want to run a handful of wallets
< luke-jr>
goatpig: so that assumes the blockchains in question are minimally compatible with Bitcoin in some way?
< jonasschnelli>
But ideally for a large backend
< luke-jr>
jonasschnelli: IMO it should be a goal that Core does something similar long-term
< goatpig>
luke-jr: this is targetted at Bitcoin, i dont do alts
< arubi>
oh ^
< webuser8434>
Hey I just wanted to say that I think maybe at some point in the future you guys might want to consider dissolution of the "Core" brand thing. As much I support everything you do and how you do it the whole "Core" idea is Bad and you'll never stop paying price for it and by extension the entire Bitcoin community. It's divisive in its nature and it gives opponents a tangible target. Unless of course it goes away. It was
< jonasschnelli>
luke-jr: Yeah.. I started to change my mind about indexing... it may should be in Core
< webuser8434>
The only label there is is Bitcoin. Maybe use a section of bitcoin.org to communicate development .. whatever, details are not import. Core needs to die for Bitcoin to live!
< luke-jr>
goatpig: that contradicts the "undiscrimnately" part.. invalid blocks aren't Bitcoin
< goatpig>
arubi: any public facing service has to, but this can also be used internally by businesses
< webuser8434>
Ah, and please please release this bloody Segwit yesterday.
< webuser8434>
Good holidays chaps!
< luke-jr>
jonasschnelli: for example, by tracking BCH's chain, we can use "total known hashrate" as a security metric
< wumpus>
eck: 'cryptography' is kind of general
< arubi>
goatpig, I'll have to see what you mean by "any blockchain"
< luke-jr>
jonasschnelli: this is useful because if we know hashrate is mining BCH, we know it isn't being used to make an attack reorg chain
< jonasschnelli>
luke-jr: hmm... thats interesting... though "known" hashrate is probably not enough for a security metric... there could be hashrate sitting around in non BCH/BTC chains
< goatpig>
arubi: im not saying that, this is based on Bitcoin, i dont care about other networks/chains
< luke-jr>
jonasschnelli: yes, but it's an improvement
< jonasschnelli>
luke-jr: if you attack BTC, then you would just have to "hide" the hashrate until it drops out of BTC hash security algo, then attack with that hidden hashrate
< eck>
wumpus: well eventually i'd like to understand things like pederson commitments, ring signatures etc. at a deeper level, my current understanding is superficial. doesn't necessarily have to be a book that covers those things specifically, but i'd like to build a more solid theory foundation.
< luke-jr>
jonasschnelli: it's harder to hide 50%
< arubi>
goatpig, alright, but I don't think I understand the usefulness if it's targeted at bitcoin specifically
< goatpig>
my users run against fullnodes
< goatpig>
this lets you do
< goatpig>
1 fullnode -> 1 db -> any amount of clients
< luke-jr>
jonasschnelli: but for example, if 50% of miners switch to BCH, we wouldn't want to false flag this as a security problem in Bitcoin
< jonasschnelli>
goatpig: I'm currently in favor of a direct backend. Means, you pass in new just created pubkeys in oder to track them (like a wallet), means you don't need block history, means you can run on pruned peers
< provoostenator>
In theory you could feed the client any sha256 hash from any source and it couuld figure out how much went into it. So you can feed it headers from anything that's completely different from Bitcoin, as long as it has a trustworthy timestamp, and it only cares aobut estimating total work in the world.
< arubi>
goatpig, so the clients aren't fully validating?
< jonasschnelli>
goatpig: if you don't care about the backup recovery, you can run endless wallets on a 4GB pruned peer
< provoostenator>
(known work, and the trustworthy timestamp bit doesn't seem trivial)
< wumpus>
eck: in that case it might be useful to focus on the math underpinning it, group theory etc first
< goatpig>
arubi: maybe some context is lost, the supernode is for armory, i was asking about litghter nodes for users to interface with while they bootstrap off a remote supernode
< goatpig>
arubi: the armory stack is full node, db, client. im looking into possible ways around that
< arubi>
ah, you're right. yea I understand now. I missed context
< wumpus>
eck: one of my fav books in that regard is Victor Shoup's A Computational Introduction to Number Theory and Algebra, it's free for download too at http://shoup.net/ntb/
< eck>
great, thank you for the recommendation!
< goatpig>
jonasschnelli: as long as i can deliver a good service with armory, Core wouldn't need to work towards that
< wumpus>
eck: besides I really enjoyed "applied cryptoanalsys
< wumpus>
eck: but that's as off topic to cryptocurrencies as it's possible :)
< eck>
i might enjoy it anyway, i'll take a look
< jonasschnelli>
"applied cryptoanalysys"... is that the new word for hacking?
< jonasschnelli>
:-)
< wumpus>
jonasschnelli: it's about breaking rsa in some edge cases, timing attacks, and breaking various historical ciphers, so yea sort of
< wumpus>
but not the expoitation kind
< provoostenator>
I doubt this is reproducable, but I just managed to crash QT while it was doing a reindex (in order to get -txindex=1 to work). At the next launch it decided to just redownload the whole blockchain...
< wumpus>
eck: http://cryptopals.com/ has some fairly interesting challenges re: applied cryptography things
< wumpus>
provoostenator: uh oh
< wumpus>
provoostenator: are you able to get a traceback?
< provoostenator>
I'm not entirely sure how I managed to crash it. I was running the eclair lightning test suite, so it's possible that that interfered.
< provoostenator>
wumpus: where would I find that?
< wumpus>
well if you ran it in gdb it would be easy, otherwise, did it dump a core file?
< wumpus>
linux also prints the crash eip to dmesg in case of a segmentation fault but I've found that fairly useless usually with ASLR
< jonasschnelli>
provoostenator: I guess you ran in the OOM issue? It's still in master AFAIK
< provoostenator>
OSX applications sometimes create crash reports. Maybe that's something we can / need to enable? At least in debug mode.
< jonasschnelli>
The crash report should be stored somewhere
< provoostenator>
I'm on sipa's SegWit branch and I set a pretty high dbcache
< jonasschnelli>
I did a reindex 4-5 days ago and had the OOM crash on debian with 32GB ram
< provoostenator>
Why would an OOM cause a new IDB?
< provoostenator>
IBD
< provoostenator>
IBD
< promag>
does it cause ibd?
< jonasschnelli>
provoostenator: I think you may end up with a corrupted db.. even if you souldn't (in theory)
< provoostenator>
Oh I was monitoring memory usage, and that was about 30 GB during the reindex (I have 16 GB physical)
< jonasschnelli>
provoostenator: yes. Its fixed in 11824
< jonasschnelli>
reindex in master is currently not usable
< provoostenator>
promag: I don't know if it caused IBD, but it certain started an IBD after this happened
< wumpus>
apparently the validation queue fills memory
< provoostenator>
So only a re-index should cause this crash, right? Not the new IBD? I might just let this IBD finish and then do another re-index to see if it crashes, before cherry-picking that fix.
< promag>
guess I'll check 11824 too
< gmaxwell>
it would effect IBD too
< luke-jr>
depending on bandwidth?
< jonasschnelli>
I haven't looked at the code of 11824 to be honest...
< cfields>
meeting?
< wumpus>
#startmeeting
< lightningbot>
Meeting started Thu Dec 21 19:01:13 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< jonasschnelli>
If we disable it by default, you wonldn't
< jonasschnelli>
gmaxwell: no.. but I guess I should add that
< jonasschnelli>
gmaxwell: it says you should wait for the feeest to be ready (a couple of blocks)
< gmaxwell>
We should probably do this but we need to make the matching fixes so that the software isn't unusuable for the first day of running it or whatever. e.g. by telling you that you can manually set a fee and providing facilities to do that.
< gmaxwell>
probably need to add a trivial rpc to set the fallback fee.
< jtimon>
ack on RBF by default. I would also remove -mempoolreplacement and always do replacements but that's likely to be more controversial
< instagibbs>
jtimon, luke-jr says miners actually use this option
< jonasschnelli>
gmaxwell: I agree.
< wumpus>
it's still settable on the command line at least
< gmaxwell>
since paytxfee doesn't really do the right thing there.
< sipa>
it's probably best to look at the actual UI, which i haven't :)
< jonasschnelli>
We could even fetch estimations from bitcoincore.org (*hide* *duck* *runaway")
< wumpus>
not sure it'd make sense as a RPC, as there's already paytxfee
< zelest>
sorry for asking, but can anyone just grab whatever bug in the repo and fix it.. and submit a pull request? :o
< instagibbs>
jonasschnelli, or from one of my two suspended twitter bots :P
< jtimon>
instagibbs: yeah, I remember that, just repeating my opinion about it
< jonasschnelli>
heh
< gmaxwell>
wumpus: IIRC paytxfee overrides the estimator, rather than being overridden by the estimator.
< sipa>
indeed
< wumpus>
zelest: no, you need triple-signed off documents from the central committee first
< wumpus>
zelest: (yes, everyone can just do that :-)
< gmaxwell>
wumpus: so if you achieve your fallback by setting paytxfee then you'll end up underpaying even when your estimator knows better.
< zelest>
Ah ;-)
< jonasschnelli>
The sendto commands have really no clever way to set the txfee
< zelest>
Mayhaps this is what I should spend/waste my free time on...
< gmaxwell>
in any case, I can write the rpc to set the fallback fee, it would be trivial.
< jtimon>
what is the fallback fee?
< meshcollider>
hi, sorry I'm late
< gmaxwell>
and then the errors when you hit that case should just tell you to set the fee.
< wumpus>
gmaxwell: I think it'd be slightly confusing to add yet another fee setting RPC, but okay
< jonasschnelli>
jtimon: its the feerate used when no estimations are available
< wumpus>
another global used in fee determination
< jtimon>
jonasschnelli: thanks
< wumpus>
zelest: that'd be awesome
< jonasschnelli>
I agree with gmaxwell that we need a good UX for the first "day" when fee estimations are not available
< gmaxwell>
wumpus: Agreed, but I don't see around it, telling lots of people to use paytxfee is probably a bad situation.
< promag>
so if fee estimation is not available, rpc funding should fail?
< gmaxwell>
jonasschnelli: not just first day, every day, because of resource usage lots of people don't leave their nodes running.
< jonasschnelli>
promag: Yes
< wumpus>
gmaxwell: agree...
< jonasschnelli>
gmaxwell: indeed.
< gmaxwell>
promag: unless you've set a fallback feerate.
< wumpus>
gmaxwell: would almost wish that there'd be something like 'paytxfeepriority' but not that that would be any easier to understand :-)
< promag>
jonasschnelli: and in the UI too? or prompt for custom?
< jtimon>
gmaxwell: yeah, or people just shut down their computers when they go to sleep
< jonasschnelli>
So either the user enters the current feerates into RPC/GUI or we load it from somewhere
< wumpus>
gmaxwell: (e.g. whether it'd override the fee estimator or not)
< promag>
gmaxwell: but we want to remove that?
< gmaxwell>
promag: no we want to eliminate there being a default one.
< gmaxwell>
The estimator is always going to take time to start working. And it's not reasonable to force people to not transact until they have estimates.
< gmaxwell>
But a static compiled in fallback is dumb.
< wumpus>
promag: the problem is that fees are too variable now to hardcode any sensible default in the software
< promag>
gmaxwell: ok, but once defined it can be outdated very fast
< luke-jr>
ideally we could pre-sign multiple fee rates and send the higher ones once we have an estimate
< promag>
luke-jr: only with rbf signaled
< gmaxwell>
RBFing has complications, unfortunately.
< promag>
?
< jonasschnelli>
luke-jr: long term.... yes. Maybe. But complicated to implement
< luke-jr>
well, require RBF when there's no estimates?
< jonasschnelli>
luke-jr: I had this in a PR
< gmaxwell>
You can't just assume that RBF will work unfortunately.
< gmaxwell>
Because of the pinning problem.
< jonasschnelli>
But then morocs asked for just disabling fallback.. which makes sense
< wumpus>
RBF is orthogonal imo
< luke-jr>
even without RBF, it would probably work if the problem is fee rate too low
< instagibbs>
gmaxwell, "pinning" meaning someone spending on top?
< instagibbs>
I like the name if so
< luke-jr>
if nobody has the conflicting tx in their mempool, it's not even considered a replacement
< wumpus>
yes, we also want RBF by default, but that doesn't change the fallback fee situation
< gmaxwell>
instagibbs: with a large txn, yes.
< wumpus>
certainly not for RPC
< * luke-jr>
wonders how pinning affects mempool eviction of low feerate
< jonasschnelli>
I think the fallback fee problem is solveble in the GUI,... but not sure about RPC layer,... we would have to add feerate parameters to the send commands
< gmaxwell>
in any case, ACK removing fallback fee but we must be mindful that for a lot of users the no-estimate case will be very frequent so the workflow has to be good: which means clear messages and a straight forward way to set a fee.
< gmaxwell>
jonasschnelli: RPC I think is fine, setfallbackfee ... and the error returned on send tells you that you have to use that.
< wumpus>
yeah...
< jonasschnelli>
I think gmaxwell idea with the setfallbackfee RPC makes most sense..
< jtimon>
yeah I think RBF is orthogonal too. let's just make it default independently of the estimation issue
< wumpus>
jtimon: agree
< gmaxwell>
then for cli users the workflow is basically like the GUI one, and for businesses they might pull the fallback off another node, or an estimation site.
< wumpus>
right
< gmaxwell>
(automatically)
< jtimon>
don't we have an estimator purely based on past blocks with no knowledge of the mempool?
< instagibbs>
jtimon, that's the only way we do it
< jtimon>
mhm, then why do you need to be up for some time to have estimates?
< gmaxwell>
instagibbs: not quite we watch the dwell time of transactions that confirm.
< gmaxwell>
it needs both
< promag>
how about something to help/speedup fee estimation?
< instagibbs>
mistook the question
< wumpus>
using only blocks would be easy to manipulate
< promag>
like feeding fee estimation with something.. don't know the internals
< gmaxwell>
using blocks exclusively is exploitable, unfortunately. Though there are limited ways which it could help.
< gmaxwell>
e.g. you could look at the minimum fee confirmed over many blocks, but sadly it would be misleadingly low because of OOB payments and such.
< jtimon>
perhaps we could have a non-mempool estimator that is used by default until there's data for the mempool based one
< wumpus>
adding a new estimator is not going to go for 0.16 at least
< wumpus>
in the future, who knows
< gmaxwell>
also it's not likely to be invented by folks who don't know the current one and history. :)
< jtimon>
say, something stupid like max (the minimum feerate in each block for the last 144 blocks)
< gmaxwell>
jtimon: yes, maybe... under the bet that there is at least one block with no OOB fees. You'd have to exclude blocks that weren't full.
< sipa>
or bounding estimates by the feerate at 1 MB vbyte from the top of the mempool
< aj>
jtimon: aggregate all the fee rates over a bunch of blocks and choose a fee that's higher than ~10% or 20% of them
< gmaxwell>
sipa: without mempool sync that isn't fast.
< jtimon>
gmaxwell: right, 100 empty blocks would screw you
< sipa>
ah yes
< gmaxwell>
but indeed, once we have some kind of mempool sync we could do things like that.
< wumpus>
100 empty blocks would screw everyone
< jtimon>
is there a way to persist the mempool while running instead of only when shutting down?
< instagibbs>
jtimon, i think there is an rpc for that
< gmaxwell>
jtimon: just go back one day of blocks, counting only blocks at least 0.95*MAX_WEIGHT in size, and check the maximum of their minimum feerates. Would be interesting to see what that yields right now. It _might_ be useful.
< jtimon>
gmaxwell: yeah, that sounds less stupid than what I proposed, and still isn't hard
< gmaxwell>
or instead of their minimum feerate, their Nth percentile feerate.
< jtimon>
I mean, still probably not for 0.16, but not hard to code I think
< gmaxwell>
right
< wumpus>
any other topics?
< gmaxwell>
e.g. what feerate is less than 95% of the txn in the block... gives it room to ignore 5% priority txn.
< jtimon>
wumpus: instagibbs thank you! and sorry, the question is kind of unrelated anyway
< wumpus>
yes that'd make sense
< provoostenator>
I'm still reluctant about enabling RBF for RPC. Without having a long disucssion here, is there a list of known large services that use Bitcoin Core RPC to broadcast transactions? I'd like to know their take on this.
< gmaxwell>
provoostenator: an RPC using service can at least read the release note and simply turn it off again.
< wumpus>
promag: let's first enable it for the gui, at least that's uncontroversial
< wumpus>
provoostenator*
< instagibbs>
15 minutes left
< provoostenator>
It's equally trivial for an RPC user to just set walletrbf=1 if they want to use this. The only problem seems to be code complexity.
< wumpus>
I think having a too long defaults discussion is not productive, if anyone is opposed to enabling it for RPC with good reason then we shouldn't do that
< gmaxwell>
rpc can wait, we can release note a reminder that you can turn it on for cli/rpc use.
< promag>
wumpus: ok
< wumpus>
people using RPC will usually have a better idea of available options anyhow
< provoostenator>
gmaxwell: I already put that in the release note in my PR
< instagibbs>
perhaps with a warning that future versions may change this
< provoostenator>
(sort of)
< jonasschnelli>
I don't think splitting walletrbf between GUI and RPC makes sense in the long run
< wumpus>
yes, defaults are subject to change
< gmaxwell>
sipa: so what do you think long term trying to use that block percentile as a maximum fee for a fast estimate, and then use a synced mempool to potentially reduce the number. I think that escapes the primary manipulation concerns we have.
< wumpus>
jonasschnelli: on the long run it makes no sense
< provoostenator>
I think it does make sense to treat GUI and RPC different
< wumpus>
jonasschnelli: it'd be a temporary artifact
< provoostenator>
Very different use cases.
< gmaxwell>
just get rid of the setting for the GUI.
< provoostenator>
It's just a code maintenance thing why we shouldn't make them too different.
< sipa>
gmaxwell: if you're worried about OOB paymemts, shouldn't you also be concerned about OOB refunds?
< jonasschnelli>
What speak again just enabling -walletrbf GUI/RPC by default?
< jonasschnelli>
*against
< wumpus>
gmaxwell: I think that's a good point too - why would the GUI need a setting for the default?
< jtimon>
i think rbf active is the most sensible default for both rpc and gui
< gmaxwell>
sipa: OOB refunds don't currently appear to be a real thing.
< wumpus>
it has a checkbox if you really want to disable it
< provoostenator>
gmaxwell: yes, I can kill the setting for the GUI, especially because I renamed the RPC setting to -rpcwalletrbf
< gmaxwell>
wumpus: yep thats just what I was typing, that it has a checkbox.
< jonasschnelli>
wumpus: people are lazy to read checkboxes? :)
< gmaxwell>
then they'll certantly not read a setting. :)
< wumpus>
jonasschnelli: well the default is sensible, lazy people won't want to override it!
< wumpus>
gmaxwell: indeed
< sipa>
gmaxwell: for now.
< wumpus>
+1 on not having the GUI default setting
< jonasschnelli>
Set walletrbf=1 by default,.. switch the checkbox in the GUI (to disable RBF instead of enable)
< jtimon>
why not leave the checkbox as meaning enabled but simply have it checked by default?
< provoostenator>
Rather than renaming -walletrbf to -rpcwalletrbf, I can also make it clear that -walletrbf won't impact the GUI.
< wumpus>
provoostenator: yes, I'd prefer that
< gmaxwell>
+1
< wumpus>
provoostenator: I'd really prefer not to have a rename/deprecate cycle there
< gmaxwell>
better to not break things for people who are already walletrbf=1 if we can avoid it.
< wumpus>
yeah...
< * jonasschnelli>
unsure
< wumpus>
just document the option instead of renaming it
< jonasschnelli>
Wait...yes. This makes sense
< provoostenator>
Yeah, the deprecation stuff was a bit overkill.
< gmaxwell>
just adjust the description, make the gui not read that setting for the checkbox default.
< wumpus>
ok, cool!
< wumpus>
seems we agree
< jonasschnelli>
ack
< meshcollider>
yep sounds good
< gmaxwell>
if users complain that they can't set a different default we'll deal with that then, but I don't expect it.
< luke-jr>
why not just let -walletrbf continue to work, but have the new defaults only affect when it's unset?
< wumpus>
luke-jr: it will continue to work
< wumpus>
for the RPC
< luke-jr>
wumpus: I mean for both
< wumpus>
any other topics?
< wumpus>
luke-jr: using the same setting with different default in different places was *ugly*
< provoostenator>
^
< provoostenator>
That was actually what I did in the first version, but it's confusing.
< gmaxwell>
the 'implementation defined behavior when not set' should be used very sparingly.
< provoostenator>
Making it clear that -walletrbf has no bearing on the GUI (including it's default) seems better.
< luke-jr>
IMO the ugliness only comes from having two defaults, not from having a common setting
< wumpus>
yes, that used to be the case, but it's no way to handle options imo, and won't be ocmpatible when we introduce an actual options registration/parsing system
< provoostenator>
I'll push that after the meeting.
< jonasschnelli>
Thanks provoostenator!
< gmaxwell>
In general we should probably not have config file setting for GUI checkboxes that stare the user in the face.
< provoostenator>
Remind me not to make changes to defaults too often :-)
< gmaxwell>
if the GUI wants a persistant default it should be changable from the GUI.
< meshcollider>
Which I am trying to work on at the moment :)
< luke-jr>
gmaxwell: via rwconf ;)
< jonasschnelli>
provoostenator: hah... these are the worst. :)
< gmaxwell>
But hopefully we won't need a changable persistant default for this.
< wumpus>
right
< jtimon>
the rbf checkbox doesn't appear with every tx?
< provoostenator>
luke-jr: rwconf?
< wumpus>
jtimon: isn't it always there?
< meshcollider>
jtimon: what?
< gmaxwell>
provoostenator: code to allow the conf file to be rewritten by setting changes at runtime.
< luke-jr>
provoostenator: lets the GUI change config file settings
< wumpus>
please, no scope creep
< gmaxwell>
that was just a tangent.
< gmaxwell>
not scope creep. :)
< provoostenator>
Ah, so we don't have this "here's a setting, but if you use -blah it's overridden, unless you also have bitcoin.conf, unless you have another one" stuff?
< gmaxwell>
I was just expressing the principle that controlling GUI defaults via non-gui accessable settings is just not very good.
< jtimon>
sorry, I should look at the gui. my assumption was that for every tx a checkbox would say "allow rbf" and that is unchecked by default and we're moving to checked by default
< wumpus>
it would add another bitcoin.conf, bitcoin_rw.conf, which can be written by the software itself
< provoostenator>
gmaxwell: indeed, also not very easy to launch QT with flags on OSX.
< gmaxwell>
I know, we could save the users settings ON THE BLOCKCHAIN
< meshcollider>
jtimon: yep that's basically what this is doing
< wumpus>
hehehe, settings delta chain
< sipa>
gmaxwell: woah!
< meshcollider>
lol
< * cfields>
founds chainsettingsalytics
< wumpus>
gmaxwell: I"m surprised that no *coin project commits git diffs to the blockchain yet
< jtimon>
meshcollider: then I don't understand the -walletrbf discussion, but it's fine
< gmaxwell>
plus the related costs will make them never get changed, and since they're never changed we could remove the implementation of the choices... less UI to maintain!
< provoostenator>
Some people use opentimestamps for that
< provoostenator>
The git integration thing.
< achow101>
wumpus: there's definitely a Core commit diff somewhere on the blockchain
< meshcollider>
jtimon: the walletrbf discussion is about whether that parameter should affect the GUI default or only the RPC I believe
< wumpus>
or even better, just commit javascript code for the GUI to the block chain
< wumpus>
:')
< achow101>
I found it once, but don't know where it is
< wumpus>
achow101: oh! which one?
< wumpus>
it'd certainly create incentive to make patches small
< achow101>
wumpus: I don't quite remember
< jtimon>
meshcollider: right, we're moving to not affecting it seems, which is what makes most sense to me, just what I described with no relation to -walletrbf. so it's fine.
< meshcollider>
wumpus: heh why just the GUI, entire new versions of core could be downloaded directly from the blockchain too!
< wumpus>
no one would submit a diff-all-over-the-place PR if it costs >300 sat/byte
< wumpus>
meshcollider: yes of course, updates to the consensus algo too :')
< sipa>
wumpus: do you get a refund for deleted lines?
< wumpus>
sipa: yes!
< provoostenator>
Unless they want to show off their wealth as an offering...
< meshcollider>
jtimon: yep exactly
< jtimon>
meshcollider: that would be great to make sure everyone upgrades before a hf :p
< sipa>
wumpus: brb, deleting all the tests
< wumpus>
sipa: but only if accepted :-)
< luke-jr>
wumpus: you're going to give my children nightmares
< sipa>
oh.
< sipa>
DONG
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Dec 21 20:00:08 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< cfields>
jonasschnelli: you happen to have git revisions for good/broken gitian builds?
< sipa>
achow101: you should make the blockchain remind you
< achow101>
sipa: lol
< jonasschnelli>
cfields: let me check
< cfields>
thanks
< jonasschnelli>
Good: 38d31f95
< jtimon>
sipa: can you even program a smart contract alarm without turing completeness? :p
< jonasschnelli>
Broken: 13e31dd6
< jonasschnelli>
Happy bisect
< achow101>
in other unrelated news, I finally got around to simulating the branch and bound coin selection stuff
< cfields>
perfect! thanks :)
< jtimon>
alright, I'm going to go try that savemempool rpc...
< jonasschnelli>
jtimon: why?
< gmaxwell>
achow101: and?
< wumpus>
FYI you can only save to the default file, it doesn't take a filename argument
< achow101>
gmaxwell: it's taking a long time
< achow101>
I'm looking at some results right now and I'll add a comment to the PR with them
< achow101>
gmaxwell: AFAICT, it performs on par with the current coin selection behavior but I think that might be because BnB was only used <3% of the time with the dataset and parameters I just tried
< spence>
Is there a roadmap for integrating segwit better into Core? Gui, etc...
< jtimon>
jonasschnelli: I'm working on an explorer, and every time I deploy ir restarts the daemon's container, but it doesn't wait for the mempool dump, so I lose the whole mempool every time. I'll fix it with process that periodically calls savemempool
< jonasschnelli>
ah
< sipa>
provoostenator: congratulations
< sipa>
very happy to see that
< jonasschnelli>
provoostenator: Oh. Nice! Well done.
< wumpus>
provoostenator: great!
< jimpo>
Just out of curiousity, why is much of the secp256k1 code in _impl.h header files instead of .c files?
< wumpus>
jimpo: optimization, scope for inlining, as well as making it easy to add secp256k1 to a project by just adding one .c file
< jtimon>
provoostenator: cool, great news
< meshcollider>
🎉
< cfields>
provoostenator: congrats!
< zelest>
how much of self-torture will I have to live through to get bitcoin running on OpenBSD? :)
< provoostenator>
Thanks! Also, updated #11605 (but do check carefully, it's a bit late here...)
< zelest>
wumpus, thanks for all the help though :)
< wumpus>
zelest: I don't think that should matter - what matters is that both dbc++ and bitcoind are compiled with the same c and c++ compiler
< wumpus>
zelest: if not, you get linker errors, due to ABI mismatch
< zelest>
hmms..
< Guest99499>
How can 4 btc come out of my wallet and I did not send anything
< Guest99499>
It was several different transactions with the same address going out is it rerouting
< zelest>
wumpus, i will give it another go tomorrow and start out with a fresh copy of both source trees.. need to hit the shower before i hit the sack. :)
< Guest99499>
Will it come back to my Wallet
< sipa>
Guest99499: #bitcoin
< wumpus>
zelest: yes it might be that something left behind from earlier builds; also it's a good idea to pipe the build output to a file to see if the right compiler gets used