asciilifeform: 'KeepKey is actually a fork of the Trezor project. We have maintained compatibility through development, and are compatible with Trezor v1.3.3.' << l0l
asciilifeform: i confess to having wondered if anyone in .ar writes software
asciilifeform: mircea_popescu: it is actually very common in usa software shops. indians produce mountain of horror, and then a handful of other people - clean it
asciilifeform: mircea_popescu: perhaps they had a stable of indians also
asciilifeform: no screwing with pgp separately, no untarring, etc.
asciilifeform: this way, no one who wants to get a release ever needs to do anything but ordinary operation of 'v'.
asciilifeform: but this way, a release is simply a vpatch that adds a 'this is part of such-and-such release' comment to a set of files in such a way that the desired leaves are brought into the release.
asciilifeform: mircea_popescu: as i understood it, he was speaking of signing manifests
asciilifeform: it is the thing children like about 'lego'
asciilifeform: this property of a system is called 'orthogonality'
asciilifeform: ;;later tell mod6 after this, anyone who wants to build THAT release merely needs to 'grab' ~that~ patch and 'v' does the rest.
asciilifeform: ;;later tell mod6 http://log.bitcoin-assets.com/?date=25-09-2015#1285169 << the way i suggested doing it is to avoid having multiple classes of signed objects. manifest for a release would be merely another kind of patch - one that simply takes every leaf that is to form part of the release head, and add a comment to the top of the file, 'REL-xxx.' this auto-gloms the leaves into a single patch 'handle', think about it.☝︎
asciilifeform: the specificity-of-diddle 'theorem' more or less demands this approach.
asciilifeform: (the set of mathematical operations used in crypto is quite limited, well-defined, and does not require a turing-complete interpreter to fully encompass.)
asciilifeform: mircea_popescu: the blockchain is tough on the disk i/o, yes. as illustrated by the abysmal failure of pogo-with-mechanical-hdd
asciilifeform: (for n00bz - consider a lock as analogous to an airplane toilet door)
asciilifeform: http://log.bitcoin-assets.com/?date=25-09-2015#1285158 << this picture is not correct. 'locking' here refers to literal lock, the global big fat lock in bitcoind, the one that makes it only pseudo-multithreaded on account of just about every major routine hogging it☝︎
asciilifeform: (a panel which fits on a passenger car roof - let's even assume one on the hood, as well - would be lucky to pick up 200W at high noon on a cloudless day.)☟︎
asciilifeform: and ideally one could specify the hash in a manner similar to bitcoin's scripts, rather than a hardcoded list of algos.
asciilifeform: if the protocol had been designed by sane people, ALL SIGNATURES WOULD HAVE SAME FORMAT regardless of for what the signature is - for a file, or for the key itself, whatever☟︎
asciilifeform: (not only in the added complexity of a zlib decoder, but in the fact that a message's actual length remains unknown until your start shitting it out)
asciilifeform: aaand is an attack vector of its own.
asciilifeform: (except that it very clearly adds structure of another kind)
asciilifeform: traditional whizzzdum is that it somehow improves seek00rity by making the plaintext less structured.
asciilifeform: yes, there is a 'do i want zlib' flag in pubkey, but EVERYONE here has it set.
asciilifeform: another annoyance is the inclusion of zlib.☟︎
asciilifeform: the third and all-encompassing atrocity of rfc2440/4880 is the idiot cruft pertaining to 'new' vs 'old' packet formats, the magical constants specifying largely antiquated block ciphers and hash algos, etc.
asciilifeform: ought to be able to include any subset of a pubmod with a signature or ciphertext - up to all of it, if i want.
asciilifeform: the other major atrocity is the fingerprint (yes).
asciilifeform: one modulus, one key, as the gods intended.
