00:00:38 gmaxwell: ah I see what you mean, that works 00:02:07 petertodd: cool, i joined you 00:02:24 andytoshi: cool, so I sign when the tx closes right? 00:02:42 yeah, if the window is open it should play a chime 00:02:47 in 5 minutes 00:04:00 andytoshi: a nice feature would be to list not just popular output values, but also combinations of input values that you might want to match 00:04:11 in future, it will not use donations in computing the popular outputs 00:04:17 andytoshi: though obviously that gets complex :) 00:04:17 petertodd: yeah, agreed, the devil is in the details 00:04:42 andytoshi, that's cool 00:04:57 gmaxwell suggested just showing all the output values which appear at least twice 00:05:08 or an arbitrary one, if none do 00:05:49 you could also use a second transaction to further split outputs 00:06:24 hmmm, although if not careful, that can leak information 00:06:47 andytoshi: "The current session is open for -0 more minutes." 00:06:52 The current session is open for -0 more minutes. 00:07:02 petertodd: lol, it won't go actually negative 00:07:06 agreed, i should fix that bug 00:08:05 andytoshi: signed and submitted 00:08:25 you could have all inputs be the same value, then have each submitter send a change output 00:08:28 cool, one sec, i'll just verify 00:09:05 participants could create specifically denominated outputs beforehand 00:09:13 to use as inputs in this transaction 00:09:18 i submitted too, in a minute it should give us a txid 00:09:52 CodeShark: also a good idea 00:10:12 it's hard to say what would be best, and all the ideas proposed involve a lot of work ;) 00:11:48 andytoshi: fee is a bit low 00:12:03 andytoshi: off by one digit 00:12:12 really? 00:12:15 requiring specifically denominated outputs should be easy to implement from your perspective - you just need to have multiple "rooms" for different denominations, ensure the inputs are the same value. you do need a txindexed database to query against to get input values, though 00:12:24 err, specifically denominated inputs 00:13:38 petertodd: the code uses 1500 satoshi / kb 00:13:42 andytoshi: it's 688 bytes, so the fee should be at least 0.0000688 BTC 00:14:16 oh, i am off by a power of ten 00:14:18 shit 00:14:20 heh 00:14:54 the 0.1 room, the 1.0 room, the 10.0 room, etc.. :) 00:15:19 really 00:15:26 ? 15000 seems wrong 00:15:34 10000* 00:15:54 you might also want to charge the fee proportional to the number of bytes contributed 00:16:02 for each participant 00:16:19 you don't know the bytes in advance, alas. 00:16:28 well, you don't know the signatures 00:16:32 though you can compute a conservative estimate but it makes it hard to use. 00:16:35 andytoshi: int64 CTransaction::nMinRelayTxFee = 10000 00:16:37 CodeShark: which is almost all the bytes. 00:16:42 i'm already using a conservative estimate 00:16:45 andytoshi: 15000 is a good value 00:16:48 but you can estimate the signature size 00:16:54 ok, that's what i'm going to use then 00:17:00 i'll have to jack up the minimum donation 00:17:39 andytoshi: I wouldn't worry about maybe too high fees myself 00:18:09 ok, so the site now demands 10000 satoshi from each participant 00:18:23 from that, it submits 15000/kb to network fees, and keeps the rest (if any) 00:18:39 andytoshi: heck, scriptSigs are limited to 520 bytes or something IsStandard - that's not that much more than the usual scriptSig size, so just assuming that with absolute min fees wouldn't be a big deal 00:18:56 another way to deal with the fee calculation is have each participant specify a change output - then you calculate fees on your end and set the value accordingly 00:20:25 as a convention, for instance, the first output of the transaction can always be treated as the change output 00:20:27 or the last 00:20:41 CodeShark: i don't think that much complexity is needed 00:20:42 of course, you should shuffle it on your end before signing is done 00:20:55 point is you could set the fees yourself 00:20:58 yes, there is shuffling done 00:21:04 without requiring the participants to calculate the fee 00:21:17 makes it easier to use :) 00:21:38 CodeShark: if they want ease of use they can just send a ton to the donation address ;) 00:21:45 lol 00:22:06 petertodd: should i fix our transaction and try to resubmit it? my node has not seen it yet for example 00:22:13 i'd have to pm you for a new signature 00:22:15 andytoshi: sure 00:22:55 andytoshi: or fix the site and I'll just do another join 00:23:50 the site is fixed, but it won't let you put the same inputs in 00:23:57 ah 00:24:13 yeah, quite frustrating 00:24:16 gimme a couple minutes.. 00:30:28 just started a fresh tx if anyone wants to join 00:31:26 pretty high minfee now. 00:32:17 gmaxwell: low compared to the value of my time :P 00:33:52 yea, its not bad. 00:34:12 sorry, i can't join, all my money is in the one i just did with petertodd :P 00:34:43 andytoshi: ha 00:39:31 andytoshi: heh one lame thing with the rotation is that if you only get one other player the timer really doesn't have time to go solicit more. 00:40:41 yeah, my original plan was to make it be open for 24 or 48 hours 00:41:37 thats so long people will lose attention though. 00:41:51 i joined this one with a small 0.008 input and spent it all to the donation address.. 00:42:06 gmaxwell: yeah, it's a tough balance 00:42:10 hah. I guess thats something you have the ability to do! :P 00:42:25 easier if in the future there is a autosigner. 00:42:27 :P i am actually doing the spent-through-coinjoin trick we talk about 00:48:34 andytoshi: the sound thing works, no color change? :P 00:49:20 I feel like window 3.1 encountered an error. 00:50:16 ehehe 00:51:09 andytoshi: looks good this time 00:51:48 andytoshi: dunno why it says "this transation has a non-standard input" on bc.i though 00:52:47 it does? 00:52:57 gmaxwell: https://blockchain.info/tx/33854f625c90e3287eae951103489a2449f91bfe039aa4d4c810bd66450edbf1 00:54:22 someone could run a bot that constantly submits transactions at specific demoninations for inputs with random outputs 00:54:31 so that there are always enough "participants" :) 00:54:49 CodeShark: the bot to run is one that matches other peoples outputs and/or input combinations on demand 00:54:57 right :) 00:55:24 petertodd: doesn't say that for me. 00:55:46 so you could specify a minimum number of participants and a maximum amount of time to wait - if in that time, the number of participants is below what you asked for, a bot fills in the rest 00:55:46 gmaxwell: the little triangle thing in "estimated confirmation time" 00:56:44 what is a "_none_ standard input" 00:56:57 beats me 00:57:21 you'd want the bot to fill each of the remaining slots using a separate wallet 00:57:23 isn't the fee a bit high? 00:57:37 no, 1.5x minimum 00:57:44 got it. 01:15:42 petertodd: it seems to me that pond could be combined with bitmessage ... where bitmessage was used for small messages and notifications that you had messages waiting ... so that it didn't have to constantly poll. 01:16:13 the polling probably makes parties substantially more vulnerable to traffic analysis should their pond server be compromised. 01:16:45 gmaxwell: makes sense, better bandwidth utilization too 01:17:36 gmaxwell: wasnt pond supposed to be constant-bandwidth? 01:17:42 what's this pond thing now? 01:17:45 or am I thinking of a different one? 01:17:53 nsh: https://pond.imperialviolet.org 01:17:55 ty 01:18:44 BlueMatt: it doesn't appear to be but if it is that still doesn't prevent traffic analysis. E.g. if your pond server is compromised it still knows when you (by your group ID) poll. and the fact that you keep polling over and over and over again (10 minutes appears to be the default) makes tracing the tor a lot easier. 01:19:26 petertodd: depends on usage patterns. ... you'd have to have a very high number of users who never had any traffic then perhaps a flooding network for you-have-new-messages may well indeed be more efficient. Certantly pond for large objects is way more efficient than bitmessage. 01:19:38 well, yes, if your server is compromised, but at least thats stronger than if the encrypted links to your server are compromised 01:20:31 pond also doesn't seem to have any real way of handling "your server got taken down" that I can see, it looks like you have to start a totally new identity and rebuild your contacts? 01:24:05 are there any actually good products for having secure group messaging today? 01:24:17 gmaxwell: that chime is actually me on the piano 01:24:24 BlueMatt: oh, interesting bugs in bloom FWIW 01:24:24 i was quite sad to discover it was the win3.1 chime :P 01:25:18 BlueMatt: define "secure" and "group" :P 01:25:20 you should sure microsoft for retroactively stealing your chimetulectual property 01:25:23 petertodd: oh? 01:25:24 *sue 01:25:44 BlueMatt: I mean, what you were telling me - I need to think about that stuff some more 01:26:01 petertodd: oh, yes 01:26:09 its possible to fix, but not in a clean way afaict 01:26:38 * BlueMatt fucked it up...suppose thats what I get for running out of time and just trying to get it done... 01:26:52 could coinjoin be defeated by someone who inserts the vast majority of requests? 01:27:11 you join a transaction, think there are 10 participants, when actually 9 of them are an attacker 01:27:13 petertodd: secure: otr-like security, group: >= 3 technically-minded people 01:27:16 BlueMatt: yeah, good example of how important analysis is up front :( 01:27:56 BlueMatt: right, where the group can trust each other not to leak 01:28:28 petertodd: well, I did analyse it, and had a good design....then it needed tweaking to make it more useable, but I was out of time, so I tweaked it until it worked 01:28:39 now I realize I tweaked it until it broke...but it works 01:28:58 BlueMatt: do you have that original analysis written up somewhere? good starting point for fixing it 01:29:13 writeup? noooo 01:29:23 BlueMatt: stained napkin? 01:29:33 stained braincells, sure 01:30:37 anyway, my brief thoughts over the past two days dont indicate any clear way of keeping the "efficiency" (ie not making it worse than it already is for serving nodes) while improving the privacy 01:30:48 andytoshi: where is the actual url to your chime? 01:31:13 * nsh is starting to think computers should not ever have access to plaintext 01:31:41 that decoding of anything into human-comprehensible form should only be done by an input-only device you wear as glasses or something 01:31:51 homomorphic encryption? :) 01:32:11 aye, it's at least a weekend project :) 01:32:20 BlueMatt: figures 01:32:38 BlueMatt: I think it's just a fundemental problem where it's a tradeoff between efficiency and anonymity set size 01:33:12 BlueMatt: I'm actually thinking we might be better off with this stealth address idea/reinvention of mine and just using a fixed % of all addresses as your anonymity set 01:33:28 petertodd: no, I mean its very possible to get that tradeoff decent, you just have to do something like make the server Hash256^2 all elements tested against the filter as well as the element itself 01:33:47 or push the hash160 of the pubkey onto the scriptSig as an extra element 01:34:01 s/Hash256^2/hash160/ 01:34:40 you can get verry good download speeds with a fp rate of like 0.005% or so, which gives you a pretty big anonymity set 01:34:43 or even 0.01% 01:34:55 hell, a desktop does fine higher than that 01:35:06 andytoshi: interesting, I did a tx where I was all parties, and sent it on my own node, and it just said "invalidated" 01:35:53 should have you a litecoinj as a christmas present... 01:35:56 BlueMatt: maybe we're thinking of different things; I'm more talking about a perfect bloom filter with optimal behavior 01:35:57 ehhh, damn missing /msg 01:36:09 BlueMatt: heh, I could go for that 01:36:24 BlueMatt: maybe a mastercoinj while we're at it 01:36:25 * petertodd ducks 01:36:29 haha 01:36:44 * BlueMatt kicks petertodd's ducking head 01:36:54 that's not very nice... 01:37:16 I mean, to bring up mastercoin :p 01:37:25 CodeShark: lol 01:37:52 petertodd: well, ok, but as far as I'm concerned, having an anonymity set of a few thousand addresses besides your own is perfectly reasonable for 99% of people 01:38:00 the rest can damn well run full nodes 01:38:17 it's not quite that simple, because there are usually several other bits of deanonymizing data available. 01:38:25 and so a set of thousands is quite often a set of 1. 01:39:27 for instance the nTweak itself can be a deanonymizer... 01:39:29 at least bloom only reveals it to your servers. 01:39:34 I dont think its nearly /that/ bad, sure you can get rid of lots of fps with some analysis, but getting it down to 1 would require as much (or far less) effort than just breaking in and stealing a computer... 01:39:46 petertodd: how? 01:39:58 BlueMatt: getting it down to a few is how you figure out which computers to go steal. :) 01:40:33 (go look at that bomb threat moron. They simply enumerated all the people on campus who had used tor near the time in question and went and intimidated them all and the guilty party confessed) 01:41:34 BlueMatt: by reusing it multiple times you have a 32-bit unique value that identifies you across multiple connections 01:41:50 petertodd: so...dont use it multiple times? 01:42:05 I don't know why you'd reuse it? 01:42:18 gmaxwell: I'm not sure we're thinking of the same threat model here... 01:43:18 the main threat model a bloom filter addresses is your upstream nodes finding out who you are 01:43:26 gmaxwell: if you don't reuse it, and someone matches multiple instances of bloom filters to you, they can AND all the addresses matched by the filters to narrow down the actual ones in your wallet 01:43:30 not the network tracking down where given addresses lie 01:43:48 petertodd: ah. point, right I knew this before. 01:44:07 gmaxwell: damned if you do, damned if you don't, unless everyone just uses the same nTweak, but then you have DoS attacks 01:44:31 gmaxwell: I mean, prefix-filtering has those DoS attacks too of course, but at least we know they're expensive 01:44:33 petertodd: this is why you dont use the same nodes multiple times (but mitm?: no, at that point you already know your target, whats the point?) 01:44:52 BlueMatt: your target can easily run a high % of the nodes on the network 01:44:56 [OT] http://www.gwern.net/Blackmail I'm amused by this both because of gwern whining about people thinking he's satoshi while he's been super agressively trying to deanonymize satoshi elsewhere, and also accusing random people of being satoshi. Also amused by the moron he's talking to who _cant_ get pgp right. 01:45:10 BlueMatt: s/target/attacker/ 01:45:38 BlueMatt: less relevant given that bitcoinj doesn't do Tor yet, but one day... 01:45:51 petertodd: yes, at this point you're fucked anyway... 01:46:00 petertodd: (note the model here is a phone who's ip changes every 10 minutes) 01:46:09 petertodd: bitcoinj /does/ do tor now 01:46:17 (on master, no support for hidden services) 01:47:07 sure, with enough nodes you can AND everything together and find results which have large intersections, but that should be very expensive 01:47:10 BlueMatt: no, I don't think you necessarily are. e.g. many scalability schemes spread the work out over multiple shards, which means a client can just subscribe to some subset 01:47:24 BlueMatt: why? running nodes is cheap - all you need is ip addresses 01:47:33 BlueMatt: they don't actually need to even be unique nodes... 01:47:45 * gmaxwell waits for one of you guys to find http://percy.sourceforge.net/ 01:48:24 gmaxwell: meh, that's the kind of thing only a wizard would understand, oh wait... 01:48:39 gmaxwell: wpsoftware.net/coinjoin/chime.wav 01:49:01 it is actually a MIDI of a c chord run through the fluid soundfont that came from fedra 01:49:03 fedora* 01:49:35 BlueMatt: with payment protocols you're doing especially well, because fixed filters (prefix or bloom) mean it's basically like a well design bitmessage: all the adversary knows is you keep on getting some consistent % of the transaction space 01:49:48 BlueMatt: they can't do any better than that to deanonymize you 01:50:50 BlueMatt: (ie, you never actually send a transaction) Handling sends can be done via special-purpose mixnets and what not too 01:50:51 petertodd: except you suggest making the data visible to everybody instead of a finite number of possibly evil servers. 01:50:54 petertodd: I didnt say it wasnt possible, I know its very possible to become some large % of network nodes 01:51:45 gmaxwell: not necessarily: remember the version where all you leak is the fact that *a* payment was made, not the details of what txout in the transaction was involved, which is doubly hidden via coinjoin 01:51:56 petertodd: I was saying that if you're a client who's ip changes regularly (ie you cant identify one client from one session to the next), then the AND attack is difficult due to the large cost of ANDing together all combinations of filters you've ever seen.... 01:52:02 s/large/impossibly large/ 01:52:44 generally the "ip changes regularly" part is quite ugly, but its realistic on many networks, especially mobile ones 01:52:48 BlueMatt: problem is IP's don't neccessarily change like that - NAT maps things to the same IP, and the clients leak a bunch of info because they give version strings 01:53:19 on android the upgrades happen at ~the same time, so version string doesnt leak much there 01:53:33 BlueMatt: sure in a perfect world the ANDs are hard, but that's a perfect world... 01:54:00 1. make perfect world 01:54:06 2. build cryptosystems 01:54:21 petertodd: agreed, there are certainly cases where its not good...my point is just that coming up with a realistic threat model where these things break down and where the attack is still realistic is pretty hard 01:54:33 BlueMatt: heh, that's in some ways worse: you probably can use update lags to start tracking down your target, although at least that's a NSA adversary 01:54:38 (if you already know who it is, just go hit them with a wrench instead...) 01:55:02 easier for an nsa adversary to just hack your baseband :p 01:55:32 and, again, anyone who's concerned about an nsa adversary probably wants an anonymity set of the whole network, not any subset thereof 01:55:33 BlueMatt: maybe... they don't like using their sophisticated exploits if they can help it 01:56:19 BlueMatt: anyway, my main point is there's a shitload of tradeoffs involved here, and there probably are good designs that we haven't considered carefully enough 01:56:39 yes, certainly 01:56:51 my point is that there are more pressing issues as what we have is ~workable 01:56:54 BlueMatt: that there isn't a master tradeoffs document outlining the thought process isn't a good sign... 01:56:59 maybe with some small tweaks 01:57:35 petertodd: lol, what in bitcoin has such a doc? 01:57:35 * nsh imagines compropedia -- the definitive interactive animated guide to trade-offs in security models 01:57:46 with sliders 01:57:48 mmmm, sliders 01:57:56 BlueMatt: well, remember that it looks like electrum will be implementing prefix filtering because of how it fits there model well, so I'd like to understand that well, and this stealth address stuff involves a similar set of considerations 01:58:16 BlueMatt: gee, I dunno: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03508.html 01:59:09 petertodd: ok, what before very recent stuff in bitcoin has master tradeoff docs like that? 01:59:45 BlueMatt: heh, fuck all 02:00:22 petertodd: :) 02:00:22 BlueMatt: I also gotta do one up for, dare I say it, mastercoin... 02:00:31 ewwwwww 02:01:07 BlueMatt: so much disgust as blank canvases, just waiting to be filled with beautiful consensus systems... 02:01:22 BlueMatt: s/as/about/ 02:01:46 petertodd: anyway, the analysis for bloom filters was largely started on an original version that looked up input scriptPubKeys (which was a bit disk expensive, surprise, surprise...) and the privacy provided vs efficiency tradeoff on the client side was really quite good 02:02:06 petertodd: yes, I would like it if it were 1:1 pegged to bitcoin and on its own merged-mined chain 02:02:09 until then, ewwwwwww 02:03:02 petertodd: if you can come up with a script type that is easily matched by one element in both the scriptPubKey of an output and the scriptSig spending that output, the bloom filter model would go back to that 02:03:03 BlueMatt: it's not going to be merge-mined unless some major advances in crypto-coin theory are made 02:03:20 and the anonymity set could be ramped up with tiny thin clients being able to handle it fine 02:03:49 (eg, push the hash160(pubkey) to the back of the scriptSig after the pubkey/sig) 02:04:30 well, ok, if you can come up with a way to do it so that you dont risk missing txn if a key is imported to a different client (or block that?) and a good upgrade path 02:04:36 petertodd: why not? 02:06:59 * BlueMatt hurtles at a runway a few hundred mph and decides to get off irc 02:07:30 BlueMatt: isn't just defining bloom v2 that matches H(element) and element simultaneously enough? 02:07:39 BlueMatt: merge-mining is insecure 02:07:44 BlueMatt: ha, have fun 02:08:04 petertodd: too expensive for servers, I think 02:08:08 needs further testing, I suppose 02:08:24 BlueMatt: why? it's just one extra hash and comaprison per element 02:08:29 petertodd: yes, a 1:1 pegged merged-mined coin can be more secure 02:08:44 there are currently 0 cryptographic hashes per element right now 02:08:44 BlueMatt: no it can't - merge-mining means the cost to attack is near zero 02:08:49 youre now making it 2 02:09:00 BlueMatt: hashes are fast... 02:09:14 BlueMatt: gurantee you disk io is a bigger problem 02:09:55 BlueMatt: also, those hashes can be cached easily and re-used for multiple clients 02:11:15 petertodd: yes, disk io is currently the problem, I'm not entirely convinced that the hashes arent also expensive if you assume nodes are only serving some small section of the chain (ie the past 1k blocks served out of memory) 02:11:30 petertodd: if you're gonna cache them on disk, you should just match both scriptSig and the scriptPubKey its spending 02:11:35 thats more general and as easily cached 02:11:45 anyway, actually landing 02:11:49 BlueMatt: heh, have fun 02:12:15 BlueMatt: That is a good point: any per block index of scriptPubKeys should have a per-block index of scriptPubKey's spent. 02:12:26 *of scriptPubKeys created 03:10:36 andytoshi: can you setup a simple http page that gives a one line coinjoin status? e.g. something we could ask nanotube to have gribble query? 03:11:10 andytoshi: e.g. the number of txn in the queue, popular output(s), time remaining. 03:12:05 sure, one moment 03:14:56 plain text? 03:16:32 nanotube: what would be useful for gribble? 03:16:54 I assume plaintext is fine, since thats what the old blockexplorer api was. 03:17:45 https://www.wpsoftware.net/coinjoin/status.php 03:18:28 when there is a transaction in there, it is pretty verbose.. 03:18:34 echo 'The current session is open for ', Session::time_to_switch(), ' more minutes. There ', 03:18:35 'are currently ', Bitcoin::unsigned_tx_count(), 'transactions in the pot. The most ', 03:18:37 'popular output value is ', Bitcoin::most_popular_output(), '.'; 03:19:17 does the way it works now have a session 'close' and open for signing? e.g. is there also a need for a status.php?id=deadbeef to find out if a past session is still in need of signatures? 03:19:48 yeah, there is a flag in the database which sets the "active" session 03:20:16 one moment.. 03:21:25 (might be useful in harassing people to finish signing in an IRC join) 03:25:58 see eg https://www.wpsoftware.net/coinjoin/status.php?session=fd1d19c88eaa675d7151a625bcb911e05d8b58e35faf51a974ba73c565ba6a63 03:26:57 andytoshi: maybe a lark you'll think is stupid. But I think it should display a "round name" from the session ID, which is converted to english using a spookwords list (e.g. http://attrition.org/misc/keywords.html ) so it tells you that "session fissionable Indigo speedbump is live in three signatures." 03:27:24 I have no idea where a good name generator is though, the link there was a random google result. 03:27:44 :P i think that'd be awesome 03:27:48 i'll look into it 03:27:53 Is there a reason alex_fun hasn't had at least a kick or warning in #bitcoin-dev yet? He seems to intentionally flaunt being off-topic :/ 03:28:16 my brainwallet uses six random words from Great Expectations, and they always come out as stories 03:28:22 in fact, i never use it as a brainwallet, just for making passwords 03:28:40 Luke-Jr: I prodded him in PM which promoted 03:28:41 19:07 < alex_fun> guys and girls whatever really , u feel rigid its u choise 03:28:56 nanotube: the source for status.php is here: http://pastebin.com/ra8NTFxA 03:29:13 nanotube: i'm happy to change the formatting however you see fit 03:30:09 andytoshi: there doesn't seem to be any good "topsecret codeword" generators though there are lots of lists of sutiable words. 03:33:34 CodeShark: the joiner I'm working on 100% p2p 03:33:46 but it's not something I'm spending a lot of time working on ... 03:34:45 I think of andy's thing as something fun that people can use right now. It's obviously not what we need long term, and (at least right now) doesn't really overlap or compete with better ways of doing it. 03:35:05 to Luke-Jr's point, alex_fun has been around for many months (years?) 03:35:30 i thought luke was yelling at ghosts, and it turned out that there was in fact some alex_fun in my /ignore list, which i'd put there so long ago i'd forgotten 03:36:06 yeah he's a troll that's been around a while 03:36:21 I think he's just another yibbering idiot. 03:36:44 gmaxwell: i don't mean to imply anything negative. CodeShark just asked earlier if anyone is working on a server-less joiner 03:36:56 ah! 03:38:09 maaku, gmaxwell: i agree with gmaxwell's opinion of my joiner, i'm glad it's usable but it's mostly a way for me to learn rust 03:46:11 it's good work andytoshi, and better to have something working than the perfect unimplemented whiteboard design 03:46:43 my weakness is that I spend too much time on the latter (see: freimarkets) 04:23:34 ;;alias add cjs web fetch https://www.wpsoftware.net/coinjoin/status.php 04:23:35 The operation succeeded. 04:23:37 ;;cjs 04:23:37 Error: This url is not on the whitelist. 04:23:40 >_> 04:23:43 just a sec lol 04:23:46 lol 04:24:13 ;;cjs 04:24:14 There is no currently open session. 04:24:16 there :P 04:24:26 ;;alias add coinjoinstatus cjs 04:24:26 The operation succeeded. 04:24:33 for those who prefer a more verbose command. :) 04:24:53 nanotube: hurrah 04:25:34 nanotube: can we make ;;cjs fd1d19c88eaa675d7151a625bcb911e05d8b58e35faf51a974ba73c565ba6a63 go to status.php?session=fd1d19c88eaa675d7151a625bcb911e05d8b58e35faf51a974ba73c565ba6a63 04:25:36 ? 04:26:02 also, thanks! :) 04:26:04 yes, technically speaking. :) question is, if session id is blank, will it still work? 04:26:24 ;; web fetch https://www.wpsoftware.net/coinjoin/status.php?session= 04:26:24 There is no such session. 04:26:29 nope, one moment.. 04:26:46 ;; web fetch https://www.wpsoftware.net/coinjoin/status.php?session=fd1d19c88eaa675d7151a625bcb911e05d8b58e35faf51a974ba73c565ba6a63 04:26:47 This session is complete. The submitted transaction ID was 33854f625c90e3287eae951103489a2449f91bfe039aa4d4c810bd66450edbf1. 04:27:20 ;; web fetch https://www.wpsoftware.net/coinjoin/status.php?session= 04:27:21 There is no currently open session. 04:27:23 there we go 04:27:40 nice. :) i could do it either way, but it would be more trivially easy if empty sessionid defaulted to general query. 04:28:11 yeah, this is probably the better behavior for when users put a blank session= anyway 04:28:16 ;;cjs Halcon Capricorn 04:28:16 Coinjoin Status: There is no such session. 04:28:32 aww 04:28:51 i've got a python script which converts to codewords, but not the other direction 04:29:02 ;;cjs fd1d19c88eaa675d7151a625bcb911e05d8b58e35faf51a974ba73c565ba6a63 04:29:02 Coinjoin Status: This session is complete. The submitted transaction ID was 33854f625c90e3287eae951103489a2449f91bfe039aa4d4c810bd66450edbf1. 04:29:05 ;;cjs 04:29:06 Coinjoin Status: There is no currently open session. 04:29:09 :D 04:29:13 there we go. :) 04:29:26 ;;help cjs 04:29:26 (cjs ) -- Alias for "echo Coinjoin Status: [web fetch https://www.wpsoftware.net/coinjoin/status.php?session=@1]". 04:29:50 ;;cjs Halcon Capricorn 04:29:50 Coinjoin Status: There is no such session. 04:29:54 heh 04:30:02 ;;sl halcon capricorn 04:30:03 http://www.youtube.com/watch?v=DITktReXJpI | 4 Dic 2011 ... Horoscopo Maya 2012 KosmosErika HALCON, para los nacidos del 7 de ... CAPRICORN Horoscope for JANUARY 2014 - Karen Lustrupby ... 04:30:09 >_> 04:30:14 right now this fd1d19 guy turns into "DIA sorot van 1071 JSOFC3IP Cornflower Electron PBX Ionosphere CSC EG&G MKNAOMI PBX Iris WWSP RSO MD5 USACIL JCE NSWC IACIS LEASAT Yukon GGL NAIA" 04:30:21 so it should be a bit shorter :P 04:30:53 heh yea... but it is a pretty long string.... 04:31:33 so, the sessid is actually only 32 bits from /dev/urandom right now 04:31:37 i just run it through sha256 :P 04:31:47 it has lots of room to go shorter 04:31:49 ah good old sha2 04:34:13 making the small big and the big small since 2001. 04:35:17 ok, future sessions will use 8 bytes of randomness and output the first 16 chars of the hash 04:35:34 that translates to 7-8 words, which looks good 04:35:37 [username@titanic spookwords]$ ./main.py fd1d19c88eaa675d 04:35:39 FID DDP Embassy Bluebird GEO Canine 1911 07:01:30 Fistful_of_LTC is now known as Fistful_of_AFK 07:16:48 ;;cjs fd1d19c88eaa675d7151a625bcb911e05d8b58e35faf51a974ba73c565ba6a63 07:16:49 Coinjoin Status: Session Delta USAFA SAMU SIGS DCSS spook RRF LASINT CFC spookwords NSDM Uziel NRO PLO MSNBC JPL plutonium FINCEN JANET Fortezza ESN SATKA toffee eavesdropping fissionable : completed. The submitted transaction ID was 33854f625c90e3287eae951103489a2449f91bfe039aa4d4c810bd66450edbf1. 07:17:01 ;;cjs Delta USAFA SAMU SIGS DCSS spook RRF LASINT CFC spookwords NSDM Uziel NRO PLO MSNBC JPL plutonium FINCEN JANET Fortezza ESN SATKA toffee eavesdropping fissionable 07:17:01 Coinjoin Status: Session Delta USAFA SAMU SIGS DCSS spook RRF LASINT CFC spookwords NSDM Uziel NRO PLO MSNBC JPL plutonium FINCEN JANET Fortezza ESN SATKA toffee eavesdropping fissionable : completed. The submitted transaction ID was 33854f625c90e3287eae951103489a2449f91bfe039aa4d4c810bd66450edbf1. 08:14:35 hahahah 08:16:11 ;;cjs 08:16:12 Coinjoin Status: There is no currently open session. 08:42:04 why is JPL a scary word? :P 08:47:51 maaku: the spookwords lists have a whole bunch of generic military-industrial-complex keywords. ... someone's idea of unusual words that in the early 90s might have triggered some government keyword filter, at least in the busy imagination of some cryptoanarchist. 08:48:02 (and, well, probably in reality too— at least for some of the words) 08:49:01 gmaxwell: were you able to install boost_log? :) 08:49:39 CodeShark: s'not yet. I figured I'd upgrade fedora and got as far as downloading it. :) 08:50:05 well, in the worst of cases you can just ./b2 --with-log :) 08:52:33 what am i reading 12:50:38 petertodd, gmaxwell: sender derived address/code and stealth-addr write up on my older thread (still to locate bytecodes to link) feel free to correct https://bitcointalk.org/index.php?topic=317835.new#new 15:08:42 ;;cjs 15:08:42 Coinjoin Status: There is no currently open session. 15:33:42 petertodd, gmaxwell: if you throw a tx into the joiner it'll trigger a new session 15:33:52 at this point it's probably okay to do so without irritating anyone 15:34:03 ;;cjs 15:34:03 Coinjoin Status: The current session is open for 15 more minutes. There are currently 1transactions in the pot. The most popular output value is 0.107428. 15:34:07 ;;cjs 196bfaf16b1dbfb9 15:34:07 Coinjoin Status: The current session is open for 15 more minutes. There are currently 1transactions in the pot. The most popular output value is 0.107428. 15:34:26