--- Log opened Mon Dec 30 00:00:39 2013
00:59  * andytoshi-logbot is logging
00:59 < andytoshi> <.<
01:04 < pigeons> there is a book called The Anarchistic Colossus by A E van Vogt where immediate punishment from "Kirlian computers" enables an anarchistic society, perhaps "weak" and ripe for alien invasion...
01:28 < gmaxwell> heh xkcd  "Extremely Strong Goldbach conjecture"
01:31 < BlueMatt> gmaxwell: lol
01:45  * midnightmagic CHEERS for comment about Stross + Doctorow being crappy writers!!
01:45 < midnightmagic> i couldn't even fnish the atrocity archives.
01:49 < gmaxwell> they really are, also rudy rucker is a crappy writer too.. but again some neat ideas.
01:51 < midnightmagic> Snow Crash couldn't been a short story. He has these brilliant oases of ideas and diction in the middle of whole empty deserts of shitty prose
01:52 < midnightmagic> *could've
01:56 < midnightmagic> .. which pretty much defines most modern scifi these days.  Oh Stephenson, how your cryptonomicon disappointed.
01:57 < gmaxwell> I'm mostly fine with Neal Stephenson's writing. He's long winded, and well, perhaps I'm not the person you should look to for criticism of that.
01:57 < gmaxwell> it does annoy me that I can't ever recommend his books to most people because they're simply too long.
01:57 < gmaxwell> If you can't read a long (say 80kword) novel in a single sitting then you basically can't enjoy his books.
02:08 < midnightmagic> I read Tommyknockers in basicaly one sitting.
02:19 < midnightmagic> I gots staying power. Blindsight in one sitting. 50+ chapters of HPMoR in one sitting. Greg Bear's blood music in one. Herbert's Hellstrom's Hive and Dune, Chalker's old Wellworld novels, Four Lords of the Diamond, Stross' Friday ripoff (Saturn's Children I think? I'm trying to forget,) and entire collections of Lovecraft even though it was written at the turn of the century and is clunky.
02:21 < andytoshi> nice -- i've had neuromancer and cryptonomicon sitting on my HD for several years now
02:21 < midnightmagic> Neuromancer was an easy couple hours. Heck I can read comp sci textbooks in one go (makes studying them later easier)
02:22 < andytoshi> i can read textbooks for hours on end, with fun books i always feel like i ought to be doing something useful if i'm gonna stare at text for several hours
02:22 < andytoshi> ...and yet, i have no problem with IRC...
02:22 < midnightmagic> But Snow Crash. Damn. Half that stuff didn't even belong in there. Or Gaiman's American Gods. What the hell man. Thunderbird's super-powerful but the christian deities don't make an appearance?
02:22 < midnightmagic> bah
02:24 < midnightmagic> Nooooo they're making a series out of it
02:33 < nsh> American Gods was pretty consistently good reading for me
03:35 < maaku> andytoshi, money has not taken consistent form over time
03:35 < maaku> that is to say what we call 'money' has been changing in nature time after time throughout human history
03:35 < maaku> with measurable effects
03:38 < gmaxwell> (there was a reason that I qualified my statements with 'durable money', tough perhaps thats not the best definition for the effects I was talking about)
03:39 < maaku> yeah you know my bias on that, but even so it's not like historical money can be put in just two categories
03:40 < maaku> its weird and bizaare how many fundamentally different systems we used for the same function, and retroactively we tend to think what we use now has always been the case
03:43 < gmaxwell> not just always been the case, but is the only kind that can exist.
03:43 < maaku> yeah
03:43 < gmaxwell> which is also somewhat amusing because we currently do use other kinds of money too, we just don't reconize it as such.
04:04 < midnightmagic> nsh: We can't be friends anymore. I'm sorry.
04:04 < nsh> because gaiman? noes...
04:05 < nsh> if it helps, i was working in a call centre at the time and anything that wasn't market research questionnaires got a pretty big attentivity power-up
05:27 < justanotheruser> What are your thoughts on this? Can you route your bank website traffic through a third party safely? https://bitcointalk.org/index.php?topic=173220.0
05:34  * nsh frowns
05:35 < justanotheruser> In post 10 it looks like he proposes just giving the escrow the SSL key
05:36 < nsh> why not just get a receipt from the bank like everyone else does?
05:38 < justanotheruser> nsh: because that could be forged easily
05:44 < nsh> in any system where the bank has a private key, signing a receipt is going to be much simpler and more effective than keeping a log of http traffic
05:44 < nsh> i am probably missing something but this seems pretty absurd
05:44 < gmaxwell> nsh: that requires the bank cooperate.
05:45 < gmaxwell> this can work if the bank doesn't do jack shit beyond having an ssl website.
05:45 < justanotheruser> nsh: Banks don't sign receipts
05:46 < justanotheruser> they just encrypt it and send it to you
05:47 < justanotheruser> gmaxwell: have you seen the post I linked?
05:47 < justanotheruser> You're usually able to tell me some fundamental flaw in a system.
05:48 < gmaxwell> a while back, if it's the thread I think it is.
05:48 < gmaxwell> the proxy on aws that can extract a transcript of your bank session minus login credentials
05:48 < gmaxwell> which has enough remote attest to be relatively confident that it's legit
05:49 < gmaxwell> it's ugly, but what better can you do?  It would be vunlerable to misconduct on the proxy host hardware, or vulnerabilties in the software stack.
05:49 < justanotheruser> gmaxwell: can the transcript be forged?
05:49 < gmaxwell> avoiding leaking things like session cookies might be hard.
05:49 < gmaxwell> by someone with control of the proxy hardware or who has compromised its software stack.
05:50 < gmaxwell> I'd have to review again, I didn't look at it too deeply before.
05:50 < nsh> all seems very messy. i bet there are lots of ways to interact with online banking software that look right but cause a failure, or instantly cancelling it through another channel, etc.
05:50 < gmaxwell> my 30 second conclusions was 'yuck, well I suppose you probably can't do better right now'
05:51 < justanotheruser> gmaxwell: P2P exchanging with fiat is a pretty messy concept when you have banks that don't sign receipts and dollars that don't have proof they were transacted.
05:52 < gmaxwell> plus tons of corner cases.
05:52 < nsh> i wonder what a bank would say if you asked them to cryptographically sign receipts of purchase
05:52 < nsh> doesn't seem hugely onerous
05:52 < justanotheruser> gmaxwell: example of a corner case?
05:52 < gmaxwell> I'm sure there are all sorts of ways to make a ledger entry show up in the bank which means nothing.
05:52 < gmaxwell> I mean the transactions are inherently reversable.
05:52 < justanotheruser> nsh: they wouldn't go through that much work to keep a customer
05:53 < nsh> never ask for yourself. ask for you and your seventeen thousand friends :)
05:53 < gmaxwell> I pay you.. shows up in my bank. I get a transcript and call the bank. "sorry, I was drunk and some fraudster tricked me into it. please reverse."
05:53 < justanotheruser> gmaxwell: how do exchanges deal with that?
05:53 < gmaxwell> nsh: the problem is that we want to use this for applications the bank actually wants to block.
05:53 < nsh> oh, right
05:54 < gmaxwell> justanotheruser: long delays, invasive personal information collection... and profit margins big enough to absorb non-trivial losses.
05:54 < justanotheruser> gmaxwell: but if I wire money to btc-e in russia, it can't be reversed right?
05:55 < gmaxwell> it can be, sometimes.
05:55 < justanotheruser> wouldn't that involve russian banks cooperating?
05:56 < justanotheruser> Perhaps P2P exchanging can be achieved if we only trade with members of countries that aren't super good buddies with us.
06:31 < CodeShar_> gmaxwell: I got rid of that boost_log dependency :)
06:32 < CodeShark> gmaxwell: I got rid of that boost_log dependency :)
09:39 < Emcy> 30c3: To Protect And Infect, Part 2
09:39 < Emcy> is there actually a part one anywhere or is it called part 2 for another reason
10:57 < Emcy> i think appelbaum genuinely thinks he might wind up dead
11:27 < pigeons> it is scary to be messed with and have your family messed with by the people who are apparently messing with him
11:31 < Emcy> just how he joked about it at the end
11:31 < Emcy> just the way it came across
11:31 < Emcy> like he knows he is far past the point of no return so may as well press on
16:59 < andytoshi> a new snark paper from ben-sasson: http://eprint.iacr.org/2013/879
17:03 < andytoshi> 35 pages, has a bunch of tinyram benchmarks, looks really cool
17:53 < nanotube> fwiw, i enjoy both stephenson and doctorow >_> i wonder what that says about me. :)
17:56 < Emcy> doctorow i find a bit hard because the stuff he writes is preaching to the choir for me
18:01 < andytoshi> hey guys, who makes laptops like lenovo?
18:01 < andytoshi> who is not lenovo
18:08 < nanotube> haha good thing you qualified. or i might have said lenovo. >_>
18:09 < Emcy> whats wrong with lenovo
18:09 < nanotube> what particular qualities of 'like lenovo' do you have in mind?
18:09 < nanotube> i've been pretty happy with dells
18:09 < nanotube> they take well to linux
18:13 < andytoshi> well, the 440p no longer has the intel chipset, and rumor has it that the default one does not support linux
18:13 < andytoshi> also they don't have the eraser mouse
18:19 < andytoshi> by 'like lenovo' i mean i want a decent keyboard, and an eraser mouse, and ruggedization
18:55 < gmaxwell> maaku: in your blind signing investigation did you find an implementation for JS ready to go someplace.
18:57 < gmaxwell> ?
18:58 < gmaxwell> I'd like to ask wikimedia to just setup the donation form so that when you donate, for every— say— $10 donated you get a blindsigned token which can be used to make an IP BLOCK excempt account in order to solve this problem: http://lists.wikimedia.org/pipermail/wikitech-l/2013-December/073764.html
19:45 < robert222> Bitmessage 2.0
19:45 < robert222> http://twister.net.co/
19:45 < robert222> "Introducing Twister: a fully decentralized P2P microblogging platform leveraging both the Bitcoin and BitTorrent protocols. "
19:50 < sipa> kthxbye
19:51 < CodeShark> https://github.com/CodeShark/bips/blob/master/bip-n2.mediawiki
19:51 < CodeShark> gmaxwell, sipa: please, tell me why this is a bad idea :)
19:52 < sipa> if a transaction gets included right at the edge, a reorganization could push it over the limit
19:52 < sipa> making it invalid
19:52 < sipa> and making any transaction depending on it invalid
19:52 < CodeShark> same could be said for double-spends, though, no?
19:53 < sipa> those don't happen without malice
19:53 < CodeShark> I gave some examples where they in fact happen without any malice at all
19:53 < sipa> malice or buggyness :)
19:54 < CodeShark> in practice you'd set the expiration sufficiently in the future and set the fee high enough so that this reorg risk is reduced
19:54 < gmaxwell> CodeShark: sipa was faster than me. This creates fungibility problems because now you have transactions dependant on spending recently mined expiring coins, where a perfectly ordinary chance reorg will invalidate enormous amounts of transaction potentially.
19:55 < gmaxwell> CodeShark: the risk is not just to the transaction user, the risk is to all downstream coins... and so you'd have to do blockchain analysis to figure out which coins have what exposure.
19:55 < gmaxwell> (preventing this is part of why the coinbases aren't spendable for 100 blocks)
19:55 < CodeShark> hmm - ok, this is a valid point…trying to think of a way around it
19:56 < sipa> in a world where nobody trust 0-conf transactions, and everyone waits N (with N>2 or so) confirmations before spending anything, that is likely much less of a problem
19:56 < gmaxwell> There are other script features people have wanted that had similar risks.
19:56 < CodeShark> yeah, what sipa just said: accepting transactions with low confirmation count is already somewhat risky - if some of those coins also happen to be near expiration, it's even more risky
19:56 < gmaxwell> sipa: except if you accept N>2  and someone has a transaction which would get killed by an N=3 reorg, you would really want a N>2+3 wait on that coin.
19:57 < CodeShark> the biggest problem, I think, is not so much the risk…this could be managed…but the potential complications in dependency analysis
19:58 < CodeShark> but nothing that couldn't be solved with some well-written code :p
19:58 < sipa> too tired to reason now, but i'm very wary about changing the (apparently very deliberately chosen) rule that a transaction, once valid, is always valid (modulo its inputs becoming unavailable)
19:58 < CodeShark> doesn't seem to be intractable
19:58 < gmaxwell> as far as expirations go, we already have a way to expire: spend one of the contributing inputs. :P
19:58 < sipa> CodeShark: it's completely impossible for SPV wallets to do such analysis
19:58 < sipa> without a local mempool
19:58 < CodeShark> sipa: true
19:59 < CodeShark> well, there could be other partial validation mechanism
19:59 < CodeShark> but that's perhaps a topic for another time :p
19:59 < sipa> that's perhaps more on topic here in the first place :D
19:59 < CodeShark> I'm running into this problem right now as we speak, though - here's the use scenario:
20:00 < CodeShark> (it's not hypothetical - I'm actually doing it for real)
20:00 < CodeShark> you create a joint account with two other people, 2-of-3 signature policy
20:00 < CodeShark> you want to initiate a payment, need approval from at least one other person
20:01 < CodeShark> you provide them with a partially signed transaction
20:01 < CodeShark> now, to invalidate that transaction the way gmaxwell was talking about, you'd also have to incorporate another simple output that only you can redeem
20:02 < CodeShark> so now we need to mix the 2-of-3 policy account with another personal account
20:02 < CodeShark> just to allow us to pull the trigger on it
20:02 < CodeShark> the usability becomes horrendous
20:03 < CodeShark> an expiration time would be a very simple solution to this particular problem
20:03 < sipa> but a very significantly change to force onto every wallet on earth...
20:03 < CodeShark> ?
20:03 < gmaxwell> not just every wallet, but the whole incentive structure of bitcoin
20:03 < CodeShark> you can refuse to accept payments that expire soon
20:04 < gmaxwell> since now you need to think about miners being bribed to reorg or being unwilling to reorg to change to an honest chain because of txn that can't be included.
20:04 < gmaxwell> CodeShark: only if you can determine when the entire (perhaps exponentially sized) history's earliest expiration is.
20:05 < CodeShark> these are healthy concerns - this is why I like to talk to you guys :)
20:06 < sipa> we've heard these suggestion many times already :p
20:06 < CodeShark> however, in a real practical sense right now, one way or another I need a solution - and I don't think deliberately "double-spending" extra outputs is a very clean one, to say the least :)
20:07 < gmaxwell> yea, it's not just applicable to your application. E.g. people have wanted things like lotteries which can read the block hash of some subsiquent confirming block.
20:07 < gmaxwell> CodeShark: why don't you make your protocol such that the originator of the transaction signs last?
20:07 < CodeShark> blinding?
20:07 < CodeShark> hmm
20:07 < CodeShark> that could work
20:08 < CodeShark> yeah, I suppose it does make sense for the originator to be the one who broadcasts (or sends to recipient)
20:08 < maaku> gmaxwell: no i didn't investigate any JS solutions, but "javascript rsa" turns up some hits
20:09 < CodeShark> gmaxwell: without blinding, though, you still have a problem if the originator changes her mind
20:09 < gmaxwell> CodeShark: hm? why? they just don't sign then.
20:09 < CodeShark> but then you get the same issue in reverse
20:09 < CodeShark> now it's the person whose signature was requested that ends up in this unfinished situation
20:10 < gmaxwell> maaku: this is what I'm thinking of proposing, if you care: http://0bin.net/paste/yV7e4WCpZVHEj7nN#fi70f2LMSGO3JyrkNSeOG+ivIpfr2QirZzcNbVc2IXc=
20:10 < CodeShark> if only there were a way to ensure that the signature sharing were atomic :)
20:11 < gmaxwell> CodeShark: whats the problem with everyone except the originator pretending it didn't happen until it ends up in the blockchain?
20:12 < CodeShark> a few: they can't use those outputs without halting a transaction they want to happen, and if they pretend it didn't happen they might overspend their balance
20:12 < gmaxwell> e.g. if the funds in the account form a linked list (e.g. only a linear line of coins) then it's all atomic. Any parallel signatures are mutually exclusive.
20:13 < maaku> gmaxwell: it's a great idea
20:14 < gmaxwell> CodeShark: ISTM you're expecting bitcoin to function as a database for your application giving it SERIALIZABLE atomiticiy for all its data.
20:14 < gmaxwell> thats probably unrealistic in general, because there are probably non-transaction bits of data you'd eventually what to synchronize too.
20:15 < CodeShark> well, there are things like labels, but that's a separate problem for now
20:15 < gmaxwell> Instead of pretending your application is multi-master, it would be a lot simpler to make it master/signer  where all transactions are originated in one point normally (except for exceptional recovery cases)
20:15 < CodeShark> ideally I want to reduce the amount of data that needs to be sent over the block chain
20:16 < maaku> CodeShark: I'm a dissenting voice here. How is nExpireTime any different in principle than a coinbase output?
20:17 < maaku> there are very real advantages to having an nExpireTime, and other scripting extensions which invalidate txns over a reorg
20:17 < maaku> Making users wait to get the desired number of confirmations is not a big hurdle
20:17 < maaku> They should be doing that anyway
20:17 < gmaxwell> maaku: a coinbase output can't be spent in the blockchain for 100 blocks. If you wanted to have an identical limit for outputs from those txn, my objections would go away— except to point out that it's really trying to cram application logic into bitcoin which might be a poor fit.
20:18 < CodeShark> ok, then how about this: set a limit on number of blocks before an nExpireTime transaction is spendable :)
20:18 < maaku> gmaxwell: I don't like the 100 block protocol rule
20:18 < gmaxwell> maaku: I'm sorry for you then.
20:18 < maaku> but i think clients / wallets should implement something similar
20:18 < CodeShark> doesn't have to be 100 blocks
20:18 < sipa> i think 100 is serious overkill, but the reason the rule exists is very real
20:19 < gmaxwell> CodeShark: I think it does need to be 100 blocks, simply because asking wallets to cope with _two_ kinds of behavior is burdensom.
20:19 < maaku> there's no problem building off a txn that can be reorg'd away, but the user interface better have big flashing red lights
20:19 < CodeShark> but require that any transaction confirmed close to the edge of nExpireTime sit on the block chain for a bit before it can be spent
20:19 < gmaxwell> meh, we've had reorg events a substantial fraction of 100.
20:19 < gmaxwell> Imagine we have another long fork event and then we _cannot_ fix it without people forever losing money. Even if there were no malicious spends. egads.
20:20 < CodeShark> the problem, as I understand it, is the potential for a long chain of dependencies from an edge transaction
20:20 < CodeShark> that seems to be the main concern, right?
20:20 < CodeShark> so we can alleviate that concern by taking similar measures as we do for coinbase transactions
20:20 < gmaxwell> maaku: you even have to be able to detect it. a SPV client can't tell how deep the newest expiring input is from some chained coin.
20:21 < maaku> CodeShark: well you'll get to play with this in any case. Freimarkets has an nExpireTime and other reorg-sensitive constructions
20:21 < gmaxwell> maaku: sadly none of that matters unless the system gets serious usage you'll never learn the folly of your ways.
20:21 < gmaxwell> :P
20:21 < CodeShark> if you have an nExpireTime transaction that confirms 100 blocks before expiration, no problem. but if it confirms one block before expiration, it should not be spendable for a few blocks :)
20:21 < maaku> gmaxwell: it could if you had utxo proofs with embedded heights
20:22 < phantomcircuit> zomg yes pizza
20:22 < maaku> (which is one reason why my proposal keeps the height field even though it is not strictly needed)
20:22 < gmaxwell> exponentially in size, since you have to trace the whole history.. having one height isn't good enough.
20:23 < gmaxwell> I guess you could track for every output a shortest-reorg-that-can-kill-it?
20:24 < gmaxwell> e.g. max(height)
20:24 < CodeShark> yeah
20:25 < sipa> bleh
20:25 < maaku> gmaxwell: I honestly don't think the risk is high enough to warrent doing that calculation
20:25 < maaku> which is not easy to do in general beyond the nExpireTime case
20:26 < CodeShark> I tend to concur, maaku
20:26 < gmaxwell> maaku: We've had long >20 block reorgs in bitcoin, where thousands of transactions would have been irrepariably invalidated if there were just one or a few unreorgable coins.
20:27 < gmaxwell> I think you guys are nuts, it's not even a theoretical problem. We've had at least three events where what you would have proposed would _probably_ have caused severe monetary loss if it were widely used.
20:27 < CodeShark> the risk could be mitigated
20:27 < CodeShark> I'm not saying "pretend the risk doesn't exist
20:27 < gmaxwell> and with expirations near the tip, we could be exposed on each and every block.
20:27 < gmaxwell> coins with the risk are not fully fungible with coins without the risk.
20:28 < maaku> gmaxwell: how is that any different than someone watching a major fork in progress, and doing a double-spend?
20:28 < CodeShark> so you simply don't allow spending of those coins for a while
20:28 < maaku> (as actually did happen back in March)
20:28 < maaku> from the perspective of someone building off the transaction, that is
20:28 < gmaxwell> Because it requires someone to actually be malicious, this doesn't.
20:29 < gmaxwell> CodeShark: if _you_ are defining the "a while" then you have an exponential complexity check of the history to make sure an earlier spender didn't use a more lax definition of 'a while'.
20:29 < gmaxwell> making it a rule as we do for coinbases makes it instantly SPV compatible.
20:29 < CodeShark> yes
20:30 < CodeShark> the "while" could be a predetermined, fixed amount
20:30 < gmaxwell> well, then we have such a number already, it's 100.
20:30 < gmaxwell> :P
20:30 < maaku> gmaxwell: there's a very easy way to make it SPV compatible: wait N blocks before taking action based on the txn
20:30 < maaku> you seem to want a user to absolutely trust a txn as soon as it has 1 confirm
20:31 < CodeShark> maaku: the problem is if there's a chain
20:31 < gmaxwell> maaku: egaha. The problem there is that you don't know if a transaction had an inherently risky past in a SPV compatible manner.
20:31 < gmaxwell> E.g. I want to wait 100 for coinbases, 6 for normal payments.  if coinbases were technically spendable at 1, then a spv node couldn't tell your txn was dependant on a coinbase 3 blocks ago.
20:31 < CodeShark> the min reorg depth would need to be somehow propagated through the chain…or the SPV client would need a way to obtain a simple proof of at least a certain depth
20:32 < maaku> so? you want it to be safe from any reorg less than 100 blocks? then wait 100 blocks after it hits the chain
20:32 < CodeShark> the burden of proof could be passed to the payer
20:32 < gmaxwell> also if the rule is not consistent we can't reason about the safty of forks. E.g. we know that coinbases are not spendable before 100 so if we must we can do a 99 block reorg to fix the chain and include no double spends and we won't invalidate any spent coins.
20:33 < maaku> so let the payer use old coins so they can provide a compact proof of stability
20:33 < gmaxwell> Also you've increased communications complexity between the payee and payer. Because as a payer now I need to know the payee has some preference for non-risky coins wich differs from payee to payee.
20:33 < maaku> otherwise, sucks to be them and the merchant makes them wait 100 blocks
20:34 < gmaxwell> having to wait 100 blocks at all times, or having to treat coins as highly non-fungible are both pretty poor solutions.
20:35 < gmaxwell> Esp. when the coin is some small improvement which you couldn't even explain to most people. :P
20:35 < gmaxwell> Perhaps its fine in some other system, I don't think its something we can reasonably do in bitcoin.
20:35 < maaku> well having signatures expire is pretty important when its used ina p2p exchange...
20:35 < maaku> or in a server-to-server consensus mechanism
20:36 < gmaxwell> 17:35 < maaku> or in a server-to-server consensus mechanism
20:36 < gmaxwell> yea... except dear gods, the bitcoin blockchain is NOT a communications mechenism for your server to server consensus!  _global broadcast network_
20:36 < maaku> gmaxwell: using the public chain as a semaphore for two-phase commit of a distributed transaction over multiple private asset servers
20:37 < gmaxwell> your asset servers are known in advance! use a freeking ordinary consensus.
20:37 < maaku> that's why we haven't even tried to get anyone onboard with deploying Freimarkets to bitcoin
20:37 < maaku> i just assume it wouldn't fly
20:38 < maaku> gmaxwell: you need to hit the public chain for public<-->private txns
20:39 < maaku> (e.g. atomic swaps of freicoins for private assets)
20:39 < gmaxwell> For anything like that you have a small number (because multisig scalablity) of known-in-advance servers. Which means you can do a regular n-of-m consensus totally external to bitcoin. E.g. an initatior proposes a distributed database update and get a supermajority of the servers to sign off on it.
20:39 < CodeShark> ok, perhaps amore interesting theoretical question (whose solution would work just as well for my problem): is there a practical way to achieve atomic data swaps between multiple entities?
20:40 < CodeShark> homomorphic encryption?
20:41 < CodeShark> would it require quantum crypto? :)
20:41 < gmaxwell> CodeShark: you basically want two people to trade data such that they either both get the data or neither do?
20:41 < CodeShark> exactly
20:42 < CodeShark> and the outcome shouldn't take forever to determine :)
20:42 < gmaxwell> I don't know if its possible, unless you assume both parties are equally computationally bounded.
20:43 < CodeShark> or you use quantum crypto
20:43 < gmaxwell> I'm not even sure how you'd do it with quantum crypto.
20:44 < gmaxwell> lemme think for a minute.
20:45 < gmaxwell> It has to be a two party protocol?  Can the protocol have N bystanders who help out, and the protocol is fair if most of the bystandards are honest?
20:46 < gmaxwell> I can give you protocols for this, but they don't work for the two-party case because they need an honest majority.
20:46 < CodeShark> escrow?
20:46 < CodeShark> yeah, the two party case seems to have much more profound theoretical implications
20:47 < gmaxwell> yea, kinda, you split the data up N ways such that N/2+1 can reveal. And then N/2+1 reveals to both and you're done. Of course it can be encrypted so that no one but the right parties learn anything.
20:47 < gmaxwell> With N=2 I think the best I can do involves bitcommitments and a cheater can terminate the protocol early and know 1 more bit than the other guy, plus then they can do computation to grind out the answer.
20:48 < gmaxwell> e.g. say you both can afford 2^64 work to grind out a missing key.  I abort the protocol early so that I am missing 64 bits and you are missing 65. It's even worse if the parties are computationally unbalanced.
20:49 < gmaxwell> e.g. you can afford 2^32 and I can afford 2^64. I can terminate it after learning K-64 bits and you're just screwed.
20:49 < CodeShark> right
20:51 < gmaxwell> I know there are some protocols which claim to be able to achieve 2-party active secure multiparty computation. So I suppose I should go look and find out what the catch is, becuase I think thats not possible.
20:51 < gmaxwell> (for the same reason as here)
20:51 < CodeShark> not even with quantum crypto?
20:53 < gmaxwell> I think if you can do it with quantum crypto then you can make something secure in the CRS model (e.g. where there is some magic trusted random tape).
21:06 < brisque> would anybody be available to help me isolate some network oddness? trying to work out if something I'm seeing is my peers behaving badly, or something on a larger scale.
21:06 < CodeShark> what are you seeing?
21:07 < brisque> I'm getting huge floods of double spend attempts in my logs- I know it's not an issue but it's extremely persistent
21:08 < brisque> usually around block boundaries I get 60+ transactions spending spent outputs, which is strange in my eyes. big blocks milliseconds apart.
21:08 < gmaxwell> brisque: I don't think thats anything too new or interesting, some things, e.g. bc.i uselessly flood peers with double spends.
21:08 < gmaxwell> also I think coinbase does this.
21:09 < gmaxwell> after a block that doesn't have some unconfirmed transaction it has, it uselessly floods all its peers readverting them, even if they're conflicted.
21:09 < brisque> ah. I've banned blockchain.info for that, but I wasn't aware anybody else decided it was a good idea.
21:32 < brisque> I'm definitely connected to blockchain.info or coinbase's nodes, but I've no way of knowing which they are out of hundreds of peers. might be a rainy day project to try and isolate them somehow.
21:53 < gmaxwell> brisque: unfortunately it's hard to distinguish idiotic spamming of conflicted transactions vs honest spamming of them from a peer which isn't quite caught up with the blockchain.
21:53 < gmaxwell> If it were, we could just automatically ban those nodes.
21:58 < brisque> gmaxwell: if you were intent on identifying one of the mentioned services, you presumably could just listen and isolate it by forcing the service to broadcast known transactions and measuring the latency. I don't have any inclination to, but even if they're not listening (I'm sure they're not) you could eventually find them. the number of listening nodes in the network is quite small after all, anyone with enough
21:59 < brisque> I seem to remember that Bitcoind avoids talking to multiple peers in the same network, which would make that more difficult of course.
22:01 < gmaxwell> well mostly I think this crap wastes a lot of bandwidth, but right now people have very little incentive to write compently authored node software in any case that won't get them banned.
22:05 < brisque> I suppose bandwidth is cheap enough that nobody cares. ultimately their dodgy patches will just lead to them not updating, which is the real risk.
22:10 < gmaxwell> it's already the case... well it's not just 'dodgy patches', e.g. coinbase has their own node software... and yea, they get isolated from time to time as a result.
22:10 < gmaxwell> The bandwidth might be cheap for them, but it's pretty inconsiderate to the network.
22:10 < brisque> oh god. seriously!?
22:11 < gmaxwell> yea.
22:11 < brisque> why would anybody running a financial service run their own bitcoin node!?
22:11 < gmaxwell> And expose it directly to the world too.
22:12 < gmaxwell> In any case, maybe we could just keep a count of doublespends per-peer preferentially kick the worst offender.
22:13 < brisque> that's just ridiculous. the cost involved in building their own bitcoin node would far outstrip any benefit they would gain from it. no wonder they needed piles of VC money.
22:13 < brisque> it explains a lot, why their outgoing transactions are so slow, get stuck, often don't get broadcast.
22:14 < gmaxwell> it's not just that, if someone goes and finds yet another way to get them to reject the real chain, (which has happened by accident many times) they can potentially buy a bit of hashpower and rob them blind.
22:15 < gmaxwell> ... though in that particular case, I guess its not even the low hanging fruit. At least a month ago it was possible to deposit, and then withdraw before it confirmed.... (I reported it to them, dunno if they fixed it)
22:15 < brisque> surely they would have paid a bug bounty for you. they have a minimum 5BTC policy.
22:15 < brisque> that's an obscenely bad bug for an online wallet to have
22:15 < Luke-Jr> gmaxwell: now I can't even sell until it confirms :/
22:16 < gmaxwell> oh I guess they fixed it then.
22:16 < gmaxwell> brisque: I didn't ask about that.  .. hell I wasn't even trying to discover it. Worse, in the case where I discovered this there was actually a double spend on the network, and I could have _accidentally_ ripped them off.
22:17 < brisque> I think you could have the QT client scream "DONT ACCEPT ZERO CONF TRANSACTIONS" every 5 minutes and people would still do it.
22:18 < brisque> gmaxwell: I'm shocked nobody had realised that before.
22:19 < brisque> oh, coinbase have changed their responsible disclosure police. it's now minimum $1000 rather than 5BTC. guess they got bitten by the exchange rate.
22:19 < gmaxwell> (it was at a time when mtgox was having problems, and I transfered from mtgox to coinbase, .. and mtgox made a conflicting doublespend... so not only did I withdraw unconfirmed coins, I did so at a time when .. if things confirmed in a different order it would have ripped them off)
22:19 < gmaxwell> ... to the tune of something like $30,000.
22:19 < gmaxwell> (I wasn't aware of the second mtgox payment... lol.. or I wouldn't have done something so potentially confusable as an attempt at theft!)
22:20 < brisque> either way, lucky you found it rather than somebody who would have exploited it.
22:20 < gmaxwell> in any case, if you look around you can find horrifying stories about almost every bitcoin service.
22:21 < gmaxwell> brisque: Well, maybe thats what the VC money is for: to cover hemoraging money from failures like that. :P
22:21 < gmaxwell> BTC-e has has some really severe money loss events and somehow keeps on trucking.
22:22 < brisque> fractional reserve?
22:22 < gmaxwell> maybe!
22:22 < gmaxwell> e.g. someone figured out how to impersonate the liberty reserve deposit callback and then gave themselves infinite btc-e USD.
22:22 < gmaxwell> and then bought up and withdrew all coins that appeared in the btc-e hotwallet.
22:22 < gmaxwell> ... for something like 12 hours.
22:23 < gmaxwell> btc-e price per bitcoin went to >$100 (when btc had been at like $10 or something) and so lots of idiots deposited more coin.
22:24 < brisque> you'd think a service like that would have some sort of checks and balances that sees someone with unlikely situations and freezes the site until it can be verified. better that than losing out.
22:24 < gmaxwell> mtgox now does some of that, though I think probably not enough.
22:25 < gmaxwell> at least these things should freeze deposits and withdrawls... anything purely internal can at least be made right later.
22:25 < gmaxwell> But I suspect that the pretty good incomes from running the sites coupled with fractional reserve can make up for a lot of mistakes.
22:26 < brisque> until there's a bank run, and then they're completely high and dry
22:27 < gmaxwell> Failure is always an option.
22:28 < gmaxwell> I'm not aware of a _single_ major bitcoin business operator who has faced _civil_, much less criminal, charges for their default.
22:28 < pigeons> i guess calling trendon sahvors/pirate@40 a business operator would be a stretch
22:29 < phantomcircuit> gmaxwell, er
22:29  * phantomcircuit raises hand
22:29 < gmaxwell> okay, fair, I'd even include that since a lot of people did think it was real. (::facepalm::)  has he actually suffered any consequences for it?
22:30 < pigeons> he got a default judegemnt by the sec cause he stopped responding to the court
22:30 < phantomcircuit> oh charges
22:30 < phantomcircuit> didn't see that
22:30 < gmaxwell> phantomcircuit: well I'm not counting bitcoinica because the actual owner and responsible party dropped the bag of shit in someone elses lap!
22:30 < pigeons> and now the fbi is finishing their investigation
22:30 < phantomcircuit> gmaxwell, charges usually refers to government action also
22:30 < phantomcircuit> gov can take civil action which i believe is what they did against shavers
22:31 < phantomcircuit> or however the fuck you spell his name
22:31 < pigeons> these are the shavers docs. http://ia800904.us.archive.org/35/items/gov.uscourts.txed.146063/
22:31 < gmaxwell> thats what they did against him, yea.
22:31 < pigeons> yes and i hear criminal is coming soon against shavers
22:31 < brisque> the point being that even under the most abstract failure, most sites simply disappear when something goes wrong.
22:31 < phantomcircuit> so looks like hashfast isn't going to delivery
22:31 < phantomcircuit> deliver*
22:31 < gmaxwell> phantomcircuit: nope, they're not.
22:31 < pigeons> not only do they disappear, they reopen using the same identity
22:32 < gmaxwell> They've also announced that they aren't planning to honor their original comittments to refunds.
22:32 < pigeons> coinjar.io
22:32 < brisque> I enjoyed the inputs.io thread particularly. by the looks of things all the "security" advertised either didn't work or didn't even exist in the first place.
22:32 < phantomcircuit> i actually knew this like two weeks ago
22:32 < phantomcircuit> but i find it amusing watching people find out they're fucked
22:32 < gmaxwell> I'm trying to figure out what I'm going to do about that, as I have two orders with them, along with email correspondance confirming that their refund commitment was to refund the full amount of BTC paid.
22:32 < gmaxwell> The problem, of course, is that if I sue them they'll just bankrupt themselves defending it, and there will be nothing to recover.
22:33 < brisque> they'll end up delivering something I assume
22:33 < phantomcircuit> gmaxwell, my guess is they dont have the capital to do a full production run and were delaying hoping to get enough new orders to do the run
22:33 < phantomcircuit> they didn't hit the target and are now completely screwed
22:33 < phantomcircuit> this is of course fraud
22:34 < phantomcircuit> gmaxwell, it's likely criminal
22:34 < phantomcircuit> but i doubt it's worth anybodies time to pursue
22:34 < brisque> is a poor lack of judgement criminal?
22:34 < gmaxwell> brisque: yea, but at this point its so late that anything they deliver will be a massive loss. To entice batch 1 customers they initially claimed target shipment on Oct 20th, and a full refund of the BTC amount paid if they don't make dec 31st.
22:34 < gmaxwell> brisque: Its become pretty hard to believe that they ever thought they could deliver on what they promised.
22:35 < phantomcircuit> gmaxwell, fun fact hashfast was trying to sell chips in bulk recently
22:35 < phantomcircuit> possibly they have the chips but they dont work
22:35 < phantomcircuit> or they cant put them on boards
22:35 < phantomcircuit> or they cant get components
22:35 < phantomcircuit> or ???
22:35 < gmaxwell> they have some demo videos now actually showing a test unit hashing,
22:35 < brisque> gmaxwell: from what I've read it looks like they underestimated the complexity, underestimated the power draw (needing new power supplies), and burnt all their funds trying to rectify it all.
22:35 < gmaxwell> and I believe that its real (esp since one of the people in #eligius went to visit them and saw it)
22:36 < gmaxwell> brisque: nah, their power was on target (you might have been duped by someone's joke post... which was sadly a little too believable)
22:36 < gmaxwell> this is the epic timeline post: https://bitcointalk.org/index.php?topic=391251.0
22:37 < brisque> gmaxwell: I wasn't duped by that post, there's a hashfast comment that they needed to order new PCB designs of a new revision.
22:37 < gmaxwell> brisque: oh that, yea, I assumed it was just a design error.
22:37 < phantomcircuit> gmaxwell, they might have the chips
22:37 < phantomcircuit> which i assume they could sell
22:37 < phantomcircuit> so possibly bankruptcy would actually be useful
22:38 < phantomcircuit> but there is no way they can actually refund people in btc
22:38 < Luke-Jr> phantomcircuit: yes there is
22:38 < brisque> hashfasts design is useless anyway. it's cheaper to just buy other designs at this point.
22:38 < phantomcircuit> Luke-Jr, if they kept the btc?
22:38 < Luke-Jr> phantomcircuit: exactly
22:38 < gmaxwell> phantomcircuit: it actually appears that they did though its hard to be sure.
22:39 < brisque> Luke-Jr: isn't there a comment about them using Bitpay, which would go to USD instantly?
22:39 < gmaxwell> brisque: they took both direct payments and bitpay, and bitpay lets the merchant choose.
22:39 < Luke-Jr> brisque: BitPay offers that *option*, but it isn't required
22:39 < phantomcircuit> gmaxwell, huh interesting
22:39 < brisque> Luke-Jr: I wasn't aware of that, interesting
22:40 < gmaxwell> the other fucked up thing is that they're claiming that you have only 15 days to request a refund, which they'll just refund a tiny fraction of the BTC paid (and a bit less than half of what you could expect to mine if they ship early january), and if you don't elect a refund in that window you can't have one.
22:41 < gmaxwell> so it looks like an optimal (scummy) strategy for them is to just build the boxes and start mining and say fuck you to everyone who doesn't refund until march.
22:41 < gmaxwell> so you either lock in an 86% loss by refunding, or take a risk that they'll do something shitty like that.
22:41 < brisque> I suppose they messed up and they're quite afraid of the consequences. I don't blame them for acting irrationally.
22:43 < gmaxwell> brisque: yea, though part of the issue is that no one has yet proposed a conceivable explination for their actions which doesn't involve fraud.
22:43 < gmaxwell> e.g. messing up doesn't explain why they were saying they were on time just a few days before they mised their original oct 20 target, and yet it turns out they didn't get anything from the fab until mid dec.
22:44 < gmaxwell> I guess the most charitable explination I can come up with is the one phantomcircuit mentioned— that they didn't raise enough money for the fab run until fairly late... but that still involves them lying about their schedule continually since november.
22:44 < brisque> gmaxwell: I can certainly relate to them from reading that timeline. you mess up a little and tell yourself that it will be alright, you can save face if you just pretend you don't make it clear. things crumble under them and they've just got to keep continuing on so as to not admit they lied in the first place.
22:45 < brisque> it's schoolchildren mentality, but there you go.
22:47 < gmaxwell> they could do other things to make it right. Their COGS on these devices should be very low. They _should_ be able to afford to double everyones order, for example.. which is what cointerra did for their december orders.
22:47 < gmaxwell> but god knows, maybe their had a failed spin.
22:48 < gmaxwell> s/their/they/
22:49 < brisque> that market is fascinating really. we have BFL, Avalon, Hashfast and Bitfury all acting quite strangely for companies
22:49 < brisque> I can't fathom what's going on with Bitfury and ghash.io. by the looks of things they own most of the network with their own hardware.
22:51 < brisque> frustratingly there's very little information about what ghash.io actually is, and what Bitfury is doing behind the scenes with it
22:59 < gmaxwell> the old "miners will avoid violating the security assumptions for fear of making their coins worthless" argument turns out to fail because its possible to violate the assumptions and keep them secret, and people are willing to gamble that no one will notice or care if the security assumptions are violated.
23:03 < brisque> easy enough to hide your hashrate with a fake pool anyway or by replicating coinbases.
23:03 < brisque> do you like Luke would notice if I mined a block with Eligius.st's coinbase?
23:05 < brisque> back to the point, I don't think anybody would notice or care in a wider sense if Bitfury took a larger potion of the network. as it stands his portion is absolutely massive, and has some real world attacks under it's belt.. yet there's nothing really that anybody can do about it.
23:07 < gmaxwell> well, for one, they could stop giving him _more_ hashpower. :P
23:07 < gmaxwell> best estimatimates still have 1/2 to 1/3 of ghash.io's hashpower is third party.
23:08 < phantomcircuit> brisque, bitfury supplies cex.io which uses ghash.io
23:08 < gmaxwell> they could also stop buying more insanely priced chips from him, since every chip you buy from him pays for him to put 10x more than that chip onto his own farm.
23:08 < phantomcircuit> they're actually different people
23:08 < phantomcircuit> but since they're all ukrainians with weird names nobody can tell
23:09 < gmaxwell> phantomcircuit: I don't believe they are. They claim to be, but evidence I've seen suggests it's one person with a couple employees.
23:09 < phantomcircuit> gmaxwell, it's definitely different people
23:09 < phantomcircuit> they are obviously very close though
23:10 < nessence> are dzminercoop guys legit?
23:15 < CodeShark> gmaxwell: https://github.com/CodeShark/bips/blob/master/bip-n1.mediawiki
23:17 < gmaxwell> CodeShark: you realize that partially signed transactions are already implemented by bitcoin-qt, bitrated, brainwallet, and a half dozen other things, right?
23:18 < CodeShark> is there a standard?
23:19 < CodeShark> many "partially signed transaction" implementations I've seen just blank out entire input scripts
23:19 < CodeShark> which makes some of the use cases I'm considering impossible
23:20 < gmaxwell> A defacto one at least. I'm not sure what you mean by "entire input scripts"
23:20 < CodeShark> as in the entire input script is blanked
23:20 < maaku> CodeShark: what use cases are you considering?
23:21 < maaku> or rather, what do you need to do?
23:21 < CodeShark> maaku: the main thing for me right now is supporting p2sh
23:22 < CodeShark> especially in cases where the signing devices don't know anything about the scripts a priori
23:22 < CodeShark> they just need to know whether they can sign and if they sign what the implications are
23:24 < CodeShark> IMO, the signatures should have been kept as a separate list structure in the txin
23:24 < CodeShark> rather than making them part of the script :p
23:24 < CodeShark> but that's another story
23:24 < CodeShark> an account management app keeps track of script pairs (txinscript/txoutscript)
23:25 < CodeShark> the txinscript just have placeholders for signatures
23:25 < CodeShark> the signing devices just keep keychains
23:25 < CodeShark> they don't even need to know about the scripts a priori at all
23:26 < CodeShark> this will allow a good separation between account management/inbound payment processing tools (a.k.a. watch-only wallets) and signing devices
23:26 < maaku> CodeShark: why is scriptSig connected to p2sh?
23:26 < maaku> don't they figure that out by looking at the scriptPubKey?
23:27 < CodeShark> no
23:27 < CodeShark> the scriptPubKey for a p2sh only holds a hash of the script
23:27 < CodeShark> which is useless to anyone who doesn't already know the script
23:27 < maaku> ok so you're partially constructing the p2sh scriptSig
23:28 < maaku> (a) wallets probably already know the scripts (but I can imagine cases where they do not)
23:28 < maaku> (b) pass it out-of-band
23:28 < CodeShark> yes
23:28 < CodeShark> I like the p2sh approach generally - it's the recipient's responsibility to know how to claim the output
23:29 < CodeShark> the sender doesn't really care
23:33 < CodeShark> I mean, there could be conceivable cases where the sender cares - but not for the use cases under consideration here
23:33 < gmaxwell>  ... https://bitcointalk.org/index.php?topic=392166.0  < KNC miner botnet.
23:36 < CodeShark> the out-of-band stuff is the principal motivation, maaku - I'm trying to develop a signing request protocol…might turn out to be a natural extension of the payment protocol
23:36 < CodeShark> a "generalized" payment protocol, so to speak
23:37 < CodeShark> which works for multisigs, coinjoin, internal company policy, merchants, and several other use cases
23:37 < phantomcircuit> gmaxwell, he's just brute forcing the passwords for web exposed boxes
23:37 < phantomcircuit> it's comical anybody has web exposed boxes at all
23:37 < gmaxwell> phantomcircuit: yea, sort of, except he can do an offline brute force, which digest auth is supposted to prevent.
23:37 < gmaxwell> presumably it uses a constant nonce or something stupid like that.
23:38 < phantomcircuit> probably
23:38 < maaku> why the hell was this posted online?
23:38 < phantomcircuit> but still
23:38 < phantomcircuit> maaku, the guy who found it decided to
23:40 < gmaxwell> someone reported the post and asked me to remove it, but I think its too late.
23:40 < maaku> phantomcircuit: i understand, but besides being unethical it is illegal with legal implicaitons if any of those boxes do get hacked
23:40 < phantomcircuit> maaku, publishing an exploit like that isn't illegal
23:40 < gmaxwell> in the grand scheme of shitty behavior in bitcoin land, someone hacking miners to divert them is probably the most minor.
23:40 < phantomcircuit> admitting to breaking into 28 boxes is
23:41 < phantomcircuit> gmaxwell, well he is basically rootkitting them
23:41 < gmaxwell> hehe 'most minor'
23:41 < phantomcircuit> those 28 people are going to have to pull the sd card to fix them
23:41 < maaku> phantomcircuit: depends on your jurisdiction, but yes publishing exploits is typically illegal
23:41 < gmaxwell> he said he didn't actually do that.
23:41 < maaku> if done in a negligent way
23:41 < phantomcircuit> oh i missed that part
23:42 < phantomcircuit> maaku, not in parts of the world with freedom
23:42 < gmaxwell> maaku: illegal? probably not. Exposes him to civil claims, perhaps.
23:42 < phantomcircuit> im going to assume he doesn't live in north korea
23:42 < phantomcircuit> since he's on the internet
23:42 < gmaxwell> actually reading again, I'm not sure what he's saying.
23:43 < gmaxwell> http digest auth doesn't prevent bruteforcing, and it actually does sound like he's doing a regular bruteforce attack. kinda boring.
23:44 < maaku> phantomcircuit: North Korea? try France, for example. In the U.S. this is borderline. see: https://www.eff.org/issues/coders/vulnerability-reporting-faq
23:44 < phantomcircuit> maaku, im not aware of anybody who has even been prosecuted in the us for disclosing a flaw
23:45 < phantomcircuit> numerous people have been subsequently accused of using the flaw under the assumption they the attack happened before they had disclosed it
23:45 < phantomcircuit> so thye must have been the attacker
23:45 < phantomcircuit> but that's not the same thing
23:50 < CodeShark> the funny thing is that this guy's "exposure of vulnerability" applies just about to pretty much any device connected directly to the Internet :p
23:50 < CodeShark> so it's not so much an exposure as it is just another example of a well-known attack
23:55 < maaku> CodeShark: it's pointing people at the factor reset script and config files to update which is more unique
23:55 < maaku> not hard to figure out by anyone technically compitent, but he reduced it down to script kiddie level
23:57 < CodeShark> the hard part is getting root access :p
23:58 < CodeShark> but yeah, this guy sounds a tad bit too boastful
--- Log closed Tue Dec 31 00:00:42 2013