| 00:35:46 | wallet421: | wallet421 is now known as wallet42 |
| 00:58:17 | shinybro: | shinybro is now known as satoshi_nakamofo |
| 01:01:59 | satoshi_nakamofo: | satoshi_nakamofo is now known as c0kea |
| 01:03:30 | c0kea: | c0kea is now known as jokea |
| 01:08:29 | jokea: | jokea is now known as hasanone |
| 01:12:08 | emsid: | emsid is now known as hasssan |
| 01:12:18 | hasssan: | hasssan is now known as hassan9 |
| 01:19:22 | hassan9: | hassan9 is now known as emsid |
| 01:57:54 | hasanone: | hasanone is now known as satoshi_nakamofo |
| 02:23:20 | nezZario: | really... |
| 04:43:38 | Luke-Jr: | adam3us: hi from Las Vegas.. |
| 04:58:54 | phantomcircuit: | Luke-Jr, las vegas? |
| 05:07:29 | Luke-Jr: | phantomcircuit: departing for SF now |
| 05:07:44 | phantomcircuit: | Luke-Jr, sf? |
| 05:08:24 | Luke-Jr: | san francisco |
| 05:08:45 | Luke-Jr: | bbl when i land… |
| 05:14:36 | phantomcircuit: | Luke-Jr, lol yeah but why |
| 05:58:26 | gmaxwell: | I am just absolutely beside myself here: http://www.reddit.com/r/Bitcoin/comments/1zx61b/to_the_people_criticising_the_bitcoin_foundation/cfxuhkr |
| 06:02:01 | maaku: | gmaxwell: haters gonna hate |
| 06:03:21 | phantomcircuit: | gmaxwell, that is lol |
| 06:05:08 | sipa: | i wish i didn't read that |
| 06:06:29 | maaku: | sipa: i gave up after the 2nd reply |
| 06:06:34 | maaku: | gmaxwell has the patience of a saint |
| 06:24:39 | tt_away: | sigh, i wish there wasn't so much fighting amongst btcd versus bitcoind devs |
| 06:25:31 | tt_away: | i'm with conformal by development but i'm hoping everyone can just get along sooner than later |
| 06:26:45 | maaku: | tt_away: there isn't any fighting that I know of |
| 06:27:06 | maaku: | i have some SNARK related questions outside of my limit of knowledge, but I'm hoping to level up |
| 06:27:30 | maaku: | pinocchio can handle arbitrary boolean circuits, OR arbitrary arithmetic circuits |
| 06:27:53 | maaku: | is there a reason you cant have both operations in a hybrid circuit? |
| 06:28:44 | tt_away: | 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 | maaku: | also, this paper also adds set operations to the mix: http://fc14.ifca.ai/papers/fc14_submission_126.pdf |
| 06:29:09 | wyager: | tt_away: are the Btcd devs complaining? |
| 06:29:14 | maaku: | does anyone know some possible use cases? that might help me understand better |
| 06:29:46 | tt_away: | wyager: I don't think "complaining" is the right word, they want to interact more directly with the bitcoind devs |
| 06:30:08 | wyager: | I haven't seen anything on the mailing list about that |
| 06:30:32 | tt_away: | wyager: I told davec (lead dev on btcd) to post to the mailing list and try to sort things out |
| 06:30:34 | maaku: | 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 | wyager: | I've heard complaints from random people, but none of the devs |
| 06:31:30 | tt_away: | maaku: it's someone from our irc server yeah, i don't think he's a dev tho |
| 06:32:01 | sipa: | 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 | tt_away: | but there has been a little concern that there hasn't been attributions to btcd for some features |
| 06:32:30 | sipa: | we're one community and it's in everyone's best interest to push the technology safely forward |
| 06:32:39 | maaku: | tt_away: because there hasn't been any contributions from btcd |
| 06:32:44 | wyager: | sipa: I agree, I think any reasonable person realizes that it's not a contest! |
| 06:32:45 | maaku: | if there were, we would attribute them |
| 06:33:06 | sipa: | but indeed, i have seen zero interaction with btcd whatsoever |
| 06:34:05 | sipa: | maybe some people have sent pull requests for features that exidted in btcd first, but without my knkwledge for sure |
| 06:34:08 | tt_away: | 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 | maaku: | tt_away: if you could find btcd developers saying that, it would be helpful |
| 06:36:16 | maaku: | maybe we could then identify an actual technology transfer |
| 06:36:34 | maaku: | but as far as I can tell this is just random ignorant people on the internet not connected to either project |
| 06:38:55 | wyager: | 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 | phantomcircuit: | tt_away, i would be uhm... very surprised if btcd implemented anything before it was even an idea in bitcoind |
| 06:40:03 | sipa: | well, for certain there are hundreds of ideas that aren't implemented |
| 06:40:28 | sipa: | and for some things it's just obvious that this will halpen one way or another |
| 06:40:54 | gmaxwell: | sorry sipa, I should have told you not to load it. |
| 06:41:14 | sipa: | bitcoin core will at some point have deterministic wallets |
| 06:41:19 | gmaxwell: | 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 | gmaxwell: | 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 | gmaxwell: | :P |
| 06:42:09 | sipa: | 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 | sipa: | there's no reason not to adoot best practices after they've been established |
| 06:42:29 | wyager: | Interent arguments ftw |
| 06:43:31 | gmaxwell: | sipa: yea, they've already claimed that about bip32 "copying" electrum wallets, though the electrum functionality was via me in any case. |
| 06:59:34 | zooko: | maaku: the motivation for using CRS model in that paper makes me sad. |
| 07:01:31 | maaku: | zooko: can you explain? |
| 07:01:44 | maaku: | maybe I just missed it |
| 07:02:38 | gmaxwell: | oh awesome there is now apparently (?!) a btcd person supporting those outragious claims! |
| 07:06:12 | pigeons: | who, "behindtext"? |
| 07:07:34 | pigeons: | I don't understand this "blind spot" after you went through the list for him |
| 07:09:10 | phantomcircuit: | gmaxwell, http://www.aarongreenspan.com/writing/essay.html?id=98 |
| 07:09:26 | phantomcircuit: | that about covers it |
| 07:09:33 | phantomcircuit: | a gem in there |
| 07:09:36 | phantomcircuit: | "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 | gmaxwell: | 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 | pigeons: | it is puzzling |
| 07:12:49 | phantomcircuit: | gmaxwell, unfortunately it has been my experience that often both are true |
| 07:15:00 | gmaxwell: | 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 | gmaxwell: | ... so that kind of thing I can understand, except the folks here claim to be following the development. |
| 07:18:25 | sipa: | gmaxwell: 30 nov 2020? :) |
| 07:18:29 | phantomcircuit: | 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 | phantomcircuit: | i haven't been entirely following what is going on in that area |
| 07:19:29 | sipa: | gmaxwell: i'm sure we had grttransaction before that |
| 07:19:54 | gmaxwell: | /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 | gmaxwell: | :P |
| 07:20:40 | gmaxwell: | phantomcircuit: go to iwilcox's page. There are implementations. |
| 07:21:09 | sipa: | gmaxwell: needs delorean treatment |
| 07:45:47 | maaku: | phantomcircuit: you mean a trie structure? |
| 07:46:07 | maaku: | phantomcircuit: there is this : https://github.com/monetizeio/python-bitcoin/blob/master/bitcoin/authtree.py |
| 07:47:19 | phantomcircuit: | maaku, no i mean a merkle tree to prove liabilities |
| 07:47:35 | phantomcircuit: | 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 | phantomcircuit: | ie one full of 0 balance fake accounts |
| 07:48:27 | maaku: | ok, then no |
| 07:48:46 | gmaxwell: | phantomcircuit: https://iwilcox.me.uk/2014/proving-bitcoin-reserves < links from there |
| 07:49:13 | maaku: | phantomcircuit: is the number of zero entities relevant? |
| 07:49:26 | maaku: | gah, it's late, the total number of entities? |
| 07:49:44 | maaku: | i would think it's okay for that to be public information |
| 07:49:50 | phantomcircuit: | maaku, yes? it tells the entire world how many accounts you have unless you actively work to prevent that |
| 07:50:17 | phantomcircuit: | maaku, for a privately held company even disclosing the total liabilities is an extremely strange thing to do |
| 07:50:28 | phantomcircuit: | but of course this isn't the normal course of business |
| 07:50:45 | phantomcircuit: | gmaxwell, thanks i was having a hard time finding that, it seems to not be linked to extrensively |
| 07:50:50 | maaku: | phantomcircuit: meh, we're talking summation of client funds not total liabilities |
| 07:51:21 | phantomcircuit: | maaku, for any reasonably well operated shared wallet those will be within 1% of each other |
| 07:53:52 | gmaxwell: | For a shared wallet, but a shared wallet isn't an ordinary business. |
| 07:54:13 | gmaxwell: | 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 | gmaxwell: | 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 | gmaxwell: | 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:39 | maaku: | ugh |
| 07:55:56 | gmaxwell: | (including one place that had told me they were working on it— alas) |
| 07:56:01 | maaku: | i want zkp and notarized bank statements please, or i don't do business with you |
| 07:56:10 | maaku: | someone should start a shame campaign |
| 07:56:39 | gmaxwell: | 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 | gmaxwell: | or other factors; maybe they think doing the proof suggests people should be concerned? maybe they intend on being fractional? |
| 07:57:14 | ebfull: | 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 | gmaxwell: | 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 | maaku: | ebfull: no, but for different reasons than you mention |
| 07:58:17 | ebfull: | like what? i'm curious |
| 07:58:20 | gmaxwell: | 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 | maaku: | or if the crypto itself is weak (keep in mind that it is very new) |
| 07:59:31 | gmaxwell: | 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 | ebfull: | i remember reading about that with the original proposal (zerocoin?) i guess there's no known solution for that yet |
| 08:00:13 | maaku: | thanks gmaxwell for the link, i had seen your descriptions but this iwilcox article is much more detailed |
| 08:00:25 | maaku: | good for showing other people |
| 08:00:29 | gmaxwell: | 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 | maaku: | 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 | gmaxwell: | 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 | gmaxwell: | jinx |
| 08:01:35 | maaku: | heh |
| 08:02:59 | gmaxwell: | 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 | gmaxwell: | I do think cryptocurrency will get full fungibility some day. |
| 08:03:26 | gmaxwell: | The current situation is not acceptable or stable. |
| 08:04:29 | gmaxwell: | 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 | phantomcircuit: | 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 | phantomcircuit: | que? |
| 08:06:38 | sipa: | phantomcircuit: do not question moon math or its followers |
| 08:06:45 | phantomcircuit: | sipa, heh |
| 08:07:01 | phantomcircuit: | gmaxwell, i cant speak for anybody else, but my primary reservation is privacy |
| 08:08:35 | gmaxwell: | 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:58 | gmaxwell: | so basically the show the assets side is almost the same thing as a zerocash spend. |
| 08:09:27 | phantomcircuit: | ah |
| 08:09:31 | phantomcircuit: | hmm that's interesting |
| 08:09:45 | just[dead]: | just[dead] is now known as justanotheruser |
| 08:09:54 | gmaxwell: | So, if all the zerocash stuff gets publicized it should only require some moderately complex retasking. |
| 08:10:37 | gmaxwell: | and the CRS security assumptions that we were whining about are probably fine for an audit system. |
| 08:10:40 | maaku: | or, you can do it yourself today with Pinocchio/SICP |
| 08:11:40 | gmaxwell: | 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 | gmaxwell: | I'm not sure how well the circuit generator in pinocchio would work for sha256, might be interesting to try it. |
| 08:14:26 | maaku: | there must be circuit optimizing libraries for verilog et al that could be repurposed |
| 08:14:34 | maaku: | it would at least make work like this easier to do |
| 08:15:15 | gmaxwell: | all this stuff uses arithemetic circuits, not boolean ones, the results are much more efficient... |
| 08:16:41 | gmaxwell: | 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 | gmaxwell: | then you can have a similar proof that adds up the blinded coin values, etc. |
| 08:18:44 | gmaxwell: | 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 | gmaxwell: | but whatever, not my battle. |
| 08:19:50 | gmaxwell: | midnightmagic: |
| 08:19:50 | gmaxwell: | http://www.aliexpress.com/item/1PCS-400MH-s-FPGA-Bitcoin-Miner-X-1Pcs-Ship-Now/1660670965.html |
| 08:19:54 | gmaxwell: | http://www.aliexpress.com/item/400MH-s-FPGA-Bitcoin-Miner-X-1Pcs-Ship-Now-By-DHL/1660168916.html |
| 08:19:59 | gmaxwell: | super cheap icaruses on aliexpress (maybe a scam?) |
| 08:23:48 | fanquake: | fanquake has left #bitcoin-wizards |
| 08:31:59 | petertodd: | 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 | maaku: | petertodd: yes, but you need crypto magic to make verified assertions about the full contents of those trees |
| 08:34:32 | gmaxwell: | petertodd: because you still learn the sum. |
| 08:34:49 | gmaxwell: | 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 | gmaxwell: | It _is_ arguably commercially relevant information. |
| 08:35:17 | petertodd: | 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 | maaku: | gmaxwell: is that the reason? |
| 08:35:36 | maaku: | 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 | gmaxwell: | maaku: it's what they've said, if I didn't understand it. |
| 08:36:13 | gmaxwell: | 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 | petertodd: | 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 | maaku: | gmaxwell: oh i don't doubt these companies are giving stupid rationalizations for not implementing this |
| 08:36:36 | petertodd: | gmaxwell: so am I, in particular cold storage |
| 08:37:26 | petertodd: | gmaxwell: I agree crypto-magic would be nice... but that's scaring people off from just getting it done |
| 08:37:37 | gmaxwell: | petertodd: huh, I dunno wtf you're talking about. |
| 08:37:54 | gmaxwell: | The only mention of 'magic' is one line saying magic is possible in iwilcox's thing, and the discussion here. |
| 08:38:45 | petertodd: | 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 | gmaxwell: | 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 | gmaxwell: | (and yes, the notion of including the commitment in the txout is suggested on iwilcox's page) |
| 08:41:03 | gmaxwell: | but I think thats fine too. |
| 08:43:33 | petertodd: | gmaxwell: good, because this discussion *has* been scaring off real world users - s |
| 08:45:59 | nsh: | whichcussion? |
| 08:47:10 | petertodd: | 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 | petertodd: | people kept bringing it up at the financial crypto conference (at least the less technical people) |
| 08:47:50 | gmaxwell: | lame |
| 08:48:32 | petertodd: | meh, how much business your service is doing is competitively private info |
| 08:49:12 | gmaxwell: | 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 | petertodd: | yes, but that can easily be spread out over the day - doesn't have to happen all at once |
| 08:50:38 | petertodd: | equally, reproving that you really have the keys is surprisingly important to people |
| 08:51:02 | gmaxwell: | 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 | gmaxwell: | 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 | petertodd: | 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:55:25 | petertodd: | 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:52 | phantomcircuit: | petertodd, n-of-m for an exchange in which the user is one of the keys? |
| 09:03:56 | phantomcircuit: | s/is/has/ |
| 09:04:34 | petertodd: | 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 | petertodd: | 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 | phantomcircuit: | petertodd, ah |
| 09:05:29 | petertodd: | phantomcircuit: obviously if *customers* had PGP keys and were willing to use them it'd be an easy problem... |
| 09:05:45 | phantomcircuit: | petertodd, ultimately though the exchange *must* have control of the bitcoins |
| 09:06:11 | phantomcircuit: | it's a necessity if trades are to be guaranteed to clear |
| 09:06:19 | petertodd: | 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 | phantomcircuit: | petertodd, right and that can be useful in a number of ways |
| 09:06:52 | petertodd: | phantomcircuit: equally, those separate stacks could be managed by different teams, or for that matter, the exchange and their software vendor |
| 09:07:37 | phantomcircuit: | petertodd, ultimately there is a database somewhere with a balance and some ledger entries |
| 09:08:05 | petertodd: | 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: | hellyeah has left #bitcoin-wizards |
| 09:09:03 | petertodd: | phantomcircuit: no, there should be redundent such databases maintained by different codebases, and the codebases should be in consensus! |
| 09:09:03 | phantomcircuit: | petertodd, if that is exploited then it doesn't much matter what else you have in plance |
| 09:09:24 | phantomcircuit: | petertodd, that's nice in theory, but not in practice |
| 09:09:53 | petertodd: | 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 | petertodd: | phantomcircuit: yes, it obviously increases development effort by >2x |
| 09:10:27 | phantomcircuit: | 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 | phantomcircuit: | both databases will appear correct |
| 09:10:58 | phantomcircuit: | and even if you detect that something is wrong |
| 09:11:04 | phantomcircuit: | good luck proving it |
| 09:11:43 | petertodd: | phantomcircuit: the databases aren't synching to each other, they're comparing to each other |
| 09:12:01 | phantomcircuit: | petertodd, i know, im saying even if you detect a fault |
| 09:12:05 | phantomcircuit: | and you halt everything |
| 09:12:27 | phantomcircuit: | reconcilling the two is going to be essentially impossible |
| 09:12:32 | petertodd: | 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 | petertodd: | 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 | petertodd: | 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:50 | petertodd: | 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:46:37 | phantomcircuit: | petertodd, er no |
| 09:46:57 | phantomcircuit: | petertodd, on an exchange the vast majority of actions are from sources external to the customers intent |
| 09:47:09 | phantomcircuit: | orders filling |
| 09:47:13 | phantomcircuit: | bank wires posting |
| 09:47:28 | phantomcircuit: | bitcoin transfers in acquiring enough confirmations |
| 09:47:53 | phantomcircuit: | indeed the only thing that is based on customer intent alone is requests to transfer out |
| 09:48:00 | phantomcircuit: | and that's only true under normal operations |
| 09:50:02 | petertodd: | phantomcircuit: all those things either can be subject to the same two-factor-type rules, or are deterministic based on customers intent |
| 09:51:42 | phantomcircuit: | petertodd, how do you keep the two factor rules for the exchanges central limit orderbook? |
| 09:51:47 | petertodd: | phantomcircuit: e.g. bank wires posting should be verified by more than one person |
| 09:52:04 | phantomcircuit: | you have 1ms to complete all of the logic in that loop for a very slow implementation |
| 09:52:51 | petertodd: | 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 | petertodd: | phantomcircuit: once you have an agreed sequence of orders being fully verified, the state of the orderbook is deterministic |
| 09:53:32 | petertodd: | phantomcircuit: which in turn means the state of the balances at any given point in time |
| 09:54:27 | petertodd: | 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 | phantomcircuit: | petertodd, personally i consider requiring the wall clock to be synchronized for an exchange engine to work an absolute show stopper |
| 09:55:37 | petertodd: | I sure don't - I've personally worked on systems with a dozen moving parts all synchronized to the nanosecond |
| 09:57:01 | phantomcircuit: | petertodd, i wouldn't consider such a system to be robust |
| 09:57:02 | petertodd: | 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 | phantomcircuit: | (especially given that building a system which doesn't require timestamps to be anywhere close to synchronized is relatively easy) |
| 09:57:26 | petertodd: | phantomcircuit: security is weird; robust means don't lose money, not uptime |
| 09:57:53 | phantomcircuit: | petertodd, if you rely on timestamps for order execution you will eventually lose money |
| 09:58:00 | petertodd: | 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 | phantomcircuit: | remember that orders are filled in a price time priority basis |
| 09:58:33 | phantomcircuit: | petertodd, (mostly im just playing devils advocate) |
| 09:58:58 | petertodd: | 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 | petertodd: | 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 | phantomcircuit: | 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 | petertodd: | phantomcircuit: ...and guess what was proposed for version 0.1? |
| 10:00:39 | phantomcircuit: | a magical oracle |
| 10:01:38 | phantomcircuit: | petertodd, this exchange wouldn't happen to be in .au would it? |
| 10:04:37 | petertodd: | phantomcircuit: dunno if I can comment on that |
| 10:15:44 | edulix_: | edulix_ is now known as Edulix |
| 10:18:05 | gmaxwell: | uh. Dave @ conformal has responded supporting that bullshit thread on reddit. |
| 10:18:38 | petertodd: | ? |
| 10:18:53 | midnightmagic: | these are the people that de raadt was raging at a year or so ago aren't they? |
| 10:19:03 | midnightmagic: | * midnightmagic shakes head. |
| 10:19:22 | gmaxwell: | midnightmagic: yes. |
| 10:21:58 | petertodd: | so what's the thread url? |
| 10:22:39 | gmaxwell: | petertodd: http://www.reddit.com/r/Bitcoin/comments/1zx61b/to_the_people_criticising_the_bitcoin_foundation/cfxuhkr |
| 10:24:16 | wumpus: | WTF?! |
| 10:24:45 | petertodd: | rather slimy of him I agree... |
| 10:24:59 | wumpus: | these things make me really close to quitting :/ |
| 10:25:32 | wumpus: | that's quite an accusation |
| 10:26:31 | wumpus: | at least I didn't even *look at* btcd |
| 10:27:50 | gmaxwell: | wumpus: yea, perhaps I shouldn't have let you become aware of it. |
| 10:28:11 | gmaxwell: | it's such a stupid thing, we've gotten "what are you guys, idiots?" for the way it used to work a bunch of times. |
| 10:28:25 | gmaxwell: | NTPD, bind, etc. other things have a seperate rpc client its just the obvious thing to do. |
| 10:29:20 | wumpus: | it's the obvioius thing to do, and has been proposed many times, it's just that someone got around to executing it now |
| 10:30:24 | wumpus: | and in any case, ideas diffuse around, that's something else than claiming you 'stole' code changes |
| 10:30:25 | petertodd: | heh, wonder if he's finding it hard to get clients... |
| 10:30:33 | phantomcircuit: | gmaxwell, dont feed the douchbags |
| 10:30:37 | phantomcircuit: | i mean trolls |
| 10:31:33 | gmaxwell: | it's very mysterious |
| 10:31:46 | petertodd: | "One key difference between btcd and bitcoind is that btcd does NOT include wallet functionality and this was a very intentional design decision." <- also, yet another example of the political failure involved with reimplementations vs. just hitting fork and declaring your fork the better fork (preferably after actually making it better) |
| 10:31:50 | gmaxwell: | same company has apparently been cloning openbsd and creating some big drama there. |
| 10:32:11 | petertodd: | wallet software should have been the first thing he worked on, you know, because actual customers would want it |
| 10:32:12 | wumpus: | gmaxwell: interesting |
| 10:32:24 | justanotheruser: | justanotheruser is now known as just[dead] |
| 10:32:35 | gmaxwell: | midnightmagic knows more about it. |
| 10:33:10 | gmaxwell: | petertodd: thats odd because its like ... the smallest possible thing. |
| 10:33:23 | wumpus: | petertodd: yep ... look at what CodeShark is doing, it's much more interesting |
| 10:33:26 | gmaxwell: | I mean it's just boring engineering work to go seperate out the parts, not some start design decision. |
| 10:33:41 | gmaxwell: | It's something we've considered a good thing to do longterm since 2011. |
| 10:33:44 | gmaxwell: | (at least!) |
| 10:33:51 | wumpus: | right |
| 10:33:54 | gmaxwell: | s/start/stark/ |
| 10:33:57 | petertodd: | wumpus: what's he doing exactly? |
| 10:34:07 | gmaxwell: | I suppose when we finally do that we'll get accused of copying that too. :-/ |
| 10:34:25 | phantomcircuit: | gmaxwell, i wonder if that's their goal |
| 10:34:29 | wumpus: | petertodd: a wallet that actually uses hierarchical determinism, n-out-of-n signatures, and such |
| 10:34:41 | phantomcircuit: | to try and guilt us into not copying the few ideas they do come up with |
| 10:34:46 | petertodd: | gmaxwell: heh, I'd be inclined to take the approach of "uh, duh, of course we're copying good design, that's perfectly legal - your code *is* MIT licensed after all" |
| 10:34:57 | petertodd: | wumpus: ah, cool |
| 10:35:14 | gmaxwell: | yea sure, copying it is fine (pedantically if they actually copy code they're required to retain copyright notices) |
| 10:35:40 | phantomcircuit: | which they're not |
| 10:35:42 | petertodd: | gmaxwell: yup, I personally have copied lots of code and code structure from bitcoind -> python-bitcoinlib, and jgarzik before me |
| 10:35:45 | phantomcircuit: | quick grab the pitch forks |
| 10:35:51 | gmaxwell: | which I don't care about and I expect any of our commiters would tell them they don't have to... but some of the contributors may be less happy. |
| 10:36:09 | gmaxwell: | but I hope for their sake that they aren't actually copying too much code. :) |
| 10:36:36 | gmaxwell: | (because thats its own punishment. :) ) |
| 10:36:40 | petertodd: | heh |
| 10:37:48 | petertodd: | granted, jgarzik following the satoshi code rather slavishly re: EvalScript() saved *so* much effort in making it pass the unit tests compared to, say, bitcoin-ruby's very diferent structure and oodles of bugs |
| 10:38:13 | gmaxwell: | lol glib replacement of vectors. |
| 10:38:30 | petertodd: | gmaxwell: ? |
| 10:39:00 | wumpus: | petertodd: had to look it up, his project is 'coinvault' |
| 10:39:39 | petertodd: | wumpus: ah, yeah, I saw that, haven't tried it yet |
| 10:40:25 | gmaxwell: | petertodd: I was looking for a very self contained implementation of script recently and was amused but sad that Jeff's implementation of script basically search and replaced vectors with some glibc datastructure. :) |
| 10:40:30 | petertodd: | wumpus: pity he's not giving all that hard work with no pay away for free :/ |
| 10:40:40 | gmaxwell: | (sad just because it made it non-self-contained) |
| 10:41:08 | petertodd: | gmaxwell: oh, yeah the C library? I dunno, I shudder to think what writing that code in C would be like |
| 10:41:34 | gmaxwell: | just like the C++ code it turns out. So long as you have a vector implementation. :) |
| 10:41:46 | petertodd: | gmaxwell: heh, well.. ifyou take that approach... |
| 10:42:24 | gmaxwell: | there is an effective upper bound on the stack size and the number of objects in it, so an allocation free version should be possible. |
| 10:42:59 | petertodd: | indeed, like we were saying when I was thinking about forth for remote attestation |
| 10:43:50 | wumpus: | petertodd: he doesn't? the project does have a github repo: https://github.com/ciphrex/CoinVault , but no idea if everything is included |
| 10:45:59 | petertodd: | wumpus: it's not opensource though; I can't find any license beyond "all rights reserved" |
| 10:46:19 | wumpus: | -CoinClasses is licensed under the MIT license. |
| 10:46:19 | wumpus: | -CoinQ and CoinDB are licensed under the GPLv2 license. |
| 10:47:00 | petertodd: | wumpus: where is that made clear? |
| 10:47:09 | wumpus: | in the README |
| 10:50:26 | wumpus: | gmaxwell: I can't blame jgarzik, glib is a nice library, it makes programming C a lot more comfortable by providing sane string and vector types and other data structures, better than having to reinvent the wheel every time |
| 10:51:58 | midnightmagic: | short form: conformal poached a bunch of openbsd developers, was unreasonably underhanded about it, and when theo revoked the respective poached devs commit bits they forked openbsd in response. The thread fyi is here more or less: http://marc.info/?l=openbsd-misc&m=133988170001415 |
| 10:52:47 | wumpus: | though, thinking about, for consensus critical things a self-contained implementation that doesn't rely on any libraries (even libc) makes sense |
| 10:53:20 | wumpus: | midnightmagic: just the kind of drama we needed, thanks for warning us |
| 10:54:10 | sipa: | wumpus: one step at a time |
| 10:54:11 | midnightmagic: | wumpus: if I can help at all, in however limited fashion i'm able, i'm glad to. |
| 10:54:26 | sipa: | wumpus: i've thinking about getting rid of the openssl dependency in validation code |
| 10:55:45 | petertodd: | wumpus: ah! now I see - would be better to be more clear, but that''s good |
| 10:55:47 | wumpus: | sipa: getting openssl out of its direct role in validation/consensus would be a great step forward in that regard |
| 10:58:55 | petertodd: | sipa: reminds me: might be interesting to take your ssl lib and integrate it into python-bitcoinlib; is there a github repo for it that you consider canonical? |
| 10:59:10 | sipa: | you mean libsecp256k1? |
| 10:59:22 | petertodd: | sipa: yes |
| 10:59:37 | sipa: | github.com/bitcoin/secp256k1 :) |
| 11:00:41 | sipa: | needs a big disclaimer readme though |
| 11:02:19 | petertodd: | sipa: so are you planning on git-subtree-including that in bitcoin core when the time comes? |
| 11:02:33 | petertodd: | sipa: indeed |
| 11:07:10 | sipa: | yes |
| 11:07:28 | sipa: | with a --enable-experimental compile-time flag |
| 11:15:31 | petertodd: | sipa: cool. also to be sure, the tweak parameters for add and mul can be 32-bytes right? |
| 11:15:41 | sipa: | must be, iirc |
| 11:17:51 | petertodd: | thanks |
| 11:18:00 | petertodd: | bbl, net connection here is full of fail... |
| 11:57:43 | sipa: | * sipa -> US |
| 11:58:35 | gmaxwell: | sipa: fly safely. |
| 12:00:47 | nsh: | +1 |
| 12:01:05 | sipa: | i will do everything in my power to not disturb the pilot |
| 12:11:04 | Emcy: | heh |
| 12:37:11 | jgarzik: | wumpus, gmaxwell: patches welcome :) |
| 12:37:25 | jgarzik: | would love to have a dep-lib-free embeddable lib |
| 12:38:34 | gmaxwell: | FWIW, Forrestv is planning on making it possible for p2pool to run without a bitcoin node. |
| 12:39:35 | gmaxwell: | This ultimately involves making p2pool itself a storageless full node. He's already implemented a lot of this... but it means having things like script validation in p2pool. With all the horrors of alt incompatiblity, plus its mining. |
| 12:39:47 | warren: | gmaxwell: that would put p2pool within the realm of instant docker deployment ... |
| 12:40:11 | gmaxwell: | So making the script enging embeddable is probably necessary to prevent this in resulting in doom of some degree or another. :) |
| 12:40:17 | wumpus: | another reason for a consensus library |
| 12:40:33 | gmaxwell: | yea, thats why I mention it. |
| 12:40:48 | petertodd: | gmaxwell: I saw that; even with script validation I'm currently convinced he'll open up all kinds of fun 51% attacks with <51% - way less |
| 12:41:18 | gmaxwell: | really script in bitcoind itself can be made freestanding without enormous work, and python calling to C++ is not so bad. Though a C engine with no dependencies would be more portable. (and I have other applications where C++ stuff is less good of a fit) |
| 12:41:23 | wumpus: | it does sound pretty reckless |
| 12:42:06 | gmaxwell: | He was previously unaware of some of the issues. E.g. he was operating under the belief that a miner producing bad blocks was only harming the miner. |
| 12:42:17 | gmaxwell: | I've straightened that out. |
| 12:42:43 | gmaxwell: | petertodd: he's also invnted a new kind of authenticated data structure which is self balancing but yet guarentees you can compose proofs. |
| 12:42:51 | petertodd: | gmaxwell: python calling c++ isn't a problem |
| 12:42:57 | gmaxwell: | I know. |
| 12:43:03 | gmaxwell: | But thats just his usecase. |
| 12:43:18 | petertodd: | gmaxwell: good - just use the satoshi code! c calling C++ isn't impossible either after all |
| 12:43:38 | gmaxwell: | (it's not not a problem either, because the C++ abi is not uniform, so if you have multiple C++ compilers on your system you can still get broken) |
| 12:43:42 | petertodd: | gmaxwell: huh, so he's really going for utxo commitments? or is he using that for another thing? |
| 12:43:58 | wumpus: | right it wouldn't be a lot of work to seperate the scripting engine, though it means you need the key stuff as well |
| 12:44:30 | gmaxwell: | wumpus: yea, well, libsecp256k1, detangling bignum stuff... |
| 12:44:31 | petertodd: | gmaxwell: I'd expect ABI to cause way less issues than trying to port the existing code to plain C |
| 12:44:47 | gmaxwell: | petertodd: he has an implementation now that builds a committed utxo, and also extracts proofs from it and validates blocks using the proofs. |
| 12:45:25 | petertodd: | wumpus: well, an intermediate approach might be to port p2pool to python-bitcoinlib - it does pass every test right now re: scripting, so we might actually be reasonably close (though I'd rather it just be done right...) |
| 12:45:48 | gmaxwell: | petertodd: for forrestv reorging the existing code is enough. I was thinking longer term. Basically a libscep256k1 for the 'script' digital signature system. |
| 12:45:54 | petertodd: | gmaxwell: ugh, committed utxo is madness long run... and if it's a within-p2pool thing like I say, it's a 51% attack vector |
| 12:46:20 | warren: | forrestv mentioned a desire to rewrite p2pool in C (or something) after the bitcoind-less node is prototyped in python |
| 12:46:24 | gmaxwell: | petertodd: p2pool needs to use calls to C/C++ for fast ecdsa anyways. |
| 12:46:51 | petertodd: | gmaxwell: yeah, why python-bitcoinlib calls openssl :) |
| 12:47:26 | petertodd: | warren: is he open to C++ so it could just directly call a consensus library from the satoshi code? |
| 12:47:39 | warren: | petertodd: dunno, e-mail him |
| 12:47:40 | gmaxwell: | petertodd: I haven't had a chance to fully hash out those concerns with forrest, he knows they exist now. I think utxo is an awesome fast startup mechenism regardless, but it seems he thinks that p2pool must become storage-free. |
| 12:48:07 | gmaxwell: | petertodd: he already told me that he was fine calling into C++ for the consensus library from satoshi code. |
| 12:48:10 | petertodd: | gmaxwell: txo commitments are no different in terms of implementation complexity |
| 12:48:16 | petertodd: | gmaxwell: good! |
| 12:49:28 | petertodd: | * petertodd wonders if forrest knows about partial utxo mode |
| 12:49:31 | gmaxwell: | then this discussion made me realize that eventually I need a very small implementation of script for another project. So then I went to look at Jeff's C code in picocoin. The glib made it not immediately useful to me for now, but its close. |
| 12:49:45 | gmaxwell: | I don't think forrest has been pulled into any of these discussions which needs to get fixed. |
| 12:50:10 | gmaxwell: | but in any case, I don't think we can prevent it from being a liablity if it's doing something stateless in a network that is still stateful. |
| 12:50:29 | petertodd: | gmaxwell: no, we really can't... fundemental flaw of bitcoin right now |
| 12:50:53 | petertodd: | gmaxwell: I mean, god help us if he realizes he can do all this even simplier with partial utxo mode and just assuming blocks are valid... |
| 12:51:07 | petertodd: | gmaxwell: no fancy utxo proofs needed at all! |
| 12:51:20 | gmaxwell: | but who knows, p2pool hasn't been gaining hashrate with the network lately. KNC has their 1.5 PH/s on eligius, and it seems all the cointerra stuff is going elsewhere (e.g. cloudhashing doing its own thing). Too bad, the cointerra boxes are awesome on p2pool... ~1% DOA rate. |
| 12:51:46 | gmaxwell: | "Expected time to block: 1.3 days" |
| 12:52:16 | gmaxwell: | I'm not actually convinced storageless is an interesting goal, since the bandwidth overhead is so substantial. |
| 12:52:21 | gmaxwell: | but thats what he's been thinking. |
| 12:52:44 | petertodd: | I tell you, you need to A: integrate low-varience mining into the core and B: ban pools outright. I think I've figured out how tree-chains could be a soft-fork upgrade to bitcoin - haven't looked into andrew miller's stuff for making it always possible for hashers to steal block rewards via blind sigs though |
| 12:52:45 | jgarzik: | makes life easy on the machine side; less components to fail |
| 12:53:02 | jgarzik: | RE RAM-only |
| 12:53:20 | petertodd: | jgarzik: yeah, easier aside from the entire network failing... |
| 12:53:43 | gmaxwell: | indeed. though at what bandwidth overhead is that a win? p2pool using 10x the bandwidth would be very irritating for me personally. I'm not sure what the overhead of his stuff actually works out to however. |
| 12:54:22 | TD_: | TD_ is now known as TD |
| 12:56:21 | petertodd: | gmaxwell: see, that's the scary thing, if you drop the utxo proofs and use partial utxo mode you get no bandwidth overhead, but aren't really contributing to the security of the network |
| 12:57:18 | petertodd: | heck, I should write that code as an example economic exploit |
| 12:58:01 | petertodd: | doing a quick soft-fork to proof block content posession wouldn't be hard |
| 12:58:10 | gmaxwell: | well I figured I'd talk to forrestv again later after he's had time to mull my cluesticking that it's actually harmful to mine bad blocks. |
| 12:58:40 | gmaxwell: | petertodd: just futher supercharges hosted mining which is way worse than pooling. |
| 12:59:17 | petertodd: | gmaxwell: we don't have a choice - it's an economic exploit |
| 13:00:10 | gmaxwell: | sure we do... so long as scaling isn't uncapped the actual cost of running a node is not very exciting. |
| 13:00:55 | petertodd: | but that's playing into *my* argument that requiring, say, proof of past block data isn't bad |
| 13:01:15 | gmaxwell: | (e.g. I think forrestv is actually chasing the wrong problems: p2pool increase in block time is because these centeralized miners are choosing not to use it, but not due to the cost of running a node…) |
| 13:01:40 | gmaxwell: | oh well perhaps I agree with that. Not sure. Too many things in my head these days. |
| 13:01:46 | petertodd: | forrestv would be smart to take this to an alt actually - dogecoin might have the right politics |
| 13:03:35 | gmaxwell: | Forrestv is smart enough that I trust that next time I talk to him he'll have magically solved all these problems. |
| 13:04:03 | petertodd: | I sure hope so |
| 13:04:19 | gmaxwell: | well I can't handle any more feeling of doom, so it'll have to be so. |
| 13:05:34 | petertodd: | heh, feel free to outsource all your doom to me |
| 13:05:58 | gmaxwell: | doom dummy load |
| 13:06:09 | gmaxwell: | what is your doompedance? |
| 13:06:36 | gmaxwell: | "50 owwwwm doomload" |
| 13:06:36 | petertodd: | variable |
| 13:08:11 | petertodd: | heh, the exchange I was talking to said I ruined their day |
| 13:08:59 | petertodd: | ...and they were pretty clueful already |
| 13:33:58 | wumpus: | gmaxwell: thanks for refuting IanCormac's accusations one by one on reddit, hopefully he'll bugger off now, and if not we can just link there |
| 14:15:57 | tt_away: | tt_away is now known as tacotime_ |
| 17:06:05 | maaku: | grrr why is pinocchio on a non-commercial license... |
| 17:06:58 | petertodd: | maaku: because they're bad people, incapable of love |
| 17:07:29 | maaku: | redmond needs to see a little more sunshine |
| 17:08:08 | petertodd: | oh, right, that's MS research, figures... |
| 17:09:20 | teward: | teward has left #bitcoin-wizards |
| 17:12:40 | just[dead]: | just[dead] is now known as justanotheruser |
| 17:13:24 | spin123456: | spin123456 is now known as spinza |
| 17:21:35 | maaku: | and SNARKs for C doesn't seem to be publicly available :( |
| 17:21:43 | maaku: | i may have to roll my own |
| 17:27:04 | tacotime_: | maaku: is the SCIPR lab stuff under some kind of government/corporate license? |
| 17:27:42 | maaku: | tacotime_: that's SNARKs for C. i can't seem to find a source release (or even a binary release) anywhere |
| 17:27:48 | maaku: | just conference papers |
| 17:28:06 | tacotime_: | ah. yeah try the authors |
| 17:28:28 | tacotime_: | if you haven't already. sometimes they just don't release to public initially. |
| 17:29:00 | tacotime_: | it looks like the zerocash paper is going to be released at the symposium in oakland this year: http://www.scipr-lab.org/pub |
| 17:32:56 | maaku: | yes, but i'll wait until there's a version that doesn't include unbounded, undetectable inflation, thank you :) |
| 17:33:11 | tacotime_: | heh |
| 17:41:26 | nsh_: | maaku, how confident are you that a zerocash system sidestepping the requirement for trusted destruction of initialization information is plausible? |
| 17:42:13 | nsh_: | nsh_ is now known as nsh |
| 17:42:49 | maaku: | nsh: depends on what you mean - zerocash's mistake was to make too much information private in a CRS setup |
| 17:43:16 | nsh: | can you elaborate? |
| 17:44:13 | maaku: | if the amounts were public and/or accounted for by the validator then the worst the creator of the system could do is steal coins, publicly as they are put in |
| 17:44:39 | nsh: | oh, i see |
| 17:44:58 | tacotime_: | does darkcoin's decentralized coinjoin mechanism actually work as intended to provide privacy? |
| 17:45:15 | maaku: | i think that would be acceptable if it is true that we really can't get rid of the CRS limitation |
| 17:45:30 | maaku: | especially if you allow anyone to create validation keys, instead of standardizing on one |
| 17:45:58 | maaku: | tacotime_: coinjoin works as intended, i have no idea what darkcoin's rebranding of it is promising |
| 17:46:17 | nsh: | i guess there's a kind of conservation of connivance effect: the trade-off for increasing the privacy of user-balances is an increase in the malfeasance potential of someone possessing the CRS init material |
| 17:46:37 | justusranvier: | maaku: Can you give an update on the UBC project for the benefit of those donating to support it? Should they continue to do so? |
| 17:46:42 | nsh: | (connivance might not be the best word there -- it just sounds good and alliterates ;) |
| 17:46:44 | maaku: | nsh: i hear credible rumors that a CRS-free construction might be possible, which would make zerocash safe-er to use on a side chain |
| 17:46:52 | nsh: | that would be very cool |
| 17:47:39 | tacotime_: | maaku: this is their latest diagram: http://www.darkcoin.io/downloads/DarkSendv3.pdf |
| 17:48:02 | tacotime_: | I thought there was a reason that you couldn't effectively do coinjoin over a decentralized protocol, but I might be mistaken |
| 17:48:16 | maaku: | nsh: precisely. abusing the CRS init material, or a break of the underlying crypto (keep in mind that this is both very new, and adds novel assumptions) |
| 17:48:27 | nsh: | indeed |
| 17:49:05 | maaku: | tacotime_: you can do coinjoin just fine over a p2p protocol, so long as you have access to an anonymous communication mechanism. |
| 17:49:16 | maaku: | indeed that is the original described use case |
| 17:49:22 | tacotime_: | ah, okay |
| 17:49:29 | jtimon: | oh dear, http://huntercoin.org/ http://wiki.chronokings.com/index.php?title=Introduction "players can broadcast their digitally signed moves over the P2P network" |
| 17:50:24 | maaku: | justusranvier: the UBC data structures are documented here : https://github.com/maaku/bips/blob/master/drafts/auth-trie.mediawiki |
| 17:51:43 | maaku: | based on feedback I got from that in Dec/Jan, a few changes were made, and as of 4 days ago these are now implemented in the reference code, with unit tests : https://github.com/monetizeio/python-bitcoin/blob/master/bitcoin/authtree.py |
| 17:53:17 | maaku: | based on continued feedback from core developers in this channel, I think it likely a validation index would be accepted, but less likely that a wallet index for light clients would make it into the soft-fork |
| 17:54:45 | maaku: | for this reason I've developed a compromise - committed indices covering just the contents of a block, with occational summary indices every day or so |
| 17:55:13 | maaku: | that will allow the common use case of syncing a wallet, wihtout doubling the storage and performance requirements of a full node |
| 17:56:37 | tacotime_: | How is the C implementation of the UBC coming along? |
| 17:57:07 | justusranvier: | What about other implementations besides bitcoin-core? |
| 17:57:17 | maaku: | tacotime_: I've got a STL map-like class for reading, writing, and updating these proofs |
| 17:57:26 | maaku: | but it doesn't yet pass the unit tests imported from the Python version |
| 17:57:38 | tacotime_: | ah, hmm |
| 17:58:50 | maaku: | once it does, i then need to do a backend for sharding proofs to LevelDB, which is complex but similar to the CCoins code already written, so maybe a lot of that can be reused (it sortof replaces CCoins anyway) |
| 17:59:10 | tacotime_: | right |
| 18:00:05 | maaku: | regarding other implementations, it'll be very easy for Electrum to use the existing Python code I linked to. it purposefully doesn't have too many other dependencies |
| 18:01:19 | maaku: | BitcoinJ/MultiBit will unfortunately require another implementation in Java |
| 18:01:26 | maaku: | but that doesn't need to hold up the soft-fork |
| 18:03:07 | maaku: | nsh: there's a lot of really interesting things you can do even with the CRS limitation |
| 18:03:51 | maaku: | you just don't want to force any CRS parameters into the protocol itself - let people specify their own validation keys in their scriptPubKey |
| 18:04:08 | justusranvier: | maaku: Thank you. I believe I have the answers to all my questions now, including the ones you've refrained from answering. |
| 18:04:32 | maaku: | justusranvier: did I refrain from answering anything? I didn't intend to |
| 18:05:23 | maaku: | nsh: like escrow, you can usually find someone trusted to do the CRS initialization for *specific* use cases, (e.g. for an audit, have your competetor or a regulator generate them) |
| 18:05:24 | justusranvier: | I haven't received any replies to recent emails and PMs. |
| 18:06:03 | maaku: | oh sorry, yes I got your email from yesterday and was going to reply this afternoon (I still will, addressing the contents of that email specifically) |
| 18:06:09 | maaku: | i was just out with family yesterday |
| 18:08:45 | justusranvier: | Maybe one of our IRC clients is broken with respect to PMs. |