--- Log opened Sat Nov 16 00:00:52 2013
00:43 < midnightmagic> I thought he was 17.
00:44 < midnightmagic> Anyway his family was/is privileged.
00:46 < gmaxwell> I always assumed he wasn't actually that young, but it was instead just the friendly disreputability layered on to prevent people from noticing the deeper rot.
03:24 < adam3us> gmaxwell: morning: dreaming about EdDSA - i think it should work for split key etc.  djb et al have only placed restrictions on d as d is random k with  a few bits 0d.  So then d1G+d2G=dG where d1+d2=d nod n
03:25 < adam3us> gmaxwell: futher the compression of R has to be optional - you can decompress it so thats just wire compression unrelated to the sig scheme
04:30 < warren> http://www.asrock.com/news/index.asp?cat=News&ID=1765  <---- Wow.  Only a little late.
04:33 < gmaxwell> lol
04:33 < gmaxwell> Enterprise speed
04:49 < Luke-Jr> and they didn't even cut the x1 slots so you could put GPUs directly in
04:49 < Luke-Jr> FAIL
04:51 < gmaxwell> maybe it was a product intended for some other purpose... :P
04:55 < warren> Luke-Jr: if you have GPU's that close together they overheat anyway
04:55 < Luke-Jr> warren: I suppose
04:55 < Luke-Jr> gmaxwell: maybe they want BFL to offer them $ for a partnership :p
04:57 < gmaxwell> Luke-Jr: I have to admit I'm happy to see someone doing a gpu formfactor miner.
04:57 < warren> that pcie monarch card will actually use pcie for communicatoin?
04:57 < Luke-Jr> warren: barely :/
04:57 < gmaxwell> pretty easy to stick a usb controller on pcie. :P
04:57 < Luke-Jr> gmaxwell: I wish
04:57 < gmaxwell> oh is some horiffic bitbang interfac?E
04:58 < Luke-Jr> if only
04:58 < Luke-Jr> think the current USB protocol, using PCI-e memory
04:58 < Luke-Jr> if they have time, there might be an interrupt for nonce found
04:59 < warren> better nonce handling latency than serial?
04:59 < Luke-Jr> I suppose.
05:00 < gmaxwell> warren: with what luke is saying your latency advantages there will probably get lost by the protocol desyncing and other nonsense.
05:00 < warren> not to mention it being delivered maybe in 2015
05:01 < Luke-Jr> nah, I expect them to be within a month this time around
05:01 < Luke-Jr> certainly won't be a bigger screwup than SC
05:01 < gmaxwell> warren: I suspect the chips are coming from another supplier. :P
05:29 < adam3us> i guess you'd need watercooling gpu mods and not sure if you can get a case to hold 6x double height cards so then you're building  franken-miner
05:33 < gmaxwell> adam3us: I ran lots of systems like that ... case? lol. yea no, the only way to work with 6gpus on a board is either with special engineered high speed fans or to spread the things out.
05:33 < gmaxwell> e.g. http://www.bitcoinminingrigs.com/wp-content/uploads/2013/09/200-amp-3-phase-480-...-165kW.jpg
05:34 < gmaxwell> or less ambitious: http://i.imgur.com/tb124Nm.jpg
05:41  * gmaxwell is so glad to be rid of gpus
05:41  * gmaxwell hopes to never use a gpu again
05:44 < warren> direct neural port
05:46 < gmaxwell> vt100 forever!
05:59 < sipa> the information revolution will be fought on the command line
06:08 < warren> it looks like scrypt FPGA's are ramping up
06:08 < warren> hashrate is higher than ever, and litecoin was too cheap to warrant buying new GPU's for the past few months
06:31 < HM2> scrypt FPGAs....
06:31 < HM2> wasn't scrypt designed with killing FPGA and ASICs in mind?
06:31 < midnightmagic> litecoin screwed up when they chose the scrypt parameters.
06:32 < HM2> Don't they have an equivalent difficulty?
06:32 < midnightmagic> What do you mean?
06:32 < HM2> or did they just use bitmasking of the output like Bitcoin
06:32 < HM2> The difficultly should be the scrypto params, right?
06:32 < HM2> *scrypt
06:33 < gmaxwell> HM2: no because that would screw up the verifying costs
06:34 < gmaxwell> (and it's already screwed up)
06:34 < HM2> hmm
06:34 < warren> the FPGA's so far are only like 2-5x more power efficient at an incredibly high cost
06:34 < HM2> then how do they apply difficulty? if your params are fixed and difficultly just depends on a partial hash collision on the output, you haven't really addressed the issue of improving hardware
06:35 < warren> someone just approached me saying they'll pay for my attendance of the Vegas Dec 10th conference
06:35 < warren> "what's the catch?"
06:35 < warren> no response.
06:35 < gmaxwell> HM2: you're laboring under the impression that it was well thought out. It wasn't.
06:35 < HM2> warren, ask for gambling expenses
06:36 < gmaxwell> HM2: it was a "yippie! gpu proof!"
06:36 < warren> We still haven't revealed Litecoin's secret sponsor.
06:36 < warren> AMD!
06:36 < HM2> not ARM?
06:36 < petertodd> warren: lol
06:36 < HM2> We all want mining on the smartphone. Sponsored by Sanyo batteries
07:38 < adam3us> warren: you know bitshares momentum hash had the interesting design objectives: memory hard to mine, but no memory (2 or 3 hashes) to verify
07:38 < adam3us> warren: unfortunately its harder than they thoght, an their attempt is triply broken
07:39 < adam3us> warren: but maybe they knew that and built a well optimized tuned custom box to exploit the heck out of it
07:39 < gmaxwell> nah
07:39 < petertodd> they aren't that smart...
07:39 < gmaxwell> right
07:39 < gmaxwell> I'm sure they are smart in their own ways.
07:40 < petertodd> ...or if they are, they are also good actors
07:40 < adam3us> gmaxwell, petertodd: yeah bytemaster seemed to take some convincing, but i believe paid otu the $5k bounty for the first two defects
07:41 < adam3us> gmaxwell, petertodd: well they also did the classic gross miscalc of impact of slow difficulty adjust and mined 6months planned in 7days followed by emergency hard fork
07:42 < adam3us> ***adam3us chortles
07:42 < petertodd> damn
07:42 < gmaxwell> adam3us: I assume they made the mistake of making their diff update continious and then scaling back the safty non-linearly to some tiny value so they were always in the non-linear region?
07:43 < adam3us> gmaxwell: i didnt do the calc myself (7day to 6mo) but  guy who rented a ton of vsps did and seems sharp, i think they just didnt adjust for2 weeks normal params
07:43 < adam3us> gmaxwell: and it was a natural effect of their initial param being too easy
07:44 < gmaxwell> adam3us: huh, the way bitcoin works is that the adjustment is triggered on blocks not time precisely for that reason. :)
07:44 < gmaxwell> I guess they must have broken that.
07:44 < adam3us> gmaxwell: i didnt quite get the hard fork, same guy was telling me the put a manual 32x diffi increase automatically at the adjust or something instead of 4x
07:45 < adam3us> gmaxwell: i think the target was made 4x less easy on an accelerated schedule, but it wasnt enough gven the massive mining race, so they changed it to 32x, and i guess they had 5min target locks, but they were going at 15sec or something real
07:45 < gmaxwell> adam3us: bitcoin clamps the difficulty adjustment to 4x / 0.25x at retarget, prevents stranding, and still leaves you with quartic convergence. .. and its far enough off nominal you shouldn't ever really get weird incentives from the non-linearity.
07:46 < adam3us> gmaxwell: i exect that is what they adjusted from 4x to 32x in their patch, their curve was almost vertical
07:46 < adam3us> gmaxwell: so even though the adjustment happened the limit applied and prevented enogh adjustment, oving their intentionally short (1yr?) schedule forward by 6mo
07:48 < adam3us> maybe they accidentally effectively increased the number of blocks per adjust interval in the code, not sure.
07:49 < adam3us> i wasnt enough interested to try figure it out, but it was nevertheless hilarious to spectate.  i mined a few hrs on my 4.8ghz watercooled 3930k 6 core and gave the coins to the guy who asked me to look at it :)
09:30 < adam3us> Fistful_of_LTC: did patching semiOrderedMap.cpp give you an n^2 momentum speed boost?  curious how the constants work out
09:32 < Fistful_of_LTC> adam3us: i haven't figured out how
09:33 < Fistful_of_LTC> i'm actually using another client, https://github.com/Tydus/jhProtominer/blob/master/src/jhProtominer/protosharesMiner.cpp
09:33 < adam3us> Fistful_of_LTC: is it faster than ptsminer?
09:33 < Fistful_of_LTC> yes, a few times faster
09:34 < Fistful_of_LTC> what change do i need to make to patch ptsminer/this one?
09:39 < adam3us> Fistful_of_LTC: so it looks like this one lets u use up to 4GB ram.. how much do you have?
09:40 < adam3us> Fistful_of_LTC: he has the same code repeated like 5 times with the constants changed for 256,512,1024,2048,4096 (MB)
09:40 < adam3us> Fistful_of_LTC: I think cut & paste one more time, change it again in the same way as from 2048 to 4096,
09:40 < Fistful_of_LTC> 64 gb
09:41 < Fistful_of_LTC> you think there will be an even greater improvement?
09:43 < adam3us> Fistful_of_LTC: it depends on how fast it takes to fill the ram, if its less than the block time interval, then yes, 2x ram should be > 2x faster
09:44 < adam3us> Fistful_of_LTC: the only thing that seems to change is #define COLLISION_TABLE_BITS        (29)
09:48 < adam3us> Fistful_of_LTC: so just change it to 32, i think that should give you 16GB
09:51 < Fistful_of_LTC> i tried that it wouldnt compile, i'm going to try it again
10:07 < adam3us> #define COLLISION_TABLE_BITS    (32)
10:07 < adam3us> #define COLLISION_TABLE_SIZE    ((uint64)1<<COLLISION_TABLE_BITS)
10:08 < adam3us> Fistful_of_LTC: you are runnning -m4096 right? is that the fastest choice (vs -m2048 or -m1024)?
10:10 < Fistful_of_LTC> the fastest choice seems to be 512 mb actually, but i just noticed i'd been running an old version
10:11 < adam3us> Fistful_of_LTC: all cores busy?
10:13 < adam3us> Fistful_of_LTC: (if thats the case this wont work, my edit was to create -m16384)
10:14 < Fistful_of_LTC> you have it somewhere i can dl/test it?
10:15 < Fistful_of_LTC> i just have to wait for the pool to come back up
10:19 < adam3us> Fistful_of_LTC: 1sec...
11:22 < adam3us> btw an amusing zerocoin thought experiment: bitcoin already has one-use addresses (if you use them as intended).  zerocoins have fixed denomination (tke your pick.. 1btc, 0.001 btc soeone has to decide)
11:23 < adam3us> if bitcoin users used 1 coin denomination (say 0.001 btc) with strict one address it would have close to the same privacy guarantees as zercoin, because you wold never send yourself change
11:28 < gmaxwell> yep.
11:29 < gmaxwell> really if used in the right manner the gap between an actually anonymous system and bitcoin is not _that_ large.
13:08 < adam3us> musing about organizing private keys as some kind of merkle-tree, if I had Q=dG where d is the root of the tree, then Q=Q1+Q2 where Q1=d1G, Q2=d2G d=d1+d2 mod n, and so on for Q1..Qk for some number.  now say leaf nodes in this tree are worth some standardized unit, 1uBTC.  now you can combine public keys to form a new public key Q0=Q1+Q1' (from Q1 prime another users input)
13:09 < adam3us> to prove authority to sign you must show a merkle path from a public key to the root, and sign it, the depth of the path and the number of leaves you can control proves the amount you are spending
13:10 < adam3us> maybe a block can add all the public keys in it, and then all transactions in it are implicitly mixed
13:11 < adam3us> maybe even all utxo public keys can be implicitly mixed analogously
14:22 < maaku> adam3us: isn't that similar to how lamport signatures work?
14:22 < adam3us> yes kind of but with hashes
14:23 < maaku> adam3us: the problem is bitcoin doesn't use ecdsa sigs, it uses scripts (which have, among other things, ecdsa opcodes)
14:46 < adam3us> maaku: yes its a bit of a blue sky thought
14:47 < adam3us> maaku: wondering if bitcoin used a key per unit like zerocoin, what you could do, it seems that if there is a unique key per unit, there is less meaning to the linking - its meaningless to the network
14:47 < adam3us> maaku: so then i was wondering can you combine lots of keys efficiently into a signature
14:49 < adam3us> maaku: where the verifier cant tell which input signature to the whole block  (or even whole utxo) it came from
14:52 < adam3us> seems to me like you need 1 thread per hyperthread
14:52 < adam3us> eg 4 core i7, then 8 threads
14:53 < adam3us> wow m512 is quite a bit faster
14:54 < adam3us> sorry wrong window on the cores and threads
14:56 < gmaxwell> maaku: yea, I've wagged my finger at adam3us with ugly optimizations that layer violate and special case for specific cryptosystems.  but man, they can be very attractive.
14:56 < petertodd> adam3us: some of my blue-sky blockchain proposals work well with single-sized coin values too
14:57 < gmaxwell> careful that you don't dance back into the space of academic cryptography that isn't actually pratically useful due to limits like that. :)
14:57 < petertodd> gmaxwell: heh, well, if such a limit enables something else, the tradeoff may be worth it...
14:58 < adam3us> petertodd: my thought experiment started hmm maybe zerocoin is silly - its one coin size, if bitcoin had that there would be no change and no meaningful linkage from the network analysis perspective either
14:58 < petertodd> adam3us: yup, it's a good idea - basically what you are doing is making it more bandwidth efficient
14:58 < adam3us> petertodd, gmaxwell: and that seems to be true no? the only person who knows which coin set is linked is the sender & recipient, other than like timing of sending them
14:59 < petertodd> adam3us: thing is, so maybe the trade-off is less bandwidth efficient per tx, but more scalable, in which case the single-sized coin values actually has a very attractive side-effect I hadn't thought of
14:59 < adam3us> petertodd: yes so then i thought ok so going the other way can you represent a big batch of sigs extremely compactly
14:59 < gmaxwell> adam3us: it's correct. if there is no splitting, merging, or address reuse, bitcoin is an anonymous currency upto timing analysis.
15:00 < adam3us> gmaxwell: that would actually meet my idealized definition almost: that only the sender & recipient could link (via subpoena etc)
15:00 < gmaxwell> and even timing analysis is .. meh, it's not like the time someone sends to you implies you are online.
15:00 < adam3us> gmaxwell: community policing
15:00 < adam3us> gmaxwell: exactly - "good enough"
15:00 < adam3us> gmaxwell: if you're not in a hurry spray them out a bit
15:01 < gmaxwell> News at 11: Mixmaster has a purpose again!
15:01 < petertodd> heh
15:01 < gmaxwell> adam3us: but yea, this isn't lost on me, but ISTM I'd never convince anyone of it.
15:01 < gmaxwell> Even the coinjoin stuff I was yabbering about that forever but couldn't get anyone to talk about it until I had a _name_ for it (thanks Peter)
15:02 < petertodd> it's too bad we don't have a "numerical addition" signature type, so you could just make multiple SIGHASH_ANYONECANPAY | SIGHASH_ADDITIVE txin signatures and gradually combine them e.g. for donations
15:02 < adam3us> gmaxwell: bah - let the people who understand jgarzik triangle deal with that
15:02 < petertodd> gmaxwell: heh, and they never thought I'd do anything useful with that art degree...
15:02 < sipa> ISTM?
15:02 < gmaxwell> it seems to me
15:02 < adam3us> petertodd: yes the schnorr sig and it turns out bernsteins EdDSA *is* ec schnorr (thanks gmaxwell for pushing me to read it)
15:03 < adam3us> petertodd: schnorr you can add sigs and keys
15:03 < petertodd> adam3us: right, I was actually thinking of something a lot simpler!
15:05 < gmaxwell> petertodd: did you see my lament about multisig and anonymity groups?
15:05 < petertodd> gmaxwell: nope
15:05 < gmaxwell> petertodd: if we used schnorr than 2 of 2 multisig txn would be indistingushable from regular transactions.
15:05 < adam3us> gmaxwell: re layering violations - when you're out of luck, bend the rules :) we can patch it up best we can afterwards
15:05 < petertodd> gmaxwell: ah, yeah that'd be a good thing...
15:05 < gmaxwell> so the anonymity set for protocols based on them (e.g. coinswaps) would be basically all txn.
15:06 < gmaxwell> adam3us: well, of course, things snapping togeather nicely is sometimes a sign that you understand the problem space...
15:06 < petertodd> gmaxwell: the one good thing about multisig is that at least it's conceivable that what gets actually used will be a relatively small set of versions of it, 2-of-2's, 2-of-3's etc.
15:06 < adam3us> gmaxwell: i love elegance, and bitcoin has a huge amount of it
15:07 < gmaxwell> petertodd: sure sure, still, kinda sad that they're distinguishable.
15:07 < adam3us> petertodd: see also there's a leakage with multisig it tells you how many sigs there are and if its k of n or n of n, with schnorr you have no idea
15:07 < adam3us> petertodd: and it takes the space of 1 sig also
15:07 < petertodd> adam3us: yup, like a fine hyper-optimized sports car - though I feel bad for the mechanic trying to change the oil filter...
15:08 < gmaxwell> in any case, I only brought it up because while the size and flexiblity advantages were old news to me, I hadn't considered the privacy impact.
15:08 < adam3us> petertodd: it also has simple efficient blind sigs
15:08 < TD> good evening
15:09 < adam3us> petertodd: blind sig with EC DSA is not efficiently possible afaik, even with DSA blind sig is horrendous (damgard jurik homomorphic adition in n^5)
15:10 < petertodd> adam3us: I'll pretend I understood what you said :P
15:10 < petertodd> adam3us: by n^5 you mean O(n^5)?
15:10 < adam3us> TD: 'evening we re musing about blue-sky crypto, and lastly aout the wonderful things you could do with schnorr (instead of dsa) adn it turns out which i didnt realize that djb's EdDSA actually is schnorr
15:11 < TD> i haven't looked at EdDSA
15:11 < TD> it's not the same as ed25519?
15:11 < adam3us> petertodd: no i mean the calculations need to be done in a group of size n^5 where n is a like 3072 bit RSA key so like 15360 bit ops
15:11 < adam3us> TD: yes it is
15:11 < petertodd> adam3us: ah, so it's a size issue?
15:12 < adam3us> TD: i mean i always assumed without reading the paper, that it was a diff curve for DSA, but its actually a tweaked verion of EC schnorr sigs which s cool
15:12 < TD> oh
15:12 < TD> interesting
15:12 < TD> yeah i thought that too
15:12 < TD> although they're quite similar aren't they
15:12 < adam3us> petertodd: the intermediate results between the two users, the final result is a normal dsa sig
15:13 < TD> re-reading the schmorr wiki page, it's still based on discrete log and a group of prime order
15:13 < adam3us> TD: yes very, i think dsa wouldn't have existed if not for schnorr's patent (expired 2008)
15:13 < petertodd> adam3us: ah ok, so final sig size is reasonable, but the intermediate state isn't?
15:13 < adam3us> TD: but schnorr has many flexibility, security, size, advantaages
15:13 < TD> sigh. patents.
15:13 < TD> is there anything they can't screw up
15:13 < adam3us> petertodd: yes, the intermediate uses a ton of experimental rade stuff
15:13 < TD> looks like to understand schnorr i will have to learn more maths first
15:13 < adam3us> petertodd: and probably moderately cpu heavy too
15:14 < petertodd> adam3us: right - I was gonna say I think I've got a possible solution to the "data hiding" problem in my txin commitments scheme
15:14 < adam3us> TD: if you understand DSA you'll get it... just djb papers are hard to decipher look at https://en.wikipedia.org/wiki/Schnorr_signature
15:15 < petertodd> adam3us: again, trade-off bandwidth for scalability
15:15 < TD> yeah i'm reading that but i need to [re] learn the definitions of things like "set of congruence classes modulo q"
15:15 < adam3us> TD: basically the only diff is you dont need to invert k
15:15 < TD> this rings bells from a-level maths but i forgot it
15:16 < TD> ed25519 is definitely on my hard-fork wishlist
15:16 < TD> the performance improvement is immense
15:18 < petertodd> adam3us: basically, remember how I was talking about "sharding" the txin space in the scheme with a binary tree? you could make the mining protocol be such that there's a way to force a lower part of the tree to either be revealed, or that part of the chain would backtrack. *If* the data is actually available, the chain shouldn't backtrack, so it's still secure. If on the other hand the data isn't, well, that was the txout owners ...
15:18 < petertodd> ... responsibility so tough luck. :)
15:18 < petertodd> adam3us: Not exactly a fully-fleshed out idea, but the approach could work.
15:19 < sipa> TD: i haven't benchmarked, but i doubt it's more than 2* as fast as libsecp256k1
15:20 < TD> right, i haven't benchmarked either
15:20 < sipa> (it.l's fully constant time though, and has other nice properties)
15:20 < TD> and 2x is not to be sneezed at
15:21 < sipa> the question is: do computers get 2x faster in the time you need to deploy a hardfork + wallet upgrade :p
15:21 < TD> hah
15:22 < sipa> (it may be just 1.5x as well)
15:22 < TD> well, i dunno. every time i think intel can't push things any further, they find a way to squeeze a bit more out
15:22 < petertodd> sipa: depends if you do it now or in fifteen years after moores law's good and dead
15:22 < TD> but 2x is a big improvement
15:22 < sipa> anyway, meaningless discussion without numbers
15:22 < TD> yeah
15:22 < TD> true
15:22 < TD> it might be 11x. then we could take it to 11
15:23 < petertodd> TD: or 1.1x, and we'd need our glasses off to take it to 11
15:23 < sipa> accorsing to the webaite, it needs (iirc) 260k cycles for a verification
15:23 < TD> for which impl? there is a C one and an asm one, right
15:23 < sipa> asm
15:23 < sipa> the c one is ridiculously slow
15:24 < sipa> as in 10x slower than openssl ecdsa
15:24 < TD> ah
15:24 < TD> ok
15:24 < sipa> i think libsecp256k1 does a verification in 300k cycles on modern hardware
15:25 < sipa> but i'm sure my benchmark is on much more recent hardware than theirs
15:35 < adam3us> sipa: i think your code is probably so close based n what you said & before that for speed alone EdDSA is not worth it
15:36 < TD> petertodd: btw i didn't really grok your comment about double spends - i'm missing something, not sure what it is
15:36 < TD> petertodd: w.r.t. coinjoin
15:36  * TD didn't think about it much though, this is a tv and beer weekend
16:00 < adam3us> TD: for your beer: comparing ECDSA and ECSchnorr:
16:00 < adam3us> ECDSA: R=kG, r=R.x, s=(H(m)+rd)/k, Q=dG verify: sR=?H(m)G+rQ
16:00 < adam3us> ECS:       R=kG, r=R.x, s=k+H(r,m)d,     Q=dG verify: sG=?R+H(r,m)Q
16:00 < TD> petertodd: you mean this don't you: https://bitcointalk.org/index.php?topic=300809.msg3227294#msg3227294
16:00 < TD> petertodd: i guess i had not envisioned people making payments directly from a coinjoin. i am not sure that's a great idea
16:00 < adam3us> TD: very similar, except no /k part which is unknown so bollocks everything up in any kind of 2 of 2 or k of n
16:01 < TD> ok
16:01 < TD> thanks
17:03 < adam3us> btw more schnorr fun if you call c=H(r,m) from above, then send sig as c,s instead of r,s the verify is c=?H([sG-cQ].x,m) which is the same, as R=sG-cQ, but then you can use a 128-bit (truncated hash) so the sig is 48byte vs 64byte HOWEVER its actually a spurious claim by Schnorr (and most people since) because they assume the attacker cant chose R.  Well what if the attacker IS the signer.  doh.  academics...
17:10 < maaku> anyone have technical details for this : https://twitter.com/matthew_d_green/status/401798811070107648
17:12 < adam3us> maaku: no seems nothing on the zerocoin.org site
17:13 < gmaxwell> maaku: I know things about it, but I don't know if it would be polite to comment.
17:15 < adam3us> unless i'm missing something ZC is still stupidly expensive even if they got the proof down to 10kB per coin, because for anonymity all the coins are the same denomination imagine paying $1000 in .01c increments
17:19 < gmaxwell> In any case, when the paper is public I'll make sure to update everyone here on it.
17:19 < gmaxwell> for now I refer to my initial ZC comments: "On the plus side— approaches can only get better."
17:19 < maaku> adam3us: have multiple mint series, with different denominations
17:20 < adam3us> maaku: indeed, but then the anonymity set drops, and you can trace amounts
17:20 < adam3us> maaku: so then it ends up being maybe no better than bitcoin as is practically
17:21 < maaku> adam3us: with a handful of standard denominations, there's no reason you can't still have a sufficiently large anonymity set
17:22 < maaku> the killer limitation of ZC is the super-long verficaiton times
17:22 < adam3us> maaku: yes it can help, something reasonably pragmatic could be done
17:22 < maaku> i've found pragmatic solutions for everything else
17:22 < maaku> but requiring 1-2s per coin redemption is orders-of-magnitude unacceptable
17:23 < adam3us> maaku: their problem is the cut & chose in their ZKP, if they could find a way to get a direct ZKP it might be  different story
17:24 < adam3us> maaku: you know even to create a coin takes 1sec because it must look like c=g^x*h^s mod p and c must also be prime
17:24 < adam3us> maaku: at least when i tried it myself using openssl (before they had the code out)
17:24 < maaku> adam3us: i don't care if it takes 1hr to create a coin
17:24 < maaku> so long as it takes milliseconds for nodes on the network to validate
17:24 < adam3us> maaku: you might if you had to use it much, but yes that is the least worrying part
17:25 < maaku> well yeah, i do care (ideally it should all be fast)
17:25 < adam3us> maaku: if nly there was a way to have the validation work be part of the PoW :)
17:25 < maaku> but if you had to choose..
17:25 < adam3us> maaku: agreed
17:26 < adam3us> maaku: also the trap door in the accumulator is kind of scary
17:26 < adam3us> maaku: if someone keeps that they can print coins at will
17:26 < maaku> adam3us: that is trouble
17:27 < gmaxwell> well you can engineer around that a little bit: e.g. you can make sure that no more comes out than went in.
17:27 < gmaxwell> so at worst an accumulator break is you steal all its coins, not inflation.
17:33 < adam3us> gmaxwell: well if there are a lot of hoarded coins might not be much consolaton
17:49 < adam3us> gmaxwell, maaku: the accumulator is fixed size, you cant tell how many coins are left in it, all you see is the spent ones serial numbers and a zkp that they are in the accumulator, so i think the limit is if you saw more coins come out of it than went in
18:55 < warren> gmaxwell: why isn't mastercoin threads moved to the alt forum like other alt coins?
19:14 < sipa> if only it was an altcoin :)
19:16 < warren> wow.  jdillon seems to have been completely pwned.
19:16 < warren> bitcointalk and GPG key cracked.
19:20 < Luke-Jr> sipa: it isn't?
19:48 < adam3us> nasty business eh - hacking people's emails
19:54 < warren> adam3us: seems he was totally pwned, far more than e-mail
19:54 < adam3us> warren: hope he didnt lose bitcoins
19:55 < warren> adam3us: given his GPG key was compromised, only way he wouldn't totally lose bitcoins would be offline wallets.
19:55 < adam3us> yes
19:56 < Luke-Jr> brain hacking?
19:56 < adam3us> warren: if he was a windows user (or even linux) he'd be nuts to keep btc on an onine puter
19:56 < Luke-Jr> adam3us: why?
19:57 < Luke-Jr> you don't have a hot wallet?
19:59 < adam3us> Luke-Jr: amory offline i think is the way to go, it even worries me about the usb bad bios!
20:17 < warren> https://bitcointalk.org/index.php?topic=319465.msg3607494#msg3607494
20:17 < warren> this is a bit concerning
20:19 < Emcy> wuts btc-ethz
20:29 < maaku> Swiss Federal Institute of Technology
20:29 < maaku> http://whois.domaintools.com/129.132.230.0
20:30 < warren> https://bitcointalk.org/index.php?topic=319465.msg3607734#msg3607734   This isn't without problems, but I think this would help to protect the entire network.
20:30 < maaku> maybe sipa can kindly go tell them to stop?
20:30 < petertodd> adam3us: he lost some: https://blockchain.info/address/1BDSZMaUvrbTjWsSgLA4XqYUK4dDzxREEV
20:31 < petertodd> People have tried to use webbugs on bitcointalk and on the foundation forums lately in discussion related to coin taint; obviously some people are taking ugly actions.
20:33 < petertodd> that 5.11BTC was a private key that it looks like he sent to gmaxwell for the CoinJoin bounty :(
20:34 < warren> why did he give a private key instead of sending it he normal way?
20:35 < petertodd> warren: guess he wanted to make sure coin tracking wouldn't help?
20:36 < warren> coin tracking indeed didn't help in this case.
20:37 < maaku> warren: any link do details on how this happened?
20:37 < warren> maaku: no idea.  just everything he has seems to be pwned.
20:37 < petertodd> maaku: we're not going to know unless he tells us, and with his PGP key compromised we're not going to know it's actually him :/
20:38 < warren> petertodd: I at least don't suspect you are jdillon anymore.
20:39 < petertodd> warren: gee, makes me feel so much better...
20:39 < warren> (sorry, bad joke)
20:39 < petertodd> heh, I know
20:40 < petertodd> seriously maybe one good thing to come out of this would be for people to take security more seriously, but, damn...
20:41 < maaku> until there is a trivial to use, secure by default setup that prevents these sorts of things, our work is not done
20:42 < petertodd> maaku: agreed
20:42 < warren> maaku: setup of what?  his entire OS was owned
20:42 < petertodd> though I always got the impression that john was a very careful and clueful guy, which just shows how hard this all is
20:42 < maaku> warren: well, his keys could have been on a TPM or hardware wallet
20:43 < petertodd> maaku: if he was smart, he took gmaxwell's advice and was doing his browsing in an isolated VM
20:46 < warren> petertodd: webbugs, where?
20:50 < petertodd> warren: http://i.imgur.com/EnHNE4k.png
20:52 < warren> petertodd: hmm, I've received localbitcoins phishing e-mail recently
20:52 < warren> they went to (do not click) llocalbitcoins.com/accounts/login
20:53 < petertodd> sheesh
21:00 < Emcy> shame about jdillon
21:01 < Emcy> how do you bootstrap a new identity when you get pwnt that hard
21:02 < petertodd> yeah, I dunno, timestamp a key in advance is the only option. downside of pseudonyms
21:03 < Emcy> no one knows him irl
21:04 < petertodd> yup, early on he offered to meet me at the conference, and my advise to him was don't if he does want to keep his IRL identity separate
21:39 < Emcy> his heart seems to be in the right place wrt bitcoin......
21:39 < Emcy> i hope he can get back somehow
21:40 < petertodd> i dunno, if I had a family to think about and that happened, I'd think very hard about quiting :(
21:42 < Emcy> what has he really got to be afraid of
21:43 < Emcy> its a step from i hacked u lul to ill kill youre family
21:43 < petertodd> Emcy: he told me he works in intelligence...
21:43 < Emcy> oh
21:43 < Emcy> US?
21:43 < petertodd> Emcy: dunno
21:44 < petertodd> Emcy: https://bitcointalk.org/index.php?topic=335658.msg3607994#msg3607994
21:44 < Emcy> maybe hes done then
21:45 < maaku> hell i would be too
21:45 < petertodd> fuck, worst-case is he just committed suicide by two gunshots to the back of the head...
21:46 < Emcy> how macabre
21:46 < Emcy> when you said web bugs, you meant nasty payloads embedded in sites right
21:47 < Emcy> dillon always seemed pretty damn clued up
21:47 < petertodd> Emcy: links to images embedded in comments - gives up the ip addresses of everyone who views the comment
21:47 < Emcy> but we do know now that if a (US at least) agency wants your computer you cant stop it
21:48 < Emcy> perhaps the forum should disable hotlinking
21:48 < petertodd> Emcy: yeah, I thought at first he was the alt of someone in the community, but that's kinda presumptuous to think there aren't smart people out there who understand bitcoin well
21:48 < petertodd> the forums really should
21:52 < Emcy> so it seems proponents of blacklisting and stuff are playing dirty
21:53 < Emcy> petertodd based on what he said there, i doubt hes coming back ever
21:55 < petertodd> maybe... i dunno, this is either some misguided hacker who has no understanding of politics - don't make martyrs out of people - or it's some scary spook shit meant to scare off employees from leaking anything/having political opinions
21:55 < petertodd> I hope it's the former, for his sake.
21:56 < Emcy> yes
21:56 < petertodd> if it's the latter, hopefully it means that Tor works and his employers still don't know who he is, so figured a warning was the best they could do.
21:56 < petertodd> or it's something else entirely
21:58 < Emcy> he could have done a dead drop of another pgp key for you at the conf, incase something like this happened
21:58 < Emcy> in the toilet maybe........
22:00 < petertodd> nah, bitcoin timestamp a message in advance is the obvious thing to do
22:01 < Emcy> oh right yeah thats perfect
22:01 < phantomcircuit> petertodd, what kind of silly person allow javascript on bitcointalk
22:02 < Emcy> if anything this shit demonstrates why privacy is important
22:02 < Emcy> also the lartyr thing
22:02 < Emcy> martyr
22:02 < petertodd> Emcy: agreed
22:02 < Emcy> babbys first politics
22:02 < phantomcircuit> petertodd, this is why i mostly chat with OTR
22:03 < Emcy> like how the republicans shut down your govt in a tantrum over obama health lol
22:03 < petertodd> phantomcircuit: yeah, that we use IRC for everything is not good
22:03 < phantomcircuit> unfortunately jabber which is the easier to use otr with is a mess
22:04 < phantomcircuit> and running our own irc server is well
22:04 < phantomcircuit> nothx
22:04 < petertodd> I mainly use ChatSecure on android for OTR
22:05 < warren> OTR for IRC seems unusable
22:06 < petertodd> works well on irssi, at least for me
22:06 < Emcy> hmm are freenodes interserver links encrypted even
22:06 < Emcy> or m/any of the other big networks
22:07 < petertodd> Emcy: dunno
22:11 < phantomcircuit> Emcy, i doubt it
22:15 < theymos> I hear there are concerns about forum security?
22:16 < warren> gmaxwell: hey, are you interested in being part of a group who defines the formal requirements for the next generation forum?
22:16 < warren> gmaxwell: including the things we discussed earlier
22:16 < petertodd> theymos: you see how jdillon was compromised?
22:17 < petertodd> theymos: probably not related, but I mentioned how twice people have tried to put web-bugs in forum messages on -talk and the foundation forum
22:17 < warren> theymos: it's hard to know for certain exactly what vector he fell to
22:19 < Emcy> if that leak was meant to reveal some sort of ulterior motives from you and john, it failed imo.
22:19 < theymos> I just read about that a few minutes ago. That's what caused me to come on IRC. Seems interesting.
22:20 < Emcy> its more like people do things in private related to what they also do in public, welcome to earth
22:20 < petertodd> Emcy: thanks, though the reddit discussion especially is remarkable at missing the point
22:20 < theymos> It seems that he was not compromised via the forum, as his GPG and email were also compromised.
22:20 < warren> It seems everyone in those communications clearly wants to protect Bitcoin.
22:20 < theymos> Web bugs in PMs are known and common.
22:21 < warren> looks like some of those copied leaked messages were PM's
22:21 < warren> others were GPG mail
22:21 < petertodd> theymos: yeah, I doubt a webbug would have done anything other than give a tor exit server ip address in this case...
22:21 < warren> Emcy: yeah, I don't know what agenda was meant in leaking that.
22:22 < Emcy> petertodd in fact it only really strengthens your position of wanting the technical side of bitcoin to remain true to its founding principles
22:22 < Emcy> not something that was exactly a secret with you or others mentioned there
22:23 < warren> Emcy: well, I spelled out the regular practice of hiding security/dos fixes in commits that don't mention it ...
22:23 < Emcy> theymos disable HTML on the forum man
22:23 < Emcy> or the parts of BBS markup that allow hotlinking and stuff
22:23 < warren> theymos: yeah, forum should be telnet only
22:23 < petertodd> warren: what if my modem has a zero-day?
22:24 < Emcy> lol i meant forum markup with the []
22:24 < theymos> petertodd: Yes, he was using Tor.
22:24 < petertodd> Reasonable compromise with hotlinking would be to filter to, say, imgur-only
22:25 < Emcy> petertodd if it was his agency trying to get him, thats not enough
22:25 < petertodd> You know, one plausible vector is github of course...
22:25 < theymos> I was thinking recently of using http://images.weserv.nl/ , but I haven't had time to do it.
22:26 < petertodd> Emcy: I'll say - could be any number of browser zerodays
22:27 < Emcy> how did firefox react to all that......they were specifically targetted too i think, according to the leaks
22:27 < warren> Emcy: that was an old version of firefox
22:27 < Emcy> youd expect it from the likes of IE
22:27 < Emcy> how old
22:28 < petertodd> Emcy: I mean, hell, this is a guy who I think was sticking to a fixed posting schedule for anti-timing analysis... heck, I'd joked to warren before that he was probably scheduling his vacations to correspond with mine to throw people off.
22:28 < Emcy> could be true.......
22:29 < Emcy> the bloom thing has since been publicly dealth with right? I think i remeber something
22:29 < warren> petertodd: oh.  I'm guessing the "leak" is the bitcoin foundation communications that were posted in public.
22:29 < petertodd> if I were trying to keep a my IRL identity anonymous I'd use IRC chat logs and only post when some well-known community member did...
22:30 < warren> Emcy: the bloom thing is not much of a secret anymore
22:30 < petertodd> warren: yeah. it did leak that I was the one who sent him mike's post in the first place
22:30 < Emcy> irc chat logs/
22:30 < petertodd> Emcy: there's been some fixes that make it a fair bit harder to exploit - far from perfect, but it's a good step that gives us time
22:30 < Emcy> ?
22:30 < warren> Bitcoin Foundation forums is not much of a secret.  it costs what $40 to be able to read it?
22:31 < Emcy> yeah i dont know why they dont just make that read only for non members. all the good stuff gets out any way
22:31 < Emcy> plus the foundation has a bit of an air of exclusivity to dispell, if it cares to
22:31 < petertodd> Emcy: with anti-timing analysis, you want to make sure someone can't try to match up your IRL schedule to when you post things with your pseudonym. So, use IRC logs to delibrately match the schedule of *someone else* to throw any investigators off the trail.
22:31 < Emcy> right yes
22:31 < petertodd> Emcy: I noticed a while back he'd almost only ever been posting on sundays too...
22:31 < Emcy> so someone else gets black bagged and not you lol
22:32 < petertodd> Emcy: yup
22:32 < Emcy> In addition to what I said earlier, I mentioned your status to a friend
22:32 < Emcy> of mine who is a former spook and well aware of the dangers of the
22:32 < Emcy> business to anyone with a sense of ethics.
22:32 < Emcy> ^saddest passage in there imo
22:33 < petertodd> Emcy: the fact that the people I know IRL who tend to be strongest in support of snowden have been from intelligence/military backgrounds really says something
22:34 < Emcy> kind of puts paid to the shitty assertion that if people really cared, theyd put on a suit and change the system from the inside
22:34 < Emcy> it jsut doesnt work like that
22:34 < petertodd> fuck no
22:34 < petertodd> well... they get into the system, and use that access to leak...
22:34 < Emcy> i heard it stated lots as a glib dismissal of the whole occupy thing.......annoyed me
22:35 < petertodd> yeah
22:36 < Emcy> (what occupy apparently was in the beginning i mean, before being sybil attacked by hippies)
22:36 < petertodd> though snowden really made it clear to people how rotten things were - these organizations can be reasonably good at compartmentalizing stuff, so you don't necessarily know that stuff is going on
22:36 < petertodd> Emcy: "sybil attacked by hippies" <- brilliant
22:36 < Emcy> heh, thats what i saw from the streams and such
22:37 < Emcy> and when they started segregating men and women in the camps
22:37 < Emcy> nope to that
22:37 < Emcy> men from women more accurately
22:37 < Emcy> anyway
22:38 < Emcy> petertodd snowden walked out with a ton of shit - if they have compartmentalisation theyre not using it properly
22:38 < Emcy> same as the reams of stuff manning got off the sipernet
22:38 < petertodd> Emcy: yes, but he was a sysadmin, and he had to use social engineering to get a lot of that data too
22:38 < warren> the media reported that he used authentication of other people to get more data
22:39 < petertodd> Emcy: if you're an average employee playing by the rules you're still compartmentalized
22:39 < Emcy> social engineering definitely counts on your overall security makeup
22:39 < Emcy> so
22:39 < Emcy> id give them a D-
22:39 < phantomcircuit> Emcy, nothing is truly compartmentalized
22:39 < phantomcircuit> anybody can lookup anything
22:39 < phantomcircuit> but everything is audited
22:39 < phantomcircuit> you look up something you shouldn't have
22:39 < phantomcircuit> go to jail
22:39 < phantomcircuit> right?
22:39 < Emcy> well nothing can be, or you dont have a functioning organisation
22:40 < phantomcircuit> except no because he's in russia
22:40 < Emcy> assange was supposed to be a total freak about compartmentalisation
22:40 < phantomcircuit> Emcy, if all the intelligence was actually compartmentalized it would be worthless
22:40 < Emcy> to the point where lots of people left wikileaks...
22:40 < petertodd> phantomcircuit: yeah, and if you don't already know about something, it's hard to know what you are supposed to be searching for... making it even more likely that the auditing will catch you
22:40 < phantomcircuit> petertodd, yup
22:41 < phantomcircuit> im guessing he was basically looking at stuff using other peoples credentials
22:41 < phantomcircuit> and they couldn't figure out what was going on until it was too late
22:41 < phantomcircuit> or maybe he really did just pull it all in at once and left for hong kong
22:41 < petertodd> yup
22:41 < petertodd> he was pretty lucky to pull that off
22:41 < Emcy> he said in that interview he just came accross these examples of casual disregard for the constitution in the course of his job
22:41 < Emcy> and that piqued his interest
22:42 < Emcy> thats how it starts, people dont go into these orgs looking to rock the boat
22:42 < phantomcircuit> Emcy, sounds about right
22:42 < Emcy> the ones with ethics change gradually, the ones without keep pulling the levers
22:43 < Emcy> similar story with manning
22:43 < petertodd> yeah, I get the sense that it's easy for people to rationalize their actions. and heck, if you don't see evidence of abuse, it's easy to figure that "well, my organization is behaving responsibly, and we really do have enemies"
22:43 < Emcy> petertodd you dont know how strong diffusion of responsibility is
22:43 < Emcy> it lefs people step literally over people dying in the street
22:44 < petertodd> Emcy: indeed
22:44 < Emcy> i have become interested again recently in the inherent cognitive defects of humans
22:45 < Emcy> to which of course i am subject as much as anyone else, if not more of course.
22:46 < phantomcircuit> Emcy, that's less of a cognitive defect and more of an evolutionary advantage
22:46 < phantomcircuit> but yeah still
22:46 < Emcy> the study about how people mental arithmetic *on an unrelated maths problem* actually gets measurably worse after being shown statistical evidence which contradicts one of thier political beliefs
22:46 < Emcy> that fascinated the shit out of me
22:47 < petertodd> phantomcircuit: an advantage in the small-group societies that we evolved in
22:47 < Emcy> phantomcircuit depends whether you think we should be bound to baser behaviours gained from our old evolutionary road, or try and be better
22:48 < phantomcircuit> Emcy, sure but it's not really a defect
22:48 < Emcy> were supposed to be sentient and sapient, we could choose not to be such slaves to instincts. But its harder work.
22:49 < phantomcircuit> it's merely a cold fact of survival that is probably not necessary anymore in relatively wealthy countries
22:49 < phantomcircuit> (im not so sure about developing countries)
22:49 < Emcy> evolutionary advantage becomes disadvantage and vice versa
22:49 < Emcy> we just havent caught up yet
22:50 < Emcy> saying that i dont think "tribes" of tens of millions is doing up much good either
22:56 < Emcy> oh wow i guess they took that 5.1btc too if they got all his pgp keys
22:56 < Emcy> nice political statement asshats, if that was the intention
--- Log closed Sun Nov 17 00:00:01 2013