< Chris_Stewart_5>
is it possible to compile secp256k1 on windows with jni enabled?
< achow101>
jhfrontz: it does 'sudo apt-get' to install a few packages that you need. you can either run the script as sudo or just find the 'sudo apt-get' lines in the script and run them yourself (I recommend that you do this) to install the packges
< achow101>
if you run the entire script as sudo, all of the folders and files that are created will be owned by root
< mryandao>
is there any reason why core continues to use boost::chrono as oppose to chrono in the standard library? or this is one of the items where a refactor is welcomed?
< sipa>
mryandao: i believe cfields has some.ongoing work to get rid of it
< sipa>
but i'm not sure of the status
< mryandao>
oh, i just did an update today and it pains me to need to install that 100MB+ of libboost to compile bitcoin-core
< mryandao>
hence I asked.
< wumpus>
I think we're also quite near to being able to get rid of boost::thread
< wumpus>
just hiaving to install the boost libraries isn't so bad, you don't *need* all 100MB+ just a few libraries as described in doc/build-unix.md, I think my biggest practical gripe about boost is the unrelible pile of hacks needed to use it in the build system. So many reported issues about not being able to find it, or the right version. esp the boost::sleep
< mryandao>
boost::thread alone had 100MB+ of dependencies
< mryandao>
the rest were ok, or by the time all the dependencies were installed, it was pretty much all of libboost
< wumpus>
that's simply not true
< wumpus>
libboost includes tons of stuff (like parsing, physics computation/units), that we don't use. Our use is very targeted and has become a smaller and smaller part over the years.
< wumpus>
you can check the gitian descriptor to see how by far most of the build is disabled
< wumpus>
boost itself has no dependencies outside of boost and the C and C++ basic library (boost::thread will use pthread)
< mryandao>
weird, unless apt-get by default packages all of them together?
< mryandao>
i did put down the `apt-get install libboost-thread-dev`
< wumpus>
I'm all for moving away from boost, over time, but these kinds of cheap digs at the library annoy me too
< wumpus>
strange - I'd write that up to debian instead of fundamental thing with boost itself
< wumpus>
in any case, feel free to help in the move forward to get rid of the boost::thread dependency, it shouldn't be too much work now
< wumpus>
was just looking at that - I don't think it has to block anything
< fanquake>
Yep, I think an rc1 can move ahead. Can always be fixed if it comes up again during testing
< fanquake>
Have updated all the projects and un-tagged backports etc.
< wumpus>
thanks!
< provoostenator>
I'd like to get #11658 in if that's still possible.
< gribble>
https://github.com/bitcoin/bitcoin/issues/11658 | During IBD, when doing pruning, prune 10% extra to avoid pruning again soon after by luke-jr · Pull Request #11658 · bitcoin/bitcoin · GitHub
< luke-jr>
not sure it's a bugfix
< provoostenator>
Oh is 0.16.1 purely backports and not masteR?
< provoostenator>
In that case it can wait for 0.17
< luke-jr>
the 3rd number of a version is always for bugfixes (and in our case, consensus protocol updates)
< wumpus>
I'd say that one is not urgent enough to hold up 0.16.1, certainly not right now, there has been enough time to propose that one in the meetings of last weeks, or at other times
< fanquake>
wumpus will you tag an rc tonight?
< wumpus>
fanquake: I'm working on doing last-minute checks now
< fanquake>
wumpus: np, let me know if you need a hand with anything. I'll be up for another couple hours.
< bitcoin-git>
bitcoin/master 2885c13 Jonas Schnelli: Qt: use [default wallet] as name for wallet with no name
< bitcoin-git>
bitcoin/master a315b79 Wladimir J. van der Laan: Merge #13275: Qt: use [default wallet] as name for wallet with no name...
< bitcoin-git>
[bitcoin] laanwj closed pull request #13275: Qt: use [default wallet] as name for wallet with no name (master...2018/05/loadwallet_gui_name) https://github.com/bitcoin/bitcoin/pull/13275
< wumpus>
i'm ok with that, for 0.16.2 though
< wumpus>
we're currently in the process of tagging 0.16.1rc1, so the 0.16 branch is locked unless there's a serious/critical bug fix
< ken2812221>
ok
< jonasschnelli>
"A Bech32[2] string is at most 90 characters long and consists of:"... that is not a bech32 limit, right?
< sipa>
otherwise harmless assert failure at shutdown?
< wumpus>
yes
< sipa>
can we remove the assert...?
< * sipa>
hides
< wumpus>
that's not a bad idea
< wumpus>
it doesn't seem to be a problem on master, just 0.16
< sipa>
hmm
< wumpus>
removing the assert (and replacing it with, say, a log message) would be a good idea if it doesn't segfault later due to the same problem
< wumpus>
anyhow, maybe it doesn't matter too much for rc11
< wumpus>
rc1*
< wumpus>
depends on how quickly we want to start testing this
< wumpus>
I think in the past it has been useful to get a rc out quick, without waiting too much, because new issues arise during testing anyhow
< sipa>
ah, you mean fix the assert in rc2/final?
< wumpus>
yes
< sipa>
sgtm
< wumpus>
it makes the process somewhat more parallel instead of serial
< pergaminho>
Olá alguém de São Paulo?
< sipa>
english please
< pergaminho>
Excuse me, I want to know if there's anyone in Sao Paulo.
< wumpus>
that seems very off topic
< wumpus>
* [new tag] v0.16.1rc1 -> v0.16.1rc1
< sipa>
w00t
< achow101>
yay
< jonasschnelli>
sipa: have you explored the field of BCH codes suitable for private keys?
< sipa>
jonasschnelli: yes, a bit
< sipa>
but the tradeoffs are hard
< sipa>
strictly for private keys, you could correct 4 errors with 12 characters of checksum
< sipa>
but not with an efficient algorithm
< jonasschnelli>
with private keys you mean 256bits, right?
< sipa>
yes
< jonasschnelli>
Hmm... for an xpriv, if the chaincode should also have the same robustness, it is maybe an overkill in length
< jonasschnelli>
sipa: how are Bech32 properties for 512 bits? How much chars would be guaranteed in the correction?
< sipa>
if you want to correct 4 errors with an efficient algorithm on 512 bits (103 characters), you need to add 15 characters of checksum
< jonasschnelli>
I'd say that is accaptable...
< jonasschnelli>
I would also say 4 error may be acceptable for 103 chars
< jonasschnelli>
Ideally it would be flexible ("choose your size / robustness")
< sipa>
such a code would guarantee correction of 4 up to length 1023
< sipa>
(of which 15 are checksum characters, and 1008 are data)
< jonasschnelli>
sipa: hmm... and there is no optimised code for something up to 103 chars (512bit in base32).
< jonasschnelli>
?
< sipa>
jonasschnelli: so there is an important distinction here
< sipa>
a BCH code is a just a subset of cyclic codes, with parameters generated in a specific way
< jonasschnelli>
the 4 in 1023?
< sipa>
that specific way guarantees (1) a certain level of error correction and (2) an efficient algorithm to do so
< sipa>
all these codes are however "better" than what they're designed for
< jonasschnelli>
so the BCH subset may not be ideal for private keys
< sipa>
it absolutely is not
< sipa>
BCH codes are not optimal
< sipa>
but they're easy
< sipa>
(and they may be close to optimal)
< sipa>
bech32 is a BCH code that only guarantees detecting 3 errors up to length 1023... that's the BCH part
< sipa>
however, out of all possible BCH codes with that property, we searching for one that is "better" in that it also detects 4 errors up to length 89
< sipa>
that took a few years of CPU time to find out, though :)
< jonasschnelli>
Yes. I heard that. :)
< sipa>
the BCH part is just math; i can tell you in an instant how good a code is
< sipa>
but no, i can't create a BCH code whose _designed_ strength is optimal for 103 characters; no such codes exist
< jonasschnelli>
I see...
< sipa>
there do exist BCH codes for length 93, FWIW :)
< sipa>
with just 13 checksum characters, even
< sipa>
but the next one up is for length 1023
< jonasschnelli>
Unsure if 4 chars are enough for a private key...
< jonasschnelli>
Implementation wise, using bech32 would be a great thing since it will very likely be already present in the code/framework...
< sipa>
19 checksum characters if you want an efficient way to correct 5
< jonasschnelli>
new proposals may lead to not getting implemented because of a complex implementation,... bech32 would make it pretty simple
< sipa>
the checksum algorithm for all of these is trivial
< sipa>
just as simple as bech32, but with larger integers
< sipa>
the error correction algorithm is more complex (but very fast)
< jonasschnelli>
the 19/5 code is in the BCH subset (up to 1023)?
< sipa>
yup
< jonasschnelli>
Something you drilled out of your supermachine?
< jonasschnelli>
(calculated on your own?)
< sipa>
no, this is just BCH
< sipa>
it's a simple sage script to compute these
< sipa>
they're not optimized for anything beyong their design strength
< sipa>
among all the 19/5 codes (there are likely thousands) i could search for the "best" one according to some extra criteria
< jonasschnelli>
So it could be possible to find a 19/6 within a length property of l<103?
< jonasschnelli>
<=
< sipa>
that seems unlikely, but it's possible yes
< sipa>
it may also take more computing power than we have
< jonasschnelli>
I see
< sipa>
however, if it's just for single private keys, we could use length 93 codes
< sipa>
where just 13 characters for 4 corrections, or 16 characters for 5, is sufficient
< jonasschnelli>
That would not cover encoding an extended private key though....
< sipa>
yup
< sipa>
also, codes _designed_ for length 93 will perform terrible beyond it
< jonasschnelli>
Metadata could be ouside of the cyclic code,.. but within the checksum (is that even possible?)?
< sipa>
no
< sipa>
bech32 was designed for length 1023, but optimized for length 89... that's why it performs still fine when you exceed the 89 characters
< jonasschnelli>
So an additional checksum
< sipa>
that's a bit ridiculous
< jonasschnelli>
we only would need to detect errors in the metadata pert... even a parity bit would be okayish?
< jonasschnelli>
*part
< sipa>
but metadata includes chaincode etcx
< jonasschnelli>
chaincode is essential IMO
< jonasschnelli>
must be within the error correcting part
< sipa>
yeah, exactly- i agree
< sipa>
so a length 93 code is out of the question
< jonasschnelli>
512bits seems to be the minimum if it should cover xprivs
< jonasschnelli>
(other xpriv then m)
< jonasschnelli>
If we would only cover m, one could think of encoding the seed
< jonasschnelli>
of the seed & keypath?
< jonasschnelli>
but meh for hardened protection
< jonasschnelli>
wait, nm my last line
< sipa>
11 char checksum for correcting 3, 15 for correcting 4, 19 for correcting 5
< jonasschnelli>
sipa: don't you think using bech32 with the property of 4 corrections for a pure private key and 3 for a key/chaincode keycombo(xpriv) would be acceptable?
< jonasschnelli>
Also, reusing bech32 would be very desirable...
< sipa>
yes, but you can't have both
< jonasschnelli>
Right now, we have 0 correction with Base58c
< sipa>
bech32 can only correct 2, and inefficiently
< sipa>
you design for a single combination of length and correction strength
< sipa>
it will likely be better for shorter lengths, but not have an efficient algorithm to do so
< jonasschnelli>
Hmm... i though bech32 corrects 4 errors up to length 89?
< jonasschnelli>
*thought
< sipa>
no, it *detects* 4
< jonasschnelli>
ah. I see
< sipa>
correction strength is always only half of the detection strength
< jonasschnelli>
meh
< jonasschnelli>
that is what we need for private keys. :/
< jonasschnelli>
Yes. I guess then we need another encoding implementation... ideally as simple as bech32
< sipa>
what do you think about a 103-character checksum code that can correct 28 errors? :)
< sipa>
(doubling the length of the string)
< gmaxwell>
I'm fond of that, but whats the efficiency of the correction code for that?
< jonasschnelli>
sipa: I think very acceptable.. really
< sipa>
206 characters is a lot :)
< sipa>
gmaxwell: efficiency in terms of what?
< jonasschnelli>
I think the correct code efficiency is not very important for private keys
< jonasschnelli>
*correction
< gmaxwell>
is it a design distance 56 code? with an efficienct locator algorithim?
< gmaxwell>
jonasschnelli: it matters if its intractably slow.
< sipa>
so it could have up to 238 data characters
< gmaxwell>
sipa: I guess I'd want to try writing down 206 characters and see how much I hate my life. :)
< sipa>
gmaxwell: why would correct be slow?
< gmaxwell>
sipa: the thinking behind my question was that if it was a design distance 40 code with an actual distance of 58, and we had to decode beyond the design without an algebraic decoder, it would take days to decode out to the full length.
< sipa>
factoring the locator polynomial should be fast; the field size is just 32^2
< sipa>
ah, i see
< sipa>
all i'm talking about here are algebraic properties
< gmaxwell>
Thanks, right thats what I was asking, I also realize now that the question is kinda stupid in that you can't _find_ codes that far beyond their design distance.
< sipa>
indeed :)
< gmaxwell>
since the search process and the decode process are essential the same.
< gmaxwell>
sipa: your suggested code also has enough length to have some metadata, a nonce for encryption, etc.
< sipa>
yup
< sipa>
but 2x length is... a lot
< jonasschnelli>
To keep the write-down-by-hand property, I guess something beyond bech32 will not be tolerated/used.
< gmaxwell>
jonasschnelli: huh?
< jonasschnelli>
gmaxwell: do you think 206 chars are acceptable to write down?
< gmaxwell>
That doesn't follow from what you're saying there. :)
< jonasschnelli>
I mean it always depends what sort of key your dealing with...
< gmaxwell>
If someone is already writing 60 digits for a private key, writing an extra 6 is a non-issue I think... and that would be what you'd be doing for a code with twice the error recovering potential of bech32.
< gmaxwell>
But yes, writing down 206 might be too much, which is why I said I'd want to try it. :)
< gmaxwell>
But 206 being too much doesn't mean that beyond bech32 isn't fine.
< jonasschnelli>
heh.. yes. I need to try that as well...
< jonasschnelli>
Yes. That is true
< gmaxwell>
I think bech32 is not very useful for private keys... it barely has error recovery which is what you need for private keys (I see sipa argued this above).
< gmaxwell>
For a while before sipa was searching for 12 digit checksums (so 6 more digits than bech32).
< jonasschnelli>
Yes. I wonder now why seed encoding proposals do have no error correction at all (or do they, AFAIL no)?
< gmaxwell>
I think mostly because people didn't know it was possible. The word-list based ones have some informal error correction since you can figure out the word from part of it.
< jonasschnelli>
Yes. The stove/stone error that took me days to figure out... :/
< gmaxwell>
ugh. yes, a problem with informal is that the worst case errors are going to be pretty bad.
< jonasschnelli>
(also wonder why they have chosen "stove" and "stone" while we know that the n and the v look often very similar)
< gmaxwell>
There really isn't a lot of good data on visual similarities of letters. This was a challenge in designing bech32 too.
< jonasschnelli>
"12 digit checksum" (gmaxwell above) would result in 6 chars correction, right?
< gmaxwell>
jonasschnelli: only if the code was perfect, which isn't possible for codes of length 32 or more (and we need length around 644). It might be possible for 5 character correction with 12 check digits, but I believe the best 12-digit codes sipa could find only allowed 4 corrections.
< gmaxwell>
(maybe even only 3? I'm not sure now... but thats why sipa was doing a search)
< gmaxwell>
It may be that 5 is possible information theoretically but there just aren't any cyclic codes that achieve that performance. Or maybe one does exist but it just hasn't been found yet. There are on the order of 2^55 possible codes...
< jonasschnelli>
I see
< jonasschnelli>
The second things – because a new error-correcting encoding proposal could go hand in hand with a seed encoding proposal (which has very similar properties to pure private key and extended private keys encoding), what do you think about the lighning aezeed proposal?
< jonasschnelli>
I don't see the relevance of the nonce-missuse resistance
< gmaxwell>
I haven't seen it before.
< jonasschnelli>
A such proposal could also use ChaCha20Poly1305 as AEAD,... though the MAC size would be 128bits instead of the flexible 8 byte AEZ mac length
< jonasschnelli>
(which results in no longer be 24 words probably)
< gmaxwell>
a mac could be made whatever length.. so the other wallet people have been regarding authenticated encryption as a negative feature.
< gmaxwell>
because they want the user to be able to be able to give out different passwords that work.
< jonasschnelli>
plausible deniable,... yes. that may be a point.
< gmaxwell>
My thought was thats really pretty dangerous, since the user could have the wrong key and didn't know it. And the use case is kind of silly and not that realistic. But a compromise could be that if the authentication was small (on the order of 16 to 32 bits) your computer could search for an alternative durress password for you to remember.
< gmaxwell>
and you'd still get protection against a wrong password.
< jonasschnelli>
cool!
< jonasschnelli>
But I guess it could be really cpu-intense to find an alternative version that goes beyond gibberish things...
< gmaxwell>
the downside being that the user couldn't freely choose the durress password. But I think thats probably acceptable.
< gmaxwell>
well if the code is 16 bits you can just try a 2^16 words from a dictionary and you're likely to have one match.
< roasbeef>
gmaxwell: it uses an arbitrary input length tweakable block cipher (aez) to encipher a plaintext wallet payload (internal version, birthday, entropy), aez takes an approach where you add reudndancy to the plaintext, and check for it on decryption. w/ this approach the seed <-> phrase conversion is actually reversible unlike bip 39
< gmaxwell>
another way to do it that doesn't require search is to store two check values, and one must match.
< gmaxwell>
roasbeef: the thing jonas linked to made it look like the plaintext key length is limited to 16 bytes tough?
< jonasschnelli>
That was also my question, why only 128bit entropy?
< gmaxwell>
jonasschnelli: with the store two check values approach to 'denyability' then there is no search, just the overhead of encoding two values.
< roasbeef>
never really been convinced w.r.t the whole "plausible deniability thing", but in theory you can adjust the redundancy size to make brute forcing a valid decryption "easier"
< roasbeef>
yes atm it's 128-bits, the current params allow everything to be encoded in 24 words, as to still be familiar w/ users of bip39
< roasbeef>
y'all think 128-bits of entropy is insufficient?
< gmaxwell>
I think the deniability thing is stupid, outright. But it's appealing to a bunch of people (who probably then go and store their keys on their smartphone or whatever), it's silly to have gratitious incompatiblity because of it.
< jonasschnelli>
Not sure... but if I can choose, I chose 256. :)
< jonasschnelli>
*choose
< gmaxwell>
roasbeef: it's probably sufficient, but it means you cannot encode existing values that come from schemes using 256 bits, sadly.
< gmaxwell>
the BIP39 problem but somewhat less dumb.
< roasbeef>
yeh, that's one detriment, but it's versioned so another version can be parameterized to store 256 bits
< jonasschnelli>
roasbeef: is aez beeing considered crypto-analysed enough?
< roasbeef>
it was amongst the caesar contest finalists, but dropped out iirc as it was difficult to implement efficeitnly in hardware
< jonasschnelli>
roasbeef: What would be the downsides of using ChaCha20Poly1305? Only the nonce missue protection?
< jonasschnelli>
or say "resistance"
< roasbeef>
don't think you'd really care about nonce misuse in this case, one could swap in chacha and simply truncate the mac (if wanted), aez was nice for us as it let use tune the size of the mac nicely to expand the plaintext given the 24 word constraint we imposed
< jonasschnelli>
Got it. Thanks
< roasbeef>
fwiw in the scheme the enciperhing is distinct from the encoding to the mnemonic, we take the enciphered payload then prepend a version, append the salt used in the kdf, and finally add a checksum over the entire thing so we can detect incorrect words, for external version 0 these params are set, but can be tweaked to use a more specialized checksum, etc
< jonasschnelli>
I would strongly prefer ChaCha over AEZ... but I'm not a cryptographer and have little arguments to say why.
< jonasschnelli>
Also, I like the truncated-MAC-approach described by gmaxwell above that would allow the plausible deniability & the two way direction (though with a pre-defined second password)
< gmaxwell>
roasbeef: since the data being encoded is high entropy, I think a nonce is nearly irrelevant from the perspective of the encryption itself. A nonce is highly useful for the KDF however.
< gmaxwell>
I'm not sure if truncated mac vs two mac is better. So the biggest argument I have against truncated mac is that if your KDF is slow (As it should be) the search will take a long time.
< jonasschnelli>
gmaxwell: in KDF, you referring to the salt?
< gmaxwell>
Yes.
< gmaxwell>
Without a decently sized nonce/salt the KDF will be gratitiously vulnerable to precomputation.
< gmaxwell>
As far as KDFs go, reasonable KDFs are incompatible with hardware wallets, unless an outsourcable KDF is used.
< jonasschnelli>
if you have two macs, an attacker could ask for both passphrases,.. while the current BIP39 approach, there are "infinite" possibilities
< jonasschnelli>
not sure if this would be a downside
< gmaxwell>
jonasschnelli: "there is no second passphrase"
< gmaxwell>
(if one one is used, you just set the other one to a random value)
< gmaxwell>
with the BIP39 thing someone could also keep demanding your other passphrase while you protest that there isn't one.
< jonasschnelli>
true
< jonasschnelli>
though they could do the same if your second mac is based on a random passphrase. :)
< jonasschnelli>
(or random MAC)
< gmaxwell>
(I still do think the feature is dumb, also largely because 99.9999% of anyone will leak all sorts of stuff about what addresses they're using all over the place)
< jonasschnelli>
Yes. I guess it's a "marketing" feature.
< jonasschnelli>
Also, if lying is something that is often easy detectable and needs more courage that one things
< jonasschnelli>
*thinks
< gmaxwell>
Another one of those is secret sharing support. Which I think is also more marketing than pratically useful, but I think probably more useful than denyability.
< jonasschnelli>
secret sharing?
< jonasschnelli>
sharing secrets with something like the shamir approach?
< gmaxwell>
Well I really think the biggest weakness is that even if you successfully lie (remember to lie, decide to do so, etc) that the attacker needs to find just a single address you've used anywhere (put in a tip jar, signed up with on coinbase, etc) to tell that you haven't given him the right passphrase.
< gmaxwell>
jonasschnelli: yes, being able to split the private key into multiple parts where all parts aren't required.
< jonasschnelli>
Yes. Indeed. I also don't think that the feature is practical useful.
< jonasschnelli>
(^ regarding deniability)
< jonasschnelli>
gmaxwell: I think the secret sharing is way more pratical then the deniability feature)
< gmaxwell>
I agree, well "more". I'm also dubious of secret sharing in practice. Like the PD it strikes people as really cool, but then in practice it takes a lot of effort.
< gmaxwell>
but yea, if I had to pick one I'd do SS.
< jonasschnelli>
Indeed
< gmaxwell>
you can also see it in the tools, a lot of secret sharing code out there is snake oil. e.g. the old armory code where could could recover from two shares regardless of what the threshold was....
< * jonasschnelli>
falls asleep
< jhfrontz>
achow101: the installations appear to be part of creation of the vm/container environment because repeating the same —setup run results in the same errors.
< jhfrontz>
in this case, it appears to be installing sudo but is upset about the contents of /etc/sudoers (claiming that it's been modified — I've modified neither the host system's /etc/sudoers nor the vm).