< jeremyrubin> Does anyone have any references on SIGHASH_NOINPUT + Schnorr and not enabling pubkey recovery? (I understand why it doesn't enable it, but I don't understand why we aren't adding a flag like SIGHASH_SIGNINGKEY). That or alternatives like OP_CHECKSIGFROMSTACK or OP_PUSHXDATA. Trying to get a general sense of the roadmap on these features and what's a solved problem or what's open design space still.
< jeremyrubin> sipa: ^
< jeremyrubin> jl2012: ^
< luke-jr> jeremyrubin: pubkey recovery is arguably an implementation detail
< sipa> pubkey recovery is not compatible with batch validation
< sipa> plus key/signature aggregation generally achieve the same bandwidth savings in a more generic fashion
< sipa> i'm not sure what sighash_signingkey would mean
< luke-jr> (aside from sipa's point) an implementation could already strip pubkeys from scripts and do recovery instead
< jeremyrubin> not interested in the bandwidth savings aspect
< jeremyrubin> More useful is the vault-like aspects
< jeremyrubin> (e.g., for very simple covenants)
< sipa> i don't see any problem with OP_CHECKSIGFROMSTACK
< gmaxwell> jeremyrubin: the recovery is signficantly slower to validate even ignoring the batch validation which it breaks. There is also a specific patent encumberance concern.
< sipa> as far as covenants go, if there is an actual desire for those, they should be supported in a first-class fashion (by having opcodes that make assertions on the spending tx), not only through a hacky pubkey recovery construction imho
< jeremyrubin> Ok, so if there were a feature which would be implementable as either a one-off feature, or via something that requires SIGHASH_NOINPUT & something which enables PubkeyRecovery (and excludes batching) that would be maybe an OK path?
< sipa> i don't see why you'd want that
< sipa> compared to alternative
< jeremyrubin> A one-off feature refers to what you said (first class feature)
< jeremyrubin> Do you have a sense or feeling about enabling somewhat generic covenant capabilities, or making an opcode that pretty tightly only enables one specific new feature?
< sipa> (to be clear: i'm giving my personal opinion on these things here, and not trying to predict what the developer ecosystem at large would think of such a hypothetical proposal; i can tell you i'm not personally interested in working on those things, though)
< jeremyrubin> That's fine, I'm just straw polling
< sipa> i suspect that to be a contentious question
< jeremyrubin> I would agree -- I think from a security perspective enabling the minimum new behavior is probably best
< jeremyrubin> but it feels similar to the MAST debacle
< gmaxwell> jeremyrubin: depends, like some generic thing that is inelegant is harder to justify than a specific thing, unless its really clear that the genericism is useful--- that it results in multiple interesting reasonably efficient things.
< sipa> jeremyrubin: generally my opinion is that for production usage, anything but the most efficient way of enabling a feature is not interesting
< gmaxwell> If the genericism is clean, doesn't result in difficult to analyize implications, and is clearly the compariable to the most efficient way to implement multiple interesting things, then that would be a case for it.
< jeremyrubin> Efficient is an interesting term...
< sipa> for experimentation purposes having generic opcodes that let you encode features at a low level are useful, but they're not really needed on mainnet to enable experimentation
< jeremyrubin> Gotcha.
< gmaxwell> sipa: a reasonable argument can be made that the highest efficiency isn't quite as important if the usage would be something like a taproot fallback case-- there more as a threat than anything else.
< luke-jr> gmaxwell: I thought the patent expired?
< sipa> jeremyrubin: to be clear, that latter statement is very much my own opinion, and i suspect it is not a majority view
< gmaxwell> luke-jr: no, not for a long time. (it might not be a _valid_ patent for various reasons, it also might not be applicable to any particular implementation, but my prior analysis was that it was enough of a concern that I wouldn't want to use it without a very careful analysis)
< jeremyrubin> Are there any backreferences on something like OP_GETOUTPUTHASH (or OP_CHECKOUTPUTHASHVERIFY) which takes an index and queries an output in the txn?
< sipa> gmaxwell: yeah, though orders of magnitude matter... if we'd have bignum arithmetic available you'd still not want to implement SNARK verification in bitcoin script :)
< gmaxwell> sipa: I agree with that view with the 'threat cases can be less efficient' priviso.
< sipa> i agree my "most efificent" is an exaggeration
< gmaxwell> jeremyrubin: some of the challenge there is that you probably want to be able to carry a small amount of data forward in the output, rather than just fixing it exactly.
< jeremyrubin> Well, for a more generic solution, perhaps.
< sipa> jeremyrubin: i have thought very vaguely about having some sort of tree matching construction that you can apply against the spending tx
< jeremyrubin> But if theres a motivating use case which has no 'data hazard' it's useful
< jeremyrubin> sipa: I've been working on this for like 2 years a little bit ;)
< jeremyrubin> there are some pretty interesting use cases for something like this IMO
< sipa> i suspect there are indeed
< jeremyrubin> gmaxwell: the way to carry data forward if needed would be to have a script which has branches and you pre-commit to all possible data values
< sipa> though i haven't seen much concretely beyond vaults
< jeremyrubin> but that's a bit messy
< jeremyrubin> sipa: I'm happy to share some of my research in a more limited setting as I want to make sure my proposal is more polished before spreading such ideas
< sipa> well i have no intention of working on these things myself... already buried in too many other work
< jeremyrubin> fair
< jeremyrubin> another possible implementation of this would be a segwit version which just commits to a set of outputs being created but has no scripting capabilities
< jeremyrubin> This sort of design ensures that there is *no* ability to branch on which UTXO gets created. This is good on the 'limited simplest implementation' front and easies to analyze, but I suspect people would want more.
< sipa> it would badly break fungbility if you need to announce in the output whether it falls under scripts or nonscript rules
< jeremyrubin> fungibility in terms of like a chain analysis tool?
< jeremyrubin> Ah -- I need to run to walk the dog before sundown, but will have a few other questions on this. Thanks for the input thus far!!
< sipa> jeremyrubin: i think it is generally advisable you can't distinguish different outputs tyoes (and to the extent possible, also when spending)
< sipa> that's the goal of taproot to a large extent
< sipa> avoiding revealing your policy to the world
< roconnor> #bitmetas
< roconnor> @jeremyrubin I had a chat with Bob McElrath about using SIGHASH_NOINPUT for a weak form of covenants.
< luke-jr> why is feature_segwit testing that one can explicitly generate a legacy address, take its pubkey, turn it into segwit, and send to that?
< luke-jr> I get that this works currently, but isn't that a behaviour we *don't* want?
< sipa> luke-jr: wellit's testing currently implemented functionality - even if that functionality is undesirable, it is currently intentional
< luke-jr> looking at the git history, it looks semi-accidental here at least
< luke-jr> it used to addwitnessaddress explicitly, but that got removed
< sipa> yeah, it's posaible the test can be rewritten in a way that matches expected workflows more
< luke-jr> hrm, trying to write an explicit test for implicit segwit stuff, and it's failing :/
< luke-jr> is it supposed to ONLY be implicit after a restart?
< sipa> no
< sipa> luke-jr: what are you trying exactly?
< luke-jr> sipa: I made a new address with getnewaddress, getaddressinfo to find the pubkey, convert that to each address type, send to them all, then make sure it shows a receive in listtransactions
< luke-jr> after a restart, legacy => others seems to work
< luke-jr> weird, even w/o the restart the second check works
< luke-jr> ugh, adding a sleep makes it work in the first loo
< luke-jr> self.sync_all() is helpful >_<
< bitcoin-git> [bitcoin] luke-jr opened pull request #15888: QA: Add wallet_implicitsegwit to test the ability to transform keys between address types (master...test_wallet_implicitsegwit) https://github.com/bitcoin/bitcoin/pull/15888
< bitcoin-git> [bitcoin] harding opened pull request #15890: Doc: remove text about txes always relayed from -whitelist (master...2019-04-whitelist-help) https://github.com/bitcoin/bitcoin/pull/15890
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #15891: test: Require standard txs in regtest (master...1904-testRequireStandard) https://github.com/bitcoin/bitcoin/pull/15891
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/40a720acb847...8cca1fbea9bc
< bitcoin-git> bitcoin/master 097c4aa Luke Dashjr: Bugfix: test/functional/rpc_psbt: Remove check for specific error message ...
< bitcoin-git> bitcoin/master c87fc71 Luke Dashjr: Bugfix: test/functional/rpc_psbt: Correct test description comment
< bitcoin-git> bitcoin/master 8cca1fb MarcoFalke: Merge #14818: Bugfix: test/functional/rpc_psbt: Remove check for specific ...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #14818: Bugfix: test/functional/rpc_psbt: Remove check for specific error message that depends on uncertain assumptions (master...bugfix_test_rpc_psbt) https://github.com/bitcoin/bitcoin/pull/14818
< wumpus> moneyball: hey, no suggested topics for today's meeting yet in https://gist.github.com/moneyball/071d608fdae217c2a6d7c35955881d8a ?
< MarcoFalke> i don't think there have been any
< MarcoFalke> #proposedmeetingtopic 0.18.0-final early next week?
< Sentineo> am not that good with git, but found a small thing that can was not working for me in the gitian build doc
< Sentineo> git push --set-upstream $NAME $VERSION-not-codesigned
< Sentineo> replacing $NAME with origin helps, just want to know if that is something to correct or my noobness
< Sentineo> I want to add 'git add $VERSION*' before that, so will create a PR, but not sure about the --set-upstream one
< Sentineo> Maybe that command is working for people who have the right to commit to the repo itself? I have to fork it and do the steps on mine and create a PR.
< MarcoFalke> Yeah, the guide assumes that your gpg key name is the same as you github handle
< MarcoFalke> git remote add $NAME git@github.com:$NAME/gitian.sigs.git
< moneyball> wumpus: only the topic MarcoFalke just proposed
< dongcarl> Question: if we're going to enable nat-pmp by default, should it go in depends and be statically linked in, or be subtree'd? What do we do for other dependencies like this?
< sipa> dongcarl: i'd say that for our normal static release builds, use depends, but from-source builds can use the system lib?
< wumpus> the initial idea (that we discussed last time) was to make it part of bitcoind
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/8cca1fbea9bc...c65c77c721b6
< bitcoin-git> bitcoin/master bb530ef Pieter Wuille: Disallow extended encoding for non-witness transactions
< bitcoin-git> bitcoin/master c65c77c MarcoFalke: Merge #14039: Disallow extended encoding for non-witness transactions
< wumpus> but I don't know anymore, there's been so much discussion in the issue, haven't really been following it
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #14039: Disallow extended encoding for non-witness transactions (master...201808_no_superfluous_witness) https://github.com/bitcoin/bitcoin/pull/14039
< sipa> wumpus: yeah i don't know either
< dongcarl> wumpus: right I believe there was some back and forth on that, I think luke-jr wanted it as a normal dependency
< wumpus> dongcarl: luke-jr is always contrarian on those things
< dongcarl> Okay, I want to make sure that the PR author doesn't get too confused. So if we're going to enable it by default, perhaps it makes sense to make it part of bitcoind.
< wumpus> I don't really like to go over all of this again; the main reason for not using it as a library was because the upstream library looked to be unmaintained, or at least have no new releases for years
< wumpus> but at this point I'd honestly be happy to see NAT-PMP *at all* at some point
< wumpus> there's been so much back and forth on this that I'm kind of losing confidence that this will happen at all
< wumpus> I'm *sure* the PR author is confused by this
< wumpus> we had this discussion, made some decision, then again and again he has to do something else
< wumpus> honestly if I were him I'd have given it up a long time ago
< bitcoin-git> [bitcoin] instagibbs opened pull request #15893: Add test for superfulous witness record in deserialization (master...test_super_witness) https://github.com/bitcoin/bitcoin/pull/15893
< dongcarl> Okay, I'm going to follow this and help him get it thru the finish line with the assumption that 1. It'll be on by default 2. we're going with the PR author's original approach and making it part of `bitcoind`.
< wumpus> thanks!
< luke-jr> dongcarl: NACK bundling
< luke-jr> bundling is basically universally considered a bad practice in the open source community; we have an excuse for consensus-critical stuff, but this is not that
< luke-jr> (and there are multiple very good reasons it is a bad practice)
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Apr 25 19:00:14 2019 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< jonasschnelli> hi
< wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb
< jamesob> hi
< sdaftuar> hi
< luke-jr> hi
< sipa> half here; will be there in 5-10 min
< wumpus> one topic was proposed in https://gist.github.com/moneyball/071d608fdae217c2a6d7c35955881d8a, anything else?
< wumpus> #topic high priority for review
< jamesob> can I get #15849 added? the change has been hanging out for a while, is generally useful, and I'd like it builtin for some work I'm doing on scheduler locks
< gribble> https://github.com/bitcoin/bitcoin/issues/15849 | Thread names in logs and deadlock debug tools by jamesob · Pull Request #15849 · bitcoin/bitcoin · GitHub
< wumpus> anything to add/remove?
< wumpus> jamesob:sure, added
< jamesob> thanks!
< phantomcircuit> wumpus, iirc the issue with nat-pmp was the quality of the upstream library more so than it's unmaintained status
< wumpus> phantomcircuit: ok
< wumpus> #topic 0.18.0-final early next week? (MarcoFalke)
< instagibbs> hi
< wumpus> seems a no-brainer, if no new regressions or critical issues come up, then -final will be tagged one week from last rc (which was monday)
< achow101> ack
< jnewbery> hi
< wumpus> there's #15665, if someone manages to reproduce it in detail to make a fix it'd make sense to do a rc5, but I don't think it's bad enough to block the release completely
< gribble> https://github.com/bitcoin/bitcoin/issues/15665 | 0.18.0 rc2 CPU spike in thread bitcoin-opencon · Issue #15665 · bitcoin/bitcoin · GitHub
< cfields> wumpus: fyi, I'll be away until Tues, so there may be a little delay in the win sig.
< jnewbery> I feel like #15141 could be close to ready. If sipa, aj or bluematt could look at it again, I think it may be ready for merge
< wumpus> cfields: no problem
< gribble> https://github.com/bitcoin/bitcoin/issues/15141 | Rewrite DoS interface between validation and net_processing by sdaftuar · Pull Request #15141 · bitcoin/bitcoin · GitHub
< wumpus> jnewbery: how does this relate to 0.18.0?
< jnewbery> oh sorry, missed that we'd moved on from #highpriority
< jnewbery> not related to 0.18
< wumpus> jnewbery: oh! makes sense
< wumpus> good to know it's almost ready
< sipa> here
< wumpus> any other topics?
< kanzure> hi
< instagibbs> micro-topic, did sipa or anyone email dev list about segwit v1+ output relay
< instagibbs> sorry if I missed it, I just think it's polite to announce it early
< sipa> i didn't
< wumpus> #topic segwit v1+ output relay announcement
< sdaftuar> that seems like a strange thing to announce imo? but fine of course if someone feels like it
< instagibbs> why?
< sdaftuar> if it has any impact on the network today then that seems bad!
< instagibbs> it might on wonky wallets or in some way we didn't consider :)
< sdaftuar> ie some service is being griefed or something
< sdaftuar> sure, no harm of course
< harding> instagibbs: you mean announce that it fixes wallets that try to send to v1 now but get their transactions rejected by nodes?
< sipa> i think it makes sense to try encourage wallet developers to support sending to future witness versions... and to the extent that a relay policy change contributes to that it's a good thing
< instagibbs> sipa, that too!
< luke-jr> seems like it belongs just in release notes, but who knows who reads those
< sipa> but it is not actually making any observable change to the network now
< sdaftuar> sipa: i agree with that, i just worry that pointing out that v1 relay currently doesn't work might have the opposite effect
< sipa> sdaftuar: ha
< * sipa> looks at harding for opinions
< instagibbs> Policy has been changed in the past and end-users(people building on top) end up quite surprised, ive seen it multiple times
< instagibbs> anyways, end of topic i guess
< moneyball> we could announce in optech newsletter?
< harding> I'm also worried that announcing that v1 doesn't work will cause wallet authors to disable it. I actually wrote docs suggesting that (not published) a couple weeks ago because that's what it looked like Bitcoin Core was encouraging.
< sipa> small topic: what is the status of the getdata randomization? i know it was reverted for 0.18, but for master it seems there were multiple solutions
< wumpus> #topic status of getdata randomization
< sdaftuar> sipa: i've got a PR in progress to fix the issues, working on a test as well (that's what's holding me up from updating the pr)
< luke-jr> :x
< sdaftuar> i guess he didn't like that answer
< sdaftuar> #15834, in case anyone is curious
< gribble> https://github.com/bitcoin/bitcoin/issues/15834 | Fix NOTFOUND bug and expire getdata requests for transactions by sdaftuar · Pull Request #15834 · bitcoin/bitcoin · GitHub
< sipa> i have returned
< wumpus> woohoo !
< sipa> 12:19:32 < sdaftuar> sipa: i've got a PR in progress to fix the issues, working on a test as well (that's what's holding me up from updating the pr)
< sipa> is the last i saw
< luke-jr> right after that [19:19:40] <-- sipa (~pw@gateway/tor-sasl/sipa1024) has left this server (Remote host closed the connection).
< wumpus> sdaftuar | i guess he didn't like that answer
< wumpus> sdaftuar | #15834, in case anyone is curious
< gribble> https://github.com/bitcoin/bitcoin/issues/15834 | Fix NOTFOUND bug and expire getdata requests for transactions by sdaftuar · Pull Request #15834 · bitcoin/bitcoin · GitHub
< wumpus> (and then gribble) that's all
< sipa> ok, thanks
< wumpus> any other topics ?
< wumpus> looks like no - short meeting this time
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Apr 25 19:25:55 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< anddam> aand I got my answer
< luke-jr> re NAT-PMP, apparently it's been deprecated since 2013 x.x
< wumpus> the entire protocol?
< wumpus> if so, in favor of what
< sipa> PCP was standardized in 2013 as a successor to the NAT Port Mapping Protocol (NAT-PMP), with which it shares similar protocol concepts and packet formats.[3]:87
< anddam> just to be sure, https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L3311 is not going to add any key with -keypool=0 , right?
< luke-jr> ^
< sipa> i suspect libnatpmp may support both
< * luke-jr> peers at sipa
< wumpus> I think that's a straightforward extension of it
< bitcoin-git> [bitcoin] hebasto opened pull request #15894: trivial, qt: Remove duplicated "Error: " prefix (master...20190425-duplicated-error-prefix) https://github.com/bitcoin/bitcoin/pull/15894
< instagibbs> MarcoFalke, master is failing tests, probably because of silent merge conflict with the superfluous witness check just merged
< sdaftuar> instagibbs: oops
< instagibbs> i added a test... but i didnt break al lthose other ones!
< instagibbs> #15893
< gribble> https://github.com/bitcoin/bitcoin/issues/15893 | Add test for superfluous witness record in deserialization by instagibbs · Pull Request #15893 · bitcoin/bitcoin · GitHub
< sdaftuar> yeah i see, how did travis not catch that?
< instagibbs> old PR
< instagibbs> never rebased?
< sdaftuar> hm, so it ran once and then never again i guess
< instagibbs> drahtbot closing and opening it could have saved us :P
< instagibbs> maybe
< sdaftuar> i'm deeply afraid that somehow i'm going to have to rebase 15141
< sdaftuar> and i'll have only myself to blame!
< instagibbs> oh great, this test is now passing locally for me, even better
< instagibbs> oh heh, our tests were accidentally making witness-marked txs with no witness data, and decoding it a different way yet still hitting the condition we were checking for
< bitcoin-git> [bitcoin] luke-jr opened pull request #15895: QA: Avoid re-reading config.ini unnecessarily (master...redundant_configini) https://github.com/bitcoin/bitcoin/pull/15895
< instagibbs> sdaftuar, is it impossible to hit "bad-txns-vin-empty" now?
< instagibbs> seems that way
< instagibbs> except for peering with non-witness peers I guess
< bitcoin-git> [bitcoin] luke-jr opened pull request #15896: QA: feature_filelock, interface_bitcoin_cli: Use PACKAGE_NAME in messages rather than hardcoding Bitcoin Core (master...qa_pkgname) https://github.com/bitcoin/bitcoin/pull/15896
< bitcoin-git> [bitcoin] luke-jr opened pull request #15897: QA/mininode: Send all headers upfront in send_blocks_and_test to avoid sending an unconnected one (master...qa_mininode_headers) https://github.com/bitcoin/bitcoin/pull/15897
< luke-jr> is someone fixing the Travis failure on master, or should I do it?
< aj> sdaftuar: you don't just want to reuse the tests from my pr for 15834?
< sdaftuar> aj: gah, i totally forgot you had tests written -- thank you, i will take a look
< aj> sdaftuar: heh. btw, i have some draft patches to reduce the number of 'notfound' messages; i don't think it quite gets all of them, but haven't figured out why not yet. top four commits of https://github.com/ajtowns/bitcoin/commits/201904-reduce-notfounds
< gmaxwell> 16:14:07 < ghost43> https://github.com/spesmilo/electrum/issues/5292 "BitPay BIP70 signing x509 cert has expired. Electrum will refuse to accept it."
< gmaxwell> 16:14:07 < ghost43> https://github.com/spesmilo/electrum/issues/5292 "BitPay BIP70 signing x509 cert has expired. Electrum will refuse to accept it."
< ghost43> does Core accept it?
< luke-jr> afaik it hasn't worked at all for Core in a while?
< ghost43> ( you can create one here https://bitpay.com/181852/donate )
< luke-jr> also, it would be a bug to accept it, not to reject it
< sipa> luke-jr: i think bip70 is optional at compile time, but still on in release binaries (including in 0.18)
< gmaxwell> I think we were planning on turning it off in the next major release?
< luke-jr> sipa: yes, but BitPay's "BIP70" isn't actually BIP70-compatible
< luke-jr> sipa: supposedly they reject payments if they see the transaction broadcast before they get it over payment protocol
< luke-jr> (or so I hear, I haven't tested it in a long time)
< ghost43> I think it's still compatible. last I tried, they did not reject, they are just threating they will. they are rejecting for shitcoins but not bitcoin
< luke-jr> ghost43: could be a race?
< sipa> luke-jr: yes, i know (not sure they actually enforce this, but to be fair... it's the only sensible thing to do)
< luke-jr> sipa: sensible or not, Core does do the broadcast
< sipa> i know.
< sipa> (and is following the spec by doing so)
< sipa> but the spec has always been pointless because of this
< ghost43> oh well that exemption is not for this broadcasting... hmm ok then not sure