mircea_popescu: <PeterL> I don't suppose people pass keys down to their heirs? << people well might.
davout: *further timestamps
davout: PeterL: well, sign something to this effect, otherwise timestamps are inherently suspicious, esp. if factorization is possible given state of current technology
PeterL: I don't suppose people pass keys down to their heirs?
asciilifeform: well yes, in that case joe is, so to speak, trimming the weeds on your monument.
mircea_popescu: this is the point of notarization : making the acts of men equal to the acts of god.
davout: i just fail to see a good reason to make the signatures mandatory, outside of access control that is
davout: yeah well, i wanted to point out that it didn't really prevent anyone from checking the inner sig at home
davout: say i want to timestamp a contract i made with someone also in the L2 group as nested clearsigns, i doesn't really matter which signature is checked by deedbot, right?
mircea_popescu: davout nah, it's required for inclusion in bthe actual deed.
davout: and if the signature on the blob is required only for access control, maybe it's be better to leverage asswot's functionality directly
mircea_popescu: PeterL idea kinda is to make a further record of people's sigs, help guard them against mitm and other nefariousness. but as davout points out, now the bot needs a key.
davout: mircea_popescu: well, now the bot needs a key too :-)
mircea_popescu: davout it gotta be one way. if there's four people and they fuck in two subsets of twos, that's segregation. if there's one that fucks all other three but the rest only jack off, that's privilege.
mircea_popescu: but dun worry about it, i seeded the prev one an' ill seed this one too.
undata: mircea_popescu: I read the payment as coming from the party wanting a signature, not the bot?
mircea_popescu: the point is to let them create and let the whole world trust and be able to verify.
mircea_popescu: not and only them.
davout: and only them
davout: the whole point here is to let ppl with L2/L1 trust timestamp stuff
punkman: davout, I'll just say that there were many cases with invalid signatures posted as deeds
undata: keeps the published bundles down to a size that is manageable
punkman: it doesn't really, but it's useful nonetheless
davout: why would Z's word add any value to the information GPG outputs?
davout: we don't need Z to witness that X and Y signed a contract together, because any party can and will use GPG
davout: why the hell would it need deedbot to testify to that too ?
undata: davout: its output should be the history of valid deeds, not "that which a rubber stamp has touched"
davout: wrt to your earlier example of me scamming you, anybody can verify i signed the contract by using gpg itself
davout: undata: you fail to comprehend that it's not deedbot's job to certify to a third party that the contract is signed by an identified party, gpg already does that
davout: let whores timestamp some blobs now and then i say
mircea_popescu: i give voice to all the whores, not to mention all sorts of known usg agents
davout: greatly simplifies the problem, don't see too much downside to it, and we're eventually moving to gossipd anyway
mircea_popescu: so i guess ima have to modify the spec instead of finishing my "on terrorism' article.
davout: anyway, my point wrt to deedbot is that it's supposed to be used by ppl with L1/L2 trust, it doesn't need to check gpg signatures, so let anyone with +v in -assets use it, do away with the requirement that a keyid belonging to someone in assbot's wot be presented or maliciously hammered into the message
mircea_popescu: which i guess is not that bad, seeing how it also solves the problem of the untrustworthy pgp-sks etc
mircea_popescu: davout only possible workaround seems keeping the lordship keys.
assbot: Logged on 17-01-2015 22:34:54; davout: asciilifeform: yeah, that's what i was reading, it mentions user ids in the subpackets spec, but i'm unsure whether that includes an actual key fingerprint, i tend to understand that it doesn't
Apocalyptic: ^ I asked myself the same
mircea_popescu: who the fuck did thius.
Apocalyptic: mircea, note that neither the "-v" nor the "--with-fingerprint" flags are required to get the fingerprint line displayed
davout: gpg can't know the fpr for a key it doesn't have, the information isn't part of the signature packet
mircea_popescu: feel free to fork and fix the gpg key verification process so it reports fingerpritns properly not wtf it's doing now.
mircea_popescu: defo the gpg signature model is bad.
davout: the crux is 'verified keys', if deedbot doesn't maintain a full keyring at all times it can't pull fingerprints
mircea_popescu: IF gpg doesn't put out full fingerprints for verified keys, then gpg is broken
davout: yea that's the whole problem
davout: mircea_popescu: with the fingerprint for a key it could simply do what you said wrt requesting trust data as a json blob from the w.b-a.link thing
mircea_popescu: well apparently it just became required to verify cause otherwise it can't talk to assbot.
mircea_popescu: davout if you don';t have the key you can't verify signatures, dork!
mircea_popescu: Apocalyptic the fingerprint, penultimate line.
mircea_popescu: kakobrekla: the point is MAPPING is bad << he understands.
mircea_popescu: asciilifeform keyid is the last 16 chars of the 40 char fignerprint. and then there's an 8 char shit too. neither of these last two are any good, but hey, "usability". crap.
davout: asciilifeform: well, keyid is a part of the fpr afaik
mircea_popescu: ah it's there.
mircea_popescu: who the fuck did this i have nfi.
davout: that implies you have the key in your keyring
mircea_popescu: ok but then gpg --fingerprint | grep "keid" ?
mircea_popescu: what do you mean gpg doesn't return them ?!
davout: i'll let you read the convo
mircea_popescu: same here, but who the fuck knows what they do in the soviet republic of san francisco.
mircea_popescu: apparently nobody heard of a "shut.the.fuck.up.and.hire.cleaning.crew.cheapskates."
mircea_popescu: asciilifeform they don't have cleaning ladies in the classic sense, which is why conde nast is writing memos to the "journos" about keeping the place clean.
mircea_popescu: at least until proof to the contrary.
mircea_popescu: PeterL so you'd be the innocent.
asciilifeform: not cleaning lady. demented bomzh who breaks into the office and takes a shit in the coffee pot.
davout: ah, yea lol, i had a look to see if this chick had any other commits on the project, seems like it's her sole 'contribution' to the whole thing
nanotube: kakobrekla: i have no idea why i keep keyid as a separate column in db either. probably something grandfathered in...
asciilifeform: this is a considerably less-fantastic scenario than it would have appeared to be in the '90s, because of the 'nintendoization' of computing. gpg simply won't appear in the apple and microshit 'app stores' and thereby vanish
undata: asciilifeform: after the next attack they'll ram all kind of laws through around weakining crypto
davout: "sure you can escrow my key, wanna make sure it's mine? just check the keyid"
asciilifeform: Apocalyptic: 'key escrow' crapolade went out with the first clinton presidency, will probably return with the second.
ben_vulpes: <kakobrekla> [] fuckin key party and assumption of socialization << another kakobrekla line worth reposting
Apocalyptic: and that's just for a preimage, if you want a collision the birthday paradox will tell you that you need much less than that
Apocalyptic: just take the bitcoin network, it performs 2**64 hashes in 60 seconds at current hashrate if I'm not mistaken
davout: that would be the number of distinct keyids, not sure how practically feasible it would be to bruteforce a collision
gribble: Error: Something in there wasn't a valid number.
davout: the signature verification would in this case (assuming both keys are in the keyring) yield both a pass and a fail, right?
asciilifeform: and so they weren't.
asciilifeform: and naturally the sigs will verify
asciilifeform: davout: picture if you were trying to pass a document off as having been signed by X. you generate a key with the correct name, etc. and colliding keyid, then try to pass it off as the genuine article; then, when chumps swallow it, sign with it
asciilifeform: davout: only if the signature was in fact made with evilkey
davout: that doesn't make much sense to me, how would a maliciously crafted pubkey even verify the signature?
asciilifeform: the keychain thing nicely parallels ben_vulpes's discussion re: bitcoind wallets
davout: and i guess even in the case of a keyid collision that has no impact on actual signature verification
asciilifeform: rather than something to resist attack of any kind
asciilifeform: hence the 'key id' was meant as merely a soft handle to quickly pick out the right pubkey.
asciilifeform: davout: a little subtler than that. the original assumption was that you would only ever verify sigs from folks you had a proper key party with
davout: "Implementations SHOULD NOT assume that Key IDs are unique", so let's just include that in the signature packet. derp
asciilifeform: or, alternatively, like the choice of 'aes' over the stronger but 'slower' 'serpent' cipher, it was merely orders from lizardhitler.
asciilifeform: 'it saves a few bytes' probably sounded like 'good reason' to the authors.
asciilifeform: kakobrekla: none afaik. the standard simply sucks.
davout: asciilifeform: yeah, that's what i was reading, it mentions user ids in the subpackets spec, but i'm unsure whether that includes an actual key fingerprint, i tend to understand that it doesn't
asciilifeform: davout: the version 4 signature subpacket spec << what do you want to know about it ?
undata: davout: surely you understand that the wot quantifies what a deed may provide historicity
undata: the reputation of the orifice matters and is maintained by not shoveling shit out into the public forum
davout: i think we should've stuck to lighting these jasmine candles :-)
undata: davout: what is the point of publishing a scientific work in a credible journal?
davout: umm... to timestamp them
undata: what's the point of that? in human terms?
undata: why does one publish the signed blobs
undata: davout: why are they published?
davout: lol, where does the spec even mention a second party?
davout: the point is to timestamp stuff, not hold anyone accountable to anybody other than by the actual parties to the contract, what's so hard about that?
undata: whether it says inside "A owes B his kidney" or "The sky is blue" both can be held to account that they have made the utterance by the existince of the thing
davout: that's not what tell you, they tell you 'this blob existed at that point of time, what's in it is none of your business'
undata: I have witnessed that fact and I sign and note the time
undata: two parties presented themselves to me and both said "I agree to whatevers in this blob"
davout: what then? you refuse to process it?
davout: look, there is a reason it's called deedbot, and not notarybot, it's none of deedbot's business to know what happened, for all you know the notarized stuff could perfectly be encrypted
undata: part of the service is actually having an idea of what has transpired, sort of renting out your good name
davout: i mean, even in that case, what's the worst that could happen? specifically?
davout: the thing is that, whatever turd comes along is necessarily given by someone who has voice in assets, so by very definition, not a turd
davout: because the notary doesn't enforce or verify anything, just certifies that something existed at some point of time
undata: so you're going to rely on the IRC protocol and not gpg?
davout: well, let's light some jasmine candles and talk about our feelings then
davout: for all i care the bot could hang out in -assets, and notarize whatever is asked from whoever has voice, sounds like the simplest straight-to-the-point approach to me
davout: undata: the notary doesn't enforce the agreement so why bother verifying the signature at all
davout: undata: i didn't spec it, ask mp for the rationale -> http://log.bitcoin-assets.com/?date=30-08-2014#815284
undata: davout: isn't the whole point of a notary verifying the identities of the parties involved then verifying that an agreement has taken place?
davout: but if you'd be ok with having some API call simply return the array of fingerprints in realtime, that'd be the easiest deedbot-wise :D
punkman: so I guess v4 sigs don't have fingerprints either
davout: kakobrekla: tbh if verifying the signature on notarized data is not considered necessary i don't think it's a big issue if the dump is unsigned
davout: kakobrekla: is there a way to easily get an array of asswotted fingerprints?
davout: the version 4 signature subpacket spec isn't that clear to me, maybe asciilifeform has some insight
davout: looked at version 3 signature packets, mebbe version 4 includes them
Apocalyptic: I confess that surprises me, had imagined the full fp would be somewhere
punkman: I think there is, but not 100% sure
Apocalyptic: punkman, thanks for the link, but I mean that there should be something in the clearsigned message structures that clearly identifies the key that produced it
davout: - the last option is kakobrekla getting some moar work
Apocalyptic: the second seems like a reasonable choice
Apocalyptic: I wonder what the behaviour is if you have two pubkeys in your keyring with the same eight bytes key id and you're trying to verify a message
davout: so basically the options are
Apocalyptic: then it's settled I guess
Apocalyptic: grep "get_short_fingerprint" in verify.c and see the related call get_fingerprint_hexstring() which supposedly could get the full fp
Apocalyptic: davout, re "looks like this can't be verified correctly without either relying on a keyid as an actual key unique identifier OR keeping a synchronized keyring and actually verifying the signature" I suspect there actually is, playing with the source atm
davout: undata: "the wot is an excellent tool for making good decisions about establishing those" <<< sure, but i'm not sure why the notarization *tool* would enforce that, i defo don't feel strongly enough about it to argue the point either way
davout: oh, and it's ppl who have L1/L2 trust from assbot, a subset from the wot members sez the spec
undata: the wot is an excellent tool for making good decisions about establishing those
undata: davout: the deeds are presumably for business arrangements
davout: other than that your understanding seems correct to me
davout: undata: it doesn't burn the bitcoins
undata: to summarize what's desired, the bot accepts signed documents from wot members in good standing only, publishes them by burning a small amount of btc and uploading to a site?
Apocalyptic: davout, so you're taking the deedbot project ?
undata: plugins can be started and stopped independently of the core
undata: the networking core is one thing, and plugins communicate with that over redis
davout: what *is* specified is that the bot must verify that the signer has L1/L2 assbot trust, looks like this can't be verified correctly without either relying on a keyid as an actual key unique identifier OR keeping a synchronized keyring and actually verifying the signature
undata: you'd write the deed bit as a plugin
davout: yeah, i put fpr or keyid in url, you spit out the fpr, actually no that's dumb
Apocalyptic: I can see a quite unpleasant spam attack otherwise
davout: kakobrekla: i agree, it's bad if you rely on keyids to actually identify the key, but if you output the actual full fingerprints in the returned json one can make an educated choice
undata considers the silence an affirmative...
davout: Apocalyptic: yeah, i think mp mentioned somewhere that verifying the sig is not necessary
Apocalyptic: davout, wait, so you're going to publish the deed without checking the signature is legit ?
davout: Apocalyptic: "you have to validate the sig" <<< no i don't think so
kakobrekla: the point is MAPPING is bad
punkman: davout, there is some combination of options that will do it for sure, you can look in python-gnupg
davout: it's always possible to query gribble to get the mapping, but that seems... suboptimal
Apocalyptic: davout, yeah but anyway you would have the key in your keyring since you have to validate the sig
kakobrekla: davout you can search keyserver perhps, but starting the search wherever with keyid instead of fp is not best idea
davout: if i don't have the key in my own keyring it doesn't seem possible to extract the fingerprint from a signed message
undata: as for english as I delve into a few other languages on duolingo I find my native tongue ever more horrifying
undata: carry on then
undata: ben_vulpes: hah oh the commit
davout: "replace keyid with fp ?" <<< sure, but how do i get the fpr from a signed message? gpg -v -v will just return the key id
davout: kakobrekla: "nfi why nano keeps keyid field in his db" <<< if you keep the fingerprint you're automatically keeping the key id as far as i understand since the key id is simply the second half of the fpr
davout: thing is, i was also reading mp's deedbot spec, the part i was wondering about was the "extract keyid from signed message, and use it in w.b-a.link URL"
davout: yea, i was reading gpg's rfc yesterday and found out that they aren't supposed to be relied upon for unicity
asciilifeform: it's hard and takes a lot of dedicated study << only for folks who do not read for pleasure in the particular language.
ben_vulpes: "their" implies more than one party.
ben_vulpes: if you don't know the gender, say "his or her"
ben_vulpes: nevermind that them/their is actually incorrect grammar if not used in reference to more than one person
undata: davout: it's ruby; let them have it
davout: danielpbarron: iirc with the raw tx thing you can send zero fees without problem, there's however a safeguard against sending a massive fee
asciilifeform: ben_vulpes not dead, therefore grew stronger
asciilifeform: sorta the point of having blockchain, no ?
ben_vulpes: say i have the transaction hash (aka txid) and output index - how do i get the pubkey those coins were sent to?
ben_vulpes: how do i get the pubkey for a given output?
ben_vulpes: (one can sign anything at any time - that's not the problem. the problems crop up in a) knowing the sigs are valid and b) the multi-input, multi-privkey transaction generation use-case: how am i to know which privkeys are to be used to sign which inputs, and furthermore [and somewhat recursively] how do i know those signatures to be valid?)
ben_vulpes: otherwise you just sign hash of txn, index in txn, and have no way to double check that you produced a valid signature corresponding to the pubkey to which those funds were transmitted originally.
ben_vulpes: to verify that you've created a valid transaction, you have to have the entirety of the previous output on hand to examine the public key
ben_vulpes: to use the modern txn api, yeah
ben_vulpes: i don't know that a bitcoind would be able to verify a transaction without access to the full inputs
ben_vulpes: creating a raw transaction requires having the previous transaction in hand in full at runtime, so as to extract the pubkey from the previous transaction
ben_vulpes: far easier for the people working on it at the time to make some silly assumptions about what txns a user would want to sign, and then keep those txns on hand
ben_vulpes: i'm starting to see some of the rationale behind the wallet paradigm - creating transactions for signing requires being able to retrieve arbitrary transactions from the blockchain
undata: it'd be neat if the thing paid its own bills out of its fees on some btc vps
ben_vulpes: undata: if you're interested in implementing, talk to MP for the spec
mircea_popescu: they look more like tower defense / dune2 sort of thing to me /
gabriel_laddel: they're in the same vein of games such as diablo I&II, baulders gate, path of exile etc. Not in terms of gameplay, but overall attention to detail and cohesive structure.
mircea_popescu: somehow i've never played either.
mircea_popescu: actually the supreme commander thing looks pretty slick.
ben_vulpes: need the right partners tho
mircea_popescu: "I've lived in filth, I've lived in sin, but I still smell cleaner than the shit you're in"
ben_vulpes: i awoke to sewage leaking around the bathtub plug actuator
ben_vulpes: the apartment complex drain backed up
mircea_popescu: hi terror brother ben
mircea_popescu: (well minus the "modern crypto uses ecdsa")
mircea_popescu: we stand against dns and against govt-sponsored pki schemes. their combination is not likely to resolve that.
fluffypony: "The alert key will be raised by Gavin"
PeterL: the more we disclose now leaves less suprises later
mircea_popescu: it was his twin brother.
kakobrekla goes to look the code
assbot: Successfully updated the rating for kakobrekla from 2 to 5 with note: too much stuff to list. inquire within..
assbot: You rated user decimation on 17-Jan-2015, with a rating of 0, and supplied these additional notes: marginal.
PeterL: so, if somebody has < 1 L2 rating, they don't get voice? or it just has to be > 0?
mircea_popescu: nah srsly. kakobrekla dun bother fixing
decimation: me thinks there might be some bugs
assbot: Successfully updated the rating for kakobrekla from 5 to 1.7 with note: hurr
assbot: Michigan Local News, Breaking News, Sports & Weather - MLive.com ... ( http://bit.ly/1wikq44 )
PeterL: there was talk earlier about newspapers. I find good local reporting at http://mlive.com and my sister-in-law writes for http://tooeleonline.com/
mircea_popescu: move to hungary. i hear they're going all fascist.
mircea_popescu: bitbet has it as well. so does every other country.
assbot: Sovereign immunity in the United States - Wikipedia, the free encyclopedia ... ( http://bit.ly/1wik1yA )
decimation: in civil court usg has explicit immunity https://en.wikipedia.org/wiki/Sovereign_immunity_in_the_United_States
decimation: in theory, usg has no legal immunity (from criminal courts), but in practice it clearly does
mircea_popescu: come to think about it, so can the da.
mircea_popescu: heck, the us scammer office (previously marshall's office) doesn't have to answer foia if it doesn't feel like it, and can even lie in public statements.
decimation: some elements of usg would claim otherwise