00:35:46wallet421:wallet421 is now known as wallet42
00:58:17shinybro:shinybro is now known as satoshi_nakamofo
01:01:59satoshi_nakamofo:satoshi_nakamofo is now known as c0kea
01:03:30c0kea:c0kea is now known as jokea
01:08:29jokea:jokea is now known as hasanone
01:12:08emsid:emsid is now known as hasssan
01:12:18hasssan:hasssan is now known as hassan9
01:19:22hassan9:hassan9 is now known as emsid
01:57:54hasanone:hasanone is now known as satoshi_nakamofo
04:43:38Luke-Jr:adam3us: hi from Las Vegas..
04:58:54phantomcircuit:Luke-Jr, las vegas?
05:07:29Luke-Jr:phantomcircuit: departing for SF now
05:07:44phantomcircuit:Luke-Jr, sf?
05:08:24Luke-Jr:san francisco
05:08:45Luke-Jr:bbl when i land…
05:14:36phantomcircuit:Luke-Jr, lol yeah but why
05:58:26gmaxwell: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:01maaku:gmaxwell: haters gonna hate
06:03:21phantomcircuit:gmaxwell, that is lol
06:05:08sipa:i wish i didn't read that
06:06:29maaku:sipa: i gave up after the 2nd reply
06:06:34maaku:gmaxwell has the patience of a saint
06:24:39tt_away:sigh, i wish there wasn't so much fighting amongst btcd versus bitcoind devs
06:25:31tt_away:i'm with conformal by development but i'm hoping everyone can just get along sooner than later
06:26:45maaku:tt_away: there isn't any fighting that I know of
06:27:06maaku:i have some SNARK related questions outside of my limit of knowledge, but I'm hoping to level up
06:27:30maaku:pinocchio can handle arbitrary boolean circuits, OR arbitrary arithmetic circuits
06:27:53maaku:is there a reason you cant have both operations in a hybrid circuit?
06:28:44tt_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:51maaku:also, this paper also adds set operations to the mix: http://fc14.ifca.ai/papers/fc14_submission_126.pdf
06:29:09wyager:tt_away: are the Btcd devs complaining?
06:29:14maaku:does anyone know some possible use cases? that might help me understand better
06:29:46tt_away:wyager: I don't think "complaining" is the right word, they want to interact more directly with the bitcoind devs
06:30:08wyager:I haven't seen anything on the mailing list about that
06:30:32tt_away:wyager: I told davec (lead dev on btcd) to post to the mailing list and try to sort things out
06:30:34maaku: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:36wyager:I've heard complaints from random people, but none of the devs
06:31:30tt_away:maaku: it's someone from our irc server yeah, i don't think he's a dev tho
06:32:01sipa: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:13tt_away:but there has been a little concern that there hasn't been attributions to btcd for some features
06:32:30sipa:we're one community and it's in everyone's best interest to push the technology safely forward
06:32:39maaku:tt_away: because there hasn't been any contributions from btcd
06:32:44wyager:sipa: I agree, I think any reasonable person realizes that it's not a contest!
06:32:45maaku:if there were, we would attribute them
06:33:06sipa:but indeed, i have seen zero interaction with btcd whatsoever
06:34:05sipa:maybe some people have sent pull requests for features that exidted in btcd first, but without my knkwledge for sure
06:34:08tt_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:05maaku:tt_away: if you could find btcd developers saying that, it would be helpful
06:36:16maaku:maybe we could then identify an actual technology transfer
06:36:34maaku:but as far as I can tell this is just random ignorant people on the internet not connected to either project
06:38:55wyager: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:38phantomcircuit:tt_away, i would be uhm... very surprised if btcd implemented anything before it was even an idea in bitcoind
06:40:03sipa:well, for certain there are hundreds of ideas that aren't implemented
06:40:28sipa:and for some things it's just obvious that this will halpen one way or another
06:40:54gmaxwell:sorry sipa, I should have told you not to load it.
06:41:14sipa:bitcoin core will at some point have deterministic wallets
06:41:19gmaxwell: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:44gmaxwell: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:42:09sipa: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:28sipa:there's no reason not to adoot best practices after they've been established
06:42:29wyager:Interent arguments ftw
06:43:31gmaxwell:sipa: yea, they've already claimed that about bip32 "copying" electrum wallets, though the electrum functionality was via me in any case.
06:59:34zooko:maaku: the motivation for using CRS model in that paper makes me sad.
07:01:31maaku:zooko: can you explain?
07:01:44maaku:maybe I just missed it
07:02:38gmaxwell:oh awesome there is now apparently (?!) a btcd person supporting those outragious claims!
07:06:12pigeons:who, "behindtext"?
07:07:34pigeons:I don't understand this "blind spot" after you went through the list for him
07:09:10phantomcircuit:gmaxwell, http://www.aarongreenspan.com/writing/essay.html?id=98
07:09:26phantomcircuit:that about covers it
07:09:33phantomcircuit:a gem in there
07:09:36phantomcircuit:"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:44gmaxwell: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:31pigeons:it is puzzling
07:12:49phantomcircuit:gmaxwell, unfortunately it has been my experience that often both are true
07:15:00gmaxwell: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:18gmaxwell:... so that kind of thing I can understand, except the folks here claim to be following the development.
07:18:25sipa:gmaxwell: 30 nov 2020? :)
07:18:29phantomcircuit:gmaxwell, is there a tool that can take a list of account#/balance pairs and turn it into an unbalances merkle tree?
07:18:38phantomcircuit:i haven't been entirely following what is going on in that area
07:19:29sipa:gmaxwell: i'm sure we had grttransaction before that
07:19:54gmaxwell:/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:40gmaxwell:phantomcircuit: go to iwilcox's page. There are implementations.
07:21:09sipa:gmaxwell: needs delorean treatment
07:45:47maaku:phantomcircuit: you mean a trie structure?
07:46:07maaku:phantomcircuit: there is this : https://github.com/monetizeio/python-bitcoin/blob/master/bitcoin/authtree.py
07:47:19phantomcircuit:maaku, no i mean a merkle tree to prove liabilities
07:47:35phantomcircuit:but one in which you cannot use the length of the fragment you receive to guess how many other entities there are
07:47:45phantomcircuit:ie one full of 0 balance fake accounts
07:48:27maaku:ok, then no
07:48:46gmaxwell:phantomcircuit: https://iwilcox.me.uk/2014/proving-bitcoin-reserves < links from there
07:49:13maaku:phantomcircuit: is the number of zero entities relevant?
07:49:26maaku:gah, it's late, the total number of entities?
07:49:44maaku:i would think it's okay for that to be public information
07:49:50phantomcircuit:maaku, yes? it tells the entire world how many accounts you have unless you actively work to prevent that
07:50:17phantomcircuit:maaku, for a privately held company even disclosing the total liabilities is an extremely strange thing to do
07:50:28phantomcircuit:but of course this isn't the normal course of business
07:50:45phantomcircuit:gmaxwell, thanks i was having a hard time finding that, it seems to not be linked to extrensively
07:50:50maaku:phantomcircuit: meh, we're talking summation of client funds not total liabilities
07:51:21phantomcircuit:maaku, for any reasonably well operated shared wallet those will be within 1% of each other
07:53:52gmaxwell:For a shared wallet, but a shared wallet isn't an ordinary business.
07:54:13gmaxwell: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:36gmaxwell: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:17gmaxwell: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:56gmaxwell:(including one place that had told me they were working on it— alas)
07:56:01maaku:i want zkp and notarized bank statements please, or i don't do business with you
07:56:10maaku:someone should start a shame campaign
07:56:39gmaxwell: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:57gmaxwell:or other factors; maybe they think doing the proof suggests people should be concerned? maybe they intend on being fractional?
07:57:14ebfull:is the current state of zerocash (288 byte proofs, 128-bits of security) efficient and secure enough for bitcoin's use case?
07:57:25gmaxwell: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:41maaku:ebfull: no, but for different reasons than you mention
07:58:17ebfull:like what? i'm curious
07:58:20gmaxwell: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:14maaku:or if the crypto itself is weak (keep in mind that it is very new)
07:59:31gmaxwell: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:51ebfull:i remember reading about that with the original proposal (zerocoin?) i guess there's no known solution for that yet
08:00:13maaku:thanks gmaxwell for the link, i had seen your descriptions but this iwilcox article is much more detailed
08:00:25maaku:good for showing other people
08:00:29gmaxwell: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:17maaku: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:18gmaxwell: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:02:59gmaxwell: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:18gmaxwell:I do think cryptocurrency will get full fungibility some day.
08:03:26gmaxwell:The current situation is not acceptable or stable.
08:04:29gmaxwell: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:29phantomcircuit: 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:06:38sipa:phantomcircuit: do not question moon math or its followers
08:06:45phantomcircuit:sipa, heh
08:07:01phantomcircuit:gmaxwell, i cant speak for anybody else, but my primary reservation is privacy
08:08:35gmaxwell: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:58gmaxwell:so basically the show the assets side is almost the same thing as a zerocash spend.
08:09:31phantomcircuit:hmm that's interesting
08:09:45just[dead]:just[dead] is now known as justanotheruser
08:09:54gmaxwell:So, if all the zerocash stuff gets publicized it should only require some moderately complex retasking.
08:10:37gmaxwell:and the CRS security assumptions that we were whining about are probably fine for an audit system.
08:10:40maaku:or, you can do it yourself today with Pinocchio/SICP
08:11:40gmaxwell: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:26gmaxwell:I'm not sure how well the circuit generator in pinocchio would work for sha256, might be interesting to try it.
08:14:26maaku:there must be circuit optimizing libraries for verilog et al that could be repurposed
08:14:34maaku:it would at least make work like this easier to do
08:15:15gmaxwell:all this stuff uses arithemetic circuits, not boolean ones, the results are much more efficient...
08:16:41gmaxwell: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:39gmaxwell:then you can have a similar proof that adds up the blinded coin values, etc.
08:18:44gmaxwell: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:57gmaxwell:but whatever, not my battle.
08:19:59gmaxwell:super cheap icaruses on aliexpress (maybe a scam?)
08:23:48fanquake:fanquake has left #bitcoin-wizards
08:31:59petertodd: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:15maaku:petertodd: yes, but you need crypto magic to make verified assertions about the full contents of those trees
08:34:32gmaxwell:petertodd: because you still learn the sum.
08:34:49gmaxwell: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:04gmaxwell:It _is_ arguably commercially relevant information.
08:35:17petertodd: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:18maaku:gmaxwell: is that the reason?
08:35:36maaku: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:50gmaxwell:maaku: it's what they've said, if I didn't understand it.
08:36:13gmaxwell: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:18petertodd: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:21maaku:gmaxwell: oh i don't doubt these companies are giving stupid rationalizations for not implementing this
08:36:36petertodd:gmaxwell: so am I, in particular cold storage
08:37:26petertodd:gmaxwell: I agree crypto-magic would be nice... but that's scaring people off from just getting it done
08:37:37gmaxwell:petertodd: huh, I dunno wtf you're talking about.
08:37:54gmaxwell:The only mention of 'magic' is one line saying magic is possible in iwilcox's thing, and the discussion here.
08:38:45petertodd: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:06gmaxwell: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:25gmaxwell:(and yes, the notion of including the commitment in the txout is suggested on iwilcox's page)
08:41:03gmaxwell:but I think thats fine too.
08:43:33petertodd:gmaxwell: good, because this discussion *has* been scaring off real world users - s
08:47:10petertodd: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:38petertodd:people kept bringing it up at the financial crypto conference (at least the less technical people)
08:48:32petertodd:meh, how much business your service is doing is competitively private info
08:49:12gmaxwell: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:19petertodd:yes, but that can easily be spread out over the day - doesn't have to happen all at once
08:50:38petertodd:equally, reproving that you really have the keys is surprisingly important to people
08:51:02gmaxwell: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:33gmaxwell: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:48petertodd: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:25petertodd: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:52phantomcircuit:petertodd, n-of-m for an exchange in which the user is one of the keys?
09:04:34petertodd: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:11petertodd: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:24phantomcircuit:petertodd, ah
09:05:29petertodd:phantomcircuit: obviously if *customers* had PGP keys and were willing to use them it'd be an easy problem...
09:05:45phantomcircuit:petertodd, ultimately though the exchange *must* have control of the bitcoins
09:06:11phantomcircuit:it's a necessity if trades are to be guaranteed to clear
09:06:19petertodd: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:38phantomcircuit:petertodd, right and that can be useful in a number of ways
09:06:52petertodd:phantomcircuit: equally, those separate stacks could be managed by different teams, or for that matter, the exchange and their software vendor
09:07:37phantomcircuit:petertodd, ultimately there is a database somewhere with a balance and some ledger entries
09:08:05petertodd: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:25hellyeah:hellyeah has left #bitcoin-wizards
09:09:03petertodd:phantomcircuit: no, there should be redundent such databases maintained by different codebases, and the codebases should be in consensus!
09:09:03phantomcircuit:petertodd, if that is exploited then it doesn't much matter what else you have in plance
09:09:24phantomcircuit:petertodd, that's nice in theory, but not in practice
09:09:53petertodd:phantomcircuit: e.g. if you have two databases and customer intent authentication systems, that maps nicely to a 2-of->=2 system
09:10:11petertodd:phantomcircuit: yes, it obviously increases development effort by >2x
09:10:27phantomcircuit: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:51phantomcircuit:both databases will appear correct
09:10:58phantomcircuit:and even if you detect that something is wrong
09:11:04phantomcircuit:good luck proving it
09:11:43petertodd:phantomcircuit: the databases aren't synching to each other, they're comparing to each other
09:12:01phantomcircuit:petertodd, i know, im saying even if you detect a fault
09:12:05phantomcircuit:and you halt everything
09:12:27phantomcircuit:reconcilling the two is going to be essentially impossible
09:12:32petertodd: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:18petertodd: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:13petertodd: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:50petertodd: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:37phantomcircuit:petertodd, er no
09:46:57phantomcircuit:petertodd, on an exchange the vast majority of actions are from sources external to the customers intent
09:47:09phantomcircuit:orders filling
09:47:13phantomcircuit:bank wires posting
09:47:28phantomcircuit:bitcoin transfers in acquiring enough confirmations
09:47:53phantomcircuit:indeed the only thing that is based on customer intent alone is requests to transfer out
09:48:00phantomcircuit:and that's only true under normal operations
09:50:02petertodd:phantomcircuit: all those things either can be subject to the same two-factor-type rules, or are deterministic based on customers intent
09:51:42phantomcircuit:petertodd, how do you keep the two factor rules for the exchanges central limit orderbook?
09:51:47petertodd:phantomcircuit: e.g. bank wires posting should be verified by more than one person
09:52:04phantomcircuit:you have 1ms to complete all of the logic in that loop for a very slow implementation
09:52:51petertodd: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:11petertodd:phantomcircuit: once you have an agreed sequence of orders being fully verified, the state of the orderbook is deterministic
09:53:32petertodd:phantomcircuit: which in turn means the state of the balances at any given point in time
09:54:27petertodd: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:57phantomcircuit:petertodd, personally i consider requiring the wall clock to be synchronized for an exchange engine to work an absolute show stopper
09:55:37petertodd:I sure don't - I've personally worked on systems with a dozen moving parts all synchronized to the nanosecond
09:57:01phantomcircuit:petertodd, i wouldn't consider such a system to be robust
09:57:02petertodd: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:23phantomcircuit:(especially given that building a system which doesn't require timestamps to be anywhere close to synchronized is relatively easy)
09:57:26petertodd:phantomcircuit: security is weird; robust means don't lose money, not uptime
09:57:53phantomcircuit:petertodd, if you rely on timestamps for order execution you will eventually lose money
09:58:00petertodd: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:05phantomcircuit:remember that orders are filled in a price time priority basis
09:58:33phantomcircuit:petertodd, (mostly im just playing devils advocate)
09:58:58petertodd:phantomcircuit: yes, then if that's hard, create a simpler system for version #1 that maintains the strong multi-factor security property
09:59:54petertodd: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:01phantomcircuit: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:30petertodd:phantomcircuit: ...and guess what was proposed for version 0.1?
10:00:39phantomcircuit:a magical oracle
10:01:38phantomcircuit:petertodd, this exchange wouldn't happen to be in .au would it?
10:04:37petertodd:phantomcircuit: dunno if I can comment on that
10:15:44edulix_:edulix_ is now known as Edulix
10:18:05gmaxwell:uh. Dave @ conformal has responded supporting that bullshit thread on reddit.
10:18:53midnightmagic:these are the people that de raadt was raging at a year or so ago aren't they?
10:19:03midnightmagic:* midnightmagic shakes head.
10:19:22gmaxwell:midnightmagic: yes.
10:21:58petertodd:so what's the thread url?
10:22:39gmaxwell:petertodd: http://www.reddit.com/r/Bitcoin/comments/1zx61b/to_the_people_criticising_the_bitcoin_foundation/cfxuhkr
10:24:45petertodd:rather slimy of him I agree...
10:24:59wumpus:these things make me really close to quitting :/
10:25:32wumpus:that's quite an accusation
10:26:31wumpus:at least I didn't even *look at* btcd
10:27:50gmaxwell:wumpus: yea, perhaps I shouldn't have let you become aware of it.
10:28:11gmaxwell: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:25gmaxwell:NTPD, bind, etc. other things have a seperate rpc client its just the obvious thing to do.
10:29:20wumpus: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:24wumpus:and in any case, ideas diffuse around, that's something else than claiming you 'stole' code changes
10:30:25petertodd:heh, wonder if he's finding it hard to get clients...
10:30:33phantomcircuit:gmaxwell, dont feed the douchbags
10:30:37phantomcircuit:i mean trolls
10:31:33gmaxwell:it's very mysterious
10:31:46petertodd:"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:50gmaxwell:same company has apparently been cloning openbsd and creating some big drama there.
10:32:11petertodd:wallet software should have been the first thing he worked on, you know, because actual customers would want it
10:32:12wumpus:gmaxwell: interesting
10:32:24justanotheruser:justanotheruser is now known as just[dead]
10:32:35gmaxwell:midnightmagic knows more about it.
10:33:10gmaxwell:petertodd: thats odd because its like ... the smallest possible thing.
10:33:23wumpus:petertodd: yep ... look at what CodeShark is doing, it's much more interesting
10:33:26gmaxwell:I mean it's just boring engineering work to go seperate out the parts, not some start design decision.
10:33:41gmaxwell:It's something we've considered a good thing to do longterm since 2011.
10:33:44gmaxwell:(at least!)
10:33:57petertodd:wumpus: what's he doing exactly?
10:34:07gmaxwell:I suppose when we finally do that we'll get accused of copying that too. :-/
10:34:25phantomcircuit:gmaxwell, i wonder if that's their goal
10:34:29wumpus:petertodd: a wallet that actually uses hierarchical determinism, n-out-of-n signatures, and such
10:34:41phantomcircuit:to try and guilt us into not copying the few ideas they do come up with
10:34:46petertodd: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:57petertodd:wumpus: ah, cool
10:35:14gmaxwell:yea sure, copying it is fine (pedantically if they actually copy code they're required to retain copyright notices)
10:35:40phantomcircuit:which they're not
10:35:42petertodd:gmaxwell: yup, I personally have copied lots of code and code structure from bitcoind -> python-bitcoinlib, and jgarzik before me
10:35:45phantomcircuit:quick grab the pitch forks
10:35:51gmaxwell: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:09gmaxwell:but I hope for their sake that they aren't actually copying too much code. :)
10:36:36gmaxwell:(because thats its own punishment. :) )
10:37:48petertodd: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:13gmaxwell:lol glib replacement of vectors.
10:38:30petertodd:gmaxwell: ?
10:39:00wumpus:petertodd: had to look it up, his project is 'coinvault'
10:39:39petertodd:wumpus: ah, yeah, I saw that, haven't tried it yet
10:40:25gmaxwell: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:30petertodd:wumpus: pity he's not giving all that hard work with no pay away for free :/
10:40:40gmaxwell:(sad just because it made it non-self-contained)
10:41:08petertodd:gmaxwell: oh, yeah the C library? I dunno, I shudder to think what writing that code in C would be like
10:41:34gmaxwell:just like the C++ code it turns out. So long as you have a vector implementation. :)
10:41:46petertodd:gmaxwell: heh, well.. ifyou take that approach...
10:42:24gmaxwell: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:59petertodd:indeed, like we were saying when I was thinking about forth for remote attestation
10:43:50wumpus: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:59petertodd:wumpus: it's not opensource though; I can't find any license beyond "all rights reserved"
10:46:19wumpus:-CoinClasses is licensed under the MIT license.
10:46:19wumpus:-CoinQ and CoinDB are licensed under the GPLv2 license.
10:47:00petertodd:wumpus: where is that made clear?
10:47:09wumpus:in the README
10:50:26wumpus: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:58midnightmagic: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:47wumpus:though, thinking about, for consensus critical things a self-contained implementation that doesn't rely on any libraries (even libc) makes sense
10:53:20wumpus:midnightmagic: just the kind of drama we needed, thanks for warning us
10:54:10sipa:wumpus: one step at a time
10:54:11midnightmagic:wumpus: if I can help at all, in however limited fashion i'm able, i'm glad to.
10:54:26sipa:wumpus: i've thinking about getting rid of the openssl dependency in validation code
10:55:45petertodd:wumpus: ah! now I see - would be better to be more clear, but that''s good
10:55:47wumpus:sipa: getting openssl out of its direct role in validation/consensus would be a great step forward in that regard
10:58:55petertodd: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:10sipa:you mean libsecp256k1?
10:59:22petertodd:sipa: yes
10:59:37sipa:github.com/bitcoin/secp256k1 :)
11:00:41sipa:needs a big disclaimer readme though
11:02:19petertodd:sipa: so are you planning on git-subtree-including that in bitcoin core when the time comes?
11:02:33petertodd:sipa: indeed
11:07:28sipa:with a --enable-experimental compile-time flag
11:15:31petertodd:sipa: cool. also to be sure, the tweak parameters for add and mul can be 32-bytes right?
11:15:41sipa:must be, iirc
11:18:00petertodd:bbl, net connection here is full of fail...
11:57:43sipa:* sipa -> US
11:58:35gmaxwell:sipa: fly safely.
12:01:05sipa:i will do everything in my power to not disturb the pilot
12:37:11jgarzik:wumpus, gmaxwell: patches welcome :)
12:37:25jgarzik:would love to have a dep-lib-free embeddable lib
12:38:34gmaxwell:FWIW, Forrestv is planning on making it possible for p2pool to run without a bitcoin node.
12:39:35gmaxwell: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:47warren:gmaxwell: that would put p2pool within the realm of instant docker deployment ...
12:40:11gmaxwell:So making the script enging embeddable is probably necessary to prevent this in resulting in doom of some degree or another. :)
12:40:17wumpus:another reason for a consensus library
12:40:33gmaxwell:yea, thats why I mention it.
12:40:48petertodd: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:18gmaxwell: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:23wumpus:it does sound pretty reckless
12:42:06gmaxwell: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:17gmaxwell:I've straightened that out.
12:42:43gmaxwell: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:51petertodd:gmaxwell: python calling c++ isn't a problem
12:42:57gmaxwell:I know.
12:43:03gmaxwell:But thats just his usecase.
12:43:18petertodd:gmaxwell: good - just use the satoshi code! c calling C++ isn't impossible either after all
12:43:38gmaxwell:(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:42petertodd:gmaxwell: huh, so he's really going for utxo commitments? or is he using that for another thing?
12:43:58wumpus: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:30gmaxwell:wumpus: yea, well, libsecp256k1, detangling bignum stuff...
12:44:31petertodd:gmaxwell: I'd expect ABI to cause way less issues than trying to port the existing code to plain C
12:44:47gmaxwell: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:25petertodd: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:48gmaxwell: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:54petertodd: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:20warren:forrestv mentioned a desire to rewrite p2pool in C (or something) after the bitcoind-less node is prototyped in python
12:46:24gmaxwell:petertodd: p2pool needs to use calls to C/C++ for fast ecdsa anyways.
12:46:51petertodd:gmaxwell: yeah, why python-bitcoinlib calls openssl :)
12:47:26petertodd:warren: is he open to C++ so it could just directly call a consensus library from the satoshi code?
12:47:39warren:petertodd: dunno, e-mail him
12:47:40gmaxwell: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:07gmaxwell:petertodd: he already told me that he was fine calling into C++ for the consensus library from satoshi code.
12:48:10petertodd:gmaxwell: txo commitments are no different in terms of implementation complexity
12:48:16petertodd:gmaxwell: good!
12:49:28petertodd:* petertodd wonders if forrest knows about partial utxo mode
12:49:31gmaxwell: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:45gmaxwell:I don't think forrest has been pulled into any of these discussions which needs to get fixed.
12:50:10gmaxwell: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:29petertodd:gmaxwell: no, we really can't... fundemental flaw of bitcoin right now
12:50:53petertodd: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:07petertodd:gmaxwell: no fancy utxo proofs needed at all!
12:51:20gmaxwell: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:46gmaxwell:"Expected time to block: 1.3 days"
12:52:16gmaxwell:I'm not actually convinced storageless is an interesting goal, since the bandwidth overhead is so substantial.
12:52:21gmaxwell:but thats what he's been thinking.
12:52:44petertodd: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:45jgarzik:makes life easy on the machine side; less components to fail
12:53:02jgarzik:RE RAM-only
12:53:20petertodd:jgarzik: yeah, easier aside from the entire network failing...
12:53:43gmaxwell: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:22TD_:TD_ is now known as TD
12:56:21petertodd: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:18petertodd:heck, I should write that code as an example economic exploit
12:58:01petertodd:doing a quick soft-fork to proof block content posession wouldn't be hard
12:58:10gmaxwell: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:40gmaxwell:petertodd: just futher supercharges hosted mining which is way worse than pooling.
12:59:17petertodd:gmaxwell: we don't have a choice - it's an economic exploit
13:00:10gmaxwell:sure we do... so long as scaling isn't uncapped the actual cost of running a node is not very exciting.
13:00:55petertodd:but that's playing into *my* argument that requiring, say, proof of past block data isn't bad
13:01:15gmaxwell:(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:40gmaxwell:oh well perhaps I agree with that. Not sure. Too many things in my head these days.
13:01:46petertodd:forrestv would be smart to take this to an alt actually - dogecoin might have the right politics
13:03:35gmaxwell:Forrestv is smart enough that I trust that next time I talk to him he'll have magically solved all these problems.
13:04:03petertodd:I sure hope so
13:04:19gmaxwell:well I can't handle any more feeling of doom, so it'll have to be so.
13:05:34petertodd:heh, feel free to outsource all your doom to me
13:05:58gmaxwell:doom dummy load
13:06:09gmaxwell:what is your doompedance?
13:06:36gmaxwell:"50 owwwwm doomload"
13:08:11petertodd:heh, the exchange I was talking to said I ruined their day
13:08:59petertodd:...and they were pretty clueful already
13:33:58wumpus: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:57tt_away:tt_away is now known as tacotime_
17:06:05maaku:grrr why is pinocchio on a non-commercial license...
17:06:58petertodd:maaku: because they're bad people, incapable of love
17:07:29maaku:redmond needs to see a little more sunshine
17:08:08petertodd:oh, right, that's MS research, figures...
17:09:20teward:teward has left #bitcoin-wizards
17:12:40just[dead]:just[dead] is now known as justanotheruser
17:13:24spin123456:spin123456 is now known as spinza
17:21:35maaku:and SNARKs for C doesn't seem to be publicly available :(
17:21:43maaku:i may have to roll my own
17:27:04tacotime_:maaku: is the SCIPR lab stuff under some kind of government/corporate license?
17:27:42maaku:tacotime_: that's SNARKs for C. i can't seem to find a source release (or even a binary release) anywhere
17:27:48maaku:just conference papers
17:28:06tacotime_:ah. yeah try the authors
17:28:28tacotime_:if you haven't already. sometimes they just don't release to public initially.
17:29:00tacotime_: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:56maaku:yes, but i'll wait until there's a version that doesn't include unbounded, undetectable inflation, thank you :)
17:41:26nsh_:maaku, how confident are you that a zerocash system sidestepping the requirement for trusted destruction of initialization information is plausible?
17:42:13nsh_:nsh_ is now known as nsh
17:42:49maaku:nsh: depends on what you mean - zerocash's mistake was to make too much information private in a CRS setup
17:43:16nsh:can you elaborate?
17:44:13maaku: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:39nsh:oh, i see
17:44:58tacotime_:does darkcoin's decentralized coinjoin mechanism actually work as intended to provide privacy?
17:45:15maaku:i think that would be acceptable if it is true that we really can't get rid of the CRS limitation
17:45:30maaku:especially if you allow anyone to create validation keys, instead of standardizing on one
17:45:58maaku:tacotime_: coinjoin works as intended, i have no idea what darkcoin's rebranding of it is promising
17:46:17nsh: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:37justusranvier: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:42nsh:(connivance might not be the best word there -- it just sounds good and alliterates ;)
17:46:44maaku: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:52nsh:that would be very cool
17:47:39tacotime_:maaku: this is their latest diagram: http://www.darkcoin.io/downloads/DarkSendv3.pdf
17:48:02tacotime_:I thought there was a reason that you couldn't effectively do coinjoin over a decentralized protocol, but I might be mistaken
17:48:16maaku: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:49:05maaku:tacotime_: you can do coinjoin just fine over a p2p protocol, so long as you have access to an anonymous communication mechanism.
17:49:16maaku:indeed that is the original described use case
17:49:22tacotime_:ah, okay
17:49:29jtimon: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:24maaku:justusranvier: the UBC data structures are documented here : https://github.com/maaku/bips/blob/master/drafts/auth-trie.mediawiki
17:51:43maaku: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:17maaku: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:45maaku: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:13maaku:that will allow the common use case of syncing a wallet, wihtout doubling the storage and performance requirements of a full node
17:56:37tacotime_:How is the C implementation of the UBC coming along?
17:57:07justusranvier:What about other implementations besides bitcoin-core?
17:57:17maaku:tacotime_: I've got a STL map-like class for reading, writing, and updating these proofs
17:57:26maaku:but it doesn't yet pass the unit tests imported from the Python version
17:57:38tacotime_:ah, hmm
17:58:50maaku: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)
18:00:05maaku: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:19maaku:BitcoinJ/MultiBit will unfortunately require another implementation in Java
18:01:26maaku:but that doesn't need to hold up the soft-fork
18:03:07maaku:nsh: there's a lot of really interesting things you can do even with the CRS limitation
18:03:51maaku: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:08justusranvier:maaku: Thank you. I believe I have the answers to all my questions now, including the ones you've refrained from answering.
18:04:32maaku:justusranvier: did I refrain from answering anything? I didn't intend to
18:05:23maaku: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:24justusranvier:I haven't received any replies to recent emails and PMs.
18:06:03maaku: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:09maaku:i was just out with family yesterday
18:08:45justusranvier:Maybe one of our IRC clients is broken with respect to PMs.