--- Log opened Fri Nov 15 00:00:43 2013 00:49 < BlueMatt> definitely 03:02 < gmaxwell> https://bitcointalk.org/index.php?topic=334316.msg3588908#msg3588908 03:02 < gmaxwell> adam3us: ^ you might like that. 03:37 < warren> are we going to stick with testnet3 for 0.9? 03:38 < warren> there was talk of restart earlier 03:38 < warren> (this matters to test code in other implementations) 05:11 < adam3us> gmaxwell: yes good, i am going to post a cross link on another thread to your reasoned explanation 05:15 < adam3us> gmaxwell: unfortunately (because its more technically challenging) it seems cryptographic anonymity is a better shelling point than mixing - people can look at the mix and see ooh its some % mixed with bad event X - if its mathematically unknowable, they just shrug and say so what its cash, i have identity of my customers, thats all i need to know 05:15 < midnightmagic> You can pretend to say "2% of your coins are tained." 05:15 < adam3us> gmaxwell: but i agree if & until someone figures out how to do that efficiently we need to blur the taint to meaninglessness by default in most clients 05:17 < adam3us> gmaxwell, midnightmagic: the problem is when people like CoinValidation get in the mix, they create counter-veiling and potentially viral counter effect where people avoid mixing, rather than increasing mixing. if that happens it may cause a price run of selling tainted coins at lower & lower is counts. 05:20 < gmaxwell> adam3us: yea, there is a symmetry break we need to have, where either privacy is easy and common, or where privacy is mostly useless and only available at great expense. 05:21 < gmaxwell> If only some people use the privacy stuff then everyone will be driven away from wanting to use it for fear of association. 05:22 < gmaxwell> Theymos announced a match on the CJ bounty. 05:22 < gmaxwell> FWIW. 05:23 < adam3us> gmaxwell: btw yday about computational PIR i meant computational variant of multi-node to reduce bandwidth. where n-1 of the n request strings are RNG seeds (there's a footnote in mojonation tech paper about my having suggested it to them). mojo was an agoric p2p anonymous storage system. ex-mojo people include bram cohen (bittorrent), zooko (tahoe-lafs) they took the bits of mojo and expanded them 05:25 < gmaxwell> adam3us: interesting! I'll look into that. Yea, I'm vaguely familar with mojonation... I know zooko worked on it. (amusingly zooko asked if I knew about it, and I misheard him, and said no, and he looked so crestfallen. :) ) 05:25 < adam3us> gmaxwell: still musing if there is a way to use TD's noisy bloom request to get secure spv searching for sender randomization of static 05:26 < adam3us> gmaxwell: its too simple to read: just instead of sending n random strings that xor to 1 bit remaining, you send n-1 seeds and one random string, no longer info theoretic secure if you can break the stream cipher/rng 05:31 < adam3us> nice matonis (9000 twitter followers) just retweeted via petertodd my rant about coin validation. i think dark wallet are going to reach their funding target. I offered them free crypto advice. 05:34 < petertodd> adam3us: I'm going to their hackathon in a few weeks 05:47 < adam3us> petertodd: cool. people going to vegas conf? 05:47 < petertodd> vegas conf? didn't know there was one 05:52 < warren> I'm considering going to vegas conf. 05:53 < adam3us> http://www.mediabistro.com/insidebitcoins/ i'm not the most in the loop guy - there are 100s of bitcoin conf & I dont know which are the most relevant - just i was going to be in the us anyway so i figured why not 05:53 < warren> not exactly sure how useful it is though 05:53 < warren> quite expensive looking 05:53 < adam3us> warren: hoteil is cheap tho $66 in amsterdam it was $100s for a mediocre 2*! 05:55 < adam3us> warren: yes usefulness - the only recognizable names are reiner/armory and charlie lee's brother from btcchina - someone tell me whats the most useful. i have limited idea. there are loads, there was another one in amsterdam 2months after the previous one - they didnt get critical mass interest so canceled. (they were soliciting speakers) 05:56 < TD> good morning 06:00 < adam3us> we should have a bitcoin wizards BoF: recommended for wizards only - others heads will spin so they wont get much out of it 06:03 < warren> adam3us: the conference sign up fee is rather large 06:04 < gmaxwell> or we just hold our own conference. :P 06:05 < adam3us> warren: it is, yes just meant its offset by the hotel cost. i paid $930 for 4 nights at a bad 2* for the amsterdam conf. their conf hotel is $66/night 06:06 < warren> 2* ? 06:06 < adam3us> gmaxwell: why not. round up the brains lock them in a room, until they fix fungibility :) 06:06 < adam3us> warren: actually i guess it was 3-star, but it was so bad i mentally graded it as a 2-star missold as 3* 06:09 < adam3us> warren: in malta you can stay at a swank 5* around the corner from me for $110/night - amsterdam is too expensive 06:43 < gmaxwell> $450. :P 06:45 < adam3us> gmaxwell: bay area? right expensive. btw https://bitcointalk.org/index.php?topic=333882.msg3590223#msg3590223 link to your post 06:45 < adam3us> gmaxwell: but maybe sleep :) 06:46 < gmaxwell> Bitcoin price, not hotels. 07:02 < wumpus> sigh... http://www.reddit.com/r/Bitcoin/comments/1qnqn1/a_pledge_i_invite_you_to_help_us_stop_the_threats/ :-( 07:03 < wumpus> some people conflate everything 07:19 < TD> a lot of people don't read 07:19 < TD> it's the very nature of a pitchfork-wielding mob 07:19 < TD> i lolled at the "bitcoin developers are too political .... it should be writte in C" post 07:20 < gmaxwell> wumpus: its the sort of thing where you should ignore their words and read their feelings and have sympathy. 07:20 < gmaxwell> This is very important. 07:20 < gmaxwell> ... 07:20 < gmaxwell> Because it's impossible to strangle them over the internet. 07:20 < TD> haha 07:21 * TD is reminded of jwz's "cock shaped sound wave" w.r.t linux video 07:36 < wumpus> watch out we're getting together and going to FORK the project... well wow, yes that's how open source works, go ahead and do some useful work 07:36 < wumpus> hehehe 07:37 < TD> yeah. over time i've come to realise the importance of communicating ideas in as few words as possible, on the internet. because a lot of people just won't read something if it's long, they'll assume you said what they expect you to have said 07:37 < TD> and then their responses won't make any sense. 07:37 < TD> but sometimes it's hard to sum up complicated ideas in a short space 07:38 < wumpus> well the problem is that there are a lot of ideas here, most of them not so much complicated, but a lot of them, and seemingly people conflate them all into one 07:38 < TD> everyone loves the idea of "us vs them". it's just fundamental to human nature. 07:39 < TD> people like to pick sides and feel like they're fighting for their side 07:39 < TD> whether it's us vs the terrorists, west vs east, anarchists vs the foundation, liberals vs conservatives etc. often these fights don't make a ton of sense but they help people feel belonging 07:40 < wumpus> agreed 07:40 < wumpus> but sometimes it does get in my nerves, we're sort of al on the same side here 07:43 < warren> I just convinced mastercoin's lead dev that their design is 1) stupid 2) at risk of being filtered by BTC pools and messed up 3) unnecessarily pays a tax on every MSC tx to benefit a centralized entity that externalizes costs 4) and could be done with two TXO per tx instead of four. 07:46 < wumpus> I haven't looked at mastercoin yet tbh 07:52 < adam3us> warren: go warren :) petettodd claimed otherwise on their thread, but i think if they use eg committed tx and a side-chain they only need a timestamp from bitcoin main 07:53 < adam3us> warren: (i think peter was pointing out without committed tx, chain has no stake or incentive in any direction for msc) 07:55 < warren> hmm, #3 has no technical reason not to fix, except the centralized entity that created Mastercoin wouldn't support a proposal to change the protocol where they lose perpetual tax income. 07:55 < warren> #4 it is actually possible with one TXO 07:55 < Fistful_1f_LTC> could they still move mastercoin to another independant blockchain ? 07:56 < warren> I'm trying to suggest that.... 07:56 < adam3us> Fistful_1f_LTC: I think so ripper123 (mastercoin ceo?) mentioned it himself on the thread 07:56 < warren> they're scared suddenly by Luke-Jr's patch, and realization that there's targeted ways for pools to filter only them 07:58 < adam3us> warren: i dont want to give them ideas but i think steganography wins (eg they could use committed tx too (even steganographically encoded variant of it), and we may want to prevent miner policy with (non-stego) committed tx also) Luke-Jr is awesome but miner policy is a slippery slope when we have limited technical defense against miner centralization 07:59 < sipa> luke's patch makes sense, but it's not rational for miners to adopt it 07:59 < sipa> it adds complexity to mining, and can only result in lost fee income 08:00 < adam3us> sipa: his policy was to deprioritize non-unique addresses right? or was the another feature also? 08:00 < sipa> yes 08:01 < adam3us> sipa: and msc is using address tagging i guess 08:01 < warren> adam3us: their address tagging is for dumb reasons that have nothing to do with the goal of the protocol 08:01 < adam3us> sipa: sweet patch btw :) 08:01 < warren> adam3us: it's for the founder to collect a tax on every tx 08:02 < Fistful_1f_LTC> why dont they move to PTS 08:02 < adam3us> warren: yes so the patch is a temporary win 08:02 < Fistful_1f_LTC> or create their own, 08:02 < adam3us> Fistful_1f_LTC: yes i suggested that to ripper123 on the msc thread - pts 08:02 < sipa> PTS? 08:02 < Fistful_1f_LTC> protoshare 08:02 < Fistful_1f_LTC> bitshare 08:03 < adam3us> sipa: protoshares a temporary "please mine this while we code bitshare" and we promise to give pts a 10% premine equity in bitshare 08:03 < Fistful_1f_LTC> lol 08:03 < sipa> brrr 08:03 < warren> Fistful_1f_LTC: I think their goal is to avoid having the entire network being declared illegal by making it impossible to be detected 08:04 < adam3us> Fistful_1f_LTC: its awesome - i hung out the on the #protoshares irc for a short while - most of the people had no idea what or why they wre mining, only that they were there EARLY so if it rocketed theyd make bundle 08:05 < adam3us> warren: i think stego works, eg built on committed tx. but only up to the insider attack someone can get in their identify msc tx via nominal value msc tx, and feed the info and evidence to miners to block 08:08 < Fistful_1f_LTC> adam3us: it's already rallying, 08:08 < adam3us> sipa: the mistakes on pts were almost terracoin in proportion. its hashrate went up faster than the adjustment could control, so it mined 6months planned in 1 week. they released a hardfork patch and demaned all miners switch 08:08 < Fistful_1f_LTC> i'm mining a ton right now 08:08 < TD> i don't think miners should be down-prioritising address re-use 08:08 < adam3us> Fistful_1f_LTC: i think you maybe could get more speed, like n^2 more by increasing the ram used in the code 08:09 < Fistful_1f_LTC> how would i do that? 08:10 < adam3us> Fistful_1f_LTC: there is a data structure tht stors colision candidates, its set to lke 1GB, if you increase it to 64GB it may run 1000x faster 08:10 < adam3us> Fistful_1f_LTC: (or however much ram you have) 08:11 < Fistful_1f_LTC> using AWS 08:11 < Fistful_1f_LTC> its probably scalable 08:11 < adam3us> Fistful_1f_LTC: yes you can choose instances with more or less RAM, but try it first 08:12 < warren> TD: sipa: sure Luke-Jr's patch may not be rational, although filtering MSC may 08:12 < TD> well it's just not useful, imo. people already have incentives to not re-use addresses 08:13 < Fistful_1f_LTC> ok, you kno which datastructure that is? 08:13 < adam3us> Fistful_1f_LTC: erm 1 sec 08:13 < Fistful_1f_LTC> or which miner are you talking about the coyote one ? or the beer 08:14 < adam3us> Fistful_1f_LTC: either the qt client or the ptsminer client (its the same code)... the bitshare binary they dont release source for 08:14 < warren> and OMG, have you read their "spec"? The designer seriously doesn't know what he's doing. 08:15 < Fistful_1f_LTC> ok, i use ypool's miner, which is slightly faster, 08:15 < warren> huh, protoshares uses XPM's pow? 08:17 < adam3us> Fistful_1f_LTC: probably from same source... look for semiOrderedMap.cpp 08:17 < Fistful_1f_LTC> adam3us: cool, thanks 08:17 < Fistful_1f_LTC> warren: they use momoentum, 08:18 < adam3us> Fistful_1f_LTC: (I havent tried it... just as they are using birthday collision, until ram is full it speed increases n^2 with size of ram, if the cpu cores are fast enough to fill it in about the size of a block duration) 08:18 < Fistful_1f_LTC> slightly "hardened" scrypt, but it seems it's not that much harder 08:19 < adam3us> Fistful_1f_LTC: did they change it? i think its H=hashcash-SHA512-26 (26 bit bitcoin like collision) 08:19 < Fistful_1f_LTC> adam3us: i will test it then 08:19 < adam3us> Fistful_1f_LTC: warren: then they find store H(cb,a), H(cb,b) for random values or counters a, until they find H(cb,a)==H(cb,b) in the last 50-bits (50-bit birthday partial collision) 08:20 < adam3us> Fistful_1f_LTC, warren: finally they test if H(cb,a,b) < target 08:21 < adam3us> Fistful_1f_LTC, warren: (cb is coinbase) their idea is its they wanted to make a scrypt variant which was faster to verify (3 hashes) but still needed ram like scrypt, an interesting but unsolved design concept (i thought of it and tried it myself ages ago - its not easy) 08:24 < adam3us> Fistful_1f_LTC, warren: consequently they failed on 3 counts: 1. it has TMTO (via unreliable bloom storage - which they dint realize) so it can probably be made to work in GPU L2 cache; 2. it has progress so powerful computers win more than their share, 3. it has economies of scale (ie 2x ram = 4x power). triple fail 08:27 < warren> adam3us: I recall Luke-Jr was touting their design earlier while making fun of Litecoin's PoW failure. =) 08:27 < warren> (sure ,Litecoin had a PoW failure) 08:31 < adam3us> warren: litecoin PoW failure was params, this one is algorithmic :) an luckily for the investors in litecoin, the b0rken params turned to be OK params for GPUs when ASICs took over 08:33 < adam3us> warren: 3am dude. 08:33 < warren> sigh 08:33 < warren> yeah 08:37 < adam3us> warren: it would be interesting to find a way to design a secure memory hard pow that does not require memory to verify and has no progress nor economy of scale problems (nor tmtos) 08:38 < warren> adam3us: I don't have enough CPU's to benefit from that new scamcoin. 08:39 < adam3us> warren: the guy who asked me to look at it rented 80 vsps from the vsp provider that bitshare were getting affiliation profitfor 08:39 < adam3us> warren: then bitshre did the hard fork he had 80 vsp sitting there with nothing to do on a monht contract, he was not happy 08:40 < warren> adam3us: read the launch of XPM and digitalocean? hilarious 08:40 < adam3us> warren: (the difficulty jump after the fork made it ridiculous) 08:40 < adam3us> warren: no will go take a look for giggles 08:41 < warren> hmm, can't find the URL 08:41 < warren> adam3us: someone made a killing ... from referral codes 09:40 < petertodd> adam3us: the underlying problem isn't the incentive to mine - timestamping by itself is fine - it's the incentive to *publish* 09:41 < petertodd> sipa: sure, but equally adopting the dust patch can only result in lost-fee income too... 09:42 < petertodd> warren: yeah, I told MSC to ditch the address tagging too - they understand the issue and even came up with the idea of creating a globally predictable per-MSC address so that MSC clients could still work via SPV 09:42 < petertodd> warren: s/they/some of them/ :P 09:42 < warren> gavinandresen: just to confirm, you have 5 BTC available for macosx corruption bounty? 1) explain HOW it happens 2) provide a fix that is acceptable for merging by the standard review procedure. 09:43 < warren> petertodd: ooh 09:43 < petertodd> warren: (a MSC investor approached me a while back and paid me to do a bit of consulting for them; said investor decided to sell all the same) 09:43 < warren> petertodd: that's a better design than what I came up with 09:43 < adam3us> petertodd: well if the mine is of a bitcoin coinbase that includes a merkle root for the side-chain - then the miner has to publish it to collect their bitcoin reward 09:44 < petertodd> warren: yeah, basically the idea would be to predict the address, you'd have to duplicate a decent chunk of their code. Obvously that can be stopped, but it's a pain in the ass too. 09:44 < warren> gavinandresen: we'll chip in to the bounty, ask public for more donations to chip in more and post it. 09:44 < petertodd> adam3us: sure, but what if publishing late has incentives for some reason? mastercoin has global state crap so... 09:46 < adam3us> petertodd: well other than selfish mining, delaying publication of bitcoin blocks is playing dice with $25*450 09:47 < petertodd> adam3us: yes, *bitcoin* blocks, we're talking about mastercoin here 09:47 < petertodd> (well I'm talking...) 09:47 < adam3us> petertodd: the pay not to mine, given tx is a problem for bitcoin also, or pay to mine a different msc merkleroot 09:48 < petertodd> adam3us: right, but remember, this is a side-chain, timestamped, so the problem is what happenes if a MSC tx or block or whatever it's called gets stamped, but not published? it's not a trivial problem 09:50 < adam3us> petertodd: ah i see what you mean. mining a hash runs the risk that the block is not available. bitcoin mines a hash, but announces by sending the block in one stage (not hash then block) 09:51 < adam3us> petertodd: i think other miners ignore hashes without blocks, and orphan them 09:51 < petertodd> adam3us: exactly. and with pow mining, it helps that naturally everyone is running flat out - not true with sacrifices/timestamps/etc. 09:58 < petertodd> bbl 14:03 < Luke-Jr> adam3us: there's no slope in miner policy. miners have always had a right to decide which transactions they will and won't accept… 14:04 < Luke-Jr> sipa: it's rational for miners to use it because it ensures the value of their earned bitcoin remains 14:05 < Luke-Jr> adam3us: to fix the param problems with Litecoin's PoW, you'd introduce an algorithmic problem because you'd expose validators to the memory requirements 14:06 < adam3us> Luke-Jr: I love what you are doing with eligius policy. My point was more in the long term/theoretical - the fact that a miner can make decisions about payments might lead to censorship, coin blaclisting if miners get too large and centralized 14:07 < adam3us> Luke-Jr: this risk is what led me to think of committed tx where the miner cant see the coin contents until after it is mined 14:08 < Luke-Jr> adam3us: that was already a risk 14:08 < amiller> gmaxwell, you see the post about bitter to better and hash locking? 14:08 < amiller> i'm familiar with that paper but somehow didn't understand that. 14:10 < adam3us> Luke-Jr: yes i am talking about the 5 year old risk. like I say your new policy i think is awesome :) 14:16 < K1773R> adam3us: how should a miner (were talking about bitcoind in this case) decide which txs are valid and which not if he dosnt know what it is until it founds a PoW? 14:17 < gmaxwell> K1773R: becuase in such schemes it doesn't matter if its not valid. 14:18 < adam3us> K1773R: the commited tx is a hash of the tx and a cleartext fee, only the recipient gets to see inside it, and technically its only recipients who care. 14:18 < K1773R> gmaxwell: so i could fill someone else blocks with trash (invalid txs which will be later droped/ignored) to minimize the amount of valid txs? that seems even more horible than it is now 14:19 < gmaxwell> K1773R: you'd have to pay fees, same as always. You're replaying my objections now. :P 14:19 < K1773R> adam3us: so i can spent coins from someone else with no signatures attached and the system would mine a block with it? ugh :S 14:20 < K1773R> gmaxwell: ah i c, so you pay the fee even if the tx will be later droped (after its contents are known)? 14:20 < adam3us> gmaxwell, K1773R: (yes) btw similar objections could probably be made of mastercoin and colored coins and the new message packet - people ay to use the block chain in ways even less useful to bitcoin 14:21 < gmaxwell> K1773R: yea. you can imagine it as a normal fee paying txn plus a blinded txn stuffed inside it. And no, if it's used right someone can't block you with an invalid txn. 14:21 < amiller> damn this bitter to better proposal is actually really cool.... 14:21 < adam3us> K1773R: it also cant be double spent, even though its in commited form 14:22 < amiller> i didn't realize it but it successfully provides no way to link the two transactions involved 14:22 < gmaxwell> amiller: it doesn't work in bitcoin today. 14:22 < amiller> why not 14:22 < amiller> looks like it does to me? 14:23 < gmaxwell> IIRC it requires arithemetic in script. 14:24 < maaku> adam3us: fyi i object to "committed tx" because that terminology is misleading. people think committed == confirmed == validated. 14:24 < maaku> you might have an easier time explaining it if you adopt "hidden tx" or some other terminology 14:25 < adam3us> maaku: yes. was thinking of bit-commitments when i came up with the name. it might be better yes. howeve it is only temporarily hidden typically. so in some way it is rather like a classical bit commitment - you fix a value for the duration of the protocol and then reveal 14:25 < amiller> gmaxwell, i just checked and no it doesn't require any airthmetic in the script 14:25 < amiller> i thought it did too, but it doesn't 14:25 < adam3us> amiller: link? 14:25 < amiller> https://crypto.stanford.edu/~xb/fc12/bitcoin.pdf 14:25 < amiller> scroll to section 7.1 a fair exchange protocol 14:25 < amiller> alice and bob can swap coins in two transactions without linking the two transactions to each other 14:30 < maaku> really? it looks to me like they're linked by the hashes 14:30 < maaku> it'd be easy to build an index of transaction matching this form, matching them together 14:31 < amiller> they're not 14:31 < amiller> i totally misread this paper as i think everyone else did 14:31 < amiller> a1,a2,a3,... are alices secrets 14:31 < amiller> b1,b2,b3 are bobs secrets 14:32 < amiller> what happens is that one transaction contins H(b1),H(b2),... 14:32 < amiller> while the other transaction contains H(a1+b1), H(a2+b2), ... etc 14:32 < amiller> so you can only link the transctions if you know a1,... 14:32 < maaku> a1 + b1 meaning a1 XOR b1? 14:33 < amiller> ye 14:33 < maaku> ok they could have been much clearer 14:33 < amiller> so alice begins with a1,... and bob learns a1+b1 throuhg the protocol 14:33 < amiller> however no one else learns them. 14:34 < amiller> er i mean bob learns a1,... throughout the protocol by observing a1+b1 and alreayd knowing b1,... but no one else learns b1 etc 14:35 < maaku> b is revealed when alice claims her amount, yes? 14:35 < amiller> b is revealed yes 14:36 < amiller> everyone learns b 14:36 < amiller> no one other than bob and alice learn a though 14:39 < adam3us> maaku: btw the other day on here you mentioned about combining chaum certified issue for a external issuer and ZC. maybe with lower overhead for the network you could have chaum certs exchangeable with the issuer, and use the blockchain only for recording spent coins 14:40 < gmaxwell> maaku: basically its a similar protocol to my first coinswap attempt, but they didn't move as much of the protocol out of band as petertodd did. 14:41 < maaku> gmaxwell: where's the latest protocol? 14:41 < gmaxwell> instead, they just moved the script execution out via the cut and choose thing. 14:41 < gmaxwell> whereas PT's approach was to move the entire hashlock out via escrows and refunds. 14:42 < maaku> adam3us: yes, if someone has rights to issue currency, trusting them for double-spend validation is no less secure 14:42 < maaku> issuing more currency or allowing double-spends amounts to the same thing 14:42 < maaku> it requires them to be online, however 14:43 < maaku> i see a use for that with private accounting servers, where the server itself can act as signer 14:43 < maaku> not so sure about the public chain though 14:43 < adam3us> maaku: i was wondering also if you could prevent overissuing. say the issuer key is offline, but thre is an online refreshing key. the block chain validates that no more than the issuer number exist 14:45 < adam3us> maaku: i think the main problem is it conflicts with privacy - if the refreshed coin has to be block chain validated, it is obvious to the issuer who the owner is 14:46 < maaku> adam3us: how? 14:46 < adam3us> maaku: timing 14:46 < maaku> i'm not sure I follow 14:47 < maaku> there are 20 coins in existance in this series, say, and when I send a token for redemption, how does the server know which one prior -- 14:47 < maaku> oh you mean because the person claims it and uses it 14:47 < adam3us> maaku: so say th eblock chain provides a way to count how many coins are in circulation, because they are recorded as confirmed 14:48 < maaku> yes everyone knows where coins enter and leave the chaum system. that's assumed 14:48 < adam3us> maaku: yes the recipient swaps it for a fresh one, and then has to confirm it. the old serial number must be recorded, and the new blind coin 14:48 < maaku> but if it's chaum -> chaum, there's no linkage 14:49 < adam3us> maaku: the timing is the issue - the user would like to hold it off chain until he wants to spend it ,if he does that the online issuer could overissue wrt to the offline issuer intended share pool size (eg if it was hacked) 14:49 < maaku> why? there's no privacy risk to confirming the redemption 14:50 < maaku> because it's not linked to future or past transactions 14:50 < maaku> it's completely anonymous 14:50 < maaku> input: unblinded token (not linked to past), output: blinded token (not linked to future) 14:51 < adam3us> maaku: i am making assumptions about how to enforce the limit. maybe there is a better way. at time of issue, 100 shars are issued (blind certs). 14:51 < adam3us> maaku: whenever they are traded the old serial number is given to the block chain by the recipient for validation, and used as proof to the online issuer to get a fresh coin 14:54 < adam3us> maaku: you want the network to be able to help the bearer share holders know there are only 100 in circulation still. seems tricky 14:55 < maaku> adam3us: that could be kept in an index 14:58 < adam3us> maaku: seems like the online issuer could issue 101, 102 etc because the recipients hold them offline until use 15:12 < adam3us> gmaxwell: you mentioned yday or so that the idea of sending keys from committed/hidden coins via the p2p network without mining validation would conflict with confirmed utxo. is the utxo set view of he miner included in the coinbase to facilitate spv? 15:18 < gmaxwell> adam3us: it isn't included today, we've talked about including it.. not just spv but "spv that can validate", for use in rapid full node bootstrapping and other things. 15:20 < gmaxwell> adam3us: on a seperate subject, I was thinking: It's actually really sad that our native signature scheme can't do efficient 2-of-2 multisigning ("split key"), because if it could the anonymity set of 2-of-2 escrows (like coinswaps) would include all the regular transactions too. 15:23 < adam3us> gmaxwell: yes this is why i keep on about EC schnorr it supports n of n without prior arrangement, just add up Q1 and Q2 and sign with d1 and d2 15:24 < adam3us> gmaxwell: schnorr also supports simple k of n (again with public key of size one key) and the observer never knows if a signature is one public key, 2 of 2 or k of n. its all invisible to the veifier 15:25 < adam3us> gmaxwell: ec schnorr also supports very simple efficient blinding (unlike ec dsa), an extends into brands credentials which open a whole realm of compact, similarly efficient to ECDSA per term ZKPs of selective disclosure and formulae on attributes, which probably something interesting can be done with 15:25 < gmaxwell> adam3us: I know it does, thats why I'm crying to you. 15:25 < adam3us> gmaxwell: so couldnt we add a new signture schme? 15:25 < gmaxwell> adam3us: we can, it's non-trivial though. 15:27 < gmaxwell> worse, there is no sutiable prefab EC schnorr sitting ready to use. The Ed25519 formulation, for example, breaks this stuff. 15:27 < adam3us> gmaxwell: maybe you could joint validate multiple input keys. add up the public keys from the input addresses and provide one signature with it 15:28 < adam3us> gmaxwell: why do you say ed25519 breaks ec schnorr? 15:28 < gmaxwell> adam3us: meh, never been a fan of that kind of layering violation, as it binds script too tightly to the choice of underlying crypto. 15:28 < adam3us> gmaxwell: :) more compact though. cisc vs risc argument 15:29 < gmaxwell> adam3us: I mean, if bitcoin worked that way now talking about adding schnorr would be much harder. :) 15:30 < gmaxwell> adam3us: IIRC Ed25519 modifies schnorr by adding an extra hash input. I am not sure if it breaks these things, but I had a vague recollection that it did. 15:31 < adam3us> gmaxwell: yes - i understand. its not that serious of a suggestion what you could say is its an optional op only avalable with some sig types eg opcombosig or whatever. as you say layer violation, agreed. you'd have to decide if it was worth the bandwidth saving 15:31 < gmaxwell> If it doesn't ... then my evaluation of the usefulness of Ed25519 has gone up a lot. 15:32 < adam3us> gmaxwell: i dont know the answer... anyone else on here read djb stuff in enough detail to know? 15:32 < gmaxwell> I mean, both sipa and I have, but I know I don't currently remember. :) 15:33 < gmaxwell> At the time, while I knew there were schnorr things to do threshold crypto I was totally not thinking about that. 15:33 < gmaxwell> For some reason DJB himself never points out that Ed25519 is applicable to that stuff. 15:34 < adam3us> gmaxwell: i think sooner or later we should add/move over to schnorr it is just better in so many directions that its a design/efficiency win 15:34 < adam3us> gmaxwell: mainly the flexibility enables new things, that are not possible without it 15:35 < gmaxwell> I think the notion that it enables new things which are externally indistinguishable from old things is one I hadn't considered before and is also pretty compelling. 15:42 < adam3us> gmaxwell: trying to decipher EdDSA - has he done something funky to the H (aka sha256) etc output? seems like he went slightly too far in optimization, maybe use his curve but not the most extreme of the optimizations 15:43 < gmaxwell> I think the optimization was to try to eliminate some precomputation attacks. 15:52 < adam3us> gmaxwell: djb can be one crazy dude at times. i think this is more like a speed hacked, mangled, curve specific, bigger hash schnorr! (i thought it was dsa lke from the name) 15:54 < adam3us> gmaxwell: he might've broken the algebraic properties with the speed hacking for n of n etc 15:55 < adam3us> gmaxwell: i reckon this djb edDSA has its own protocol violation layers; i reckon use sipa's ECDSA,and if/when switching use ECSchnorr with your favorite EC curve 15:57 < gmaxwell> yea, but then you've taken the whole setup out of the realm of something well known, which is unfortunate. 16:00 < adam3us> gmaxwell: btw there are even arguments schnorr is more secure than dsa see p10 of bernstein paper. there's another paper just on that topic by someone else. i dont think edDSA is something that specific - its just a speed hacked tweaked schnorr. but the signature size is bigger a he doesnt want to count the cost of uncompressing 16:01 < adam3us> gmaxwell: i do like his idea to include Q the schnorr hash (he labels it A) alternatively someone figures out if it doesnt break the desired features n o n, brands, blinding etc and if it can be optionally used in compressed form 16:13 < adam3us> gmaxwell: btw here in lies the problem (of why we are even having this conversation) "Practical use of Schnorr's system was hampered by a patent (which expired in 2008)," 16:13 < adam3us> gmaxwell: hence the introduction of the inferior DSA (slower, less flexible, less secure to some attacks) 16:14 < adam3us> gmaxwell: and less security proofs, and more complex... something like a quintuple fail as the standardized algorithm because prof schnorr decided to get himself a patent - i bet he never got much money from it 16:17 < gmaxwell> adam3us: yea, I know. (I thought I previously defeneded bitcoin's use of ecdsa instead of it on that basis, but maybe I didn't because the patent expired in 2008 ...) 16:17 < gmaxwell> And 12:16 < gmaxwell> If they do, it'll be sad because the history of crypto says that patented crypto is dead on arrival. 16:17 < gmaxwell> (on a seperate subject) 16:18 < adam3us> gmaxwell: and dsa was also designed by NSA, and has fragility due to extreme reliance on unbiased randomness (withotu the determinsitc change) and the original dsa spec had a suspicious bias only rectified as an advisory after bleichenbacher spotted it. something like 8 negative points 16:19 < gmaxwell> i was unaware of issues in the original dsa spec! 16:20 < adam3us> gmaxwell: the algo for generating k had a bias... given the other attacks on computing d given even a few bits from a few hundred sigs, thats suspicious to me in hindsiht 16:21 < jrmithdobbs> adam3us: i hadn't thought about it before, but that is indeed very suspicious in light of recent events 16:21 < jrmithdobbs> but as used/specified now it just has the randomness reliance so is 'safe enough' if implemented well afaict 16:22 < adam3us> http://www.ipa.go.jp/security/enc/CRYPTREC/fy15/doc/1002_reportDSA.pdf by vaudenay section 5. i think bleichenbacher is another one of those people who doesnt bother to write papers... 16:22 < gmaxwell> yea, requiring good randomness is a neat trick, you can be sure your own stuff is secure just by doing better engineering, and then trust everyone else will get it wrong. 16:23 < jrmithdobbs> ya, i've always wondered why dsa did that, i didn't realize it came out of the nsa (was aware of that paper you just linked though) 16:23 < adam3us> 4 million signature key recovery attack (say a busy web server)... i dont think he tried very hard to optimie it either 16:24 < adam3us> gmaxwell: thre was a greenwald article that said expliclty that> they did that intentionally as a form of soft sabotage, complexity and fragilize standards and use their influence with nist to get it through 16:24 < jrmithdobbs> adam3us: papers over a decade old, might not have seemed feasible/worthwhile to try at the time 16:25 < adam3us> jrmithdobbs: bear n mind you do not get FIPS certification beyond a certain level if you do not follow their method. even certification rams through their defective designs, because some sectors wont buy non fips certified sw 16:26 < jrmithdobbs> adam3us: ya, i worked in compliance "industry" for a while, i know. 16:27 < jrmithdobbs> what I want to know is what's non-obviously wrong with keccak that they chose it over blake or is this the one nist crypto standard nsa failed to get in on? 16:27 < jrmithdobbs> and the fact that i think thoughts like this constantly these days without feeling paranoid/dellusional hurts my head in itself :( 16:28 < Luke-Jr> in other news, some Linux kernel devs are "complaining" to me (simply because they recognised my name on the forum thread) that tips4bitcoin is "spamming" them XD 16:28 < adam3us> its probably hard for them to damage the primitives... they attack the key management - its a more valuable target then you can mitm and decrypt despite strong primitives 16:28 < gmaxwell> Luke-Jr: lol 16:29 < Luke-Jr> .. along with a complaint that Linus shouldn't get so much for mere merge commits 16:29 < jrmithdobbs> adam3us: didn't stop them with md*/sha* 16:29 < adam3us> jrmithdobbs: (i mean because these days its an international design competition and a lot of expert participation, open etc) 16:30 < maaku> jrmithdobbs: you could say the same about AES 16:30 < maaku> NSA doesn't seem to be targetting the core algorithms, but rather the constructions on top of them 16:30 < maaku> (Snowden said that in an interview somewhere) 16:31 < BlueMatt> d-ec-drbg... 16:31 < adam3us> sha0 was a mistake, sha1 also later, i thnk it just shows the nsa doesnt have a lead anymore for some time now. they just sabotage. md4, md5 blame rivest 16:31 < jrmithdobbs> except you could say that they may have influenced the decision that chose rijindael as aes in favor of it's weaker key schedule to exacerbate those issues 16:31 < jrmithdobbs> they claimed "performance" re: the key schedule thing, but looking back, every time they claim performance they seem to mean "nsa backdoor of some form" 16:32 < jrmithdobbs> (note: I do not believe rijindael was influenced directly by nefarious parties, just that it's shortcomings may have been intentionally overlooked due to influence from same parties) 16:32 < adam3us> maaku: yes i think i saw that article. also sabotaging standards, including complicating crypto standards and open protocols to make them prone to impl mistakes, and also pressuring us companies to modify system arhcitecture to create central choke points for inerception/attack 16:33 < TD> the IPsec thing was interesting 16:33 < gmaxwell> jrmithdobbs: nah, I mean, look at DUAL-EC ... no one could claim "performance" for that. And atm I believe that is the only absolutely known for sure backdoored thing. 16:34 < jrmithdobbs> did someone finally own up to intentionally convoluting ipsec so that's impossible (except on openbsd, basically, and with a very knowledgable admin) to actually construct a secure ipsec tunnel that provides encryption and authentication in a way that isn't recoverable (pfs) given keys 16:34 < jrmithdobbs> because ipsec is one fucked spec 16:34 < TD> one of the guys who worked on it said that people associated with the NSA kept making suggestions during the spec process that sounded reasonable to non-experts, but actually broke the security 16:36 < petertodd> TD: it's a good thing we've never ran into that problem with Bitcoin 16:37 < jrmithdobbs> gmaxwell: we don't know for sure but we know they're actively targeting specs now why wouldn't they have been 15-30 years ago while the others were written? Whose to say we haven't ignored some of their infiltration as simple mistakes/advancements on the state of the art 16:38 < gmaxwell> TD: hard to know for sure, since even honest experts make suggestions with bad security here and there. 16:38 < maaku> petertodd: that we know of 16:38 < jgarzik> anybody gonna be in DC next week? 16:38 < TD> yeah i dunno what to make of the ipsec allegation 16:38 * jgarzik decided to attend, on short notice 16:39 < TD> you'll watch live? 16:39 < petertodd> jrmithdobbs: the NSA aren't omniscient, even they probably don't know how to write useful backdoors into a lot of the core algorithms due to constraints on the math; I understand that no-one has ever come up with a plausibly backdoored hash function with the same type of construction as SHA256 for instance. 16:39 < jrmithdobbs> TD: the ipsec allegations are plausible but don't matter, we know it's broken by design ("we" being anyone familiar with the crypto who has actually tried to implement it) for a while now 16:39 < TD> i don't know much about ipsec so i'll take your word for it 16:39 < jgarzik> TD, dunno :) If it's not open to the public, that's the only alternative. 16:40 < petertodd> maaku: those merkle mountain ranges even sound dangerous 16:40 < jrmithdobbs> TD: the interesting question is was it's design broken by infiltration of the process or by the fact that it's process was design by comitte in the first place? ;p 16:40 < gmaxwell> jrmithdobbs: there are a lot of IETF protocols that are uselessly complex. Some of them get implement none the less (e.g. SIP) 16:40 < TD> i'm not a big fan of designing specifications by committee 16:40 < jrmithdobbs> me either 16:40 < TD> but then again designed by individual doesn't always work either 16:41 < jrmithdobbs> and tls and ipsec are the best examples of it failing 16:41 < TD> e.g. jabber "xml is fashionable let's use that" 16:41 < TD> tls wasn't designed by commitee, right. it's basically SSL which was designed by a few guys at netscape 16:41 < jrmithdobbs> which is why i said tls not ssl 16:41 < jrmithdobbs> the extensions were all by comittee 16:41 < TD> ah ok 16:42 < TD> gavinandresen has some fun stories about when he worked on standardising VRML 16:42 < gmaxwell> TD: most IETF documents are the work of one or two authors. E.g. in the case of jabber the thing was dropped half way fully formed (including the trendy XML) right on the IETFs doorstep. IETF generally works more like peer-review than a design committee. 16:42 * TD remembers the 3D shark vrml demo 16:42 < Luke-Jr> gavinandresen is to blame for VRML? 16:42 < TD> yeah sure, jabber started as jeremie millers pet project and went from there 16:43 < maaku> I'd much rather someone here take a few months to design IPSec-done-right, we implement it, use it, and standardize after the fact 16:43 < jrmithdobbs> and now it's jeremie millers' pet project as deployed by google 16:43 < jrmithdobbs> basically 16:43 < jrmithdobbs> ;p 16:43 < TD> it did pretty well yeah 16:43 < jrmithdobbs> (bleh xmpp) 16:43 < TD> maaku: what does done right mean? 16:43 < Luke-Jr> XMPP is better than the alternatives, at least. 16:44 < maaku> TD: secure by default, easy to understand and use, hard to get wrong 16:44 < petertodd> maaku: secure against what type of attacker? 16:44 < gmaxwell> maaku: there have been a bunch of proposals, but really done right is not the right objective. The right way of doing it doesn't work because it doesn't get past the enormous installed base of nats and firewalls. 16:44 < jrmithdobbs> maaku: the problem with ipsec is it tries to solve 10 different problems and ends up doing so very poorly because of it 16:45 < gmaxwell> maaku: personally I'm a fan of TCPcrypt: http://tcpcrypt.org/ (though I wish it were using curve25519) 16:45 < jrmithdobbs> we have replacements for each individual component of ipsec ... just not at the transport layer 16:45 < jrmithdobbs> where it would be, you know, useful 16:45 < maaku> cool i didn't know about tcpcrypt 16:46 < jrmithdobbs> gmaxwell: what is that *curve one someone released recently that's similar to sctp (iirc) 16:46 < jrmithdobbs> based loosely on the dnscurve work iirc 16:47 < jrmithdobbs> curvecp! 16:48 < Luke-Jr> gmaxwell: isn't it builtin to IPv6 already? 16:48 < jrmithdobbs> there was a revision or alteration of it by someone else more recently (maybe @tarcieri) but I can't find the name/project i'm thinking of specifically 16:48 < gmaxwell> Luke-Jr: "lol" 16:48 < petertodd> Luke-Jr: nope 16:50 < phantomcircuit> iirc ipsec is required of ipv6 but nobody is actually implementing it that way 16:50 < TD> yeah stuff like tcpcrypt is gret 16:50 < TD> i think that's the right approach 16:50 < phantomcircuit> also ipsec is crazy complicated 16:50 < jrmithdobbs> ipsec is worthless 16:50 < TD> the shared secret thing is interesting 16:50 < jrmithdobbs> (says probably the only person in the country that had a working transport mesh network setup in his house for the longest time) 16:51 < phantomcircuit> jrmithdobbs, i tried to setup ipsec between two boxes on my lan once and it just refused to work 16:51 < jrmithdobbs> phantomcircuit: see above, i got it working 16:51 < TD> it seems to be a dead project though? last change was 2 years ago 16:51 < jrmithdobbs> phantomcircuit: i even got it working WELL and CORRECTLY but it wasn't worth the effort. 16:52 < jrmithdobbs> phantomcircuit: it's convoluted and you actually have to understand both the spec and the underlying primitives, in some cases, to have a shot in hell of even figuring out why it's not working, let alone fixing it =/ 16:52 < phantomcircuit> which of course 99.99% of sysadmins wont do 16:53 < phantomcircuit> and 99.999999% of people wont 16:53 < jrmithdobbs> phantomcircuit: right, and that's without even going into the fun subtle differences between different spec versions of the major components (eg, isakmp vs ikev2) 16:54 < jrmithdobbs> phantomcircuit: and then on top of that you can have problems between different implementations that implement the same spec versions and primitives just because of how the spec is so convoluted and unspecific 16:54 < jrmithdobbs> fuck ipsec. 17:02 < phantomcircuit> jrmithdobbs, that was my distinct impression 17:02 < phantomcircuit> jrmithdobbs, so NSA subversion or just normal design by commitee 18:11 < adam3us> https://twitter.com/DataTranslator/status/401410639354019840 18:11 < adam3us> yifu responds "@adam3us see http://www.coindesk.com/bitcoin-tracking-proposal-divides-bitcoin-community/ … Coin Validation is not trying to police Bitcoin or bitcoins." 18:12 < adam3us> ho hum... no but they are hoping their customers will and that it will be viral, and as a side effect will kill fungibility 18:14 < gmaxwell> adam3us: yea, I don't get the people fixating on goverment imposition in general, as if badness can only be emitted by governments. 18:14 < gmaxwell> People seem to not think that bussinesses enforcing it out of paranoia and cargoculting good practices would be somehow better. 18:15 < adam3us> the verified-by-visa of the bitcoin world 18:17 < MC1984> gmaxwell thats stems from fear of govt action 18:18 < MC1984> people think maybe if they make a good show of it perhaps the govt wont steamroll in with regulation 18:18 < MC1984> maybe thats right 18:19 < gmaxwell> MC1984: in some cases— e.g. even with no fear of government action you can happily throw away a couple percent of 'likely troublemakers' for pure business reasons, but regardless not directly. 18:19 < adam3us> MC1984: well like i said, they just need to issue AML/KYC certs for cases where its needed why would they want to kill fungibility 18:19 < MC1984> but its like locking your keys in the house so that you dont lose them 18:19 < phantomcircuit> gmaxwell, or like 20% 18:19 < phantomcircuit> (or 90+% like i currently do) 18:19 < MC1984> you cant troublemake with bitcoin though, from the view of a merchant 18:20 < MC1984> why would most of them care where coins come from 18:20 < phantomcircuit> MC1984, oh boy is that not true 18:20 < MC1984> phantomcircuit assuming merchant has sane policies 18:20 < phantomcircuit> did you see the crazy lady saying im killing her dog? 18:20 < MC1984> nope 18:20 < phantomcircuit> just google patrick strateman 18:20 < adam3us> MC1984: they only would feel they need to care because of the existence of taint; if taint were fixed they would have no reason to even give it a second thought 18:21 < MC1984> "just google me" 18:21 < phantomcircuit> MC1984, it's literally the first result 18:22 < phantomcircuit> if i cared more i'd start giving reporters sensational comments to change that 18:22 < phantomcircuit> lol 18:22 < MC1984> yeah im just saying "just google me and all will be clear" 18:22 < MC1984> more like patrick bateman amirite 18:23 < gmaxwell> phantomcircuit: when that person was posting on the forum I thought they were threatening to kill your dog 18:23 < gmaxwell> because they were all "I know where you live and now the dog will die because you didn't give me money!!" 18:23 < phantomcircuit> gmaxwell, she has threatened to kill both me my mother and my dog 18:23 < phantomcircuit> ironically blaming me for killing her dog 18:24 < MC1984> which one of those links is the moneyshot 18:27 < MC1984> yeah thats weird, its like a whole narrative 18:28 < phantomcircuit> yeah 18:28 < phantomcircuit> the thing is 18:28 < phantomcircuit> i have literally no record of her ever 18:28 < phantomcircuit> bitch is crazyyyy 18:29 < MC1984> are you amused or harassed 18:29 < gmaxwell> phantomcircuit: you should tell her that you paid her but {pick a victim} took the money. 18:29 < phantomcircuit> MC1984, mostly amused 18:29 < phantomcircuit> if she continues im going to call the police and have her deported 18:30 < MC1984> all goof fun then 18:30 < phantomcircuit> she's a uk national on a fiance visa 18:30 < phantomcircuit> if she has any negative contact with the police she is immediately deported 18:30 < phantomcircuit> but that would just make her even more angry 18:30 < MC1984> what if something got lost between britcoin>intersango or somthing 18:30 < phantomcircuit> so tradeoffs in life 18:30 < phantomcircuit> MC1984, im pretty sure i have all the bank records 18:31 < MC1984> invite her to sue then 18:31 < phantomcircuit> MC1984, god i dont want to actually deal with that shit 18:31 < phantomcircuit> but yeah i think that's what i have to do 18:31 < MC1984> can you countersue in the uk 18:32 < phantomcircuit> MC1984, she's in like florida or georgia or something 18:32 < phantomcircuit> so yeah i could pretty much ruin her 18:32 < phantomcircuit> but really who wants to ruin a crazy lady who would then have nothing better to do than direct even more crazy at you 18:32 < MC1984> well 18:32 < MC1984> fair warning and all that 18:33 < gmaxwell> MC1984: if she gets deported back to the UK she'll likely have even more free time to bug him. 18:34 < MC1984> tru 18:36 < Emcy> oh nice 18:36 < phantomcircuit> gmaxwell, exactly 18:36 < Emcy> just grouped this nick 18:36 < Emcy> henceforth i am Emcy 18:36 < phantomcircuit> actually at this point she's probably gone past the point of harassment and is well within terroristic threats 18:36 < phantomcircuit> which would mean jail time 18:36 < phantomcircuit> but she'd still be crazy 18:36 < phantomcircuit> just even more angry 18:38 < gmaxwell> there should be a service that you can hire that redirects the crazy people to be mad at them, or better, ficticious persons they create just for that purpose. 18:38 < Emcy> terroristic rly 18:38 < Emcy> anyone seen the complaint letter generator thing? 18:38 < phantomcircuit> Emcy, it's a deceptive term us lawenforcement uses to mean threatening to commit a crime against someone 18:38 < Emcy> had a few people on forums with that 18:39 < phantomcircuit> gmaxwell, that's actually a really good idea 18:39 < Emcy> well still, dont perpetuate it 18:39 < Emcy> its one of the worst things to happen in the last 10 or 15 years 18:40 < phantomcircuit> Emcy, sure except in this case she is literally threatening to kill me 18:41 < Emcy> well yeah but is that legit terrifying 18:42 < Emcy> like, what happend to just threats of harm 18:42 < Emcy> over here you have all the rights in the world when dealing with police, unless he "suspects you of terroristic activity", and then youre his pet for the next while 18:42 < phantomcircuit> Emcy, i have literally thought about what i would do if she broke into my house and tried to kill me 18:42 < Emcy> its not right 18:43 < phantomcircuit> so yes 18:43 < phantomcircuit> yes it is 18:43 < Emcy> get a gun? 18:43 < phantomcircuit> i've moved 18:43 < phantomcircuit> cant find me now 18:44 < adam3us> https://twitter.com/adam3us/status/401492797846335488 18:44 < adam3us> @DataTranslator seems like PR distinction: Coin Validation is trying to fan viral run on fungibility by businesses. But *they* dont police. 18:45 < phantomcircuit> that's a large part of why she's mostly just annoying 18:46 < gmaxwell> phantomcircuit: you still in the bay area? 18:46 < phantomcircuit> gmaxwell, nope 18:46 < phantomcircuit> i moved to a loverly place where i can carry a concealed firearm 24/7 18:46 < phantomcircuit> and will be doing so shortly 18:48 < Emcy> you handled weapons before? 18:49 < phantomcircuit> Emcy, nope 18:49 < adam3us> man we've so got to fix fungibility 18:49 < phantomcircuit> have a ccw course scheduled and will tell them it's not a joke 18:49 < adam3us> & talk some sense into Yifo & Coin Validation 18:50 < phantomcircuit> adam3us, no 18:50 < phantomcircuit> just leave them alone 18:50 < phantomcircuit> the more you talk about them the more credibility you give them 18:51 < adam3us> phantomcircuit: do you think they realize how dangerous to fungibility and bitcoin continued existence that they are doing is? i mean they dont actually want to kill it or they have no business to validate 18:51 < phantomcircuit> adam3us, my first guess would be yes 18:51 < sipa> look at it this way: if business believe what they're selling is useful, cryptocurrencies like bitcoin have probably little chance of surviving (at least in its original fungible spirit) 18:52 < phantomcircuit> and they're just being dicks 18:52 < Emcy> meanwhile in britain 18:52 < Emcy> breadknives come with an 18+ warning 18:52 < adam3us> phantomcircuit: or maybe they do know and Gifu is just the tech sucker/grunt in a bigger scheme 18:52 < phantomcircuit> Emcy, yeah well if you fucks would stop stabbing each other... 18:52 < sipa> but if we're just ignoring them, i think the chance of them just silently being forgotten increases 18:52 < gmaxwell> Yea, I don't see any reason to debate with them... we should just moot them. 18:52 < Emcy> phantomcircuit thats mostly london 18:52 < gmaxwell> arguing with them gives them credability. 18:52 < phantomcircuit> Emcy, lol i was kidding 18:53 < gmaxwell> if no one responded a lot of people would just think "bitcoin is anonymous so what you're suggesting can't work!" 18:53 < adam3us> have to educate bitcoin biz people i bet there are enough of them who dont understand the fungibility risks 18:53 < sipa> adam3us: agree there 18:53 < gmaxwell> then again, yifu ahs probably ripped off enough miners at this point to fund this effort for a long time. :( 18:53 < Emcy> well i would not want my countrymen to have firearms any way. It would be a mostly accidental bloodbath 18:54 < sipa> adam3us: but doing it as a reaction to the co-invalidation thing is not the right signal 18:54 < adam3us> gmaxwell: i think its more likely this mellon trust fund guy thats funding the gig 18:54 < kill\switch> Which one does the PR videos on weusecoins? I forget the nick, he's on IRC 18:54 < phantomcircuit> gmaxwell, i dont even know what he did 18:54 < sipa> kill\switch: justmoon made that site, a long time ago, before he was at opencoin 18:54 < phantomcircuit> i dont think he did the videos though 18:54 < kill\switch> I think a PR video series about fungibility basics would go far to making the case for 'normal' people 18:54 < phantomcircuit> he paid someone to do it 18:55 < sipa> yes, there was a crowdfunding for the video 18:55 < jrmithdobbs> the weusecoins guy? ya he paid someone 18:55 < adam3us> kill\switch: hat sounds like a good idea 18:55 < jrmithdobbs> it was like the only bounty that ever actually got paid i think 18:55 < jrmithdobbs> ha 18:55 < sipa> and the wallet.dat file was subsequently lost... 18:55 < gmaxwell> sipa: and the video only used like half of the raised funds, and the rest were lost. 18:56 < jrmithdobbs> ya that too 18:56 < gmaxwell> I think they lost over 5000 btc if I was remembering correctly. 18:56 < sipa> IIRC it was something like 7k BTC 18:56 < jrmithdobbs> nah it was 5000 usd 18:56 < gmaxwell> if you average our opinions ... :P 18:57 < sipa> https://bitcointalk.org/index.php?topic=83794.0#post_toc_19 18:57 < sipa> 7000 BTC 18:58 < phantomcircuit> aahah 18:59 < phantomcircuit> man i forgot how much btc was taken in mybitcoin 18:59 < phantomcircuit> 78k 19:02 < sipa> cdecker lost 9k BTC? :o 19:02 < sipa> i never knew 19:03 < gmaxwell> Its interesting that it lists the mooncoin thing and not the reorg attacks on mooncoin, cdouble's exchange, etc. 19:04 < gmaxwell> (several exchanges were attacked with reorgs and timewarps on altcoins used to empty their orderbooks and walk with bitcoins around that time) 19:04 < gmaxwell> bitscalper lol 19:04 < gmaxwell> that was funny. 19:05 < gmaxwell> the story there is incomplete. the site was woefully insecure, some speculated it was intentionally so to cover up for it being a scam. 19:08 < gmaxwell> " The thief is still unknown at this point, but the theft has supposedly been entirely returned" .. facepalm 19:09 < gmaxwell> whomever wrote this was far too kind 19:10 < sipa> where do you read that? 19:10 < sipa> Victim: Users of Bitscalper 19:10 < sipa> Status: MiningBuddy (bitcointalk.org user) attempted to reorganize bitscalper, but failed. No coins have been returned at all. 19:10 < sipa> ah bitcoinica 19:10 < gmaxwell> in that thread. 19:12 < gmaxwell> in the bitcoinica final theft the funds went through several places all provable linked to Zhou. Finally ending up in an exchange account owned by zhou on another exchange. Which were frozen when the tried to withdraw them. Then magically zhou realized the theif must be a mysterious friend of his and 'brokered' a deal that the funds would be returned if the investigation was ended. 19:13 < gmaxwell> but we have no idea who the theif was... 19:13 < gmaxwell> :P 19:18 < Emcy> its impressive for a 14 year old --- Log closed Sat Nov 16 00:00:52 2013