< bitcoin-git>
bitcoin/master 29d6634 John Newbery: Check that all test scripts in test/functional are being run...
< bitcoin-git>
bitcoin/master 79af9fb MarcoFalke: Merge #10096: Check that all test scripts in test/functional are being run...
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #10096: Check that all test scripts in test/functional are being run (master...check_all_tests_run) https://github.com/bitcoin/bitcoin/pull/10096
< brg444>
has someone undertaken more research into BFD/committed bloom filters since it was proposed on the ml?
< bitcoin-git>
bitcoin/master fa4535d MarcoFalke: [qa] combine_logs: Use ordered list for logfiles
< bitcoin-git>
bitcoin/master 5b029aa MarcoFalke: Merge #10076: [qa] combine_logs: Use ordered list for logfiles...
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #10076: [qa] combine_logs: Use ordered list for logfiles (master...Mf1703-orderedLog) https://github.com/bitcoin/bitcoin/pull/10076
< bitcoin-git>
[bitcoin] jnewbery opened pull request #10105: [tests] fixup - make all Travis test runs quiet, non just cron job runs (master...fixup_travis_logging) https://github.com/bitcoin/bitcoin/pull/10105
< bitcoin-git>
bitcoin/master 91f1f19 John Newbery: Make all Travis test runs quiet, non just cron job runs
< bitcoin-git>
bitcoin/master 0b9fb68 MarcoFalke: Merge #10105: [tests] fixup - make all Travis test runs quiet, non just cron job runs...
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #10105: [tests] fixup - make all Travis test runs quiet, non just cron job runs (master...fixup_travis_logging) https://github.com/bitcoin/bitcoin/pull/10105
< luke-jr>
hmm. I wonder if, when there are two equal-work tips, we ought to be treating the last common block as the real tip until the contention resolves.
< bitcoin-git>
[bitcoin] practicalswift opened pull request #10107: Remove unused variable. Fix accidental trailing semicolons in Python code (master...recent-python-style-regressions) https://github.com/bitcoin/bitcoin/pull/10107
< BlueMatt>
wumpus: hmm, would be good to get a rebase on #7729
< spudowiar>
For signing, we could have a signer process (which could talk to a hardware wallet, a remote computer, etc.) which communicates with the wallet over IPC
< TD-Linux>
spudowiar, it only has the RPC interface and zeromq
< spudowiar>
TD-Linux: I was thinking about the RPC interface, but I don't think running a server would be a good idea
< spudowiar>
If that's jonasschnelli's proposal, I've read that :)
< TD-Linux>
spudowiar, it's for "push notifications" of events
< spudowiar>
I see
< TD-Linux>
spudowiar, yeah. I'm personally not a huge fan of the URL style communication method...
< spudowiar>
Me neither
< spudowiar>
I want a separate process (I don't want any hardware wallet stuff in Bitcoin Core)
< spudowiar>
We could have something like bitcoin-trezor-signd
< TD-Linux>
I think it'd actually be really neat if bitcoin core supported hw wallets out of the box
< spudowiar>
Of course, but it should be a separate process
< spudowiar>
e.g. Core starts `bitcoin-trezor-signd`, communicates over IPC
< TD-Linux>
what's the main purpose of the separate process?
< spudowiar>
I don't think it's a good idea to have the actual code in Core
< TD-Linux>
for security reasons?
< spudowiar>
gmaxwell: Since you're on GitHub RIGHT NOW talking about IPC, what IPC method do you suggest :)
< spudowiar>
For a number of reasons, security being one of them
< TD-Linux>
if you want to do IPC for security, you also need sandboxing or some sort of isolation between the two processes
< spudowiar>
You'd have to add dependencies on software like hidapi, etc.
< luke-jr>
TD-Linux: it'd be nice if hw wallets could just distribute plugins
< spudowiar>
luke-jr: That would work with my method
< spudowiar>
Ooh
< spudowiar>
Doesn't Bitcoin Core use Protocol Buffers for payment requests?
< spudowiar>
We could use Protocol Buffers?
< gmaxwell>
DO NOT USE PROTOBUF
< spudowiar>
Ok :)
< spudowiar>
Why?
< spudowiar>
I feel like I've been told off ;)
< gmaxwell>
As you should.
< gmaxwell>
:P
< luke-jr>
use Perl and put a Perl interpreter in Core
< luke-jr>
/s
< spudowiar>
luke-jr: I kind of think Java would be better? Know any Perl JVM implementations? /s :)
< gmaxwell>
spudowiar: what you're discussing has been discussed a few times in the past. You don't need a freeking seralization library to send a simple 'sign this'
< TD-Linux>
luke-jr, yes, though that's an extra step that would be nice to have automated
< spudowiar>
gmaxwell: Well, you can't send the transaction, you need a data format
< spudowiar>
The hardware wallet needs to know the key path and other metadata it will store with the wallet (like account number, etc.)
< spudowiar>
And UTXO ids
< gmaxwell>
spudowiar: yes, so just seralize it. this isn't rocket science. We manage to run the whole network without any wonky seralization libraries.
< TD-Linux>
I'd really love to have a standard USB protocol, maybe I am overreaching :)
< gmaxwell>
die.
< gmaxwell>
somewhere I wrote some requiremets for a suggestion that you be able to add to the configuration a path to an executable to run for signing, and it would just invoke it and communicate over stdin, to tell it what to sign. Said executable could do whatever it wanted, pop up confirmation dialogs to get passwords and decrypt keys, connect out over usb using whatever protocol you want, etc.
< gmaxwell>
this keeps the implementation of whatever weird interface you want to use outside of bitcoin.
< spudowiar>
gmaxwell: Serialize it with... what? That's all I'm asking you :)
< spudowiar>
gmaxwell: That's the sort of thing I was thinking of
< spudowiar>
I meant serialization earlier, not IPC when I asked you :)
< gmaxwell>
spudowiar: the serialization code already in the software.
< spudowiar>
So, the C* family of classes?
< spudowiar>
Well, base_blob
< gmaxwell>
spudowiar: this is like ... programming 101 stuff. Define a structure for what you need to communicate and then make a seralizer for it. This is simplified by the fact that we already have seralizers for most or all of the fields you need to send (like a transaction).
< spudowiar>
gmaxwell: I know how to serialize, but this is more of a "this is your codebase, how do you do stuff around here"
< gmaxwell>
spudowiar: look at the codebase to answer that! we don't do things by pulling in gigantic libraries that barely do what we need and only inefficiently in other to replace what is probably 5 lines of code. :P
< spudowiar>
Anyway, sorry for being annoying, it takes me a bit of time to get familiar with large codebases
< spudowiar>
Grrr, CExtKey and CExtPubKey share no interface :( This means there's a ton of repeated code :(
< bsm117532>
bitcoin.sipa.be appears to be down. I can't check my daily segwit activation stats!
< sipa>
spudowiar: look at the Serialize and Unserialize methods that some classes have
< spudowiar>
sipa: Ah, so it's all the base_blob stuff, gotcha! :)
< spudowiar>
I should just be able to create something like an ExternalSignatureCreator : BaseSignatureCreator
< sipa>
eh, maybe
< sipa>
i dodn't read the conversation above
< spudowiar>
sipa: Basically, execute other program, feed it serialized transaction data, (external program talks to HW wallet), verify signature
< spudowiar>
Probably : TransactionSignatureCreator, rather than Base
< spudowiar>
Thanks sipa & gmaxwell for all the help :)
< spudowiar>
Now I know what to grep for, I can infer the rest :)
< sipa>
bsm117532: my vps provider claims it was running a bitcoin miner and turned it off
< sipa>
bsm117532: thankfully i'm in the middle of migrating elsewhere
< bsm117532>
Sounds like they need to be hit with a cluestick. Moving sounds like a good plan...
< sipa>
it is not even the first time they claim this
< sipa>
though in previous occasions they at least asked for an explanation instead of just turning it off
< bitcoin-git>
[bitcoin] RHavar opened pull request #10108: ApproximateBestSubset should take inputs by reference, not value (master...trivial) https://github.com/bitcoin/bitcoin/pull/10108
< bitcoinreminder_>
sipa: it looks like your segwit stats are offline?
< sipa>
bitcoinreminder_: read a few lines up
< bitcoinreminder_>
oh right, I see, sorry! :)
< instagibbs>
what's the fastest way to run a python test with an additional debug log param?
< jnewbery>
./test_runner.py -l debug
< jnewbery>
Sorry. To be clearer: bitcoind instances being tested now always have debug logging enabled. the -l debug enables debug logging for the test framework
< jnewbery>
instagibbs: ^
< instagibbs>
jnewbery, ah thanks.
< jnewbery>
#10017 may also be helpful if you're trying to fix failing testcases
< gribble>
https://github.com/bitcoin/bitcoin/issues/10017 | combine_logs.py - aggregates log files from multiple bitcoinds during functional tests. by jnewbery · Pull Request #10017 · bitcoin/bitcoin · GitHub
< sipa>
bsm117532: it's moved, but DNS will take 12 hours to propagate
< sipa>
s/propagate/timeout/
< bsm117532>
But...what if segwit activates in the next 12 hours?!?!?! How will we know?!?!?!
< bsm117532>
I kid...I kid...but thanks for making that service.
< sipa>
the only way you should find out: you run a segwit-enabled full node :)
< bsm117532>
Oh I do. :-P
< Cobra>
so this is where the magic happens :P
< BlueMatt>
sipa: I rndc flush'd and i still cant access it
< BlueMatt>
sipa: looks like ns*.ulyssis.org are still returning the old values
< sipa>
BlueMatt: that's possible
< bitcoin-git>
[bitcoin] jnewbery opened pull request #10111: Remove NetworkThread from individual test cases (master...remove_network_thread_from_test_scripts) https://github.com/bitcoin/bitcoin/pull/10111