< wumpus>
can we please stop doing the copyright pulls where half of github is highlightes
< wumpus>
if you really think it is necessary to add everyone that ever fixed a typo in a build script before adding a header to each individual file, ask yourself whether this is really worth it, you're generalling ten gezillion notification mails
< achow101>
by contributing to the repo, aren't you already implicitly agreeing to the copyright? So asking for everyone's permission is redundant.
< gmaxwell>
Why is that kind of thing being done by indivigual PRs rather than e.g. sending a mass email to all past contributors saying we're normalizing files in this and that way?
< gmaxwell>
achow101: that is unlear though it could be made clear.
< wumpus>
I don't know, but this getting out of hand
< achow101>
I though that was just kind of "in general" for all OSS projects
< wumpus>
achow101: that is what I always thought too
< wumpus>
there is a COPYING file in the rot of the repository
< wumpus>
root*
< wumpus>
if you don't put an explicit license in a file, that is what it is bound to
< wumpus>
but apparantly this is turning into a frigging zoo now, what's next, ahving to ask permision for every source line?
< wumpus>
what is this accomplishing?
< wumpus>
and yes, asking per email would have been preferable. Asking once per contributor, too. If that is really necessary.
< wumpus>
but we're not relicencing the project
< wumpus>
it has ALWAYS been MIT
< wumpus>
satoshi made it MIT
< wumpus>
I've been contributing to open source for 20 years and I've never, once had a mail whether I gave permission to add a license header (license of the project) to the top of some file
< wumpus>
I've been mailed a few times to approve of license changes, but that's a whole different and more serious thing
< wumpus>
and that was for real contributions not changing the case of one letter in one file
< achow101>
So what about adding this to the contributing.md: "By contributing to this repository, you agree to license your work under the MIT license and any subsequent licensing changes"
< wumpus>
not the last part
< wumpus>
only "By contributing to this repository, you agree to license your work under the MIT license"
< achow101>
ok.
< wumpus>
future license changes are absolutely out of scope, I wouldn't agree to that - who decides? changing licenses is a serious issue. Adding the existing copyright header that has been the project's license since 2009 isn't.
< wumpus>
I wouldn't be surprised with all this polling that people are starting to think we're changing licenses though ...
< luke-jr>
[01:45:21] <achow101> by contributing to the repo, aren't you already implicitly agreeing to the copyright? So asking for everyone's permission is redundant. <-- not with the MIT license
< luke-jr>
and hopefully people will stop submitting non-licensed code without getting permission first <.<
< wumpus>
such as?
< luke-jr>
wumpus: l_atomic.m4 until today
< wumpus>
let's revert it then?
< luke-jr>
came from a GPL-licensed project, with no license on the build stuff
< luke-jr>
nah
< luke-jr>
already got an ACK from the author for MIT terms
< luke-jr>
just something to keep in mind when stuff gets contributed by someone other than the original author
< wumpus>
maybe we should add that to #8786, that if you submit something from another source it is important to mention that source as well as the license it is under
< luke-jr>
+1
< wumpus>
hey, github review comments don't show as comments in the pull list
< wumpus>
but can I use it for that? the problem is that I have to manually keep track of groups of issues right now, but they don't warrant a new label
< achow101>
AFAICT, yes, you can use it for grouping related issues and PR's
< achow101>
although it seems that actually doing it might be a bit of a pain with the drag and drop interface
< achow101>
Stuff can be in multiple projects, and within projects are additional sub groupings (called columns)
< wumpus>
thanks, looks somewhat like hwat I'm looking for then, I'll read on about it
< * luke-jr>
wonders if projects are accessible to non-committers
< GitHub28>
[bitcoin] laanwj closed pull request #8186: [0.12.2] backport: getblockchaininfo: make bip9_softforks an object, not an array. (0.12...Mf1606-rpcBip9Backport) https://github.com/bitcoin/bitcoin/pull/8186
< cfields>
wumpus: I'll have a look in the morning. I've been distracted this week from the net stuff by the win32 toolchain crap. Got some neat stuff coming up as a result, though
< btcdrak>
I quite like the projects tab, much easier to see a project progress potentially over more than one release
< cfields>
jonasschnelli: heh, I just fixed the same thing for "bench" a few days ago, I need to PR it
< cfields>
jonasschnelli: sec for link
< jonasschnelli>
cfields: thanks!
< cfields>
jonasschnelli: fyi, link-order doesn't matter for apple's linker, but it does for gnu ld/gold
< jonasschnelli>
Yeah. I thought so and tried different orders,.. used the same the bitcoid does...
< jonasschnelli>
cfields: Thanks.. Let me try something..
< cfields>
jonasschnelli: should be pretty much copy/paste for you
< jonasschnelli>
okay.
< jonasschnelli>
btcdrak: A nice! We have projects now.
< btcdrak>
international standards for copyright is "belongs to author" by default unless employed by a company, then it belongs to the employer by default, unless there is a prior agreement. Licensing is not implicit however. You do need to be careful about code copied from other projects that have incompatible licenses. Since we use MIT that's generally not a problem
< btcdrak>
since MIT is generally quite permissive and compatible with just about anything.
< cfields>
jonasschnelli: note that if something is disabled (zmq for example), it'll just be blank, so skipped. No need to try to if/endif around them anymore
< btcdrak>
But in any case, users should be told the terms of submitting patches is that they license their work as MIT or if there is another license attached, they state that, and it is up to us to accept or refuse the patch (for example if the license was incompatible with our distribution).
< btcdrak>
Contributing should have a line about this.
< cfields>
jonasschnelli: sigh, sorry. I took a quick look at the failure and assumed it was the same problem. Obviously looking more closely, it's something different.
< jonasschnelli>
cfields: ah.. okay. But the amount of missing symbols should also point out that the linking order is wrong.. not?
< cfields>
jonasschnelli: yes, either busted link order or circular dependency
< murch>
gmaxwell: Re "selecting by taint": I've always been discounting that because I wouldn't be able to discern change and target outputs. I wouldn't get the behavior of one wallet, but rather incoming and outgoing payments from different users. You just made me realize that this might still be a useful dataset. Thanks
< cfields>
jonasschnelli: oh, i might know
< cfields>
jonasschnelli: as a kludgy test, try adding a convenience lib for the tool, containing most of the functions. Move main() to a separate file, and have that be the only source listed for bitcoin_wallet_tool_SOURCES. Then add the convenience lib to bitcoin_wallet_tool_LDADD
< jonasschnelli>
cfields: Okay. I'll try that.
< cfields>
jonasschnelli: see bitcoind as an example
< phantomcircuit>
jonasschnelli: any idea why we're asseting that locks are held instead of acquiring the lock in cwallet?
< phantomcircuit>
the locks recursive so it should be fine to just acquire it again
< cfields>
jonasschnelli: i can play around with it tomorrow (later) if it's still not working
< jonasschnelli>
phantomcircuit: Is there no overhead in acquiring the lock again? Couple of CPU ticks consumed?
< jonasschnelli>
cfields: Okay. I may try to play with it... but I guess I will fail. :) But no hurry
< cfields>
jonasschnelli: you should know by now that telling me "no hurry" guarantees it will never happen :)
< phantomcircuit>
wumpus: any idea if it costs more to acquire an already held lock than asserting the lock is held?
< jonasschnelli>
cfields: hurry up then! :)
< wumpus>
phantomcircuit: asserting that the lock is held is only enabled when log debugging is enabled, so that is the cheaper option
< wumpus>
it's really a sanity assertion
< cfields>
also, asserting means that you're not depending on the recursive lock and may be able to rip it out at some point :)
< gmaxwell>
murch: it would be approximate for sure.
< gmaxwell>
but I think worth analizing.
< GitHub79>
[bitcoin] jonasschnelli opened pull request #8788: [RPC] Give RPC commands more information about the RPC request (master...2016/09/rpc_container) https://github.com/bitcoin/bitcoin/pull/8788
< phantomcircuit>
wumpus: hmm
< phantomcircuit>
how expensive is it to acquire a lock when you already have it?
< phantomcircuit>
should just be a thread local check
< jonasschnelli>
phantomcircuit: Is there a reason for re-acquiring the lock? Why not acquire the lock from the caller instead in the called function?
< jonasschnelli>
But meh,.. depends on your layering.
< luke-jr>
even if we have recursive locks in some places, it's still not a good idea to use it recursively :/
< luke-jr>
jonasschnelli: your travis failed
< jonasschnelli>
Luke-Jr: thanks... looking..
< jonasschnelli>
It broke rest
< luke-jr>
jonasschnelli: part of the reason I didn't like that approach FWIW, was that now we need to look up the user twice :p
< jonasschnelli>
Luke-Jr: depends how you make the user<->wallet mapping..
< jonasschnelli>
But I think user-wallet-mapping is a different thing then RPC auth
< jonasschnelli>
But I would prefer selecting the wallet based on the endpoint or something within the RPC request
< jonasschnelli>
Selecting based on the -rpcuser makes it relatively complex to setup
< luke-jr>
even if we do so, most likely users should be restricted to only some wallet(s)
< jonasschnelli>
We could still do this... but multiwallet is probably simpler then multiwallet-multiuser
< luke-jr>
we already have multiuser :p
< jonasschnelli>
Yes. I meant simpler to not do mutliuser-multiwallet in the first step
< jonasschnelli>
If we would select the wallet depending on the endpoint, we could just use something like bitcoin-cli --wallet=<walletid> getbalance
< jonasschnelli>
where the bitcoin-cli tools would use --wallet=<walletid> to pass the request to /<walletid>
< luke-jr>
can do it with mu-mw already today - plus the code for it is written already *shrug*
< jonasschnelli>
Yes. But what if you want to wallet with a single user?
< jonasschnelli>
How would you select?
< luke-jr>
can't with the current implementation
< jonasschnelli>
*want two
< luke-jr>
doing that is more complicated IMO
< jonasschnelli>
I think its the more obvious use case (single user, multiple wallet=
< luke-jr>
I'm all for /?wallet=<walletid>, just don't think it's the ideal first-step
< luke-jr>
since we already have multiuser and even with wallet-selection-by-endpoint would want to lock it down
< jonasschnelli>
I'm also happy with /?wallet=<walleid> ... AFAIK it's simpler to parse /<walletid>
< jonasschnelli>
or /wallet/<walletid>
< luke-jr>
as I see it, endpoint wallet selection is an additional step beyond user permissions
< jonasschnelli>
Yes. But I think we need to solve singleuser-multiwallet
< jonasschnelli>
Either with ?wallet=<walletid> in request or /<walletid>
< btcdrak>
luke-jr why ?wallet=
< luke-jr>
btcdrak: doesn't step on REST stuff, and unlikely to conflict with future extensions
< btcdrak>
well thats not how to build REST interface
< jonasschnelli>
REST does not support wallet
< btcdrak>
query strings in REST are considered a very poor practice
< jonasschnelli>
query-string are in the same HTTP element (path)
< jonasschnelli>
Modern designs mostly use /<key>/<value> instead or ?<key>=<value>
< jonasschnelli>
Parsing is simpler, browser support better AFAIK
< phantomcircuit>
jonasschnelli: optimally cs_wallet would be private
< jonasschnelli>
Happy that our p2p encryption plans and not based on SSL
< jonasschnelli>
phantomcircuit: agree
< phantomcircuit>
the only way for that to happen is for the public methods to acquire the lock
< jonasschnelli>
I think its a bad design that cs_wallet can be (and will) accessed from the outside
< wumpus>
yes, the lock should be private
< wumpus>
"Operations in the DSA signing algorithm should run in constant time in order to avoid side channel attacks. A flaw in the OpenSSL DSA implementation means that a non-constant time codepath is followed for certain operations." happy we use secp256k1 instead
< sipa>
wumpus: note that this is about DSA, not ECDSA
< wumpus>
oh that's a different code path? I don't know openssl internals
< wumpus>
I mean it's the same operation on a different group, but they probably made a parallel implementation, okay
< sipa>
yeah, the ecdsa code is separate
< phantomcircuit>
CWalletTx::InMempool
< phantomcircuit>
wtf
< phantomcircuit>
jonasschnelli: why
< phantomcircuit>
WHYY
< wumpus>
which doesn't mean they don't have the same bug there , just waiting to be found :)
< sipa>
phantomcircuit: ?
< jonasschnelli>
phantomcircuit: The current wallet logic need to know that
< phantomcircuit>
sipa: abstraction violation to the max
< jonasschnelli>
But I agree,... couping the wallet with the mempool is bad!
< wumpus>
the wallet is allowed to communicate with the mempool in our case
< wumpus>
this is used for some things such as showing conflicts
< sipa>
phantomcircuit: we can't avoid that without breaking semantics
< wumpus>
I mean: this is a full node wallet, you have the mempool information, why not use it
< sipa>
it can be abstracted more cleanly (install a callback, etc), but functionally we need it, unfortunately
< jonasschnelli>
Yes. But maybe not directly accessing the mempool object. :)
< wumpus>
*the way* of communicating with the mempool may be wrong, that'sa another thing
< wumpus>
right.
< jonasschnelli>
We need to make this more flexible if we once like to have the hybrid SPV mode.
< jonasschnelli>
Which is – sadly – probably far away from being implemented. :)
< sipa>
we use the mempool as an estimation for whether a transaction may still confirm (and for example, refuse to spend unconfirmed output that is not in the mempool)
< wumpus>
yes sure, it would need a fallback with the information missing . Like not show unconfirmed transactions at all.
< wumpus>
that's essentially what is the case already during initial sync
< wumpus>
doesn't seem like any of the SSL issues are a serious problem for us
< wumpus>
I guess "SSL_peek() hang on empty record (CVE-2016-6305)" can apply to qt's usage of SSL, then again, the server hanging the connection isn't really that interesting
< wumpus>
paveljanik: curious, almost all of the functions that are changes change in the binary
< wumpus>
looking at WalletModel::WalletModel now
< paveljanik>
interesting
< paveljanik>
I still have to investigate's Marco's finding about reverselock's change changing the binary. It was only lock -> _lock...
< wumpus>
looks like some ebp relative local variables change address, but I don't understand, it's really just a variable renaming
< paveljanik>
but only in QT binary
< paveljanik>
bitcoind untouched...
< wumpus>
yes
< paveljanik>
do we compile Qt somehow different?
< wumpus>
I use the same build and comparison process that I use to cmpare bitcoind binaries
< wumpus>
well qt has qrc passes
< wumpus>
moc, I mean
< wumpus>
which automatically generates some code for signal/slot dispatch, property setting, and such
< wumpus>
that may be what happens here, I don't know
< wumpus>
I'll check if this is restricted to consturctors
< wumpus>
paveljanik: in the case of void WalletView::setClientModel(ClientModel *_clientModel) I think I know why: you haven't changed the latter two statements to refer to the new parameter name
< wumpus>
paveljanik: they now refer to the memner variable
< wumpus>
member*
< wumpus>
same for WalletView::setWalletModel
< wumpus>
the otherwise-empty constructors remain a mystery though
< paveljanik>
will fix both...
< wumpus>
ok let me know when you pushed then I'll redo the binaries check
< paveljanik>
done
< wumpus>
building
< paveljanik>
coffee ;-)
< wumpus>
good idea
< sipa>
just had one
< paveljanik>
Kenya AA Top Superstar - macchiato :-)
< wumpus>
paveljanik: that worked, those two functions are gone from the list now - only constructors left
< wumpus>
I'll just say this is fine, I don't have time to investigate the assembly and data in detail now, and I don't think this can be avoided
< paveljanik>
wumpus, yes, thanks for investigation!
< paveljanik>
I'll double check the rest of the functions in the list
< paveljanik>
Hmm, in WalletView::WalletView, I use platformStyle and not _ platformStyle...
< paveljanik>
I have to say I prefer the usage of member-initialized member variable to an argument in the body of the functions...
< wumpus>
yes, I don't think it's an improvement
< wumpus>
let's just leave it at this
< wumpus>
it's explained
< paveljanik>
well, but this means that binaries will be different :-(
< wumpus>
yes, but we are capable of creating a patch that won't change the binaries, it's just ugly
< wumpus>
+larger
< paveljanik>
but its correct (QED)
< sipa>
i think having a patch available to removes the differences is enough
< sipa>
the changes are trivial anyway
< wumpus>
well I've also reviewed the changes and they look ok, this is just qt anyhow and not consensus code
< wumpus>
right sipa
< paveljanik>
yup
< JackH>
Is there any reason to think that Bitcoin wont eventually be taken over in terms of usage by Ethereum (serious question)
< JackH>
Since it seems as if it has become the darling of the current payments industry, despite its failures. The "best" or most "safe" solution does not always take the prize
< JackH>
I am just thinking in terms of opening up Bitcoin, beside fixing malleability, if there is anything on the table?
< wumpus>
#bitcoin
< JackH>
#futureofbitcoin in here? (conceptually)
< JackH>
ah shit
< JackH>
I am not in wizards
< JackH>
sorry
< JackH>
this is akward...
< wumpus>
wizards is about cryptography and moonmath, it's also not the place to discuss comparison to altcoins
< haakonn>
JackH: eth is the darling of the "blockchain industry", not the payments industry (what can you pay for with ethers?)
< haakonn>
agh, sorry for the noise, thought this was #bitcoin
< helo>
you had me convinced :P
< instagibbs>
when running make check is there a way to get a stack trace on failure
< instagibbs>
error is happening in some helper function, and no useful info about when it's happening
< GitHub197>
[bitcoin] jonnynewbs opened pull request #8796: [trivial] fix mempool comment (outdated by BIP125) (master...trivial_comment) https://github.com/bitcoin/bitcoin/pull/8796
< btcdrak>
meeting time?
< instagibbs>
in an hour?
< achow101>
you're an hour early
< btcdrak>
oh woops
< kanzure>
btcdrak: i propose we deprecate timezones
< jcorgan>
and DST
< btcdrak>
yes
< achow101>
kanzure: ask IANA
< murch>
kanzure: Yes, let's all just use UTC all year long.
< btcdrak>
achow101: more like ask Trump
< achow101>
Hah!
< gmaxwell>
shh.
< sipa>
murch: another thing we should learn from icelanders
< cfields>
here for meeting, but dog's pacing at the door. Back in ~5.
< gmaxwell>
Don't start a big OT discussion right before the meeting.
< wumpus>
#startmeeting
< lightningbot>
Meeting started Thu Sep 22 18:59:48 2016 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< wumpus>
<jl2012> It seems the risks is too much comparing with the benefit
< wumpus>
yes what ever time you pick it's always unfriendly to someone
< btcdrak>
I was discussing this with him yesterday. I also think it should be dropped.
< btcdrak>
wumpus: we should find a time that is unfriendly to everyone :)
< wumpus>
#topic Drop reuse sighash computations across evaluation #8654 from 0.13.1?
< gmaxwell>
wumpus: wasn't a complaint, just reminding people of it. :) (and we can all make an effort to stand in for people who can't make it)
< wumpus>
gmaxwell: something else we could do is have e.g. alternating times every week
< sipa>
yes, i'm in favor of dropping it. i believed the advantages were larger first
< wumpus>
but given that people already have a hard time being there intime for a meeting with a fixed time... :-)
< sipa>
but it seems we'll need more changes anyway than we can tolerate for 0.13.1
< gmaxwell>
So re: that PR. We can do it later. We've survived thus far without it.
< btcdrak>
yes.
< wumpus>
ok
< wumpus>
removing 0.13.1 milestone from it
< petertodd>
how much worse is the maximum O(n^2) time for segwit? my understanding is that w/o segwit in theory even dozens of minutes are possible anyway
< sipa>
petertodd: the same
< petertodd>
sipa: but can't you get more checksig ops w/ segwit?
< sipa>
petertodd: as segwit inputs only hash the entire transaction at most once
< sipa>
see bip143
< gmaxwell>
petertodd: IIRC. this change is primarily fixing the non-segwit case. The plain hashcache in segwit already optimizes segwit so its basically solved under segwit.
< jtimon>
hi
< sipa>
petertodd: the worst case for a pure segwit-inputs transaction is around 6 ms per block
< gmaxwell>
so the non-segwit cases are the worst case, but we have determined that exploiting some additional caching oppturnities radically reduces that worst case when coupled with a few inconsequential additional limits.
< petertodd>
gmaxwell: ah right, because of how we changed SIGHASH_SINGLE behavior
< sipa>
petertodd: all sighashing is changed in segwit
< petertodd>
alright, I'm ACK to remove that for 0.13.1
< wumpus>
great
< petertodd>
sipa: well sure, but SIGHASH_SINGLE is changed in substance significantly :)
< gmaxwell>
petertodd: right but the reason segwit doesn't have the n^2 blowup anymore is the general change so that the hashing work across inputs can be shared.
< sipa>
petertodd: hmm? they're all changed in a very similar way, with the whole-transaction parts precomputed rather than inlined
< achow101>
are #8634 and #8499 and #8526 ready for merge?
< wumpus>
that's a new topic proposal achow101?
< achow101>
just a question
< gmaxwell>
related topic at least.
< btcdrak>
well they were part of last week's homework
< wumpus>
jonasschnelli: right, if we do that it should be something documented in the release notes of a major release
< jonasschnelli>
ack
< jonasschnelli>
People probably built apps on the "strange" listsinceblock behavior.
< wumpus>
exactly
< jonasschnelli>
remved the 0.13.1 ms from 8757
< wumpus>
okay that leaves four to go
< BlueMatt>
wumpus: wait, we're unmarking compact blocks for 0.13.1?
< BlueMatt>
(you just did)
< gmaxwell>
re the listsince blocks The complaint is that conflicts are always shown and the proposed change made them never shown?
< btcdrak>
regarding segwitcb, roasbeef's scripts are running spamming testnet. If there are any miners pointing hash at testnet, can they set "-blockmaxweight=4000000", leaving off any other related params so we get more bigger blocks.
< wumpus>
BlueMatt: uh
< gmaxwell>
BlueMatt: wat?
< BlueMatt>
@laanwj laanwj removed this from the 0.13.1 milestone a minute ago
< instagibbs>
er did someone remove the segwit cb?
< wumpus>
that was a mistake
< BlueMatt>
I assume that was accidental
< wumpus>
please readd
< BlueMatt>
#8393
< gmaxwell>
unclick
< BlueMatt>
ok, so 5 to go
< jonasschnelli>
readded
< instagibbs>
4 PRs, one related issue
< sipa>
you take one down, pass it around, 5 PR to g
< * BlueMatt>
is not sure how to feel about #8526...it'll surely end up merged onto master before segwit activates...agree its nice to have things "clean from the start", but do we define clean as policy in 0.13.1 or policy on master/0.14?
< gmaxwell>
if you just want the percentage to go up, feel free to add tags to closed prs that got backported but were never tagged 0.13.1... There are many. :P
< wumpus>
yes good point btcdrak PSA: I've started using the new feature of github projects for tracking a few longer-running projects: https://github.com/bitcoin/bitcoin/projects
< BlueMatt>
same with 8634
< paveljanik>
wumpus, nice!
< BlueMatt>
or, really, what about ignoring #8634 and #8526 and going to solicit feedback for segwit dates after the other ones are in, and then if they make it in before we get date consensus, then they go in, otherwise no
< gmaxwell>
minor meta aside, is there any facility for backing up and retaining all this new github stuff?
< BlueMatt>
gmaxwell: havent looked, but the github api has historically been very, very complete
< BlueMatt>
so i ass-u-me so?
< wumpus>
gmaxwell: that's iwilcox's department (but he's not here)
< wumpus>
but yes I guess it's available on the API if you know where to look, or it will become available, as BlueMatt says
< gmaxwell>
BlueMatt: 8526 when it goes SF could plausably conficate coins, so it's more important to have it non-standard from the getgo.
< gmaxwell>
and 8634 is done but for a squash as far as I can tell.
< wumpus>
already created an action for #8634, we're repeating ourselves
< BlueMatt>
gmaxwell: I'm not sold on it needing to be in anything but master before release, but, ok, in any case, i'd propose we start looking for date-consensus after #8279 and #8499 are in
< BlueMatt>
(ie lets start looking for date consensus like...soon)
< achow101>
like.. now?
< sipa>
no, not now
< instagibbs>
achow101: no, after critical updates are merged
< sipa>
first know when we can possibly have a release
< BlueMatt>
like...in a few days after the non-critical ones are merged
< btcdrak>
BlueMatt: well we need #8393 merged too before we can be sure to set dates
< BlueMatt>
btcdrak: sure, fine, #8393, #8279, and #8499, then dates?
< btcdrak>
ack
< sdaftuar>
i believe 8279 is sufficiently resolved for 0.13.1
< wumpus>
let's try to finish those pulls this week then we can talk about the release next meeting
< gmaxwell>
BlueMatt: do we know what the status of btcd's SW support is?
< BlueMatt>
gmaxwell: thats part of soliciting consensus on dates :p
< btcdrak>
ping roasbeef
< BlueMatt>
(ie reaching out to non-bitcoin core people)
< gmaxwell>
BlueMatt: well I've been doing that for a while. that doesn't have any binding on pending PRs.
< instagibbs>
wumpus: ack
< wumpus>
sdaftuar: ok, so let's remove that issue from the 0.13.1 milestone, but not close it
< sdaftuar>
wumpus: sounds good to me
< sipa>
wumpus: sounds good
< gmaxwell>
btcd is the only active alt implementation that I'm aware of that didn't respond to my "when do you think you'll work on this" with a "only after it's locked in on the network".
< gmaxwell>
BlueMatt: in any case, out of meeting lets try to work on a list of required actions for the activation.
< wumpus>
makes sense to reach out to them then
< btcdrak>
well in terms of wallet code and supporting libraries, there are many which are SW ready, or have it almost ready to go.
< gmaxwell>
yes.
< petertodd>
python-bitcoinlib has a fairly good pull-req for segwit
< wumpus>
awesome
< gmaxwell>
mining software was in a sad state last time I checked, but I know things have improved a lot.
< gmaxwell>
in any case, many things to discuss there that don't need everyone. :)
< roasbeef>
will be starting to finalize my segwit stuff for btcd starting tomorrow, have been busy with lightning stuff and getting btcd up-to-date with past recent soft-forks (CSV, etc)
< petertodd>
roasbeef: +1
< roasbeef>
primarily need to improve the test coverage, and make changes like cost->weight and the nulldummy stuff
< gmaxwell>
roasbeef: fantastic.
< cfields>
i keep meaning to return to patching miners but getting distracted. Feel free to ponk me if there's some mining software that actually gets used that needs to be updated.
< achow101>
armory is.. getting there. We're aiming for the release after the next to have full segwit support
< petertodd>
achow101: thanks!
< gmaxwell>
achow101: thats a good timeframe, really no one should be using it the instant it activates, except for testing.
< btcdrak>
oh I didnt know you work on Armory achow101 +1
< CodeShark>
my stuff is almost 100% segwit ready, just need merkle proofs for witnesses in filtered blocks or some better SPV solution
< petertodd>
gmaxwell: I'll probably switch opentimestamps to use segwit, but that's a maximum loss of something like $20 :)
< gmaxwell>
It's just good to hear that more things are almost read, as it's another angle of testing.
< Chris_St1>
CodeShark: What BIP is that related to?
< CodeShark>
We don't have a BIP yet, I don't think
< sipa>
Chris_St1: that will need a new bip
< sipa>
it's trivial (just combine bip37 with bip141 wtxids)
< Chris_St1>
ok, gotcha.
< gmaxwell>
Chris_St1: he wants something like the filtered block messages that provide witnesses too. (the opposite of what most SPV wallets do, but codeshark extracts participant data from witnesses)
< sipa>
but it needs to be fleshed out... and i don't know how keen people are on extending bip37 further
< CodeShark>
I'd prefer a replacement to bip37, but that's more involved
< Chris_St1>
BIP37 is definitely a monster in terms of implementation... or atleast it was for me
< gmaxwell>
We could probably do better.
< sipa>
at least we could propose to drop some of the auto-inserting that causes false positive rate blowup
< petertodd>
note that it's reasonable to ask for a full block even if you are a lite-client in many cases
< BlueMatt>
CodeShark: uhhhhhhhhh, that sounds like a blocker
< gmaxwell>
petertodd: Satoshi's vision.
< btcdrak>
petertodd: such as?
< jtimon>
I guess he means as a way to get more privacy?
< sipa>
BlueMatt: how so?
< BlueMatt>
it seems to me it is impossible to use the bloom-filtered connection stuff in segwit....I mean we can decide to not support it because its bad, but we need to actively decide that
< petertodd>
no, I just mean that the data increase is relatively low
< gmaxwell>
BlueMatt: wut? hell no. I am aware of no other SPV client than codeshark's that does _anything_ with the witness data right now.
< jtimon>
no tevealing which txs you care about? just thinking out loud...
< sipa>
BlueMatt: spv wallets shouldn't care about the witness data
< sipa>
hell, it's an advantage that their bandwidth will drop
< petertodd>
sipa: indeed, they can't verify that the witness is valid
< gmaxwell>
BlueMatt: it works fine, you just don't get witnesses, which is an intentional and desirable outcome thats actually listed on the segwit advantage sheets. For the most part they can't do anything with the data.
< CodeShark>
wallets that don't tell you who signed a multisig are incomplete ;)
< gmaxwell>
There should be some option for those who want it, sure. Though they can also fetch the whole block, so its not a big deal even there.
< petertodd>
CodeShark: well, that's an example where you can request a full block - not many wallets need to actually know that
< petertodd>
CodeShark: as an example, I don't think GreenAddress will tell you who actually signed txs in a GA wallet
< CodeShark>
it's critical for enterprise applications
< CodeShark>
Accountability is important
< petertodd>
CodeShark: enterprise can afford some extra bandwidth I'm sure :)
< achow101>
I think we're getting OT
< petertodd>
CodeShark: this isn't a blocker is all I'm saying
< CodeShark>
we can revisit this after 0.13.1
< gmaxwell>
It's also not news or an accident.
< wumpus>
no one is considering it is a blocker except for BlueMatt
< petertodd>
CodeShark: ack
< BlueMatt>
gmaxwell: sure, I'm saying that you cant use segwit as an spv client
< sipa>
BlueMatt: of course you can?
< gmaxwell>
BlueMatt: thats not true.
< petertodd>
BlueMatt: note how with segwit, your txids aren't malleable, therefore you can add the txids of outputs in your wallet to your bloom filter and be sure you'll know if they get spent
< BlueMatt>
gmaxwell: however, in cases like a scripthash, you previously are able to see things that were to your public, or partially to your pubkey
< BlueMatt>
which you might want to
< BlueMatt>
petertodd: you already do that, the malleability doesnt help
< Chris_St1>
May be a stupid question, but are we refering to 'blocker' in the context of blocking 0.13.1 or downloading a full block?
< * BlueMatt>
isnt recalling exactly what the use-case was for scriptSig matching, but you now can no longer do that
< petertodd>
BlueMatt: true, once confirmed
< wumpus>
Chris_St1: I think it would be really ill-advices to add a blocker for 0.13.1
< jtimon>
Chris_St1: the former
< petertodd>
BlueMatt: I take back that comment
< petertodd>
anyway, we can agree that anything fixing this is non-consensus, right? therefore it's not relevant for 0.13.1
< gmaxwell>
BlueMatt: I carefully went through the code base of some three different wallets to confirm there were no complications there. Of course, it also does nothing to _existing_ software.
< BlueMatt>
gmaxwell: i take back my comment, i no longer recall why we needed to match scriptSigs...maybe we didnt need to
< sipa>
i think there was no reason for that, indeed
< BlueMatt>
but it is the case that you lose this property of matching pubkeys which were used
< sipa>
and if there is, we can still add it back
< BlueMatt>
sipa: well, you might want it, but not a ton
< gmaxwell>
which all works fine. And so even where there are things that want that data (which appear to be almost none of them), they can be accomidated later. The most common case (of not needing it) is already accomidated. And all existing things are unchanged as well.
< petertodd>
I can imagine silly embedded consensus applications where it'd be useful... but supporting that is definitely not a priority
< wumpus>
at this point we should be careful to only let critical problems block 0.13.1, not everything that would be nice for some applications
< Chris_St1>
BlueMatt: Matching scriptSig constants in BIP37 right?
< BlueMatt>
wumpus: well, if it were the case that you couldnt match properly in segwit it would be bad, but it seems that you're fine
< wumpus>
BIP37 can be extended, sure
< BlueMatt>
Chris_St1: bip37 only ever matches constants
< wumpus>
but that's not yet another reason to move forward the release
< BlueMatt>
agreed
< achow101>
topic proposal: alert system retirement
< gmaxwell>
AFAICT the only 'utility' of that matching was degrading privacy by tainting the filter with FPs on extrainous data. :P
< instagibbs>
8 minutes left
< BlueMatt>
we might fix this by throwing out bip37 and doing something not-batshit-insane, but thats an aside from the meeting
< BlueMatt>
gmaxwell: yup
< gmaxwell>
BlueMatt: yup.
< CodeShark>
I want a good fairly secure quick sync solution. BIP37 sucks :p
< gmaxwell>
Okay I sent out an email on this. Mostly well recieved (at least in public). I went and bludgenoned alt implementations into removing the alert key and only got mildly bloodied in the process.
< petertodd>
gmaxwell: sounds like it's time to set dates
< gmaxwell>
My view on the next steps:
< gmaxwell>
(1) Create a bitcoincore.org or bitcoin.org announcement message.
< gmaxwell>
(2) send a penulitmate alert with more polite text than the COMPROMISED message that directs people to it.
< gmaxwell>
(3) much later, send final alert.
< wumpus>
I'd say we send the final alert with the 0.14 release
< gmaxwell>
(4) hardcode nodes to send the final alert to peers to overcome the lack of propagation. (just using the one or two lines of code needed to send a static message, not pulling back any alert code)
< wumpus>
then include code in there to send it to old peers that connect, as gmaxwell says
< BlueMatt>
gmaxwell: ACK
< BlueMatt>
wumpus: ACK final alert with 0.14
< jtimon>
ack
< achow101>
ack
< petertodd>
gmaxwell: and release the privkey for the alert key w/ the final alert?
< btcdrak>
ack
< gmaxwell>
I think we can do 1/2 in the next week. I'm not aware of any reason to delay, and there are propagation advantages to doing it earlier rather than later.
< sipa>
i'd release the key later even
< petertodd>
gmaxwell: ack
< instagibbs>
make sure to sweep the funds people have sent to the key :P
< petertodd>
instagibbs: ha
< roasbeef>
btcd still has the code in place to parse the alert messages, but we simply drop-it-like-its-hot once recv of the message without any further processing (and have since early last year)
< BlueMatt>
sipa: ack
< sipa>
there may be alternate codebases that use the key who want to do something similar to (3) and (4)
< sipa>
oh, wait
< sipa>
they need the key for that
< BlueMatt>
2 min
< instagibbs>
any pressing topics
< wumpus>
well after the final alert is sent, the key is only historical curiosity
< gmaxwell>
okay, I'll send a message to the list.
< luke-jr>
can the final alert match all clients?
< wumpus>
luke-jr: you mean the pre-final alert, and yes
< petertodd>
wumpus: yeah, once that final alert is sent, I doubt releasing the key will do any harm
< gmaxwell>
It cann't not match all clients.
< wumpus>
gmaxwell: I think he means the penultimate alert
< wumpus>
obviously the final alert matches all clients, at least those that still parse alerts
< gmaxwell>
petertodd: if I can parition your network I can make your client show "Your bitcoin is outdated and vulnerable. You MUST download an update to continue. http://bitcoinscam.eu/"
< wumpus>
gmaxwell: wasn't that the point in adding it to the client?
< gmaxwell>
I was thinking of limiting the applicability of the penultimate alert to users of Bitcoin Core, open to suggestions.
< petertodd>
gmaxwell: sure, but that'll have been after months of alert - I'm not worried there
< wumpus>
it applies to everyone using the key, not just users of bitcoin core
< gmaxwell>
in any case, can continue after, we should wrap the meeting. :)
< petertodd>
gmaxwell: I'd be inclined to provide it to everyone - it's a warning that everyone will soon have a final alert
< instagibbs>
ding ding
< btcdrak>
ding ding ding
< wumpus>
yes it's time
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Sep 22 20:01:03 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< wumpus>
this is not bitcoin core specific but everyone-that-embeds-that-pubkey specific
< Chris_Stewart_5>
CodeShark: Did you have any concrete ideas for improving on BIP37?
< gmaxwell>
petertodd: the reasoning I had for that thought is I think it should provide upgrade advice. And I don't want to give update advice to people who insist on running software I consider broken and dangerous.
< petertodd>
gmaxwell: I think the upgrade advice can be general "whatever you are running, upgade"
< petertodd>
gmaxwell: equally, it can just be a warning that you will soon see a final alert, as the alert system is being depreciated
< wumpus>
yes, it can just be a warning about the alert
< wumpus>
it doesn't really have to tell to upgrade
< wumpus>
just make sure peopel are aware
< btcdrak>
that's a good idea
< gmaxwell>
Chris_Stewart_5: there is a proposal on the list for a replacement using commited filters. that coupled with a CB like getblocktxn that provides hashproofs would be the replacement.
< CodeShark>
Chris_Stewart_5: proposals to put the filters in the blocks themselves seem at least slightly more promising
< gmaxwell>
the commited filter thing can also be done without the commitment and still have the same security as BIP37 but without the consensus change.
< petertodd>
gmaxwell: re: committed filter, you can make the consensus rule be it has to be a superset of what actually matches re: soft-forks
< petertodd>
gmaxwell: otherwise if we add another segwit-like thing we need a new filter
< gmaxwell>
petertodd: bandwidth overhead in that however.
< gmaxwell>
because then you have to send the filter between full nodes. yuck.
< CodeShark>
UTXO commitments + getutxos would probably be the quickest sync option that isn't totally insecure
< instagibbs>
is the bitcoin wiki down for others for the last few days?
< petertodd>
gmaxwell: true, though wasn't it only a few KB?
< CodeShark>
Privacy issues are still a problem, though
< petertodd>
CodeShark: I don't think we can reasonably implement UTXO commitments
< gmaxwell>
there are also many other options for scanning, including ones that are private, like via PIR lookup.
< Chris_Stewart_5>
Thanks gmaxwell, CodeShark, will read.
< petertodd>
and it'd be good for some of those options to be implemented via central services first to prototype
< gmaxwell>
the commited maps thing would let us do several non-commited revisions the only thing you lose without the commitment is security against censorship, which BIP37 has none of already.
< petertodd>
and a central service can be audited easily enough to detect censorship (assuming clients connect anonymously)
< gmaxwell>
petertodd: re-size it may be interesting to have several sizes, so clients could probe at the smallest and then only probe the larger if they have a hit... so perhaps they're larger than you might think. this would also all be unpredictable uncached validation. and 4kb would add about 1/3rd to a CB transmission.
< petertodd>
or actually, commit to the contents of the filter, and then provide the filter
< petertodd>
gmaxwell: true
< gmaxwell>
petertodd: right you could talk to N hosts, and find that they all give the same commitment value.
< gmaxwell>
without having to fetch the filter N times.
< gmaxwell>
or even connect to one host and get a commitment signed by N parties.
< petertodd>
gmaxwell: add a signature on the commitment and that should be enough
< gmaxwell>
right.
< CodeShark>
Thing is all these proposals significantly complicate client implementations
< petertodd>
CodeShark: well, privacy is hard :)
< gmaxwell>
checking a signature is not complex. :P
< gmaxwell>
in any case, it's foolish to think we can design for forever in a single step; we must have incremental stepping stones.
< CodeShark>
Ultimately, we need client implementations to be relatively simple or centralized API services will domimate
< CodeShark>
*dominate
< petertodd>
gmaxwell: I found it interesting how the Roughtime spec says that they will depreciate servers on a regular basis to force clients to keep up-to-date
< petertodd>
CodeShark: well, if we don't do a good enough job, centralized API services may be better for privacy... I'd trust a centralized API over bloom filters
< CodeShark>
or at the least we need some solid client-side libraries with multiple language bindings
< petertodd>
CodeShark: does bloom filters even have that? :)
< petertodd>
CodeShark: python-bitcoinlib *still* doesn't have a full bloom filter implementation - I've never had anyone interested in using it
< CodeShark>
petertodd: only the true diehards even attempt to use bloom filters rather than, say, bc.i :p
< petertodd>
CodeShark: indeed - python-bitcoinlib is likely used 99% of the time with a local copy of Bitcoin Core
< gmaxwell>
bc.i has better privacy than bloomfilters, IMO.
< CodeShark>
but it's still a single point of failure
< petertodd>
CodeShark: then use the Electrum servers! :)
< CodeShark>
Argh - lol
< * petertodd>
runs two OpenTimestamps public calendar servers and thinks that's good enough. :)
< petertodd>
CodeShark: honestly, I think Electrum would be interested in better privacy too - they've been open to discussing this in the past, and IIRC implemented prefix filters for that purpose
< CodeShark>
I run multiple bitcoin core instances and reluctantly use bip37
< CodeShark>
I get around the privacy and censorship issues by running my own instances
< CodeShark>
Electrum is just an additional dependency I don't want
< CodeShark>
Hell, if I wanted to go that route I could probably write a much thinner custom server - or a custom build of bitcoin core, even
< luke-jr>
if we merge script indexes, should probably do some p2p replacement for Electrum's protocol <.<
< CodeShark>
fwiw I'd like to work with all interested parties, including the electrum folks, in figuring out a good long-term solution to this
< gmaxwell>
The model that many application prefer where you have some random access query by address is inherently unscalable and probably lacks a non-centeralized future.
< CodeShark>
Then perhaps we need a different application model as well
< CodeShark>
it won't be simple to implement - but with the right abstractions it could be well-encapsulated, providing app developers with a reasonably simple model
< cfields>
morcos: started there, and got side-tracked optimizing prevector. the top commit is probably good as-is, though it won't change much without making prevector movable.
< luke-jr>
always annoying when people hear "I'm running Bitcoin Core" and their immediate reply is "you should switch to Electrum!"
< gmaxwell>
more than a little frightening too.
< gmaxwell>
wumpus: what happened with the work on SSE sha2 and asm for the CRC32?
< morcos>
cfields: i've been using that commit in my benchmarks for a while.. and today while trying to update everything i left it out.. and i'm thinking that explains some inconsitencies. i'll confirm, but i think its worth getting in
< gmaxwell>
wumpus: if you were disappointed at the fairly modest improvement, I expect it will be much better post the checkqueue changes.
< cfields>
morcos: sure. If you'd like to double-down, I can give you a quick commit that just adds move to prevector. It should be quite significant if you're seeing a difference already
< Chris_Stewart_5>
Back when pay to public key and raw multisig were used on the network, how were addresses generated? Did you just hash the entire scriptPubKey?
< luke-jr>
that was before addresses
< luke-jr>
(and raw multisig was never common use)
< luke-jr>
if you wanted to pay someone, you put in their IP and your client connected to them for a script
< Chris_Stewart_5>
Interesting, I guess i'm conflating addresses and actually spending scriptPubKeys.
< Chris_Stewart_5>
luke-jr: Was that functionality inside of Bitcoin Core? Inputing their ip address?
< luke-jr>
Chris_Stewart_5: this was before Bitcoin Core's time, and also before my time :p
< luke-jr>
Bitcoin started off with a wxWidgets Windows-only GUI client which was abandoned a long time ago
< Chris_Stewart_5>
Haha fair enough, guess i'm getting more into history instead of development any way
< morcos>
cfields: i'd love to double down, but will have to wait til tomorrow
< cfields>
morcos: ok, will push there later. sanity checking now.
< luke-jr>
FWIW, C++11 is de facto causing ABI issues on Gentoo (but probably not significant enough to regret the move)
< luke-jr>
mostly due to GCC 4.9 vs 5 mixing it seems
< sipa>
i would expect to be the one distro that doesn't suffer from such issues :)
< sipa>
*gentoo
< luke-jr>
sipa: tends to be the most likely to hit issues; binary distros just rebuild everything when ABIs change :p
< gmaxwell>
Re PR #8661 is there a reason that this isn't getting merged?