< bitcoin-git>
bitcoin/master 223a4aa fanquake: [build] Don't fail when passed --disable-lcov and lcov isn't available
< bitcoin-git>
bitcoin/master 0e70791 Wladimir J. van der Laan: Merge #11611: [build] Don't fail when passed --disable-lcov and lcov isn't available...
< bitcoin-git>
[bitcoin] laanwj closed pull request #11611: [build] Don't fail when passed --disable-lcov and lcov isn't available (master...dontfaillcov) https://github.com/bitcoin/bitcoin/pull/11611
< andre1>
I started downloading the bitcoin core wallet since a couple of days and although I realize this might have been asked many times before I could find the answer on the web. Why does the download start in 2009 and works its way to today and not the other way round start with today and work back to 2009?
< Sentineo>
andre1: this is the core dev channel, discussions are about developement and code. Can you please repaste that question to #bitcoin? I will answer there.
< andre1>
sorry ok thanks will do
< Sentineo>
no problem
< fanquake>
Looks like a bit of mess to sort out with OpenSSL? Can't wait until it's gone..
< wumpus>
fanquake: same sentiment here...
< wumpus>
I went from mildly opposed to actively hostile toward OpenSSL
< luke-jr>
what's going on with OpenSSL this time? :/
< wumpus>
another random non-backward-compatible API change - and this one is pretty dangerous, a fix for newer versions would actively break threading support with older versions
< wumpus>
this is a really bad place to be in with a critical library
< luke-jr>
yes, just I've gotten used to complaints of OpenSSL indicating a critical security problem XD
< Sentineo>
I heard openssl will be abandoned fully, right?
< wumpus>
at least happy we link openssl statically
< Sentineo>
I mean in core
< wumpus>
we need it in the GUI, but for the rest it should be ditched completely yes
< wumpus>
pretty far along already
< wumpus>
IIRC it's only randomness that's left used for, and maybe some tests
< bitcoin-git>
[bitcoin] fanquake opened pull request #11621: [build] Add temp_bitcoin_locale_qrc to CLEANFILES to fix make distcheck (master...fix-osx-distcheck) https://github.com/bitcoin/bitcoin/pull/11621
< BlueMatt>
wumpus: re: openssl can we just remove the payment protocol garbage?
< BlueMatt>
I mean at least rip out the cert-checking part of it
< BlueMatt>
its nonsense, and almost certainly provides a sense of security that it simply doesnt provide
< wumpus>
BlueMatt: even if you do that you still can't get rid of openssl, as qt needs that for https
< wumpus>
BlueMatt: anyhow as soon as we don't use SSL anymore in core code, we can leave its initialization to qt
< name>
what does the GUI use https fpr?
< name>
*for
< wumpus>
name: for retrieving payment protocol URLs
< wumpus>
you'd really have to remove the entire payment protocol, and I'm not sure that's a good idea, at least announce its deprecation far in advance
< BlueMatt>
wumpus: ugh i forgot it fetches the descriptors
< BlueMatt>
man, fuck that thing
< name>
This is the BIP70 stuff?
< wumpus>
name: yes
< wumpus>
as preparation for (future or far future) deprecation we could add a compile option to build without BIP70 support
< name>
I wonder how much real-world usage the payment protocol feature has
< wumpus>
I've seen only bitpay use it, with android wallet
< wumpus>
that might be all real-world usage of it, in which case removing it from bitcoin core wouldn't affect anyone :)
< StopAndDecrypt>
i have 4 good peers but the new ones keep cycling out
< StopAndDecrypt>
anyone more experience able to touch on what this might be indicative of?
< StopAndDecrypt>
im running 0.15
< kinlo>
I did always like the payment protocol idea, it's usefull on bitpay and there are more wallets that support it, I'm using it on bread....
< StopAndDecrypt>
to clarify, all the new peers have no user agent name or details
< wumpus>
kinlo: I like the idea as well, the problem is with the implementation
< StopAndDecrypt>
oh im in the wrong channel, apologies
< wumpus>
StopAndDecrypt: it's quite normal that some peers only connect shortly, doesn't need to be indicative of anything
< kinlo>
I can't talk about the implementation, haven't read it, but even if the core wallet would remove it from it's implementation, I think the standard shouldn't be deprecated
< wumpus>
kinlo: the foremost thing I like about payment request is that they have expiration dates, and the user never sees the address used, so it's possible for vendors to rotate keys and not worry too much about receiving payments on old addresses
< kinlo>
wumpus: I've discussed this with gavin when the protocol was designed, I like that too but I think it is a missed oportunity to supply a refund address from the client so merchants could refund easily. But I guess that's a discussion we shouldn't be having here and now
< wumpus>
kinlo: how do you mean? an optional refund addres is also part of it
< StopAndDecrypt>
wumpus, it got all the way up to 160, and now i have 8 that arent disconnecting, but thanks
< wumpus>
kinlo: which is also a great idea
< kinlo>
wumpus: it is? then ignore me, I'll have to reread the final specs, maybe my comments at the time might have made the final specs :)
< wumpus>
kinlo: so what I hate about it: - google protocol buffers - use of PKI certificate chains (lots of overhead in implementing this, especially on embedded hw) - needs fetching data over the web which pretty much mandates SSL in the wallet
< wumpus>
kinlo: yeah you probably just missed that part. I don't blame you.
< kinlo>
yeah, pki sucks but what's the alternative :)
< wumpus>
again, I think the *idea* is great, of making it possible for the (hw) wallet to authenticate the vendor
< sipa>
my main concern with the payment protocol is that is has no guaranteed message delivery
< sipa>
the tx creator is allowed to just broadcast the tx
< sipa>
if it were required to just send the sign tx back to the merchant, it would guarantee reception
< wumpus>
yes, although it supports sending the tx directly to the merchant, it's not required
< ccc>
fuckfuck
< ccc>
everyone is a fucker?
< ccc>
i hear giszmo is a fucker
< BlueMatt>
#11524 could use a quick review-and-merge..
< BlueMatt>
jonasschnelli: can you take another look at 3716? I initially came to the same conclusion as you, but then changed my mind cause I was missing some context
< BlueMatt>
and it is the longest-still-open-pr by a pretty large margin :/