< bitcoin-git>
[bitcoin] laanwj closed pull request #10890: libbitcoinconsensus: Add version field to pkg-config info file (master...master) https://github.com/bitcoin/bitcoin/pull/10890
< BlueMatt>
cfields: we should be preferring steady_clock over high_resolution, I think, and then we can static_assert something about the resolution being at least microsecond or so...
< wumpus>
BlueMatt: I also commented about that on the original PR
< wumpus>
apparently the steady clock is usually the same resolution as the high resolution clock
< wumpus>
this just handles the rare case where the high resolution clock is higher resolution (but not steady) in which case a higher resolution is probably preferred
< BlueMatt>
wumpus: indeed, but it seems nonsense to prefer high_resolution over steady *unless* their resolution is the same
< BlueMatt>
really? I mean its not like any of our runs require *that* much precision
< wumpus>
I don't think I agree on that, for benchmarks precision is always preferred
< BlueMatt>
microsecond is more than enough, even millisecond is probably fine especially after the next pr
< wumpus>
I mean the difference is that the steady clock isn't affected by time changes, but those should be rare anyhow right?
< BlueMatt>
but precision is nonsense if you're running ntp - the chance that your clock is running fast/slow randomly is not 0 and the gain you get from microsecond to something smaller is ~0
< wumpus>
running benchmarks on a system where the time is jumping crazy around sounds like a stupid idea to me
< BlueMatt>
most systems have ntpd, though....
< BlueMatt>
I think its like built-in to systemd or some batshit insane shit now
< wumpus>
ntp is supposed to increase time precision, not decrease it
< wumpus>
e.g. it explicitly doesn't do any large sudden corrections
< BlueMatt>
but it does corrections by making your clock run fast/slow when it detects your clock to be off (or your network path to have changed.....)
< wumpus>
that's the point, yes
< MarcoFalke>
I read that as a point for the steady_clock
< Victorsueca>
Came here to say it, but seems like you already noticed master is failing a lot lately
< wumpus>
Victorsueca: a lot?
< BlueMatt>
Victorsueca: usually master travis failures are cause travis will cancel a job if you push something new on top of it, so github shows them as failed
< MarcoFalke>
what do you mean? The tests?
< BlueMatt>
though master is actually failing right now, but its the first I've seen that in months
< wumpus>
these kind of merge conficts are incredibly rare
< Victorsueca>
BlueMatt: ahh that explains it
< wumpus>
currently testing BlueMatt's change
< sipa>
far better to have it fail to compile/test than have bugs
< BlueMatt>
Victorsueca: I often restart them cause I'm super ocd, though I should probably stop doing that cause it stops testing other things......
< wumpus>
absolutely
< MarcoFalke>
I mean we have a backlog anyway and that motivates people to compile and run locally
< MarcoFalke>
So I don't see huge issues with that
< BlueMatt>
yea, we almost always have a backlog during business hours :/
< * BlueMatt>
works on weekends, suckers :p
< BlueMatt>
wumpus: eg https://github.com/coreos/bugs/issues/391 which talks about how, yet again, systemd be breaking shit, in this case cause its timesyncd (which will now be default, I guess, on most hosts) is not accurate enough for ceph
< wumpus>
BlueMatt: yes thinking about it some more I agree with you
< BlueMatt>
given steady_clock usually has very good precision and the point of benchmarks is usually to figure out if things changed from one commit to another, not to compare between hosts, I think we should prefer that
< wumpus>
yes, indeed
< BlueMatt>
k, willfix
< wumpus>
it also simplifies the code if we always use the same clock
< bitcoin-git>
[bitcoin] TheBlueMatt opened pull request #11646: Require a steady clock for bench with at least micro precision (master...2017-11-11562-cleanups) https://github.com/bitcoin/bitcoin/pull/11646
< BlueMatt>
wumpus: hmmm, re: #11583 I kinda feel yucky adding a BCLog category that just means "ALWAYS log" - would you be ok with a #define function which does the LogPrint/LogPrintf call based on pnode->fInbound?
< gribble>
https://github.com/bitcoin/bitcoin/issues/11583 | Do not make it trivial for inbound peers to generate log entries by TheBlueMatt · Pull Request #11583 · bitcoin/bitcoin · GitHub
< wumpus>
BlueMatt: I kind of like the idea of having a always-log category
< wumpus>
BlueMatt: it means LogPrintf could be defined in terms of it, and at some point only one log function would be needed anymore
< wumpus>
myself I always get confused between Logprint and Logprintf also because they are named so similarly
< BlueMatt>
true.....
< BlueMatt>
man i hate having a one-of-these-things-is-not-like-the-other enum :(
< wumpus>
well there is already a ::ALL
< BlueMatt>
yea, but at least thats just defined to ~0
< wumpus>
maybe we could use that as "log always"?
< wumpus>
it doesn't really matter what it's defined to, just how it's handled :)
< BlueMatt>
hmmmm, I thought about that briefly but decided I prefer an ::ALWAYS cause then you're even more confused....-debug=0 means ~0 still logs?
< BlueMatt>
even though ~0 & 1 doesnt?
< BlueMatt>
errr, ~0 ^ 1
< wumpus>
hrm yeah
< wumpus>
can't we just move those messages always to ::NET :-)
< BlueMatt>
alright, I'll take a dive down the ::ALWAYS rabbit hole and see where I end up
< wumpus>
that would remove this entire issue
< BlueMatt>
I mean its nice to know when your outbound peers succeed in connecting
< wumpus>
I mean they *are* net messages
< BlueMatt>
I could add a second log for that
< wumpus>
yes
< wumpus>
maybe that's better
< BlueMatt>
ok, fine, will table the ::ALWAYS discussion
< wumpus>
the root issue really is that we confound log class and log priority
< wumpus>
but I don't think we need to make logging perfect before merging your PR :)
< wumpus>
but I agree with you that BCLog::ALWAYS is ugly
< wumpus>
would prefer to add BCLog::ERROR BCLog::WARNING BCLog::DEBUG
< wumpus>
then the log system would show messages based on a threshold
< wumpus>
and it's not decided at the site of logigng whether something should always show
< BlueMatt>
I mean I dunno, I kinda like the idea of logging based on subsystem, especially with rpc to turn them on and off - it lets you debug just the subsystem that is acting up
< wumpus>
the subsystem should certainly stay
< BlueMatt>
we could add both
< * BlueMatt>
ducks
< wumpus>
common is to have a combination of both
< BlueMatt>
that sounds overcomplex
< BlueMatt>
but, eh...whatever
< wumpus>
it's pretty much how it's done in all software
< BlueMatt>
a discussion for when someone actually goes and writes the code to change it :p
< wumpus>
so you can select by category or by priority
< wumpus>
so this would be either a low priority or high priority net message based on incoming/outgoing
< wumpus>
it also means that the log output can show the category, so you can grep for it later
< wumpus>
(because all log messages will have a category, not just the debug priority ones)
< cfields>
BlueMatt / wumpus: after thinking on it a bit, i agree with the clock change.
< bitcoin-git>
bitcoin/master 3788a84 Matt Corallo: Do not send (potentially) invalid headers in response to getheaders...
< bitcoin-git>
bitcoin/master 725b79a Russell Yanofsky: [test] Verify node doesn't send headers that haven't been fully validated
< bitcoin-git>
bitcoin/master 1f4375f Wladimir J. van der Laan: Merge #11580: Do not send (potentially) invalid headers in response to getheaders...
< bitcoin-git>
[bitcoin] laanwj closed pull request #11580: Do not send (potentially) invalid headers in response to getheaders (master...2017-10-getheaders-valid-only) https://github.com/bitcoin/bitcoin/pull/11580
< sipa>
meetung?
< jonasschnelli>
jup
< achow101>
meeting
< wumpus>
#startmeeting
< lightningbot>
Meeting started Thu Nov 9 19:02:18 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< jonasschnelli>
I'd like to see BIP159 in 0.16... but it's already in the HP list
< BlueMatt>
jonasschnelli: needs rebase and I left you comments :p
< wumpus>
10286 is already on there
< meshcollider>
Any label stuff to replace accounts in there?
< sipa>
bip159 would be nice, indeed
< jonasschnelli>
BlueMatt: yes. Saw that.. will work on it asap
< * jonasschnelli>
has 14.4k connection this week
< promag>
btw, I think it would be cool to have some diagram of the current thread model and what should be the ideal model
< wumpus>
thread model?
< promag>
I think BlueMatt has some things in mind
< jonasschnelli>
I think promag means the general concurrency concept, right?
< promag>
sure
< BlueMatt>
promag: my model is CValidationInterface
< BlueMatt>
:p
< promag>
well BlueMatt keeps saying he wants to refactor in some way, but would be cool to actually "see" the big picture
< jonasschnelli>
We move away from topics... MarcoFalke had a proposed topic
< BlueMatt>
promag: CValidationInterface :p
< meshcollider>
Signing keys for binaries?
< morcos>
promag: +1
< jonasschnelli>
[09:02:17] <MarcoFalke>proposed short topic "Signing key for gitian executables"
< wumpus>
#topic Signing key for gitian executables (MarcoFalke)
< MarcoFalke>
Background is that the current key expires Q1 2018, so we should come up with something for the 0.16 release. Someone had the idea to ask MIT to apply for a key, as individuals can not apply AFAICT.
< jonasschnelli>
can you elaborate MarcoFalke?
< jonasschnelli>
MarcoFalke: you mean the Apple/WINDOWS code signing keys?
< BlueMatt>
MarcoFalke: there was some discussion of doing a split rsa key here.... gmaxwell around?
< MarcoFalke>
jonasschnelli: jup
< luke-jr>
would be good to have a key that is explicitly used for not only Core releases (eg, Knots too)
< jonasschnelli>
Apple is still the Bitcoin Foundatiomn, right?
< gmaxwell>
BlueMatt: I have code for mpc generation of rsa keys and signing.
< MarcoFalke>
BlueMatt: That would require some more time?
< jonasschnelli>
luke-jr: no, only Core
< luke-jr>
jonasschnelli: why?
< cfields>
yes, both are btcf atm
< BlueMatt>
luke-jr: no
< gmaxwell>
BlueMatt: (by I have, I mean it's on github, and I've used it... works fine)
< jonasschnelli>
luke-jr: its about trust... I don't know if I would sign something I havev't reviewd
< cfields>
gmaxwell: deals well with csr? I have no idea if that complicates things.
< achow101>
the windows cert expires in 2019
< jonasschnelli>
MarcoFalke: individuals can apply for keys (Apple and Windows)
< jonasschnelli>
But not sure if we should do individuals...
< instagibbs>
jonasschnelli, mmm not sure if gitian is about you "trusting" the binary, so much as it matches others'?
< gmaxwell>
cfields: it deals with RSA numbers, someone would need to do the hacking to stuff the rsa number it generates into a CSR and whatnot.
< cfields>
gmaxwell: ok
< luke-jr>
jonasschnelli: I see it as dealing with backward OS policies that make it hard for users to run stuff.
< morcos>
Does anyone think its best to just get BTCF to renew for now?
< gmaxwell>
I think it's _really_ unfortunate to have any name except the project name on the binaries, causes a drama and stupidity. There are still people that think the bitcoin foundation controls bitcoin just because of that existing cert. :(
< wumpus>
luke-jr: it basically is
< BlueMatt>
todo: cfields creates an rsa # -> csr program :p
< gmaxwell>
morcos: thats the obvious thing to do.
< jonasschnelli>
luke-jr: yes. But applying for you own key is maybe 300USD/year,.... so possible IMO
< BlueMatt>
gmaxwell: so can I just legally change my name to Bitcoin Core, get a cert, and then change it back?
< BlueMatt>
:p
< jonasschnelli>
morcos: renaming with the APPLE Developer Portal is almost impossible
< achow101>
BlueMatt: lol
< meshcollider>
lol
< morcos>
jonasschnelli: huh?
< jonasschnelli>
changing name requires legal documents, etc.
< gmaxwell>
BlueMatt: well the other option is that we just register a bitcoin core org someplace and have it get the key. But I wouldn't want to suggest that for a key that is expiring soon.
< jonasschnelli>
It's all by approval basis through apple
< gmaxwell>
it's not terribly hard, just requires a bit of money.
< jonasschnelli>
you need a D.U.N.S number as well
< BlueMatt>
I mean it doesnt take long to create an LLC that holds $0
< kanzure>
would chaincode do it?
< jonasschnelli>
But plase... don't set up an orga called "Bitcoin Core"
< meshcollider>
Then bitcoin core really would be a company and you'd set off all the conspiracy theorists
< wumpus>
jonasschnelli: agree
< gmaxwell>
Bitcoin Core Code Signing Key inc.
< morcos>
I'm happy to have an official Bitcoin Core org established if we want that, but it does seem like there are downsides to that
< wumpus>
gmaxwell: yeah
< jonasschnelli>
Id rather use an individual then ChainCodeLabs for it's own protection
< morcos>
unless we specifically limited its purpose very narrowly
< cfields>
ugh
< kanzure>
yes if it's a "bitoin core org" then it should be named "bitcoin core code signing key holding only and nothing else, llc."
< wumpus>
CoreSign
< luke-jr>
wumpus: jonasschnelli: then I see no reason not to use a common key for both Core and Knots..
< jonasschnelli>
I could provide my own personal APPL key...
< * BlueMatt>
votes for someone to just create Bitcoin Core Code Signing, LLC
< achow101>
BTW the apple key expires Jan 11 2018, Windows March 5 2019, so we would need to do this soon
< morcos>
luke-jr: stop.. please bring up knots later . it has nothing to do with the Core meeting
< jonasschnelli>
(OSX only)
< jonasschnelli>
heh
< gmaxwell>
achow101: or just renew the apple one then, and continue on with doing something sensible.
< cfields>
ok, in parallel to whatever else, I'll work on trying to get our current apple cert renewed
< wumpus>
makes sense
< morcos>
cfields: i think it makes most sense to do that.
< wumpus>
any name would give conspiracy theories anyway, I don't really think it's so bad to have TBF as signing organization
< Provoostenator>
Or Gitan Code Signing LLC, if other projects want their stuff signed too?
< gmaxwell>
If someone wants to work on stuffing rsa numbers into CSRs, I can show them out to use the RSA MPC code (have to remember it myself first, but it's not hard)
< cfields>
but i think we need a plan b. no clue if the resources/accounts/etc. are still live and available
< luke-jr>
Provoostenator: good idea
< jonasschnelli>
I kinda like the idea of a "Bitcoin Core Code Signing Assoc."
< cfields>
gmaxwell: yes, i'd very very much like to do that
< cfields>
so i'll volunteer for that
< achow101>
do we really need code signed binaries though?
< cfields>
tired of 10hr builds and signing on my damn laptop
< gmaxwell>
wumpus: well at least TBF isn't any _new_ conspiracy theories... though it does kinda suck. :)
< cfields>
achow101: yea. necessary evil, im afraid
< luke-jr>
achow101: some variants of Mac and Windows won't let users run unsigned stuff or something like that
< wumpus>
yes, otherwise all virus scanners will trigger on it and such
< achow101>
luke-jr: well that's annoying
< Provoostenator>
As an aside: has any one ever tried submitting to the Mac App Store?
< jonasschnelli>
Provoostenator: no.. we won't
< jonasschnelli>
This means the binaries are under APPLs control
< jonasschnelli>
Would someone disagree on founding a "Bitcoin Core Code Signing Association" based in Switzerland?...
< jonasschnelli>
(we could just try and also follow the path of renewing the current cert)
< wumpus>
jonasschnelli: no, would be great
< luke-jr>
jonasschnelli: "Gitian Code Signing" would be better as Provoostenator suggested
< gmaxwell>
jonasschnelli: sounds fine to me, whatever is the path of least resistance.
< wumpus>
luke-jr: I think that makes the scope too wide
< gmaxwell>
I'd rather not introduce a new word 'gitian' to users.
< morcos>
Let's please leave whatever we do focused on Bitcoin Core
< BlueMatt>
it should probably have "Bitcoin Core" in the name
< luke-jr>
BlueMatt: then you'll whine that it can't be shared
< wumpus>
luke-jr: I don't personally have a problem with signing knots executables, but making it soo general means we'll have a bureaucracy about what to sign blabla, and btw devrandom owns the name gitian :)
< sipa>
and then we'd apply for code signing keys under that association's name, using the MPC RSA scheme?
< meshcollider>
jonasschnelli: sounds good to me
< jonasschnelli>
Okay... I'll let that happen and register with apple
< sipa>
(or at least eventually)
< Provoostenator>
Decentralized Code Signers LLC?
< wumpus>
sipa: yes, at least eventually
< BlueMatt>
luke-jr: I object to it being shared, it is not *that* hard for you to get your own cert for your own project.....
< gmaxwell>
sipa: yes, thats the idea.
< jonasschnelli>
sipa: not sure it that is possible with apples key enrolling process
< sipa>
jonasschnelli: i don't see why not
< BlueMatt>
sipa: yes
< cfields>
wumpus: exactly. The question to ask is: would we want btc1 signed with the same key?
< jonasschnelli>
I'll focus on the legal association stuff maybe someone can try to look into the MPC RSA sheme with apple OSX signing keys
< sipa>
jonasschnelli: assuming all the plumbing work is done
< wumpus>
cfields: right, no we don't :)
< luke-jr>
BlueMatt: it's a waste of money to a bad corp and a waste of time, at the very least
< achow101>
does anyone have a link to the rsa mpc thing?
< gmaxwell>
I wouldn't want any of us us wasting time helping with an adversarial project.
< morcos>
Guys, if you are signing code, you are responsible for that code. If we are signing it in the name of Bitcoin Core we are all taking responsibility. Please let's limit this discussion to the code we all work on together
< Provoostenator>
Makes sense
< sipa>
well, in the MPC setting, the group of signers would be fixed
< morcos>
someone can always separately create a more general entity to sign other projects, but thats not related to Core
< sipa>
the project should be signing the things that group of signers is jointly interested in signing
< wumpus>
yeah it's typical scope creep
< gmaxwell>
achow101: I'll give you the link after the meeting.
< kanzure>
or bike shedding on name
< wumpus>
let's sign the entire world :p
< cfields>
gmaxwell: right. I was making the point that it would be impossible to draw the line unless core-specific.
< achow101>
gmaxwell: k, thanks
< MarcoFalke>
Any other topics?
< BlueMatt>
promag: CValidationInterface is where you learn things from consensus code (ie from CChainState after 10279 or validation.cpp otherwise) - its also where you learn about mempool things but I have a branch which comes after 10286 that splits the interface up between the two to differentiate a little bit....wrt threading, CValidationInterface listeners all move into the scheduler, which means you dont have any deadlocking issues since
< BlueMatt>
they're all just called async, this is mostly complete in 10286, but cleaning up the remaining few isnt too hard...thats pretty much it, there's not much to it...net/net_processing is a different issue, and is mostly around moving things from CNode to CNodeState and disconnecting those two things being so closely joined, but the threading issues there are less of the primary concern (except for cs_main being too heavily shared between
< BlueMatt>
net_processing for mapNodeState and everything else)
< gmaxwell>
it is unfortunate that e.g. knots has an uphill time there, it's a barrier to entry that shouldn't exist. But it's also not one we created.
< luke-jr>
cfields: except Knots and Core have the same developers
< wumpus>
gmaxwell: I agree
< cfields>
luke-jr: as does btc1...
< sipa>
luke-jr: they don't have the same maintainers
< luke-jr>
cfields: hardly
< sipa>
i don't think everyone who is interested in signing off on core releases is interested in doing the same work for knots - and perhaps the other way around
< cfields>
luke-jr: i hope it's clear that I'm not trying to lump you in with an adversarial fork. Just making the point that the distinction in terms of signing is hard to draw.
< luke-jr>
"We Just Codesign Stuff We Want, LLC" XD
< cfields>
luke-jr: that's my end goal, actually
< jonasschnelli>
Indeed
< jonasschnelli>
It's one entity luke-jr
< wumpus>
well adversarial versus consensus-compatible is easy to draw
< gmaxwell>
there is another issue, I'm pretty sure that apple will not grant a key to "I sign random shit LLC"
< jonasschnelli>
You can found a "Knots Code Signing Assoc"
< promag>
thanks BlueMatt, I'll read that in a bit
< cfields>
to create a body like Let's Encrypt, which attests to the fact that code -> binary.
< wumpus>
cfields: that would be awesome
< luke-jr>
cfields: well, how to stop malware from using it?
< achow101>
cfields: well that's a whole separate thing which we can join once it exists :)
< wumpus>
but it's outside the scope of the bitcoin core project
< wumpus>
any other topics?
< cfields>
luke-jr: deterministic malware would have to be welcome, unfortunately
< luke-jr>
that'd just get the key revoked
< gmaxwell>
not like this stuff actually stops malware, snake oil security. alas.
< gmaxwell>
in any case, a discussion for another time.
< wumpus>
ok, no other topics
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Nov 9 19:36:19 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< wumpus>
meshcollider: that's the case here in the netherlands
< gmaxwell>
achow101: the key gen is really slow, but who cares... signing is fast.
< sipa>
meshcollider: 3 BTC doesn't *sound* like much at all :p
< BlueMatt>
if thats the case might as well just create a US LLC
< BlueMatt>
cost is trivial
< gmaxwell>
achow101: IIRC that implementation is setup for three parties, but it would be relatively straight forward to adjust it for more.
< jonasschnelli>
meshcollider: 10k for a GmbH
< jonasschnelli>
jonasschnelli: but we do an association.. which is almost free (maybe 1k)
< sipa>
promag: cchain is pretty big
< meshcollider>
Heh yeah sounds like quite a lot for a code signing only company
< BlueMatt>
jonasschnelli: i believe us is like 50$
< promag>
sipa: you don't have to copy everything
< BlueMatt>
(but I think in most states yearly to file tax returns)
< sipa>
promag: not without introducing massive granularity
< achow101>
gmaxwell: thanks. I'm going to try taking a look at it
< jonasschnelli>
BlueMatt: that's why people trust swiss companies more then US. :)
< BlueMatt>
jonasschnelli: would you prefer I do something in .us?
< sipa>
promag: if there is ever a point where concurrency is hurt by needing a consistent CChain, i think the solution is to stop using CChain for that purpose (CChain is just an optimized-for-seeking copy of CBlockIndex)
< jonasschnelli>
For the simplest form of a registered non-single-person company, the GmbH, you need to deposit 10k and have liability (personal) for 20k
< jonasschnelli>
BlueMatt: no.. please not US
< BlueMatt>
I mean its not like the company will even hold the cert
< meshcollider>
jonasschnelli is there any difference between an association and an LLC in terms of getting the certs
< BlueMatt>
only exist as a legal entity to exist
< jonasschnelli>
Or the association member may have troubles getting a US visa. :()
< BlueMatt>
jonasschnelli: I presume there will be no "members"
< meshcollider>
Or wumpus will be so he gets the cert?
< gmaxwell>
the only concern about the entity is that it could get more certs but I don't think we care, since the fact that apple et. al. can issue as many as they want regardless.
< gmaxwell>
meshcollider: we're hopefully going to use multiparty computation so no one person has the cert.'
< morcos>
i think it makes sense for it to be jonas or someone not related to the Blockstream/Chaincode conspiracy who does this
< BlueMatt>
gmaxwell: I'm gonna go out on a limb and bet that almost anyone would claim to be a representative of the company and apple would buy it
< jonasschnelli>
BlueMatt: an official assiciation needs to have member
< jonasschnelli>
(but only in the background)
< jonasschnelli>
LLC is US imo
< * luke-jr>
wonders if a non-developer should do this
< cfields>
my original suggestion was the DCI, but that got drowned out in the discussion
< gmaxwell>
lol please, no more non-developers.
< BlueMatt>
jonasschnelli: I mean ok, if you hate the idea of a us LLC, fine, I just figure its not worth wasting 1k on it, but....ok
< cfields>
(also, i realize that everyone is just suggesting their own org :p )
< BlueMatt>
gmaxwell: yea...that
< wumpus>
cfields: DCI would be fine with me too
< sdaftuar>
cfields: i am not suggesting my own org! :)
< luke-jr>
cfields: everyone else is suggesting not-our-org it sounds like
< wumpus>
cfields: this is just to have alternatives
< * BlueMatt>
doesnt care, I was trying to save jonasschnelli 1000$, but the purpose is to exist, not do *do* anything
< jonasschnelli>
I'm not really familiar with US legal company/association constructs....
< BlueMatt>
jonasschnelli: all that matters is its cheaper :p
< gmaxwell>
I would rather not use DCI simply because we really have suffered from people using that stupid message as proof BCF controls bitcoin. I'd rather the name be more benign. (the "foo code signing" sort).
< promag>
sipa: consider a long rpc call, it locks cs_main and replies a big json - how can it avoid the cs_main lock?
< jonasschnelli>
DCI would be fine for me as well, though I prefer "Bitcoin Core Code Signing Assocation" over "DCI" (which is a private owned company) in the signing details
< wumpus>
yes on the longer term having our own signing org would certainly be preferable, I agree
< gmaxwell>
"Orginization which does not control Bitcoin. LLC"
< gmaxwell>
yea, for a stopgap, whatever works. hopefully we can just.
< jonasschnelli>
BlueMatt: I guess the 1000$ is for the lawyers setup,... I guess I would need the same for the LLC process (or someone needs to fill out the application form which then leads to lost 1000$ in development ressources)
< cfields>
well, this may shortcut the discussion a bit...
< BlueMatt>
ok, are there any remaining questions aside from "does jonasschnelli want to register it as a swiss org, or do we want someone in .us to spend the 35$ to make it happen here"
< wumpus>
DCI sounds sufficiently neutral to me though
< cfields>
from a quick glance, looks pretty possible that I can renew with the current cert
< gmaxwell>
lol
< achow101>
who would be the named members/officers/whatever of said organization/association/llc
< wumpus>
cfields: nice!
< sipa>
promag: accessing CBlockIndex entries does not require a lock to access most fields (as they are immutable)
< BlueMatt>
jonasschnelli: the registration process for an org in the us can be pretty easily diy-d, especially if you're never going to *use* the org
< luke-jr>
why does it need to be Core-specific? just a redundant waste of money and time to then get another one for Knots, when it could just as easily be a shared effort. sigh.
< BlueMatt>
achow101: who cares?
< gmaxwell>
achow101: we should create a UK org, you can name anyone you want as the officers.
< jonasschnelli>
BlueMatt: let me first check the real costs here in CH
< jonasschnelli>
I know it's basically free... but someone needs to do the paperwork...
< jonasschnelli>
Which is the significant costs IMO
< gmaxwell>
achow101: and the registrations are visible online. :P
< luke-jr>
gmaxwell: even without their consent? XD
< jonasschnelli>
Which *are
< meshcollider>
BlueMatt does a US LLC need a bank account and everything?
< gmaxwell>
luke-jr: yes.
< BlueMatt>
meshcollider: no
< gmaxwell>
meshcollider: no.
< BlueMatt>
why would it?
< achow101>
BlueMatt: people who want to look at the paperwork and then go "X controls bitcoin blarg" conspiracy
< meshcollider>
Idk, some countries do dont they
< BlueMatt>
all you have to do is file paperwork to create it, then file a tax return every year....some nominal cost to doing so, but IIRC 35$ for delaware
< luke-jr>
gmaxwell: Satoshi Nakamoto, John Doe, Jane Doe, …
< gmaxwell>
achow101: so e.g. we can list satoshi nakamoto, bill gates, donald trump...
< achow101>
gmaxwell: lol
< BlueMatt>
achow101: hence why its called "Code Signing, LLC" :p
< achow101>
meshcollider: it varies in the us by state. IIRC it costs almost nothing to register an LLC. pay the fee and submit paperwork and thats just about it
< BlueMatt>
yea, that ^
< meshcollider>
Ok sweet as
< gmaxwell>
it does take a bit of time.
< jonasschnelli>
I guess an US LLC is always tied to an individual, a person who found/owns the LLC?
< achow101>
jonasschnelli: yes
< meshcollider>
According to cagi.ch, "The creation of an association does not entail any administrative cost."
< achow101>
that person also has to file taxes for the llc every year. but for something that does nothing and makes no money, that shouldn't be a problem
< sipa>
promag: so if you want consistent but just read-only access to CChain, you could ibstead just briefly lock main, get a copy of chainActive.Tip() pointer, unlock, and then use the resulting CBlockIndex without any locks
< jonasschnelli>
Where an association (in Switzerland at least) has no owner,... it just has members (which have different / exchangable roles)
< luke-jr>
jonasschnelli: does Apple definitely recognise it?
< meshcollider>
Association in Switzerland sounds cleaner than LLC in us imo
< jonasschnelli>
meshcollider: "costs" are a wide term... fill out paperwork/forms for 2-3 can have costs...
< sipa>
promag: CBlockIndex has efficient Ancestor function yo query at any height... not quite as efficient as looking up in CChain, but probably sufficient for almost anything
< jonasschnelli>
luke-jr: just checking... but I know other swiss Assocaitions having an App in the App store... so it should work
< promag>
right, only lacks Next
< BlueMatt>
jonasschnelli: I dont think we care about ownership here - it literally will not even hold the keys
< meshcollider>
Jonasschnelli it also says "A Committee (comprising at least a president, a secretary, and a treasurer)." Not just members, irrelevant point though
< achow101>
I guess the cost here is "how much money does someone need to pay for this thing to exist"
< jonasschnelli>
A committee is required,.. yes. But it's flexible...
< jonasschnelli>
achow101: + how much work does he need to spend
< meshcollider>
Yep
< jonasschnelli>
BlueMatt: The ownership can have some sideeffects... I personally don't want to be in a register with my Name tied to a company that have "Bitcoin" in it's name. For travel purposes...
< wumpus>
wasn't it that you can put other companies as officers? :)
< wumpus>
and create a recursive organization
< jonasschnelli>
wumpus: I guess not for an association
< jonasschnelli>
(for other companies that would work)
< jonasschnelli>
although I may be wrong
< BlueMatt>
jonasschnelli: heh, I'm not too worried, if they google any of us they'll find bitcoin faster than if they look at what companies we are connected to :p
< achow101>
jonasschnelli: in the US, you could register in like Delaware where the business registrations are not public and can only be revealed by subpoena (or the like)
< wumpus>
jonasschnelli: yes maybe that's only true in Panama :p
< wumpus>
BlueMatt: I'm not really worried either, they know we're connected to the software project anyhow
< jonasschnelli>
Yes... probably... though I'm always suprised how entering the country depends on the officers (and the little surface info he has) you have in front of you
< meshcollider>
"LLCs in Delaware don’t file annual reports"
< wumpus>
meshcollider: that's another popular location for shell companies right?
< jonasschnelli>
However, next week i should have more bandwidth then 14.4kbds so I'll can check the details... and report in next weeks meeting
< meshcollider>
I'd expect so, achow101 suggested it
< sipa>
promag: but next is easy to implement as tip->Ancestor(prev->nHeight + 1) :)
< achow101>
wumpus: a lot of big US companies are registered in delaware, e.g. Google
< luke-jr>
TIL achow101 is well-known for suggesting shell company locations
< wumpus>
luke-jr: hah
< achow101>
there's also a few other states too
< sipa>
unfortunately, someone would just need to know the information was suggested by achow101, to guess
< meshcollider>
Sounds like delaware is good for avoiding lots of tax too, not that that matters here ;)
< achow101>
luke-jr: well right now I'm taking a course about fraud and scams, and we came to the topic of shell companies and the panama papers recently :p
< luke-jr>
i c
< meshcollider>
Oh, "Delaware LLCs do not file annual reports; instead, LLCs in Delaware file annual taxes. The annual tax is a flat $300."
< RealM9>
Hello, which paper wallet generator can be trusted?
< RealM9>
(Asking it here, because i trust core devs)
< RealM9>
Is bit address safe?
< aj>
jonasschnelli: is there really a question about #8550 being qt only or having a non-qt stats collector? having non-qt access to info always seems better, at a minimum for tests and the like...
< wumpus>
aj jonasschnelli I tend to agree, though getting things merged w/ the GUI tends to be easier than JSON API changes
< wumpus>
in any case the end goal is to have both
< aj>
wumpus: (loving watching all the commits going through today)
< wumpus>
I really want the GUI interactive mempool graph in, because it is appealing to people
< wumpus>
aj: yes, much progress today
< cfields>
meshcollider: that reminds me, anyone else getting a cert issue for bitcoincore.org ?
< cfields>
wumpus: and, looks like i was wrong about an easy cert renewal. going deeper now.
< aj>
cfields: bitcoincore.org seems fine here (firefox sees a let's encrypt cert)
< wumpus>
cfields: uh oh
< wumpus>
aj: he means the code signing cert, web certs are much easier luckily
< cfields>
aj: ah right, thanks for confirming
< cfields>
wumpus: nah, i meant the site. forgot i had a dns hack in place
< cfields>
damn you BlueMatt!
< wumpus>
oh
< BlueMatt>
cfields: lol, uhhhh, I have no idea what server you were accessing that had an old cert
< BlueMatt>
thats...strange
< cfields>
BlueMatt: it was pointed at bitcoin.org for some experiment
< BlueMatt>
lolk
< cfields>
no worries, all good now
< luke-jr>
[21:06:22] <wumpus> I really want the GUI interactive mempool graph in, because it is appealing to people <-- it conflicts with its dependency nowadays :x
< luke-jr>
although I have it in Knots with an older version of the dep