--- Log opened Tue Nov 19 00:00:02 2013
--- Day changed Tue Nov 19 2013
00:00 < Luke-Jr> maybe FL has some stupid laws
00:58 < dejasun> "no one can reist the clas "
00:58 < dejasun> resist*
00:59 < dejasun> "nothing can stop the claw!"
02:33 < gmaxwell> warren: should I go make a sign  "XYZ BTC bounty for fixing Bitcoin-qt on OSX" and stick it outside of apple?
02:56 < maaku> gmaxwell: that's not a bad idea
02:56 < sipa> with below the same in USD
02:57 < maaku> heh there's a bunch of protesters in front of infinite loop now. maybe I can get someone to stand there with a big "BTC BOUNTY!" sign
02:57 < sipa> strikethrough'ed many time
02:57 < sipa> with increasing usd numbers
02:57 < gmaxwell> need an electronic sign.
02:57 < gmaxwell> maaku: what are they protesting?
02:58 < maaku> offshore tax schemes
02:58 < gmaxwell> ah, I suppose that makes sense, they're ... far from alone in that.
02:59 < gmaxwell> but I suppose unlike most companies their customers might care.
02:59 < maaku> meh. i think it's more like reporters care. more likely for the protestors to get media attention if they focus on apple
03:05 < gmaxwell> Luke-Jr: so lets imagine that you have some anonymous cryptocurrency like that discussions we were having in here last week(end) with adam3us's encrypted coins + proofs ... which had the property that there was a UTXO set that you couldn't remove spent coins from as they were spent because if the network knew which coins they were spending then it wouldn't be anonymous (we mentioned this problem last week),  and it also had a spent coin li
03:05 < sipa> gmaxwell: you still need splitlong.pl
03:05 < gmaxwell> where was I truncated?
03:06 < sipa> spent coin li
03:06 < gmaxwell> ...you need an entry in the spent coin list to prevent it from being respent, once  it has been spent once.
03:06 < gmaxwell> Luke-Jr: now lets say its possible for someone who has spent a coin to seperately produce a proof that says "this entry in the utxo set is spent  now, go ahead and remove it." unconnected with their spend so they're still anonymous.  And likewise, once that ha happened they could produce a "this spent coin is nolonger in the utxo set" proof.
03:07 < gmaxwell> But only the anonymous spender of the coin could do this.
03:07 < gmaxwell> How the heck could you incentivize users to emit these additional messages?
03:07 < gmaxwell> keeping in mind is that if the result is giving them another anonymous coin, you're not achieving net reduction in the utxo set size, except via batching.
03:09 < Luke-Jr> offer them pizza?
03:09 < Luke-Jr> <.<
03:11 < gmaxwell> Interesting economic insight. Have you ever considered seeking a job at the fed?
03:11 < gmaxwell> :P
03:11 < Luke-Jr> :P
04:01 < midnightmagic> Yeah. I'd do quite a lot for a pizza dinner..
04:06 < warren> Luke-Jr: cfields wants to know if the deterministic linux -> mac cross-compile is good enough for the .app or it must be the .dmg.  He thinks the .app is possible deterministic but not the .dmg.
04:06 < Luke-Jr> why wouldn't .dmg be possible? -.-
04:06 < Luke-Jr> it's just a disc image
04:14 < warren> Luke-Jr: he can explain
04:15 < warren> Whoa.  Someone just donated to us $4,500 in one tx.
04:17 < Luke-Jr> for what?
04:18 < Luke-Jr> "in one tx" isn't surprising though :P
04:18  * Luke-Jr regularly sends over $100k in one tx
04:18 < warren> o_O
04:19 < Luke-Jr> well, why split it up?
04:19 < Luke-Jr> I guess I could get rid of more dust that way..
04:21 < Luke-Jr> you can always tell when it's mine too - I'm the only one who sends that kind of volume in TBC :P
05:14 < petertodd> gmaxwell: make a second currency whose proof-of-work is replace by proof-of-emitted-utxo-removal
05:14 < petertodd> gmaxwell: duh
05:18 < adam3us> gmaxwell, petertodd: still not 100% convinced it hurts to have a best-effort utxo reduction, full nodes want to do that to conserve ram
05:19 < petertodd> adam3us: utxo isn't in ram
05:19 < TD> good morning
05:19 < adam3us> gmaxwell, petertodd: however unless there is a ZKP proof that the coin stems from another coin & inputs addup to outputs, you cant do it
05:20 < adam3us> TD: 'morning
05:21 < petertodd> adam3us: big problem is the very idea of a utxo set is ugly, because it becomes something that can be attacked, or just ignorantly abused - better off to make that irrelevant
05:21 < adam3us> so then you're looking at like homomorphic values and ringcoin would kind of do it except they are 1.4kB per value and 3kB for ringcoin ones (where you prove you spent either of 2 coins, one of which you dont even own by proving either you own it, or you are ading 0 to its balance)
05:22 < adam3us> petertodd: yes i agree and its definitely easier if one can say screw utxo size, however its necessary for spv bloom and that or something similarly effective for bandwidth constrained devices is necessary for scalability
05:22 < petertodd> adam3us: well ~kB isn't a disaster if your underlying chain is scalable, which I think we need to do anyway in some fashion due to the centralization incentives that tx fees have (and I think this ends up being applicable to most types of crypto-currency systems)
05:23 < adam3us> btw charles hoskinson seems to be trying to cook up a big x-prize bounty for solving this problem.  i am not 100% sure its necessary or will help as most people with the skills to stand much of a chance are already working on it, but ou can never discount the power of 1000 fresh eyes
05:23 < petertodd> which problem exactly? anonymity or scalability?
05:24 < adam3us> petertodd: cryptographic anonymity without damaging decentralization or existing scalability, and using conservative crypto assumptions
05:25 < adam3us> a real hard problem
05:25 < petertodd> adam3us: ok, so lets bolt-on some anonymity to my txin commitments scheme. heck, with SCIP you'd be done actually - you don't need to show your txins exist, just prove they're real.
05:25 < petertodd> adam3us: remember your comment about how single-coin values would be anonymous...
05:25 < adam3us> petertodd: SCIP might fail the conservative crypto assumption, it seems if you go for it with SCIP there are a lot of options in the SCIP-coin area
05:26 < adam3us> petertodd: yes.  got to figure out what structure the private keys need so you can prove ownership of a sub-branch with log (n-k) where n is the number of coins and k the depth of the branch you own
05:27 < adam3us> petertodd: how's ttxin commitment work? did you write about it on forum?
05:27 < petertodd> adam3us: yeah, so lets ditch SCIP and stick with single-coin methods instead. with txin commitments you can roughly bound proof size without fancy math with demurrange, which is probably needed anyway to have a defined incentive to mine.
05:27 < petertodd> adam3us: heh, I've actually got a draft sitting in mutt that I haven't sent yet on it...
05:27 < adam3us> btw another downside of x-prize is people then get all secretive and competitive - i prefer open design
05:27 < petertodd> indeed
05:28 < petertodd> brb, gonna timestamp #bitcoin-wizards into the blockchain for credit :P
05:28 < adam3us> i wouldnt be surprised if that could be net negative
05:28 < petertodd> yeah
05:28 < petertodd> this is stuff where basic ideas are still being researched - it's not like your typical x-prize which is actually more similar to engineering
05:29 < petertodd> adam3us: you going to submit anything to this: http://fc14.ifca.ai/bitcoin/cfp.html ?
05:30 < adam3us> nope i tend not to do formal publictions if i have anything to say i just put a pdf on my website :) also the deadline is quite soon right
05:30 < petertodd> yes, very
05:30 < adam3us> (huge lead time 3months?)
05:31 < petertodd> yeah, and I only found out about it nov 7th myself, which I think would be true of everyone...
05:33 < adam3us> petertodd: the other thing i was wondering is you can still use bloom SPV approach with committed tx
05:34 < petertodd> adam3us: thing with bloom is it makes the assumption that you have this chunk of data, and you scan for txs in it - that's a bad assumption
05:34 < adam3us> petertodd: you just have to dload more; maybe if you put big miners in the payment chain, they can assert to having validated the payment path by their hash
05:35 < petertodd> adam3us: with the original pay-to-ip (or now payment protocol) version of bitcoin you never need to scan the blockchain to find coins (in theory)
05:35 < adam3us> petertodd: because the spender gives them to you
05:36 < petertodd> exactly
05:36 < adam3us> petertodd: well if you're going to do that you can safely use static addresses with a public variant of BIP 32 i posted about.  spender adds random value to your address.  Q'=yG+Q
05:36 < petertodd> which opens up a tonne of possibilities
05:36 < petertodd> sure, I mentioned a similar idea using the block hash as the nonce
05:37 < adam3us> petertodd: i was thinking a downside of payment protocol is it implies tighter integration between between browser and bitcoin client; browsers are notoriously security buggy
05:38 < petertodd> adam3us: who said a payment protocol needs the browser?
05:38 < adam3us> petertodd: right now you can scan a qr code on a browser
05:38 < petertodd> or just paste a URL into your wallet and let it do the magic
05:38 < adam3us> petertodd: with a smartphone and send the payment via the block chain, malware i the browser cant use the callback as an attack vector on your wallet because it has optical isolation
05:39 < adam3us> petertodd: yes but i mean if the spender has to inform the recipient of the key used because the spender randomized the recipients address (without forcing the recipient to be a full node)
05:40 < petertodd> adam3us: well I'm assuming a payment protocol with positive authentication of who you are sending too
05:40 < adam3us> petertodd: the implication is a send to ip, or hook from wallet to browser http post.  send to ip could be ok
05:41 < petertodd> adam3us: yeah, heck, "send via cut-n-paste"
05:41 < petertodd> adam3us: provided the proof of a txin isn't too unweidly, or at worst click and download a file to import to your wallet. It's all less nice than short addresses, but none of it is a showstopper.
05:41 < adam3us> petertodd: yes i am just saying something semi-related that you can convert a static address into a dynamic address if the sender has a way to notify the recipient of the dynamic address
05:43 < petertodd> adam3us: yeah, so use a prefix-filter rather than bloom filter and implement bitmessage - pick your anonymity set based on how much bandwidth for unrelated messages you can tolerate. Of course, sender just sends you the addr
05:43 < adam3us> petertodd: or you could do it anyway via broadcast if the recipient is a full node to trial decrypt all dynamic addr payments; does seem like a waste of bandwidth to communicate via broadcast any bits that dont need miner validation
05:44 < adam3us> petertodd: the only reason to not send it direct is if the recipient is a user, who is not online much; then something like bitmessage is more sensible than full broadcast.  i think people may be a bit hungup on broadcast as the most robust distributed delivery
05:44 < adam3us> petertodd: you could even email it to them.  it is encrypted.
05:45 < petertodd> adam3us: right, but you see where I'm going with that... so if you assume a prefix-filtered broadast medium, if you just add order to it you've also got txin commitments :P
05:45 < adam3us> petertodd: i think the prefix filter is probably the same thing as what i was calling bloom bait in discussion here with gmaxwell
05:45 < petertodd> adam3us: and yeah, you're totally right that a simple data packet that you send to the receipient, somehow, makes a lot of sense
05:45 < petertodd> adam3us: bloom bait?
05:46 < adam3us> petertodd: eg you put 1 byte of the non-randomized public key as a prefix, then spv clients can ask for such messages from full nodes with some privacy
05:46 < petertodd> adam3us: yeah, exactly that
05:47 < petertodd> adam3us: point is, that's a totally different, and more scalable, mechanism that bloom
05:47 < adam3us> petertodd: bloom bait because the Q'=yG+Q is randomized so badly you have no idea without downloading them all.  if you use 1 byte of Q also, your anonymity set is reduced but you reduce your bandwidth by 1/256
05:47 < petertodd> adam3us: also has some potential for attac if not handled well...
05:47 < petertodd> adam3us: yup
05:47 < petertodd> adam3us: and fundementally anonymity sets are about bandwidht anyway, so tht's not a surprising trade-off
05:48 < adam3us> petertodd: eg make an addr with same last byte as your target, and spam it with minimum non-dust payments to sabotage your victims spv ability to find their payment
05:48 < adam3us> petertodd: i was wondering about a multi-node pir solution
05:48 < petertodd> adam3us: yup, which gets to how part of that needs to have clearly defined costs
05:48 < petertodd> adam3us: pir?
05:49 < adam3us> petertodd: private info retrieval ... if you have two machines with a ddatabase, ou can ask one to xor rrandom bits from the db and the other to xor random bits, but with 1 bit different, xor the 2 results and you have your result but each db knows nothing without colluding
05:50 < adam3us> petertodd: you can make one of the bitstrings be a seed to a prng to halve request bandwidth; there is even some funky stuff where you can have single db pir
05:50 < adam3us> petertodd: but its a bit bandwidth heavy and cpu heavy
05:50 < petertodd> adam3us: ahh
05:51 < petertodd> adam3us: IMO better if you aren't thinking in terms of clients and servers anyway
05:51 < adam3us> petertodd: however allt he bandwidth and cpu can be tuned by reducing the anonyity set
05:51 < adam3us> petertodd: yes client is spv client, server is a random selection of full nodes, like spv operatin but a different request privacy mechanism than noisy bloom
05:53 < adam3us> petertodd: single db computational pir is kind of amazing that its possible.  works via homomorphically encrypted xor
05:54 < adam3us> petertodd: BUT rsa public key encrypted value PER BIT... jeeze (bandwidth) and public key op per db index bit on the server also, result is compact though one public key value
05:55 < adam3us> petertodd: so txin commitments  relates to fidelity bonds at a guess? ;)
05:55 < petertodd> adam3us: when you pick a random full node, how do you know they are independent? :P
05:55 < petertodd> adam3us: no, not at all. txin commitments just means the blockchain exists as a mechanism to commit to the txins of a transaction, and transactions are arranged such that the txouts are committed to by the txins
05:56 < adam3us> petertodd: indeed.  however its just address linkability - not security.  now they are linkable .  if you o that with random nodes, and try to avoid being herded to a hostile group of nodes, its an improvement
05:56 < petertodd> adam3us: here, give me a minute and I'll publish :P
06:00 < petertodd> published! hopefully there weren't any glaring editing mistakes I'd forgotten about...
06:01 < petertodd> adam3us: ok, so remember, the key thing about this is that like committed txs in general, you never have to publish the whole tx publicly
06:01 < adam3us> ok
06:02 < petertodd> adam3us: so it is securety, just not quite as strong as it could be if you used some more fancy crypto
06:02 < adam3us> petertodd: i do like that you dont publish as it simplifies miner validation.  seems to me miner validation is a protocol complexity risk
06:03 < adam3us> petertodd: its better if the distributed signature (global hashing) is focussing on something extremely simple - ordering
06:03 < warren> I'm booking my trip to the Vegas conference.   anyone else going?
06:03 < warren> there's a hidden discount code
06:03 < adam3us> warren: yeah i think so
06:03 < adam3us> warren: oooh nice ... do share :)
06:03 < petertodd> warren: vegas?
06:03 < adam3us> warren: (not booked yet)... btw fair warning it seems to be relatively non-tech
06:04 < warren> adam3us: I'm a MBA/law student
06:04 < adam3us> warren: reiner is presenting, otherwise suits
06:04 < petertodd> adam3us: yeah, and by sticking to ordering, you are forced to deal with incentivising mining separately, which can be an advantage rather than just giving it a hope and prayor
06:04 < adam3us> warren: i am talking about people who cant code, or probably fully understand bitcoin protocol if they had to to save their life
06:05 < adam3us> petertodd: yes that is a nice side effect- many incentives and attacks become weaker if you're attacking opaque blobs of your adversary, worst you can do in many cases is random DoS that costs you money
06:06 < warren> adam3us: you mean any of us fully understand the bitcoin protocol? =)
06:06 < warren> I don't think Satoshi understood it fully.
06:09 < adam3us> warren: satoshi - maybe... the full implications at the limits of game theory are complex.  but the whole thing is amazing so bucket loads of kudos to satoshi
06:11 < petertodd> adam3us: see the tx fees/latency thing is something I've lately realized should be worried about - specifically how orphans incentivize mining centralization
06:24 < adam3us> so bitcoin hw security.  seems like the risk is going up.  at some point someone with $1m worth of zerodays is going to burn them to steal $10m worth of bitcoins.  and there are people with access to zero days
06:25 < adam3us> i think the solution is hw wallets like trezor and armory offline
06:25 < petertodd> armory says they'll have useful multisig soonish
06:28 < adam3us> petertodd: my other thought is any 2fa for services can not be disconnected from teh tx
06:28 < petertodd> adam3us: ever see my 2fa sceme with multisig txs?
06:28 < adam3us> petertodd: ie it must resolve to the tx, on an offline wallet with a display
06:28 < adam3us> petertodd: no but that sounds like you already had the same thought
06:30 < petertodd> adam3us: well I was thinking use bip32 to generate one of the keys, and then use a OTP scheme to generate the other. Now when you initialize it, you pre-generate all the pubkeys for the OTP scheme, and then transfer coins to the resulting addresses. Every OTP code you reveal has in effect authorized the expenditure of some fixed amount of BTC.
06:30 < petertodd> adam3us: it's not "interactive", but the security is very understandable and predictable, and the scheme can be done on paper
06:43 < warren> adam3us: fail.  conference fee paying has no bitcoin option.
06:43 < adam3us> petertodd: well i mean like say an exchange, it holds your coins and fiat
06:43 < petertodd> adam3us: ah, outsource the risk to them, which is reasonable too
06:44 < adam3us> petertodd: rather it should do the type3 exchange. it green signs only
06:45 < adam3us> petertodd: then the 2fa is the user signs with their multisig key after reviewing the transaction
06:45 < adam3us> petertodd: they should issue their usdcoin also with an offline issuing key, block chain validated, again 2fa signed by multisig
06:46 < petertodd> adam3us: yeah, gavin outlined something similar to that actually
06:46 < petertodd> adam3us: 2fa auth to the holder, and then they coutner-sign
06:46 < adam3us> petertodd: in that way the exchange cant steal or be hacked
06:46 < adam3us> petertodd: and their only signing key (issue/redeem) is air gapped
06:47 < adam3us> petertodd: people are going to have to do type3 exchange sooner or later or bad things are going to happen
06:47 < petertodd> type3 exchange?
06:48 < adam3us> petertodd: so where the exchange has no coins at risk
06:48 < petertodd> ah right
06:48 < adam3us> petertodd: type2 i was calling where they have only fiat at risk (like bitalo finally is working on)
06:49 < petertodd> well, there's also type2.5, where the exchange can't steal, but if they lose the key you're fucked
06:49 < adam3us> petertodd: after having their previous exchange owned/insider attacked or something - only because they learnt the hard way!
06:49 < adam3us> petertodd: yes.  i think you want a timelocked reimbursement for the multisig in case exchange goes rogue, disk crash, out of biz, etc
06:50 < petertodd> absolutely, although actually handling that is hard - lots of ugly state and software messyness
06:50 < adam3us> petertodd: of course your usdcoin are toast anyway - thats down to queueing up as a creditor of the type 3 exchange
06:50 < petertodd> owning USD is inherently not a type3 scenario :P
06:50 < petertodd> regardless of how directly you own it
06:51 < adam3us> petertodd: i think its the new model really i cant see anything else working as you're just putting up a fat perfect crime target, people will burn zerodays, hack certificate authorities, bribe employees, physically break into server rooms... its all coming
06:52 < adam3us> petertodd: i suspect even the 1000s of snowden level guys at NSA and other intelligence agencies with access to their grey-market zerodays, and the grey hat hackers who developed and sold them the zerodays will sooner or later go darkside
06:52 < petertodd> adam3us: I remember saying to gmaxwell months ago that I was hesitant to write anything remotely real related to fidelity bonded banking until I had some remote attest capable TPM hardware to use
06:52 < adam3us> petertodd: eg btcarmory.org is a malware clone of bitcoinarmory.com professionally cloned web site, presumably designed to steal your offline armory wallet
06:52 < petertodd> nice...
06:52 < petertodd> yes, bad software is a nasty one too
06:53 < petertodd> heck, whenever I've used bitaddress.org I've always entered in my own randomness :P
06:54 < adam3us> petertodd: people are going to steal code signing certs or obtain by document forgery.  even happened to micrsoft something like that ... fool the RA process of a CA
06:54 < petertodd> yup
06:55 < petertodd> excellent reason to avoid auto update for tha tmatter... also spread your coins across multiple wallet implementations
06:56 < adam3us> petertodd: i think even code signing is bad... signing keys can be compromised, compelled sig on TLA malware version by court, compelled signing key disclosure things like that
06:56 < adam3us> petertodd: maybe its time to publish software hashes to the block chain and forward secure signatures
06:57 < petertodd> forward secure sigs?
07:04 < adam3us> petertodd: kind of like forward secrecy for encryption
07:05 < adam3us> petertodd: you destroy old signature keys so you couldnt forge and resign an old one with the same key
07:06 < adam3us> petertodd: http://www.cypherspace.org/adam/nifs/refs/forwardsecure.pdf
07:06 < petertodd> ah right
07:07 < petertodd> see, just timestamping signatures in bitcoin works well too for that
07:07 < adam3us> petertodd: the main thing is they found a way to have a sequence of public keys and deleted old private eys compactly, otherwise ou could just state an intent to use each sig only once
07:07 < adam3us> petertodd: yes it maybe functionally similar in effect
07:08 < petertodd> I keep meaning to update opentimestamps with OpenPGP support, but that'll be a fair amount of work...
07:08 < adam3us> petertodd: also there is a way to do one use signatures where the signature key can only be used once,
07:08 < petertodd> how does that work? I mean, how could you enforce that?
07:08 < petertodd> (well, without a consensus key-value system anyway...) :P
07:09 < adam3us> petertodd: its quite simple you pre-generate R=xG and make it part of the address, so Q'=H(Q,R)
07:09 < adam3us> petertodd: now people will only accept as valid a signature with that specific R value
07:09 < adam3us> petertodd: brands uses it for one-show certificates.
07:09 < petertodd> I guess I'm not following
07:10 < adam3us> petertodd: the interesting thing is if you go ahead and reuse R, and sign two idfferent messages, you can do that but you leak our private key via simultaenosu equation
07:10 < petertodd> ah right, figures, my point was, that's not a scheme where you can't re-use a signature, that's a scheme where you damn well shouldn't, but a validator without perfect knowledge can't tell the difference
07:10 < adam3us> petertodd: so ecdsa sig Q=xG, R=kG, s=(h(m)+rd)/k, r=R.x
07:10 < petertodd> (knowledge of all sigs made)
07:10 < adam3us> petertodd: ok
07:11 < petertodd> my point being that with a consensus key-value system, you can define the signature as valid if it's the one setting a given key to a given value
07:11 < adam3us> petertodd: yes, but it becomes unconvincing - why would you sign twice, it tells you this is invalid, if you can combine it with time-stamping to order them, thats it
07:12 < petertodd> right, but then the attacker signs twice, so you have three in total, and you still need the consensus system to figure out which was first
07:12 < adam3us> petertodd: yes.  it could be interesting though because any miner could ake the private key and spend it to himself instead
07:12 < petertodd> right, so in some cases you can treat it like a fidelity bond
07:13 < adam3us> petertodd: and it prvoides cryptographcally enforced one-use addresses re Luke-Jr attempt to incentivize secure use
07:14 < petertodd> yeah, but s/enforced/boobytrapped/ :P
07:14 < adam3us> petertodd: yes i guess so.  it could even be specificed who benefits eg put the double spend address in the address
07:14 < adam3us> petertodd: the one downside is yo have to be really careful with sw failure, spending is not idempotent
07:15 < petertodd> yea, and that's damn ugly
07:15 < adam3us> petertodd: accidentally pay twice due to system crash during a spend and lose your money
07:15 < adam3us> petertodd: it is a deterministic signature however, if you spend to the same recipient, same amount you release the same sig, so no leak
07:16 < petertodd> yup
07:16 < petertodd> but anyway, I gotta go
07:16 < adam3us> petertodd: so you need like database transactional behavior
07:16 < adam3us> petertodd: 'night!
07:16 < petertodd> later
07:16 < petertodd> read through that txin post if you could btw
07:16 < petertodd> thanks
07:16 < adam3us> petertodd: i am
07:26 < jtimon> petertodd I'm still reading your proposal, looks very promissing
07:38 < jtimon> I have some questions when you get back
07:45 < warren> The obscure exploit in Litecoin's code for the clones with non-Litecoin parameters might not actually work.  They're failing to make a copy of our code work at all.
08:16 < Emcy_> it seems like you really want to see that logic bomb go off
08:21 < Emcy_> did i just hear right that the foundation is involved in some sort of child protection "task force"
08:23 < Emcy_> tht pretty much precludes any endorsement of measures to counter things like CV, or even indifference since theres no way to magically seperate out 'good' uses of privacy from bad ones
08:23 < Emcy_> however desirable that may be especially in this case
08:25 < warren> The logic bomb may or may not exist.  They lack the ability to figure out if it exists.
08:25 < warren> They can't even get the code to run.
08:27 < Emcy_> also i find it interesting that the first panel consisted of the reps from the very serious and scary agencies and depts of government, and the second panel they threw a child protection guy in with the actual 3 reps from the bitcoin community.
08:27 < Emcy_> an attempt to steer the commentry or am i just cynical
08:30 < Emcy_> god did he relly have to namedrop somr of those onion sites........
08:32 < Emcy_> now he just basically said we need to break privacy for everyone because actual police work is expensive and difficult
11:52 < petertodd> jtimon: thanks!
11:53 < petertodd> warren: lol
11:53 < TD> wow
11:54 < TD> tony actually submitted my smart property auto loan protocol as an example to the US Senate
11:57 < petertodd> TD: congrats!
11:57 < TD> thanks!   a little bit of #bitcoin-wizards has gone to washington :)
14:43 < BlueMatt> TD: nice!
14:43 < sipa> it's in 45 minutes, right?
14:43 < sipa> *47
14:43 < BlueMatt> yea
14:51 < TD> BlueMatt: wanna see a video of micropayments based file download app?
14:52 < BlueMatt> TD: really? yes!
14:52 < TD> http://www.youtube.com/watch?v=r0BXnWlnIi4
14:52 < TD> i made this for a journalist who is writing a story about cool stuff you can do with bitcoin, contracts and so on
14:52 < TD> he wanted to see it
14:53 < TD> it's not _quite_ ready to ship yet but a guy has turned up to help and is serious, he's been submitting patches. so i think it should launch by EOY
14:53 < BlueMatt> TD: wow, that is beautiful
14:53 < BlueMatt> is the code public?
14:53 < TD> https://github.com/mikehearn/PayFile
14:54 < TD> there's a CLI and a server as well, of course
14:54 < BlueMatt> awesome
14:54 < BlueMatt> out of curiosity, how long did it take you to bootstrap that?
14:55 < BlueMatt> ok, this seems unreasonably high, sending a block from new york -> sydney -> new york is taking multiple seconds???
14:55 < BlueMatt> is that a shitty network stack or is that shitty tcp?
14:56 < TD> the actual amount of code is small, but i developed the wallet template app and fixed a bunch of micropayments issues along the way so hard to say
14:56 < TD> but if you look at the code it's not very complicated
14:56 < TD> switching it to use a properly abstracted protobuf rpc layer like p2proto would reduce the code size even further
14:56 < TD> also it's java 8 so i get to use lots of lambdas and CompletableFuture
14:56 < TD> which is sort of like ListenableFuture but on steroids
14:57 < TD> but payfile was an evenings and a few weeks jobby
14:57 < BlueMatt> ahh, well, still...thats awesome
14:58 < TD> when it's done i was thinking of making some video tutorials where i actually code it up, on the video
14:58 < TD> i reckon we can make the code required small enough that a code spring from start to finish could be just a few hours
15:00 < BlueMatt> yea, in theory it shouldnt be hard, but yea, thats pretty awesome
15:00 < BlueMatt> a tutorial would be pretty cool, get people using micropayments
15:01 < TD> right
15:06 < TD> anyway glad you like it. and yeah i put in some effort to make it look nice and be usable, like with the qrcode button
15:07 < TD> i'm looking forward to seeing what people make of it. we found a really nice java installer creator as well - you can even create windows installers from mac/linux without needing windows (signed!)
15:07 < BlueMatt> damn
15:08 < BlueMatt> yea, Im not sure about the use it will get, but its a perfect example for micropayments and it should drum up some interest for other related projects
15:09 < TD> well downloading files isn't terribly important.
15:09 < TD> but simon, i think, is ambitious. he wants to evolve it towards gmaxwell's StorJ vision. like after v1, he wants to do uploads, and from there ....
15:11 < BlueMatt> ooo
15:11 < BlueMatt> yea, ok, thats very useful
15:36 < coryfields> Luke-Jr: around?
15:37 < cfields> Luke-Jr: just in case i was invisible just now, re-ping
15:44 < phantomcircuit> hmm
15:45 < phantomcircuit> im running master on a server with zfs
15:45 < phantomcircuit> a client is reporting that the time of a block it's sending is too far in the future
15:45 < phantomcircuit> given it's zfs im not thinking disk corruption is likely
15:59 < Luke-Jr> cfields: ?
16:12 < petertodd> TD: in addition to data streaming, here's another application for your micropayments: http://www.reddit.com/r/Bitcoin/comments/1qzr3n/when_escorts_start_accepting_payment_in_bitcoin/cdi450c
16:13 < TD> like pay-per-minute sex? i think that establishes the wrong incentives ....
16:13 < petertodd> TD: hehe
16:13 < TD> i guess camgirls could use it though
16:13 < warren> cfields: you still going to do the qt dep upgrade?
16:14 < TD> if there was a generic pay-per-second stopwatch
16:14 < TD> petertodd: btw, economist writes up fidelity bonds/sacrifices on the babbage blog: http://www.economist.com/blogs/babbage/2013/11/internet-security
16:14 < petertodd> TD: actually that'd be a nifty thing... generic payment-protocol-using pay-to-time-money
16:15 < TD> (unfortunately the journalist called it "Mr Hearn's protocol" at one point, I wrote him to correct that, dunno if he'll update the blog)
16:15 < petertodd> TD: thanks, that's awesome
16:15 < petertodd> TD: do mention the computational financial side of it too - they're both distinct use-cases
16:16 < TD> there's a larger article coming out at the end of the month in the print edition that covers more topics, not sure what it'll contain exactly
16:17 < petertodd> TD: interesting; the economist tends to have good insight
16:17 < TD> well after spending ~1 hour talking to one of their journalists, i am not really surprised by that, they do their homework
16:18 < TD> after he heard about the anonymous ID protocol he got really excited by it and obviously wanted to write about it ASAP
16:18 < TD> so that's pretty cool
16:18 < petertodd> Yeah, I think in the short term the anonymous ID stuff is much more interesting - financial uses for sacrifices are much more abstract and theoretical.
16:19 < TD> yeah
16:19 < petertodd> I mean, it's cool and all you can make fidelity bonded banks with all those nice incentives, but that doesn't mean they're useful.
16:21 < cfields> warren: osx dmg built in linux, up and running on osx :)
16:22 < cfields> Luke-Jr: deterministic dmg's would be a major headache, if even possible
16:22 < warren> cfields: can the toolchain itself be deterministic and unpacked in one of the existing VM's?
16:23 < cfields> warren: yea. going to take a while to clean it up, but that will be the end result
16:23 < warren> cfields: awesome
16:23 < petertodd> http://www.reddit.com/r/Bitcoin/comments/1qz6hn/dont_believe_the_numbers_in_blockchain_scam_alert/ <- cryptographic proof, you don't grok it
16:24 < warren> cfields: what is the minimum macosx version that it will run on?
16:24 < warren> cfields: I think we can drop 10.5.x
16:24 < cfields> warren: should be 10.5
16:24 < cfields> it's currently running on my 10.6 box
16:25 < warren> cfields: following gavin's instructions our binaries don't work on 10.5
16:25 < warren> 10.6 works
16:25 < warren> in any case are there really 10.5 users?
16:26 < cfields> warren: that discussion is tangential.
16:27 < warren> cfields: how much more work would it be to make it 32/64bit in the same binary?
16:28 < cfields> not too bad, you'd basically just do the whole things twice
16:29 < warren> cfields: can users crypto verify the .app without executing anything in the .dmg?
16:30 < warren> since the .dmg can't be deterministic
16:31 < cfields> not saying it can't be, just saying it may be an unreasonable amount of effort. .app is a much more reasonable (first) goal
16:31 < cfields> and yes
16:32 < cfields> there's still a long way to go.. it's big, it's not pretty, it was built by hand, etc
16:33 < cfields> just figured i'd mention that it's up and running
16:36 < warren> cfields: are you still doing the planned qt dep upgrade?  we've held off from touching that stuff because you requested.
16:36 < cfields> hmm, forgot about that
16:36 < cfields> yea, i'll dig it up and PR it
16:37 < warren> cool
16:37 < Luke-Jr> cfields: DMGs are just disc images, why would that be a headache? O.o
16:38 < cfields> Luke-Jr: hehe, they're far from 'just disc images' :)
16:38 < Luke-Jr> …
16:38 < Luke-Jr> they *can be* at least
16:38 < cfields> Luke-Jr: yea. seems there's all kinds of randomness baked into the spec
16:39 < cfields> i can get to the bottom of most of it.. but to go further means really nasty hacks
16:39 < warren> cfields: hmm, one user reports they have the mac corruption without time machine
16:40 < warren> they didn't say which version they were running though
16:41 < cfields> Luke-Jr: unfortunately, the cleanest approach to the next step is to begin modding the hfs+ kernel module. And at that point, I don't think it's really worth it
16:41 < cfields> either that, or ofc writing a new tool from scratch
16:43 < warren> cfields: timestamps in the filesystem and checksums differ, I'm guessing?
16:45 < cfields> warren: most linux tools use loopbacks to mount an image file. mounting/unmounting causes alterations like last-accessed times, next fsck time, mount-count, etc
16:46 < cfields> better option would probably be to start hacking on genisoimage, but iirc its output was much more random
16:49 < Luke-Jr> I suggest 7z920/CPP/7zip/Archive/DmgHandler.cpp
16:49 < Luke-Jr> not sure if the Linux version is built with DMG support, but at least the code exists
16:52 < warren> the way mac itself makes the .dmg is a loopbac mount
16:52 < cfields> Luke-Jr: i'm not saying it's not possible. I'm saying that i suspect that a bit of randomness may be functionally necessary
16:53 < cfields> could you link those sources btw? my google-fu must be weak today
16:53 < Luke-Jr> http://downloads.sourceforge.net/sevenzip/7z920.tar.bz2
16:54 < Luke-Jr> deterministic randomness is possible for anything DMG could possibly need
16:54 < cfields> thanks
16:54 < Luke-Jr> sorry, "randomness" in quotes..
16:54 < Luke-Jr> ie, tar & hash the .app a few times as a seed..
17:01 < warren> cfields: you also going to change all the .zip's to tar?
17:01 < Luke-Jr> deterministic tar is likely more work
17:02 < Luke-Jr> since it saves more attributes
17:03 < cfields> warren: i'd like to, yes
17:04 < Luke-Jr> imo ideal would be to have the deps build deterministic debs - but that's probably more trouble than it's worth :p
17:05 < warren> I'd like fedora to just ship upstream's determinsitic binaries in their rpm
17:05 < Luke-Jr> good luck
17:05 < Luke-Jr> it's a shame there's so much politics in Gentoo development
17:05 < Luke-Jr> so much potential there
17:06 < Luke-Jr> could have the entire OS be deterministic :D
17:09 < warren> Luke-Jr: ask cfields for his patches to make binutils deterministic
17:17 < Luke-Jr> :o
17:18 < cfields> looks like they'll make it into 2.24: https://sourceware.org/ml/binutils/2013-11/msg00214.html
17:20 < cfields> Luke-Jr: it's worth noting that I haven't even reached the point of trying to create a deterministic dmg. Any dmg must first contain a deterministic filesystem...
17:20 < cfields> So that means creating/formatting/writing an hfs+ partition in some deterministic way
17:25 < sipa> i think having a determinstic binary is already a huge step
17:25 < Luke-Jr> indeed
17:26 < cfields> well, the question is: what is "good enough" for distribution?
17:27 < sipa> right now, the only ones checking determinism are those that build and sign
17:27 < cfields> the .app is the only thing that ends up on the target machine, so i would call a deterministic app "good enough" for the most part
17:27 < sipa> which is a pity
17:27 < cfields> problem comes with the verification process of that .app
17:27 < sipa> but being able to compare your installed binary with published signatures is very nice already
17:28 < sipa> it may actually matter more than deterministic installers, i just realized
17:28 < sipa> what if the deterministic installer secretly downloads data?
17:28 < cfields> how could it do so secretly?
17:28 < sipa> well, the same argument holds for the binary of course...
17:28 < cfields> heh, right :)
17:28 < Luke-Jr> cfields: we could in theory distribute a tar of the app
17:29 < cfields> Luke-Jr: well, that's really abou the same thing, no? user un-tar's, discards the tar, ends up with the same .app
17:29 < cfields> only thing that changes is a possible attack vector in the dmg itself
17:29 < Luke-Jr> well, I mean a deterministic tar of course :P
17:30 < cfields> oh, i see. so at least the download could have a checksum next to it
17:30 < Luke-Jr> deterministic tar vs deterministic dmg, not sure anyone cares about the diff
17:30 < cfields> Luke-Jr: btw, i agree with you that it should be possible to recreate a dmg. I'm not sure where the fuzzing is happening, but i'm sure that it could be tracked down
17:30 < Luke-Jr> but you'd have to ask Mac users I guess
17:31 < cfields> whether it's worth the trouble, that's where i take issue
17:31 < cfields> as an osx user (i hate admitting that), any download that's not a dmg gets on my nerves
17:31 < cfields> unless it's a .pkg for good reason
17:31 < Luke-Jr> so it sounds like we should get .dmg to work
17:32 < cfields> yea...
17:32 < cfields> i'll keep at it
17:32 < cfields> at this point, i'm checking out genisoimage. Sources there should point me to something
17:32 < Luke-Jr> cfields: can you rename .iso to .dmg and have it work quietly? ;)
17:33 < sipa> just rename the .tar to .dmg *ducks*
17:33 < cfields> heh. the main thing with dmg is the convenience of dragging it to the applications shortcut
17:33 < cfields> i'd say users expect that, to the point of possibly being lost if it's not there
17:34 < Luke-Jr> cfields: but do you get that if you rename an iso maybe?
17:34 < cfields> Luke-Jr: no, that's scripted as part of the dmg-building process
17:34 < Luke-Jr> O.o
17:34 < sipa> scripted disk images
17:35 < sipa> what's next?
17:35 < sipa> object-oriented assembly?
17:35 < sipa> power over wireless ethernet?
17:35 < cfields> sipa: i guarantee you someone's hacked wireless charging pads to carry data :p
17:36 < cfields> aha...
17:36 < cfields> -getpid()                                = 12125
17:36 < cfields> +getpid()                                = 12158
17:38  * cfields starts with some LD_PRELOAD fun
17:47 < cfields> hah, got it
17:47 < cfields> i'm a moron.
17:51  * sipa doubts this
17:55 < cfields> heh, you'd be surprised
17:57 < Luke-Jr> ?
18:06 < phantomcircuit> i think there's a regression in master
18:07 < phantomcircuit> i have a 0.8.5 client connected to a server running master that keeps failing with "CheckBlock(): block timestamp too far in the future"
18:07 < phantomcircuit> BlueMatt, is the build bot working?
18:09 < phantomcircuit> gmaxwell, ^
18:21 < cfields> deterministic dmg up and running
18:22 < cfields> Luke-Jr: i assume you'll cut me some slack if the initial process isn't exactly pretty :p
18:22 < warren> cfields: too much of a headache.  <one hour later> done
18:23 < warren> cfields: so ... gitian .yml to build clang and whatever tools, tar it up and gitian.sigs that, use it as an input for another gitian .yml?
18:23 < cfields> warren: heh, was just a case of me being stupid
18:23 < cfields> warren: uses ubuntu's existing clang
18:23 < warren> which ubuntu?
18:24 < cfields> well, that part still needs to be investigated. I'm currently using a nightly build of llvm/clang, but I don't think it's actually needed
18:24 < cfields> (I'm on raring)
18:24 < phantomcircuit> nvm the clock is just wrong on the client
18:25 < cfields> i'll drop back to system packages and see what breaks
18:25 < warren> Gavin will enjoy a 4th gitian VM =)
18:25 < cfields> anyway, now that it's working, i'll start packaging it all up so it can be automated cleanly
18:26 < cfields> will be a few days i'm sure
18:27 < sipa> warren: i think Gavin will enjoy not doing OSX releases manually
18:29 < gmaxwell> phantomcircuit: your time/ timezone is wrong.
18:29 < gmaxwell> phantomcircuit: on the node reporting that.
18:29 < warren> sipa: I suppose the build-to-old-glibc goal really isn't that important.
18:29 < gmaxwell> it means you've got a block with a timestamp >2 hours in the future.
18:30 < phantomcircuit> gmaxwell, yeah i just fixed it
18:30 < phantomcircuit> it's weird that it stops the initial sync though
18:35 < Luke-Jr> [23:22:24] <warren> cfields: too much of a headache.  <one hour later> done <-- yeah, lol
18:35 < sipa> he clearly found some aspirin in that hour
18:36 < Luke-Jr> :D
18:53 < gavinandresen> warren solved the cross-compile-for-OSX problem?
18:54 < sipa> no, cfields did
18:54 < gavinandresen> ah, excellent!
18:55 < warren> gavinandresen: on your system where leveldb corrupts on mac, do you have time machine enabled?
18:55 < gavinandresen> warren: No, no time machine
18:55 < warren> there goes that theory
18:56 < phantomcircuit> gavinandresen, can you consistently cause a corruption?
18:56 < gavinandresen> phantomcircuit: no
18:56 < phantomcircuit> heh
18:56 < warren> some of the users can consistently reproduce it
18:56 < phantomcircuit> quick everybody run in circles
18:56 < warren> some users can't at all
18:56 < phantomcircuit> i wonder if it would be worth buying on of their computers...
19:02 < cfields> gavinandresen: you get leveldb corruption on current master?
19:03 < warren> cfields: yes, and 0.8.5 OMG3 which contains the same pathes
19:03 < warren> patches
19:03 < gavinandresen> cfields: last corruption I got was master as of about 1 Nov
19:03 < warren> cfields: the remaining corruption that users report when testing 0.8.5 OMG3 seems to happen during clean shutdown
19:03 < cfields> gavinandresen: built on which version?
19:04 < gavinandresen> cfields: I dunno, master as of 1 Nov
19:04 < cfields> gavinandresen: sorry, i meant which osx version
19:04 < gavinandresen> cfields: oh, OSX 10.7
19:04 < warren> cfields: 10.6.8 in our case
19:04 < warren> cfields: using xcode 3.2.6 (gcc, not clang)
19:05 < cfields> gavinandresen: i spent some time tracing the code last night, and really couldn't find much of anything that looks osx specific. I've started to wonder if it's a gcc vs clang thing
19:05 < cfields> hah!
19:05 < warren> cfields: the official bitcoin and litecoin releases are built on gcc
19:05 < cfields> another theory crossed off :)
19:05 < sipa> one thing maybe worth investigating is mmap vs io access to files
19:05 < sipa> iirc mmap is only used in leveldb on 64-bit platforms
19:06 < warren> the mac builds are 32bit
19:06 < sipa> ah
19:06 < gavinandresen> I was running a bitcoind compiled with clang when I got corruption
19:06 < warren> gavinandresen: 32bit or 64bit?
19:06 < phantomcircuit> personally i suspect there is an issue with the ioctl sync function
19:06 < phantomcircuit> but who really knows
19:12 < Luke-Jr> cfields: have you published any of the Mac stuff yet?
19:17 < cfields> Luke-Jr: i'm just now starting to get it packaged up. It looks about like this right now: http://www.digitalmediatree.com/library/image/12/beautiful_mind_2.JPG
19:17 < cfields> should have something presentable in a few days i'd think
19:21 < cfields> it will initially be missing some of the dmg fluff. compression, background images, drag+drop, etc. But i'll publish before tackling those in the hopes of finding some help along the way
19:27 < warren> cfields: is the plist working in your build?
19:27 < cfields> basic, not fancy
19:27 < sipa> plist?
19:28 < cfields> which is why drag+drop and background images aren't hooked up yet
19:28 < cfields> we'll have to port that stuff
19:30 < cfields> sipa: i assume he was alluding to the 'fancy' dmg generation options. customizations for how the dmg should present itself when opened
19:38 < Luke-Jr> wtf, why could callq ever segfault?
19:40 < warren> cfields: no
19:40 < warren> cfields: the context menu on the dock when you right click
19:44 < cfields> warren: hmm, no. tbh i'm not sure where that comes from?
19:46 < gavinandresen> warren: clang 64-bit.    All of the speculating "maybe it is this, maybe that, lets try putting a full-sync here" is unlikely to be productive. In my humble opinion, somebody who knows a lot about the OSX filesystem needs to instrument leveldb (maybe stream a log of operations over-the-network to a second logging system???) and either figure out how the corruption could happen theoretically or capture an actual case of corrupti
19:48 < gavinandresen> (I'm hoping somebody who knows a lot more about filesystems than I do will tell me why I'm wrong, and what actually needs to be done is to run the FroBaz Filesystem Widgetizer to catpure all low-level disk activity and analyze it with the FileWizPro doo-hickey)
19:49 < gavinandresen> (… after installing some hardware on the EIEIO hardware bus)
19:50 < cfields> gavinandresen: i was discussing with warren a bit yesterday. Seems to me it would be a reasonable first step to throw an assert() and output some useful data (like what the actual/expected read data was) in the case of a crc mismatch
19:50 < cfields> or is the read data completely unhelpful, and only the failed write is interesting you think?
19:51 < gavinandresen> dunno, haven't thought about it.
19:52 < warren> gavinandresen: I'm convinced that the wild guesses earlier (fsync blah) actually did fix things, the errors we have now are more consistent.
19:52 < gavinandresen> warren: okey dokey.  Just don't forget that we're pattern-seeking monkeys....
19:53 < cfields> warren: i just compared my linux-built dmg to mainline bitcoin-qt. They seem to have the same options/actions
19:54 < warren> cfields: great
19:54 < cfields> afaik dock handling is done in code. I'm not aware of anything to mess with in packaging
19:54 < warren> there's python scripts that fiddles with the plist stuff
19:55 < cfields> other than maybe ensuring the icon finds its way to the right place
19:55 < cfields> yea, i hacked those up to make em work in linux
19:55 < warren> ooh, I'm intersted in that
19:58 < cfields> ok
19:59 < cfields> i'm off for tonight. I've got the rest of the week to spend on this, though. And I'll get the qt updates in somewhere in there as well.
--- Log closed Wed Nov 20 00:00:39 2013