| 00:45:00 | robert222: | Bitmessage 2.0 |
| 00:45:08 | robert222: | http://twister.net.co/ |
| 00:45:18 | robert222: | "Introducing Twister: a fully decentralized P2P microblogging platform leveraging both the Bitcoin and BitTorrent protocols. " |
| 00:45:21 | robert222: | robert222 has left #bitcoin-wizards |
| 00:50:54 | sipa: | kthxbye |
| 00:51:10 | CodeShark: | https://github.com/CodeShark/bips/blob/master/bip-n2.mediawiki |
| 00:51:32 | CodeShark: | gmaxwell, sipa: please, tell me why this is a bad idea :) |
| 00:52:30 | sipa: | if a transaction gets included right at the edge, a reorganization could push it over the limit |
| 00:52:34 | sipa: | making it invalid |
| 00:52:42 | sipa: | and making any transaction depending on it invalid |
| 00:52:54 | CodeShark: | same could be said for double-spends, though, no? |
| 00:53:08 | sipa: | those don't happen without malice |
| 00:53:23 | CodeShark: | I gave some examples where they in fact happen without any malice at all |
| 00:53:34 | sipa: | malice or buggyness :) |
| 00:54:24 | 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 |
| 00:54:40 | 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. |
| 00:55:14 | 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. |
| 00:55:29 | gmaxwell: | (preventing this is part of why the coinbases aren't spendable for 100 blocks) |
| 00:55:44 | CodeShark: | hmm - ok, this is a valid point…trying to think of a way around it |
| 00:56:01 | 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 |
| 00:56:12 | gmaxwell: | There are other script features people have wanted that had similar risks. |
| 00:56:48 | 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 |
| 00:56:55 | 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. |
| 00:57:36 | CodeShark: | the biggest problem, I think, is not so much the risk…this could be managed…but the potential complications in dependency analysis |
| 00:58:02 | CodeShark: | but nothing that couldn't be solved with some well-written code :p |
| 00:58:11 | 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) |
| 00:58:12 | CodeShark: | doesn't seem to be intractable |
| 00:58:14 | gmaxwell: | as far as expirations go, we already have a way to expire: spend one of the contributing inputs. :P |
| 00:58:41 | sipa: | CodeShark: it's completely impossible for SPV wallets to do such analysis |
| 00:58:49 | sipa: | without a local mempool |
| 00:58:53 | CodeShark: | sipa: true |
| 00:59:06 | CodeShark: | well, there could be other partial validation mechanism |
| 00:59:15 | CodeShark: | but that's perhaps a topic for another time :p |
| 00:59:28 | sipa: | that's perhaps more on topic here in the first place :D |
| 00:59:46 | CodeShark: | I'm running into this problem right now as we speak, though - here's the use scenario: |
| 01:00:07 | CodeShark: | (it's not hypothetical - I'm actually doing it for real) |
| 01:00:31 | CodeShark: | you create a joint account with two other people, 2-of-3 signature policy |
| 01:00:54 | CodeShark: | you want to initiate a payment, need approval from at least one other person |
| 01:01:05 | CodeShark: | you provide them with a partially signed transaction |
| 01:01:42 | 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 |
| 01:02:09 | CodeShark: | so now we need to mix the 2-of-3 policy account with another personal account |
| 01:02:23 | CodeShark: | just to allow us to pull the trigger on it |
| 01:02:40 | CodeShark: | the usability becomes horrendous |
| 01:03:13 | CodeShark: | an expiration time would be a very simple solution to this particular problem |
| 01:03:30 | sipa: | but a very significantly change to force onto every wallet on earth... |
| 01:03:43 | CodeShark: | ? |
| 01:03:52 | gmaxwell: | not just every wallet, but the whole incentive structure of bitcoin |
| 01:03:59 | CodeShark: | you can refuse to accept payments that expire soon |
| 01:04:23 | 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. |
| 01:04:51 | gmaxwell: | CodeShark: only if you can determine when the entire (perhaps exponentially sized) history's earliest expiration is. |
| 01:05:50 | CodeShark: | these are healthy concerns - this is why I like to talk to you guys :) |
| 01:06:16 | sipa: | we've heard these suggestion many times already :p |
| 01:06:41 | 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 :) |
| 01:07:08 | 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. |
| 01:07:28 | gmaxwell: | CodeShark: why don't you make your protocol such that the originator of the transaction signs last? |
| 01:07:38 | CodeShark: | blinding? |
| 01:07:40 | CodeShark: | hmm |
| 01:07:44 | CodeShark: | that could work |
| 01:08:20 | CodeShark: | yeah, I suppose it does make sense for the originator to be the one who broadcasts (or sends to recipient) |
| 01:08:37 | maaku: | gmaxwell: no i didn't investigate any JS solutions, but "javascript rsa" turns up some hits |
| 01:09:16 | CodeShark: | gmaxwell: without blinding, though, you still have a problem if the originator changes her mind |
| 01:09:35 | gmaxwell: | CodeShark: hm? why? they just don't sign then. |
| 01:09:44 | CodeShark: | but then you get the same issue in reverse |
| 01:09:57 | CodeShark: | now it's the person whose signature was requested that ends up in this unfinished situation |
| 01:10:11 | gmaxwell: | maaku: this is what I'm thinking of proposing, if you care: http://0bin.net/paste/yV7e4WCpZVHEj7nN#fi70f2LMSGO3JyrkNSeOG+ivIpfr2QirZzcNbVc2IXc= |
| 01:10:56 | CodeShark: | if only there were a way to ensure that the signature sharing were atomic :) |
| 01:11:39 | gmaxwell: | CodeShark: whats the problem with everyone except the originator pretending it didn't happen until it ends up in the blockchain? |
| 01:12:51 | 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 |
| 01:12:52 | 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. |
| 01:13:02 | maaku: | gmaxwell: it's a great idea |
| 01:14:07 | gmaxwell: | CodeShark: ISTM you're expecting bitcoin to function as a database for your application giving it SERIALIZABLE atomiticiy for all its data. |
| 01:14:38 | gmaxwell: | thats probably unrealistic in general, because there are probably non-transaction bits of data you'd eventually what to synchronize too. |
| 01:15:06 | CodeShark: | well, there are things like labels, but that's a separate problem for now |
| 01:15:24 | 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) |
| 01:15:32 | CodeShark: | ideally I want to reduce the amount of data that needs to be sent over the block chain |
| 01:16:26 | maaku: | CodeShark: I'm a dissenting voice here. How is nExpireTime any different in principle than a coinbase output? |
| 01:17:03 | maaku: | there are very real advantages to having an nExpireTime, and other scripting extensions which invalidate txns over a reorg |
| 01:17:34 | maaku: | Making users wait to get the desired number of confirmations is not a big hurdle |
| 01:17:52 | maaku: | They should be doing that anyway |
| 01:17:54 | 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. |
| 01:18:22 | CodeShark: | ok, then how about this: set a limit on number of blocks before an nExpireTime transaction is spendable :) |
| 01:18:23 | maaku: | gmaxwell: I don't like the 100 block protocol rule |
| 01:18:32 | gmaxwell: | maaku: I'm sorry for you then. |
| 01:18:34 | maaku: | but i think clients / wallets should implement something similar |
| 01:18:35 | CodeShark: | doesn't have to be 100 blocks |
| 01:18:49 | sipa: | i think 100 is serious overkill, but the reason the rule exists is very real |
| 01:19:00 | gmaxwell: | CodeShark: I think it does need to be 100 blocks, simply because asking wallets to cope with _two_ kinds of behavior is burdensom. |
| 01:19:11 | 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 |
| 01:19:12 | 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 |
| 01:19:19 | gmaxwell: | meh, we've had reorg events a substantial fraction of 100. |
| 01:19:44 | 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. |
| 01:20:00 | CodeShark: | the problem, as I understand it, is the potential for a long chain of dependencies from an edge transaction |
| 01:20:13 | CodeShark: | that seems to be the main concern, right? |
| 01:20:28 | CodeShark: | so we can alleviate that concern by taking similar measures as we do for coinbase transactions |
| 01:20:43 | 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. |
| 01:21:07 | maaku: | CodeShark: well you'll get to play with this in any case. Freimarkets has an nExpireTime and other reorg-sensitive constructions |
| 01:21:32 | gmaxwell: | maaku: sadly none of that matters unless the system gets serious usage you'll never learn the folly of your ways. |
| 01:21:36 | gmaxwell: | :P |
| 01:21:49 | 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 :) |
| 01:21:50 | maaku: | gmaxwell: it could if you had utxo proofs with embedded heights |
| 01:22:18 | phantomcircuit: | zomg yes pizza |
| 01:22:22 | maaku: | (which is one reason why my proposal keeps the height field even though it is not strictly needed) |
| 01:22:25 | gmaxwell: | exponentially in size, since you have to trace the whole history.. having one height isn't good enough. |
| 01:23:56 | gmaxwell: | I guess you could track for every output a shortest-reorg-that-can-kill-it? |
| 01:24:35 | gmaxwell: | e.g. max(height) |
| 01:24:54 | CodeShark: | yeah |
| 01:25:00 | sipa: | bleh |
| 01:25:02 | maaku: | gmaxwell: I honestly don't think the risk is high enough to warrent doing that calculation |
| 01:25:19 | maaku: | which is not easy to do in general beyond the nExpireTime case |
| 01:26:14 | CodeShark: | I tend to concur, maaku |
| 01:26:20 | 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. |
| 01:27:00 | 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. |
| 01:27:15 | CodeShark: | the risk could be mitigated |
| 01:27:27 | CodeShark: | I'm not saying "pretend the risk doesn't exist |
| 01:27:31 | gmaxwell: | and with expirations near the tip, we could be exposed on each and every block. |
| 01:27:54 | gmaxwell: | coins with the risk are not fully fungible with coins without the risk. |
| 01:28:01 | maaku: | gmaxwell: how is that any different than someone watching a major fork in progress, and doing a double-spend? |
| 01:28:04 | CodeShark: | so you simply don't allow spending of those coins for a while |
| 01:28:07 | maaku: | (as actually did happen back in March) |
| 01:28:30 | maaku: | from the perspective of someone building off the transaction, that is |
| 01:28:48 | gmaxwell: | Because it requires someone to actually be malicious, this doesn't. |
| 01:29:21 | 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'. |
| 01:29:47 | gmaxwell: | making it a rule as we do for coinbases makes it instantly SPV compatible. |
| 01:29:54 | CodeShark: | yes |
| 01:30:15 | CodeShark: | the "while" could be a predetermined, fixed amount |
| 01:30:27 | gmaxwell: | well, then we have such a number already, it's 100. |
| 01:30:28 | gmaxwell: | :P |
| 01:30:34 | maaku: | gmaxwell: there's a very easy way to make it SPV compatible: wait N blocks before taking action based on the txn |
| 01:30:52 | maaku: | you seem to want a user to absolutely trust a txn as soon as it has 1 confirm |
| 01:31:00 | CodeShark: | maaku: the problem is if there's a chain |
| 01:31:08 | 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. |
| 01:31:48 | 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. |
| 01:31:57 | 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 |
| 01:32:08 | maaku: | so? you want it to be safe from any reorg less than 100 blocks? then wait 100 blocks after it hits the chain |
| 01:32:40 | CodeShark: | the burden of proof could be passed to the payer |
| 01:32:49 | 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. |
| 01:33:18 | maaku: | so let the payer use old coins so they can provide a compact proof of stability |
| 01:33:28 | 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. |
| 01:33:33 | maaku: | otherwise, sucks to be them and the merchant makes them wait 100 blocks |
| 01:34:42 | gmaxwell: | having to wait 100 blocks at all times, or having to treat coins as highly non-fungible are both pretty poor solutions. |
| 01:35:03 | gmaxwell: | Esp. when the coin is some small improvement which you couldn't even explain to most people. :P |
| 01:35:19 | gmaxwell: | Perhaps its fine in some other system, I don't think its something we can reasonably do in bitcoin. |
| 01:35:38 | maaku: | well having signatures expire is pretty important when its used ina p2p exchange... |
| 01:35:55 | maaku: | or in a server-to-server consensus mechanism |
| 01:36:10 | gmaxwell: | 17:35 < maaku> or in a server-to-server consensus mechanism |
| 01:36:44 | gmaxwell: | yea... except dear gods, the bitcoin blockchain is NOT a communications mechenism for your server to server consensus! _global broadcast network_ |
| 01:36:54 | maaku: | gmaxwell: using the public chain as a semaphore for two-phase commit of a distributed transaction over multiple private asset servers |
| 01:37:42 | gmaxwell: | your asset servers are known in advance! use a freeking ordinary consensus. |
| 01:37:48 | maaku: | that's why we haven't even tried to get anyone onboard with deploying Freimarkets to bitcoin |
| 01:37:53 | maaku: | i just assume it wouldn't fly |
| 01:38:28 | maaku: | gmaxwell: you need to hit the public chain for public<-->private txns |
| 01:39:11 | maaku: | (e.g. atomic swaps of freicoins for private assets) |
| 01:39:27 | 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. |
| 01:39:44 | 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? |
| 01:40:21 | CodeShark: | homomorphic encryption? |
| 01:41:12 | CodeShark: | would it require quantum crypto? :) |
| 01:41:36 | gmaxwell: | CodeShark: you basically want two people to trade data such that they either both get the data or neither do? |
| 01:41:43 | CodeShark: | exactly |
| 01:42:45 | CodeShark: | and the outcome shouldn't take forever to determine :) |
| 01:42:59 | gmaxwell: | I don't know if its possible, unless you assume both parties are equally computationally bounded. |
| 01:43:25 | CodeShark: | or you use quantum crypto |
| 01:43:44 | gmaxwell: | I'm not even sure how you'd do it with quantum crypto. |
| 01:44:08 | gmaxwell: | lemme think for a minute. |
| 01:45:26 | 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? |
| 01:46:02 | gmaxwell: | I can give you protocols for this, but they don't work for the two-party case because they need an honest majority. |
| 01:46:22 | CodeShark: | escrow? |
| 01:46:40 | CodeShark: | yeah, the two party case seems to have much more profound theoretical implications |
| 01:47:14 | 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. |
| 01:47:50 | 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. |
| 01:48:37 | 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. |
| 01:49:10 | 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. |
| 01:49:50 | CodeShark: | right |
| 01:51:28 | 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. |
| 01:51:36 | gmaxwell: | (for the same reason as here) |
| 01:51:45 | CodeShark: | not even with quantum crypto? |
| 01:53:29 | 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). |
| 02:06:13 | 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. |
| 02:06:35 | CodeShark: | what are you seeing? |
| 02:07:27 | 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 |
| 02:08:18 | brisque: | usually around block boundaries I get 60+ transactions spending spent outputs, which is strange in my eyes. big blocks milliseconds apart. |
| 02:08:27 | gmaxwell: | brisque: I don't think thats anything too new or interesting, some things, e.g. bc.i uselessly flood peers with double spends. |
| 02:08:43 | gmaxwell: | also I think coinbase does this. |
| 02:09:11 | 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. |
| 02:09:26 | brisque: | ah. I've banned blockchain.info for that, but I wasn't aware anybody else decided it was a good idea. |
| 02:32:20 | 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. |
| 02:53:41 | 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. |
| 02:53:56 | gmaxwell: | If it were, we could just automatically ban those nodes. |
| 02:58:12 | 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 |
| 02:59:52 | brisque: | I seem to remember that Bitcoind avoids talking to multiple peers in the same network, which would make that more difficult of course. |
| 03:01:54 | 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. |
| 03:05:21 | 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. |
| 03:10:18 | 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. |
| 03:10:38 | gmaxwell: | The bandwidth might be cheap for them, but it's pretty inconsiderate to the network. |
| 03:10:48 | brisque: | oh god. seriously!? |
| 03:11:00 | gmaxwell: | yea. |
| 03:11:04 | brisque: | why would anybody running a financial service run their own bitcoin node!? |
| 03:11:23 | gmaxwell: | And expose it directly to the world too. |
| 03:12:33 | gmaxwell: | In any case, maybe we could just keep a count of doublespends per-peer preferentially kick the worst offender. |
| 03:13:19 | 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. |
| 03:13:43 | brisque: | it explains a lot, why their outgoing transactions are so slow, get stuck, often don't get broadcast. |
| 03:14:31 | 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. |
| 03:15:07 | 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) |
| 03:15:36 | brisque: | surely they would have paid a bug bounty for you. they have a minimum 5BTC policy. |
| 03:15:49 | brisque: | that's an obscenely bad bug for an online wallet to have |
| 03:15:50 | Luke-Jr: | gmaxwell: now I can't even sell until it confirms :/ |
| 03:16:02 | gmaxwell: | oh I guess they fixed it then. |
| 03:16:59 | 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. |
| 03:17:09 | brisque: | I think you could have the QT client scream "DONT ACCEPT ZERO CONF TRANSACTIONS" every 5 minutes and people would still do it. |
| 03:18:05 | brisque: | gmaxwell: I'm shocked nobody had realised that before. |
| 03:19:13 | 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. |
| 03:19:16 | 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) |
| 03:19:24 | gmaxwell: | ... to the tune of something like $30,000. |
| 03:19:58 | 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!) |
| 03:20:45 | brisque: | either way, lucky you found it rather than somebody who would have exploited it. |
| 03:20:47 | gmaxwell: | in any case, if you look around you can find horrifying stories about almost every bitcoin service. |
| 03:21:20 | gmaxwell: | brisque: Well, maybe thats what the VC money is for: to cover hemoraging money from failures like that. :P |
| 03:21:48 | gmaxwell: | BTC-e has has some really severe money loss events and somehow keeps on trucking. |
| 03:22:01 | brisque: | fractional reserve? |
| 03:22:06 | gmaxwell: | maybe! |
| 03:22:26 | gmaxwell: | e.g. someone figured out how to impersonate the liberty reserve deposit callback and then gave themselves infinite btc-e USD. |
| 03:22:39 | gmaxwell: | and then bought up and withdrew all coins that appeared in the btc-e hotwallet. |
| 03:22:43 | gmaxwell: | ... for something like 12 hours. |
| 03:23:08 | 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. |
| 03:24:08 | 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. |
| 03:24:40 | gmaxwell: | mtgox now does some of that, though I think probably not enough. |
| 03:25:22 | gmaxwell: | at least these things should freeze deposits and withdrawls... anything purely internal can at least be made right later. |
| 03:25:41 | 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. |
| 03:26:50 | brisque: | until there's a bank run, and then they're completely high and dry |
| 03:27:31 | gmaxwell: | Failure is always an option. |
| 03:28:04 | gmaxwell: | I'm not aware of a _single_ major bitcoin business operator who has faced _civil_, much less criminal, charges for their default. |
| 03:28:50 | pigeons: | i guess calling trendon sahvors/pirate@40 a business operator would be a stretch |
| 03:29:42 | phantomcircuit: | gmaxwell, er |
| 03:29:47 | phantomcircuit: | * phantomcircuit raises hand |
| 03:29:51 | 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? |
| 03:30:11 | pigeons: | he got a default judegemnt by the sec cause he stopped responding to the court |
| 03:30:13 | phantomcircuit: | oh charges |
| 03:30:16 | phantomcircuit: | didn't see that |
| 03:30:16 | gmaxwell: | phantomcircuit: well I'm not counting bitcoinica because the actual owner and responsible party dropped the bag of shit in someone elses lap! |
| 03:30:19 | pigeons: | and now the fbi is finishing their investigation |
| 03:30:39 | phantomcircuit: | gmaxwell, charges usually refers to government action also |
| 03:30:52 | phantomcircuit: | gov can take civil action which i believe is what they did against shavers |
| 03:31:01 | phantomcircuit: | or however the fuck you spell his name |
| 03:31:07 | pigeons: | these are the shavers docs. http://ia800904.us.archive.org/35/items/gov.uscourts.txed.146063/ |
| 03:31:07 | gmaxwell: | thats what they did against him, yea. |
| 03:31:26 | pigeons: | yes and i hear criminal is coming soon against shavers |
| 03:31:27 | brisque: | the point being that even under the most abstract failure, most sites simply disappear when something goes wrong. |
| 03:31:30 | phantomcircuit: | so looks like hashfast isn't going to delivery |
| 03:31:33 | phantomcircuit: | deliver* |
| 03:31:45 | gmaxwell: | phantomcircuit: nope, they're not. |
| 03:31:50 | pigeons: | not only do they disappear, they reopen using the same identity |
| 03:32:02 | gmaxwell: | They've also announced that they aren't planning to honor their original comittments to refunds. |
| 03:32:03 | pigeons: | coinjar.io |
| 03:32:07 | 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. |
| 03:32:07 | phantomcircuit: | i actually knew this like two weeks ago |
| 03:32:16 | phantomcircuit: | but i find it amusing watching people find out they're fucked |
| 03:32:38 | 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. |
| 03:32:59 | 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. |
| 03:33:27 | brisque: | they'll end up delivering something I assume |
| 03:33:29 | 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 |
| 03:33:42 | phantomcircuit: | they didn't hit the target and are now completely screwed |
| 03:33:50 | phantomcircuit: | this is of course fraud |
| 03:34:14 | phantomcircuit: | gmaxwell, it's likely criminal |
| 03:34:24 | phantomcircuit: | but i doubt it's worth anybodies time to pursue |
| 03:34:30 | brisque: | is a poor lack of judgement criminal? |
| 03:34:31 | 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. |
| 03:34:55 | gmaxwell: | brisque: Its become pretty hard to believe that they ever thought they could deliver on what they promised. |
| 03:35:17 | phantomcircuit: | gmaxwell, fun fact hashfast was trying to sell chips in bulk recently |
| 03:35:25 | phantomcircuit: | possibly they have the chips but they dont work |
| 03:35:33 | phantomcircuit: | or they cant put them on boards |
| 03:35:38 | phantomcircuit: | or they cant get components |
| 03:35:40 | phantomcircuit: | or ??? |
| 03:35:44 | gmaxwell: | they have some demo videos now actually showing a test unit hashing, |
| 03:35:51 | 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. |
| 03:35:58 | gmaxwell: | and I believe that its real (esp since one of the people in #eligius went to visit them and saw it) |
| 03:36:27 | 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) |
| 03:36:35 | gmaxwell: | this is the epic timeline post: https://bitcointalk.org/index.php?topic=391251.0 |
| 03:37:02 | 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. |
| 03:37:21 | gmaxwell: | brisque: oh that, yea, I assumed it was just a design error. |
| 03:37:38 | phantomcircuit: | gmaxwell, they might have the chips |
| 03:37:43 | phantomcircuit: | which i assume they could sell |
| 03:37:53 | phantomcircuit: | so possibly bankruptcy would actually be useful |
| 03:38:04 | phantomcircuit: | but there is no way they can actually refund people in btc |
| 03:38:12 | Luke-Jr: | phantomcircuit: yes there is |
| 03:38:27 | brisque: | hashfasts design is useless anyway. it's cheaper to just buy other designs at this point. |
| 03:38:32 | phantomcircuit: | Luke-Jr, if they kept the btc? |
| 03:38:38 | Luke-Jr: | phantomcircuit: exactly |
| 03:38:48 | gmaxwell: | phantomcircuit: it actually appears that they did though its hard to be sure. |
| 03:39:01 | brisque: | Luke-Jr: isn't there a comment about them using Bitpay, which would go to USD instantly? |
| 03:39:17 | gmaxwell: | brisque: they took both direct payments and bitpay, and bitpay lets the merchant choose. |
| 03:39:19 | Luke-Jr: | brisque: BitPay offers that *option*, but it isn't required |
| 03:39:21 | phantomcircuit: | gmaxwell, huh interesting |
| 03:39:45 | brisque: | Luke-Jr: I wasn't aware of that, interesting |
| 03:40:29 | 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. |
| 03:41:00 | 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. |
| 03:41:35 | gmaxwell: | so you either lock in an 86% loss by refunding, or take a risk that they'll do something shitty like that. |
| 03:41:47 | brisque: | I suppose they messed up and they're quite afraid of the consequences. I don't blame them for acting irrationally. |
| 03:43:04 | 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. |
| 03:43:38 | 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. |
| 03:44:27 | 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. |
| 03:44:53 | 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. |
| 03:45:10 | brisque: | it's schoolchildren mentality, but there you go. |
| 03:47:15 | 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. |
| 03:47:45 | gmaxwell: | but god knows, maybe their had a failed spin. |
| 03:48:00 | gmaxwell: | s/their/they/ |
| 03:49:10 | brisque: | that market is fascinating really. we have BFL, Avalon, Hashfast and Bitfury all acting quite strangely for companies |
| 03:49:41 | 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. |
| 03:51:05 | brisque: | frustratingly there's very little information about what ghash.io actually is, and what Bitfury is doing behind the scenes with it |
| 03:59:39 | 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. |
| 04:03:07 | brisque: | easy enough to hide your hashrate with a fake pool anyway or by replicating coinbases. |
| 04:03:24 | brisque: | do you like Luke would notice if I mined a block with Eligius.st's coinbase? |
| 04:05:21 | 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. |
| 04:07:29 | gmaxwell: | well, for one, they could stop giving him _more_ hashpower. :P |
| 04:07:53 | gmaxwell: | best estimatimates still have 1/2 to 1/3 of ghash.io's hashpower is third party. |
| 04:08:27 | phantomcircuit: | brisque, bitfury supplies cex.io which uses ghash.io |
| 04:08:28 | 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. |
| 04:08:35 | phantomcircuit: | they're actually different people |
| 04:08:47 | phantomcircuit: | but since they're all ukrainians with weird names nobody can tell |
| 04:09:01 | 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. |
| 04:09:15 | phantomcircuit: | gmaxwell, it's definitely different people |
| 04:09:25 | phantomcircuit: | they are obviously very close though |
| 04:10:04 | nessence: | are dzminercoop guys legit? |
| 04:15:14 | CodeShark: | gmaxwell: https://github.com/CodeShark/bips/blob/master/bip-n1.mediawiki |
| 04:17:59 | gmaxwell: | CodeShark: you realize that partially signed transactions are already implemented by bitcoin-qt, bitrated, brainwallet, and a half dozen other things, right? |
| 04:18:18 | CodeShark: | is there a standard? |
| 04:19:24 | CodeShark: | many "partially signed transaction" implementations I've seen just blank out entire input scripts |
| 04:19:35 | CodeShark: | which makes some of the use cases I'm considering impossible |
| 04:20:37 | gmaxwell: | A defacto one at least. I'm not sure what you mean by "entire input scripts" |
| 04:20:54 | CodeShark: | as in the entire input script is blanked |
| 04:20:56 | maaku: | CodeShark: what use cases are you considering? |
| 04:21:04 | maaku: | or rather, what do you need to do? |
| 04:21:33 | CodeShark: | maaku: the main thing for me right now is supporting p2sh |
| 04:22:16 | CodeShark: | especially in cases where the signing devices don't know anything about the scripts a priori |
| 04:22:31 | CodeShark: | they just need to know whether they can sign and if they sign what the implications are |
| 04:24:00 | CodeShark: | IMO, the signatures should have been kept as a separate list structure in the txin |
| 04:24:05 | CodeShark: | rather than making them part of the script :p |
| 04:24:09 | CodeShark: | but that's another story |
| 04:24:53 | CodeShark: | an account management app keeps track of script pairs (txinscript/txoutscript) |
| 04:25:02 | CodeShark: | the txinscript just have placeholders for signatures |
| 04:25:14 | CodeShark: | the signing devices just keep keychains |
| 04:25:26 | CodeShark: | they don't even need to know about the scripts a priori at all |
| 04:26:34 | CodeShark: | this will allow a good separation between account management/inbound payment processing tools (a.k.a. watch-only wallets) and signing devices |
| 04:26:49 | maaku: | CodeShark: why is scriptSig connected to p2sh? |
| 04:26:57 | maaku: | don't they figure that out by looking at the scriptPubKey? |
| 04:27:03 | CodeShark: | no |
| 04:27:12 | CodeShark: | the scriptPubKey for a p2sh only holds a hash of the script |
| 04:27:20 | CodeShark: | which is useless to anyone who doesn't already know the script |
| 04:27:54 | maaku: | ok so you're partially constructing the p2sh scriptSig |
| 04:28:08 | maaku: | (a) wallets probably already know the scripts (but I can imagine cases where they do not) |
| 04:28:14 | maaku: | (b) pass it out-of-band |
| 04:28:20 | CodeShark: | yes |
| 04:28:52 | CodeShark: | I like the p2sh approach generally - it's the recipient's responsibility to know how to claim the output |
| 04:29:01 | CodeShark: | the sender doesn't really care |
| 04:33:10 | CodeShark: | I mean, there could be conceivable cases where the sender cares - but not for the use cases under consideration here |
| 04:33:37 | gmaxwell: | ... https://bitcointalk.org/index.php?topic=392166.0 < KNC miner botnet. |
| 04:36:10 | 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 |
| 04:36:22 | CodeShark: | a "generalized" payment protocol, so to speak |
| 04:37:16 | CodeShark: | which works for multisigs, coinjoin, internal company policy, merchants, and several other use cases |
| 04:37:25 | phantomcircuit: | gmaxwell, he's just brute forcing the passwords for web exposed boxes |
| 04:37:40 | phantomcircuit: | it's comical anybody has web exposed boxes at all |
| 04:37:50 | gmaxwell: | phantomcircuit: yea, sort of, except he can do an offline brute force, which digest auth is supposted to prevent. |
| 04:37:59 | gmaxwell: | presumably it uses a constant nonce or something stupid like that. |
| 04:38:26 | phantomcircuit: | probably |
| 04:38:30 | maaku: | why the hell was this posted online? |
| 04:38:30 | phantomcircuit: | but still |
| 04:38:52 | phantomcircuit: | maaku, the guy who found it decided to |
| 04:40:09 | gmaxwell: | someone reported the post and asked me to remove it, but I think its too late. |
| 04:40:16 | maaku: | phantomcircuit: i understand, but besides being unethical it is illegal with legal implicaitons if any of those boxes do get hacked |
| 04:40:46 | phantomcircuit: | maaku, publishing an exploit like that isn't illegal |
| 04:40:54 | gmaxwell: | in the grand scheme of shitty behavior in bitcoin land, someone hacking miners to divert them is probably the most minor. |
| 04:40:55 | phantomcircuit: | admitting to breaking into 28 boxes is |
| 04:41:10 | phantomcircuit: | gmaxwell, well he is basically rootkitting them |
| 04:41:13 | gmaxwell: | hehe 'most minor' |
| 04:41:21 | phantomcircuit: | those 28 people are going to have to pull the sd card to fix them |
| 04:41:31 | maaku: | phantomcircuit: depends on your jurisdiction, but yes publishing exploits is typically illegal |
| 04:41:35 | gmaxwell: | he said he didn't actually do that. |
| 04:41:39 | maaku: | if done in a negligent way |
| 04:41:43 | phantomcircuit: | oh i missed that part |
| 04:42:12 | phantomcircuit: | maaku, not in parts of the world with freedom |
| 04:42:14 | gmaxwell: | maaku: illegal? probably not. Exposes him to civil claims, perhaps. |
| 04:42:20 | phantomcircuit: | im going to assume he doesn't live in north korea |
| 04:42:30 | phantomcircuit: | since he's on the internet |
| 04:42:48 | gmaxwell: | actually reading again, I'm not sure what he's saying. |
| 04:43:18 | gmaxwell: | http digest auth doesn't prevent bruteforcing, and it actually does sound like he's doing a regular bruteforce attack. kinda boring. |
| 04:44:15 | 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 |
| 04:44:40 | phantomcircuit: | maaku, im not aware of anybody who has even been prosecuted in the us for disclosing a flaw |
| 04:45:08 | phantomcircuit: | numerous people have been subsequently accused of using the flaw under the assumption they the attack happened before they had disclosed it |
| 04:45:14 | phantomcircuit: | so thye must have been the attacker |
| 04:45:21 | phantomcircuit: | but that's not the same thing |
| 04:50:22 | 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 |
| 04:50:54 | CodeShark: | so it's not so much an exposure as it is just another example of a well-known attack |
| 04:55:04 | maaku: | CodeShark: it's pointing people at the factor reset script and config files to update which is more unique |
| 04:55:22 | maaku: | not hard to figure out by anyone technically compitent, but he reduced it down to script kiddie level |
| 04:57:25 | CodeShark: | the hard part is getting root access :p |
| 04:58:27 | CodeShark: | but yeah, this guy sounds a tad bit too boastful |
| 05:03:25 | brisque: | that's bold, announcing that you're exploiting people's hardware on a public forum. |
| 05:05:09 | brisque: | depending on the country that's most certainly illegal, akin to breaking and entering. if they get charged for doing it or not is a whole different matter. |
| 05:05:30 | CodeShark: | it's not announcing it that's illegal - it's doing it that's illegal |
| 05:06:05 | brisque: | certainly, but announcing that you did it is foolhardy |
| 05:07:53 | brisque: | oh dear. the user has also posted their KNC order number on the forums, and their country. |
| 05:14:30 | brisque: | who connects an embedded device directly to the internet anyway? |
| 05:19:27 | phantomcircuit: | brisque, people putting them in a dc who dont pay attention |
| 05:20:27 | brisque: | right. forgotten people might be doing that. |
| 05:37:50 | gmaxwell: | hey, could be worse, he could have posted instructions for making it look like one 1/4 of the hardware failed, while sending the 1/4 of the hashrate to himself. |
| 05:39:16 | brisque: | not even that, just skimming 5% of the hash power wouldn't be noticed. over 1000 units they claim to have found, that's uh. |
| 05:39:27 | brisque: | 30TH. |
| 05:40:05 | gmaxwell: | well he only got into 28 of them I think. |
| 05:40:58 | brisque: | the "disclosure" is shit because we know that most of these units won't be patched in a reasonable timeframe. there's a lot that are now going to be under attack by people hoping to make a quick buck. |
| 05:45:37 | gmaxwell: | brisque: they don't need to be 'patched' they just need to have their password changed to something not crackable. |
| 05:49:07 | brisque: | gmaxwell: haven't brainwallets showed that users, even technical ones, can't make secure passwords to save their own money? |
| 05:50:00 | gmaxwell: | brisque: brainwallets add the extra expectation that they'll remember those passwords. |
| 05:50:11 | gmaxwell: | No need to remember these... just write them down. |
| 05:51:41 | brisque: | the point is more that people won't no matter what is being told to them. protecting $10000 of mining equipment is a difficult job when they're advertising what they are at connect time. |
| 05:53:03 | gmaxwell: | brisque: uh? all my miners have 128 bit passwords... |
| 05:53:46 | brisque: | you're not an average user. |
| 05:53:49 | gmaxwell: | (even though they're not internet exposed, just a standard practice. If I weren't a chickenshit I'd turn off the web interfaces entirely, but I'm a bit afraid of getting locked out.) |
| 05:54:28 | gmaxwell: | brisque: in any case, it's easy to give good advice for this. Well, give a little credit: An average user doesn't own a $10,000 asic miner. |
| 05:58:01 | brisque: | I suspect a lot of miners are in the hands of casual users though, which is why there's exposed KNC miners in DCs in the first place. |
| 06:03:52 | gmaxwell: | how casual can you be with a $10k device in a data center? come on— signing up for the colocation is more complicated than using a password generator and a text file. :P |
| 06:20:54 | Sangheili_afk: | Sangheili_afk is now known as Sangheili |
| 07:27:41 | midnightmagic: | ha ha ha |
| 07:31:42 | midnightmagic: | It would be great if that were gobbles. |
| 07:52:30 | BlueMatt: | I'm assuming this has been seen already: http://miki.it/pdf/BitIodine_presentation.pdf |
| 07:53:32 | gmaxwell: | anyone try out their software? |
| 07:53:41 | gmaxwell: | I queued that presentation for reading and forgot about it |
| 07:53:52 | brisque1: | they did a hell of a lot os scraping |
| 07:53:59 | brisque1: | s/os/of |
| 07:54:02 | BlueMatt: | it looks like they've actually thought coin analysis through, unlike most of the shit we've seen so far |
| 07:54:33 | BlueMatt: | mostly because of the huge amount of scraping they did |
| 07:55:31 | justanotheruser: | BlueMatt: "When a transaction has multiple input addresses, we can safely assume that those addresses belong to the same wallet, thus to the same user." |
| 07:55:58 | justanotheruser: | biggest flaw I found |
| 07:56:11 | BlueMatt: | yea, they didnt get that right, at least they could have said "we can usually safely assume" |
| 07:56:17 | BlueMatt: | because, realistically, today, you can |
| 07:56:19 | brisque1: | justanotheruser: generally a safe assumption, especially with some online wallets reusing addresses for change. |
| 07:56:33 | brisque1: | in that case you don't even have to assume. |
| 07:57:58 | gmaxwell: | oh wow, the presentation is kinda worthless. |
| 07:58:38 | gmaxwell: | BlueMatt: nah, even today a really substantial fraction of txn on the network are shared wallet transactions. |
| 07:58:50 | gmaxwell: | so you can't do the common inputs = same user thing. |
| 07:58:55 | justanotheruser: | "If multiple outputs, change is never the last output. Fixed only in January 2013!" |
| 07:59:01 | justanotheruser: | Most interesting thing I learned |
| 07:59:20 | gmaxwell: | justanotheruser: I like how it's like "software is flawed" except it was fixed long before their work. Should say 'was' but oh well. |
| 07:59:48 | brisque1: | you can often tell what is change just from the values. if there's a 0.1BTC output another with 8 places, you know certainly which is the change. |
| 07:59:54 | gmaxwell: | Gavin introduced the bug in .. what, 2010? Hal found the bug at the end of 2012. |
| 08:00:07 | gmaxwell: | brisque1: yea, thats a somewhat helpful hurestic. though not always true. |
| 08:00:16 | BlueMatt: | gmaxwell: true, though you can safely assume that the users are using the same shared wallet (which is likely the intended meaning here, though its not explicitly stated) |
| 08:00:30 | gmaxwell: | e.g. when the amount I move is up to me, I make the third party get the change like amount sometimes. |
| 08:01:04 | gmaxwell: | BlueMatt: eh. but thats strictly less useful. Because you may not know either of the users are using a shared wallet at all. |
| 08:01:19 | BlueMatt: | oh, sure, but its still more than nothing |
| 08:01:44 | BlueMatt: | and if you know which shared wallet, you can sometimes tell via other things (coinbase does some dumb double-tx shit to make the "from" address work) |
| 08:02:03 | brisque1: | … |
| 08:02:04 | gmaxwell: | yea, coinbase does dumb stuff. Strongcoin does dumb stuff. |
| 08:02:16 | gmaxwell: | (strongcoin makes every transaction pay some donation address of theirs) |
| 08:02:18 | brisque1: | seriously? coinbase wants to have "return" addresses? |
| 08:03:38 | gmaxwell: | brisque1: dude not just that, coinbase's merchant thing was randomly "refunding" things when it wasn't expecting a payment. (and causing people to lose bitcoin forever, dunno if its fixed yet— I assume) |
| 08:03:58 | gmaxwell: | brisque1: every transaction into or out of coinbase result in two transactions. Except sometimes it doesn't |
| 08:04:37 | brisque1: | gmaxwell: that's not giving me the warm fuzzy feeling their "safe and secure" animation says I should. |
| 08:04:42 | gmaxwell: | BlueMatt: in any case, share wallets are still a huge source of noise and uncertanty in this kind of analysis. |
| 08:05:05 | gmaxwell: | BlueMatt: just because until you have evidence that its a shared wallet you'll be falsely merging some users. |
| 08:05:08 | BlueMatt: | gmaxwell: yes, but I'd like to see these guys figure out ways to analyse coinbase txn to link them too, etc |
| 08:06:54 | _ingsoc: | brisque1: What animation? |
| 08:07:23 | brisque1: | _ingsoc: coinbase.com has a sort of flip clock thing that says "safe and secure" when you visit the page. |
| 08:07:37 | _ingsoc: | Ah, thank you. I like animations. |
| 08:07:54 | gmaxwell: | BlueMatt: I still think we should have some switch you can set when sending coins that lets it round up to x amount more to eliminate or round-off change. |
| 08:08:32 | BlueMatt: | gmaxwell: I still think all wallets should work together to make this kind of analysis impossible (coinjoin et al), but until the analysis gets amazingly accurate, we may not see that |
| 08:14:20 | gmaxwell: | certantly I think it's useful if the publically disclosed analysis is as powerful as any privately held analysis may be. |
| 09:45:14 | mist: | [Festive Global Notice] The year 2014 will soon be kicking in in some parts of the world! Join us in #freenode-newyears for fun and festivity! (Yes, there may be more comedy globals over the period, complaints to /dev/null you moaning ninnies) |
| 11:00:37 | mist: | [New Year Global] Happy New Year to everyone in the New Zealand time zone! |
| 11:11:37 | RichiH: | [Global Notice] Hi all. As the kiwis are firmly in 2014 already and the marmites are preparing, let us remind you about the spammy #freenode-newyears and the conversational #freenode-newyears-nospam . Also in the news: carrots |
| 11:38:02 | jtimon: | hello, does anyone has what was talked after this? |
| 11:38:12 | jtimon: | [02:36:09] 17:35 < maaku> or in a server-to-server consensus mechanism |
| 11:38:12 | jtimon: | [02:36:43] yea... except dear gods, the bitcoin blockchain is NOT a communications mechenism for your server to server consensus! _global broadcast network_ |
| 11:38:12 | jtimon: | [02:36:52] gmaxwell: using the public chain as a semaphore for two-phase commit of a distributed transaction over multiple private asset servers |
| 11:38:12 | jtimon: | [12:08:31] <-- jtimon (~quassel@87.pool85-53-148.dynamic.orange.es) has quit (No Ping reply in 180 seconds.) |
| 11:39:12 | RichiH: | [Global Notice] a very grumpy dan408_ has requested, and confirmed, that he does not, quote, "receive enough msgs as well". he wants _you_ to fix that. do not ask me why, but have at it, i guess |
| 12:05:28 | jtimon: | a pastebin would do it |
| 12:06:15 | brisque: | I'd help you out but I don't have scrollback that far. someone will surely have logs. |
| 15:52:56 | mist: | [New Year Festive Notice] About 10 minutes to go until new year hits Malaysia, bits of China, and finishes sweeping through Oz. Cast greetings out in #freenode-newyears! |
| 16:19:28 | andytoshi: | jtimon: i have logs at http://download.wpsoftware.net/bitcoin/wizards/2013-12-31.txt which cover what you want |
| 17:13:12 | jtimon: | cool andytoshi thank you |
| 17:23:18 | phantomcircuit: | gmaxwell, bitcoin.org was moved to a dedi and the dedi died under the load |
| 17:23:20 | phantomcircuit: | wat |
| 17:23:22 | phantomcircuit: | it's like |
| 17:23:24 | phantomcircuit: | all static content |
| 17:23:26 | phantomcircuit: | how is that even |
| 17:25:52 | jtimon: | I'm not sure I understand this part: |
| 17:25:54 | jtimon: | 01:38:28 gmaxwell: you need to hit the public chain for public<-->private txns |
| 17:25:55 | jtimon: | 01:39:11 (e.g. atomic swaps of freicoins for private assets) |
| 17:25:55 | jtimon: | 01:39:27 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. |
| 17:26:24 | jtimon: | freimarkets options also need expiries |
| 17:27:25 | jtimon: | but the first use case when it was reallly necessary are transitive (ripple-like) trasactions involving several in-chain and off-chain assets |
| 17:28:08 | jtimon: | when all the asset are off-chain you can just use a regular timestamping server all the private chains agree upon |
| 17:29:24 | jtimon: | what we used to call "registries" in 2PC Ripple http://archive.ripple-project.org/Protocol/RegistryCommitMethod |
| 17:32:10 | jtimon: | I don't know how can you implement my example "5.6.3 Hybrid Transitive transaction" (pubA -> pubB -> privC -> privD -> pubE -> userA) without block expiries |
| 17:32:42 | jtimon: | of course, whether you think that's an important use case or not is another question |
| 17:34:30 | jtimon: | as for the "dangers of expiries" the way I see it, the responsability to decide how many blocks to wait to consider a transaction "safely buried" should ALWAYS rely on the recipient |
| 17:34:57 | jtimon: | 6 blocks is just an orientation |
| 17:35:34 | jtimon: | it depends much more on the quantity than in previous transactions or expiries |
| 17:36:05 | jtimon: | well, it will usually will, but it's still the payee's problem |
| 17:38:53 | jtimon: | in fact all of the examples in our off-chain transactions section rely on expiries (the all off-chain asset transaction example is missing, but it's basically 2PC Ripple) |
| 17:57:54 | andytoshi: | jtimon: the problem is that it the whole transaction sub-DAG is risky .. IMO requiring 100 blocks before any nExpiresTime output can be spent would solve this, and it'd be better than having no expiry time |
| 17:58:05 | andytoshi: | as for the weird miner incentives, i'd really have to think about that |
| 17:59:02 | ziplock: | ziplock has left #bitcoin-wizards |
| 18:38:48 | _ingsoc: | _ingsoc is now known as Guest80848 |
| 18:50:58 | Emcy: | "BitTorrent Sync was designed with privacy and security in mind. The system uses SRP for mutual authentication and for generating session keys that ensure Perfect Forward Secrecy. All traffic between devices is encrypted with AES-128 in counter mode, using a unique session key. Modification requests are all verified using Ed25519 signatures and only systems with full access keys can generate valid modification requests." |
| 18:51:19 | Emcy: | that seems ok right. apart from the closed source ofc |
| 19:02:25 | gmaxwell: | lol |
| 19:02:57 | gmaxwell: | "Hmm. Low fat. Low Sodium. That seems ok right. apart from the gives you cancer part ofc" |
| 19:07:04 | Emcy: | but bt sync is so usable..... |
| 19:09:19 | maaku: | jtimon: having transactions expire is a requirement of the system we are building. no way around that |
| 19:11:04 | Emcy: | i did notice in the android client sync gives you the option to email somewhere that nifty shared secret string you just generated |
| 19:11:06 | Emcy: | derp derp |
| 19:11:47 | maaku: | Emcy: that email is PGP encrypted, of course? :P |
| 19:12:15 | Emcy: | of course not, just uses whatever email handler you have in android. Liekly gmail |
| 19:13:18 | Emcy: | they should take that out and add the QR reader to the desktop app instead. The android client can already scan a QR produced by the desktop program, dont know why its not both ways |
| 19:13:24 | Emcy: | i guess thats why its still beta |
| 19:18:21 | phantomcircuit: | Emcy, i dont see any really good reason why you couldn't implement bittorrent sync with nothing more than a private tracker and a shared key |
| 19:18:34 | phantomcircuit: | it shouldn't even be that difficult |
| 19:19:09 | Emcy: | i think thats essentially what theve done |
| 19:21:42 | Emcy: | theyve just automated the hashing and .torrent publishing parts, and have some sort of metadata files hanging around so the nodes dont get confused about timestamps and such |
| 19:21:42 | Emcy: | it seems to be really quite usable though so far |
| 19:21:42 | phantomcircuit: | Emcy, depending on whether you trust the filesystems modification timestamp you can do all of this very very efficiently |
| 19:21:42 | Emcy: | its not quite dropbox level of brain absentia though |
| 19:21:42 | phantomcircuit: | im surprised it took them this long to do it actually |
| 19:22:32 | Emcy: | yeah well no one wanted to do anything with torrent tech because muh piracy |
| 19:22:44 | phantomcircuit: | if they wanted to make it really fast they could share the block hashes for all the files |
| 19:23:03 | phantomcircuit: | so you have 2 files that are 90% identical you only transfer the diff blocks |
| 19:23:19 | phantomcircuit: | but i bet they didn't do that and have each file setup as basically a torrent with private peering |
| 19:23:28 | Emcy: | i think there was actually a BEP for that for normal bittorrent |
| 19:27:19 | Emcy: | a thing which could maybe bring avail. <1 torrents back fromthe dead by matching data blocks from seeders of other torrents |
| 19:27:19 | jtimon: | maaku I though gmaxwell was proposing an alternative with multisig, but probably not the same use case |
| 19:27:42 | jtimon: | andytoshi, I'm not sure what you mean by "the whole transaction sub-DAG is risky", but I don't see how the 100 block wait is necessary |
| 19:30:52 | jtimon: | I'm not very informed on the bittorrent sync topic, but wouldn't a tahoe-LAFS GUI be better? |
| 19:31:10 | andytoshi: | jtimon: if a tx gets expired as a consequence of some reorg, the receiver of the btc loses out -- and so does everyone he spent to, and everyone they spent to, and so on |
| 19:31:34 | andytoshi: | the whole transaction chain is invalidated, so the risk model is the same as that for coinbase transactions |
| 19:31:36 | andytoshi: | hence the 100 block wait |
| 19:31:40 | jtimon: | that's the receiveer problem, why didn't he wait for reorgs to be unlikely? |
| 19:32:04 | maaku: | jtimon: they like the fact that any non-coinbase tx that hits the chain can only be made invalid by malicious/buggy clients |
| 19:32:23 | jtimon: | or by a later double-spend |
| 19:32:31 | andytoshi: | jtimon: because he's an spv node and he didn't know that there was an nExpiresTime tx 2 layers back in the blockchain |
| 19:32:43 | maaku: | jtimon: that falls under the malicious category |
| 19:33:17 | jtimon: | can SPV wait less confirmation than rational people just because they have less information about the global state? |
| 19:33:18 | maaku: | as you say, it is trivially solved by having the receiver wait 100 blocks, then you have the same security as other transactions |
| 19:33:27 | andytoshi: | jtimon: and actually, if people are doing this sort of analysis when considering whether to receive coins, then the coins are non-fungible |
| 19:33:33 | andytoshi: | (at least temporarily) |
| 19:33:35 | jtimon: | why 100? where that number comes from? |
| 19:33:38 | maaku: | or, alternatively, tracing inputs back 100 blocks to show that they are not expiring soon |
| 19:33:44 | maaku: | coinbase maturity |
| 19:34:08 | andytoshi: | jtimon: 100 is arbitrary, just to be consistent with coinbases |
| 19:34:32 | maaku: | i'm just saying that would get you to the same level - right now any bitcoin transaction could get reversed in a reorg of >100 blocks |
| 19:34:34 | jtimon: | if you wait 50 blocks you are probably pretty secure despite previous coinbases or expiries |
| 19:34:47 | maaku: | well not *any* txn, but as a SPV node you don't know which ones |
| 19:35:37 | adam3us: | jtimon: thanks for the url btw i was unable to find "original ripple" before archive.ripple-project.org! all other urls and history redirects to ripple.com which maybe moderately different |
| 19:36:10 | maaku: | adam3us: significantly different |
| 19:37:07 | jtimon: | adam3us that link was to the 2PC distributed Ripple protocol, which is radically different from ripple.com |
| 19:38:13 | maaku: | jtimon: you know i think this is a non-issue, but it falls in a similar category as refheights |
| 19:38:25 | maaku: | you have to change your behavior slightly, and maybe adjust how clients/wallets work |
| 19:38:27 | jtimon: | everything is "off-chain" and you can actually trade 2PC assets for bitcoins (not btc denominated IOUs) atomically |
| 19:38:58 | jtimon: | if there wasn't expiries |
| 19:39:39 | jtimon: | all clients should probably determine the "secure number of confirmations" from the value of the transaction received |
| 19:40:22 | jtimon: | my point is that with expiries, transaction value is still the more important criterion |
| 19:40:32 | jtimon: | for both SPV and non-SPV clients |
| 19:41:01 | maaku: | jtimon: the ~100 blocks of security becomes a concern during network-wide problems like the March fork |
| 19:41:30 | maaku: | where opportunistic people can build chains off of expiring transactions on the bad fork, and cause merchants to lose money |
| 19:41:40 | jtimon: | maybe some miners |
| 19:41:43 | jtimon: | sorry |
| 19:42:00 | maaku: | but there are solutions that could be put in place on the merchant and wallet side to fix that |
| 19:42:47 | maaku: | by estimating nethash you'd be able to see the drop in hash power that would signal a fork, and delay/postpone any irreversable actions |
| 19:43:14 | jtimon: | march fork was exceptional, it was an unexpected hardfork |
| 19:43:26 | jtimon: | what are the chances of that happening again? |
| 19:44:30 | maaku: | pretty high, just not on a regular basis |
| 19:44:35 | maaku: | or you can make 100 confirms, or something as absurdly high the norm for high-value transactions |
| 19:45:03 | maaku: | and let clients/wallets use old coins with short proofs showing that they can't be reversed in less than N blocks |
| 19:45:26 | jtimon: | "high-value" doesn't exist in chain |
| 19:45:45 | maaku: | it's not something you have to reach consensus over |
| 19:45:59 | jtimon: | value is only in our heads, thus outside the chain |
| 19:46:02 | jtimon: | oh, I see |
| 19:46:09 | jtimon: | client policies |
| 19:46:11 | maaku: | i'm just saying the merchant waits until processing your gateway withdrawal or shipping your order or whatever |
| 19:46:13 | maaku: | yeah |
| 19:46:37 | jtimon: | yeah, I'm with client policies as well |
| 19:46:55 | maaku: | unless your client used old coins and provided proof, which could even be made the default behavior with little more than a UI checkbox for "expediatd transaction" |
| 19:47:23 | jtimon: | in certain way I'm with miners policies too I don't like "non-standard fees" for the long run |
| 19:48:14 | maaku: | so my position is that like refheights this is a developer education problem |
| 19:48:20 | maaku: | but what we get out of it is absolutely worth it |
| 19:48:48 | maaku: | what do you mean? |
| 19:48:58 | jtimon: | I still I don't see how unexpected hardforks can be common anyway |
| 19:49:46 | gmaxwell: | who cares if its common, if you play your cards right its world ending. |
| 19:49:47 | jtimon: | and although I think the devs did the right thing, they could have been chosen the other solution |
| 19:49:58 | gmaxwell: | As in .. some event happens and it can never be recovered. |
| 19:50:22 | jtimon: | it was the ref implementation which wasn't following the protocol specification |
| 19:51:19 | jtimon: | we could have had much lower hashrates until the ref implementation was fixed |
| 19:51:31 | gmaxwell: | ... thats what we did. |
| 19:51:41 | gmaxwell: | we fixed the ref implementation to match the old. |
| 19:51:59 | jtimon: | that's the opposite of what I'm saying |
| 19:52:08 | gmaxwell: | uh. |
| 19:52:17 | maaku: | gmaxwell: you get just as much gloom and doom from a >100 block reorg now, and merchant policies can limit their exposure to be the same |
| 19:52:20 | jtimon: | we said "the rules aren't the specification, the rules were the old implementation" |
| 19:52:21 | gmaxwell: | jtimon: something like 80% of nodes were on the other fork including every major merchant, it would have been a non-issue except for the fact that 3 upgraded miners constuted >60% of the hashpower. |
| 19:52:49 | jtimon: | we could have as well said "the rules are the specification, fuck the old implementation for not following it" |
| 19:52:50 | gmaxwell: | maaku: yes, >100. But the events we've had have been <20. |
| 19:53:10 | maaku: | "merchant policies can limit their exposure to be the same" |
| 19:53:32 | maaku: | the only guys who got screwed are the ones who weren't doing adequate coin safety |
| 19:53:41 | gmaxwell: | jtimon: gee thats nice, except for the 80% of nodes including all major merchants who were actively being defrauded. |
| 19:54:02 | jtimon: | exactly, the decision was taken (sanely) counting miners and merchants, instead of being strict with the defined rules |
| 19:54:46 | gmaxwell: | jtimon: not to mention the utterly insane risk of rapidly forcing everyone onto bleeding edge software... including god knows how many people who had highly customized code who are _still_ on 0.7.x with patches. |
| 19:54:58 | adam3us: | the 2pc ripple seems a bit like OpenTranscations security model also... get signed/timestamped receipts from servers, users audit servers, if they detect malicious server, they have proof, and can rebuild server state with the receipts (in theory though maybe the rebuild part may not be automated yet) |
| 19:55:05 | gmaxwell: | jtimon: the decision was simply "the deployed software is the spec" |
| 19:55:06 | jtimon: | I'm not saying the decision was wrong |
| 19:55:20 | jtimon: | but I hate that justification |
| 19:56:03 | jtimon: | I prefer to justify it as "following the specs instead of the ref code would have had worse consequences" |
| 19:56:26 | gmaxwell: | jtimon: You can point at a stack of paper and say "but the rules!" all day... but the paper doesn't do shit. The behavior of the participants is what defines the rules in a consensus system. |
| 19:57:01 | gmaxwell: | jtimon: well of course, it's not like we say "the deployed software is the spec" because God gave that to us on a tablet,— rather, its the necessary thing to achieve good outcomes in 99.99% of cases. |
| 19:57:13 | jtimon: | agreed, of ALL the participants, not just miners |
| 19:57:41 | jtimon: | as some seemed to imply at the time |
| 19:57:44 | gmaxwell: | absolutely not just miners, and double absolutely not hashpower. |
| 19:57:51 | jtimon: | let me put it another way |
| 19:57:56 | gmaxwell: | Those implying that are not competent. |
| 19:58:52 | jtimon: | if 90% of the hash power was in the old code and 90% of merchants and users are on the specs (I know that wasn't the case), what's the right chain? |
| 19:58:56 | gmaxwell: | (And as you may note, in that hardfork the majority of hashpower was the new behavior... due to the fact that hashpower is controlled by basically 3-4 people, and they'd upgraded faster than the rest of the network due to the competative incentive of orphaning reduction) |
| 19:59:18 | jtimon: | yeah, ok, good point |
| 19:59:39 | gmaxwell: | Merchants and users would be the right chain generally. |
| 19:59:41 | adam3us: | i suppose this is another reason pooled mining can be a problem |
| 19:59:43 | jtimon: | the majority of hash was on the specs back then and we went with users |
| 20:00:00 | adam3us: | and economies of scale in mining |
| 20:00:12 | jtimon: | I agree, merchants and users are the right chain |
| 20:00:15 | gmaxwell: | (90% hashpower might just be 50 people that need to fix themselves) |
| 20:00:46 | gmaxwell: | (but even ignoring that, I think its reasonable and prudent that mining basically takes more of the risk, and pratically every miner whos thought about any of this would agree) |
| 20:01:26 | adam3us: | gmaxwell: how do u think that fork would've played out if there was no pooled mining and mostly decentralized mining power? better or worse? (more distributed consensus on sw upgrade, maybe slower reaction time) |
| 20:01:35 | jtimon: | adam3us, 2PC is similar to OT in some senses, but simpler (not so many instruments) and...in OT all atomic stuff occurs in a single server, with 2PC, there's atomic trades involving an arbbitrary number of independent servers that don't necessarily trust each other |
| 20:01:50 | gmaxwell: | adam3us: I don't think the fork would have happened, in fact. |
| 20:02:03 | gmaxwell: | (well, it would have self resolved) |
| 20:02:20 | adam3us: | gmaxwell: well wasnt the fork the result of the level db bug? how would it have self-resolved... a few people early would've noticed problems |
| 20:02:30 | adam3us: | gmaxwell: and been outvoted anyway, and then the bug backed-out? |
| 20:02:32 | maaku: | adam3us: It would have been much harder to side with the users |
| 20:02:47 | gmaxwell: | adam3us: it would have been hashpower overtaken |
| 20:02:48 | maaku: | if there weren't any big miners you could get to switch chains |
| 20:03:00 | gmaxwell: | maaku: there wouldn't have been an artificial miner/user split there. |
| 20:03:11 | adam3us: | jtimon: i think OT also has a concept called voting pools like k of n pools have to agree for a tx to complete |
| 20:03:19 | gmaxwell: | most _miners_ were also on old code at the time too. |
| 20:03:29 | maaku: | gmaxwell: yes there would. miners-set doesn't overlap well with user-set |
| 20:03:34 | gmaxwell: | it's just that most hashpower was on the new stuff. |
| 20:03:55 | adam3us: | gmaxwell: we could really do with direct mining protocol for that reason also. difficult to make that work though. |
| 20:04:18 | adam3us: | gmaxwell: a lesson therefore without decentralization, is the centralized parties need to use intelligence and gradual phase in |
| 20:04:25 | gmaxwell: | maaku: at the time most of p2pool's hashpower stayed on the 0.7 side.. though it was complicated by the fact that 0.7 didn't reliably reject the new chain. |
| 20:04:44 | adam3us: | gmaxwell: however i think from views expressed here that most of the mining power has very limited "intelligence" applied to it at all |
| 20:04:50 | gmaxwell: | (it wasn't a real hard fork, it was a softboiled fork. :P ) |
| 20:05:12 | maaku: | adam3us: iirc Luke does a good job of this. he runs blocks past multiple node versions |
| 20:05:36 | gmaxwell: | yes, it would be easier for more to do that if we'd merged luke's patches for that.. but they were pretty invasive. |
| 20:07:43 | jtimon: | adam3us, but that's not more scalable, that's like a "shared server" much like ripple.com's consensus mechanism |
| 20:09:12 | adam3us: | maaku: yes Luke-Jr is a rare example of pool intelligence |
| 22:14:50 | irc.freenode.net: | Disconnected from irc.freenode.net (ERROR :Closing Link: S0106c0c1c0894c25.vs.shawcable.net (Ping timeout: 265 seconds)) |
| 22:15:06 | dickson.freenode.net: | topic is: Bitcoin research, hardfork wishlist, ideas for the future - see also: https://en.bitcoin.it/wiki/Hardfork_Wishlist https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas |
| 22:15:06 | dickson.freenode.net: | Users on #bitcoin-wizards: andytoshi-logbot andytoshi justanotheruser MoALTz_ go11111111111 mappum spinza_ Guest80848 gribble bizzle deepc0re_ Graet hnz jtimon fagmuffinz Luke-Jr Dylan_ Emcy gmaxwell CodeShark BlueMatt rs0_ OneFixt espes__ Fistful_of_Coins realazthat iddo Krellan Hunger- jrmithdobbs jarpiain ghtdak @ChanServ maaku forrestv tucenaber typex warren sipa wumpus jgarzik Alanius K1773R helo Sangheili edulix michagogo|cloud kinlo wangbus amiller hno |
| 22:15:06 | dickson.freenode.net: | Users on #bitcoin-wizards: harrow EasyAt petertodd nanotube azariah4 phantomcircuit Mikalv midnightmagic epscy UukGoblin pigeons trn lianj cfields Ryan52 HM2 |
| 22:17:31 | andytoshi: | hey, it came back on its own :) |
| 22:56:40 | realazthat: | realazthat is now known as rudest |
| 23:25:55 | rudest: | rudest is now known as realazthat |
| 23:42:49 | gmaxwell: | but ... now it seems to have a droopy leg and a strange interest in brains. |