< belcher>
a slight nuance with electrum is it sends hashes of scriptpubkeys, so addresses which are never used stay hidden (of course thats not much better)
< luke-jr>
it does? the protocol spec just has actual addresses though?
< gmaxwell>
belcher: Keeping your irrelevant secrets safe!
< belcher>
luke-jr even if the the protocol supports it, electrum only uses scripthash when requesting
< belcher>
gmaxwell :D
< sipa>
jonasschnelli: in the v2 p2p bip, 02 pubkeys are even and 03 ones are odd
< ghost43>
to clarify, electrum used to send addresses to servers, but around the time bip173 was published, the protocol was changed to sha256(scriptPubKey), to abstract away addresses
< gmaxwell>
I wasn't aware of that until belcher mentioned it above, but it doesn't have any privacy implication.. just allows the protocol to work independantly of address encodings.
< ghost43>
privacy was not a motivation at all. and you are right. I could come up with contrived counterexamples though; like having an address in a forum signature that never receives a transaction, and subscribing to an electrum server; the server would not be able to tie the two identities together. :P
< ghost43>
oh wait that does not work either, lol
< luke-jr>
Lightsword: AIUI, Bitpay rejects payments if they see the transaction broadcast before they get it
< gmaxwell>
09:03:15 < wumpus> gmaxwell: that said, not finding *one* working node in 20+ hours is unexpected I think
< gmaxwell>
thats my thought.... if it was two hours I wouldn't have been surprised.
< promag>
fanquake_: in the 1st log you see it hangs for 19 seconds
< promag>
something is blocking the shutdown
< echeveria>
isn't that expected, to flush the cache to disk?
< promag>
from a clean datadir, launch and wait for some connections, then ctrl-c
< promag>
echeveria: I don't think it could take 20 seconds, especially right on the begin
< promag>
echeveria: my system is also quite fast
< harding>
Took 8 seconds here from after initial connections established but before the first updatetip, on a fresh datadir with master.
< promag>
harding: thanks
< echeveria>
promag: I mean, I can get it to take like 4 seconds to shut down if I attempt a connection, SIGINT, and then it waits briefly for the timeout.
< harding>
Here's the big gap in my log: 2019-03-24T13:54:31Z msghand thread exit
< echeveria>
sort of pales in comparison to most people's time to dump to disk. unless its holding up tests or hitting systemd timeouts I don't see it as an issue particularly.
< promag>
echeveria: if this happens in travis/appveyor then I think it could be improved
< promag>
there are at least 2 "interruptNet.sleep_for(std::chrono::seconds" in the code
< promag>
but not always, I'm trying to figure out what is causing it
< gmaxwell>
turn debug=1 and see if you can see the cause from that?
< promag>
yap
< promag>
but sometimes in travis/appveyor there are random failures when stopping test nodes
< gmaxwell>
your statement about it doing to right away surprises me, but if you said you waited log enough for dbcache to fill I wouldn't be shocked if it took minutes.
< promag>
gmaxwell: first of all, I only observe this in mainnet
< promag>
clear datadir etc
< promag>
bitcoind -debug
< gmaxwell>
promag: thats consistent with it being actual flushing that makes it take time.
< gmaxwell>
so it was waiting on the dnsseed lookups to finish.
< promag>
gmaxwell: oh, but is it LookupHost that takes so long?
< gmaxwell>
It certantly can, it waits on the network.
< gmaxwell>
has anyone noticed the github web ui being a lot slower recently or is it just me?
< gmaxwell>
harding: re your question on the mailing list about the transport BIP: it's hard to coordinate ID assignment. The initial BIP obviously can just do so.
< harding>
gmaxwell: yeah, that's what I didn't understand, why the initial BIP doesn't just do it.
< harding>
(Especially since it is doing it for three of the messages.)
< gmaxwell>
harding: one alternative would be that any further assignments are negoiated at connect time, then variable length could be ignored... but expecting all future messages to get static one byte asignments wouldn't be realistic.
< harding>
I guess. I know there's been some contention over things like getdata msg_type between different node implementations before, but 200+ free values seems like enough space that everyone could just get along (or at least specify what they expect via version messages). Perhaps I'm being too optimistic though.
< harding>
Oh, I guess with encryption and, hopefully, subsequent authentication, we could be expecting to see private extensions to P2P, which could significantly increase the number of message types. Maybe then it does make more sense to have negotiation.
< echeveria>
is there any actually used implementation of a bitcoin node other than btcd and bitcoin core?
< gmaxwell>
harding: it's just too hard process wise to allocate ids.
< gmaxwell>
like even just cordinating expiremental use...
< harding>
echeveria: not that I'm aware of at the moment. I was thinking about 2015-17 contention between Bitcoin Core and some of the stuff Unlimited was doing. Also XT had BIP64 support and a different protocol version.
< gmaxwell>
but negoiation is probably sufficient, I don't really see needing to have more than 256 message types, esp since a message type can be an extended-type-message
< harding>
gmaxwell: fair enough. I've seen enough food fights about BIP numbers.
< gmaxwell>
But I can see an argument that the complexity of variable types would better be spent on negoiation, since thats eventually needed in any case... but like consider a message like "sendheaders" ... there is really no reason to give it a shortid.
< gmaxwell>
so even if there were no variable length types, I think there would need to be one or more "option messages" that could be used for things like send headers, and then thats just introducing a variable length type, but maybe at a different 'layer'
< gmaxwell>
(and maybe making it a different layer is a good idea)
< echeveria>
harding: the only other one I was thinking of was Parity Bitcoin, and they seemed to have only been funded to create that for a very short period.
< gmaxwell>
harding: aside, I kinda worry that too much debate about the shortids will just get them dropped from the protocol... because they're not that important. But I think that would be a bit sad.
< harding>
gmaxwell: thanks for explaining. It looked to me like unnecessary complexity, but as long as there's a reasonable use for it (eliminating developer time wasted coordinating allocation), I'm fine with it.
< gmaxwell>
harding: yeah, I think that serves a purpose.
< gmaxwell>
(you might want to follow up on the list, I'm not on it anymore)
< harding>
:-( Ok.
< gmaxwell>
(ironically, one of the relatively few cases where I think replying would be useful happens shortly after I unsub :P )
< bitcoin-git>
[bitcoin] jonasschnelli closed pull request #14050: Add chacha20/poly1305 and chacha20poly1305_AEAD from openssh (master...2018/08/bip151_chachapoly1305) https://github.com/bitcoin/bitcoin/pull/14050