< jonasschnelli> cfields: would appreciate a final review of #9502 (since it's touching net code)
< gribble> https://github.com/bitcoin/bitcoin/issues/9502 | [Qt] Add option to pause/resume block downloads by jonasschnelli · Pull Request #9502 · bitcoin/bitcoin · GitHub
< jonasschnelli> If one wants to use the REST-API behind authentication (which makes very much sense for most use cases), use a reverse proxy via apache or other httpds
< jcorgan> nginx works well here
< jonasschnelli> Indeed,... though once I got told nginx is great for static data and apache is better for CGI/etc.,... I may be wrong.
< eklitzke> discussions of apache vs nginx elsewhere please
< jonasschnelli> however, OT
< jonasschnelli> +1
< jonasschnelli> eklitzke: I read your leveldb post! impressive.
< eklitzke> thanks i need to get my max_open_files changed before i post more PRs though
< eklitzke> waiting on wumpus for that
< bitcoin-git> [bitcoin] jonasschnelli opened pull request #12721: Qt: remove "new" button during receive-mode in addressbook (master...2018/03/addr_new_btn) https://github.com/bitcoin/bitcoin/pull/12721
< jonasschnelli> eklitzke: I guess your work could be very useful for Ordoid-HC2 nodes with spinning disks
< eklitzke> i want to make all low-end use cases work better, the three i am most interested in are: (1) regular computer with a slow external hard drive (or maybe home NAS) attached for storage, (2) default ec2/gcp cloud instance with slow disks, (3) something like an rpi
< eklitzke> i think we could make all three of these work a lot better with the default options
< jonasschnelli> eklitzke: great to hear!
< wump> so we've kind of reached a dead end on transifex, not being able to set team permissions, https://github.com/bitcoin/bitcoin/issues/12657#issuecomment-373956561 Does anyone know if seone gets on Freenode?
< wumpus> I've tried contacting him through the transifex message system but never heard back
< midnightmagic> :-/
< midnightmagic> that kinda sucks.
< wumpus> it's not like github where it's possible to transfer projects between organizations, or at least, not with the permissions I have
< wumpus> I can *copy* the translations to another project on another organization but how to get all the translators along
< meshcollider> Could you contact transifex themselves? Would they help?
< wumpus> maybe if seone completely went inactive, but I'm not sure about that. This is why my question if anyone knows him here.
< wumpus> (or her, I have no idea really)
< wumpus> luke-jr maybe?
< wumpus> who was active in this project when the transifex translations started?
< kinlo> wumpus: he does get on freenode, but the last time he was active on freenode was 20 weeks ago
< wumpus> kinlo: that's not reassuring
< kinlo> it is not
< kinlo> but that is what /msg nickserv info seone tells me
< kinlo> do we have an email for him?
< wumpus> I don't
< kinlo> I'll send him a message to contact you?
< kinlo> done, I've asked him to contact you, let's hope he reads that
< wumpus> thanks!
< Catherine> hello
< Guest19657> help
< bitcoin-git> [bitcoin] krab opened pull request #12723: Qt5: Warning users about invalid-BIP21 URI bitcoin:// (master...qt5-uri-error-message) https://github.com/bitcoin/bitcoin/pull/12723
< drexl> hey guys, how can I contribute if I only know python?
< instagibbs> drexl, check out the functional test suite
< instagibbs> `test/functional`
< drexl> cheers
< instagibbs> so expanding/improving functional tests is definitely one way
< bitcoin-git> [bitcoin] mathhoang88 opened pull request #12725: LCoin (master...master) https://github.com/bitcoin/bitcoin/pull/12725
< bitcoin-git> [bitcoin] fanquake closed pull request #12725: LCoin (master...master) https://github.com/bitcoin/bitcoin/pull/12725
< rabidus> Am I the only one who lacks of connections after 0.16 release. Node has been up fairly long (with some shutdowns) for several weeks? I'm currently having 22 connections, while with 0.15 I was having 50+
< fanquake> wumpus I was suspicious that was someone chasing altcoin dev help, was giving them the benefit of the doubt heh
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/00d1680498c5...872c921c0a20
< bitcoin-git> bitcoin/master 0dbb32b Jeff Rade: Avoiding 'file' function name from python2 with more descriptive variable naming
< bitcoin-git> bitcoin/master 872c921 MarcoFalke: Merge #12720: qa: Avoiding 'file' function name from python2...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #12720: qa: Avoiding 'file' function name from python2 (master...pr_12437_variable_rename) https://github.com/bitcoin/bitcoin/pull/12720
< setpill> i am trying to set up gitian builds but getting "lxc-execute: start.c: lxc_spawn: 1079 Failed to find gateway addresses."
< setpill> i followed the instructions on https://github.com/bitcoin-core/docs/blob/master/gitian-building/gitian-building-setup-gitian-debian.md including the rc.local stuff, not sure what i missed
< bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/872c921c0a20...6324c68aa017
< bitcoin-git> bitcoin/master 8c632f7 Vasil Dimov: ax_boost_{chrono,unit_test_framework}.m4: take changes from upstream...
< bitcoin-git> bitcoin/master 71129e0 Vasil Dimov: Do not check for main() in libminiupnpc...
< bitcoin-git> bitcoin/master 8ae4132 Vasil Dimov: Remove redundant checks for MSG_* from configure.ac...
< bitcoin-git> [bitcoin] laanwj closed pull request #12678: build: Fix a few compilation issues with Clang 7 and -Werror (master...master-compilation-fixes-with-clang7-werror) https://github.com/bitcoin/bitcoin/pull/12678
< wumpus> fanquake: yes, good to give people the benefit of the doubt in general, but his response made it clear
< luke-jr> wumpus: I can add a "project maintainer", but not sure if that's the same thing
< luke-jr> and I think project maintainer can remove other people, so there is a possible risk
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6324c68aa017...c39dd2ef59c9
< bitcoin-git> bitcoin/master fab8a6f MarcoFalke: wallet: Change output type globals to members
< bitcoin-git> bitcoin/master c39dd2e Wladimir J. van der Laan: Merge #12408: wallet: Change output type globals to members...
< bitcoin-git> [bitcoin] laanwj closed pull request #12408: wallet: Change output type globals to members (master...Mf1802-walletChangeTypeMember) https://github.com/bitcoin/bitcoin/pull/12408
< bitcoin-git> [bitcoin] lutangar opened pull request #12727: [RPC][Trivial] Remove unreachable help conditions in `rpcwallet.cpp` (master...unreachable-help-condition) https://github.com/bitcoin/bitcoin/pull/12727
< ossifrage> rabidus, I used to have hundreds of connections, now I only have 4 inbound connections. I attributed it to my ip address changing (multiple times due to power failures) and not 0.16.x
< bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/c39dd2ef59c9...93634f296e0b
< bitcoin-git> bitcoin/master 81b0822 Ben Woosley: test: Use wait_until in tests where time was used for polling
< bitcoin-git> bitcoin/master 9d7f839 Ben Woosley: test: Use os.path.join consistently in feature_pruning tests
< bitcoin-git> bitcoin/master 93634f2 Wladimir J. van der Laan: Merge #12553: Prefer wait_until over polling with time.sleep...
< bitcoin-git> [bitcoin] laanwj closed pull request #12553: Prefer wait_until over polling with time.sleep (master...wait-until) https://github.com/bitcoin/bitcoin/pull/12553
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/93634f296e0b...ebdf84c9601e
< bitcoin-git> bitcoin/master 4c317d8 Russell Yanofsky: Document RPC method aliasing...
< bitcoin-git> bitcoin/master ebdf84c Wladimir J. van der Laan: Merge #12700: Document RPC method aliasing...
< bitcoin-git> [bitcoin] laanwj closed pull request #12700: Document RPC method aliasing (master...pr/alias) https://github.com/bitcoin/bitcoin/pull/12700
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ebdf84c9601e...ee7b67e2784a
< bitcoin-git> bitcoin/master 499d95e Russell Yanofsky: Add static_assert to prevent VARINT(<signed value>)...
< bitcoin-git> bitcoin/master ee7b67e Wladimir J. van der Laan: Merge #9753: Add static_assert to prevent VARINT(<signed value>)...
< bitcoin-git> [bitcoin] laanwj closed pull request #9753: Add static_assert to prevent VARINT(<signed value>) (master...pr/varint-assert) https://github.com/bitcoin/bitcoin/pull/9753
< bitcoin-git> [bitcoin] jnewbery opened pull request #12728: [tests] rename TestNode to TestP2PConn in tests (master...rename_test_node) https://github.com/bitcoin/bitcoin/pull/12728
< bcamacho> Hello, I have a full node configured and fully sync. I can create new addresses which are validated with RPC commands. I'm running into an issue when using signmessage, the results reports "Address does not refer to key (code -3)" -- Has anyone faced this issue?
< luke-jr> bcamacho: signmessage is deprecated, and only works with old 1-style addresses
< luke-jr> bcamacho: signmessage was often misunderstood as a "proof of funds", which it doesn't actually prove; and very rarely used correctly.. so a new specification is needed to address these issues
< luke-jr> there is some discussion on the development mailing list around trying to get a newer message-signing spec made
< bitcoin-git> [bitcoin] sipa closed pull request #12712: Support serialization as another type without casting (master...201803_astype) https://github.com/bitcoin/bitcoin/pull/12712
< jimpo> sipa: I updated the PR description of #12254 with stats on the filter sizes in proportion to block sizes
< gribble> https://github.com/bitcoin/bitcoin/issues/12254 | BIP 158: Compact Block Filters for Light Clients by jimpo · Pull Request #12254 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] ryanofsky opened pull request #12729: Get rid of ambiguous OutputType::NONE value (master...pr/nonone) https://github.com/bitcoin/bitcoin/pull/12729
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ee7b67e2784a...8ee5c7b74717
< bitcoin-git> bitcoin/master e5468a1 lutangar: Remove unreachable help conditions
< bitcoin-git> bitcoin/master 8ee5c7b MarcoFalke: Merge #12727: [RPC] Remove unreachable help conditions in rpcwallet.cpp...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #12727: [RPC] Remove unreachable help conditions in rpcwallet.cpp (master...unreachable-help-condition) https://github.com/bitcoin/bitcoin/pull/12727
< bcamacho> luke-jr do you have a link that you could share regarding message-signing?
< bcamacho> luke-jr: in my project I'm using message-signing as proof of identity. You can sign a message proving address ownership, not proof of funds.
< bcamacho> I just noticed that the new addressesing starts with 3xx versus 1xx. Thanks to luke-jr for assisting :)
< sipa> "new"?
< sipa> it was proposed and implemented in 2012
< bcamacho> I thought 3xx was used for multi-sig wallets
< sipa> yes, since 2012
< bcamacho> All new client addresses are now being issued with 3xx, even if they are not multi-sig.
< sipa> the 3xxx addresses are P2SH: they send to a *script* rather than to a key
< sipa> the first thing they were being used for was multisig, but it's always been generically usable for any script
< hirish> 3xx are P2SH addreses, it means they encapsulate a script. Now core is issuing 3xx addresses because is encapsulating witness scripts
< sipa> since segwit all backward compatible addresses use P2SH, as it's the only way to use segwit
< sipa> jimpo: looking at https://github.com/bitcoin/bitcoin/commit/9ff9435ccb6668c96d6c554129a31e5de6df4dda, it uses GetOp to determine what to index
< sipa> i believe that means it will have 2 elements for every native segwit output
< bcamacho> Got it! Thanks for the help on this. I was originally using 1xx addresses to sign message and prove ownership for authentication. Do you have a suggestion for how we can sign to prove id with 3xx addresses?
< sipa> bcamacho: different approaches are being discussed
< sipa> jimpo: that seems highly inefficient (perhaps it should be restricted to pushes above a certain size... or just to the whole output at once rather than its pushes?)
< luke-jr> bcamacho: 3xx isn't new anymore. New is now bc1… ;)
< bcamacho> I understand. I'm trying to figure out how I still can use message signing. It seems at this moment, the only way is to stick with 1xx addresses.
< setpill> is this the right place to ask for help on getting gitian builds working? im trying to follow the instructions for the virtualbox debian build, but so far only the windows version builds
< setpill> (manifest matches, though, so that's a plus)
< setpill> getting lxc-execute: conf.c: setup_rootfs: 1279 failed to mount rootfs for the linux build
< jimpo> sipa: Yes, it pushes small OP_0 - OP_16 opcodes
< luke-jr> bcamacho: there's no harm to using 1xx for identification, at least.
< jimpo> but they get deduped per block filter
< sipa> jimpo: right, so it's at most 17
< luke-jr> although actually generating a 1xx address with Core 0.16 may be a pain..
< luke-jr> probably need to use the debug window
< jimpo> yes, at most 17 additional elements per filter
< sipa> so you're relying on standardness/miner policy to prevent someone from creating outputs with just a bunch of pushes?
< jimpo> well, and the cost of the data they are adding to the block for no good reason
< jimpo> It sounds like your suggestion is just to push the entire scriptPubKey instead of parsing out data pushes?
< sipa> yes
< sipa> i don't think this loses you anything
< jimpo> That's fine with me and eliminates the edge case of corrupted output scripts
< jimpo> Lemme check with roasbeef
< sipa> the filter size numbers look nice, btw
< jimpo> Oh, regarding the extended filter thing. If we're OK burning another service bit, we could separate the two so that nodes can choose to just build basic or just build extended filters.
< jimpo> but service bits are kind of limited
< sipa> i would be fine with that (it's not too hard to extend the service bits field if really necessary - it's just a p2p change)
< sipa> do you have filter size number per filter element? (in other words: what's the actual size compared to 20bits * elements)
< jimpo> hmm, good question. No, I did not pull down the number of elements per filter, but I will now.
< sipa> thank you!
< luke-jr> sipa: if you use the entire scriptPubKey only, that wouldn't work with stuff like stealth addresses, right?
< sipa> luke-jr: stealth addresses are inherently incompatible with this approach
< sipa> (if there was something to match on, they wouldn't be stealth)
< luke-jr> true
< sipa> and i think it's perfectly fine to add more filters later if there are use cases for them... i just prefer being conservative in what responsibilities get added to full nodes for the purpose of serving P2P extensions; they may turn out to be very hard to get rid of
< jimpo> That said, a light client could pull down only the scriptPubKeys for a block and scan those before pulling down all block data (in a stealth address world)
< setpill> wtf these scripts... ran the exact same invocation of gitian-build.sh again and it decided to remove 2 packages (???) and now it seems to be compiling
< echeveria> sipa: bip37 also separately hashes every single script element
< sipa> echeveria: yes, a stupid choice IMHO :)
< echeveria> so up to 1M bloom filter elements per block.
< echeveria> I guess 4M with segwit.
< sipa> segwit inputs aren't scripts ;)
< sipa> so they're not included in BIP37
< echeveria> right
< sipa> they are in the extended BIP118 filters though
< sipa> as currently written, at least
< drexl> where does one find the pgp key to verify the signature?
< luke-jr> which signature?
< drexl> from the release
< luke-jr> there are many signatures on each release; you can get key ids from the source, and the keys themselves from any public keyserver typically
< luke-jr> bitcoin.org hosts a mirror of some keys, but you should probably verify the keys are correct from multiple sources, or someone you know/trust personally
< drexl> might be a good idea to upload them to keybase.io ? so it can be publicly verifiable that the owner of the domain/repo owns the keys
< sipa> how does it let you verify that...?
< drexl> you sign a public gist in your github account
< jimpo> Bidirectional links to social media accounts
< sipa> i guess i should read up on keybase
< jimpo> It's pretty sweet. And it has web-of-trust type stuff where you can see which accounts other people follow with signed proofs that they are following them.
< luke-jr> PGP has web-of-trust stuff built-in.. IIRC (but probably didn't look into it too much) keybase wasn't anything interesting
< drexl> it's kind of the opposite of web of trust, every account you link with your keys is accompanied with a proof that anyone can verify
< drexl> you dont have to trust anyone
< drexl> and you can link domains too
< setpill> you still need to bootstrap the trust
< drexl> setpill look at GPGTools for example https://keybase.io/GPGTools
< drexl> I can verify myself that they own the domain and the twitter account
< bcamacho> luke-jr or sipa: Is there a link regarding deprecation for signmessage? I was reviewing the developer documentation and it has no mention of the deprecation: https://bitcoin.org/en/developer-reference#signmessage
< sipa> it's not deprecated
< sipa> it just doesn't support new address types
< bcamacho> sipa: thanks, i figured as much. I'm now trying to figure out a solution. I compile v0.16 and seeing if I can generate a 1xx address with the core client to mode the wallet to prompt user regarding address types. I believe there is still use of sign/verify with address for proof of ID, not funds. It would be great if we can use and manage mix addresses.
< bcamacho> If you have any info that could help save time on this, please share :)
< sipa> bitcoin addresses are not identities
< bcamacho> They can be for services
< sipa> that's nonsense
< sipa> they're single use payment request identifiers at best
< sipa> i can't prevent you from leveraging them for more, but i think it's ill-advised to reuse keys across multiple application at best
< bcamacho> Why nonsense? If you can prove ownership of 1xx address you can utilize that for authenticated webservices. No need for username or password. Not for production, more for creative education.
< sipa> why would you do such a thing?
< sipa> the address doesn't mean anything
< sipa> you can just as well use a different key
< aj> bcamacho: all you're doing is reinventing public key auth, but adding the potential that someone might screw up and lose their btc funds?
< sipa> which is generally good practice in cryptography to use separate keys for separate purposes
< sipa> as far as using the signmessage functionality in bitcoin core goes, you can use validateaddress to extract the public key for an address (if it's yours), and then sign with the P1PKH address corresponding to that key instead
< sipa> please take any further discussion elsewhere, it has nothing to do with bitcoin core's software development
< bcamacho> sipa: I was not trying to clog up this thread with non-core discussions. Thank you for your help!