00:12:11maaku:comboy: there should be no difference in proving hot or cold storage in implementation
00:12:18maaku:if anything hot storage should be easier...
00:13:34phantomcircuit:maaku, the difference is that hot tends to be deposit -> withdrawal in a loop (ie the same wallet for both)
00:13:52phantomcircuit:so it ends up linking transactions together in weird unexpected ways
00:14:02phantomcircuit:cold storage would typically be cold -> hot
00:14:11phantomcircuit:in which case you know just as much as you did before
00:15:53maaku:phantomcircuit: I was questioning comboy's statement "proving just cold storage is much easier in implementation"
00:17:26phantomcircuit:maaku, oh, hmm well actually it might be given that it tends to be much more static
00:17:37phantomcircuit:a hot wallet is optimally a rapidly moving target
00:23:27comboy: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:32maaku:phantomcircuit comboy: every time you sign something in the hot wallet, you output signature + update to audit structure
00:26:08maaku: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:21maaku:then you can provide continuous per-block proofs of solvency
00:27:56phantomcircuit:maaku, the only reliable way to do that would be to modify bitcoind to do it for you
00:28:13phantomcircuit:and im not a super bit fan of running modified bitcoind instances for things with other peoples money
00:28:53comboy:maaku: wouldn't you need to rebuild the whole hash tree every time?
00:29:25maaku:comboy: no, just the updated branches
00:29:49maaku:updated meaning: spent since the last block
00:29:54maaku:(or new)
00:30:42maaku:phantomcircuit: these people have bitcoin core devs on their payroll (or could, if they were so inclined)
00:31:07comboy: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:58maaku:comboy: that's fine, keep business as usual
00:33:01maaku:every time you move coins, those updates to the hash tree get sent to the auditing service
00:33:14maaku:you then compile proofs for each block based on the transactions which make it in
00:33:32maaku:(each time performing O(log) operations per update)
00:34:33comboy:since the root hash keeps chaning every block I wonder if it would really be more secure than say daily proofs
00:35:15maaku:why not? running it every 10 minutes is certainly more secure than every 24 hours
00:35:22maaku:but the root hash doesn't make a difference
00:36:13maaku:you'd be calculating and givng out zero-knowledge proofs anyway
00:38:38phantomcircuit:maaku, that's harder to do than it seems
00:38:46phantomcircuit:they're largely not simply money motivated people :P
00:38:51comboy: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:57phantomcircuit:for example go and try to hire gmaxwell
00:39:07phantomcircuit:good luck with that unless you're doing something supppper cool
00:39:41comboy:but probably with history of them ... well it surely is not a trivial implementation to do it right
00:39:43maaku:i would happily code this for them if they were willing to pay to make it happen
00:39:49maaku:they're not, seemingly
00:40:36phantomcircuit: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:46phantomcircuit:i mean out of the business of having other peoples bitcoins
00:43:30phantomcircuit: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:35phantomcircuit:it's mind boggling
00:47:44copumpkin: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:16phantomcircuit:copumpkin, oh sometimes they get even better
00:48:36phantomcircuit:copumpkin, there's at least one account in which there is someone claiming it's them
00:48:47maaku:phantomcircuit: hahaha being in the business of holding people's coins is a very, very bad idea
00:48:48phantomcircuit:except they quite literally cannot show that it's theirs
00:48:59phantomcircuit:as in it's literally impossible unless they remember their password
00:49:24phantomcircuit:since the account was registered with a tormail address and those are all gone
00:49:47phantomcircuit:maaku, i had to learn that the hard way
00:49:50phantomcircuit:damn is it annoying
00:50:03maaku: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:07maaku:well, except my own :)
00:50:43phantomcircuit: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:02phantomcircuit:ie the exchange needs to hold at least enough to be able to cover all of your outstanding asks
00:51:26phantomcircuit:the only way around that is a request for quote scheme
00:51:38phantomcircuit:but then you need to do a credit check on nearly every market participant
00:51:50phantomcircuit:and/or be prepared for peoples trades to regularly not clear
00:52:29phantomcircuit: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:47phantomcircuit:but there's all sorts of race condition issues and other nastyness there
00:53:01maaku:phantomcircuit: do a peer-to-peer exchange, on a side-chain
00:53:27phantomcircuit:maaku, it's too slow by orders of magnitude
00:53:55maaku:it's infinitely scalable, with federated private servers
00:53:57phantomcircuit:maaku, maybe i should say what i think is reasonable speed for an exchange first
00:54:00maaku:up to bandwidth limits at least
00:54:23phantomcircuit:a single symbol running on a clob should be able to do at least 1k orders/second
00:54:25maaku:and trustless if you're using 2-way pegging with premissionless withdraws
00:54:35maaku:phantomcircuit: I'm looking 1 million tps
00:54:41maaku:*looking at
00:54:47phantomcircuit:maaku, my first red flag is tps
00:54:55phantomcircuit:that number is almost universally meaningless :P
00:55:11phantomcircuit:well actually maybe not
00:55:20phantomcircuit:in this case we're largely talking about clearing trades
00:55:24phantomcircuit:in which case tps is correct
00:55:27phantomcircuit:maaku, carry on
00:55:49phantomcircuit:maaku, im not clear how that would help you if you were dealing in btc/usd or similar though
00:56:07phantomcircuit:i guess you the exchange would issue like
00:56:13phantomcircuit:usdcoins or something
00:56:14maaku:phantomcircuit: you would need "usdcoin" and gateway. there are various options for that
00:56:35maaku:easier than you think ... the real difficulty is keeping the AML controls from corrupting bitcoin, but that's another story
00:56:58phantomcircuit:hmm you'd basically end up with a bunch of small orderbooks that you could jump between
00:57:11phantomcircuit:each one would be fairly slow but combined they would be fast
00:57:49phantomcircuit:maaku, that's fairly simple, the exchange doesn't control the btc and thus isn't transferring money
00:58:02phantomcircuit:(acceptance is a core principle in the definition of a money transmitter)
00:58:04maaku:a merged mined side chain could easily scale to hundreds of transactions per second when rate limited to a 1Mbps connection
00:58:13maaku:(to make sure that anyone can be an auditor on a home connection)
00:58:44maaku: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:57phantomcircuit:maaku, congratulations, that is the first and only time someone has addressed my issues with such a system
00:59:15phantomcircuit:(possibly previous attempts i simply didn't understand :P)
01:00:19maaku: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:42maaku:and again you need the bandwidth limiter to be such that you can get the info to auditors in real time
01:01:06maaku:a 10Gbps data center -> data center link gets you >1Mtps
01:01:34maaku: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:35phantomcircuit:maaku, and you can certainly get > 10gbps for something like this
01:01:41maaku:using the 2-way peg mechanism
01:01:47jtimon:validators can be sharded...but I should catch up reading the past
01:02:08phantomcircuit:maaku, sounds like you're basically building ripple except not built on top of lies
01:02:16maaku:phantomcircuit: yeah pretty much
01:02:29maaku:jtimon was heavily involved in pre-OpenCoin ripple
01:02:32maaku:this is a continuation of that
01:03:01phantomcircuit:jtimon, ripple was neat before it was purchased by criminals
01:03:03phantomcircuit:oh well
01:06:29maaku: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:12maaku: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:16jtimon:phantomcircuit I wouldn't say criminals, but Ryan Fugger's concept was beatiful and ripple.com designers din't get it
01:11:13jtimon:also ryan (and me for some time) was fooled to believe that ripple consesus could bootstrap a p2p network
01:11:28phantomcircuit: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:35phantomcircuit:that is to say i believe they engaged in fraud
01:12:23phantomcircuit:of course i cant see google ventures admitting they were duped and suing about it
01:13:01jtimon:phantomcircuit I think they still believe it themselves, "...when there's many nodes with well administered UNLs..."
01:13:42phantomcircuit:jtimon, the entire copy for ripple.com was changed a few days after they closed with google ventures
01:13:42jtimon:anyway, their version doesn't scale for several reasons
01:13:53phantomcircuit:the majority of the obviously false statements were scrubbed
01:14:17jtimon:do you have a link summarizing the news?
01:16:28phantomcircuit:jtimon, the news?
01:16:36jtimon:anyway, what invalidates ripple.com as being p2p is the non-pow consensus, but what bothers me more are other design decisions
01:17:30jtimon:never mind about the news, they didn't even read 2PC ripple, I'm almost sure
01:18:15jtimon:or if they did, they didn't understood many of the design decisions
01:19:02phantomcircuit:jtimon, https://web.archive.org/web/20130816114007/https://ripple.com/how-ripple-works/
01:19:12sipa:oh it's perfectly p2p, in my opinion - but not trustless
01:19:16phantomcircuit:i believe nearly every point on that page is false
01:19:19phantomcircuit:which is impressive
01:23:44jtimon:sipa good point, maybe I should replace "p2p currency" for "trustless currency" in my terminology (in which 'cryptocurrency' includes xrp and ecash)
01:24:26sipa:well, bitcoin isn't exactly zero trust either
01:24:34sipa:but it's certainly much closer
01:24:48sipa:and the assumptions are well known
01:31:02gmaxwell: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:24gmaxwell:at least not the normal defintion of p2p which I think also implies an open membership; but perhaps not.
01:31:35gmaxwell:though if it doesn't then I suspect VISA is p2p. :P
01:34:40jtimon:yeah, probably p2p implies distributed, trustless and open membership
01:37:43gmaxwell: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:29phantomcircuit:sipa, it's interesting how few people understand the censorship issues
01:39:24jtimon:not just open
02:11:13just[dead]:just[dead] is now known as justanotheruser
02:29:36mike4:mike4 is now known as VATOS_LOCOS
02:47:23adam3us: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:43adam3us:gmaxwell: with no key setup phase as you would need with actual multi-party sig or ring-sig
03:21:44justanotheruser:justanotheruser is now known as just[dead]
04:19:09just[dead]:just[dead] is now known as justanotheruser
06:36:57ghtdak:ghtdak has left #bitcoin-wizards
08:22:30RBRubicon:RBRubicon has left #bitcoin-wizards
11:08:09nsh:"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:14nsh:-- http://journals.aps.org/prl/abstract/10.1103/PhysRevLett.111.250403
11:25:11sipa:sounds legit
11:38:35nsh_:nsh_ is now known as nsh
11:40:15justanotheruser:justanotheruser is now known as just[dead]
11:45:46MoALTz:non-paywalled: http://arxiv.org/abs/1212.2270
13:54:59nsh_:nsh_ is now known as nsh
15:19:16crucif0rm:crucif0rm has left #bitcoin-wizards
15:37:52_ingsoc_:_ingsoc_ has left #bitcoin-wizards
16:32:27kanzure:phantomcircuit: what censorship issue in particular?
17:01:32just[dead]:just[dead] is now known as justanotheruser
17:36:42mike4:mike4 is now known as c--O-O
17:48:35rastapopuloto:rastapopuloto has left #bitcoin-wizards
18:24:07phantomcircuit:kanzure, one of the core assumptions in bitcoin is that censorship is hard
18:31:48thedarkconcept:thedarkconcept has left #bitcoin-wizards
18:45:43rdponticelli:rdponticelli has left #bitcoin-wizards
20:24:05roidster:roidster is now known as Guest26425
21:25:28Baz:Baz is now known as Guest86646
21:27:37Guest86646:Guest86646 is now known as Baz_1
21:59:10thufir:thufir has left #bitcoin-wizards
23:06:27rdymac-:rdymac- is now known as rdymac
23:33:09amiller:yall see this? it's so cool
23:33:31amiller:weird old deleted bitcoin commits from satoshi that had a reviews/ratings and markets for list
23:33:41amiller:in-bitcoin bitmit/silkroad stuff kinda.
23:35:46roidster:roidster is now known as Guest55677
23:38:06Luke-Jr:amiller: interesting
23:38:26gmaxwell:amiller: you didn't know about that?
23:39:04Luke-Jr:if I did, I forgot
23:39:23amiller:no i didn't
23:39:25amiller:never saw that before
23:40:14sipa:i never saw that code, to be honest
23:40:24sipa:only the remainder of the pubsub system that remained in for longer
23:41:10gmaxwell:oh, I thought that was links to the pubsub stuff (guess thats what I get for not following them)
23:42:50sipa:no, i never knew of the MSG_REVIEW and MSG_PRODUCT :)
23:43:13sipa:seems we reused the code for MSG_REVIEW for partial blocks :p
23:44:09sipa:the only question is whether that was before or after 0.2.9
23:44:11Luke-Jr:someone should write a BIP for this and name Satoshi as the author :D
23:44:56sipa:market stuff was removed in feb 2010
23:45:02sipa:0.2.9 was may 2010
23:45:10sipa:so no worries!
23:45:21Luke-Jr:people would freak out "Satoshi is back!"
23:45:33sipa:you have 1 week
23:46:22sipa:(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:46Luke-Jr:1 week⁈
23:46:50amiller:the best scifi often occurs "long long ago"
23:47:16tacotime:Maybe Satoshi is DPR. :P
23:48:30tacotime:But probably Satoshi just thought that it was a bad idea to integrate a marketplace at introduction.