| 00:12:11 | maaku: | comboy: there should be no difference in proving hot or cold storage in implementation |
| 00:12:18 | maaku: | if anything hot storage should be easier... |
| 00:13:34 | phantomcircuit: | maaku, the difference is that hot tends to be deposit -> withdrawal in a loop (ie the same wallet for both) |
| 00:13:52 | phantomcircuit: | so it ends up linking transactions together in weird unexpected ways |
| 00:14:02 | phantomcircuit: | cold storage would typically be cold -> hot |
| 00:14:11 | phantomcircuit: | in which case you know just as much as you did before |
| 00:15:53 | maaku: | phantomcircuit: I was questioning comboy's statement "proving just cold storage is much easier in implementation" |
| 00:17:26 | phantomcircuit: | maaku, oh, hmm well actually it might be given that it tends to be much more static |
| 00:17:37 | phantomcircuit: | a hot wallet is optimally a rapidly moving target |
| 00:23:27 | comboy: | maaku: one thing is not to stop halt deposit / withdrawals, another is not to include deposit addresses, and one more is that cold storage can be even just one addr instead of hundreds in hot wallet |
| 00:25:32 | maaku: | phantomcircuit comboy: every time you sign something in the hot wallet, you output signature + update to audit structure |
| 00:26:08 | maaku: | and you can combine audit-updates in a proof-updatable structure, for both O(log) performance and the ability to re-order updates based on what actually makes it into the block |
| 00:26:21 | maaku: | then you can provide continuous per-block proofs of solvency |
| 00:27:56 | phantomcircuit: | maaku, the only reliable way to do that would be to modify bitcoind to do it for you |
| 00:28:13 | phantomcircuit: | and im not a super bit fan of running modified bitcoind instances for things with other peoples money |
| 00:28:53 | comboy: | maaku: wouldn't you need to rebuild the whole hash tree every time? |
| 00:29:25 | maaku: | comboy: no, just the updated branches |
| 00:29:49 | maaku: | updated meaning: spent since the last block |
| 00:29:54 | maaku: | (or new) |
| 00:30:42 | maaku: | phantomcircuit: these people have bitcoin core devs on their payroll (or could, if they were so inclined) |
| 00:31:07 | comboy: | ah right, maybe that's not that much.. still this problem of moving coins away from deposit addreses, andyou probably want to move some of them directly out as withdrawals |
| 00:32:58 | maaku: | comboy: that's fine, keep business as usual |
| 00:33:01 | maaku: | every time you move coins, those updates to the hash tree get sent to the auditing service |
| 00:33:14 | maaku: | you then compile proofs for each block based on the transactions which make it in |
| 00:33:32 | maaku: | (each time performing O(log) operations per update) |
| 00:34:33 | comboy: | since the root hash keeps chaning every block I wonder if it would really be more secure than say daily proofs |
| 00:35:15 | maaku: | why not? running it every 10 minutes is certainly more secure than every 24 hours |
| 00:35:22 | maaku: | but the root hash doesn't make a difference |
| 00:36:13 | maaku: | you'd be calculating and givng out zero-knowledge proofs anyway |
| 00:38:38 | phantomcircuit: | maaku, that's harder to do than it seems |
| 00:38:46 | phantomcircuit: | they're largely not simply money motivated people :P |
| 00:38:51 | comboy: | well you the root hash should be in some public place and and your proof part in your user area, so you don't fetch them at once, so exchange could say that oh yeah now block just came in and we didn't finish recomputing hash yet, that's why it didnt match |
| 00:38:57 | phantomcircuit: | for example go and try to hire gmaxwell |
| 00:39:07 | phantomcircuit: | good luck with that unless you're doing something supppper cool |
| 00:39:41 | comboy: | but probably with history of them ... well it surely is not a trivial implementation to do it right |
| 00:39:43 | maaku: | i would happily code this for them if they were willing to pay to make it happen |
| 00:39:49 | maaku: | they're not, seemingly |
| 00:40:36 | phantomcircuit: | maaku, i would pay you to do it but i am very rapidly getting out of the business of people yelling at me |
| 00:40:46 | phantomcircuit: | i mean out of the business of having other peoples bitcoins |
| 00:40:51 | phantomcircuit: | >.> |
| 00:40:52 | phantomcircuit: | <.< |
| 00:43:30 | phantomcircuit: | maaku, personally my *favorite* users are the ones who abandon an account that is almost entirely worthless for >1 year, do not respond to emails, even let their email account they registered with expire, and then demand immediate action upon returning |
| 00:43:35 | phantomcircuit: | it's mind boggling |
| 00:47:44 | copumpkin: | phantomcircuit: err, I left 100k bitcoins with you 4 years ago under an email address I no longer control and can no longer remember. Can I have them back? thanks! |
| 00:48:16 | phantomcircuit: | copumpkin, oh sometimes they get even better |
| 00:48:36 | phantomcircuit: | copumpkin, there's at least one account in which there is someone claiming it's them |
| 00:48:47 | maaku: | phantomcircuit: hahaha being in the business of holding people's coins is a very, very bad idea |
| 00:48:48 | phantomcircuit: | except they quite literally cannot show that it's theirs |
| 00:48:59 | phantomcircuit: | as in it's literally impossible unless they remember their password |
| 00:49:24 | phantomcircuit: | since the account was registered with a tormail address and those are all gone |
| 00:49:47 | phantomcircuit: | maaku, i had to learn that the hard way |
| 00:49:50 | phantomcircuit: | damn is it annoying |
| 00:50:03 | maaku: | there's a reason I'm working on trustless exchanges, vaults, etc. .... I never want to be in the position of holding *anybody*'s coins |
| 00:50:07 | maaku: | well, except my own :) |
| 00:50:43 | phantomcircuit: | maaku, the problem is that im pretty sure it's basically impossible to have a bitcoin exchange that has any significant volume that doesn't hold peoples coins |
| 00:51:02 | phantomcircuit: | ie the exchange needs to hold at least enough to be able to cover all of your outstanding asks |
| 00:51:26 | phantomcircuit: | the only way around that is a request for quote scheme |
| 00:51:38 | phantomcircuit: | but then you need to do a credit check on nearly every market participant |
| 00:51:50 | phantomcircuit: | and/or be prepared for peoples trades to regularly not clear |
| 00:52:29 | phantomcircuit: | the only thing i've seen so far that would even get you close is 1-of-2 in which the exchange spends the coins to the recipient as soon as the trade executes |
| 00:52:47 | phantomcircuit: | but there's all sorts of race condition issues and other nastyness there |
| 00:53:01 | maaku: | phantomcircuit: do a peer-to-peer exchange, on a side-chain |
| 00:53:27 | phantomcircuit: | maaku, it's too slow by orders of magnitude |
| 00:53:40 | maaku: | nope |
| 00:53:55 | maaku: | it's infinitely scalable, with federated private servers |
| 00:53:57 | phantomcircuit: | maaku, maybe i should say what i think is reasonable speed for an exchange first |
| 00:54:00 | maaku: | up to bandwidth limits at least |
| 00:54:23 | phantomcircuit: | a single symbol running on a clob should be able to do at least 1k orders/second |
| 00:54:25 | maaku: | and trustless if you're using 2-way pegging with premissionless withdraws |
| 00:54:35 | maaku: | phantomcircuit: I'm looking 1 million tps |
| 00:54:41 | maaku: | *looking at |
| 00:54:47 | phantomcircuit: | maaku, my first red flag is tps |
| 00:54:55 | phantomcircuit: | that number is almost universally meaningless :P |
| 00:55:11 | phantomcircuit: | well actually maybe not |
| 00:55:20 | phantomcircuit: | in this case we're largely talking about clearing trades |
| 00:55:24 | phantomcircuit: | in which case tps is correct |
| 00:55:27 | phantomcircuit: | maaku, carry on |
| 00:55:49 | phantomcircuit: | maaku, im not clear how that would help you if you were dealing in btc/usd or similar though |
| 00:56:07 | phantomcircuit: | i guess you the exchange would issue like |
| 00:56:13 | phantomcircuit: | usdcoins or something |
| 00:56:14 | maaku: | phantomcircuit: you would need "usdcoin" and gateway. there are various options for that |
| 00:56:35 | maaku: | easier than you think ... the real difficulty is keeping the AML controls from corrupting bitcoin, but that's another story |
| 00:56:58 | phantomcircuit: | hmm you'd basically end up with a bunch of small orderbooks that you could jump between |
| 00:57:11 | phantomcircuit: | each one would be fairly slow but combined they would be fast |
| 00:57:49 | phantomcircuit: | maaku, that's fairly simple, the exchange doesn't control the btc and thus isn't transferring money |
| 00:58:02 | phantomcircuit: | (acceptance is a core principle in the definition of a money transmitter) |
| 00:58:04 | maaku: | a merged mined side chain could easily scale to hundreds of transactions per second when rate limited to a 1Mbps connection |
| 00:58:13 | maaku: | (to make sure that anyone can be an auditor on a home connection) |
| 00:58:44 | maaku: | it's possible to safely extend two-way pegging to "private accounting servers" as well, which is to say a fully centralized timestamper |
| 00:58:57 | phantomcircuit: | maaku, congratulations, that is the first and only time someone has addressed my issues with such a system |
| 00:59:15 | phantomcircuit: | (possibly previous attempts i simply didn't understand :P) |
| 01:00:19 | maaku: | jtimon and I have come up with a serializer architecture which is fully parallel, so you are not limited to validation speed, just quantity of hardware and network connections in scaling a private server |
| 01:00:42 | maaku: | and again you need the bandwidth limiter to be such that you can get the info to auditors in real time |
| 01:01:06 | maaku: | a 10Gbps data center -> data center link gets you >1Mtps |
| 01:01:34 | maaku: | and again, even though centralized funds are safe because you are free to withdraw at any time even without cooperation of the accountant |
| 01:01:35 | phantomcircuit: | maaku, and you can certainly get > 10gbps for something like this |
| 01:01:41 | maaku: | using the 2-way peg mechanism |
| 01:01:47 | jtimon: | validators can be sharded...but I should catch up reading the past |
| 01:02:08 | phantomcircuit: | maaku, sounds like you're basically building ripple except not built on top of lies |
| 01:02:16 | maaku: | phantomcircuit: yeah pretty much |
| 01:02:29 | maaku: | jtimon was heavily involved in pre-OpenCoin ripple |
| 01:02:32 | maaku: | this is a continuation of that |
| 01:03:01 | phantomcircuit: | jtimon, ripple was neat before it was purchased by criminals |
| 01:03:03 | phantomcircuit: | oh well |
| 01:06:29 | maaku: | phantomcircuit: most of the protocol changes for this are worked out in our Freimarkets paper, although it needs a refresh as there are simpler, cleaner ways to accomplish some of it |
| 01:07:12 | maaku: | the two-way pegging stuff still needs to be written up, but adam back posted an update about that to the mailing list about a week ago |
| 01:10:16 | jtimon: | phantomcircuit I wouldn't say criminals, but Ryan Fugger's concept was beatiful and ripple.com designers din't get it |
| 01:11:13 | jtimon: | also ryan (and me for some time) was fooled to believe that ripple consesus could bootstrap a p2p network |
| 01:11:28 | phantomcircuit: | jtimon, i would say they made statements which they knew to be false to illicit others to give them things of value knowing that those statements were false and knowing that the people relying on those statements would consider that to be reasonable |
| 01:11:35 | phantomcircuit: | that is to say i believe they engaged in fraud |
| 01:12:23 | phantomcircuit: | of course i cant see google ventures admitting they were duped and suing about it |
| 01:13:01 | jtimon: | phantomcircuit I think they still believe it themselves, "...when there's many nodes with well administered UNLs..." |
| 01:13:42 | phantomcircuit: | jtimon, the entire copy for ripple.com was changed a few days after they closed with google ventures |
| 01:13:42 | jtimon: | anyway, their version doesn't scale for several reasons |
| 01:13:53 | phantomcircuit: | the majority of the obviously false statements were scrubbed |
| 01:14:17 | jtimon: | do you have a link summarizing the news? |
| 01:16:28 | phantomcircuit: | jtimon, the news? |
| 01:16:36 | jtimon: | anyway, what invalidates ripple.com as being p2p is the non-pow consensus, but what bothers me more are other design decisions |
| 01:17:30 | jtimon: | never mind about the news, they didn't even read 2PC ripple, I'm almost sure |
| 01:18:15 | jtimon: | or if they did, they didn't understood many of the design decisions |
| 01:19:02 | phantomcircuit: | jtimon, https://web.archive.org/web/20130816114007/https://ripple.com/how-ripple-works/ |
| 01:19:12 | sipa: | oh it's perfectly p2p, in my opinion - but not trustless |
| 01:19:16 | phantomcircuit: | i believe nearly every point on that page is false |
| 01:19:19 | phantomcircuit: | which is impressive |
| 01:23:44 | jtimon: | sipa good point, maybe I should replace "p2p currency" for "trustless currency" in my terminology (in which 'cryptocurrency' includes xrp and ecash) |
| 01:24:13 | sipa: | yup |
| 01:24:26 | sipa: | well, bitcoin isn't exactly zero trust either |
| 01:24:34 | sipa: | but it's certainly much closer |
| 01:24:48 | sipa: | and the assumptions are well known |
| 01:31:02 | gmaxwell: | It's not clear that it's p2p either since you need to be in an admitted set to usefully run a node. |
| 01:31:24 | gmaxwell: | at least not the normal defintion of p2p which I think also implies an open membership; but perhaps not. |
| 01:31:35 | gmaxwell: | though if it doesn't then I suspect VISA is p2p. :P |
| 01:34:40 | jtimon: | yeah, probably p2p implies distributed, trustless and open membership |
| 01:37:43 | gmaxwell: | The word I want to keep using is anonymous in the "anyone can come and go, the membership isn't gated or enumerated in advance" sense, but the other uses of the word are confusing. I don't really have a better word for that however. |
| 01:38:29 | phantomcircuit: | sipa, it's interesting how few people understand the censorship issues |
| 01:38:29 | jtimon: | free |
| 01:39:24 | jtimon: | not just open |
| 02:11:13 | just[dead]: | just[dead] is now known as justanotheruser |
| 02:29:36 | mike4: | mike4 is now known as VATOS_LOCOS |
| 02:47:23 | adam3us: | gmaxwell: i was explaining mining to a crypto guy as a dynamic membership/high churn multi-party k-of-n signature. not sure if there is a nice word for that tho. |
| 02:48:43 | adam3us: | gmaxwell: with no key setup phase as you would need with actual multi-party sig or ring-sig |
| 03:21:44 | justanotheruser: | justanotheruser is now known as just[dead] |
| 04:19:09 | just[dead]: | just[dead] is now known as justanotheruser |
| 06:36:57 | ghtdak: | ghtdak has left #bitcoin-wizards |
| 08:22:30 | RBRubicon: | RBRubicon has left #bitcoin-wizards |
| 11:08:09 | nsh: | "We develop the concept of genuine N-partite Einstein-Podolsky-Rosen (EPR) steering. This nonlocality is the natural multipartite extension of the original EPR paradox. Useful properties emerge that are not guaranteed for genuine multipartite entangled states. In particular, there is a close link with the task of one-sided, device-independent quantum secret sharing." |
| 11:08:14 | nsh: | -- http://journals.aps.org/prl/abstract/10.1103/PhysRevLett.111.250403 |
| 11:25:11 | sipa: | sounds legit |
| 11:38:35 | nsh_: | nsh_ is now known as nsh |
| 11:40:15 | justanotheruser: | justanotheruser is now known as just[dead] |
| 11:45:46 | MoALTz: | non-paywalled: http://arxiv.org/abs/1212.2270 |
| 13:54:59 | nsh_: | nsh_ is now known as nsh |
| 15:19:16 | crucif0rm: | crucif0rm has left #bitcoin-wizards |
| 15:37:52 | _ingsoc_: | _ingsoc_ has left #bitcoin-wizards |
| 16:32:27 | kanzure: | phantomcircuit: what censorship issue in particular? |
| 17:01:32 | just[dead]: | just[dead] is now known as justanotheruser |
| 17:36:42 | mike4: | mike4 is now known as c--O-O |
| 17:48:35 | rastapopuloto: | rastapopuloto has left #bitcoin-wizards |
| 18:24:07 | phantomcircuit: | kanzure, one of the core assumptions in bitcoin is that censorship is hard |
| 18:31:48 | thedarkconcept: | thedarkconcept has left #bitcoin-wizards |
| 18:45:43 | rdponticelli: | rdponticelli has left #bitcoin-wizards |
| 20:24:05 | roidster: | roidster is now known as Guest26425 |
| 21:25:28 | Baz: | Baz is now known as Guest86646 |
| 21:27:37 | Guest86646: | Guest86646 is now known as Baz_1 |
| 21:59:10 | thufir: | thufir has left #bitcoin-wizards |
| 23:06:27 | rdymac-: | rdymac- is now known as rdymac |
| 23:33:09 | amiller: | yall see this? it's so cool |
| 23:33:13 | amiller: | https://github.com/bitcoin/bitcoin/commit/5253d1ab77fab1995ede03fb934edd67f1359ba8 |
| 23:33:31 | amiller: | weird old deleted bitcoin commits from satoshi that had a reviews/ratings and markets for list |
| 23:33:41 | amiller: | in-bitcoin bitmit/silkroad stuff kinda. |
| 23:35:46 | roidster: | roidster is now known as Guest55677 |
| 23:38:06 | Luke-Jr: | amiller: interesting |
| 23:38:26 | gmaxwell: | amiller: you didn't know about that? |
| 23:39:04 | Luke-Jr: | if I did, I forgot |
| 23:39:23 | amiller: | no i didn't |
| 23:39:25 | amiller: | never saw that before |
| 23:40:14 | sipa: | i never saw that code, to be honest |
| 23:40:24 | sipa: | only the remainder of the pubsub system that remained in for longer |
| 23:41:10 | gmaxwell: | oh, I thought that was links to the pubsub stuff (guess thats what I get for not following them) |
| 23:42:50 | sipa: | no, i never knew of the MSG_REVIEW and MSG_PRODUCT :) |
| 23:43:13 | sipa: | seems we reused the code for MSG_REVIEW for partial blocks :p |
| 23:43:20 | sipa: | *identitier |
| 23:43:26 | sipa: | **identifier |
| 23:43:43 | Luke-Jr: | "oops" |
| 23:44:09 | sipa: | the only question is whether that was before or after 0.2.9 |
| 23:44:11 | Luke-Jr: | someone should write a BIP for this and name Satoshi as the author :D |
| 23:44:56 | sipa: | market stuff was removed in feb 2010 |
| 23:45:02 | sipa: | 0.2.9 was may 2010 |
| 23:45:10 | sipa: | so no worries! |
| 23:45:21 | Luke-Jr: | people would freak out "Satoshi is back!" |
| 23:45:33 | sipa: | you have 1 week |
| 23:46:22 | sipa: | (i was about to say this discussion is offtopic here, but as it is about bitcoin *long ago* it's not about bitcoin today!) |
| 23:46:46 | Luke-Jr: | 1 week⁈ |
| 23:46:50 | amiller: | the best scifi often occurs "long long ago" |
| 23:47:16 | tacotime: | Maybe Satoshi is DPR. :P |
| 23:48:30 | tacotime: | But probably Satoshi just thought that it was a bad idea to integrate a marketplace at introduction. |