< 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
< 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
< 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
< 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.
< 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
< 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
< 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)
< 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
< 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
< 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
< 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
< 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