00:01:49 tromp has joined #bitcoin-wizards 00:11:35 fanquake has joined #bitcoin-wizards 00:12:03 tromp has quit 00:14:15 tromp has joined #bitcoin-wizards 00:14:41 wallet42 has joined #bitcoin-wizards 00:35:46 wallet421 has joined #bitcoin-wizards 00:35:46 wallet42 has quit 00:35:46 wallet421 is now known as wallet42 00:37:37 tromp has quit 00:38:13 tromp has joined #bitcoin-wizards 00:39:11 shinybro has joined #bitcoin-wizards 00:39:34 tromp__ has joined #bitcoin-wizards 00:39:34 tromp has quit 00:40:49 austinhill has joined #bitcoin-wizards 00:57:14 cpacia has joined #bitcoin-wizards 00:58:17 shinybro is now known as satoshi_nakamofo 01:01:59 satoshi_nakamofo is now known as c0kea 01:03:30 c0kea is now known as jokea 01:05:15 ielo has quit 01:08:29 jokea is now known as hasanone 01:12:08 emsid is now known as hasssan 01:12:18 hasssan is now known as hassan9 01:16:56 dgovomo has quit 01:19:22 hassan9 is now known as emsid 01:28:31 tannenbaum has joined #bitcoin-wizards 01:30:39 tannenbaum has quit 01:32:40 leader has joined #bitcoin-wizards 01:37:10 nsh has quit 01:40:58 austinhill has quit 01:41:28 tromp__ has quit 01:42:00 tromp has joined #bitcoin-wizards 01:46:22 tromp has quit 01:57:54 hasanone is now known as satoshi_nakamofo 02:07:18 cpacia has quit 02:15:10 cpacia has joined #bitcoin-wizards 02:22:46 teward has joined #bitcoin-wizards 02:23:14 nezZario has joined #bitcoin-wizards 02:23:20 really... 02:28:04 tromp has joined #bitcoin-wizards 02:28:20 Sangheil- has quit 02:28:54 ghtdak has joined #bitcoin-wizards 02:33:03 austinhill has joined #bitcoin-wizards 02:39:27 wallet42 has quit 02:46:36 wallet42 has joined #bitcoin-wizards 02:50:14 austinhill has quit 02:59:41 Dizzle has joined #bitcoin-wizards 03:03:27 Dizzle has quit 03:03:33 tromp has quit 03:05:41 tromp has joined #bitcoin-wizards 03:20:42 austinhill has joined #bitcoin-wizards 03:25:27 austinhill has quit 03:36:26 rdymac has quit 03:38:00 Sangheili has joined #bitcoin-wizards 03:42:26 rdymac has joined #bitcoin-wizards 03:57:40 austinhill has joined #bitcoin-wizards 03:59:24 austinhill1 has joined #bitcoin-wizards 03:59:24 austinhill has quit 04:03:38 austinhill1 has quit 04:06:36 cpacia has quit 04:06:48 tromp has quit 04:07:20 tromp has joined #bitcoin-wizards 04:11:51 tromp has quit 04:34:29 sl01 has quit 04:34:59 tromp has joined #bitcoin-wizards 04:43:08 adam3us has joined #bitcoin-wizards 04:43:38 adam3us: hi from Las Vegas.. 04:50:02 <[7]> [7] has quit 04:50:39 TheSeven has joined #bitcoin-wizards 04:58:54 Luke-Jr, las vegas? 04:59:42 jtimon has joined #bitcoin-wizards 05:00:14 austinhill has joined #bitcoin-wizards 05:05:01 austinhill has quit 05:07:29 phantomcircuit: departing for SF now 05:07:44 Luke-Jr, sf? 05:08:24 san francisco 05:08:27 zooko has joined #bitcoin-wizards 05:08:45 bbl when i land… 05:14:36 Luke-Jr, lol yeah but why 05:22:20 wallet42 has quit 05:22:28 wallet42 has joined #bitcoin-wizards 05:22:28 wallet42 has quit 05:22:28 wallet42 has joined #bitcoin-wizards 05:22:51 HM has quit 05:23:03 spin123456 has quit 05:23:07 nOgAnOo has quit 05:23:17 spinza has joined #bitcoin-wizards 05:24:36 mr_burdell has quit 05:24:36 c0rw1n has quit 05:24:51 super3 has quit 05:25:25 mr_burdell has joined #bitcoin-wizards 05:25:30 shinybro has joined #bitcoin-wizards 05:25:48 HM_ has joined #bitcoin-wizards 05:25:50 sl01 has joined #bitcoin-wizards 05:26:12 c0rw1n has joined #bitcoin-wizards 05:28:45 wallet42 has quit 05:44:47 tromp has quit 05:45:21 tromp has joined #bitcoin-wizards 05:49:29 tromp has quit 05:58:15 gmaxwell has joined #bitcoin-wizards 05:58:26 I am just absolutely beside myself here: http://www.reddit.com/r/Bitcoin/comments/1zx61b/to_the_people_criticising_the_bitcoin_foundation/cfxuhkr 06:00:55 austinhill has joined #bitcoin-wizards 06:02:01 gmaxwell: haters gonna hate 06:03:21 gmaxwell, that is lol 06:05:08 i wish i didn't read that 06:05:25 austinhill has quit 06:06:24 adam3us has quit 06:06:29 sipa: i gave up after the 2nd reply 06:06:34 gmaxwell has the patience of a saint 06:15:46 Aesthetic has quit 06:22:00 Logicwax has joined #bitcoin-wizards 06:23:20 leader has quit 06:24:39 sigh, i wish there wasn't so much fighting amongst btcd versus bitcoind devs 06:25:31 i'm with conformal by development but i'm hoping everyone can just get along sooner than later 06:26:45 tt_away: there isn't any fighting that I know of 06:27:06 i have some SNARK related questions outside of my limit of knowledge, but I'm hoping to level up 06:27:17 wyager has joined #bitcoin-wizards 06:27:30 pinocchio can handle arbitrary boolean circuits, OR arbitrary arithmetic circuits 06:27:53 is there a reason you cant have both operations in a hybrid circuit? 06:28:02 rdymac has quit 06:28:42 rdymac has joined #bitcoin-wizards 06:28:44 maaku: the btcd devs are just concerned they aren't getting recognized for their contributions to things that are ending up in the bitcoind master 06:28:51 also, this paper also adds set operations to the mix: http://fc14.ifca.ai/papers/fc14_submission_126.pdf 06:29:09 tt_away: are the Btcd devs complaining? 06:29:14 does anyone know some possible use cases? that might help me understand better 06:29:46 wyager: I don't think "complaining" is the right word, they want to interact more directly with the bitcoind devs 06:30:08 I haven't seen anything on the mailing list about that 06:30:32 wyager: I told davec (lead dev on btcd) to post to the mailing list and try to sort things out 06:30:34 tt_away: as far as I can tell this is just some random dude who (wrongly) thinks that 0.9 features were implemented in btcd first 06:30:36 I've heard complaints from random people, but none of the devs 06:31:30 maaku: it's someone from our irc server yeah, i don't think he's a dev tho 06:32:01 i would personally have no problem making changes in the reference client that are inspired by, suggested by or copied from other implementations... in either direction 06:32:13 but there has been a little concern that there hasn't been attributions to btcd for some features 06:32:30 we're one community and it's in everyone's best interest to push the technology safely forward 06:32:39 tt_away: because there hasn't been any contributions from btcd 06:32:44 sipa: I agree, I think any reasonable person realizes that it's not a contest! 06:32:45 if there were, we would attribute them 06:33:06 but indeed, i have seen zero interaction with btcd whatsoever 06:34:05 maybe some people have sent pull requests for features that exidted in btcd first, but without my knkwledge for sure 06:34:08 i haven't looked at the commit logs so i can't say one way or the other, i hear different things from both sides. 06:36:05 tt_away: if you could find btcd developers saying that, it would be helpful 06:36:16 maybe we could then identify an actual technology transfer 06:36:31 adam3us has joined #bitcoin-wizards 06:36:34 but as far as I can tell this is just random ignorant people on the internet not connected to either project 06:38:55 maaku: I've heard some... well versed people... talking about this exact thing (attribution in general, and btcd in particular). There was some talk of this at the recent conference 06:39:38 tt_away, i would be uhm... very surprised if btcd implemented anything before it was even an idea in bitcoind 06:40:03 well, for certain there are hundreds of ideas that aren't implemented 06:40:28 and for some things it's just obvious that this will halpen one way or another 06:40:54 sorry sipa, I should have told you not to load it. 06:41:14 bitcoin core will at some point have deterministic wallets 06:41:19 well I'm a moron. in any case, I went systematically through the most recent btcd changlog update and pointed out that every change in common originated in bitcoin core. 06:41:44 http://www.reddit.com/r/Bitcoin/comments/1zx61b/to_the_people_criticising_the_bitcoin_foundation/cfxuhkr so there is now a smoking creater where IanCormac once stood. 06:41:47 :P 06:42:09 i'm sure that people will claim that bitcoin copies other wallet client features at that point, and i guess that's fine 06:42:28 there's no reason not to adoot best practices after they've been established 06:42:29 Interent arguments ftw 06:43:24 super3 has joined #bitcoin-wizards 06:43:31 sipa: yea, they've already claimed that about bip32 "copying" electrum wallets, though the electrum functionality was via me in any case. 06:47:34 ghtdak has quit 06:48:58 adam3us has quit 06:49:45 wyager has quit 06:53:56 adam3us has joined #bitcoin-wizards 06:56:55 justusranvier has joined #bitcoin-wizards 06:59:34 maaku: the motivation for using CRS model in that paper makes me sad. 07:01:13 adam3us has quit 07:01:31 zooko: can you explain? 07:01:44 austinhill has joined #bitcoin-wizards 07:01:44 maybe I just missed it 07:02:38 oh awesome there is now apparently (?!) a btcd person supporting those outragious claims! 07:05:58 austinhill has quit 07:06:12 who, "behindtext"? 07:07:26 rdymac has quit 07:07:34 I don't understand this "blind spot" after you went through the list for him 07:09:10 gmaxwell, http://www.aarongreenspan.com/writing/essay.html?id=98 07:09:26 that about covers it 07:09:33 a gem in there 07:09:36 "According to the transcript, hours before filing for bankruptcy, Vessenes transferred $12 million worth of Bitcoin out of CLI Holdings accounts to CoinLab." 07:10:44 pigeons: I know I'm supposted to just assume people are stupid and not malicious, but I am really straining my imagination now. 07:11:31 it is puzzling 07:12:49 gmaxwell, unfortunately it has been my experience that often both are true 07:14:42 rdymac has joined #bitcoin-wizards 07:15:00 pigeons: back when ltc was created I saw a bunch of people applaud it for having a vastly superior GUI to bitcoin. ... of course, the GUI was the same, the people had just never used the latest version of Bitcoin. 07:15:18 ... so that kind of thing I can understand, except the folks here claim to be following the development. 07:18:25 gmaxwell: 30 nov 2020? :) 07:18:29 gmaxwell, is there a tool that can take a list of account#/balance pairs and turn it into an unbalances merkle tree? 07:18:38 i haven't been entirely following what is going on in that area 07:19:29 gmaxwell: i'm sure we had grttransaction before that 07:19:54 /msg sipa oh crap, accidentally leaked a date out of the original "satoshi" repository. lemme know in private it you catch me with a 2020 date again! 07:20:04 :P 07:20:40 phantomcircuit: go to iwilcox's page. There are implementations. 07:21:09 gmaxwell: needs delorean treatment 07:26:43 adam3us has joined #bitcoin-wizards 07:45:47 phantomcircuit: you mean a trie structure? 07:46:07 phantomcircuit: there is this : https://github.com/monetizeio/python-bitcoin/blob/master/bitcoin/authtree.py 07:47:19 maaku, no i mean a merkle tree to prove liabilities 07:47:35 but one in which you cannot use the length of the fragment you receive to guess how many other entities there are 07:47:45 ie one full of 0 balance fake accounts 07:48:27 ok, then no 07:48:46 phantomcircuit: https://iwilcox.me.uk/2014/proving-bitcoin-reserves < links from there 07:49:13 phantomcircuit: is the number of zero entities relevant? 07:49:26 gah, it's late, the total number of entities? 07:49:44 i would think it's okay for that to be public information 07:49:50 maaku, yes? it tells the entire world how many accounts you have unless you actively work to prevent that 07:50:17 maaku, for a privately held company even disclosing the total liabilities is an extremely strange thing to do 07:50:28 but of course this isn't the normal course of business 07:50:45 gmaxwell, thanks i was having a hard time finding that, it seems to not be linked to extrensively 07:50:50 phantomcircuit: meh, we're talking summation of client funds not total liabilities 07:51:21 maaku, for any reasonably well operated shared wallet those will be within 1% of each other 07:53:52 For a shared wallet, but a shared wallet isn't an ordinary business. 07:54:13 The distinction is that you're not being asked to show your own funds, you're being asked to show funds that belong to other people which are in your possession. 07:54:36 and I think thats way more reasonable than being asked to show your own funds... though if you have investors that may be interesting too. 07:55:17 I dunno, seems that a number of big names have been taking a quick way out by waving their hands at not wanting to reveal their size/assets and instead saying that some reconized personality will audit them. 07:55:38 execut3 has joined #bitcoin-wizards 07:55:39 ugh 07:55:56 (including one place that had told me they were working on it— alas) 07:56:01 i want zkp and notarized bank statements please, or i don't do business with you 07:56:10 someone should start a shame campaign 07:56:38 shesek has quit 07:56:39 I'm not able to discernt if the how much this is motivated a lack of understanding of the difference between trust and verify and just not understanding the importance ... vs actually caring about the privacy ... vs just wanting to avoid implementing anything... 07:56:57 or other factors; maybe they think doing the proof suggests people should be concerned? maybe they intend on being fractional? 07:57:14 is the current state of zerocash (288 byte proofs, 128-bits of security) efficient and secure enough for bitcoin's use case? 07:57:25 If it's just the privacy, running the verifyier for my protocol in a CRS ZK-SNARK should solve it neatly. It's 'just' an engineering matter. 07:57:41 ebfull: no, but for different reasons than you mention 07:58:17 like what? i'm curious 07:58:20 ebfull: CRS assumption. If someone keeps the trusted initilization state (or somehow cracks it) then they get undetectable and unbounded inflation powers because they can trivially create false proofs. 07:59:14 or if the crypto itself is weak (keep in mind that it is very new) 07:59:31 otherwise, ... just the big engineering gaps. (the bitcoin specific parts are not actually implemented yet) .. and the crypto is not just new but has novel assumptions. 07:59:51 i remember reading about that with the original proposal (zerocoin?) i guess there's no known solution for that yet 08:00:13 thanks gmaxwell for the link, i had seen your descriptions but this iwilcox article is much more detailed 08:00:25 good for showing other people 08:00:29 ebfull: well zercash is an entirely unrelated cryptosystem... the trusted part can actually be fixed in the zerocoin thing by adding RSA UFOs, though at an enormous efficiency loss. 08:01:17 ebfull: there's a distinction. in zerocoin the CRS allows the creator of the system to steal coins from people who put money in. 08:01:18 the trust is actually a lot worse in zerocash too.. because in zerocoin you could only steal coins "in the bag", vs in zero cash you get the unbounded inflation. 08:01:29 jinx 08:01:35 heh 08:02:37 austinhill has joined #bitcoin-wizards 08:02:59 ebfull: IGNORING that ... it's really attractive though... (well also ignoring some other issues, that to sign a transaction you need basically 30 seconds per input+output, and on the order of a gigabyte of 'prover key' material) 08:03:18 I do think cryptocurrency will get full fungibility some day. 08:03:26 The current situation is not acceptable or stable. 08:04:29 And the theoreticians believe that the problem of trusted initilization is solvable, but the solutions are still so much theory that I can't even tell you what exactly their performance will look like. 08:05:29 If it's just the privacy, running the verifyier for my protocol in a CRS ZK-SNARK should solve it neatly. It's 'just' an engineering matter. 08:05:31 que? 08:06:38 phantomcircuit: do not question moon math or its followers 08:06:45 sipa, heh 08:06:57 austinhill has quit 08:07:01 gmaxwell, i cant speak for anybody else, but my primary reservation is privacy 08:08:35 phantomcircuit: The problem of proving you own coins in the chain amounting to some encrypted value is pretty much precisely the problem that they need to solve to build zerocash (to spend a coin you prove it exists, without identifying it) 08:08:51 wallet42 has joined #bitcoin-wizards 08:08:58 so basically the show the assets side is almost the same thing as a zerocash spend. 08:09:27 ah 08:09:31 hmm that's interesting 08:09:45 just[dead] is now known as justanotheruser 08:09:54 So, if all the zerocash stuff gets publicized it should only require some moderately complex retasking. 08:10:37 and the CRS security assumptions that we were whining about are probably fine for an audit system. 08:10:40 or, you can do it yourself today with Pinocchio/SICP 08:11:40 maaku: same cryptosystem, actually, but you still need to go make a optimized arithemetic circuit for sha256— which is the work from zerocash I'd want. (and their super optimized version of the prover) 08:12:26 I'm not sure how well the circuit generator in pinocchio would work for sha256, might be interesting to try it. 08:14:18 execut3 has quit 08:14:26 there must be circuit optimizing libraries for verilog et al that could be repurposed 08:14:34 it would at least make work like this easier to do 08:15:15 all this stuff uses arithemetic circuits, not boolean ones, the results are much more efficient... 08:16:41 for the proofs for this basically you make statements of the form "For some unspecified nonce, blinding factor, and a specified tree root: I know a txout which is included in this tree root and X is H(value of txout || nonce), and P is the Pubkey+blinding_factor for the pubkey that can spend the txout". 08:17:39 then you can have a similar proof that adds up the blinded coin values, etc. 08:18:44 I do wonder though if it's actually reasonable that these companies can insist that they ought to have privacy on the amount of funds they are holding for other people. Everywhere else where people hold enormous amounts for others that data gets made public in some manner. 08:18:57 but whatever, not my battle. 08:19:50 midnightmagic: 08:19:50 http://www.aliexpress.com/item/1PCS-400MH-s-FPGA-Bitcoin-Miner-X-1Pcs-Ship-Now/1660670965.html 08:19:54 http://www.aliexpress.com/item/400MH-s-FPGA-Bitcoin-Miner-X-1Pcs-Ship-Now-By-DHL/1660168916.html 08:19:59 super cheap icaruses on aliexpress (maybe a scam?) 08:23:48 fanquake has left #bitcoin-wizards 08:25:10 execut3 has joined #bitcoin-wizards 08:31:59 gmaxwell: why dou you keep saying that? even without crypto-magic you get privacy on the amount of funds when you do blockchain committed merkle sum trees 08:34:15 petertodd: yes, but you need crypto magic to make verified assertions about the full contents of those trees 08:34:32 petertodd: because you still learn the sum. 08:34:49 the account balances are private (enough), but e.g. coinbase doesn't want anyone else to know how much coin they're holding. 08:35:04 It _is_ arguably commercially relevant information. 08:35:17 maaku: no you don't - you create multiple trees each leading to a txout, and any given customer's funds may be covered by one or more trees. obviously fund movements take some time to be proven, but the window can be made small (a few hours) 08:35:18 gmaxwell: is that the reason? 08:35:20 MoALTz has joined #bitcoin-wizards 08:35:36 i thought the issue was that I can stuff whatever I want in that merkle tree if I don't have to reveal its contents 08:35:50 maaku: it's what they've said, if I didn't understand it. 08:36:13 petertodd: perhaps you're thinking of some extra layer I am not. But I'm talking about the assets side here, not the liabilities side. 08:36:18 I was just talking to an exchange about all this - they're perfectly fine with the audits taking a few hours - once a day would be ok - and equally they're perfectly fine with learning the sum of a few dozen wallets. 08:36:21 gmaxwell: oh i don't doubt these companies are giving stupid rationalizations for not implementing this 08:36:36 gmaxwell: so am I, in particular cold storage 08:37:26 gmaxwell: I agree crypto-magic would be nice... but that's scaring people off from just getting it done 08:37:37 petertodd: huh, I dunno wtf you're talking about. 08:37:54 The only mention of 'magic' is one line saying magic is possible in iwilcox's thing, and the discussion here. 08:38:45 gmaxwell: yes, and the *lack* of privacy without said magic is an issue, *if* you don't do my per-txout commitments which ensures that any given customer can't learn much 08:40:06 petertodd: ah, you're suggesting just seperating the proofs so that you show a different set of coins to a different set of customers. it's a lot more work to implement that, since they won't match up exactly. E.g. you have two 100 btc coin and three users with a balance of 75. 08:40:25 (and yes, the notion of including the commitment in the txout is suggested on iwilcox's page) 08:40:31 ielo has joined #bitcoin-wizards 08:41:03 but I think thats fine too. 08:41:13 nsh has joined #bitcoin-wizards 08:43:33 gmaxwell: good, because this discussion *has* been scaring off real world users - s 08:44:12 <_ingsoc> _ingsoc has joined #bitcoin-wizards 08:45:59 whichcussion? 08:47:10 nsh: discussion about privacy issues w/ merkle-sum trees and all the crypto magic needed to eliminate them in the "one tree to rule them all" model 08:47:38 people kept bringing it up at the financial crypto conference (at least the less technical people) 08:47:50 lame 08:48:32 meh, how much business your service is doing is competitively private info 08:49:12 I suppose if you augment your commitments so you can say "x funds from this output goes to this tree, y funds to that tree" you solve the knapsack problem. though you end up having constantly move the transactions to update the proof and you get identified by temporal correlations when you do that. 08:50:19 yes, but that can easily be spread out over the day - doesn't have to happen all at once 08:50:38 equally, reproving that you really have the keys is surprisingly important to people 08:51:02 petertodd: so is that you've stolen all your customer funds or not, in one sense. At least my view is that it doesn't even matter if those concerns are addressed, in the current ecosystem it's not acceptable to take other people's funds and not show that you can back it up. If the procedure you have leaks more data than you'd like, thats your own problem. 08:51:33 I'm happy enough to say, 'meh' this is all solvable. If it bothers you much, invest in solving that then and enjoy whatever competative advantages that gives you. 08:53:48 we've got the community taking andreas's word re: the coinbase audit at facevalue... we'll be lucky if we can get the dumbest possible merkle-sum tree implemented regardless 08:53:53 jtimon has quit 08:55:25 frankly with the exchange I was talking to at the conf, audit logs and pervasive two-factor authentication of actions taken was the priority, along with figuring out how to hold all funds in n-of-m wallets so that the two-factor authentication and logs would actually be useful 09:03:10 austinhill has joined #bitcoin-wizards 09:03:52 petertodd, n-of-m for an exchange in which the user is one of the keys? 09:03:53 hellyeah has joined #bitcoin-wizards 09:03:56 s/is/has/ 09:03:58 spinza has quit 09:04:20 Krellan_ has joined #bitcoin-wizards 09:04:34 Hmm... thinking about it you could do a hybrid system for your merkle-sum-tree: split up txouts on the chian into conveniently sized chunks via standard merkle-sum-trees, and then publish a second authenticated prefix tree mapping those chunks to actual customers. Since the second tree is a sorted prefix tree the customers can verify that the mapping is 1:1 09:05:11 phantomcircuit: no, rather n-of-m so different parts of the exchange software stack can have different parts of the keys. e.g. make the website have one key, and the second-factor SMS verification system have another 09:05:24 petertodd, ah 09:05:29 phantomcircuit: obviously if *customers* had PGP keys and were willing to use them it'd be an easy problem... 09:05:45 petertodd, ultimately though the exchange *must* have control of the bitcoins 09:06:11 it's a necessity if trades are to be guaranteed to clear 09:06:19 phantomcircuit: not quite... suppose the exchange software was two separate software stacks, and you have to convince each separate stack that a given transaction should go through 09:06:38 petertodd, right and that can be useful in a number of ways 09:06:52 phantomcircuit: equally, those separate stacks could be managed by different teams, or for that matter, the exchange and their software vendor 09:07:16 spinza has joined #bitcoin-wizards 09:07:37 petertodd, ultimately there is a database somewhere with a balance and some ledger entries 09:07:39 austinhill has quit 09:08:05 Re: hybrid system, what's good about it is how it makes clear that what we care about is proving that the exchange has the backing fundsand that they're allocated on a 1:1 basis for their customer accounts - if the txouts were all a single satoshi in size there would be no need for the merkel sum tree. (for instance) 09:08:25 hellyeah has left #bitcoin-wizards 09:09:03 phantomcircuit: no, there should be redundent such databases maintained by different codebases, and the codebases should be in consensus! 09:09:03 petertodd, if that is exploited then it doesn't much matter what else you have in plance 09:09:24 petertodd, that's nice in theory, but not in practice 09:09:53 phantomcircuit: e.g. if you have two databases and customer intent authentication systems, that maps nicely to a 2-of->=2 system 09:10:11 phantomcircuit: yes, it obviously increases development effort by >2x 09:10:27 petertodd, explain to me how you would prevent one of the databases from rewriting the (user, bitcoin deposit address) pairs and their corresponding ledger entires 09:10:51 both databases will appear correct 09:10:58 and even if you detect that something is wrong 09:11:04 good luck proving it 09:11:43 phantomcircuit: the databases aren't synching to each other, they're comparing to each other 09:12:01 petertodd, i know, im saying even if you detect a fault 09:12:05 and you halt everything 09:12:27 reconcilling the two is going to be essentially impossible 09:12:32 phantomcircuit: what's updating the databases is customer intent, which in an idea world can always be multi-factor, validated through independent mechanisms 09:13:18 not at all, everything that changed the state of the databases is based on customer intent, which obviously should be logged immutably in an append-only transaction ledger 09:14:13 all you have to do is go through that ledger and match up entries - if all transactions match on both sides - that is both autentication methods validated the action taken - you're good to go 09:14:18 go1111111 has quit 09:14:50 it should *always* be possible to wipe the database and recreate it from the transaction history - the database being there is purely an optimization 09:16:35 nsh has quit 09:35:11 <_ingsoc> _ingsoc has quit 09:36:45 wallet42 has quit 09:37:07 <_ingsoc> _ingsoc has joined #bitcoin-wizards 09:37:37 ielo has quit 09:39:34 <_ingsoc> _ingsoc has quit 09:46:37 petertodd, er no 09:46:57 petertodd, on an exchange the vast majority of actions are from sources external to the customers intent 09:47:09 orders filling 09:47:13 bank wires posting 09:47:28 bitcoin transfers in acquiring enough confirmations 09:47:50 kyune has joined #bitcoin-wizards 09:47:53 indeed the only thing that is based on customer intent alone is requests to transfer out 09:48:00 and that's only true under normal operations 09:50:02 phantomcircuit: all those things either can be subject to the same two-factor-type rules, or are deterministic based on customers intent 09:50:56 ielo has joined #bitcoin-wizards 09:51:42 petertodd, how do you keep the two factor rules for the exchanges central limit orderbook? 09:51:47 phantomcircuit: e.g. bank wires posting should be verified by more than one person 09:52:04 you have 1ms to complete all of the logic in that loop for a very slow implementation 09:52:51 phantomcircuit: the orders in that orderbook can all be two factor verified, and the timestamps on those orders can be fixed between all sides (given we're in a closed system) 09:53:11 phantomcircuit: once you have an agreed sequence of orders being fully verified, the state of the orderbook is deterministic 09:53:32 phantomcircuit: which in turn means the state of the balances at any given point in time 09:54:17 bobke has quit 09:54:27 phantomcircuit: also, with balances you *can* have a "fast path" and a "slow path" as we only need to verify that the set of orders that got matched made sense - at some point you can just spot check that and accept discrepencies within limits 09:54:57 petertodd, personally i consider requiring the wall clock to be synchronized for an exchange engine to work an absolute show stopper 09:55:19 bobke has joined #bitcoin-wizards 09:55:37 I sure don't - I've personally worked on systems with a dozen moving parts all synchronized to the nanosecond 09:57:01 petertodd, i wouldn't consider such a system to be robust 09:57:02 besides, the *context* of the discussion I had with regard to all this stuff was an exchange that frankly could have worked just fine if a 1 order/second limit... if you want to be risky go for it, but there's a market for less fast and more secure exchanges too 09:57:23 (especially given that building a system which doesn't require timestamps to be anywhere close to synchronized is relatively easy) 09:57:26 phantomcircuit: security is weird; robust means don't lose money, not uptime 09:57:53 petertodd, if you rely on timestamps for order execution you will eventually lose money 09:58:00 phantomcircuit: you're claiming building a secure multi-factor system isn't if the timestamps aren't synchronized, so I'm telling you "fine, synchronizing them is easy you know" 09:58:05 remember that orders are filled in a price time priority basis 09:58:33 petertodd, (mostly im just playing devils advocate) 09:58:58 phantomcircuit: yes, then if that's hard, create a simpler system for version #1 that maintains the strong multi-factor security property 09:59:54 heck, I had this discussion yesterday, and all parties agreed we'd be better off with less hot failover redundency in favor of fewer vm's and more physical separation (non-infinite money of course) 10:00:01 petertodd, just implementing an oracle that restricted the rate at which transfers could occur would be a massive improvement for most shared wallets security :P 10:00:30 phantomcircuit: ...and guess what was proposed for version 0.1? 10:00:39 a magical oracle 10:01:38 petertodd, this exchange wouldn't happen to be in .au would it? 10:03:56 austinhill has joined #bitcoin-wizards 10:04:37 phantomcircuit: dunno if I can comment on that 10:08:18 austinhill has quit 10:09:19 ssj4mo has quit 10:15:44 edulix_ is now known as Edulix 10:18:05 uh. Dave @ conformal has responded supporting that bullshit thread on reddit. 10:18:38 ? 10:18:53 these are the people that de raadt was raging at a year or so ago aren't they? 10:19:03 * midnightmagic shakes head. 10:19:22 midnightmagic: yes. 10:21:58 so what's the thread url? 10:22:39 petertodd: http://www.reddit.com/r/Bitcoin/comments/1zx61b/to_the_people_criticising_the_bitcoin_foundation/cfxuhkr 10:24:16 WTF?! 10:24:45 rather slimy of him I agree... 10:24:49 execut3 has quit 10:24:59 these things make me really close to quitting :/ 10:25:32 that's quite an accusation 10:26:31