< gmaxwell>
But in practice it appears that a lot of people are exposing themselves, and ultimately thats an issue for us... not just because we care about people getting owned but because it increases the critical attack surface a lot.
< echeveria>
ie, even if not authenticated, I don't believe the RPC server is designed to handle a lot of arbitrary connections hogging sockets.
< achow101>
the rpcpassword is sent plaintext so a mitm can access everything too
< echeveria>
it's not a huge issue, just something to consider.
< gmaxwell>
indeed, we've had people in #bitcoin that were having issues because some third party was trying to password bruteforce their rpc port or something like that..
< sipa>
meshcollider: you don't seem to have code for P2SH-P2WPKH
< sipa>
meshcollider: also i think the tests are very insufficient; it doesn't test anything but that importmulti succeeds, not whether it actually imported anything
< sipa>
meshcollider: also, no tests with solvable-but-not-spendable cases
< meshcollider>
sipa: yeah I know the tests aren't the best, I'll make some better ones soon
< meshcollider>
sipa: good point re P2SH-P2WPKH, it was there earlier when it always imported the public keys, but now I changed that I need to add the pubkey import into the P2SH if statement too
< sipa>
meshcollider: i also realized that the importmulti does a whole bunch of things not that it should be doing (unrelated to your PR), which I'd like to fix, like checking that the private keys are actually used, or assigning a timestamp for imported pubkey, or checking that no unnecessary information is given
< sipa>
so maybe my earlier claim that it can simplied a lot is an overstatement, but at least it should be possible to avoid all the duplication that exists now
< meshcollider>
yeah that's what I had hoped at the start, but it keeps devolving into lots of if statements :(
< sipa>
yeah
< sipa>
let's first fix the functionality and tests
< sipa>
further improvements can come later
< meshcollider>
agreed
< sipa>
meshcollider: btw, i realized that getaddressinfo doesn't expose issolvable
< sipa>
which seems a pretty obvious improvement, and would make tests for whether importing succeeded much easier
< meshcollider>
mmm I noticed that, I originally thought it did
< meshcollider>
did validateaddress expose it?
< meshcollider>
or was that never possible
< sipa>
i don't think it did
< meshcollider>
sipa: managed to get rid of a bit more duplication in the process, should be better now
< provoostenator>
Github has a new review feature: "New! Suggest specific code changes that the pull request author can immediately commit. You will be attributed in the commit."
< provoostenator>
I'll try it on the importmulti segwit RPC PR, though I suspect it creates entire new (unsigned) commits, which would mess up our usual flow.
< meshcollider>
well, the commits don't need to be signed except the merge commits
< meshcollider>
so who knows :)
< meshcollider>
but most suggested changes in PRs will be nitfixes I imagine, which should be squashed anyway
< provoostenator>
Related thought: it would be very cool if it was possible to co-sign another persons commit, like a superACK.
< sipa>
there is a convention to add "Signed-off-by: <name>" to a commit message
< sipa>
there's even a git option for it, git commit --signoff
< sipa>
meshcollider: moar comments, starting to look good :)
< meshcollider>
sipa: thanks, appreciate the amount of time youre putting into reviewing this, I'll work on them as soon as I can
< sipa>
meshcollider: happy to see someone working on this; we should have done this 2 releases ago, so the alternative is probably that i'd need to do it myself :)
< sipa>
also, it's great to get some more people familiar with this code
< AM5800>
Hi, can someone tell me what is the current status of dandelion (BIP 156)?
< sipa>
AM5800: people are working on an implementation, but there is a lot of unclarity on how to combine it with the DoS protections the current mempool model has
< AM5800>
sipa, thanks. I would like to offer an assistance on this feature, who should I contact?
< sipa>
AM5800: sdaftuar and MarcoFalke are probably people to talk to
< AM5800>
sipa, one final question: what would be the best way to reach them?
< sipa>
irc is pretty good :)
< sipa>
you may need to wait a few hours or days, though
< meshcollider>
sipa: yes, I find the wallet and descriptor stuff all very interesting, much more interesting than say network code hehe
< Drakon>
The option to minimize to system tray instead of the taskbar ist available, but doesn't have an effect if it is started with the -min option. If I start it via that option, I have to click on the program symbil on the taskbar and then minimize it again in order to get it minimized to system tray.
< bitcoin-git>
bitcoin/master ee0b7c4 practicalswift: build: Pin to specific versions of Python packages we install from PyPI in Travis
< bitcoin-git>
bitcoin/master 3036faf Wladimir J. van der Laan: Merge #14496: build: Pin to specific versions of Python packages we install from PyPI in Travis...
< bitcoin-git>
[bitcoin] laanwj closed pull request #14496: build: Pin to specific versions of Python packages we install from PyPI in Travis (master...pin-pip-installed-packages-in-travis) https://github.com/bitcoin/bitcoin/pull/14496
< promag>
ken2812221: do you build bitcoin-qt with msvc?
< bitcoin-git>
[bitcoin] practicalswift opened pull request #14505: Make all single parameter constructors explicit (C++11) (master...explicit-single-argument-constructors) https://github.com/bitcoin/bitcoin/pull/14505
< iceberg>
Hello, I would like to ask question related to the hot wallet implementation of Gemini. Gemini is using the CloudHSM (the cloud-based HSM of AWS) for their hot wallet. As far as I know CloudHSM does not support the secp256k1. How is it possible to implement such a solution? Can such a solution be as safe as if the CloudHSM was supporting the secp256k1? I also asked the question on stack exchange https://tinyurl.com/yaq8al5
< sipa>
you'll need to ask gemini :)
< iceberg>
I am sorry if the question is not relevant for this channel, but I am very curious...
< sipa>
to me personally, "cloud HSM" sounds like marketing nonsense, but I haven't really looked into it
< sipa>
but yes, off topic here
< iceberg>
I asked Gemini and they replied with a link from their website, which didn't help. Thanks for the reply.
< gmaxwell>
I don't know anything about gemini, but it is routine for bitcoin companies to more or less outright lie about their security.
< gmaxwell>
MTGox also claimed to be using HSMs, for example.
< gmaxwell>
Using 'cloud hsm' might just mean they're securing passwords using it. Or they keep the private keys in it normally but routinely export them for signing.
< sipa>
i assume that if gemini claims to be using amazon cloudhsm, then they're indeed actually using those in some kind or form. whether that product actually gives them a security advantage is a very different question though :)
< gmaxwell>
Yes, indeed.
< phantomcircuit>
iceberg, there's keystorage which is what i assume they're using
< phantomcircuit>
i cant see how that would provide any meaningful security
< phantomcircuit>
gmaxwell, well he had them at least
< phantomcircuit>
lol
< ap4lmtree>
hi
< sipa>
what's up with appveyor failing random builds?
< sipa>
or am i actually doing something wrong that travis doesn't catch?
< ken2812221>
The act the same behaviour with mingw builds
< sipa>
ken2812221: i had no idea there was a fix
< sipa>
ken2812221: perhaps you should comment there is one on 14446?
< ken2812221>
I did mention them in issue description.
< sipa>
ken2812221: my apologies
< sipa>
i didn't notice there were fixes mentioned
< ken2812221>
Now I use bold font to mention to fixes in the description. Hope that people won't ignore them again.
< sipa>
ken2812221: thanks!
< sipa>
ken2812221: i'm sorry if i came about as dismissive about appveyor, but i was a bit annoyed how it is interfering with development for little purpose (being compatible with building on windows is a nice to have, but it's not like we'll create production binaries that way)... though i have to take my words back if there are actual issues that are at the basis here
< jnewbery>
sipa: example_test is an example test, for people who don't know how to use our test framework. It didn't used to run in CI. It shouldn't ever fail
< ken2812221>
As laanwj say, the appveyor ci status is not merge blocker. It's a bit racy on Windows, so the error shows more often, we could find the same issue on travis sometimes.