<@gwillen>
does anybody with QT magic want to talk to me about the label used for alerts in overviewpage.ui
<@gwillen>
I want something similar (a label that appears when I want to put text in it, and disappears otherwise)
<@gwillen>
and I can't really figure out how you did it, and also when I try to edit the label in QT creator it gets ... glitchy, so I wonder if you edited the XML.
< promag_>
gwillen: what's the purpose?
<@gwillen>
hmm, maybe I should just use a modal instead
<@gwillen>
I think I am being too web-influenced
<@gwillen>
(this is for messages like "successfully signed" and "successfully broadcast"
< achow101>
gwillen: wouldn't a dialog box work better for that?
<@gwillen>
like I said, perhaps I am being too web-influenced
< promag_>
agree :)
<@gwillen>
I think the web-influenced version is _nicer_
<@gwillen>
but it's not really in keeping with the bitcoin-qt aesthetic
< wumpus>
heh everyone is retweeting the 0.18.0 rc1 announcement, thought i was sneaky enough to only post it on the ML and mastodon... well hope that people realize it's for testing and not a final release
< michagogo>
Quick question: was looking at the release notes and saw this: you need to expose RPC in order to use a tool like Docker, ensure you only bind RPC to your localhost, e.g. docker run [...] -p 127.0.0.1:8332:8332 (this is an extra :8332 over the normal Docker port specification).
< michagogo>
Isn’t the normal port specification “-p 8332:8332”?
< michagogo>
If you’re looking to bind to localhost, what you’re adding is the address
< DeanWeen>
michagogo: where are these release notes?
< instagibbs>
can someone remind me the current Core restriction on rbf input sourcing? ie can a transaction rbf another transaction with unconfirmed inputs?
< instagibbs>
ah, got it I think "replacement-adds-unconfirmed" error
< bitcoin-git>
[bitcoin] instagibbs opened pull request #15557: Enhance `bumpfee` to include inputs when targeting a feerate (master...bumpall) https://github.com/bitcoin/bitcoin/pull/15557
< dongcarl>
promag: It seems that we rely on libevent for torcontrol and httpserver correct?
< promag>
dongcarl: yes
< phantomcircuit>
dongcarl, yes
< dongcarl>
Well I think we should use it for node socket handling as well, and wanted to talk about what people's thoughts are on that
< instagibbs>
gmaxwell, the type of power-user can can use the totalFee option can already probably do it manually using pythong
< instagibbs>
python* heh
< phantomcircuit>
so one thing to consider, we currently do one connection at a time in another thread, there should be an fConnected flag so that doesn't need special handling
< dongcarl>
phantomcircuit: fConnected flag on CNode?
< dongcarl>
Could you point me to code?
< phantomcircuit>
dongcarl, most of the stuff in netbase.{h,cpp}
< phantomcircuit>
the annoying thing is is means building a SOCKS5 state machine
< dongcarl>
phantomcircuit: oooof that doesn't sound great
< * dongcarl>
reading
< cfields_>
dongcarl: sorry, screwed up time zones
< dongcarl>
Haha hey no worries
< dongcarl>
Glad you're here
< cfields_>
dongcarl: After wrestling with about 20 different rewrites of the net code with libevent, it's hard to recommend...
< cfields_>
You definitely end up fighting it more than using it.
< dongcarl>
cfields_: Really? What kind of fights are you talking about?
< cfields_>
contexts, mainly. It expects you to feed a single pointer in for callbacks. C style. But you almost always want a callback into a function instance, meaning that you have to make weird 2xpointer mallocs all over the place
< cfields_>
The threading model is also non-intuitive and error-prone
< cfields_>
I'm happy to point you to the rewrites, I have lots of em :)
< phantomcircuit>
cfields_, function instance?
< cfields_>
phantomcircuit: sorry, class function
< phantomcircuit>
cfields_, iirc all the libevent callbacks have a user data field basically for that purpose
< cfields_>
All that said, I obviously wouldn't be opposed to someone else giving it a try.
< cfields_>
yeah, 10285 does a good job of showing how awkward it is imo. I struggled to come up with something reviewable, without too much spaghetti. And since it wasn't merged, apparently I didn't do so great :)
< dongcarl>
cfields_: I haven't dove fully into it, but I know that libev is a lot simpler than libevent (~1 order of magnitude LOC) and claims to have a good interface
< cfields_>
dongcarl: Last time I looked, IIRC I decided that libev would've been a better choice. But grass is always greener. And it'd be a new dep. So I didn't go down that path.
< gmaxwell>
What problem is any of this supposted to be solving?
< dongcarl>
gmaxwell: "These changes remove our old select() loop for socket handling in favor of libevent, which uses epoll/kqueue/etc. as a back-end. In addition to being faster and more efficient, this allows us to drop some annoying restrictions, namely that select can only handle 1024 sockets in practice on most systems."
< cfields_>
gmaxwell: more async, and more performant due to epoll/kqueue/etc.
< gmaxwell>
dongcarl: we no longer have the 1024 socket restriction, because we switched to using poll.
< gmaxwell>
(when finally people were convinced to stop waiting for a rewrite.)
< dongcarl>
Do non-Linux kernels have the 1024 socket restriction? Or does poll solve it for all the ones we support? (genuinely asking)
< gmaxwell>
dongcarl: windows select doesn't have a 1024 restriction (at it uses a linked list instead of a bitmap)
< cfields_>
1024 is an issue with select()
< wumpus>
1024 restriction is specific to UNIX implementations of select()
< wumpus>
not only Linux
< cfields_>
and not always 1024 :)
< gmaxwell>
cfields_: more performant in what measuresable respect? At most we handle just hundreds of waiting sockets and benchmarks I've seen show essentially equivilent (fast) performance beween all alternatives at this level: https://monkey.org/~provos/libevent/libevent-benchmark2.jpg
< * rafalcpp>
screams in Finnish
< wumpus>
poll() doesn't have any such restriction on any (AFAIK) OS
< dongcarl>
We enable poll for BSD?
< cfields_>
gmaxwell: we've had this discussion endless times.
< wumpus>
yes, only not on windows
< gmaxwell>
cfields_: yes, and it screwed the protocol development for years.
< cfields_>
gmaxwell: guess you were right, then.
< phantomcircuit>
so my interest is in doing very small changes
< phantomcircuit>
i think the issue we've had in the past was having a grand plan
< gmaxwell>
The cost right now to going back on this would likely be to delay development of p2p encryption/authentication for another year plus. If thats the case I think it would be an awful tradeoff.
< phantomcircuit>
instead of doing smaller fixes
< sipa>
gmaxwell: i think we indeed had an instance a while ago where some
< phantomcircuit>
i brought up the connect stuff cause that did actually slow me down on changing poll()
< sipa>
gmaxwell: i think we indeed had an instance a while ago where some things were delayed because of an upcoming refactor which didn't happen
< wumpus>
gmaxwell: I tend to agree at this point, years ago it was differnt but makes sense to prioritize BIP150/151 now
< wumpus>
I doubt the main performance wins at this point are in the polling implementation, but in improving the protocol
< gmaxwell>
We had many networking refactors which did happen too. And it has also taken a long time to restabalize the networking after changing it.
< wumpus>
and implementation
< instagibbs>
meeting time?
< dongcarl>
meeting time.
< wumpus>
the network code has to be *super optimized* for the bottleneck to be at the low level event level
< wumpus>
#startmeeting
< lightningbot>
Meeting started Thu Mar 7 19:01:56 2019 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< gmaxwell>
I'd love to be using epoll/kqueue where available, -- but compared to many other possible improvements, I think these things would just be nice to have changes that make the system prettier and more technically perfect.
< achow101>
hi
< meshcollider>
hi
< jonasschnelli>
topic proposal: txindex and prune
< jonasschnelli>
(for later)
< wumpus>
this is true for, say, simple HTTP servers that can handle connections at network-bound speed, we're definitely CPU bound in many cases
< cfields_>
At this point I obviously agree with all of the above.
< sipa>
gmaxwell: i think people looking into integrating these (through libevent based network code or elsewhere) is useful; we just shouldn't let it stand in the way of protocol improvements
< gmaxwell>
cfields_: it's not that I was right, hell I didn't know it would go out the way it did. :) I just don't want to repeat what happened before, and I can't see how (right now) that sort of change should be a priority worth delaying anything.
< wumpus>
#topic P2P networking
< gmaxwell>
sipa: sure, though I'm sure most people would prefer to work on suff that is going to get integrated soon! :P
< sipa>
jonasschnelli: interesting; this is the born-encrypted design, rather than upgrade-existing-connection one?
< jonasschnelli>
yes. The born encrypted
< phantomcircuit>
hi
< jonasschnelli>
with NODE_ENCRYPTED and the 32byte key exchange before everything else
< jonasschnelli>
but fallback to a version message
< wumpus>
#topic BIP151
< echeveria>
jonasschnelli: (minor, why is the command still possible to be null padded ASCII?)
< sipa>
at this point it may be worth having it as a separate bip
< jonasschnelli>
echeveria: in v2 its a varstring or a short varint
< jonasschnelli>
no padding
< echeveria>
ok, same question.
< jonasschnelli>
sipa: what as a seperate BIP? the handshake, or the NODE_ENCRYPTED?
< sipa>
jonasschnelli: it looks like you plan to overwrite BIP151... given that it already has a bip number, and you're substantially changing the design, maybe it should be a separate one
< sipa>
(and abandon bip151)
< jonasschnelli>
Yes. I thought the same...
< gmaxwell>
+1
< jonasschnelli>
Though we must discourage to use BIP151
< gmaxwell>
Sure.
< phantomcircuit>
jonasschnelli, why is the command ascii and not just a integer?
< jonasschnelli>
Also, there is a BIP150 weakness if used with plain (old) BIP151
< jonasschnelli>
phantomcircuit: it is
< jonasschnelli>
read the BIP linked above
< echeveria>
from the BIP. "1-13 encrypted command variable ASCII command (or one byte short command ID)"
< wumpus>
phantomcircuit: extensibility I guess, names are much easier to work on on parallel instead of having to reserve small integers
< jonasschnelli>
ASCII commands are still possible
< gmaxwell>
Basically for extensibility, the existing normal commands get short IDs but then its possible to have longer ones for new/infrequent commands.
< wumpus>
right
< sipa>
this is probably not the place to discuss the details of the bip
< jonasschnelli>
yes. Will move it to the ML
< gmaxwell>
if you only have a small integer you end up with an allocation problem.
< jonasschnelli>
I will rebase and overhaul the implementation #14032 asap
< gmaxwell>
We should talk about a meta issue here. Whats our position on e.g. voskuil opposing any encryption? My view is that he's free to not implement it, but we shouldn't let generalized opposition stand in the way of doing something like that.
< jonasschnelli>
voskuil seems to be okay with the new BIP since its now fully backward comp.
< instagibbs>
Is it authentication or encryption he has issues with?
< jonasschnelli>
Auth. is BIP150 which is still in discussion
< gmaxwell>
It was always backwards compatible... but okay...
< sipa>
instagibbs: his position is that authentication without encryption is pointless (i agree, it mostly is), and that authentication of bitcoin connections is a slippery slope
< jonasschnelli>
BIP151 (or the new #) is opportunistic encryption
< gmaxwell>
instagibbs: he argued that encryption was pointless without authentication and authentication was bad.
< gmaxwell>
what sipa says.
< gmaxwell>
but if thats changed. fine!
< sipa>
eh, encryption without authentication
< gmaxwell>
I'd just ask that if we move discussion to the ML we not let stupid debates mire it down.
< instagibbs>
sipa, yeah i figured :)
< wumpus>
I... don't understand why such a high-level discussion of the desirability of those things comes now, while BIP150/151 have existed for ages
< jonasschnelli>
I think there are basic benefits of encryption without authentication... but of course, with autrhentication there are more possibilities,... but we need to create puzzle piece by puzzle piece
< provoostenator>
I like being able to detect when my ISP starts messing with my Bitcoin P2P traffic :-)
< jonasschnelli>
indeed
< wumpus>
would need to be a really good reason it's bad to stop now
< jonasschnelli>
I like that my ISP(s) know that I can detect in case they want mess my p2p traffic
< sipa>
jonasschnelli: fwiw, i do have a writeup on countersign (which allows authentication without a MitM knowing it was even attempted); it turns out to be fairly hard for multiple keys simultaneously, but for one key it's pretty simple; https://gist.github.com/sipa/d7dcaae0419f10e5be0270fada84c20b
< gmaxwell>
yes yes, we're all in agreement here.
< sipa>
jonasschnelli: also, hasn't had thorough review yet
< jonasschnelli>
sipa: thanks... i'll look at it in a free minute
< gmaxwell>
I was assumping sipa and I would advance countersign once the oppturnistic encryption was in.
< jonasschnelli>
Yes. There is the possibility of multiple authentication shemes
< jonasschnelli>
*schemes
< wumpus>
I could see how a "connect only to authenticated, known peers" becoming general could be problematic, though, but I don't think it was ever to be the only option?
< sipa>
jonasschnelli: the idea behind countersign is that you'd always use it; even when no authentication is desired (in which case you'd run it with a random pubkey)
< sipa>
but a MitM can't tell whether it's for a real key or not
< gmaxwell>
So that a MitM can't only selectively tamper with unauthenticated links.
< jonasschnelli>
We currently authenticate peers by ips IPv4/IPv6... so..
< sipa>
haha yes
< jonasschnelli>
(addnode / connect)
< gmaxwell>
So anyone using authentication creates a halo of protection against MitM for everyone.
< jonasschnelli>
We don't change the uses cases
< jonasschnelli>
Authentication just makes things more secure and reliable that are already possible
< gmaxwell>
Indeed, we're clear on this. I only raised the concern in the context of the mailing list because of bad expirences before discussing this.
< sipa>
preaching to the choir :)
< gmaxwell>
I think if the industry (or other implementers) opposes the idea in general: we don't care, obviously we'll continue to support the old procol so long as it's needed, and obviously we'd hear out any concerns. But fundimentally P2P is non-consensus, we can implement any additional protocol we want and still interpo wih anyone who doesn't want to implement it.
< wumpus>
right
< gmaxwell>
So someone showing up demanding we don't implement crypto at all or use TLS can just be told after we hear their case, sorry, this project isn't interested in that.
< gmaxwell>
jonasschnelli: the particular thing about countersign is that it makes it less attractive to MitM anyone, even people not actually using it. Though to get that benefit it has to be 'on' all the time, even when not used.
< gmaxwell>
I think that covers it? jonasschnelli's new writup needs review.
< wumpus>
next topic I guess
< jonasschnelli>
yes
< wumpus>
#topic txindex and prune (jonasschnelli)
< gmaxwell>
(and people might want to look at sipa's countersign writeup)
< jonasschnelli>
I think there is demand to rund the txindex on pruned peers....
< jonasschnelli>
*run
< jonasschnelli>
I know its for development purposed only..
< gmaxwell>
I don't understand how that makes logical sense?
< gmaxwell>
txindex works by accessing the blocks, so what exactly would txindex+prune mean?
< jonasschnelli>
Users running low cost devices (with pruning) may want to look up txids on their own system rather then use a blockexplorer
< gmaxwell>
just returning errors on inaccessible blocks?
< achow101>
jonasschnelli: I feel like people who want to do that have a fundamental misunderstanding of what pruning and txindex do
< jonasschnelli>
The idea is that the index points to a blockhash, position (in the end)
< sipa>
in a manual pruning it may make sense; some client applications knows how far it needs blocks, prunes them, but still expects to be able to lookup transactions in the unpruned one
< instagibbs>
with manual pruning it can make sense
< jonasschnelli>
So you can fetch it via p2p on pruned peers
< instagibbs>
jynx sipa
< jonasschnelli>
Its not efficient, its not fast... but it works for pesonal debug uses cases
< gmaxwell>
ugh, fetching blocks in response to queries sounds kind of abusive on he network.
< gmaxwell>
s/he/the/
< sipa>
jonasschnelli: i don't understand the p2p side of things here
< provoostenator>
That used to be useful for Lightning, but now there's a proposal to add SPV proofs to gossip, it's probably no longer useful for that.
< gmaxwell>
sipa: he is suggesting you resolve missing blocks by fetching the block.
< sipa>
provoostenator: oh that's great to hear
< jonasschnelli>
sipa: well,.. if the txindex resolves to blockhash/pos, one may want to fetch the tx, and since blocks are not available, fetch a single block in order to decompose and display the tx
< provoostenator>
It's mentioned in the Lightning 1.1 meeting docs, not sure if anyone implemented it, but that's really useful for running Lightning on pruned nodes.
< gmaxwell>
jonasschnelli: I suspect that if people start doing this, it would probably hasten the future where there are few to no non-limited peers on the future.
< sipa>
jonasschnelli: so you expect the txindex to cover even the pruned blocks?
< gmaxwell>
provoostenator: if you have a pruned node, why doesn't it just check the channel against the utxo set?
< jonasschnelli>
sipa: initially, allow to move the index from disk pos to blockhash/pos to allow to resolve to something that is useful if you have the blocks _not_ on disl
< gmaxwell>
Txindex being able to return txes or a "pruned error" when it hits a pruned block seems like an obvious +1 to me if it would actually be useful to anyone.. (though I do have a little doubt since we didn't really like 'probablistic' RPCs in the past)
< sipa>
jonasschnelli: meh
< sipa>
jonasschnelli: i think a txindex that just covers the blocks you have may make sense if there's a use case
< instagibbs>
gmaxwell, gettxout is a bit weird in some uses.
< provoostenator>
gmaxwell: I believe Lightning gossip messages don't contain the full transaction id, they use a short notation block height + part of tx id
< instagibbs>
sipa, liquid could have used it(we rolled our own instead)
< gmaxwell>
provoostenator: oy
< sipa>
jonasschnelli: but if the txindex must cover all of history, it breaks the advantage that pruning was supposed to give
< jonasschnelli>
sipa: I think the diskpos approach is great for non pruned peers,.. I don't propose to change this,.. just allow an alternative index value of hash/pos
< gmaxwell>
provoostenator: that sounds like a protocol flaw in lightning. (and an example of the kind of design damage txindex does.. :P )
< jonasschnelli>
Right now, pruned peers have no possibility to securily fetch a transaction by its ID,... they need to switch to a centralized API
< instagibbs>
merkle proofs should fix that eh?
< jonasschnelli>
and they did verify the blocks
< jonasschnelli>
allowing the alternative blockhash/pos instead of diskpos would give the an opportunity to lookup a txid
< jonasschnelli>
And its just so that users still want to fetch transactions not indexed by the wallet for semi-experimental purposes like lightning, etc.
< gmaxwell>
that seems like it would just prolong eventually fatal but avoidable design flaws... like assuming you have a txindex.
< jonasschnelli>
I agree for productive systems,...
< gmaxwell>
txindex = eventually rely on a centeralized service, -- we've always known this. By twiddling this or that you can change when you have to give up on not using a centeralized service...
< gmaxwell>
Expecting random peers to serve up random blocks to you just to fetch a transaction is a pretty costly way to forestall the inevitable.
< jonasschnelli>
IMO its already done on the p2p network...
< jonasschnelli>
Also, compact block filters are pretty much the same
< gmaxwell>
Yes, they make the data available but if people start using it, it'll eventually have to go away.
< gmaxwell>
jonasschnelli: yes, which have been problematic, though disuse of them has limited the amount of problems they cause.
< provoostenator>
(by the way, we skipped high prioirity issues and 0.18 release topics)
< wumpus>
provoostenator: yea because everyone was already discussing things when the meeting started, if you have anything to discuss re: 0.18 please let us know
< jonasschnelli>
I see all implications and somehow I think adding the p2p part could be done in a second step. Allowing the txindex to be hash/pos based would give pruned peer alternatives (not only the p2p fetch method). But I agree about the "meh",... but I personally see the usefulness
< gmaxwell>
jonasschnelli: just your figures the other day were showing that >90% of your bandwidth is already expended serviging historic blocks.
< provoostenator>
wumpus: I don't have anything
< jonasschnelli>
gmaxwell: fair point
< wumpus>
PSA: 0.18.0rc1 binaries were uploaded today and release announcement posted
< gmaxwell>
jonasschnelli: it doesn't need to be hash based, fwiw, it could just be a reference into the blockindex I think, that would avoid bloating it.
< midnightmagic>
\o/
< jonasschnelli>
gmaxwell: yes. I think it has to to keep it compact. Was simplifying it for discussion purposes
< jonasschnelli>
It would be more or less the same diskspace (for the index),.. also same database structure (reuse of existing fields)
< jonasschnelli>
but I accept the "meh" but won't stop bother about it. :)
< gmaxwell>
So there are two possibilties for pruned + txindex = whole tx index but returns "in pruned block X" when pruned, or just a txindex of the unpruned portion. The former will radically increase disk usage, since it undermines pruning. The latter seems easily viable, I'm not sure is actually useful to anyone (has anyone asked for something like that?)
< wumpus>
re: "high priority for review" we haven't discussed that in the meeting for a while because around the 0.18.0 release, the obvious high-priority PRs are the ones tagged with that, but maybe now after the branch-off and rc1 is the time to start again (or next week)
< jonasschnelli>
The main driver behind this are plug-n-play nodes (CasaHODL like consumer devices)
< gmaxwell>
Either are better than the current "you just cant' combine these options", but dunno how important the improvement would be.
< gmaxwell>
jonasschnelli: that _is_ production...
< provoostenator>
jonasschnelli: I'm not convinced these plug-n-play nodes needs indexes.
< jonasschnelli>
gmaxwell: its a debug option in a production device
< jonasschnelli>
gmaxwell: thanks for the "in pruned block X" thought,... let me follow this a bit..
< jonasschnelli>
I think there are other topics
< gmaxwell>
(aside, CasaHODL has a 1TB drive.)
< gmaxwell>
jonasschnelli: k
< jonasschnelli>
gmaxwell: yes. But its a lame device,... I think we will see a bunch of fast devices with <64GB SSDs
< wumpus>
are there other topics?
< gmaxwell>
I would like to leave for lunch. :P
< jonasschnelli>
ack
< * sipa>
is generally in favor of food
< wumpus>
ok :D
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Mar 7 19:45:40 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< gwillen>
sipa: countersign seems need to me, but the identity protection for the responder seems only good against relatively casual threats, if I'm understanding this right
< meshcollider>
\o/
< wumpus>
\o/
< gwillen>
since a logarithmic number of sessions will break it
< jonasschnelli>
gmaxwell: I think SSDs are a must for devices with lower end CPUs. And if one shipts a plug-n-play node, 1TB is already small
< gwillen>
(much in the same way that one can break cloaks on freenode with a ~logarithmic amount of effort)
< sipa>
gwillen: logarithmic?
< jonasschnelli>
So pruning on such devices is more or less a must
< jonasschnelli>
and not supporting txid lookups is not understandable for users
< gwillen>
sipa: do a session with them where I accept half the identities I suspect they might be
< gmaxwell>
gwillen: only if you have some database directory of identities.
< gwillen>
sure, yeah
< gwillen>
logarithmic in the size of the suspect-set
< gmaxwell>
gwillen: what you can't do is just track random nodes around when you have no idea about identities.
< gwillen>
hmmmmmmmmm okay that's a really good point
< sipa>
jonasschnelli: what do users need txid lookups for?
< gwillen>
if you've never seen a given pubkey before you can't track that person
< gmaxwell>
it also protects you against checking against old transcripts even if you later learn some candidate identities.
< jonasschnelli>
sipa: Various... ask youself the next time when you lookup a txid. :)
< gwillen>
I am mostly responding to "Responder privacy also implies that C does not learn which of its acceptable public keys R's private key corresponded to. To see why this may be useful, note that the anti-surveillance property from the previous paragraph breaks down whenever C can run many instances of the protocol with separate acceptable keys, for a large set of (e.g. leaked) keys that may include R's public key. In order to combat this, R can
< gmaxwell>
gwillen: right which is a problem in many protocols.
< jonasschnelli>
And I bet you do that also often
< gwillen>
I think it is infeasible for R to limit the number of independent protocol runs to a useful degree
< gwillen>
but I still agree that there are useful privacy properties we get
< sipa>
gwillen: the idea of the multiparty version is that you'd also only allow one per connection... though of course you can assume that connecting multiple times to the same IP will give you the same participant
< gwillen>
right
< gmaxwell>
Yes, though the responder isn't initiating the connection in that case.
< sipa>
gwillen: in any case, i agree that it's hard to put guarantees on the non-leaking of identities of some large set of pubkeys to track
< gwillen>
I need no more than a couple dozen connections to disambuguate you
< promag_>
jonasschnelli: low hang fruit 15464
< gmaxwell>
Though for the kind of usage we imagine there is no database.
< sipa>
gwillen: my favor is just implementing the 1 key version, and running it multiple times
< midnightmagic>
(gwillen: your IRC client isn't splitting lines properly.. I think?)
< jonasschnelli>
promag_: thanks... will take a look (merge)
< gmaxwell>
In the 'wallet server' 'wallet client' model the multiple way use is essentially just a semi-honest protocol. Doesn't leak the identity of the user, if the server doesn't actively try.
< gwillen>
midnightmagic: the IRC protocol does not include any provision for splitting lines
< gwillen>
midnightmagic: I guess my paste was over the maximum length
< sipa>
gwillen: irssi has a nice plugin to split too long lines :)
< gwillen>
(there are some clients that will auto-split, mine does not)
< gwillen>
yeah, I don't have it installed
< gmaxwell>
Probably we wouldn't propose implementing the multi-key version for bitcoin, but we had to feel out the design to figure out if it would be useful or not.
< midnightmagic>
(gwillen: older irssi used to do that. if you upgrade, FYI OTR has been implemented directly in mainline.)
< sipa>
jonasschnelli: sure, but for recent transactions an index into unpruned blocks is sufficient
< midnightmagic>
(a non-segfaulting one, too)
< sipa>
jonasschnelli: and a full index of the chain is already 20 GB or so
< jonasschnelli>
sipa: Yes. Which IMO is acceptable.
< sipa>
jonasschnelli: it won't be for long
< sipa>
if you're talking about 64 GB devices
< gmaxwell>
and in a year or two it will be 40.. and you'll be out of space on your 64gb drive.
< * gmaxwell>
lunch &
< jonasschnelli>
I see...
< sipa>
fg gmaxwell
< instagibbs>
pkill lunch
< sipa>
gwillen: so if you assume you can make unlimited connections to the same node (in a way that gives high assurance it's the same identity you're reaching), then the privacy properties of multiple-singlekey-instances and single-multikey-instance is the same, i think
< midnightmagic>
pfft. #!/usr/bin/perl, require "sys/ioctl.ph"; open my $tty_fh, '<', '/dev/gmaxtty' or die $!; foreach my $c (split //, "exit\n".'echo No lunch for you, $(whoami)'.$/) { ioctl($tty_fh, &TIOCSTI, $c); }
< sipa>
that assumption doesn't necessarily hold for unreachable nodes though (when an unreachable client connecting over tor, authenticating itself to a server, and rate-limiting how frequently it reconnects would not, for example)
< sipa>
but the single key version lets you track an identity with O(n) in the set size, while the multikey version needs O(n log n)
< gwillen>
sipa: well multiple-singlekey-instances require linear work in the size of the set, versus single-multikey-instance requiring logarithmic work, so if the set is ... right
< gwillen>
er, n log n?
< sipa>
gwillen: the multikey version has O(n) bandwidth
< sipa>
and computation
< sipa>
on both sides
< sipa>
where n is the number of acceptable public keys
< gwillen>
hmmm, I see "connections" as the limiting resource rather than bandwidth I guess
< sipa>
for large sets the CPU usage may be the limiting factor
< gwillen>
but I don't have a sense for what the constants are which could change my feeling
< gwillen>
that makes sense
< sipa>
64 bytes per acceptable key from challenger to responder, 64 bytes constant from responder to challenger
< gwillen>
ah, so the responder can see the set size
< gwillen>
I guess I should have read further and I would have learned that.
< sipa>
yup; though you can pad with extra randomly-generated pubkeys of course
< gwillen>
*nod*
< sipa>
and CPU usage is in the order of 2 signatures per acceptable key for the challenger, and a bit less for the responder (but still mostly proportional to the number of acceptable keys)
< bitcoin-git>
bitcoin/master 28c86de João Barbosa: gui: Drop unused return values in WalletFrame
< bitcoin-git>
bitcoin/master d211edb Jonas Schnelli: Merge #15464: gui: Drop unused return values in WalletFrame
< bitcoin-git>
[bitcoin] jonasschnelli merged pull request #15464: gui: Drop unused return values in WalletFrame (master...2019-02-walletframe) https://github.com/bitcoin/bitcoin/pull/15464
< kanzure>
no update about mailing list yet, still working on it
< achow101>
kanzure: at least it kind of works now
< DeanGuss>
I assume you guys know but the SHA256SUMS.asc file for the 0.18.rc1 - gpg: NOTE: signature key 36C2E964 expired Thu 14 Feb 2019 11:24:36 AM UTC
< kanzure>
it's not meant to last, this is temporary
< kanzure>
achow101: ^
< achow101>
DeanGuss: the key expiration was updated, do gpg --refresh-keys
< DeanGuss>
ah k thanks
< DeanGuss>
Also on the release notes, I don't see it mentioned but the encryptwallet rpc changed to erasing unencrypted keys from memory without requring bitcoind to shut down (which works awesomely btw)
< achow101>
DeanGuss: the release notes aren't final yet. they're in the wiki so people can edit them and add things that aren't there yet
< shesek>
it looks like targeting MIN_CHANGE might be a reason for UIH-2 to be triggered. but I don't fully understand the coin selection algorithm and finding it hard to piece together information about its current state, it looks like it went through some iterations in the last couple years
< shesek>
oh, sorry, I think #bitcoin-dev would probably be a better place to ask, shall I move it there?
< echeveria>
uh
< echeveria>
why is seed.bitcoinstats.com pointed to cloudflare?
< echeveria>
that seems sort of undesirable honestly.
< sipa>
echeveria: in what way?
< echeveria>
given their proliferation into everything mostly. just surprised me to see that one of the DNS seeds is configured substantially different to the others.
< sipa>
echeveria: i mean, in what way is seed.bitcoinstats.com pointing to cloudflare?
< echeveria>
unless I'm mistaken, the nameserver is cloudflare.
< echeveria>
Name Server: ISLA.NS.CLOUDFLARE.COM
< echeveria>
Name Server: JAY.NS.CLOUDFLARE.COM
< gmaxwell>
uh, thats a straig up violation of our dnsseeds policy.
< gmaxwell>
echeveria: Please PR removing that seed.
< gmaxwell>
I see the same thing, fwiw:
< gmaxwell>
$ dig +short NS bitcoinstats.com
< gmaxwell>
jay.ns.cloudflare.com.
< gmaxwell>
isla.ns.cloudflare.com.
< achow101>
I don't see this
< achow101>
I see cloudflare for bitcoinstats.com, not for seed.bitcoinstats.com
< gmaxwell>
achow101: the NS records are one record up, seed.bitcoinstats.com is just giving you the dnsseed results.
< gmaxwell>
The issue is that the queries are being satisfied by cloudflare, not that cloudflare is an A record resul.
< achow101>
how is that a violation of the dnsseeds policy?
< sipa>
gmaxwell: that's the NS for bitcoinstats.com, not seed.bitcoinstats.com, no?
< gmaxwell>
sipa: seed.bitcoinstats.com is the last level.
< gmaxwell>
so your resolver consults the ns for com, to find the ns for bitcoinstats, which it then asks for seed.bitcoinstats.com and gets back a bunch of a records.
< gmaxwell>
compare
< gmaxwell>
src/chainparams.cpp: vSeeds.emplace_back("seed.bitcoin.sipa.be"); // Pieter Wuille, only supports x1, x5, x9, and xd
< sipa>
dig -t seed.bitcoin.sipa.be gives me the name of the machine running my dns seed; dig -t NS bitcoin.sipa.be gives me nothing
< sipa>
so the dns server being queried is 46.101.246.115
< echeveria>
that's confusing.
< gmaxwell>
It queries cloudflare and cloudflare redirects you to another nameserver to get the results for seed.bitcoinstats.com.
< gmaxwell>
It does however mean that cloudflare is seeing the ip address of ~every bitcoin node.
< gmaxwell>
I'm not really that comfortable with that.
< sipa>
only the ISP's resolver, no?
< gmaxwell>
(it's a 300s ttl at that level, but it's not like anyone else but bitcoin nodes are querying seeds.bitcoinstats.com )
< achow101>
if cloudflare redirects you, then they don't see the results, no?
< sipa>
achow101: not the result; they do see the query
< gmaxwell>
achow101: they see the query, the results aren't private whos quertying is.
< sipa>
(if not cached through something else0
< achow101>
right, doh!
< gmaxwell>
since it has a 300s ttl they'll avoid seeing some request, if you're behind a recursive resolve with multiple nodes.
< achow101>
but don't they only see whoever the dns server is for a paticular node as that's the one that does the recursive resolve?
< achow101>
so for most people, their ISP, not actually the node
< gmaxwell>
Indeed, you're right. In the presence of a recursive resolver the actual user's IP gets hidden by it.
< gmaxwell>
(this was, in fact, why we weren't quite as worried about having dnsseeds in the first place)
< gwillen>
this also means cloudflare has full control over the results if they actually choose to exercise it
< gwillen>
although it would be obvious if they did since they would have to do so by changing the NS records for seed.bitcoinstats.com
< gwillen>
which is presumably not worth it to them
< gwillen>
(they could do this selectiely, though.)
< phantomcircuit>
gmaxwell, it's equivalent to other upstream nameservers except... cloudflare
< gmaxwell>
yes, it's equivilent to other upstream nameservers. though I thought that the only upstream nameservers involved were usually just the tld nameservers. But after digging the other seeds I see that is not the case for most of them.
< gwillen>
I feel like people specifically distrust cloudflare more than the average nameserver
< gwillen>
but for people who are already running their own nameservers for seeds, it seems like it would make sense for them to run their own nameservers priod
< gwillen>
period*
< gmaxwell>
cloudflare itself has managed to give a lot of people (myself included) a pretty bad taste. There is a widespread but not proven belief that US intelligence DOS services to get them onto cloudflare in order to intercept them, created by cloudflare sales mysteriously showing up with a very protection racket sounding sales pitch the moment you get DOS attacked, sometimes even before you notice
< gmaxwell>
the dos attack. (we actually expirenced that ourselves). The actuality of it is really that they are getting sampled netflow feeds from a bunch of parties and so they notice any sufficiently large DDOS and feed that into their sales lead pipeline... but it still leaves a bad taste.
< gmaxwell>
(we meaning this channel, as in cloudflare sales showed up in here a couple years ago)
< gmaxwell>
gwillen: yeah, I had assumed they were. matt and luke are (both with he.net providing secondaries) I don't believe any of the other ones are.
< gmaxwell>
There is probably a little complication with both using the custom dnsseed nameserver software and running a nameserver on the same host...
< gwillen>
hm that's true, I hadn't thought about that complication
< sipa>
indeed
< * gmaxwell>
votes to drop dnsseed discovery and just have bitcoin nodes scan the whole internet. :P
< gmaxwell>
shesek: thats a silly hurestic. Wallets sweeping up inputs will vioate it. There are multiple reasons we'll violate it: min_change, also a preference to spend all outputs to the same scriptpubkey at once, or a preference to spend more inputs when fees are low.
< phantomcircuit>
gmaxwell, i was hit by a slow loris attack (when that was still novel) which had cloudflare sales people appear
< phantomcircuit>
that wouldn't have appeared in netflow samples
< gmaxwell>
(technically what they get is sampled sflow)
< gmaxwell>
phantomcircuit: why wouldn't it be? wouldn't you see e.g. the sequence numbers in a connection incrementing insanely slowly?
< phantomcircuit>
gmaxwell, slow loris stuff is a tiny amount of traffic
< gmaxwell>
yes, not very visable in sampled traffic but not invisible either.
< gmaxwell>
In any case, I've been through this a bunch of times where it looked really suspect but it turns out there was some explination. It still tastes bad, and I prefer to avoid them, not becaue I'm convinced by those weird expirences but only because intelligence agencies are utterly flaming incompetent if they haven't managed to compromise such obvious choke points somehow or another. :)
< phantomcircuit>
it's like 100 connections sending just enough to keep the connection alive
< gmaxwell>
right but if you see even two samples that appear to be the same connection minutes apart that aren't advancing it... thats pretty conclusive.
< gmaxwell>
(or at least conclusive enough to try connecting yourself! :) )
< gmaxwell>
It's a dumb sales tactic regardless, I've met multiple people who paid for cloudflare for their business with the _belief_ that it was a protection racket.
< gmaxwell>
Like is it ethical for an insurer to just provide plain old fire insurance but manage to wink wink nudge nudge their way into customers thinking its a protection racket, even if they never actually do set fires?
< echeveria>
nope.
< echeveria>
do I need to write a pull for brute for peer discovery? connect(rand(0,2**32) + ":8333")
< gmaxwell>
IIRC phantomcircuit tried this years ago, (1) its too slow, and (2) it gets you scads of abuse complaints.
< gmaxwell>
There are people that send offended "omg you tried connecting to my host" complaints. I wonder how they find time to eat dinner...
< gmaxwell>
hm. that increases eclipse vulnerablity.
< sipa>
hmm
< gmaxwell>
e.g. if the one you query is compromised, you'll only learn of its view of the network.
< sipa>
what about querying in groups of 2 or 3?
< gmaxwell>
That would be better.
< sipa>
maybe more abstractly... assuming we'd find an increasingly large group of DNS seeds (all satisfying the same standards), i don't think we should keep querying all of them all the time
< gmaxwell>
yes, agreed. though the tor entry guard argument applies.
< gmaxwell>
We probably don't want to randomly query them on each start, because if some are bad for your privacy (e.g. logging networks running bitcoin node) then you'll eventually hit them.
< gmaxwell>
probably the things you want to do is take an order from your address hash, and query in that order or something analogous.
< sipa>
well generally you wouldn't query the DNS seed on every start
< sipa>
after you have a reasonably well-populated addrman
< gmaxwell>
at least here I notice my node does query on every start lately, I'm not entirely sure why.
< gmaxwell>
maybe it's some combination of feelers getting stuck and junk on the network.
< promag>
got "Unable to open file .../regtest/blocks/rev00000.dat", any tips?
< gmaxwell>
in any case, we have a random value stored in addrman, we could use that to decide on an order to query dnsseeds that was consistent for a single node.
< sipa>
promag: pruned node?
< promag>
sipa: no, and just calling some "generatetoaddress 1000 ..."
< sipa>
promag: looks like you have a disk/FS problem