< 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
< 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/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] 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
< 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.
< 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>
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!