< petertodd>
no, bip66 doesn't deal with low-s/hig-s
< BlueMatt>
i know it doesnt
< BlueMatt>
but it easily could have
< BlueMatt>
i guess thats the malleability bip.....
< petertodd>
well, could ave posed problems with old wallets
< CodeShark_>
BIP62 does that - BIP66 was pushed out as a fix to a more urgent issue
< petertodd>
(low-s/ig-s isn't related to the urgent problem of OpenSSL consensus)
< petertodd>
it'd be interesting to know what exactly is slush running and/or and what parts of IsStandard() have been commented out
< BlueMatt>
I'm aware of the reasons
< BlueMatt>
but....its already in the fucking code......
< gmaxwell>
There is no filtering of low/high S malleability.
< BlueMatt>
dude, who the fuck knows what slush is running
< BlueMatt>
gmaxwell: isnt it nonstandard?
< gmaxwell>
NO
< gmaxwell>
:)
< BlueMatt>
ohhhhh
< BlueMatt>
somehow i thought it was
< gmaxwell>
We cannot filter it right now because filtering is incompatible with a great many signers.
< BlueMatt>
i thought we had whittled that down to like one or two wallets
< gmaxwell>
Even in BIP66 it was going to be version gated.
< petertodd>
gmaxwell: oh, I thought we had that in IsStandard()... that takes all the fun out of it
< gmaxwell>
BlueMatt: oh no, I really really doubt that. I think you're remembering chasing canonical encodings.
< gmaxwell>
I wish.
< BlueMatt>
i thought it was, at one point, just blockchain.info and like one or two other really strange wallets
< BlueMatt>
this was a long time ago
< BlueMatt>
I'm sure more exist now
< gmaxwell>
I wanted to talk to petertodd about this actually. an interesting thing to do would be to use the RBF code to prefer lows.
< petertodd>
gmaxwell: haha
< gmaxwell>
BlueMatt: like _anyone_ who doesn't use ECDSA code that came from us will make the wrong kind.
< petertodd>
gmaxwell: speaking of, python-bitcoinlib now does low-S right
< BlueMatt>
gmaxwell: yes, that much I knew
< BlueMatt>
but long ago there were't /that/ many other wallets :p
< BlueMatt>
easiest solution: get one pool to just change everything mined to low-S
< BlueMatt>
then people's wallets would break in largely harmless ways
< BlueMatt>
probably not entirely harmless, so maybe its dangerous
< CodeShark_>
one would hope ;)
< BlueMatt>
but I dont see anything that would obviously break without being trivially human-fixable
< CodeShark_>
I bet many wallets still track transactions by signed transaction hash
< BlueMatt>
most do, I'm sure
< BlueMatt>
but thats my point
< BlueMatt>
you'd show two txn
< BlueMatt>
and one failed
< BlueMatt>
(hopefully) not a huge deal anywhere
< CodeShark_>
in any case, this scenario is trivial to pull off so wallets that do think this is a big deal have a serious security issue
< CodeShark_>
karpeles excuses notwithstanding ;)
< gmaxwell>
I've brought up the mutate everythin approach, I think it's superior to just blocking completely.
< gmaxwell>
In any case, it's not hard to go measure this on the network, last time I did, it was ... all the non-canonical form.
< gmaxwell>
BlueMatt: it absolutely would break some wallets, but the same wallets are already super vulnerable.
< CodeShark_>
this raises an interesting point...BIP62 could be deployed along with a new relay policy that mutates transactions...
< gmaxwell>
Yes, its true. I'd only raised that before for lowS but its true generally.
< gmaxwell>
if your transactions are BIP62 friendly you get no mutation, otherwise you're always mutated.
< BlueMatt>
interesting deployment strategy :p
< gmaxwell>
for BIP66 we couldn't afford any debate, as we really needed to get the openssl consensus fix in, otherwise it would have been interesting to do it there.
< gmaxwell>
Even without the forced mutation, there is that RBF idea: if a lowS mutant comes in, replace.
< phantomcircuit>
gmaxwell, which pretty much instantly devolves into mutate everything :)
< gmaxwell>
means someone performing a mutation attack would have ~100% success on highS users and ~0% success on others.
< gmaxwell>
but absent an attack you're fine.
< gmaxwell>
in any case, still leaves the general BIP62 problem that we're really not sure we got all the mutation vectors. :(
< gmaxwell>
petertodd: fwiw this channel has existed since at least nov 2014.
< wumpus>
it was created because people didn't want the github commit notifications on #bitcoin-dev
< wumpus>
I think
< gmaxwell>
I've missed it but didn't want to join another channel and was too lazy to remember to do the thing to merge the windows in irssi.
< gmaxwell>
our commit volume is just not that high.
< btcdrak>
merge and pull request notification are very useful and will increase collaboration.
< paveljanik>
+1
< jgarzik>
+1
< wumpus>
exactly, and we don't have that many commits that it gets in the way of discussion
< CodeShark_>
are we still going to do the weekly core dev meetings on thursdays?
< CodeShark_>
at the same time?
< wumpus>
yes
< jgarzik>
yes
< gmaxwell>
I was assuming. I hope it goes more orderly than last time.
< gmaxwell>
perhaps we should +m the channel between subjects or something, so we don't get three overlapping subjects and it starts moving so fast some people can't keep up?
< jgarzik>
Fedora has an IRC meeting robot for logging, tracking agenda items, and notably, moving along from one item to the next
< jgarzik>
Many subgroups in the Fedora community have weekly IRC meetings and associated software gadgetry to help
< CodeShark_>
we just need to get the robot to come up with good ideas and code...and then none of us have to even be there :)
< wumpus>
I have the following topics: CLTV(/CSV/...) deployment, mempool management. Feel free to suggest others
< gmaxwell>
A lot of people (even IRC regulars) aren't really able to follow more than two concurrent discusisons.
< gmaxwell>
We had homework from the last meeting that we should have reminded people about 24 hours out... we were supposted to review mempool management PRs.
< Naphex>
wumpus: that hearnban was best thing all month / grats
< jgarzik>
wumpus, nod. It's not just taking minutes, but addressing e.g. gmaxwell concerns about multiple conversations going on at once. The btcdrak link shows much more than just meeting minutes: attendance log, actions resolved, to-do items and their owners, and more.
< wumpus>
Naphex: yeah, it was about time
< gmaxwell>
The multiple conversations don't bother me personally, but I _know_ some participants were left behind during the meeting because they couldn't keep up with the flood.
< gmaxwell>
For many years I used BitchX in a single window mode, while being in a dozen high traffic channels. :P
< wumpus>
jgarzik: I was not posting it to argue with btcdrak :) just for information, re: the 'homework'
< wumpus>
gmaxwell: I'm kind of slow so I have trouble following such things in real time :)
< gmaxwell>
Other people are less crazy and have not subjected themselves to that kind of torture and prefer mettings deal with less than 10 things at a time.
< wumpus>
I can read the English fast enough, these days, but following the chaos of different concerns at the same time can be problematic
< jgarzik>
btcdrak, I must be blind :) I see one other reference related to use case, HTLC
< jgarzik>
"ton of" == 2 :)
< btcdrak>
:) I'm guilty of hyperbole
< CodeShark_>
if the units are 1000 lbs, then yes, "ton of" == 2
< jgarzik>
btcdrak, In any case, yes, maaku cajoled me as well. :) It's on the shortlist for review & test. It's in the "mostly ok" column but I want to understand how it impacts current payment channel stuff in the field.
< CodeShark_>
its main purpose there is in providing a predictable amount of time to respond in the event a counterparty broadcasts a revoked transaction
< CodeShark_>
absolute time lock means we need to close the channel and reopen it when we're getting close to the timeout
< CodeShark_>
relative time lock means the clock starts ticking the moment the transaction gets in the block
< CodeShark_>
it also means you know exactly how long you'll have to wait (in number of blocks) before you can pull your funds out of the channel in the event of a noncooperative counterparty
< CodeShark_>
even if this were the only use case, I'd still say it's worth doing :)
< CodeShark_>
the only nit I can possibly find is around naming
< CodeShark_>
but as I've said before...meh
< jgarzik>
Sorry, got my BIPs mixed up. It's BIP 68 that I need to understand deeply & thoroughly.
< jgarzik>
redefinitions always make me nervous :)
< btcdrak>
jgarzik: Should be clear in the BIP68 text.
< jgarzik>
I wish BIPs were assigned 8-letter alphabetic codes; easier to disambiguate ;p
< wumpus>
I like the short numbers
< wumpus>
although I agre they're easy to confuse sometimes, but at least they stick in memory at some point
< jgarzik>
not for me - I have to keep jumping to the BIP repo for older ones not actively discussed, or brand new ones that just appeared
< TZander>
for rfcs there are simple lookups urls. So many a bot can be asked an rfc number and it will respond with the title
< wumpus>
we had that at some point, but it probably broke when moving to a git repo instead of the wiki
< jgarzik>
yeah, someone snag bitrfc.co and connect it to a bot
< TZander>
I saw a wiki that is backed by a git repo; best of both worlds.
< Aquentin>
I'm a bit scared, looks like a purge is going on...???
< sipa>
?
< Aquentin>
why was this channel created?
< CodeShark_>
to track merges and pull requests ;)
< TZander>
Aquentin: Channel #bitcoin-core-dev created on Mon Nov 17 2014
< Aquentin>
it didnt get a log bot until yesterday
< CodeShark_>
yes, now it also contains dialog
< Aquentin>
does jgarzick and gavinandresen have mod here?
< wumpus>
to avoid political meta discussion, and focus on develpoment of the Bitcoin Core project in github.com/bitcoin/bitcoin
< wumpus>
so strictly you're off topic
< Aquentin>
I know... but sometime some things are too important for strict rules... such as when there seems to be a purge, coup, ostricising, whatever
< wumpus>
last warning
< TZander>
wumpus: thats a bit harsh...
< wumpus>
I have to be, to avoid this becoming #bitcoin-dev again
< TZander>
I think thats what they are talking about when people say that resolving issues is best. Otherwise they tend to follow you around.
< TZander>
anyway #bitcoin-dev is kinda empty right now
< jonasschnelli>
that change did work on my local machines (osx/debian)
< jonasschnelli>
maybe L34 change is wrong... will double-check.
< TZander>
wumpus: I'm not the one that has to resolve your issues ;)
< wumpus>
TZander: you don't have to, working on open source is voluntary, but working on that repository is the point of this channel so please respect that
< Aquentin>
The way people work on open source is part of working on open source and it seems to me that you sipa and gmaxwell are on the verge of declaring yourselves emperors unless you give mod to jgarzick gavin and all other core committers
< Aquentin>
this isn't your project to dictate by ostracising
< CodeShark_>
go away
< stonecoldpat>
ugh, mod doesn't matter. People are here just to do work, please respect the channel.
< Aquentin>
course it matters... banning developers from contributing does matter
< * jonasschnelli>
hopes this channel keeps troll free and is used only for tech. topics
< btcdrak>
TZander: No it's not harsh, this channel is for core development discussions only and everything else is OT. If you want to have those discussions, take them to another channel.
< TZander>
btcdrak: hey, I'm not the one that got kick/banned. I just wondered about how fast a warning should come when someone (not me) askes who is a moderator here.
< CodeShark_>
we don't want that attitude in here, regardless of the specific question
< CodeShark_>
anyone can create their own channel and discuss whatever topics they like
< wumpus>
yes, it's not really about that question, just the way he came into here with the typical troll attitude. Anyhow, let's let it go.
< * wumpus>
does need to actually add more moderators at some point here, but it has nothing to do with who is developer or not
< michagogo>
11:57:10 <gmaxwell> For many years I used BitchX in a single window mode, while being in a dozen high traffic channels. :P <-- Uh. At that point, why not just use netcat? :-P
< Cocodude>
Is anyone seeing a lot of transaction malleability on the network again?
< wumpus>
michagogo: because bitchx was l33t and had lots of colors :)
< wumpus>
Cocodude: haven't noticed yet
< Cocodude>
Already had one user on Bittylicious threatening to take us to Trading Standards because BitPay's Insight says there was a double spend and "not to trust this transaction"!
< btcdrak>
jonasschnelli: can you add "You need to re-do ./autogen.sh and ./configure after this is merged" in the PR body, so it's clear for everyone.
< Cocodude>
(we're only using Insight as a URL to give to users to show their transaction details)
< btcdrak>
jonasschnelli: yes!
< wumpus>
well it's possible that someone is sneakily mutilating transactions on the network before relaying
< btcdrak>
Cocodude: Use another block explorer like blocktrail.com
< jonasschnelli>
btcdrak: Okay. Thanks for pointing this out.
< Cocodude>
btcdrak: Yes, I think I will
< wumpus>
Cocodude: do you have a copy of the tx hex of the original and conflicting transaction?
< Cocodude>
btcdrak: blocktrail.com is already great - it gives the transaction that is "Double spent by", which will help the user identify the real txnid.
< GitHub185>
[bitcoin] laanwj closed pull request #5079: Accept any sequence of PUSHDATAs in OP_RETURN outputs (master...op-return-accept-multiple-pushdatas) https://github.com/bitcoin/bitcoin/pull/5079
< btcdrak>
wumpus: meetbot is not setup for #bitcoin-dev, so better here.
< wumpus>
I understand, but well it's too late to announce a new channel for the meeting now, IMO. So more luck with that next week then.
< jgarzik>
Is it a Bitcoin Core meeting or bitcoin protocol meeting? If the former, have the meeting in here, and keep an eye on #bitcoin-dev for any stragglers
< btcdrak>
change the MOTD of #-dev to say it's here
< sipa>
i think we want to discuss things like the ongoing BIPs
< jgarzik>
MOTD + ML note + watch for stragglers and tell them
< wumpus>
well I guess both types of issues get discussed, e.g. rollout of softforks
< wumpus>
but also bitcoin core specific stuff like the mempool management
< jgarzik>
ok, #bitcoin-dev as planned
< jgarzik>
and suffer lack of meetbot :)
< sipa>
perhaps over time it makes sense to split them up... core meetings are probably useful more frequently than protocol meetings
< jgarzik>
~strikethrough~ was just typing same thing as sipa :)
< jgarzik>
they will most likely diverge eventually into two meetings anyway
< wumpus>
yes that makes sense
< Naphex>
why have this backwards compat?
< Naphex>
anyway
< Naphex>
then just move back to #bitcoin-dev and get jgarzik too stop removing the bans
< Naphex>
done
< wumpus>
Naphex, stop it
< GitHub35>
[bitcoin] jmcorgan opened pull request #6743: autotools: move checking for zmq library to common area in configure.ac (master...fixes/6679) https://github.com/bitcoin/bitcoin/pull/6743
< Naphex>
consider it stopped / but have been annoyed by all this stuff for months now
< wumpus>
we all have, but let's not pollute this channel with it :)
< maaku>
jgarzik: sidechain peg is another application. it was hard finding an example that stood alone however, hence the simple payment channel
< gmaxwell>
maaku: For CSV? there are a bunch; many look a lot like payment channels, but they're distinct. For example, 2 of 2 anti doublespend
< gmaxwell>
The parties today doing 2 of 2 anti-doublespend use nlocktime refunds, they'd later move to CLTV refunds, but the absolute time refunds are kind of lame compared to dynamic ones.
< maaku>
gmaxwell: thank you I'll see if I can work those out and add to the bip 112 document
< gmaxwell>
I'd prefer it be another bot so I can ignore it, I generally don't like that functionality, esp when the number gets used 10 times in an hour and its chatting up my backlog.
< wumpus>
it could remember what numbers it translated before I guess and refuse to expand them again within a certain time
< jgarzik>
Have humans be the limiters via explicit request. Use /EPR\s*#\d+/ to trigger a one-line expansion
< jgarzik>
Then you must proactively select to use "I am hacking on EPR# 1234" in a normal sentence
< Cocodude>
Sorry, quick lazy question - what's the bitcoind source file that defines the prefix for the pubkey and script address hashes?
< Cocodude>
I thought it was base54.h but it doesn't seem to be, at least in the later bitcoinds
< Cocodude>
sipa: Sorry again. It's all changed from when I looked at the code some time back. Do you know if there's a specific #define or similar any more for the magic numbers?
< sipa>
there is an array with all prefixes, initialized for each chain separately in chainparams
< btcdrak>
warren: I've PMd aj who owns the loggers.
< Cocodude>
base58Prefixes I assume?
< sipa>
yes
< Cocodude>
Ha. Right, I know where I went wrong. I was looking at the dogecoind source and realising the magic numbers didn't match up.
< Cocodude>
Sorry :p
< warren>
not sure if asking about the status of RCLTV is on-topic
< gmaxwell>
Can we talk some about the specific activities needed to get CSV ready for deployment?
< btcdrak>
shoot
< gmaxwell>
maaku has been busting his rear trying to get it in, and he'll do whatever it takes but I think right now its not precisely clear what the gaps (code or process wise) are that need to be filled.
< btcdrak>
I've asked a bunch of people privately to take a look, I'm not sure what else to do.
< btcdrak>
gmaxwell: they are all ready for merging from maaku's perspective. They have all been rebased.
< wumpus>
BIP112 is 'CSV' right? are the others depndent on that?
< btcdrak>
wumpus: BIP68 redefines nSequence, BIP112 creates an opcode for it.
<@wumpus>
aj: can you fix your bot please? it's entering and exiting all the time
<@wumpus>
btcdrak: okay, thanks
< maaku>
BIP68 / #6312 and BIP112 / #6564 are dependency-free
< maaku>
BIP113 / #6566 builds off #6312
< maaku>
(it's kinda silly to have BIP112/CSV without BIP68/sequencenumbers, but technically they do not depend on each other in the same way that CLTV does not actually depend on nLockTime doing anything)
<@wumpus>
aj: let me know when you fixed the issues, then I'll unban them again
< btcdrak>
maaku: so we could actually merge BIP112 now
< gmaxwell>
maaku: has there been any objections (at all) to BIP113?
< CodeShark>
wumpus, supybot didn't listen
<@wumpus>
they're all leaving
< gmaxwell>
maaku: I think I can make a pretty strong case that CLTV shouldn't go out without that one, simply because it changes the locktime semantics slightly... and we probably should not amplify nlocktime use right before changing the semantics.
< btcdrak>
gmaxwell: and in that case, it means BIP68 is required too.
< sipa>
bip68 doesn't change locktime semantics
< btcdrak>
since BIP113 builds on 68
< gmaxwell>
btcdrak: artifact of software.
< gmaxwell>
Okay, so it sounds like main limitations are just on software review.
< gmaxwell>
I know that PT had some specific documentation asks related to 68/112, basically he wanted more usecase examples.
< GitHub196>
bitcoin/master 5467820 ptschip: Migrated rpc-tests.sh to all python rpc-tests.py...
< GitHub196>
bitcoin/master 5ab5dca Wladimir J. van der Laan: Merge pull request #6616...
< GitHub91>
[bitcoin] laanwj closed pull request #6616: Regression Tests: Migrated rpc-tests.sh to all Python rpc-tests.py (master...all_python) https://github.com/bitcoin/bitcoin/pull/6616
< gmaxwell>
Which I think is reasonable. I suggested another candidate example space to maaku earlier today.
< gmaxwell>
though generally I think most CLTV cases can be restated 'But with relative locktime!' and end up with a more robust protocol.
< btcdrak>
gmaxwell: indeed
< * btcdrak>
is impressed. The number of open PRs has reduced by 11+ in the last 24 hours...
< Anduck>
closed or merged?
<@wumpus>
either
< btcdrak>
do we want a bot to expand pull request numbers to URLs in this channel?
< kanzure>
i am fine if the bot is only doing that
< kanzure>
(e.g. no (automatic) titlebot spam)
<@wumpus>
I don't think it should expand all pull request numbers, we use them too much here
<@wumpus>
but if it has an explicit command to request a pull request number expansion that's ok with me, eg if you usea specific syntax
< gmaxwell>
yea, thats good.
<@wumpus>
speaking of that, does anyone know of a good command line / ncurses utility to manipulate github pull requests? (through the API) Would like it but don't really feel like writing it.
< kanzure>
maaku: re: https://github.com/bitcoin/bitcoin/pull/6564 my concern was something about CSV-failing transaction rejection and then parent replacement if it was also in mempool, but nevermind i see why that's not important here