< gwillen>
i.e. specifically why it is that mempool code needs to care about potential insanely-signature-happy transactions, but we don't need to worry that we might have to deal with one here?
< gwillen>
Is it that there is some reason one would not be possible, or just that such a transaction is so abusive that we never expect to see one in a non-adversarial context in practice?
< sipa>
gwillen: in the mempool crazy things are possible, because they're constructed by third parties
< sipa>
the size estimation code in analyzepsbt obviously only works for transactions that fully consist of inputs we at least understand
< sipa>
those crazy sigoo-limited transactions are not we're able to sign for regardless
< gmaxwell>
currently.
< sipa>
gmaxwell: can you imagine any where that isn't the case?
< sipa>
miniscript doesn't include anything where sigop cost would dominate either
< gmaxwell>
for sigops cost to dominate there needs to be reused signatures?
< sipa>
yes, by a factor 3x
< sipa>
and that is ignoring pubkey sizes
< gmaxwell>
okay, then no, I don't.
< gmaxwell>
(sorry, the currently was a thoughtless comment)
< gmaxwell>
and I hope in the future any sigops limits we do are just achieved via weight adjustment... (or at worst per txin limits...)
< sipa>
gmaxwell: weight adjustment is painful, as it means you can't compute weight without knowing utxos being spent
< sipa>
but otherwise i agree, i hope that going forward we can get rid of the two distinct resource limits
< gmaxwell>
sipa: with segwit you don't need to know the utxo, redeemscript is present in the transaction itself, always.
< gmaxwell>
though perhaps we sould make the version explicit in the transaction itself in future script versions!
< gmaxwell>
(for this reason!)
< MarcoFalke>
promag: fanquake: The gitian build takes about 12h for master and about 12h per pull (if it is in the same loop run). So the worst case for two pulls (assuming two loops are run for two pulls, because for example the second pull was labelled after the first one started) is 48 hours wait time.
< sipa>
gmaxwell: but you can't know from the spending tx what segwit version it is
< sipa>
say, there could be a p2wpkh spend that looks like a p2wsh
< sipa>
and with future witness versions this may become even harder
< gmaxwell>
we could fix that in future versions.
< sipa>
i don't think so
< fanquake>
MarcoFalke thanks
< gmaxwell>
luke-jr solve this problem for us.
< gmaxwell>
:P
< * sipa>
likes a rule that the sigop cost of a spend can't exceed its witness size
< gmaxwell>
We could fix it with a softfork that makes some classes of otherwise valid v1 scripts invalid.
< gmaxwell>
sipa: the idea of data stuffing (or never being able to have expensive opcodes) makes me sad.
< gmaxwell>
Esp with taproot where many features can mostly exist as threats more than reality.
< gmaxwell>
It would be reasonable to have absurdly expensive opcodes (e.g. like pairings), which are virtually never executed.
< sipa>
yeah, when there are opcodes that have a (much) higher cpu cost per byte than things we currently have, that approach isn't viable
< gmaxwell>
I dunno if pairings are there yet, but its at least plausable to me that they are.
< gmaxwell>
certantly if we use checksig as the standard of acceptable cpu/byte they are.
< gmaxwell>
as they're >10x worse.
< gwillen>
sipa: ok thanks that makes sense to me
< sipa>
gmaxwell: p2p/storage update that RLE encodes big zeroes in witness elements; then have a rule that every OP_PAIRING must be followed by a push of 100 zero bytes :)
< gwillen>
at that point you've pretty much turned it into size plus ops, you could just make the representation of each opcode equal in size to its op cost ;-)
< gmaxwell>
this did occure to me, but unlike you I had the good taste to not mention it. :P
< fanquake>
MarcoFalke what is the meaning of the egg
< echeveria>
be thankful we can validate unconfirmed transactions at all
< echeveria>
in ethereum you can't validate transactions really until they're in a block.
< gmaxwell>
it's not an accident...
< gmaxwell>
like, we've shot down and reformed proposals that make that harder.
< bitcoin-git>
[bitcoin] achow101 opened pull request #15588: Log the actual wallet file version and no longer publicly expose the "version" record (master...rm-wallet-nfileversion) https://github.com/bitcoin/bitcoin/pull/15588
< fanquake>
dongcarl what are you doing your testing with guix on? I've been running 0.16.0 with QEMU on macOS
< fanquake>
Currently looking at setting up a alpine/guix docker container for building etc.
< dongcarl>
fanquake: I’ve been doing it on my Arch machine... I haven’t tested nested containers yet unfortunately but you should give it a go and see if it works
< dongcarl>
Your normal OS is macOS I presume?
< fanquake>
Yea, running 10.14.x at the moment
< wumpus>
promag: it'd be nice to label all pulls that "fix something" -> this is what the "bug" label is for, in principle
< wumpus>
I don't think PRs get labeled with that in practice, but it was the idea
< wumpus>
but I fully agree it would be useful when you want to wade through the zillions refactoring PRs and find those that actually solve problems
< aj>
wumpus: maybe rename the label to "bugfix" then?
< wumpus>
bahh
< wumpus>
I mean, that would work less well for issues, but I don't think discussing names is very useful in any case
< aj>
wumpus: *shrug* it just never would've occurred to me to search PR's for label:bug
< kallewoof>
alternatively, we tag up the refactor PRs and you do "-label:refactor"
< kallewoof>
that could probably use an additional "is:pr"..
< wumpus>
but that gets features/documentation and all other categories as well, but ok good point
< luke-jr>
[03:24:13] <gmaxwell> though perhaps we sould make the version explicit in the transaction itself in future script versions! <-- like the witness v1 draft I did in ~2017? :P
< luke-jr>
(although I came away from that thinking it needed a substantial redesign)
< dta_>
chat
< dta_>
bip16?
< bitcoin-git>
[bitcoin] Sjors closed pull request #15567: Make OutputType consistent with Descriptor and return it (master...2019/03/descriptor-output-type) https://github.com/bitcoin/bitcoin/pull/15567
< newbie2019258_>
Hi guys, I got error message when I tried to use the /share/rpcauthrpcauth.py ANY help please?
< wumpus>
which error message ?
< newbie2019258_>
python ./rpcauth.py berlin2019RpcUser ---> File "/usr/lib/python2.7/hmac.py", line 50, in <lambda> self.digest_cons = lambda d='': digestmod.new(d) AttributeError: 'str' object has no attribute 'new'
< wumpus>
the script is prefixed with "#!/usr/bin/env python3" so it should find the correct python interpreter if you execute the script without specifying one
< newbie2019258_>
Yes, thank you, unfortunately I missed to check the shebang of the script.
< Sentineo>
is verify-commits.py broken? It jus returns "origin/master was not signed with a trusted key!". Not saying which key is to blame.
< newbie2019258_>
One more question please: After I added the rpcauth=... line into the config file (bitcoin.conf) how to need activate/accept, I mean maybe need to reload some service(s) or something like that? (I want to use the PHP wrapper to manage bitcoind over RPC)
< wumpus>
Sentineo: gpg --refresh-keys might help
< wumpus>
Sentineo: oh, it's broken here too
< wumpus>
sipa's key 0xAC6626172E00A82CFFAE8972A636E97631F767E0 has expired and trying to refresh it gives me "gpg: keyserver refresh failed: No data" :shrug:
< bitcoin-git>
[bitcoin] practicalswift opened pull request #15589: lint: Teach lint-whitespace.sh to detect missing newline at end of file (master...lint-newline-at-eof) https://github.com/bitcoin/bitcoin/pull/15589
< wumpus>
oh no more linting PRs
< wumpus>
can we stop doing that please ... :(
< gmaxwell>
might be a better use of time to tell people how to set color.diff.whitespace in their local git configs.
< wumpus>
I don't care about EOL at the end of files and other micro-aesthetic obsessions
< wumpus>
this is getting out of hand, has been for a while, maybe it's time to set a requirement that every PR fixes a reported problem
< gmaxwell>
\O/
< Sentineo>
is verify-commits.py broken? It jus returns "origin/master was not signed with a trusted key!". Not saying which key is to blame.
< luke-jr>
gmaxwell: isn't color.diff.whitespace the default?
< Sentineo>
hm sorry for pasting it again, exidentaly
< wumpus>
Sentineo you're repeating yourself
< wumpus>
ohh okay
< bitcoin-git>
[bitcoin] practicalswift closed pull request #15589: tests: Teach lint-whitespace.sh to detect missing newline at end of file (master...lint-newline-at-eof) https://github.com/bitcoin/bitcoin/pull/15589
< dongcarl>
fanquake: it would seem that all you need is docker --privileged to be able to nest. Lemme know if you encounter any problems.
< fanquake>
dongcarl Thanks, I've seen similar in some mailing list discussions. I don't think it should be too hard to get setup.
< dongcarl>
If you’re trying it out for the first time, I’d suggest using the install script and enabling binary downloads for packages. Otherwise you’ll be building the whole world from scratch
< fanquake>
:o
< dongcarl>
Haha yeah, very desirable for bootstrappability, but somewhat less so if you’re just trying things out haha
< dongcarl>
You’ll be prompted for it when you run the install script I believe
< fanquake>
Yea no worries, I'll keep a look out
< promag>
ryanofsky: I'm checking removing read access etc on walletdir and on each wallet file
< promag>
ryanofsky: I don't think it results in an infinite loop
< MarcoFalke>
Sentineo: It seems so. Please file an issue about that
< MarcoFalke>
Interesting that it took so long for someone to find out
< MarcoFalke>
Or instead of filing an issue, ping sipa to upload his unexpired key
< MarcoFalke>
hmm sub 4096R/C4EB3A28 2017-02-27 [expires: 2022-02-26]