< bitcoin-git>
[bitcoin] jtimon opened pull request #9654: Add jtimon pgp keys for commit sigs and future gitian builds (master...jtimon-key-gpg) https://github.com/bitcoin/bitcoin/pull/9654
< luke-jr>
what would others think of a feature where you can sign a message using the UTXO set to show you probably run a full node?
< jl2012>
you could outsource this, I suppose
< sipa>
if you do it as a challenge-response, and require a response within not-much-more-than-ping-time, you'd at least prove you're close to a full node
< luke-jr>
jl2012: yes, it won't be 100% reliable, but it might be handy
< luke-jr>
sipa: that sounds much more complicated (can't really integrate with a browser) :/
< luke-jr>
it would also exclude those who have remote full nodes under their own control
< luke-jr>
depending on implementation I guess
< luke-jr>
I suppose the node can contact the webpage directly, but that seems like not the best idea for security
< sipa>
webpage?
< sipa>
maybe you have a very different use case in mind than me
< luke-jr>
sipa: I was thinking for polling users
< TD-Linux>
that makes no sense if you're trying to make 1 vote per user
< CubicEarth>
luke-jr: you are interested in poll results, 1 vote per-full node?
< luke-jr>
CubicEarth: that's up to the polling website to figure out weights
< luke-jr>
eg, one might use a combination of full-node-signature plus coin-control-signature to weigh by coins controlled
< CubicEarth>
luke-jr: Nice! Anything with coin-weights is near and dear to my heart
< CubicEarth>
luke-jr: any what are you trying to limit by wanting the full-node signature in addition to coin control proof?
< luke-jr>
gauging interest and possible consent in protocol change ideas
< CubicEarth>
I guessed that part.... but my question stands
< CubicEarth>
I could see the benefit in giving coins more weight if someone can prove a node as well, but I can't see a point to giving the same amount of coins more weight if two nodes were proved
< luke-jr>
I'm not even sure what you're asking about there
< CubicEarth>
If you are interested in proof-of-full-node as a voting concept, and if so, curious as to why sybil wouldn't be an issue
< CubicEarth>
So, that's why I said I could see it being binary: do the coins that are voting also have a node.... that wouldn't have sybil issues
< CubicEarth>
maybe I missed something about the discussion
< jl2012>
luke-jr: wouldn't it be very cheap to run one full node, and pretend to be 100 using 100 ip addresses?
< jl2012>
if proof of full node is remotely possible, we don't need pow
< jl2012>
finally, people will just invest on resources (e.g. ip addresses), that do not have anything to do with the security of bitcoin
< CubicEarth>
I could see a small use case: If someone has a bunch of coins they want to vote with, they could also need to prove they have a full node. There would be no limit to the coins that one node could enable to vote.
< CubicEarth>
What would that show?
< CubicEarth>
That someone who wanted to vote was able to create a full node
< CubicEarth>
I don't know if that would be important to anyone....
< gmaxwell>
sipa: no you don't, I can artifically increase my ping time.
< Eliel_>
jl2012: isn't it reasonably easy to construct a challenge you can use to verify a full node? There have been ideas for mining algorithms that'd make mining impossible if you don't have the full blockchain available.
< Eliel_>
although, the only way to verify that two different looking nodes aren't the same one would be to challenge them both at the same time.
< jl2012>
yes, but luke-jr is suggesting a voting system based on that
< jl2012>
and that's outsourceable
< Eliel_>
I guess I'd better read the backlog
< jl2012>
even for the purpose of mining, that's outsourceable
< jonasschnelli>
If I create a bloom filter (block filter) of all the COutPoints and inputs scriptSigs of a recent block, it will get pretty big,... It often hits around 15'000 elememts, so, roughly 15kb per block = 2.1MB of filters per day... Any idea how to improve that?
< sipa>
gmaxwell: sure, but then you have a higher ping time
< bitcoin-git>
[bitcoin] practicalswift closed pull request #9581: [pep-8] Prefer "foo is None" to "foo == None". Prefer "foo not in bar" to "not foo in bar". (master...test-for-membership) https://github.com/bitcoin/bitcoin/pull/9581
< BlueMatt>
"The command "if [ "$RUN_TESTS" = "true" -a "$TRAVIS_REPO_SLUG" = "TheBlueMatt/bitcoin" -a "$TRAVIS_PULL_REQUEST" = "false" ]; then contrib/verify-commits/verify-commits.sh; fi" exited with 127."
< BlueMatt>
but it keps turnning......
< BlueMatt>
oh, it did mark failure, ok
< bitcoin-git>
[bitcoin] TheBlueMatt opened pull request #9656: Add Marko's Key to verify-commits and check verify-commits on pushes to master (master...2017-01-fix-verify-commits) https://github.com/bitcoin/bitcoin/pull/9656
< bitcoin-git>
[bitcoin] isle2983 opened pull request #9658: Add clang_format.py to help automate code style analysis (master...PR-clang-format) https://github.com/bitcoin/bitcoin/pull/9658
< bitcoin-git>
[bitcoin] jtimon opened pull request #9659: Net: Turn some methods and params/variables const (master...0.14-net-more-const) https://github.com/bitcoin/bitcoin/pull/9659
< dgenr8>
to conduct a poll by coins you can make a hard-forking client with limited ways to "spend" coins to vote (none of which create txes valid on mainnet). has similar drawbacks as bitcoinocracy