| 00:23:33 | Pasha: | Pasha is now known as Cory |
| 00:39:18 | gmaxwell: | [semi-ot] this is fun, has ROC charts for timing correlation attacks against tor: http://www.spiegel.de/media/media-35538.pdf |
| 00:47:41 | phantomcircuit: | gmaxwell, any guess what was redacted on page 13 |
| 00:49:21 | gmaxwell: | phantomcircuit: a person's name |
| 00:51:07 | phantomcircuit: | ah |
| 00:51:20 | phantomcircuit: | i like the "Seems to work" part |
| 00:51:53 | op_mul: | it still endlessly amuses me that people think they can remain anonymous while using bitcoin. |
| 00:53:28 | phantomcircuit: | well this is a pretty good indication of what i've suspected for a while |
| 00:53:37 | op_mul: | my block post-processor spits out a list of known address tacks every time there's a new block. half the time it's people's full names. even if people were capable of using bitcoin properly they would be very exposed, but they can't even manage that. |
| 00:53:56 | phantomcircuit: | throwing a good amount of very noisy garbage through tor would seem to likely defeat these techniques |
| 00:54:47 | belcher: | op_mul in the future could coinjoin make bitcoin anonymous / pseudonymous ? |
| 00:55:06 | belcher: | if used for the vast majority of transactions say |
| 00:55:50 | op_mul: | belcher: I doubt it. even if people could use bitcoin properly (they don't), timing attacks are easy with Bitcoin. any person using SPV also broadcasts their wallet contents to random people on the network, electrum users are even more at risk. |
| 00:55:57 | sipa: | belcher: don't confuse anonimity with privacy |
| 00:56:21 | sipa: | coinjoin improves privacy but it definitely does not give you anonimity (at least the party you're joining with knows which input/output is yours) |
| 00:56:32 | op_mul: | belcher: there's people using coinjoin who send money into a join, and then make the exit point the address they started with. |
| 00:57:06 | op_mul: | sipa: that too. |
| 00:57:29 | sipa: | anonimity is a very strong condition; it really means that nobody can know anything (unless you intentionally reveal) |
| 00:57:50 | phantomcircuit: | sipa, if there are a bunch of independent parties with inputs you can in theory keep the inputs and outputs from being linked even by the coordinator |
| 00:58:07 | sipa: | how? |
| 00:58:19 | phantomcircuit: | send your output over one tor circuit |
| 00:58:24 | op_mul: | I don't think anonymity is obtainable with Bitcoin, or with the internet in general. it's best just to accept that fact. |
| 00:58:37 | phantomcircuit: | retrieve the tx to sign over another |
| 00:58:45 | phantomcircuit: | and hell why not use another to send the signed tx |
| 00:58:52 | belcher: | op_mul so in the situation coinjoin worked, you could use other things like SPV and electrum to deanon people |
| 00:58:53 | phantomcircuit: | but this is of course trivial to dos |
| 00:59:01 | belcher: | and if sipa's objection was also somehow solved |
| 00:59:06 | sipa: | zerocash/etc give you anonimity at the protocol level, at very high cost (but still doesn't prevent your ISP from spying on your transactions of course) |
| 00:59:35 | phantomcircuit: | sipa, and is well... moon math :P |
| 00:59:46 | sipa: | yeah |
| 00:59:49 | sipa: | there be sharks |
| 00:59:50 | naturalog: | what's wrong with I2P? |
| 00:59:51 | sipa: | *snarks |
| 00:59:55 | sipa: | naturalog: nothing? |
| 01:00:02 | op_mul: | belcher: yes. lite clients are hilariously leaky for your privacy. with electrum there's a party of community run servers, all of which who will receive a copy of your wallets addresses. |
| 01:00:03 | naturalog: | good anonymity |
| 01:00:13 | sipa: | no, better privacy; no anonimity afaik :) |
| 01:00:19 | gmaxwell: | naturalog: I2P has a lot less study at least. |
| 01:00:43 | naturalog: | but on I2P its so much easier to earn more anonymity than tor or so |
| 01:01:04 | sipa: | there is no such thing as 'more anonimity'; you can get more privacy |
| 01:01:09 | sipa: | you're either anonimous or not |
| 01:01:14 | gmaxwell: | naturalog: doubtful. It has a much smaller userbase so the maximum anonymity is much lower. |
| 01:01:29 | sipa: | well, not really - but it's much less a scale |
| 01:01:33 | naturalog: | the point is that you can shuffle the peers and route as you wish |
| 01:01:38 | gmaxwell: | sipa: there actually are degrees of anonymity, e.g. set size. |
| 01:01:47 | sipa: | yeah |
| 01:01:48 | naturalog: | less a scale, true, but very different, a closed system |
| 01:01:57 | op_mul: | gmaxwell: I would say that's an oxymoron. you're either anonymous or you're not, I don't think there's an option of levels of gray. |
| 01:02:24 | gmaxwell: | op_mul: there is, at a minimum, set size. The distribution of identities you could be has some entropy. |
| 01:02:35 | gmaxwell: | If you have a perfect anonymity system with three users ... well.. |
| 01:03:07 | naturalog: | when you broadcast a tx, no one has no know where it came from. so on structure like i2p makes it possible to transmit transactions anonymously. one cannot distinguish who created the tx |
| 01:03:24 | op_mul: | naturalog: "no one". you've just lost. |
| 01:03:32 | naturalog: | since you dont need a reply, the source may remain unknown |
| 01:03:44 | naturalog: | yes cause who can know who actually created the tx? maybe im just passing it over? |
| 01:04:08 | gmaxwell: | naturalog: that sounds like magical thinking. There are many ways that your anonymity leaks. And what you're saying could equally (or better) be said of tor. |
| 01:04:23 | naturalog: | no, tor encodes the sources |
| 01:04:28 | naturalog: | since it has to give you an answer |
| 01:04:47 | op_mul: | naturalog: bitcoin nodes are very, very leaky about which transactions they are interested in. given a particular address, I can actually test your node to see if your wallet contains it or not :) |
| 01:04:51 | naturalog: | and if only say btc txs are in concern, how can that anonymity be broken? |
| 01:05:13 | sipa: | by all other i2p nodes conspiring against you |
| 01:05:14 | naturalog: | op_mul: ic true welel the user has to be aware ofc |
| 01:05:16 | gmaxwell: | naturalog: perhaps you should move this to #bitcoin, sounds like you're really underinformed about transaction privacy. |
| 01:05:28 | sipa: | or by leaking your information through other means |
| 01:05:31 | naturalog: | sipa: they can all still conspire against me, who knows who created the tx? |
| 01:05:48 | sipa: | you have a tcp connection to at least one other |
| 01:05:54 | phantomcircuit: | 1gmaxok well that was kind of interesting but not really new data |
| 01:05:58 | naturalog: | sure but maybe i didnt create it just passing it over |
| 01:06:10 | sipa: | then you know |
| 01:06:11 | gmaxwell: | phantomcircuit: yea, we knew it could be done, was interesting to see analysis of it. |
| 01:06:18 | phantomcircuit: | basically this is exactly the type of attack tors security model specifically doesn't prevent |
| 01:06:28 | sipa: | naturalog: the point of anomity is that within the set of potential sources, there is nothing that gives anything away |
| 01:06:45 | sipa: | routing just obscures things; it doesn't make anything impossible |
| 01:06:51 | op_mul: | gmaxwell: I guess my issue with the phrase "anonymity" in this context is that most people will take it as an absolute rather than a scale. I've spoken to people who think that using their blockchain.info wallet through the onion router makes them immune to everything. |
| 01:06:55 | naturalog: | sipa: ok and how does what i describe break cause of what you says? |
| 01:07:13 | naturalog: | sipa: ok so whats possible when i dont need any reply? |
| 01:07:13 | phantomcircuit: | gmaxwell, yeah the line about false positives being higher with bulk downloads suggests that throwing a bunch of noise at the problem might make a big difference |
| 01:07:37 | phantomcircuit: | iirc you can send traffic to arbitrary nodes in the circuit, not just through the circuit to the end |
| 01:07:54 | sipa: | naturalog: sorry, this doesn't lead anywhere |
| 01:08:00 | op_mul: | phantomcircuit: if you do that then somebody can just flood out the fake noise floor and measure above that. |
| 01:08:26 | gmaxwell: | naturalog: reply is totally orthorgonal, it doesn't help or harm. (reply paths are source routed backchannels in any case). |
| 01:08:41 | belcher: | op_mul how do you query a node to see if the wallet contains an address? i didnt know that |
| 01:08:47 | phantomcircuit: | op_mul, sure... but you could also just set the rate limiting up and then do constant bandwidth |
| 01:08:59 | phantomcircuit: | (at this point that would be a fairly obvious signature though) |
| 01:09:06 | gmaxwell: | naturalog: as I said, please take this to #bitcoin using tools like i2p or tor do _NOT_ make your bitcoin transactions magically "anonymous". |
| 01:09:36 | naturalog: | gmaxwell: nothing happens magically, well, you may continue assuming i dont know what im talking about |
| 01:09:45 | op_mul: | belcher: nodes that have a vested interest in a transaction will attempt to rebroadcast it. nodes that don't never will. you can make transaction forms which cause a node to reveal their wallet to you. |
| 01:10:40 | sipa: | naturalog: please understand the distinction: i2p/tor/whatever make one part of the identity leak that bitcoin transactions cause harder - it doesn't do this absolutely, and it does not prevent other leaks |
| 01:10:52 | naturalog: | sipa: thats obvious |
| 01:11:08 | sipa: | naturalog: this is not a criticism on i2p; we're just arguing that bitcoin transaction are _not_ anonymous, and nothing can fix that |
| 01:11:13 | op_mul: | phantomcircuit: I think then it's a DOS risk. |
| 01:11:23 | naturalog: | sipa: and i claim it may bi fixed |
| 01:11:25 | belcher: | i didnt know that, i thought bitcoin nodes rebroadcasted every tx |
| 01:11:25 | naturalog: | be |
| 01:11:36 | phantomcircuit: | op_mul, there's actually a lot of available relay bandwidth |
| 01:11:37 | sipa: | naturalog: #bitcoin then please |
| 01:11:44 | phantomcircuit: | there isn't a lot of exit bandwidth |
| 01:11:53 | op_mul: | belcher: no, never unless you are interested in it. |
| 01:12:22 | op_mul: | or you made the transaction. |
| 01:12:49 | belcher: | does that mean a node needs to be connected directly to a miner if it wants it tx to be mined? since otherwise the tx wont be rebroadcast and eventually reach the miner |
| 01:12:52 | gmaxwell: | op_mul: we do have some degree of protection there in that we won't accept into the wallet a transaction we wouldn't relay. so the attack of construct a transaction that'll never get mined and give it to a node to make it beacon, if you've identified the source, will not work. |
| 01:13:06 | gmaxwell: | belcher: no. |
| 01:13:32 | gmaxwell: | belcher: it'll be relayed by nodes that don't already have it in their mempools if its rebroadcast. |
| 01:14:41 | op_mul: | gmaxwell: indeed. it's expensive and noisy, probably. I've never tried it. would probably work better if you could island the node. |
| 01:16:50 | gmaxwell: | If anyone wants a my-first-bitcoin-core-patch project, a config setting (or even RPC) to suppress all transaction broadcast from the wallet, so that you can do your advertisement vis manual getrawtransaction -> alternative announcement method... would be such a thing. |
| 01:43:10 | ahmed_: | ahmed_ is now known as bittrex-bodi |
| 01:43:33 | bittrex-bodi: | bittrex-bodi is now known as ahmed_ |
| 01:43:39 | naturalog: | naturalog has left #bitcoin-wizards |
| 01:57:28 | DougieBot5000_: | DougieBot5000_ is now known as DougieBot5000 |
| 02:28:33 | jgarzik: | gmaxwell, need a patch-requests area somewhere public |
| 02:28:44 | sipa: | ? |
| 02:28:48 | sipa: | ah |
| 02:28:50 | sipa: | yes! |
| 02:29:02 | jgarzik: | a place to catalog areas where newbies could jump in |
| 02:29:07 | jgarzik: | or medium-bies |
| 02:29:27 | jgarzik: | specific requests, not vague "clean it up bleh" |
| 02:30:15 | jgarzik: | if you wanna get fancy, let us upvote in a semi-decentralized manner by adding PGP-signed or ECDSA-signed +1's |
| 02:30:51 | sipa: | dude |
| 02:30:54 | sipa: | let's vote with PoW |
| 02:31:16 | op_mul: | a patch requests block chain? |
| 02:31:21 | sipa: | votecoin |
| 02:32:28 | jgarzik: | bootstrap a web of merit |
| 02:36:00 | MRL-Relay: | [othe] https://bitcointalk.org/index.php?topic=768499.0 i throw this in the round for your voting |
| 02:37:58 | op_mul: | othe: would malleability in monero mean that anybody could spend an output as many times as they want? |
| 02:41:01 | Pan0ram1x: | Pan0ram1x is now known as Guest54581 |
| 02:44:31 | MRL-Relay: | [othe] at least not as far as i can imagine, theres a section on djbs original paper "small subgroup attacks" or sth like that about malleability, but i would not be surprised if the code is somewhere else fucked up that allows some kind of malleability tho |
| 02:46:20 | MRL-Relay: | [othe] that btctalk link is not based on any monero code, it could just be used for voting if you sign "yes" or "no" messages |
| 02:47:26 | op_mul: | think I'll have to read up on how moneros transactions work, I think I'm misunderstanding how you prevent double spends. I thought it was something to do with a double spend revealing the signer if they signed the same output in more than one transaction. |
| 02:49:26 | op_mul: | sounds more confused in words than it did in my head. |
| 02:52:08 | MRL-Relay: | [othe] it checks the key images for double spends, you can only use them once |
| 02:54:17 | atgreen: | jgarzik: did you try rebuilding from scratch? |
| 03:09:16 | jgarzik: | atgreen, pull+scratch of toolchain seems to have fixed moxiebox tests |
| 03:09:21 | jgarzik: | so all good |
| 03:09:38 | jgarzik: | glad to be sync'd up again |
| 03:09:47 | jgarzik: | I like the latest changes |
| 03:14:50 | SomeoneWeird: | SomeoneWeird is now known as s1w |
| 04:42:13 | atgreen: | jgarzik: just sent PR to add gdb support to moxiebox. https://github.com/jgarzik/moxiebox/pull/13 |
| 04:42:53 | jgarzik: | atgreen, merged |
| 04:44:17 | atgreen: | jgarzik: hmm.. don't see it. I see #12 merged, which is just some sim cleanups based on gdb sim. But not the actual GDB support. |
| 04:44:18 | jgarzik: | atgreen, oh, nvm. I thought you meant the cosmetic PR. |
| 04:44:22 | jgarzik: | atgreen, reviewing |
| 04:47:28 | atgreen: | uh.. I just noticed that it will accept the -g option unconditionally. Let me fix that. |
| 04:50:15 | jgarzik: | atgreen, can you move the big chunk of code in main() to a separate function |
| 04:50:55 | atgreen: | hmmm |
| 04:51:25 | atgreen: | ok |
| 05:01:50 | atgreen: | jgarzik: ok, done |
| 05:07:36 | jgarzik: | atgreen, Thanks. fwiw, I don't like making it compile-time optional. I would rather just always build it, and default it to disabled at runtime. It requires no additional dependencies, and results in cleaner code that way. You don't have to worry about that if you don't want to, I can clean it up after merging. |
| 05:08:14 | jgarzik: | Heading to bed *poof* |
| 05:08:21 | atgreen: | Ok, I'll let you clean that up. Thanks! |
| 05:09:30 | atgreen: | I can make the toolchain build script build gdb, and then also suggest some additions to the README |
| 07:58:45 | Pan0ram1x: | Pan0ram1x is now known as Guest45352 |
| 08:01:21 | gmaxwell: | gmaxwell is now known as Guest61857 |
| 08:04:08 | wiz_: | wiz_ is now known as wiz |
| 08:32:22 | iambernie: | iambernie has left #bitcoin-wizards |
| 08:37:31 | lclc_bnc: | lclc_bnc is now known as lclc |
| 08:49:31 | lclc: | lclc is now known as lclc_bnc |
| 09:05:16 | orwell.freenode.net: | topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja |
| 09:05:16 | orwell.freenode.net: | Users on #bitcoin-wizards: andy-logbot CoinMuncher Guyver2 d1ggy epscy digitalmagus8 adam3us spinza wiz harrow SubCreative sl01 Guest61857 gavinandresen hashtagg tacotime Guest45352 NikolaiToryzin cbeams orik zooko everettForth coiner waxwing go1111111 PRab prodatalab Emcy_ atgreen Cory copumpkin Shiftos isis E19m c0rw1n e1782d11df4c9914 hashtag_ shesek adlai Starduster_ todaystomorrow samson_ grandmaster2 SDCDev iddo Luke-Jr Aquent s1w gnusha koshii jaekwon sadgit |
| 09:05:16 | orwell.freenode.net: | Users on #bitcoin-wizards: brand0 mortale Greed eric Tjopper roasbeef mr_burdell lclc_bnc hktud0 GAit Krellan HaltingState fanquake luny null_radix berndj ebfull OneFixt jgarzik @ChanServ nuke1989 jaromil jbenet poggy_ petertodd Apocalyptic Meeh tromp__ PaulCapestany tromp cluckj DougieBot5000 helo v3Rve midnightmagic espes__ Iriez fluffypony hollandais thrasher` butters nickler Logicwax lnovy ahmed_ warren fenn LarsLarsen jchp mkarrer pi07r phantomcircuit Graet |
| 09:05:16 | orwell.freenode.net: | Users on #bitcoin-wizards: optimator morcos [\\\] michagogo mappum Muis kanzure gribble MRL-Relay maaku wizkid057 Graftec bobke rfreeman_w huseby [d__d] BananaLotus amiller artifexd kumavis Guest2104 nsh coryfields BigBitz coutts BlueMatt cfields Anduck Eliel nanotube hguux_ AdrianG gwillen CryptOprah btc__ wumpus stonecoldpat dansmith_btc toddf heath bbrittain DoctorBTC EasyAt starsoccer danneu catcow TD-Linux ryan-c smooth mmozeiko Alanius JonTitor asoltys_ K1773R a5m0 |
| 09:05:16 | orwell.freenode.net: | Users on #bitcoin-wizards: comboy btcdrak Nightwolf pigeons andytoshi lechuga_ warptangent Fistful_of_Coins HM2 Guest38445 kinlo azariah yoleaux sneak harrigan sipa livegnik burcin Taek throughnothing crescendo so Keefe phedny BrainOverfl0w |
| 10:15:20 | midnightmagic: | Guest61857: hey fix your nickname |
| 10:17:21 | Guest61857: | Guest61857 is now known as gmaxwell |
| 10:30:32 | lclc_bnc: | lclc_bnc is now known as lclc |
| 12:17:18 | lclc: | lclc is now known as lclc_bnc |
| 12:49:50 | thesnark: | thesnark is now known as narwh4l |
| 13:17:57 | lclc_bnc: | lclc_bnc is now known as lclc |
| 14:49:32 | jgarzik: | jgarzik is now known as jgarzik_ |
| 15:32:42 | wallet42: | wallet42 is now known as Guest6340 |
| 15:32:42 | wallet421: | wallet421 is now known as wallet42 |
| 15:34:35 | roidster: | roidster is now known as Guest32436 |
| 16:05:24 | E19m: | E19m is now known as Elio19 |
| 16:07:57 | lclc: | lclc is now known as lclc_bnc |
| 16:19:13 | jgarzik: | * jgarzik builds the moxie toolchain for the nth time ;p |
| 16:19:28 | jgarzik: | * jgarzik pats himself on the back for picking little endian |
| 16:21:39 | zooko: | * zooko laughs out loud. |
| 16:24:25 | sipa: | at university we had a fake hardware platform to learn architecture/assembly/basics of an OS on, called DRAMA. the translation is approximately "decimal calculation device with multiple accumulators" |
| 16:25:11 | zooko: | ☺ |
| 16:25:50 | sipa: | decimal meant that registers held numbers between 0 and 9999999999, it had 100000 memory locations, and bytes were values between 0 and 99999 |
| 16:26:04 | tromp__: | reken apparaat? |
| 16:26:13 | sipa: | decimaal rekenapparaat met meerdere accumulator |
| 16:26:51 | jgarzik: | sipa, We used SPIM (MIPS, backwards) at Georgia Tech. http://en.wikipedia.org/wiki/SPIM |
| 16:27:43 | sipa: | the idea was "it's about the principle, and not about one special actual platform. so let's make it so useless that you don't learn anything about actual hardware at all": |
| 16:27:48 | sipa: | yeah, heard about that |
| 16:29:57 | gmaxwell: | before I bumped into moxie I had been thinking of just using MMIX. (I've never used MMIX but I did make a MIX simulator and assembler and some other tools eons ago) |
| 16:30:42 | jgarzik: | MMIX is nicely surrounding by Knuth's golden halo |
| 16:30:59 | jgarzik: | Was fun when somebody created the first FPGA implementation of MMIX |
| 17:04:41 | jgarzik: | My moxie toolchain build fails because.... texinfo is not present? sigh. |
| 17:08:29 | sipa: | the compiler needs to be able to read the documentation, probably :p |
| 17:10:41 | jgarzik: | atgreen, Would you mind updating your two PRs, squashing "update" "update" "update" commits into a single commit per PR? |
| 17:11:08 | atgreen: | just leaving for day with family... :( |
| 17:11:19 | jgarzik: | atgreen, OK |
| 17:11:21 | atgreen: | I mean :) for spending time with family, but :( for not being able to do this. |
| 17:11:29 | jgarzik: | atgreen, I can squash and give you credit |
| 17:11:39 | jgarzik: | ie. manual merge |
| 18:19:40 | lclcd: | lclcd is now known as lclc |
| 18:41:29 | NewLiberty: | NewLiberty is now known as NewLiberty-afk |
| 19:37:25 | jgarzik_: | jgarzik_ is now known as jgarzik |
| 21:10:50 | jgarzik: | * jgarzik returns to continue the battle with the GNU toolchain |
| 21:51:24 | Greed`: | Greed` is now known as Greed |
| 22:10:58 | hearn_: | hearn_ is now known as Guest90916 |
| 22:34:01 | Dizzle__: | Dizzle__ is now known as Dizzle |