| 00:00:43 | gmaxwell: | tacotime_: amiller wants to use it to make compact proofs that a whole chain has a specific total difficulty. |
| 00:01:03 | amiller: | yeah that ^, way simpler than what i was staritng to type |
| 00:01:35 | amiller: | that's for sure a useful crucial component in any sharding strategy or whatever but i dont know the dtails of this PT's scheme |
| 00:01:42 | gmaxwell: | so I can give you a small proof and you'll know that the chain I have is the best of all your peers before you do the work of fetching headers. |
| 00:02:21 | gmaxwell: | amiller: so I think I can save it and make it incremental, but the cost might be too high. |
| 00:02:33 | amiller: | * amiller is prepared to sacrifice a limb |
| 00:02:52 | tacotime_: | Ah, I see. |
| 00:03:22 | gmaxwell: | basically any random graph with sufficient order is very likely to be an expander graph. So I think you can just impose random graphs and keep incresing their size by virtually repeating blocks until its an expander... but this would increase your proof sizes. |
| 00:03:38 | tacotime_: | Oh, because if you have people doing lots of easy work on the network, you'll generate a ton of different trees? And you only want people working on one? |
| 00:04:31 | tacotime_: | I hadn't even thought of that, but it makes sense (if that's the reasoning). |
| 00:04:55 | tacotime_: | PT did say that children were supposed to be generated sequentially. |
| 00:06:45 | tacotime_: | Well, sort of. Hmm. |
| 00:08:51 | amiller: | the construction in this paper is recursive |
| 00:09:21 | amiller: | the graph can be split into two subgraphs of equal size / identical structure |
| 00:10:05 | amiller: | the two equal size subgraphs are "connected with the edges of a bipartite A-expanding graph" |
| 00:11:06 | amiller: | i think the edges are all going in one direction |
| 00:11:16 | amiller: | i think that's a compatible structure with incremental construction |
| 00:32:54 | Emcy: | http://lauren.vortex.com/archive/001076.html |
| 00:33:22 | Emcy: | well thats quite a world away from 'HTTP/2.0 will be TLS by default' isnt it |
| 00:33:37 | Emcy: | funny how things always work out this way |
| 00:35:30 | nsh: | i think all IETF meetings are now conducted aboard a jet-ski jumping over a shark and landing squarely onto a human face, forever |
| 00:37:25 | Emcy: | nice |
| 00:57:28 | mus1cb0x: | well like any power structure, cunts eventually infest it like the vermin they are |
| 00:59:36 | MagicalLies: | MagicalLies is now known as c--O-O |
| 01:04:16 | andytoshi: | /j mtgox-chat |
| 01:05:41 | Emcy: | lol |
| 01:12:25 | Emcy: | gox is pretty much confirmed to be insolvent by now right |
| 01:12:39 | Emcy: | going by the 'if it looks like a duck' axiom |
| 01:12:52 | Emcy: | i read they terminated the lease on thier offices |
| 01:16:20 | tacotime_: | lol @ the live ticker |
| 01:23:00 | Luke-Jr: | Emcy: the ones they *moved out of*? :P |
| 01:23:03 | jron_: | jron_ is now known as jron |
| 01:23:11 | Luke-Jr: | pretty normal to terminate a lease when you move |
| 01:23:13 | Luke-Jr: | lol |
| 01:23:33 | Luke-Jr: | (not confirming or denying solvency or lack thereof, just making a point) |
| 01:27:21 | Emcy: | interesting timing |
| 01:27:43 | Luke-Jr: | ? |
| 01:28:38 | Emcy: | move offices whilst facing your biggest crisis |
| 01:28:54 | Emcy: | did they upsize or downsize |
| 01:31:53 | Luke-Jr: | Emcy: … |
| 01:32:13 | Luke-Jr: | as much as one has the right to doubt MtGox, making bad arguments doesn't help :P |
| 01:32:51 | tacotime_: | Luke-Jr, stopping the FUD one rumour at a time. |
| 01:32:51 | Emcy: | i havent made an argument |
| 01:33:32 | Emcy: | did they movd or not |
| 01:35:09 | Luke-Jr: | they publicly stated they were moving *because* the crisis was creating a risk to their employees' safety |
| 01:35:15 | Luke-Jr: | that part sounds perfectly reasonable to me |
| 01:35:36 | Emcy: | er |
| 01:35:38 | Luke-Jr: | tacotime_: it's not even FUD, just bad logic |
| 01:35:45 | Emcy: | wernt they in a high rise in tokyo |
| 01:36:52 | Luke-Jr: | the conclusion may very well be true, but bad logic is still bad logic :P |
| 01:37:44 | Emcy: | what logic |
| 02:15:10 | jhj: | jhj is now known as trn |
| 02:19:52 | justanotheruser: | Could anyone give me an example of a script that would be difficult to make in a lisp-like language? (and (not (= $1 $2))) (= (sha256 $1) (sha256 $2))) is the syntax right now |
| 02:20:20 | justanotheruser: | searching for corner cases |
| 02:36:56 | pawpads: | pawpads has left #bitcoin-wizards |
| 03:44:59 | EasyAt: | EasyAt is now known as EasyAt|Sofa |
| 03:54:23 | qwertyoruiop: | qwertyoruiop is now known as MagicalFat |
| 03:54:43 | MagicalFat: | MagicalFat is now known as haematite |
| 03:55:11 | haematite: | haematite is now known as qwertyoruiop |
| 04:01:04 | justanotheruser: | justanotheruser is now known as just[dead] |
| 04:03:43 | just[dead]: | just[dead] is now known as justanotheruser |
| 04:14:56 | jcrubino: | jcrubino is now known as Guest85810 |
| 05:50:12 | austinhill: | So I've gotten some questions from reporters about the supposed $370 million in BTC mission from Mt Gox…I know that gmaxwell did some blockchain investigations the other day and showed multiple re-payments of transactions coming from Mt Gox |
| 05:50:58 | brisque: | can we be sure they are repayments rather than just two payments of the same amount? |
| 05:51:27 | austinhill: | Can this issue be really the only explaination? Seems far fetched to me that transaction malleability which was known for years went unnoticed for so long with them and they just woke up a realized they were insolvent |
| 05:52:35 | austinhill: | If I remember gmaxwell's description it pointed to two payments of the same amount. I'm not sure if the 2nd payment was requested because the 1st didnt show up or one of the parties knew there was a flaw in their implementation and took advantage…do we have any info on this? |
| 05:53:51 | brisque: | what would be apparent is Mt Gox making two withdrawals to the same address and the same amount, we probably can't say for certain if this was intended or not though. people like whole numbers and often reuse addresses. |
| 05:54:25 | brisque: | gmaxwell might have better heuristics though, it's possible he has better data than that. |
| 05:55:42 | gmaxwell: | austinhill: I think it's probably incorrect to assume that malleability was playing a role in all of their losses. |
| 05:56:43 | gmaxwell: | austinhill: mtgox was reissuing payments when the originals didn't go through. In at least some cases they did this without conflicting the original transactions. This immediately guarantees a risk of loss even absent malleability, since nothing prevents both txn from going through. |
| 05:57:07 | Emcy: | 370 million? source? |
| 05:57:14 | gmaxwell: | Though I don't have any reason to believe that regular customers were getting extra payments by chance frequently, as you'd think that would get. reported. |
| 05:57:47 | gmaxwell: | The role malleability would have played there was potentially making it more reliably exploitable. The numbers are a bit hard to believe in any case. |
| 05:57:48 | EasyAt|Sofa: | EasyAt|Sofa is now known as EasyAt |
| 05:58:07 | phantomcircuit: | gmaxwell, yeah actually since their default is to send w/o any tx fee |
| 05:58:21 | phantomcircuit: | this could all have happened even without malleability |
| 05:58:24 | gmaxwell: | I did analysis and found a LOT of duplicate gox payments: but the single transaction and daily withdrawl limits would make us expect a lot of duplication without theft. |
| 06:00:32 | austinhill: | Source for claim is http://two-bit-idiot.tumblr.com/post/77745633839/bitcoins-apocalyptic-moment-mt-gox-may-have-lost which in todays rate means around $370m |
| 06:00:50 | gmaxwell: | I also note that people getting "unknown/unexpected" payments isn't unheard of, and the foundation attorney was giving advice to people that if you recieved such a payment the funds were yours: https://github.com/TheBitcoinFoundation/legal/blob/master/White%20Papers/White%20Paper%20-%20Receipt%20of%20BTC%20From%20Unknown%20Person.mdown |
| 06:02:07 | Emcy: | austinhill you realise there is large incentive to spook the market right now |
| 06:02:12 | austinhill: | gmaxwell: So this was my view as well. There wasn't a well known problem in transaction malleability that allowed unknown hackers to steal for months/years from them. These funds are either double paid to existing mtgox customers or someone around mt gox has stolen funds. |
| 06:02:49 | phantomcircuit: | gmaxwell, yet another example of patrick murck being a complete and utter retard |
| 06:02:58 | phantomcircuit: | that advise is absolutely unconditionally wrong |
| 06:03:10 | phantomcircuit: | nearly every state has a law on the books covering that which makes it theft |
| 06:03:31 | gmaxwell: | austinhill: correct. Nothing about malleability would allow theft normally. And to the best of my ability no other bitcoin business has infrastructure for performing reissues at all. MTGox had other software bugs that made having a reissue facility interesting. |
| 06:03:34 | austinhill: | Sure - but the market is spooked as is - FACTs and using this moment to let everyone know that 'trust me' exchange models are broken and suggesting strong crypotgraphic trustless infrastructures as minimum technical requirement for operating an exchange only come by a few times |
| 06:04:03 | gmaxwell: | phantomcircuit: I pointed this out and cited law in several states, in fact. It's a myopic position centered exclusively on a narrow aspect of the UCC and ignoring the rest of the law. |
| 06:04:21 | brisque: | gmaxwell: surely when you're at that size, it would be cheaper and easier to pay a mining pool out of band to confirm your transactions. |
| 06:04:28 | phantomcircuit: | gmaxwell, http://www.oregonlaws.org/ors/164.065 |
| 06:04:40 | gmaxwell: | brisque: they had such a setup with eligius. |
| 06:05:04 | gmaxwell: | austinhill: I don't know if you saw but I proposed some of that and it appears to be getting some traction with several places saying they'll implement. |
| 06:05:16 | phantomcircuit: | gmaxwell, i honestly believe that murck is personally responsible for a multitude of tragendies in the bitcoin space |
| 06:05:26 | Emcy: | austinhill you say this inthe same week as the first genuine bitcoin banks opens up and everyone loves it |
| 06:05:29 | phantomcircuit: | including coinlabs failure to understand state money transmitter laws |
| 06:05:38 | phantomcircuit: | tradehills failure to understand state money transmitter laws |
| 06:05:45 | phantomcircuit: | and the retards suing me in san francisco |
| 06:06:00 | brisque: | gmaxwell: certainly makes sense to. with such an agreement in place you don't even need to be broadcasting transactions at all, almost. |
| 06:06:10 | phantomcircuit: | gmaxwell, also probably bitinstant's failure to understand mt laws |
| 06:06:18 | gmaxwell: | If any of you are in contact with businesses that are hesitant to implement due to confidentality of their holdings, if they're willing to fund work I can point them to academics who I am confident can solve the privacy problem with a modest research grant. |
| 06:06:35 | Emcy: | and it also seems ot be the case that the reference client is falling by the wayside (for end user use) |
| 06:06:38 | austinhill: | gmaxwell: we need to meet this week & discuss, I'm about to call out all those business's who sent out the letter talking about trust in bitcoin businesses but not providing a cryptographic model for trust |
| 06:07:24 | austinhill: | gmaxwell: Adam3us and I believe we have homomorphic encryption & k/n trustless exchange transactions that solve this.... |
| 06:08:48 | Emcy: | austinhill that sounds great, but how do people verify it themselves? |
| 06:08:55 | Emcy: | without being a math phd |
| 06:09:14 | austinhill: | emcy: genuine bitcoin bank in Cyprus I believe, I'm talking about an on blockchain zero-trust cryptographic system whereby people don't need to deposit funds with 3rd parties hoping for the best |
| 06:09:49 | gmaxwell: | austinhill: I think that kind of solution is too invasive in exchanges normal operations, at least in the short term. I've just generally been proposing a simple proof of obligations and assets that shows they aren't fractional that could be published periodically (e.g. daily) |
| 06:10:12 | gmaxwell: | the downside is that it reveals their total holdings, but it wouldn't be too hard to perform in zero knoweldge. |
| 06:11:13 | austinhill: | gmaxwell: yeah, we can do proofs in zero-knowledge, and I think with brands based use of schoor boolean logic we can do more advanced greater then & does include your coins proof of knowledge statements |
| 06:11:58 | jgarzik: | austinhill, yes, that summary is basically correct |
| 06:11:58 | austinhill: | but I'll need my math assistants to back me up on that statement :) Dr. Brands is a friend and will help us if needed |
| 06:12:31 | jgarzik: | Emcy, Has Neo&Bee fully detailed their backend architecture and security setup? |
| 06:13:11 | kanzure: | well, they haven't fomrally described it |
| 06:13:23 | kanzure: | formally |
| 06:14:02 | austinhill: | so I agree, that it's a short term much easier implementation……we can use current 'crises' to list a manifesto or set of principles that we ask all exchanges to adhere to - would be great to shift confidence. I'm willing to pay personally for us to develop said list of principles & have within next few days sample code done so no one has an excuse not to adopt. |
| 06:14:04 | gmaxwell: | austinhill: in any case what we do need to get are business requirements. E.g. what level of privacy do they beleve they need, and how are their coins handled. |
| 06:14:29 | austinhill: | Would be very beneficial to an ecosystem we all believe in & need to see weather this bullshit storm |
| 06:15:34 | austinhill: | Can you come to the BTC house in San Mateo I rented? Let's talk. maaku was here today, adam3us arrives tomorrow, jtimon on wednesday. sipa & mattc are close behind |
| 06:16:08 | austinhill: | I think we convinced luke to leave his home state and join us as well. |
| 06:16:51 | kanzure: | austinhill: can i show up? |
| 06:16:52 | gmaxwell: | Well not this second, this is all horrible timing for me, I am completely saturated (and have been for some time), but I'll have time later this week. |
| 06:16:59 | copumpkin: | a BTC house sounds like fun |
| 06:17:00 | gmaxwell: | :) |
| 06:17:14 | justanotheruser: | austinhill: good idea. Perhaps you should post a list of principles for exchanges on the subreddit. It probably could gain quite a bit of traction |
| 06:18:30 | austinhill: | I was in Malta with adam3us and we came up with a set of principles we think all blockchain based companies should adhere too, maybe I can post these and get feedback and see if it is worthy of posting more publicly |
| 06:19:02 | Emcy: | jgarzik i dont know? |
| 06:19:03 | justanotheruser: | austinhill: what is the bitcoin house? A vacation house? |
| 06:19:04 | gmaxwell: | On this subject, see also: http://www.reddit.com/r/Bitcoin/comments/1yk4nv/please_ask_your_favorite_exchange_to_prove_that/ and https://news.ycombinator.com/item?id=7277865 |
| 06:19:46 | Emcy: | what i meant was, an outfit comes along calling itself a bank for bitcoin and, at least, the reddit swooned. Struck me as ironic |
| 06:19:47 | austinhill: | copumkin: BTC houses are the future :) more of them to come |
| 06:20:53 | Emcy: | vis a vis the theory that people will become more discerning in thier bitcoin institutions after mtgox |
| 06:21:28 | Emcy: | i always saw exchangers as just a way to capitalise value into the system, not a permanent fixture. It seems now like that was naive |
| 06:21:32 | copumpkin: | austinhill: what makes a house a BTC house? |
| 06:21:46 | gmaxwell: | another component which might work well with non-fractional-reserve proofs is time locked funds. There are a couple ways to do that. E.g. services could lock up cold funds so they aren't spendable immediately, so you have a upper bound on their drain rates... preventing them from taking the coins to vegas right after updating their proofs. |
| 06:21:47 | maaku_: | Emcy: we said that after mybitcoin |
| 06:21:51 | austinhill: | emcy: that's the problem. 50% of all BTC exchanges have closed down, stolen client funds or disappeared with money that was not their's. For a beautiful invention like trustless exchance of value we seem to be falling viction to the same old book entry system of off blockchain accounting. I needs to stop |
| 06:22:40 | justanotheruser: | austinhill: how do we move people to use clients instead of web wallets to store coins? |
| 06:22:55 | Emcy: | yes. I beleive it has been commented before about the lack of imagination with bitcoin. Programmable money and all that |
| 06:22:56 | maaku_: | justanotheruser: by building better clients |
| 06:23:50 | gmaxwell: | good hardware wallets may be an ingredient too... hard to say the much belated trezor looks like a disappointment though a move in a useful direction. |
| 06:24:47 | Emcy: | maaku_ for real, bitcoin core needs to pick up the pace |
| 06:25:03 | Emcy: | i dont mean that like work harder guys, i mean you need more people/resources |
| 06:25:27 | justanotheruser: | maaku_: is there something wrong with multibit and electrum? |
| 06:25:54 | maaku_: | justanotheruser: yes |
| 06:26:20 | austinhill: | justanotheruser: I think there is a role for cloud based wallets, but with a bettter security model then brain wallets or web wallets: http://en.wikipedia.org/wiki/Zhenli_Ye_Gon Zhenli Ye Gon was arrested in his home in Mexico with more then $300 million in USD dollars, Euros and hard currency - do we really think this is the future of asset management? People creating piles of cash protected by private keys they ha |
| 06:26:25 | justanotheruser: | maaku_: Any problems with the consensus? |
| 06:27:02 | maaku_: | justanotheruser: neither one of those has a complete set of consensus code... |
| 06:27:08 | maaku_: | you realize those aren't full clients, yes? |
| 06:27:09 | austinhill: | haha I was telling maaku_ the story of Zhenli Ye Gon today |
| 06:27:30 | Emcy: | what does £300mm of cash even look like |
| 06:27:30 | justanotheruser: | austinhill: Isn't the cloud just an fancy way of saying you're giving trust to someone over your money. |
| 06:27:47 | justanotheruser: | maaku_: yes, but if one of the block headers is weird or something it could break the consensus |
| 06:28:02 | jgarzik: | I'd like to see a public "audit website", that scraped/collected "proven reserve" data from other websites |
| 06:28:04 | jgarzik: | raise the visibility |
| 06:28:10 | jgarzik: | incentivize good behavior |
| 06:28:11 | maaku_: | Emcy: google Zhenli Ye Gon |
| 06:28:35 | austinhill: | gmaxwell: I'd give trezor lots of money to turn that device into a commodity that was given away at every 7eleven until we had btc secure client wallet dominance :) |
| 06:29:09 | phantomcircuit: | austinhill, im not sure you quite understand what lots is with hardware development |
| 06:29:13 | Emcy: | ephedrine, shit its heisenberg |
| 06:29:51 | gmaxwell: | austinhill: right. the device is too costly and clunky but some later generation of that development path will solve a lot of problems. |
| 06:30:01 | justanotheruser: | maaku_: anyways, is there any reason you don't like those clients? |
| 06:30:07 | austinhill: | justanotheruser: no, basic mistake in crypto protocols. We can design multi-party signatores and smart contracts that allow for more complex trust agreements so a user can enjoy the benefits of the cloud & web based wallets without having seconded their trust to another party |
| 06:30:27 | gmaxwell: | jgarzik: bitcoinity (popular ticker site) has already said that they will give special preferred placement to exchanges with such infrastructure. |
| 06:30:42 | jgarzik: | austinhill, a la https://www.belshe.com/2013/12/15/p2sh-safe-addresses/ |
| 06:30:54 | Emcy: | maaku_ it looks like a king size bed made out of fat stacks. Well thats good to know. |
| 06:31:01 | antephialtic: | its interesting to me that the most innovative use of multiparty transactions is currently being done by a darknet market |
| 06:31:08 | justanotheruser: | austinhill: instead they are trusting multiple third parties? |
| 06:31:45 | phantomcircuit: | antephialtic, why? if something goes wrong they have nothing to lose |
| 06:31:53 | antephialtic: | the drug markets have been burned like this 5+ times, and they adapted. now its time for everyone else to learn |
| 06:32:01 | maaku_: | justanotheruser: yes, I don't like clients which don't provide the same security / consensus guarantees as the reference client, or as close to it as is possible given performance constraints |
| 06:32:31 | maaku_: | but i'm not singling out those wallets in particular |
| 06:32:37 | austinhill: | jgarzick: Why do you think I want you to come join us at the BTC house :) flight is paid for …..come join it's only the future of trust that awaits you :) |
| 06:33:16 | justanotheruser: | maaku_: Well clearly those that store their coins in places they get stolen (MtGox, web wallets) care more about convenience than security. SPV is a better trade off. It is a slight inconvenience for much better security. |
| 06:33:27 | antephialtic: | phantomcircuit: there is a site on i2p called themarketplace that uses 2-of-3 multisig escrow for all transactions |
| 06:33:39 | antephialtic: | they even wrote a custom electrum plugin |
| 06:34:14 | antephialtic: | not condoning drug use/sale, but it is a better implementation than anything else I've seen in the wild |
| 06:34:38 | phantomcircuit: | antephialtic, im sure that's effective for those kinds of transactions |
| 06:34:54 | phantomcircuit: | but consider that acceptable latency on that is several orders of magnitude larger than an exchange |
| 06:35:47 | Emcy: | would that be a problem if people wernt in such a rush to recreate the HFT clusterfuck |
| 06:36:09 | austinhill: | would any #bitcoins-wizards be willing to sit in on a open dinner with reporters this week in SFO at the BTC house adam3us and I are hosting in San Mateo to answer questions about MtGox and the crisis of confidence that popular media is misreporting on. Format would be an open Q&A for 2-3hrs from a select invite only group of the best tech writers out there who clearly understand tech & bitcoin |
| 06:36:28 | austinhill: | maybe change the tied of misinformation |
| 06:37:15 | antephialtic: | I'm in the bay area, but I'm not a wizard. I just want to be one day |
| 06:37:32 | justanotheruser: | austinhill: I'm not interested in going (and other people in this room would be able to answer the questions way better than me), but could you explain what the bitcoin house is? |
| 06:39:37 | maaku_: | antephialtic: keep up your defense against the dark arts studies |
| 06:40:23 | austinhill: | I have started a new company with a few bitcoin-wizards. We don't like the way so many bitcoin investments occur off blockchain with a trust model that doesn't support the core idea of distributed trust. So we created a new company to build better software, services, and trustless infrastructures to both support bitcoin (we are altcoin haters) and change the world. So we rented a house in san mateo and have a numbe |
| 06:40:45 | jgarzik: | maaku_, heh |
| 06:42:06 | Emcy: | austinhill that sounds good. Why would investors take on risk they dont really have to, unless they havent actually fundamentally understood bitcoin and whats possible? |
| 06:42:40 | antephialtic: | maaku_: hah. I'll keep studying crypto in the meantime, seems to be a decent substitute |
| 06:43:11 | phantomcircuit: | Emcy, the issue is fairly simple actually, people expect orders to execute serially, which means latency determines throughput |
| 06:43:20 | phantomcircuit: | you can change this by changing the execution rules |
| 06:43:26 | phantomcircuit: | but then you end up with people getting mad |
| 06:43:40 | austinhill: | While we see promise in coloured coins and smart contracts, we see that these systems are proposed are fundamentally flawed and require an investment & technological advancement that no one is discussion. So minus everyone debating or seeking blog posts about imaginary coloured coins we decided to undertake large scale blockchain investments. We are tried of merchants & paypal' wanna be's clollecting all the atte |
| 06:43:43 | austinhill: | So that's us :) |
| 06:43:49 | phantomcircuit: | britcoin run with a cronjob every minute and used some pretty interesting math to calculate a reasonable middleground |
| 06:43:54 | jgarzik: | What could we usefully hack into Bitcoin-Qt's wallet in the short term, that would improve people's security? (and motivate other wallets to follow our lead) |
| 06:43:55 | phantomcircuit: | except it confused people |
| 06:44:06 | jgarzik: | a web API to a 2FA signing robot would be easy |
| 06:44:07 | phantomcircuit: | so every so often someone would pay like 10000 GBP/btc |
| 06:44:14 | phantomcircuit: | when 1 BTC ~= 0.2 GBP |
| 06:44:40 | Emcy: | confused people, or bots? |
| 06:44:52 | gmaxwell: | austinhill: I'm game. I'm a bit reportered out... but it'll be interesting to see how the week plays out. |
| 06:45:00 | phantomcircuit: | Emcy, confused people |
| 06:45:12 | phantomcircuit: | the bots happily trading correctly against the confused people |
| 06:45:16 | austinhill: | emcy: I've raised 80 million for cypherpunk technology when everyone was on 28.8 modems…since then created hundred of millions in exists & 4 vc firms - i'm not worried about money ;) |
| 06:45:26 | brisque: | jgarzik: easy enough to have a trusted oracle like that, but it begs the question of who would run it. |
| 06:45:29 | jgarzik: | austinhill, always up for answering questions, if people need questions answered |
| 06:45:45 | phantomcircuit: | austinhill, can i have $3m usd to start a us based bitcoin exchange? this is not a joke |
| 06:45:51 | jgarzik: | brisque, I'd rather distribute that trust across multiple oracles |
| 06:46:08 | jgarzik: | phantomcircuit, start in South Carolina, and require SC corps + IP addresses |
| 06:46:25 | jgarzik: | state-by-state whitelist |
| 06:46:28 | phantomcircuit: | jgarzik, more like idaho and require they be in idaho |
| 06:46:50 | antephialtic: | it takes a bit more than 3m to get 47 different money transmitter licenses needed to operate legally in the US |
| 06:46:51 | austinhill: | gmaxwell: I'll ping you, depending on how the next few days play out - holding a truth talk may be important, but will get your OK & schedule before involving you |
| 06:46:57 | jgarzik: | phantomcircuit, I also researched the cost of doing an incorporation and independent entity in each state |
| 06:47:02 | phantomcircuit: | antephialtic, no it doesn't |
| 06:47:04 | brisque: | jgarzik: is that technically doable? with normal 2FA each oracle would have enough information to cheat the others. |
| 06:47:20 | phantomcircuit: | jgarzik, do you have the numbers for it? im entirely serious |
| 06:47:24 | phantomcircuit: | i mean im a bit drunk |
| 06:47:26 | phantomcircuit: | but also serious |
| 06:47:33 | gmaxwell: | austinhill: how close is the house to the caltrain station? |
| 06:47:50 | jgarzik: | phantomcircuit, under $25m definitely |
| 06:48:03 | jgarzik: | phantomcircuit, under $10m maybe, depending on factors |
| 06:48:11 | phantomcircuit: | jgarzik, is that assuming that you have to post the bonds as cash? |
| 06:48:18 | austinhill: | We are in San Mateo, near 92 * 280 - I'll email you address - we can also subsidize uber & pick ups :) |
| 06:48:47 | jgarzik: | phantomcircuit, yes -- least likely to screw up, though I've also heard of multi-state bonds, which this scheme would necessarily forgo (a cost, versus other models) |
| 06:49:46 | phantomcircuit: | jgarzik, there are properly licensed bond agents which will do all 47 states for a flat fee that ends up being a massive savings over the cost of per state bonding |
| 06:50:17 | phantomcircuit: | it would possibly even be cheaper to be bonded in all 47 states rather than a handful given the market |
| 06:50:25 | phantomcircuit: | (or at least equivalent) |
| 06:50:38 | phantomcircuit: | i guess it's time to start picking up the phone |
| 06:50:46 | phantomcircuit: | (or maybe that time was a year ago) |
| 06:51:40 | austinhill: | Interesting thought…if you could prove you were a money transmitter in the fact that you never took possession of the funds or had control of them, could you reduce your regulatory exposure? |
| 06:52:00 | phantomcircuit: | austinhill, not really no |
| 06:52:13 | phantomcircuit: | but you could probably reduce the cost of the bonds |
| 06:52:22 | phantomcircuit: | actually scratch that |
| 06:52:34 | phantomcircuit: | the companies offering those bonds are probably not that sophisticated |
| 06:53:31 | gmaxwell: | austinhill: shesek (bitrated.com)'s advice from council was along those lines. |
| 06:54:41 | phantomcircuit: | gmaxwell, iirc the federal level regulatory stuff is almost entirely about preventing money laundering (and/or dealing with SDN people) |
| 06:54:51 | phantomcircuit: | state level regulation is largely about... well regulation |
| 06:55:39 | phantomcircuit: | so i cant imagine reducing the real risk your business has visa ve loss of client funds really matters a lot |
| 06:55:46 | phantomcircuit: | even if it should |
| 07:00:26 | phantomcircuit: | i guess open contempt for regulation is probably not helpful towards licensing |
| 07:00:31 | phantomcircuit: | * phantomcircuit walks away whistling |
| 07:03:29 | amiller: | well, regulators just care about making sure the money transmitter doesn't provide any privacy |
| 07:03:46 | petertodd: | amiller: heh |
| 07:03:46 | amiller: | they aren't going to insist you also have to suck at even balancing your own book |
| 07:05:00 | amiller: | so maybe go cryptosolve all that stuff above ground and let the red fist manifesto darklibrary team solve privacy (but they don't need to hook up your bank account!) |
| 07:06:09 | austinhill: | gmaxwell: stilll checking out bitrated link - sorry : got caught up in other discussions with other bitcoin wizards now flying to SFO for participating in house |
| 07:10:52 | brisque: | gmaxwell: out of interest, what was the total value of possible duplicate Mt Gox transactions you found? |
| 07:11:31 | gmaxwell: | brisque: I didn't add them all up, I started to but once it got over some huge number (like 80kbtc) I terminated it as an insufficiently filtered test. |
| 07:11:58 | antephialtic: | heh. well, maybe your filters weren't so off after all. |
| 07:12:27 | gmaxwell: | well I'm pretty sure they're off, heck I suspect even one of my own transactions would have been caught. |
| 07:12:52 | gmaxwell: | problem is that they had both maximum transaction sizes and maximum daily limits on many accounts, so you _expect_ to see people doing 100 100 100 100 100... |
| 07:13:11 | gmaxwell: | (limits + joe blow reuses addresses) |
| 07:13:23 | gmaxwell: | actually no, none of mine would have been repeated because I wouldn't have reused an address. :( |
| 07:13:26 | gmaxwell: | er :) |
| 07:13:29 | brisque: | damn, I was hoping for you to say you found a certain number less than 750k. the explanation they gave just makes no sense. |
| 07:14:10 | gmaxwell: | I mean, its an interesting question but I don't have a full list of their addresses so I wouldn't expect to find all of them. |
| 07:14:29 | gmaxwell: | I could add up ALL duplicate payments in the blockchain... and maybe the number will be less than 750k but I doubt it. |
| 07:14:42 | austinhill: | gmaxwell: What has the response been, this is totally legitimate, well presented (although I admidt a bit technical) - why aren't all exchanges not using k/n signatures being shamed everyday? Thoughts? |
| 07:15:00 | petertodd: | austinhill: it's a lot of software to write, simple as that |
| 07:15:10 | brisque: | do you think blockchain.info keeps a copy of all the unconfirmed transactions they see? that alone would be enough to prove that it wasn't the issue they claim. |
| 07:15:25 | gmaxwell: | austinhill: k/n doesn't work for exchanges, at least not the fashion of exchanges people are using now, because it requires one slow bitcoin transaction per trade. e.g. exchange wants you to leave your coins on the orderbook. |
| 07:15:38 | gmaxwell: | brisque: someone might have had a list of all gox txn. |
| 07:16:06 | gmaxwell: | shesek: hows bitrated's traffic levels been? |
| 07:16:12 | jgarzik: | austinhill, Why aren't bitcoin exchanges shamed into proving their reserves on a regular basis? |
| 07:16:16 | brisque: | gmaxwell: I was thinking we could prove that 750k of modified transactions never existed, but that would work too. |
| 07:16:18 | jgarzik: | Because they suck, and the crowds don't care |
| 07:16:31 | jgarzik: | Bitcoin is too easy to program for... poorly |
| 07:16:36 | brisque: | jgarzik: which is why we have ghash.io double spending and still a majority hashrate. |
| 07:16:40 | gmaxwell: | austinhill: yea, bitrated is pretty good. I recommend it to people in general. (it's web based which creates its own liabilties, but in the framework of what we can deliver today its a big step forward) |
| 07:16:55 | petertodd: | brisque: keep in mind that whether or not ghash.io actualy did something wrong is somewhat debatable |
| 07:17:11 | gmaxwell: | I even had my GF— who'd never used bitcoin before— beta test it with shesek so its provably usable by people who are not bitcoin-wizards. :) |
| 07:17:38 | brisque: | petertodd: I was under the impression that they admitted to it? there was a post somewhere where cex.io mentions the issue had been "dealt with" |
| 07:17:42 | gmaxwell: | petertodd: well their owners agrees it was wrong. (or at least doesn't disagree strongly enough to risk arguing it. :) ) |
| 07:18:10 | petertodd: | brisque: the hard-line view is that miners have no responsibility, and equally, as gmaxwell points out they say the issue is "being looked into" |
| 07:18:11 | gmaxwell: | they claimed that ghash.io was commendeered by people who'd been doing contract work on it, and that these people also robbed them. |
| 07:18:31 | petertodd: | brisque: either view leads to the conclusion they didn't necessarily do anything wrong! |
| 07:18:44 | gmaxwell: | Yea, we don want to be careful about what duty of care we argue miners have. Saying they have none has certian important advantages. |
| 07:18:59 | brisque: | I wasn't aware of the full explanation, that's interesting. |
| 07:19:11 | petertodd: | brisque: and people do like the instant payments and ease of use that ghash.io provides - which IMO is a perfectly rational view to take |
| 07:19:15 | petertodd: | gmaxwell: +1 |
| 07:20:10 | gmaxwell: | petertodd: It would be easier to argue that highest fee or random replace were good miner policies if we had a faster mechenism. bleh. |
| 07:20:25 | petertodd: | gmaxwell: what do you mean by faster? |
| 07:21:15 | gmaxwell: | petertodd: e.g. a two-tier consensus with 1 minute blocks on the faster tier. One problem with having more average uncertanty is that it increases the need to wait for confirmations even on transactions where you generally _can_ afford a risk. |
| 07:21:37 | gmaxwell: | waiting 5 minutes isn't so bad, waiting 30 kinda sucks. |
| 07:21:52 | gmaxwell: | but perhaps this will get better if we get more instant transaction mechenisms. |
| 07:22:01 | gmaxwell: | anyone been following othercoin? |
| 07:22:17 | brisque: | gmaxwell: current implementation aside, would you prefer to have a faster block time? |
| 07:22:24 | petertodd: | gmaxwell: right - it's an interesting thought question re: tree chains with the 1 tx per "block" per model I keep thinking about - how low can you push the block interval and still have good enough and non-gamable consensus? |
| 07:22:44 | petertodd: | gmaxwell: yeah, I wrote up a bunch of advice on the bitcointalk thread |
| 07:22:56 | gmaxwell: | brisque: no. |
| 07:23:17 | gmaxwell: | brisque: though some (of many possibilties) of two tier system might be interesting. |
| 07:23:18 | petertodd: | brisque: speed of light is surprisingly slow... |
| 07:23:31 | gmaxwell: | also there are overheads related to more blocks. |
| 07:23:36 | austinhill: | jgarzik: Best question of the night. All reserves should be automagically proved based on k/n signatories where funds aren't in their control (My preference) or worst case a ZKproof showing full balances and coin based participating that cant be denied |
| 07:24:13 | gmaxwell: | jgarzik: see my earlier reddit links, thats in the process of happening and there are some who are now "working on it" |
| 07:24:27 | petertodd: | austinhill: note that you don't need zk-proofs for this stuff: you can take customer balances and allocate them to txouts on the blockchain on a fine-grained basis that doesn't require revealing the entire balance of the service |
| 07:24:44 | brisque: | petertodd: it's interesting just how slow the current network can be really. I did some investigating as a rainy-day project and found that some blocks take a lot longer to propagate than I expected. |
| 07:24:57 | petertodd: | austinhill: (though obvious zk-proofs can make those proofs stronger against some types of fraud - point is they aren't needed for privacy) |
| 07:25:23 | brisque: | petertodd: the latency between the top 6 mining pools announcing the new work can be anywhere up to 15 seconds, which I wasn't expecting in the least. |
| 07:26:11 | petertodd: | brisque: among other things block messages aren't prioritized in the node-to-node communication protocol |
| 07:26:38 | austinhill: | petertodd: for privacy , I'd love to involve Dr. Brands, I hate the current full disclosure of balances and transaction ledger mechanisms in blockchain 1.0 : if I were building Blockchain 2.0 I'd start with a blinded identity IDE wallet structre |
| 07:26:39 | petertodd: | brisque: e.g. if your "pipe" is full of non-block messages your node will still process them first before processing the new block |
| 07:27:04 | brisque: | petertodd: oh, wow. so enough spam transactions a second would choke up the block delivery completely? |
| 07:27:39 | gmaxwell: | petertodd: so some places don't want to disclose their total holdings. |
| 07:27:41 | brisque: | I never checked, I just expected there to be a priority system. alerts, blocks, transactions, addresses. |
| 07:27:42 | petertodd: | austinhill: sure, though my advice might be to think in terms of a scripting language that's flexible enough that blinded identity features can be implemented on top of the basic consensus (where possible) |
| 07:28:12 | gmaxwell: | petertodd: my response to that was "fine, its possible not to do that, but you get to fund some R&D if thats really your requirement. Some of your competition doesn't mind disclosing this however." |
| 07:28:33 | petertodd: | gmaxwell: exactly, which is why I keep saying "take customers a, b, c and allocate their holdings to a *subset* of the total txouts you have, and have multiple merkle trees leading to multiple txouts" - but yeah, obviously more complex on the backend then just having one |
| 07:29:01 | petertodd: | brisque: exactly! frankly the p2p protocol and associated code is pretty primative |
| 07:29:29 | gmaxwell: | petertodd: I think they should just take the scheme we discussed previously and execute it under a ZKP for general programs. It would be similar in size to the zerocash proofs. |
| 07:30:16 | petertodd: | gmaxwell: a ZKP for general programs doesn't meet the crypto-blub test: "Can fine-arts graduate Peter Todd implement it over a weekend?" |
| 07:30:23 | gmaxwell: | I think there is a way using the new blind-ecdsa technique to get the signature out of the zkp too. |
| 07:30:38 | gmaxwell: | petertodd: thats what libraries are for. |
| 07:30:58 | Emcy: | a guy had over 4700coin on gox |
| 07:31:01 | Emcy: | oh my good lord |
| 07:31:04 | petertodd: | gmaxwell: so what? those libraries will need to be ported to multiple languages, tested, etc. etc. it's much uglier than just implementing the dumb thing first |
| 07:31:07 | gmaxwell: | Emcy: I talked to people with more than that. |
| 07:31:36 | Emcy: | this is going to be shitstom that defies description |
| 07:31:38 | midnightmagic: | Emcy: that's not a lot. |
| 07:31:44 | gmaxwell: | petertodd: oh come on. "system() to a process written in C" I know people are fixated on reinventing the wheel but none of these places are writing their own https servers. :P |
| 07:32:12 | gmaxwell: | I think people should do the dumb and not private thing first, then market pressure will fund whatever it takes to get the private thing. |
| 07:32:14 | petertodd: | gmaxwell: hey, I'm being pragmatic here... we can always roll out a ZKP scheme later |
| 07:32:18 | michagogo|cloud: | At this point, I'm glad I got cold feet before buying about 1.5-2 goxcoin at roughly 2:1 |
| 07:32:55 | Emcy: | gmaxwell i bet you feel kinda sorry for buying that goxcoin. THough it wasnt a bad bet based on information at the time |
| 07:33:24 | midnightmagic: | michagogo|cloud: I missed the boat and thus via my endless state of fugue-like procrastination, was I saved again. |
| 07:33:30 | Emcy: | midnightmagic er its a lot of an individual |
| 07:33:50 | phantomcircuit: | i'd love to provide a hosted wallet service that could provide all kinds of neat stuff like that |
| 07:33:57 | midnightmagic: | Emcy: I mean relatively. |
| 07:33:57 | phantomcircuit: | but im pretty sure it would qualify as mt |
| 07:33:59 | phantomcircuit: | :/ |
| 07:34:00 | brisque: | petertodd: I guess it makes sense that's it's fairly simple, last thing the project needs is complicated changes that gets broken easily. I was expecting blocks to have priority though. |
| 07:34:08 | gmaxwell: | petertodd: k then we're not in disagreement. |
| 07:34:10 | jgarzik: | Days ago, I would have thought buying goxcoin to be a highly risky, possibly profitable bet. |
| 07:34:31 | phantomcircuit: | jgarzik, ditto for probably everybody in here |
| 07:34:35 | jgarzik: | The siphoning is pretty stunning -- how could that not be noticed? Seems to violate every fundamental of software accounting. |
| 07:34:40 | jgarzik: | I. mean. WTF. |
| 07:35:02 | midnightmagic: | Collecting a calculated balance from hundreds of thousands of addresses seems to me to be a somewhat harder problem. |
| 07:35:09 | gmaxwell: | Emcy: I bought most of it on the 8th and 9th. I considered it risky, but I was pissed about people pumping fund while buying goxcoin, and after talking to MT it seemed not much more dangerous than depositing funds with a third party normally. |
| 07:35:12 | Emcy: | it it becoming accepted that they really did have 750 kilocoins skimmed |
| 07:35:13 | jgarzik: | If I were MtGox, I would have a network of independent nodes |
| 07:35:14 | midnightmagic: | Simple github programs notwithstanding. |
| 07:35:16 | petertodd: | gmaxwell: remember that once the basics are understood and libraries are in place, crypto-blub Peter Todd becomes capable of harder things! |
| 07:35:17 | jgarzik: | constantly scanning my TxOuts |
| 07:35:20 | jgarzik: | for theft etc. |
| 07:35:32 | jgarzik: | independent alarms, monitoring balances |
| 07:35:44 | midnightmagic: | Emcy: No source nor cite for the figure. |
| 07:35:47 | wumpus: | yes it baffles the mind... |
| 07:35:55 | brisque: | jgarzik: at a minimum you'd want to be tallying up all the users and checking they had at least that much in the cold storage. they mention they'd made a huge profit from banning people anyway. |
| 07:36:11 | jgarzik: | I mean, you are securing HUNDREDS of millions of dollars in value |
| 07:36:18 | jgarzik: | my watchdogs would have watchdogs |
| 07:36:19 | gmaxwell: | I'd been under the belief that they lost a couple thousand tops and could cover it out of pocket, until their press release on the 10th. |
| 07:36:29 | Emcy: | has anyone actually heard from karpales since the last media thing |
| 07:36:42 | gmaxwell: | jgarzik: if my coins move unexpectidly I get paged. |
| 07:36:47 | petertodd: | brisque: well, even something as simple as doing a portable high-priority scheme is surprisingly non-trivial - TCP OOB data looks like a nice technique but doesn't actually work in practice, so you wind up implementing a bunch of low-level framing crap |
| 07:36:58 | wumpus: | the story of a few helpdesk monkeys screwing up was pretty convincing, but having an automated process hemorrage coins... ouch |
| 07:37:00 | jgarzik: | gmaxwell, after the Coinlab experience, I was pretty sure they were in the hole $10-20m fiat, circa Apr 2013 |
| 07:37:04 | gmaxwell: | and my watchdog has a watchdog (in part because it was broken for several months.. :) ) |
| 07:37:47 | phantomcircuit: | jgarzik, $5m from coinlab, $5m from feds |
| 07:38:00 | petertodd: | jgarzik: the mt gox tale shows a distinct lack of necessary engineering paranoia... |
| 07:38:07 | brisque: | petertodd: well, least I know how to make my blocks faster if I somehow end up running a pool. just having my edge routers ignore everything but blocks would probably do the trick wouldn't it? |
| 07:38:11 | jgarzik: | petertodd, s/mtgox/bitcoin/ |
| 07:38:14 | midnightmagic: | but midas? |
| 07:38:22 | jgarzik: | how many exchanges and wallets have died due to stupid software? |
| 07:38:35 | brisque: | lots of web wallets certainly. |
| 07:38:38 | phantomcircuit: | jgarzik, surprisingly few actually |
| 07:38:44 | phantomcircuit: | most of it has been simple fraud |
| 07:38:54 | midnightmagic: | jgarzik: And how many due to deliberate malfeasance and seizing an opportunity to blame someone else.. |
| 07:39:14 | midnightmagic: | mybitcoin + sr2 + sheep + + + + |
| 07:39:19 | warren: | Google indexing instantwallet ... |
| 07:39:28 | brisque: | gmaxwell: does your watchdog do anything but alert you? |
| 07:39:28 | petertodd: | brisque: yup - on my p2pool node I have it connect to another node that does transaction filtering so all my bandwidth goes to moving blocks basically |
| 07:39:37 | gmaxwell: | jgarzik: I still liked the one that resized their EC2 instance and had no backup. |
| 07:40:02 | petertodd: | jgarzik: well, satoshi did release a bitcoind that automatically make backups useless after 100 transactions... |
| 07:40:07 | brisque: | I liked inputs.io, caimed they had a cold wallet storage system but didn't. |
| 07:40:09 | gmaxwell: | brisque: no just alerts me. For a while I had prefab escape hatch transactions but I broke the script that recreated them every time I made a transaction. |
| 07:40:11 | petertodd: | jgarzik: the stupidity goes deep |
| 07:40:19 | petertodd: | brisque: inputs.io paid back most of the customer funds you know |
| 07:40:40 | brisque: | petertodd: did they? from the thread I read a large portion of them got nothing. |
| 07:40:42 | Emcy: | "144 BTC and 100 were entrusted to me by a friend because he wanted to get into cryptocurrency. I haven't told him what happened just now though he has been updated all this while. I don't know how to." |
| 07:40:45 | Emcy: | thats just sad |
| 07:40:53 | phantomcircuit: | gmaxwell, he didn't have a backup for security reasons :/ |
| 07:40:58 | wumpus: | petertodd: heh, I've proposed many times to at least add a warning for that, or to add an option to make extending the keypool manual, but no one cared |
| 07:41:03 | gmaxwell: | brisque: e.g. if something went wrong I could release a bunch of transactions to move all funds to different offline wallets... but it seemed overly paranoid. |
| 07:41:04 | petertodd: | brisque: nah, that's incorrect, it was like 50% paid back in total or something |
| 07:41:22 | petertodd: | wumpus: says a lot... |
| 07:41:43 | brisque: | petertodd: I must have got sucked into the hyperbole, still a fairly awful performance from the author of the software regardless. |
| 07:42:25 | petertodd: | brisque: sure, it wasn't exactly great, but if anything to me it actually showed an improvement over previous efforts in that space |
| 07:42:29 | brisque: | gmaxwell: difficult without having an online node with your private keys in the clear too. |
| 07:42:36 | wumpus: | in any case this mtgox story, if true, is going to be one of those annoying 'worst bug in history' stories and is going to be told to students for a long time :p |
| 07:42:47 | petertodd: | wumpus: lol, very true |
| 07:43:00 | gmaxwell: | brisque: I had a script that just ran any time I unlocked the funds and wrote out new redirection txn to a file. |
| 07:43:39 | brisque: | of course, that's neat. |
| 07:43:53 | gmaxwell: | if I were really paranoid I would have sent them to some remote server and if it didn't get a heartbeet for N days it would release the transactions. |
| 07:44:10 | midnightmagic: | wow still $500 on cavirtex |
| 07:44:13 | gmaxwell: | beat* |
| 07:44:41 | petertodd: | * petertodd is glad his salary is denominated in USD. |
| 07:45:57 | jgarzik: | dollar cost average right into additional btc |
| 07:46:47 | brisque: | gmaxwell: could be sort of beautiful. a transaction that OP_DROPs all of the users coins into a mini obituary when there's no longer a heartbeat. fraught with the danger of accidental fund-nuking though. |
| 07:46:48 | petertodd: | lol, nah, I'm not much of a risk-taker - even at $1000 I had a big chunk of my wealth in pretty damn boring investments |
| 07:47:12 | wumpus: | petertodd: but I think I should really press the keypool issue, at least remind people to make new backups, it's making me feel pretty bad... every time it's 'but deterministic wallets are around the corner!' |
| 07:47:43 | michagogo|cloud: | * michagogo|cloud has a 10k keypool |
| 07:47:46 | petertodd: | I made sure to sell enough to have a years living expenses covered prior to quitting the day job |
| 07:48:08 | gmaxwell: | wumpus: I think we should just implement the dumbest possible determinstic wallets soon. e.g. just replace the key generator with the hardened-mode bip32 code we already have in the codebase... just to make it determinstic. |
| 07:48:12 | wumpus: | michagogo|cloud: yes, most knowledgeable people have, but a lot of people use the default setting of 100 |
| 07:48:20 | petertodd: | wumpus: a three-line patch to make things safer would get my ACK... |
| 07:48:36 | wumpus: | michagogo|cloud: I have a keypool setting of *crazynumber* and various automatic backups and fallbacks too, but you can't expect that from most peopl |
| 07:48:44 | gmaxwell: | and store the seed in an extra record. |
| 07:48:45 | michagogo|cloud: | Plus another 5-6k keys that I accidentally getnewaddressed a while back because of a typo in a a script |
| 07:49:02 | michagogo|cloud: | (It was supposed to take them from the testnet daemon) |
| 07:49:18 | petertodd: | wumpus: I don't use bitcoin core myself |
| 07:49:21 | gmaxwell: | Good deterministic support is actually hard because determinsm breaks key management, so we need to ultimately bring it back in some way.. otherwise people get @#$@ hard from old computers that get sold and things like that. |
| 07:50:00 | michagogo|cloud: | I might just start a new wallet at some point |
| 07:50:04 | petertodd: | gmaxwell: yeah, well, shits hard and all - the seed model IMO makes that risk clear enough |
| 07:50:32 | michagogo|cloud: | It'll be smaller for faster loading, and its keys will be compressed |
| 07:50:35 | phantomcircuit: | wumpus, crazy number == 1000000 |
| 07:50:36 | antephialtic: | I like the way electrum does things. But I run bitcoin-core as well, just to help the network |
| 07:50:37 | gmaxwell: | michagogo|cloud: things like supporting multiple concurrent wallets, and stuff are what I'm talking about.. or a button to reseed your wallet that also makes you backup before it activates the new seed. |
| 07:51:21 | wumpus: | gmaxwell: still it's quite a large risk to swap the key generation |
| 07:52:19 | gmaxwell: | wumpus: yes, but it's mostly a review/testing risk. the code is straight forward. also other wallets are doing this now and have probably given it actually very little review. :( |
| 07:54:03 | brisque: | gmaxwell: off topic, but can't the mt gox transactions be filtered a lot by the timeframes of the multiple spends? we know that their system won't be spending the same value twice in an hour, that should cut it down quite a bit. |
| 07:55:37 | gmaxwell: | brisque: no, because of the daily limits looking at lot like a reissue |
| 07:55:52 | gmaxwell: | I can point you to some addresses and you can look if you like. I don't think we can tell |
| 07:56:22 | brisque: | gmaxwell: sure, why not. |
| 07:56:26 | wumpus: | gmaxwell: according to Mike's article bitcoinj is going to introduce HD wallets soon, I wonder in what form |
| 07:56:42 | petertodd: | wumpus: BIP32 IIRC |
| 07:56:59 | petertodd: | wumpus: it'll be fun watching people realize how BIP32 + bloom filters quickly results in no privacy... |
| 07:57:00 | wumpus: | petertodd: oh sure, BIP32, but I mean what subset |
| 07:57:07 | justanotheruser: | justanotheruser is now known as just[dead] |
| 07:57:35 | gmaxwell: | brisque: here are some addresses with a bunch of repeated mtgox payments: https://blockchain.info/address/1FfdcppWbJ7FeQFznsjdLYNXdwMdoiTGSA?sort=1 |
| 07:57:38 | gmaxwell: | https://blockchain.info/address/1AacEsKeXqnUqtYQWKDHJV3JtpJkUVFxGj?sort=1 |
| 07:57:41 | gmaxwell: | https://blockchain.info/address/19DJQAMFf9hu3NSfodtkGrwpbJSuy2WvpD?sort=1 |
| 07:58:01 | wumpus: | BIP32 is quite complicated if you want to implement it completely, with the nested structure and public and private derivation and 'hardened derivation' and such |
| 07:58:35 | petertodd: | wumpus: indeed, if I had written it I wouldn't have bothered with even public derivation for version 1 |
| 07:59:36 | gmaxwell: | keep in mind it was originally only public derivation. |
| 08:00:24 | petertodd: | sure, and we probably should have written a private-only standard that was dead simple first, and implement it in bitcoin core in the dumbest possible way |
| 08:01:01 | wumpus: | +1 for the dumbest possible way |
| 08:01:21 | gmaxwell: | I'm certantly happier about the hardened (was private) derrivation... much easier to feel comfortable with it. |
| 08:01:23 | wumpus: | doesn't need to be fancy, just secure... |
| 08:01:47 | petertodd: | heh, I tell ya, the "can a drunk art student implement it?" test is a good one |
| 08:02:02 | brisque: | gmaxwell: I'd be arguing that these aren't the ones we're looking for. the mostly appear in the same block, or within a block or two of one another. I (maybe wrongly) assumed the Gox system would be resending them after 12+ hours. |
| 08:02:03 | petertodd: | ...and with kyle drake, we have two people to test that! |
| 08:02:17 | gmaxwell: | lots of people have implemented all of bip32 now though, so thats a positive sign. |
| 08:02:31 | petertodd: | yeah, just took awhile |
| 08:03:16 | gmaxwell: | brisque: no, they also appear with 12/24 hour gaps. what you're seeing there is people hitting the per transaction limit.. but that doesn't mean that they're not doing 200 200 200 200 200 repeat: 200 200 200 200 200 |
| 08:03:33 | gmaxwell: | brisque: also none of the proposed ways of hitting this should have been reliable. |
| 08:03:47 | gmaxwell: | only 1% of of mtgox signatures would have caused their txn to get delayed. |
| 08:05:33 | brisque: | if the "leaked" document is to be believed, then it was intentionally modified transactions rather than their encoding accidentally causing rejects. |
| 08:06:04 | brisque: | I find it hard to believe that they spend 3 years doubling 1% of withdrawals without somebody reporting the bug back to them. |
| 08:06:11 | gmaxwell: | brisque: don't put any stock in that, it's not like its a technical analysis. |
| 08:06:19 | gmaxwell: | but you misunderstood me. |
| 08:06:52 | gmaxwell: | brisque: unless they had miner help the only highly vulnerable transactions would have been the ones that gox made unrelayable |
| 08:08:03 | gmaxwell: | the gox api was supposidly on a delay... so the only way you could reliably change their tx out from under them is if they failed to get them to relay. |
| 08:08:35 | brisque: | got it. |
| 08:10:01 | gmaxwell: | it still doesn't make a lot of sense regardless. I think the largest tx that gox would let anyone do was 200 BTC in one transaction at least recently. |
| 08:10:14 | gmaxwell: | meaning at least 3750 times. |
| 08:27:54 | brisque: | gmaxwell: am I misremembering, or was there a comment somewhere that they attempted re-spending with higher feea? |
| 08:27:54 | brisque: | gmaxwell: some of these withdraws have 0.001BTC fees, which is excessive to say the least. |
| 08:28:27 | gmaxwell: | brisque: thats the current _mandatory_ mtgox withdraw fee. |
| 08:28:58 | brisque: | oh they'e just throwing money away. |
| 08:29:00 | gmaxwell: | I assume because mtgox didn't understand their issues they just kept cranking the fees higher, up to the stratoshphere. |
| 08:29:13 | gmaxwell: | "txn getting stuck, blocks must be full! pay more fees!" |
| 08:29:27 | gmaxwell: | meanwhile they're spending immature coinbases. |
| 08:29:56 | brisque: | … but we can plainly see that blocks aren't full. even eligius who goes all out with their crazy 1MB block size can't manage a full block. |
| 08:30:46 | CodeShark: | HD wallet, m-of-n multisignature account generation wizard has been added: https://ciphrex.com |
| 08:30:48 | gmaxwell: | brisque: that requires looking. |
| 08:31:17 | CodeShark: | soon to come - proper invoicing and a hosted notification service :) |
| 08:32:02 | CodeShark: | still to do - develop a solid signature request protocol |
| 08:33:17 | CodeShark: | signature requests + coinjoin + payment protocol could probably all be combined somehow |
| 08:33:27 | brisque: | gmaxwell: you'd have to be a moron to be blowing US$1 in fees per transaction without doing some research. |
| 08:33:40 | gmaxwell: | brisque: but mtgox doesn't pay them, the users do |
| 08:33:44 | gmaxwell: | externalities, fuck yea! |
| 08:35:16 | brisque: | ouch. |
| 08:37:47 | wumpus: | petertodd: does the drunk art student test also apply to *daring* to implent a certain thing? honestly I think a drunk art student scores higher there than me, I already get nausesous at looking at the wallet code and thinking about changing it, even though I understand how things work... |
| 08:37:53 | CodeShark: | actually, $1 for a transfer is cheap compared to wires :p |
| 08:38:18 | brisque: | unnecessary expense though, given what they were trying to do |
| 08:39:46 | gmaxwell: | Fools rush in where angels fear to tread. |
| 08:41:27 | brisque: | speaking of fools, I wonder what is going to happen to all of the people who rushed to buy GPUs to mine scamcoins. surely won't be profitable for them to do so now. |
| 08:43:43 | gmaxwell: | brisque: esp with the asics ... but there is at least a secondary market for gamers. |
| 08:44:01 | gmaxwell: | My GPUs were sold after 2 years use ... at a profit.. though probably mostly to altcoin miners. |
| 08:44:46 | brisque: | gmaxwell: did you get your GridSeed miners? they're horribly bad devices |
| 08:48:59 | brisque: | I liked the death-trap power supplies they come with. nothing like exposed AC terminals on a consumer device. |
| 08:49:34 | gmaxwell: | hah. I didn't get a psu with mine, though I have lots of lab powersupplies like that. |
| 08:50:25 | brisque: | neither, but there's people on the forums posting their setups with the exposed terminals just waiting for somebody curious to touch them and kill themselves. they're fine in embedded devices, but exposed sitting on a bench? |
| 08:50:45 | gmaxwell: | mine never quite worked right and I haven't been able to put in more time into @#$@ with it, esp since I probably sank a good 8 hours into it before and then never got emails back from the chinese engineers suppodily responsible for the drivers. |
| 08:51:09 | gmaxwell: | good ones come with a plastic cover that snaps over the spades... guess those didn't. |
| 08:51:47 | brisque: | the first batch of the gridseed devices came with a relay to cycle the power supplies every time their cgminer fork crashed. gives you an idea of the quality of them. |
| 08:52:19 | CodeShark: | haha |
| 08:53:34 | gmaxwell: | brisque: well mostly only needed if you were trying to mine sha256 on them, right? |
| 08:54:50 | brisque: | gmaxwell: I think it was just the dual operation mode, mine was the later revision that didn't come with any of that. mine is just hooked up to a lab power supply from the 80s, they seem stable enough. |
| 09:03:03 | gmaxwell: | mtgox.com now reads, |
| 09:07:31 | petertodd: | wumpus: heh, well there's a 5BTC outstanding bounty to implement replace-for-fee that I've been ignoring because I took one look at the wallet code and decided there were easier ways to make a living... |
| 09:07:54 | gmaxwell: | oh come on, it's not actually difficult code. |
| 09:08:08 | gmaxwell: | It's just ... code that handles peoples money, how hard can that be. |
| 09:08:24 | brisque: | * brisque opens a pitchfork stand nearby |
| 09:08:41 | petertodd: | * petertodd has bad memories of the time he spent a month making some safety-critical leds blink |
| 09:09:37 | gmaxwell: | petertodd: I've written code to control show pyrotechnics. (and lasers, but at least laser safty was hardware assured in my shows) |
| 09:09:55 | petertodd: | gmaxwell: probably very similar then! |
| 09:10:04 | petertodd: | gmaxwell: that code was to detect unintended pyrotechnics basically... |
| 09:10:05 | gmaxwell: | I .. think? thats about the only stuff I've written that would pretty directly get someone killed if it was really poorly handled. |
| 09:10:46 | wumpus: | no it's not actual difficult code |
| 09:11:06 | petertodd: | probably even more directly dangerous than my code - it was just a monitoring thing to alert the operators that something bad had happened and they should Land The Plane Right Now |
| 09:12:52 | brisque: | gmaxwell: people can be scary if they think you're responsible for them losing money though. |
| 09:14:31 | petertodd: | brisque: heh, I've lead caving trips where I was pretty directly responsible for everyone not dying - and we've come closer than I'd like to admit - and I'd still rate that as way nicer than money: at least with caving when you're out of the cave the stress is over and you've got nothing to worry about anymore |
| 09:16:04 | petertodd: | the closest I've come to handling people's money - my dust-b-gone thing - is setup so a human - me - inspects every transaction prior to actually hitting go and destroying the coins |
| 09:16:52 | brisque: | petertodd: exactly. even if somebody decides to step back from Bitcoin, they could be responsible for bugs in a year, 5 years, 15 years from now. there's not really a period where you can't worry. |
| 09:17:06 | brisque: | petertodd: similarly I'd be up for running a p2pool backed mining pool now, if not for the lynch factor. |
| 09:17:13 | gmaxwell: | it's almost as if it would be best to contribute under a pseudonym! |
| 09:17:15 | wumpus: | brisque: ... please don't do that |
| 09:17:20 | gmaxwell: | I wonder why no one has thought of that. |
| 09:17:49 | petertodd: | gmaxwell: heh, it's notably how counterparty - a mastercoin clone - is done under pseudonyms *and* they recently lost $100k to a hack |
| 09:18:06 | brisque: | wumpus: it'd be an easy way of getting a pool going is more what I meant. solve 220k difficulty blocks until you're ready to take a bite out of a real block. |
| 09:18:11 | petertodd: | gmaxwell: also notable how they were confident enough to get to market first... |
| 09:18:48 | brisque: | wumpus: outside of that or owning vast amounts of your own hardware, I think it would be almost impossible to start a mining pool at this point. |
| 09:19:47 | gmaxwell: | brisque: you can pay people to mine on your pool. but really we don't need more pools. |
| 09:20:01 | petertodd: | brisque: it'd be interesting to see what'd happen if, say, ghash.io had to shutdown overnight - would another pool step up to take the place and keep the total # of pools constant, or would we just see further centralization? |
| 09:20:04 | gmaxwell: | We need better pooling. |
| 09:20:21 | gmaxwell: | well there are a bunch of small ones already, including ones like kinlos that are dying |
| 09:21:24 | kinlo: | the problem I'm facing is that I can't explain that it takes more then 1 week to find a block |
| 09:21:31 | brisque: | petertodd: I think the total number of pools would stay the same. even previously large pools like Horrible Horrendous Terrible Tremendous have closed, starting a new one in the current climate of clueless miners would be basically impossible. you'd never solve a block. |
| 09:21:36 | petertodd: | gmaxwell: if you want to fix that problem, hack into ghash.io and take everyone's money... repeatedly... for like a month :P |
| 09:21:37 | kinlo: | that's a fundamental issue every small pool faces :/ |
| 09:21:58 | petertodd: | kinlo: so you've got less hashing power than p2pool |
| 09:22:05 | gmaxwell: | petertodd: I'd rather not have ukranian mobsters kill me thanks. |
| 09:22:07 | kinlo: | petertodd: yes.... |
| 09:22:30 | brisque: | kinlo: yep. the people with huge amounts of hashing power aren't the ones that are capable of making network-sane decisions. |
| 09:22:34 | petertodd: | gmaxwell: oh, I was just saying that to put the blame on you |
| 09:22:50 | gmaxwell: | brisque: nor are most of the current large pool operators. |
| 09:22:52 | kinlo: | petertodd: might help to look at http://blockorigin.pfoe.be/top.php to get an idea :) |
| 09:23:06 | kinlo: | brisque: which is too unfortunate |
| 09:23:25 | petertodd: | kinlo: I find it kinda fascinating that eligius has grown so much |
| 09:23:47 | brisque: | gmaxwell: I'd love to be the voice of reason in ghash.io's ear, but it doesn't seem like that's possible. heck, they don't even change their default block size. |
| 09:24:00 | petertodd: | brisque: meh, why should they? |
| 09:24:51 | petertodd: | kinlo: damn, 10x smaller than p2pool |
| 09:25:18 | kinlo: | petertodd: don't remind me :/ |
| 09:25:27 | gmaxwell: | brisque: discussfish seems to have shrank their blocksize, also ghash is getting _constantly_ orphaned right now,. |
| 09:25:40 | gmaxwell: | they're responsible for I think a majority of the orphans observed on the network. |
| 09:25:56 | gmaxwell: | well actually maybe not now because the fishpool has also been getting orphaned a ton. |
| 09:26:00 | petertodd: | gmaxwell: isn't that 1-3 a day? |
| 09:26:09 | brisque: | they have massive hardware and good networking, why shouldn't they be making mammoth blocks? |
| 09:26:09 | brisque: | more fees for them, and a happier network of users. |
| 09:26:09 | brisque: | petertodd: actually, it's also annoying that they still have their "happy new year" signature running when it's almost march. |
| 09:26:27 | wumpus: | brisque: maybe Chinese new year |
| 09:26:29 | brisque: | gmaxwell: they seem to be orphaning themselves a lot, or have they got over that now? |
| 09:26:49 | brisque: | nah, ghash.io is european. I'd expect that of f2pool. |
| 09:27:04 | petertodd: | brisque: IMO we're better off seeing that transaction pressure now so people don't think bitcoin magically scales |
| 09:28:41 | gmaxwell: | certantly having pressure now is good in that it gets people improving their operations (sendmany, ... not doing what coinbase does) while we still can releave the pressure with a blocksize increase. |
| 09:28:45 | gmaxwell: | easily. |
| 09:29:05 | brisque: | petertodd: I suppose it's down to determining which situation is more optimal for the network. higher performance now or more confidence later. |
| 09:29:06 | gmaxwell: | I think the malleability stuff may have increased sendmany usage, but I haven't checked. |
| 09:29:33 | kinlo: | I really don't understand why not more people use sendmany |
| 09:29:52 | petertodd: | brisque: like greg says, the fixes aren't all that easy, so best to leave lots of capacity on the table as long as possible |
| 09:30:02 | kinlo: | even tough fee's are low, it costs only a small amount of coding. |
| 09:30:12 | brisque: | gmaxwell: ideally you'd have web services offering two send options. a "send expensive" instant transaction, or a "send cheap" 5 minute delayed transaction with all of the outputs bundled into one. |
| 09:30:31 | petertodd: | kinlo: in a lot of situations user experience definitely makes sendmany impractical |
| 09:31:08 | kinlo: | petertodd: probably why I'm having fewer users, but I educate users. They all have to wait until I am ready to send a batch |
| 09:31:23 | gmaxwell: | kinlo: well for a pool where you can do batched payouts its easier, for sites that event trigger on user demand its slightly harder. |
| 09:31:43 | gmaxwell: | esp if you've gotten people used to getting a txid in return. |
| 09:32:23 | petertodd: | gmaxwell: yet another argument against "malliability-proof" txids... |
| 09:32:42 | petertodd: | kinlo: case in point! |
| 09:32:53 | gmaxwell: | yea, you should just be giving a site local handle, and there should be a transaction status page on the site.. (I think coinbase has the status page) |
| 09:35:37 | kinlo: | I do supply ppl with a txid, but haven't seen it being invalidated later on |
| 09:35:57 | kinlo: | nevertheless, it doesnt matter, I just display it and don't use it in my code at all |
| 09:37:29 | petertodd: | http://webbtc.com/scripts/p2sh?offset=18124 <- seems the rate of p2sh transactions is picking up - it'd be nice to have a graph of BTC/day sent via p2sh |
| 09:41:00 | chaterz: | chaterz has left #bitcoin-wizards |
| 10:20:01 | CodeShark: | petertodd: if you stumble across one or if you happen to write a tool to do that, please let me know :) |
| 10:21:41 | CodeShark: | I used to have a tool that could do those types of queries - but I took it down months ago and haven't updated it |
| 11:19:43 | gmaxwell: | I'm not sure if I mentioned it but I figured out how to do ZK proof of coin ownership without having ecdsa verify inside the ZKP. |
| 11:20:03 | TD: | oh? |
| 11:20:14 | TD: | that sounds pleasingly unintuitive :) |
| 11:20:29 | gmaxwell: | dump the utxo out, and arrange it to a hash tree. Verifer does this too. Both prover and verifier get a hash root. (this step can be skipped if you have a blockchain with a utxo commitment) |
| 11:22:20 | gmaxwell: | you extract a hash tree path to select your coin from the tree, you provide the public key for the coin (pub), you provide a random EC point R = nonce*G, and the point pub+R. |
| 11:23:08 | gmaxwell: | the random point, public key, and hash fragment are provided as secret inputs to the zkp, and the hashroot and pub+R are provided as public inputs. |
| 11:24:00 | gmaxwell: | under the ZKP you prove that the coin is a member of the hashroot, that the pubkey is the right pubkey for the scriptpubkey, and you perform just the EC addition (cheap as EC gets) to prove that the pub+R is pub+R. |
| 11:24:46 | gmaxwell: | then outside of the ZKP you create a signature using the private key secret+nonce. The verifyer verifies the signature and the zkp. and is convinced you own the coin. |
| 11:25:32 | gmaxwell: | basically instead of doing ECDSA verify in the ZKP you do an EC public key blinding which is much cheaper. then you sign with the blinded key. |
| 11:25:45 | TD: | ah, i see. i was thinking you meant with no signature at all. moving the signature outside the zkp seems fruitful indeed. i once asked eli about doing RSA inside zk-snarks and he mentioned microcoding modular exponentiation |
| 11:25:56 | TD: | perhaps something like that could be used to reduce the cost even further |
| 11:26:13 | TD: | so rather than implementing the EC point addition in C and then proving that, you implement it natively as a circuit and trigger it from the proved program |
| 11:27:24 | gmaxwell: | indeed. the thought of a circuit for ECDSA was bothering me, I'm much happier with a point addition. |
| 11:43:32 | TD: | gmaxwell: in an arithmetic circuit solving the group operation formula should be just a few gates, right? |
| 11:47:57 | TD: | though i'm not sure if these circuits support division, actually |
| 11:49:54 | adam3us: | gmaxwell: doesnt that just hide which coin you own? |
| 11:49:58 | gmaxwell: | TD: it's some dozen field operations or so. (including some multiplies and squares) in an arith circuit there is some blowup because the field isn't the same size. But it shouldn't be terrible. I believe it would be cheaper than another sha256 hash in any case. |
| 11:50:15 | gmaxwell: | adam3us: sure you can throw the value in there too I didn't mention it because it wasn't needed for the hard part. |
| 11:50:45 | gmaxwell: | e.g. value is a public input and it compares it to the private coin too. showing you can sign for a coin of the specified value. Or of an encrypted value or.. |
| 11:51:03 | adam3us: | gmaxwell: so then you can prove you own a certain value in zkp. but alternatively you could just sign a msg with the private key. why the zkp is my q really. |
| 11:51:37 | gmaxwell: | adam3us: because if I do that I'm revealing to you which coins are mine, which is a loss of privacy if my goal was only to prove to you that there exist coins I could sign for. |
| 11:52:20 | gmaxwell: | and if I'm encrypting the values, this means I could prove that I have some total of coins matching a total of encrypted liabilities, and not reveal to you how much funds I have in the process, just that the books balance. |
| 11:54:52 | TD: | where do you find the time to learn so much about all this maths? i am envious :) |
| 11:55:00 | TD: | i try to keep up but even so, it's tough to find the time |
| 11:55:22 | TD: | could you configure the arith circuit field size to match the secp256k1 field size? |
| 12:02:00 | adam3us: | gmaxwell: but with encrypted values you need something to compare to. that would require what? all users to provide an encrypted and publicly verifiably complete set? |
| 12:07:42 | gmaxwell: | TD: I think not, at least not with the GGPR12 stuff as the arith circuit field size is set by the size of the pairing crypto curve. |
| 12:07:59 | gmaxwell: | adam3us: yea, so this is the old non-fractional reserve protocol stuff without the privacy to solve that. |
| 12:08:25 | gmaxwell: | adam3us: basically you can do a version that involves no funky math, just hashtrees, that proves no fractional reserve with some information leak |
| 12:08:44 | gmaxwell: | first you reveal your bitcoins and prove you can spend them.. so assets are proven. Thats simple. |
| 12:09:16 | gmaxwell: | Then you build a list of all the account balances and arrange them into a hash tree with the sums of the child balances included in the interior nodes. so the root has a hash and a total. |
| 12:09:28 | gmaxwell: | you publish that via a broadcast channel (say, daily) |
| 12:09:52 | gmaxwell: | and then everyone can see that liabilities are <= assets, maybe... to prove that the liabilities are correct: |
| 12:10:28 | gmaxwell: | when each user logs in you give them the tree fragment to prove that they were included in last nights published total and they verify it (with js or browser extension, for example) |
| 12:10:54 | gmaxwell: | of course if a user never logs in, you can steal their balance. |
| 12:10:59 | gmaxwell: | "Oh well, they weren't using it." |
| 12:11:00 | adam3us: | gmaxwell: so the idea is users collectively audit it. they check if their coins are in it? |
| 12:11:06 | gmaxwell: | right. |
| 12:11:41 | adam3us: | gmaxwell: it seems like the zkp version could be vulnerable to proof lending for a fee.. there is no reputation risk for the prover (the actual owner of the coins) |
| 12:11:48 | gmaxwell: | and so to prevent balance data from leaking in that hash tree you can make the tree a huffman tree, which will maximize the equality of branches (or package-merge to make the maximum depth controlled). |
| 12:12:17 | gmaxwell: | adam3us: it could be— or taking the coins to vegas right after making the proof. |
| 12:12:29 | gmaxwell: | but you elevate from incompetence and mismanagemet to gross fraud at that point. |
| 12:13:05 | adam3us: | gmaxwell: yes. i think i'd prefer if no user assets were ever under exchange direct control. that also is possible. the hard part is to make bitcoin scale to handle it, as all trades happen on block chain then |
| 12:13:11 | gmaxwell: | which still seems to be productive to me. You could get more elaborate, like timelocking the funds and show that funds beyond the withdraw daily limits are actually unspendable by the network, but perhaps I'm getting to cipherpunk there. |
| 12:13:44 | adam3us: | gmaxwell: no such thing as too cpunk until the exchange can be run by somali pirates (or MagicalTux:) |
| 12:14:18 | gmaxwell: | I don't think thats a reasonable goal for all cases. It's certantly applicable in some and should be used where it is— but existing exchanges are doing things like hitting velocities of many hundreds of trades per second. |
| 12:14:29 | adam3us: | gmaxwell: i think exante has a published balance address |
| 12:14:47 | adam3us: | gmaxwell: yes thats why i said hard part is to make it scale |
| 12:15:01 | gmaxwell: | in any case getting people to publish proofs has picked up some traction and we'll see some progress there under variations of the protocol I just described, it's better than not. |
| 12:15:23 | sl01: | couldnt the mtgox theft of >500k coins have happened extremely quickly (like a single day) by a single individual with a bunch of verified (fake) accounts with withdrawal limits of 100k BTC |
| 12:15:27 | adam3us: | gmaxwell: i wonder if there is something between "trust exchange" and "trust no one"... eg trust SCIP on sharded blockchain or such |
| 12:15:37 | adam3us: | gmaxwell: agreed |
| 12:16:15 | gmaxwell: | sl01: no, not with reasonable and customary controls in place. |
| 12:16:25 | sl01: | gmaxwell: this is mtgox we're talkin about :) |
| 12:16:49 | sl01: | ... assuming there was no manual cold wallet withdrawal process |
| 12:16:53 | gmaxwell: | sl01: if you scroll up I did mention also making the coins timelocked. :) but I think thats getting to fancy for people's fancyness tolerance. |
| 12:17:05 | gmaxwell: | they've claimed in the past that there was. |
| 12:17:28 | sl01: | yes your solutions for prevention are awesome, i'm just curious what actually happened in this case |
| 12:17:46 | gmaxwell: | the 'leaked' document says losses went on for years. |
| 12:17:49 | adam3us: | gmaxwell: werner mention something about time windows of locked tx or something on bitcointalk.. did you see that post? |
| 12:18:06 | sl01: | yea that seems less belieable than a quick large theft |
| 12:18:16 | sl01: | requires vastly more negligence |
| 12:18:20 | gmaxwell: | maybe? I dunno. it's actually hard to lock a transaction against yourself today. |
| 12:18:32 | gmaxwell: | er lock a txout against yourself. |
| 12:19:37 | gmaxwell: | I came up with a scheme that _almost_ works, if only you could spend a coin without knowing its txid. when you sign the spending transaction (SIGHASH _REALLY_REALLY_ ANYONE CAN PAY) |
| 12:20:10 | adam3us: | gmaxwell: i meant sergio demian lerner (not werner) |
| 12:20:52 | gmaxwell: | (my locking scheme was that you write the release transaction with nlocktime and set the signature to a nothing up my sleeve value, then derrive the pubkey and pay to that) |
| 12:23:58 | sl01: | is it possible to have the script check for leading 0 bits of a hash ? |
| 12:24:15 | sl01: | so you were required to "mine" something to unlock a tx |
| 12:39:20 | mike4: | mike4 is now known as c--O-O |
| 12:45:00 | andytoshi: | wtf i'm asleep for 6 hours and there is 550 lines of wizard scrollback |
| 13:06:21 | nsh: | andytoshi, we are all actually powered by your subconscious. there's a strong correlation between advances in cryptocurrency theory and your late-night cheese consumption profile |
| 13:32:47 | michagogo|cloud: | sl01: No, I don't believe so |
| 13:33:19 | michagogo|cloud: | sl01: I think it would be possible, if OP_SUBSTR hadn't been removed |
| 14:31:39 | roconnor_: | roconnor_ is now known as roconnor |
| 14:42:07 | petertodd: | CodeShark: if python-bitcoinlib can't be used to whip up a script summing up P2SH activity in 10 minutes I've failed as a library API designer. OTOH, for the life of me I can't be bothered to make it into a pretty website for use in preaching the multisig gospel to the masses. :) |
| 14:46:03 | stonecoldpat: | petertodd: does that library work on your local copy of the blockchain? (not sure what pynode is?) |
| 14:46:26 | petertodd: | stonecoldpat: pynode != python-bitcoinlib, specifically my branch of it (what I was previously calling pythonize) |
| 14:46:40 | petertodd: | stonecoldpat: you'd use it with the bitcoin RPC interface to get the blocks |
| 15:00:30 | ghtdak: | ghtdak has left #bitcoin-wizards |
| 16:16:38 | rdymac_: | rdymac_ is now known as rdymac |
| 16:28:08 | maaku_: | sl01: verified fake account should be an oxymoron |
| 16:29:43 | stonecoldpat: | petertodd: is there any guides / examples to get started using that lib? |
| 16:32:19 | michagogo|cloud: | maaku_: right, it should be |
| 16:32:23 | michagogo|cloud: | But this is mtgox. |
| 16:35:28 | sl01: | maaku_: its super easy to fake any of the x/c's verification processes |
| 16:35:41 | sl01: | especially if it's going to net you 700k BTC |
| 16:36:16 | jgarzik: | petertodd, should I just point everyone to your branch as a new official branch? |
| 16:36:34 | jgarzik: | petertodd, interested in taking the responsibility of maintaining the lib long term? |
| 16:37:22 | jgarzik: | petertodd, We need to either merge your branch, or declare your branch the new official branch, and end confusion. |
| 16:38:06 | stonecoldpat: | ahh, i was looking at yours jgarzik and not peters ... |
| 17:04:49 | austinhill: | About to publish an article on Mt Gox, would like feedback / comments https://medium.com/p/f116bd16f8e2 |
| 17:05:45 | _ingsoc: | austinhill: Can I get a draft without having to sign in? |
| 17:06:07 | flotsamuel: | ya, signin requires post-to-twitter permission granting. |
| 17:06:11 | petertodd: | jgarzik: might as well - even at my pace I've still done a good deal more work on it lately than you :P |
| 17:06:47 | petertodd: | jgarzik: and even without the network code fixed yet, it's still quite handy w/ a local bitcoin core node and RPC |
| 17:07:23 | austinhill: | hm, hold on - let me fix that |
| 17:08:56 | austinhill: | formatting broken, but the basic article is here without needing to login https://www.dropbox.com/s/2mgyycq3lf4p3bs/BelieveInBitcoinDraft.pdf |
| 17:10:40 | petertodd: | austinhill: I wouldn't write so glowingly about bitcoin myself, but the mtgox stuff seems spot on |
| 17:12:50 | austinhill: | petertodd: thanks - I'm more bullish on blockchain, then bitcoin per se - hopefully that comes across |
| 17:13:12 | petertodd: | austinhill: see, all my criticisms of bitcoin are of the underlying blockchain tech |
| 17:13:37 | zooko: | austinhill: "about to" when? I could look at it in 1 hour. |
| 17:14:15 | austinhill: | zooko: post is going live before then - but don't worry - you are mentioned in positive light :) |
| 17:14:29 | zooko: | Oh, sweet. Thanks. ☺ |
| 17:30:21 | austinhill: | published, https://medium.com/p/f116bd16f8e2 comments & feedback are welcome |
| 17:31:06 | jgarzik: | austinhill, what is the standard one needs to met, to publish on medium.com? Do they have editors that copy-check or fact-check? Or is it just a pretty blog? |
| 17:32:56 | nsh: | feedback: your article starts with the word 'but' |
| 17:33:04 | nsh: | (i assume i'm missing a reference) |
| 17:35:38 | nsh: | ((twitter would probably rather you used their inline html formating to cite tweets, but that's their problem)) |
| 17:38:08 | austinhill: | jgarzick: a new blog - publishing community. It's nice & easy, my friend @ev from twitter is behind it and they have some great ideas on improving content publishing |
| 17:39:02 | austinhill: | nsh: the "but" is a reference to the video I ended with, probably has my grammar teacher screaming in her grave |
| 17:39:14 | nsh: | * nsh smiles |
| 17:53:38 | maaku_: | austinhill: looks good |
| 17:59:41 | jgarzik: | austinhill, hehehe, I agree with nsh ;-) Just retweeted and the "But" was right there, glaring at me with an evil grammar eye ;p |
| 17:59:48 | jgarzik: | but yeah, I like it |
| 17:59:56 | jgarzik: | ;p |
| 18:01:27 | austinhill: | grammar police have won the day :) edited the BUT out of it |
| 18:01:30 | austinhill: | thanks guys |
| 18:01:40 | nsh: | another victory for fascism! |
| 18:01:43 | nsh: | :) |
| 18:02:21 | zooko: | * zooko laughs out loud. |
| 18:13:04 | nsh: | the OSX gotofail patch just came out |
| 18:38:58 | andytoshi: | austinhill: great article, hopefully provides some perspective to those lacking it |
| 18:52:30 | Luke-Jr: | austinhill: contrary to popular myth, MtGox never did MtG trading cards |
| 18:53:46 | sipa: | indeed |
| 18:54:29 | austinhill: | ah..worthy of a factual update or should we let the myth continue :) |
| 18:55:54 | austinhill: | funny, my friend created ebay and he still cringes everytime he hears the false founder story of his girlfriend wanting to sell pez dispensers online creating the company….but it was reported as fact for years |
| 18:56:24 | Luke-Jr: | "… bad bitcoind api, going out of your way to hack up a really old version of bitcoind to use as your bitcoin manager, …" |
| 18:56:34 | gmaxwell: | Luke-Jr: gwern was looking into that recently, and I think he was going to check with jed, migt be good to checl. |
| 18:56:36 | Luke-Jr: | MtGox wasn't using bitcoind of any version AFAIK? |
| 18:57:30 | austinhill: | That was a comment from a bitcoin-wizard in private chat - won't verify the accuracy of that, but the basic idea I think still holds true |
| 18:59:18 | andytoshi: | Luke-Jr: i think they were using bitcoind for consensus code, afaik they never forked |
| 19:01:35 | Luke-Jr: | andytoshi: I was under the impression they were using QBitcoin |
| 19:03:05 | gmaxwell: | their wallet behavior was very unlike any version of bitcoind. |
| 19:03:26 | gmaxwell: | e.g. including things like having der encoding bugs, which I don't think we've ever had. |
| 19:04:00 | andytoshi: | yeah, transaction generation i'm sure was homebrew code (probably this was a natural thing to do since bitcoind can't store millions of keys) |
| 19:04:36 | Luke-Jr: | https://en.bitcoin.it/wiki/QBitcoin |
| 19:04:57 | sipa: | gmaxwell: and not tracking remotely created spends |
| 19:05:19 | Luke-Jr: | Version 0.1.0 Please note: this version is planned for mid-january 2011 |
| 19:05:25 | Luke-Jr: | wonder if we can get him to release it :x |
| 19:06:40 | gmaxwell: | sipa: indeed. |
| 19:06:58 | sipa: | iirc that was something we only added around 0.3.20ish |
| 19:07:13 | gmaxwell: | I do believe they used bitcoind of a version late enough to have sendrawtransaction at some place in their operation however. |
| 19:07:55 | gmaxwell: | (because MT was complaining that it didn't give useful errors for rejected transactions) |
| 19:08:40 | gmaxwell: | I wonder if the grand total of duplicated payments (value,scriptpubkey) in the blockchain amount to 750kBTC over all time. |
| 19:11:08 | sipa: | gmaxwell: can you find out? |
| 19:12:33 | tacotime_: | Can look for tweaked ECDSA signatures that are slightly malformed in tx? I guess that would back up the claims that this has been going on for years if you could |
| 19:15:47 | tacotime_: | I guess it depends on the method used, can you see scriptSig malleability too? |
| 19:16:45 | comboy: | wouldn't sum of (value,scriptpubkey) be heavily influnced with for example mtgox green address? (I guess people like to round values) |
| 19:18:23 | gmaxwell: | comboy: well, that would be easy to filter. |
| 19:18:43 | gmaxwell: | but my script for checking uses the rpc and is way too slow. so I'd need to do something else. |
| 19:19:32 | comboy: | gmaxwell: mtgox one yes, but some other guys were using it too afair, but yeah if it would turn out to be lower it is some valuable info |
| 19:21:30 | comboy: | *using them, I mean green addresses, sleep good |
| 19:24:05 | tacotime_: | Were green addresses the main area the exploit what used? I didn't even know mtgox was using them until googling what they were right now :P |
| 19:24:13 | tacotime_: | but it makes sense |
| 19:24:20 | tacotime_: | *what=was |
| 19:24:25 | gmaxwell: | mtgox was the only thing that ever used them pretty much. |
| 19:24:36 | gmaxwell: | it was such a crappy idea. |
| 19:25:16 | tacotime_: | I don't understand the point of it exactly. Was it to make tx going through mtgox more visible to the public? |
| 19:26:01 | gmaxwell: | It was so that silk road would instantly process withdraws from mtgox without waiting for confirmation. |
| 19:26:16 | tacotime_: | Ohhh. |
| 19:33:38 | nsh: | so gox got swindled thanks to optimizing black-market compatibility? |
| 19:33:54 | nsh: | there's probably some kind of moral to the story, if so... |
| 19:34:38 | gmaxwell: | I don't think green addresses played a role in their problems. |
| 19:34:55 | gmaxwell: | comboy was just pointing out that it would make some of that analysis harder. |
| 19:35:18 | nsh: | oh, pardon me |
| 19:35:19 | gmaxwell: | but gox knows, a mutation of one of those gree intermediate spends would be super exploitable I bet. |
| 19:35:29 | nsh: | * nsh nods |
| 19:42:47 | petertodd: | http://0bin.net/paste/YSsTChf1mYGXX7+C#D2NYMYLtRibhL2BSkRei4oLvSmq2kWp61U+1Uumc6T4= |
| 19:43:06 | petertodd: | ^ python-bitcoinlib program to scan the blockchain for dup scriptPubKey:nValue outputs |
| 19:43:24 | zooko: | Too bad that https://0bin.net doesn't work. |
| 19:43:31 | nsh: | why-- yeah |
| 19:43:37 | nsh: | someone should write them |
| 19:43:40 | zooko: | (nejucomo just pointed this out to me earlier today. Or was it nsh...) |
| 19:43:58 | nsh: | nejucomo, then i guessed after jumping into the conversation mid-way |
| 19:43:59 | nsh: | :) |
| 19:44:08 | nsh: | at a minimum the js should be served over TLS |
| 19:44:26 | nsh: | though i think you could still subvert it by injecting js into the html |
| 19:45:07 | petertodd: | (specifically https://github.com/petertodd/python-bitcoinlib) |
| 19:45:19 | nsh: | petertodd, how fast do you think that would traverse the whole blockchain? |
| 19:45:42 | petertodd: | nsh: not too fast, but it's parallelizable at least |
| 19:45:46 | nsh: | right |
| 19:46:12 | nsh: | that might be a good project actually: parallelized blockchain arbitrary query service |
| 19:46:18 | wumpus: | hmm I was patching bitcoind to do it, but that's also possible |
| 19:48:04 | RBRubicon: | RBRubicon is now known as fattie_fatlord_g |
| 19:48:06 | helo: | are there any nodes (or patches) out there that just save copies of all transactions / blocks that they receive, for historical post-mortem stuff like this? |
| 19:48:18 | fattie_fatlord_g: | fattie_fatlord_g is now known as fatlord_got_it |
| 19:48:24 | petertodd: | helo: blockchain.info does |
| 19:48:25 | fatlord_got_it: | fatlord_got_it is now known as RBRubicon |
| 19:49:32 | helo: | ahh right |
| 19:49:41 | tacotime_: | Right, yeah, I remember them saving the recent sochi spam |
| 19:50:21 | petertodd: | tacotime_: I assume they expire some unconfirmed tx's, but don't know what their policy actually is |
| 19:51:27 | comboy: | ad duplicates, may be faster to do some sql query on say webbtc.com dump, I don't have it downloaded yet, but I would assume the sum will turn out much higher, even some whale putting coins in the big equal chunks to his storage and moving them could influence it a lot |
| 19:54:18 | wumpus: | there are lots and lots of duplicate txouts |
| 19:54:57 | wumpus: | 2014-02-25 19:54:46 Scanning block 135500 (total up to now 3016807.75691431) |
| 19:55:16 | tacotime_: | oof |
| 19:55:38 | petertodd: | gah, I gotta write a BlockChainHeaders class for python-bitcoinlib and read this directly from disk - RPC isn't even close to saturating a single CPU, and disk io isn't the bottleneck either |
| 19:56:32 | comboy: | if there was automatic reissue, and reissue time or number of blocks would be known, then some a bit more complicated but much more valuable analysis could be made |
| 19:57:32 | wumpus: | comboy: something like 'count only duplicates within X blocks'? |
| 19:57:50 | comboy: | and if the issue was really big then I guess historgram of time between duplicates could help to guess |
| 19:58:08 | comboy: | wumpus: with lower limit too |
| 20:00:48 | kanzure: | 11:58 the only problem I see with it is that you can cheat by collapsing accounts which have the same value into the same node, but that's trivial to fix |
| 20:00:51 | kanzure: | 12:00 (note that if you don't fix it it's actually a serious problem, because since account values are discrete I can make a fake tree that holds "everybody's" money while only reporting a root value as large as the largest account) |
| 20:00:55 | kanzure: | gmaxwell: has this been considered? |
| 20:03:02 | kanzure: | actually, nevermind, i shouldn't play that game. i haven't tried implementing it yet. |
| 20:04:54 | gmaxwell: | kanzure: wha? no you have the account name in the tree. |
| 20:05:07 | gmaxwell: | and yes, this was pointed out in the original description. |
| 20:08:20 | maaku_: | gmaxwell: is there a good tool for making those types of queries (e.g. looking for repeated payments)? |
| 20:08:26 | maaku_: | i wanted to do that same check this morning |
| 20:08:42 | gmaxwell: | maaku_: no, I was just hitting the rpc with python and walking blocks but it was insanely slow. |
| 20:08:44 | maaku_: | maaku_ is now known as maaku |
| 20:08:55 | gmaxwell: | maybe the znort tool could be easily modified. |
| 20:11:36 | petertodd: | probably a good deal faster to read the blocks directly off disk |
| 20:11:48 | maaku: | yeah znort looks like the right tool |
| 20:11:56 | maaku: | too bad I don't have time to do that today |
| 20:12:19 | petertodd: | maaku: heh, my run will be done in another hour or two anyway :) |
| 20:12:29 | maaku: | petertodd: cool |
| 20:12:40 | nsh: | https://github.com/znort987/blockparser <- presumably? |
| 20:12:46 | petertodd: | nsh: yup |
| 20:12:50 | nsh: | k |
| 20:13:21 | nsh: | * nsh +1s BlockChainHeaders class for python-bitcoinlib |
| 20:13:56 | sipa: | how will it know where which block is stored? |
| 20:14:09 | maaku: | * maaku needs to update his sql backend for blockchain storage |
| 20:14:29 | petertodd: | sipa: it'd be just the headers for v1 I figure, so you'd just read the blocks on disk and check that they were in the best chain |
| 20:14:39 | wumpus: | if you're going to use a c++ tool anyway, why not patch it into bitcoind itself? :p |
| 20:14:39 | petertodd: | sipa: having a |
| 20:14:53 | petertodd: | sipa: having a SPV-style header class is useful generally |
| 20:37:48 | michagogo|cloud: | 20:55:55 funny, my friend created ebay and he still cringes everytime he hears the false founder story of his girlfriend wanting to sell pez dispensers online creating the company….but it was reported as fact for years |
| 20:37:51 | nsh: | * nsh listens to http://www.youtube.com/watch?v=1mWkY5yIAnc&feature=youtu.be "MtGox Saga Continues - Update 25 Feb 2014" (live) |
| 20:37:58 | michagogo|cloud: | Pez dispensers? Wasn't it a broken laser pointer? |
| 20:39:17 | hno: | Is there some reliable backbone bitcoin nodes available to connect to? |
| 20:48:37 | nsh: | gmaxwell, petertodd: you two just got a big h/t on this blahcast |
| 20:49:27 | nsh: | for proof-of-solvency |
| 20:53:22 | gmaxwell: | h/t? |
| 20:53:36 | nsh: | hat tip |
| 20:53:57 | nsh: | (some new twitter slang the youths are using) |
| 20:57:43 | nsh_: | nsh_ is now known as nsh |
| 20:58:03 | michagogo|cloud: | Ah, that's what that means? |
| 20:58:41 | nsh: | * nsh nods |
| 21:28:47 | wumpus: | maybe by adding fee=0.001 criteria to the scan for duplicate outputs it's possible to narrow things down to mtgox transactions more |
| 21:46:50 | gmaxwell: | wumpus: only applies to recent txn |
| 21:46:59 | gmaxwell: | they made that mandatory a couple months ago. |
| 21:47:34 | gmaxwell: | Another random goxthought: Imagine if their green address stuff hadn't been turned off... and imagine that bitstamp accepted them. |
| 21:47:49 | gmaxwell: | When gox shut off withdraws they had over 30k btc in stalled payments. |
| 21:48:14 | gmaxwell: | could have caused other sites to fail too |
| 21:51:15 | nsh: | mmm |
| 21:52:22 | spinza: | Who would trust a zero confirm from Gox in the last couple of months? |
| 21:55:05 | Emcy: | strange request guys |
| 21:55:12 | nsh: | i certainly think that assumptions between service providers about the trustability or internal dynamics of each other will continue to be a fertile ground for fuckups |
| 21:56:08 | Emcy: | does anyone know how to roughly calculate the distance of a laser source based on a diffraction spread diameter of about 6-7 inches on my wall and an assumed source beam diameter of say half a cm or whatever they are? |
| 21:56:15 | Emcy: | i need to direct police |
| 21:56:44 | sipa: | ? |
| 21:56:47 | midnightmagic: | Emcy: I know someone who does. Want me to ask? |
| 21:56:48 | nsh: | assuming it's a nuisance laser-pointer, i suspect the effect from the lens will be much greater than from the air |
| 21:57:00 | nsh: | so it might be hard to estimate accurately |
| 21:57:28 | sipa: | half a cm wide? that's huge! |
| 21:57:35 | Emcy: | lasers are not typically focussed right, they are a coherent beam? |
| 21:57:48 | gmaxwell: | Emcy: it depends on the divergence of the laser. |
| 21:57:51 | Emcy: | sipa i dont know what the aperture of these high powered green pointers is |
| 21:58:08 | Emcy: | shit |
| 21:58:20 | Emcy: | i thought the divergence factor was constant over distance in air |
| 21:58:51 | sipa: | that'd give you an exponential shaped beam section :) |
| 21:59:15 | gmaxwell: | usually laser diodes have crap divergence, but the green pointers are DPSS yag can have fairly reasonable divergence. |
| 21:59:38 | Emcy: | well its definitely green |
| 21:59:42 | gmaxwell: | a typical hene laser won't have visibly increased in spot size even after going a half mile. |
| 22:00:16 | gmaxwell: | Emcy: are there mind control lasers showing up in your room? |
| 22:00:27 | Emcy: | green and quite high power judging from the spot diameter and brightness on the wall |
| 22:00:40 | Emcy: | gmaxwell no im being serious, this is the second night theyre doing this |
| 22:01:04 | gmaxwell: | I imagine the distintance is limited by accessible line of sight |
| 22:01:24 | nsh: | write code to get the line-of-sight from the refraction at the window pane and the reflection from the wall... |
| 22:01:34 | nsh: | , buy stronger laser |
| 22:01:47 | Emcy: | right, if you say a good green diode can throw a beam miles before diverging, then i might have sent police to the complete wrong place |
| 22:02:06 | gmaxwell: | Emcy: nah, not miles.. |
| 22:02:24 | gmaxwell: | (a hene could but not a green laser pointer, go look up some divergence numbers) |
| 22:02:31 | Emcy: | the place im assuming so far is perhaps 2-300 foot out back |
| 22:02:51 | Emcy: | gmaxwell im assuming its one of those 125mw green jobs of the internet that kids buy |
| 22:02:54 | gmaxwell: | how big is the spot? |
| 22:03:20 | Emcy: | 6 or 7 inches from what i saw. Definitely aiming for the window though |
| 22:03:26 | nsh: | if it's deliberate, chances are they're limited by the range of how far they can see and snicker, rather than the laser range |
| 22:03:54 | Emcy: | youre probably right about that |
| 22:03:56 | nsh: | you can also estimate from the saccade, mmm, jerkiness, assuming they aren't using a tripod |
| 22:03:57 | gmaxwell: | http://www.wickedlasers.com/lasers/Executive_Series-55-3.html < says 1mRad |
| 22:04:04 | Emcy: | it has to be on the common ground behind the house then |
| 22:04:46 | gmaxwell: | and a diameter of 1.6mm |
| 22:04:56 | Emcy: | gmaxwell that is so far over my head. Ive been searching google for some sort of nifty calculator :( |
| 22:05:57 | gmaxwell: | so 1.6mm to 6inches at 1mrad is about 495 feet. |
| 22:06:26 | gmaxwell: | the range there was .8 - 1.0 mrad. |
| 22:06:37 | Emcy: | so perhaps a bit less? |
| 22:07:04 | gmaxwell: | no, perhaps a bit more— if it was that laser, but perhaps theirs was worse or they've dorked up the optics. |
| 22:07:37 | Emcy: | either way they are definitely on that common land then |
| 22:07:50 | gmaxwell: | or perhaps the spot was really 5 inches? |
| 22:08:19 | Emcy: | i only got a glance at it |
| 22:09:00 | Emcy: | but that common stretches from basically the back of the garden to like a mile away, theres nowhere else to fire it from to get that angle, apart from the hill like 3 miles away |
| 22:09:11 | gmaxwell: | why not close your blinds? |
| 22:09:39 | Emcy: | first thing i did. Im just annoyed with this |
| 22:10:08 | Emcy: | i had a run in with a laser idiot before and had a sore retina for about a month, its not fun |
| 22:11:19 | Emcy: | thanks for the estimate though gmaxwell you are a boss |
| 22:11:38 | Emcy: | if theyre still fucking around with it the police should be able to search them down from where i told them to go |
| 22:12:30 | midnightmagic: | we're all going to end up blind or looking like giant human-sized insects with opaque subglasses covering our eyes at all times. :( |
| 22:13:09 | midnightmagic: | Emcy: You want to really get some movement on it, tell them they were shining it into the sky at airplanes. |
| 22:13:20 | spinza: | Do you live in a flight path? Perhaps if you suggest they may be targeting planes you could encourage a stronger police response? |
| 22:13:26 | midnightmagic: | Emcy: The penalties for that are *insane* plus jailtime. |
| 22:13:32 | midnightmagic: | +1 spinza |
| 22:13:34 | midnightmagic: | lol |
| 22:13:35 | spinza: | Doh |
| 22:13:39 | Emcy: | midnightmagic the police lady took my details, i dont want to start blatantly bulshitting |
| 22:14:03 | midnightmagic: | Emcy: Bullshit when your permanent ability to see is at risk.. IMO justified. |
| 22:14:19 | Emcy: | i think there is a flight path out of cardiff airport over here. |
| 22:14:27 | midnightmagic: | (If you're getting no satisfactory results.) |
| 22:14:37 | Emcy: | but the planes are at cruising altitude by the time the fly over |
| 22:15:37 | spinza: | Don't have to lie. Just ask the police whether the guys might be doing that? |
| 22:15:57 | midnightmagic: | Emcy: Good luck man. I got nailed with one while I was riding in the bus one day many years ago and recovered so gradually it doesn't feel like I have my original vision back yet (though my optometrist insists I do). |
| 22:15:57 | gmaxwell: | Emcy: to be fair, even 100mw laser if the spot size is 5-6 inches is not going to give you much exposure, and the blink reflex is absolutely amazing at 532 nm. |
| 22:16:07 | Emcy: | thats true. I can imagine they are shining it straight up if theyre prepared to lase rows of houses actually |
| 22:16:42 | Emcy: | midnightmagic it fucking sucks doesnt it m8 |
| 22:16:51 | midnightmagic: | never felt anything like it. |
| 22:17:06 | gmaxwell: | pfft sissies. |
| 22:17:18 | Emcy: | gmaxwell thats true. caught it out of the corner of my eye at first, so bright green |
| 22:17:22 | midnightmagic: | completely unique pain. lol dude I was blind in one eye for three weeks. |
| 22:17:30 | midnightmagic: | well. impaired. |
| 22:18:28 | midnightmagic: | I'm good now: I can see those little brown dots in movie theatres that are only up for a frame, and my night vision is excellent. |
| 22:18:41 | Emcy: | i didnt get blinded |
| 22:19:20 | Emcy: | i had a blurry patch for ages, optometrist said that an inflamed retina moved the cells out of focal length with the rest of my eye, which made sense |
| 22:21:25 | Emcy: | but it got better and i also have top night vision which is nice |
| 22:21:47 | midnightmagic: | my blurry/grey patch was right in the centre. I don't understand how it was so severe for me, it was just an instant, and I reacted very quickly. |
| 22:21:47 | midnightmagic: | yay |
| 22:22:36 | Emcy: | certain wavelengths can bleach the retina pigment very quickly |
| 22:22:44 | gmaxwell: | yea, it was bleaching, |
| 22:22:52 | gmaxwell: | I've seen what you're talking about but never got it in the center. |
| 22:23:01 | Emcy: | or make it react the opposite way its supposed to, which is bleaching to protect the cells |
| 22:23:21 | Emcy: | in fact apparently those bright ass blue LEDS can also be hazardous |
| 22:23:43 | Emcy: | the ones that were invented 15 years ago and are now in goddamn everything |
| 22:24:50 | Emcy: | https://en.wikipedia.org/wiki/Blue_light_hazard#Blue-light_hazard wiki got it |
| 22:33:24 | Emcy: | lol im actually more upset about the cat. Shes an old cat and she sits in that window and looks out over that turf like 16 hours a day |
| 22:33:33 | Emcy: | and i cant watch her 24/7 |
| 22:37:21 | nsh: | :( |
| 22:43:54 | Emcy: | its different when theres a cat involved right, lol |
| 22:45:26 | sipa: | i love a potential attack on bitcoin is offtopic in #bitcoin-dev, but diffraction of laser pointers is ontopic here :) |
| 22:45:58 | sipa: | *how |
| 22:46:50 | Luke-Jr: | lol |
| 22:47:12 | tacotime_: | it's part of the new proof-of-photon scheme. briefly, coins are rewarded by shining lasers into other people's houses. when the nsa logs a call to the police, you get to mint a block. |
| 22:47:51 | Emcy: | its miles off topic, and i apologise, but i needed a rough answer for distance if possible and the most mathy guys i know live here |
| 22:47:54 | Emcy: | so here i came |
| 22:49:59 | nsh: | tacotime_, you joke, but i strongly believe that photons don't exist |
| 22:50:03 | nsh: | :) |
| 22:50:27 | sipa: | that's why we need proof-of-photon to convince you |
| 22:50:42 | Luke-Jr: | sipa: you going to Texas conference? |
| 22:50:57 | Luke-Jr: | we have plans for finalising the proof-of-steak spec there |
| 22:50:59 | tacotime_: | i've heard that the behaviour through a series of slits is totally unpredictable, yeah. ;D |
| 22:51:09 | tacotime_: | oh sweet, where at? |
| 22:51:18 | Luke-Jr: | Texas conference |
| 22:51:26 | Luke-Jr: | we're too disorganised to have anything more specific |
| 22:51:28 | Luke-Jr: | but we'll get it done |
| 22:51:30 | Luke-Jr: | <.< |
| 22:51:31 | tacotime_: | oh okay haha |
| 22:51:48 | sipa: | Luke-Jr: when? |
| 22:52:20 | Luke-Jr: | sipa: March 5-6 |
| 22:52:28 | Luke-Jr: | http://texasbitcoinconference.com/ |
| 22:52:30 | sipa: | in that case, no |
| 22:52:36 | Luke-Jr: | >_< |
| 22:52:40 | tacotime_: | I think I fly in on the late on the 4th and out of the morning of the 7th, so I'll be able to make it on either day |
| 22:53:05 | Luke-Jr: | speaking of which, they want to know if I can moderate the altcoin panel |
| 22:53:19 | Luke-Jr: | but I don't know how to moderate |
| 22:53:37 | sipa: | lol |
| 22:53:48 | tacotime_: | Luke-Jr: I assume texas has a proper concealed carry law |
| 22:54:04 | tacotime_: | Should be straightforward |
| 22:54:28 | tacotime_: | But more seriously, I guess you just don't let any one person ramble on for too long. |
| 22:54:54 | tacotime_: | Who is on the panel? |
| 22:56:13 | Luke-Jr: | tacotime_: besides myself, I have no idea |
| 22:56:56 | tacotime_: | Yeah the schedule just says, "Panel - Alternative Cryptocurrencies" @ 3:20 PM |
| 22:58:31 | tacotime_: | Rassah's giving the introduction to bitcoin eh. hmm. |
| 22:58:39 | Luke-Jr: | anyhow, I don't think I have the personality to moderate tbh |
| 22:58:42 | Luke-Jr: | tacotime_: he usually does |
| 22:58:52 | tacotime_: | * tacotime_ nods |
| 22:59:04 | phantomcircuit: | Luke-Jr, ban all the fools |
| 22:59:16 | phantomcircuit: | oh shit banned everybody |
| 22:59:19 | Luke-Jr: | besides, I would think there would be a huge *perceived* conflict of interest, if a panelist were the moderator |
| 22:59:42 | tacotime_: | wait, which altcoin do you endorse? |
| 22:59:50 | Luke-Jr: | and on top of all that, phantomcircuit is going to be distracting me from the conference with his silly hosted mining |
| 22:59:51 | Luke-Jr: | :P |
| 23:00:03 | jrmithdobbs: | i'll moderate, i think they're all tards |
| 23:00:13 | Luke-Jr: | tacotime_: I created the first altcoin, TBC. I also acknowledge (though don't necessarily endorse) NMC, FRC, and HUC as legit. |
| 23:00:25 | tacotime_: | Ah, okay |
| 23:00:33 | phantomcircuit: | heh |
| 23:00:43 | Luke-Jr: | phantomcircuit: jk |
| 23:00:49 | Emcy: | what is huc |
| 23:00:51 | phantomcircuit: | Luke-Jr, i tried to take pictures but they're super grainy |
| 23:00:53 | phantomcircuit: | not sure why |
| 23:00:58 | Luke-Jr: | phantomcircuit: pictures of what? |
| 23:01:07 | phantomcircuit: | the machines |
| 23:01:07 | Luke-Jr: | Emcy: HunterCoin, a MMORPG |
| 23:01:11 | phantomcircuit: | entire rows |
| 23:01:26 | Luke-Jr: | phantomcircuit: https://www.megabigpower.com/blog/wp-content/uploads/2014/01/Bitfury-Coinseed-Sideview.jpg |
| 23:01:35 | phantomcircuit: | there's like 200 Th/s in 60 sqft |
| 23:01:55 | Luke-Jr: | phantomcircuit: how much would you guys charge me to host 25 Th/s of my own machines? :P |
| 23:01:57 | phantomcircuit: | Luke-Jr, oh damn |
| 23:02:06 | phantomcircuit: | hah that's not gonna be easy to cool |
| 23:02:22 | phantomcircuit: | i can see the shoe racks with box fans now |
| 23:02:54 | Emcy: | >throwing away heat |
| 23:03:17 | phantomcircuit: | Emcy, theoretically the waste heat can be reused |
| 23:03:26 | phantomcircuit: | in practice it's rare that it's actually useful |
| 23:03:33 | phantomcircuit: | in small amounts it is |
| 23:03:37 | phantomcircuit: | when you're talking MW |
| 23:03:40 | phantomcircuit: | not so much |
| 23:03:43 | tacotime_: | it's pretty useful in heating my house in winter. |
| 23:04:27 | tacotime_: | But that's only in the kWs :P |
| 23:04:29 | Luke-Jr: | tacotime_: you offering me hosting? :P |
| 23:04:45 | Emcy: | phantomcircuit thats my one ray of hope regarding consolidated mining vs smalltime mining |
| 23:04:56 | tacotime_: | From September-March, it's almost out of season and I can only pull about 10 kW heh |
| 23:05:16 | Emcy: | that the economics for heat management for each are reversed |
| 23:05:30 | Luke-Jr: | I don't have to host it all in one place :P |
| 23:05:41 | phantomcircuit: | Emcy, it's only reversed if you're using a conventional dc with conventional cooling |
| 23:05:53 | tacotime_: | They're all bitfury cards? |
| 23:05:59 | phantomcircuit: | most mining hw can run much much hotter than normal servers |
| 23:06:14 | maaku: | Luke-Jr: I think FRCJoe is building his own data center in PA, you might want to talk to him |
| 23:06:22 | tacotime_: | The power is steep here too, I wouldn't recommend it. Ontario gov't taxes it like crazy. |
| 23:06:24 | phantomcircuit: | im pretty sure i can setup a dc for mining hw with a PUE of about 1.01 |
| 23:06:27 | gmaxwell: | [random] Someone shold make a multisig mosh... like a share screen session, but commands aren't sent until confirmed by the other user. |
| 23:06:34 | tacotime_: | I pay 60% tax on power, it's insane |
| 23:06:37 | phantomcircuit: | (assuming transformers lose 0%) |
| 23:06:43 | Luke-Jr: | tacotime_: yep |
| 23:06:46 | phantomcircuit: | so probably actually more like 1.06 |
| 23:07:28 | phantomcircuit: | tacotime_, most of the places with super cheap power have very high tax rates |
| 23:07:31 | tacotime_: | I mean I have lots of experience with the H-cards but like I said, $0.15 / kWH is steep. I guess more like $0.13 USD when you convert, though. |
| 23:07:38 | phantomcircuit: | it's something i haven't seen anybody giving serious thought |
| 23:07:41 | phantomcircuit: | which is hilarious |
| 23:07:53 | phantomcircuit: | like those kncminer idiots building a dc in sweden |
| 23:08:07 | phantomcircuit: | the tax rate on that is going to be like 40+% |
| 23:08:10 | Emcy: | phantomcircuit iceland is only so big |
| 23:08:26 | phantomcircuit: | Emcy, im not even talking about iceland |
| 23:08:32 | gmaxwell: | phantomcircuit: those "idiots" are a non-trivial fraction of the network and probably invested none of their own money to get there. |
| 23:08:55 | phantomcircuit: | gmaxwell, i guess that's fair |
| 23:09:03 | Emcy: | i thought knc were selling units |
| 23:09:21 | tacotime_: | I'm hoping raising difficulty and low price will smoke the KnCminer units out, along with everyone else. |
| 23:09:26 | phantomcircuit: | Emcy, to cover NRE, they have a large amount of their own equipment |
| 23:09:27 | tacotime_: | And we can get back to decentralization. |
| 23:09:44 | Emcy: | perhaps the whole shipinng units things is a scam to bootstrap your mining op |
| 23:10:20 | phantomcircuit: | Emcy, scam is the wrong word |
| 23:10:26 | phantomcircuit: | they more or less delivered what they promised |
| 23:10:33 | Emcy: | yeah sorry eciting investment opportunity |
| 23:10:40 | nsh: | has anyone looked into negotiating a mining colo at power production facilities with excess capacity issues |
| 23:10:45 | nsh: | ? |
| 23:10:51 | Luke-Jr: | so any advice on what to do with my 25 Th/s? $25k to host it in Cali, or I could just run one here and resell the rest.. |
| 23:11:10 | phantomcircuit: | nsh, it doesn't work until your equipment starts to hit the point of not being worth running |
| 23:11:21 | nsh: | hm |
| 23:11:27 | phantomcircuit: | since those arrangements typically require you to turn your equipment off when they need the power |
| 23:11:35 | nsh: | ah, right |
| 23:11:56 | phantomcircuit: | nsh, although you could maybe setup a transfer switching agreement with them |
| 23:12:10 | nsh: | not sure what that would entail |
| 23:12:11 | phantomcircuit: | but then you have a very complex contract with pricing that is not predictable |
| 23:12:31 | nsh: | right |
| 23:12:38 | phantomcircuit: | nsh, basically you use their excess capacity at x price and when they dont have any you pay normal pricing at x*2 |
| 23:12:46 | nsh: | ah, gotcha |
| 23:12:46 | phantomcircuit: | except now your powerbill is ??? |
| 23:12:53 | nsh: | * nsh nods |
| 23:13:23 | nsh: | it might work at the right scale but i don't know how confidently you could sell it with the unpredictability of exchange price and hashrate growth |
| 23:13:31 | tacotime_: | In ontario we're smart metered now, so if I chose to run my rigs on off hours I'd only pay 0.08 / kWh. Just haven't gotten around to writing the python scripts. :P |
| 23:13:38 | nsh: | (probably easier to bribe someone in a developing country) |
| 23:14:08 | phantomcircuit: | nsh, there are so many possible tradeoffs it's probably impossible to actually calculate the optimal setup |
| 23:14:15 | nsh: | * nsh nods |
| 23:14:23 | phantomcircuit: | nsh, generally speaking places with cheap power and cold climates have high tax rates |
| 23:14:33 | nsh: | aye |
| 23:14:36 | phantomcircuit: | places with cheap power and hot climates are corrupt developing countries |
| 23:14:48 | phantomcircuit: | (security guards who will shoot at police trying to steal your stuff are expensive) |
| 23:15:10 | tacotime_: | yes. as are coups where all your gear gets stolen. lots of insurance to cover. |
| 23:15:19 | phantomcircuit: | cheap power and cold climates in developed worlds basically means washington state |
| 23:15:32 | phantomcircuit: | they have something like 10MW of spare capacity |
| 23:15:33 | tacotime_: | yeah haha, that's where dalkore or whoever is |
| 23:15:42 | tacotime_: | He pays 0.02$ USD kWh |
| 23:15:48 | phantomcircuit: | except it's only available in like 500kW chunks at random closed factory locations |
| 23:16:03 | phantomcircuit: | so you then have to add in the price of operating a bunch of smaller facilities |
| 23:16:33 | phantomcircuit: | at the end of the day risk adjusted and adjusted for operational overhead i dont think anybody is going to find anything cheaper than $0.05/kWh |
| 23:16:38 | Emcy: | unmetered industrial power? |
| 23:16:49 | Emcy: | dont mind me just smelting ore |
| 23:16:49 | phantomcircuit: | which just so happens to be exactly what it costs if you generate the electricity from natural gas |
| 23:17:04 | tacotime_: | How much is a wind turbine? |
| 23:17:12 | phantomcircuit: | Emcy, to get that you have to install the power infrastructure yourself |
| 23:17:22 | phantomcircuit: | transformers are expensive yo |
| 23:17:30 | Emcy: | like a substation? |
| 23:17:37 | phantomcircuit: | Emcy, yes like a substation |
| 23:17:43 | Emcy: | lel to that |
| 23:17:45 | phantomcircuit: | upfront capital cost of several million easy |
| 23:18:02 | phantomcircuit: | Emcy, industrial power like that is provided at 750 kv |
| 23:18:11 | phantomcircuit: | that's 750000 volts |
| 23:18:16 | phantomcircuit: | have fun |
| 23:18:30 | Emcy: | i wonder if you could setup in a warehouse unit, and pipe your heat next door for which they pay you |
| 23:18:39 | Emcy: | next to a unit that has people working doing stuff |
| 23:18:54 | phantomcircuit: | Emcy, maybe during the winter |
| 23:19:05 | weex: | if you can get hw to run over the 100C, that would open up big possibilities |
| 23:19:10 | phantomcircuit: | but power lines that can deliver lots of power dont tend to be near office space |
| 23:19:25 | phantomcircuit: | weex, and we have a winner |
| 23:19:27 | Emcy: | not office space |
| 23:19:32 | Emcy: | an industrial estate |
| 23:19:51 | Emcy: | i suppose that counts as offices compared to real industrial sites |
| 23:20:07 | phantomcircuit: | weex, if you can get stuff that runs at very high temps you dont need cooling |
| 23:20:10 | phantomcircuit: | just heat rejection |
| 23:20:15 | phantomcircuit: | which is much much cheaper |
| 23:20:17 | just[dead]: | just[dead] is now known as justanotheruser |
| 23:20:25 | Emcy: | what about heat exchange into a small manmade lake |
| 23:20:40 | Emcy: | ecological catastrophe or what? |
| 23:21:01 | weex: | i'm sure once the asic race slows we'll see more creative ways to maximize efficiency, scrypt coin miners are likely already trying some of those |
| 23:21:13 | phantomcircuit: | Emcy, the cost of cooling is almost entirely about the price of moving the coolant around |
| 23:21:23 | phantomcircuit: | it's largely irrelevant where you dump the heat |
| 23:22:01 | phantomcircuit: | none of this is particularly hard to figure out |
| 23:22:43 | phantomcircuit: | it just requires a bit of time and a fairly basic understanding of thermodynamics |
| 23:24:54 | Emcy: | i can into thermodynamics fine |
| 23:25:10 | Emcy: | 1. its all heat and 2. you cant magic it up from nowhere |
| 23:26:37 | phantomcircuit: | there's a few engineering tricks here about efficiency of blowers vs air pressure |
| 23:26:49 | phantomcircuit: | but those will generally only net you about a 15% improvement |
| 23:28:52 | Emcy: | blower fans are cool |
| 23:29:16 | nanotube: | Luke-Jr: gwern was looking into that recently, and I think he was going to check with jed, migt be good to checl. <- his last report was that he got an email from jed, and he said that it was actually an operating MTG exchange website for a time. |
| 23:30:04 | nanotube: | ;;later tell austinhill according to jed, mtgox did actually operate as an mtg trading site for a time. |
| 23:30:04 | gribble: | The operation succeeded. |
| 23:30:15 | sipa: | oh really? |
| 23:30:53 | phantomcircuit: | sipa, yeah it did |
| 23:30:58 | tacotime_: | Seems kind of reasonable |
| 23:30:59 | tacotime_: | https://web.archive.org/web/20070817170606/http://mtgox.com/gwt/mtgox.php |
| 23:31:06 | phantomcircuit: | im not sure how that really matters though |
| 23:31:26 | sipa: | tacotime_: i saw that yes |
| 23:31:37 | sipa: | but that doesn't look very functional |
| 23:40:44 | nanotube: | phantomcircuit: it doesn't. but it seems people are curious. :) |
| 23:41:34 | phantomcircuit: | nanotube, especially considering that the entire website was rebuilt from scratch when mark took over |
| 23:42:15 | Ksipax: | Offtopic: In case anyone has an account at bitcoibuilder, I advice them to withdraw asap |
| 23:42:45 | nanotube: | Ksipax: details? |
| 23:43:14 | Ksipax: | my wallet was showing a negative balance and I was able to change withdraw address |
| 23:44:03 | midnightmagic: | phantomcircuit: it doesn't at all. |
| 23:44:19 | midnightmagic: | just people trying to verify the lineage of sayings.. |
| 23:45:00 | nanotube: | Ksipax: withdraw addresses are changeable if you have no coins in account. |
| 23:45:12 | nanotube: | the negative balance doesn't look too good though. :P |
| 23:45:29 | nanotube: | Ksipax: email josh and let them know asap, before this evening's withdraw batch |
| 23:49:05 | maaku: | petertodd: any word on the gox duplicate txns? |