09:05:14weber.freenode.net:topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
09:05:14weber.freenode.net:Users on #bitcoin-wizards: andy-logbot zwischenzug2 CoinMuncher wallet42 erasmospunk xenog mkarrer melvster Dr-G Guyver2 Mably paveljanik DougieBot5000 hktud0 dc17523be3 koshii waxwing jaromil p15 espes__ x98gvyn prodatalab_ fanquake tromp_ d1ggy_ RoboTeddy justanotheruser dgenr8 flower Apocalyptic PaulCapestany gwillen huseby dasource Emcy_ coiner jaekwon_ alferz bbrittain fenn nuke1989 GAit gribble c0rw1n hashtag_ amincd Pan0ram1x HM2 prepost shesek tromp ahmed_ eordano
09:05:14weber.freenode.net:Users on #bitcoin-wizards: cryptowest Logicwax nickler Alanius luny face PRab BananaLotus guruvan ryan-c MoALTz lnovy DoctorBTC adlai sipa harrow grandmaster Luke-Jr delll_ OneFixt amiller go1111111 ebfull cluckj brisque cfields sdaftuar Starduster veorq coryfields devrandom helo bosma Hunger- xabbix burcin runeks null_radix bedeho copumpkin gmaxwell GreenIsMyPepper sneak SwedFTP LarsLarsen epscy nanotube binaryatrocity spinza andytoshi bliljerk101 wizkid057 starsoccer
09:05:14weber.freenode.net:Users on #bitcoin-wizards: comboy nsh Taek iddo EasyAt maaku btcdrak NikolaiToryzin s1w Visheate crescendo livegnik optimator fluffypony Meeh cursive yoleaux dansmith_btc [d__d] berndj morcos Fistful_of_Coins dardasaba isis BlueMatt airbreather smooth phantomcircuit ajweiss Xzibit17 yrashk artifexd Zouppen kumavis mariorz catcow Krellan michagogo forrestv Muis platinuum Oizopower catlasshrugged Keefe JonTitor petertodd kanzure eric mappum jbenet wiz midnightmagic heath
09:05:14weber.freenode.net:Users on #bitcoin-wizards: gnusha warren Adrian_G Iriez lechuga_ dignork kinlo jessepollak Graet Eliel veox warptangent indolering K1773R TD-Linux leakypat CryptOprah Anduck a5m0 d9b4bef9 mr_burdell NeatBasis davout brand0 @ChanServ throughnothing btc___ azariah MRL-Relay otoburb hguux__ so phedny roasbeef BrainOverfl0w wumpus jcorgan
12:45:44waxwing__:waxwing__ is now known as waxwing
14:48:43bramc:Related to the discussion here from a day ago, the amount of mining which happens will inevitably be directly related to the mining rewards. If transaction fees become nontrivial they'll increase mining rewards and cause more electricity to be wasted^H^H^H^H^H^Hspent on mining
14:49:26sipa:You get what you pay for.
14:50:06sipa:The security of the system, in a purely rational setting, is exactly what the community pays for (in form of subsidy and fees).
14:50:38sipa:That is, assuming there is no means for getting consensus without burning a resource.
14:50:59luny`:luny` is now known as luny
14:51:43sipa:In a POW setting, assuming zero hardware costs, that amount will largely go to electricity, minus profitability margins for miners.
17:09:26LTD_:LTD_ has left #bitcoin-wizards
17:28:17Pasha:Pasha is now known as Cory
17:52:47waxwing__:waxwing__ is now known as waxwing
17:59:45kanzure:weird how charlie lee thinks the block interval was chosen randomly?
18:00:34CoinMuncher:He has to... otherwise is scamcoin falls to pieces.
18:03:38kanzure:also he thinks mining difficulty is based on the number of people mining. that was also a huge shock for me to hear.
18:20:58dgenr8:the network is overbuilt for the amount of value it secures today. but that's why the value can scale up immediately.
18:21:38dgenr8:credit where due, AA made the point today. kanzure posted links to transcripts in #bitcoin
18:22:42Apocalyptic:dgenr8, I was actually thinking that reading the transcript as well, I'm quite surprised
18:24:53kanzure:i have a strong urge to modify transcripts in real-time to be more correct.. but then i worry about attributing things to people that are correct but not what the people said.
18:26:57adlai:kanzure: add the note in brackets/parentheses?
18:27:23kanzure:hehe perhaps :)
19:01:35xenog_:xenog_ is now known as xenog
19:02:35xenog:xenog is now known as Guest51623
19:02:35xenog_:xenog_ is now known as xenog
19:31:03brisque:dgenr8: overbuilt? I think not. bitcoin's network is extremely immature.
19:33:56brisque:stratum is a particular problem for example. what's the point of having 300 petahash of SHA256d if a large portion of it can just be silently pushed around by whoever controls a pipe or has access to a BGP routing interface.
19:39:38kanzure:"Last week we did a gut biome discussion. Much of our personality is driven by the bacteria in our gut. In certain diseases, a fecal matter transplant (basically a poop transplant) fixes diseases but you also get the personality and the allergies that you get the FMT from. So if you could imagine stealth FMTs, and you wake up and suddenly you are a different person. So we are going ot need tamper-proof assholes. So we know ...
19:39:44kanzure:... experimentally that you can copy personality from one person to another with a fecal matter transplant, but what's interesting is when the NSA begins to design bacteria to make you behave in different ways. Perhaps this can solve depression in a few ways; so that means it will be funded. You have to be aware of the different levels and layers where attacks can occur."
19:39:50kanzure:beautiful level of paranoia that i can totally appreciate
19:45:25brisque:kanzure: you don't have to be crazy to be involved in bitcoin, but you probably are.
19:45:29Luke-Jr:kanzure: wait, is that literally true, or someone's joke?
19:46:00brisque:Luke-Jr: it is a real medical procedure, and it does have effects on peoples mood and diet.
19:47:01bramc:The major changes from intestinal flora transplants have happened, but they're the exception rather than the rule
19:47:07jcorgan:it can be used to cure an otherwise antibiotic-resistent intestinal infection.
19:48:54bramc:They are, in fact, very reliable at curing a number of otherwise very hard to cure intestinal infections
19:48:59instagibbs:not to defend Litecoin by any means, but did Satoshi actually give a reason for 10min?
19:49:21brisque:I think 10 minutes was just an otherwise undefined magic number.
19:49:56Luke-Jr:it's not a bad choice
19:50:04Luke-Jr:could have been trial and error
19:50:06instagibbs:right, like many things they ended up being pretty good
19:50:10bramc:instagibbs, A number was necessary? The tradeoff is that shorter times result in shorter transaction clearing times but more orphaned blocks
19:50:26instagibbs:No I understand why we like 10 min vs 12 seconds, but I was speaking historically
19:51:14Luke-Jr:bramc: nah, shorter times just reduce variance, they don't really help security other than that
19:52:42instagibbs:Yeah I'm not going to start investing in fecal futures quite yet
19:52:46brisque:bramc: "orphan" is the wrong term to use here
19:53:01bramc:If you make the assumption that it takes about 5 seconds for a message to make its way through the whole network, then the average clearing time is minimized when the cycle time is set to e*5, or about 14 seconds. It doesn't go up fast as you increase, and goes up sharply as you go down, so it turns out that about 30 seconds is about the minimum you should consider with a minute being somewhat reasonable.
19:53:46brisque:bramc: that must be why Ethereum chose 14 seconds.
19:53:48jcorgan:someone empirically measured p2p transit time once, no?
19:53:51bramc:Luke-Jr, I didn't say anything about security. It's a latency issue. If anything shorter times hurt security because there are more orphan blocks
19:54:34bramc:brisque, Uh... unfortunately that's probably true. Maybe when I explained this to Vitalik I should have made really, really clear that actually going with 14 seconds isn't such a hot idea
19:54:36Luke-Jr:jcorgan: for blocks, IIRC it was something like 2 minutes or so to cross the network, a few years ago
19:55:14Luke-Jr:(obv this has not huge relevance to the current state)
19:55:15jcorgan:ISTR something in the last year that actually came up with 50% and 90% distribution times for TX
19:55:23instagibbs:It also makes your consensus fragile with active afttackers, no?
19:55:28brisque:bramc: it should be amusing to watch.
19:55:30instagibbs:sybilers slowing down propagation
19:55:36brisque:jcorgan: http://bitcoinstats.com/network/propagation/
19:55:53jcorgan:that was it, thanks.
19:56:05bramc:brisque, What's your objection to my use of 'orphan'?
19:56:13instagibbs:bramc: I think the term is "stale"
19:56:20instagibbs:orphan implies dead parent?
19:56:26Luke-Jr:bramc: orphan blocks are ones without (or with unknown) parent blocks. you're not talking about those
19:56:33bramc:Oh okay
19:56:51instagibbs:Luke-Jr: like data could be totaly lost?
19:56:52brisque:instagibbs: implies no parent
19:56:55instagibbs:or just ficticious
19:56:57instagibbs:ah ok
19:57:06Luke-Jr:it's a commonly misused term since the generation of a stale block is orphaned
19:57:27Luke-Jr:(that is, the stale block contains an orphan transaction)
19:57:43instagibbs:*scratches head*
19:59:09instagibbs:sorry could you rephrase that one more time, for posterity
19:59:39instagibbs:nevermind im googling
19:59:54Luke-Jr:instagibbs: block.vtx[0] is orphaned when its block is not in the main chain
20:00:10bramc:I wonder if Joi Ito telling everybody to come on this channel was a good or a bad thing.
20:00:12brisque:bramc: at any rate it will be interesting to see how their network copes with 14 seconds. once you're down to that level, inter-node latency becomes utterly critical. just getting from asia to US is often in the 350ms range. if you assume an inv > getdata system like Bitcoin has you could be looking at 5% of your block time taken up in just latency between two nodes.
20:01:05jcorgan:i'm sure they'll come up with six different ways to propagate data and implement them simultaneously
20:01:09bramc:brisque, Yes latency becomes critical at that point. Although hopefully the relatively small transactions sets will make that easier.
20:01:52instagibbs:Active attacks on propagation will probably be more profitable, no?
20:02:14brisque:if you can jam someone else's blocks, sure.
20:02:14bramc:If you assume a million peers in the network and 100ms for a peer to get data out to two peers, that's two seconds for new blocks to propagate over the whole network
20:02:50bramc:instagibbs, Yes having lots of stale blocks means that attacks centered on making blocks stale are more likely to work
20:03:19bramc:So someone can improve their mining rate by having connections open to every peer in the universe and sending directly to all of them
20:03:29bramc:Or a mining pool can do it
20:03:40bramc:At 14s this matters a lot.
20:04:05brisque:I think people would start doing what they do in bitcoin, forget sending an inv, just force push blocks
20:04:25instagibbs:So yeah you'll end up staking for a pool that's highly connected with other pools, much like bitcoin
20:04:36instagibbs:(assuming they're doing PoS)
20:05:05bramc:Is my guess about zerocash right, that the public signatures are a hash of a serial number and a secret, and that the proofs involve showing a path to the current merkle root of all coins?
20:05:52bramc:brisque, blocks should be force pushed
20:06:15brisque:my node is going to be cutting onions if you do that.
20:07:12bramc:cutting onions?
20:07:41bramc:When a peer gets a block, it should immediately blast the whole block to 2 or three peers and send notifications that it has the block to all of its other peers
20:08:13bramc:then send the block to a new peer who hasn't announced that they have it yet every 30 ms or so
20:09:08bramc:That way you have basically 100% overhead on distributing blocks but extremely low latency
20:09:43brisque:I don't think I have a single peer that's 30ms away
20:10:21bramc:The 30 ms is in case that peer got a copy of the block from some completely unrelated route
20:10:54instagibbs:This really only matters to miners, I think
20:11:05kanzure:what's really weird is that joi ito is actually on irc
20:11:11kanzure:i just forget which channel he's hanging out in
20:11:20kanzure:amiller: do you remember where joi hangs out on irc? :(
20:12:06brisque:bramc: I meant that an announce every 30ms would have 10 in flight before I even get a reply to the first
20:12:25bramc:brisque, Oh it isn't an announce, it's just sending the block
20:13:02brisque:bramc: we would probably end up sending the binary to each other simultaneously then, which is a huge waste of time
20:13:11bramc:That whole I have X/send X/here is X automatically triples how long it takes for things to get across the network
20:13:37bramc:brisque, not if everybody only sends to two peers immediately
20:15:03bramc:Depending on assumptions, you can also do things like use ECC on the block and request extra bits from the peers who have started sending already
20:15:12kanzure:ah, #joiito
20:15:41instagibbs:thanks for the writeup kanzure
20:15:43bramc:When you have megabyte size blocks that one is actually a good idea
20:16:13kanzure:instagibbs: yep.. videos are just rude. :)
20:16:29bramc:Maybe this makes me a jerk, but I find the vast bulk of what goes on in the bitcoin space to be irrelevant blathering
20:17:22kanzure:brisque: well, he's not wrong
20:17:33kanzure:Luke-Jr: yeah, joi ito said those things (see the transcript)
20:17:40instagibbs:is this not true in any "space" unless properly scoped? ;)
20:17:53brisque:kanzure: who isn't?
20:18:17kanzure:instagibbs: i'm not sure if fecal matter futures are the right asset for that. but if you have ideas about selling custom bacteria let me know. biology is sort of a hobby, you could say.
20:18:27kanzure:brisque: sorry, i was responding to scrollback
20:19:03instagibbs:why do I feel like I'll be getting a visit by the CDC now
20:20:21bramc:instagibbs, Probably, I've often felt the same way about bittorrent and have probably come off like a jerk when someone claimed they were going to make a new protocol and I said something to the effect of 'those idiots will never get anywhere'
20:20:35lechuga_:bramc: why ecc?
20:21:00bramc:lechuga_, less chance of bandwidth wastage from two peers sending the same data
20:21:40instagibbs:bitcoin-land also suffers from being a many-pronged beast. Anyone with a degree in anything is an 'expert' in something about it
20:21:42bramc:That can also be minimized by having peers request specific pieces, but we're trying to eliminate the announce/request/send cycle
20:21:47lechuga_:seems like a heavy way of dealing with that, couldnt they just send from random offsets
20:21:52lechuga_:ah ic
20:21:57kanzure:instagibbs: nah, the fbi has taken up the "regulation" of diybio
20:22:11kanzure:instagibbs: http://diyhpl.us/wiki/transcripts/fbi-diybio-2012/
20:22:16brisque:bramc: much nicer just to use pushes from the high speed block relay and ignore it completely
20:22:53bramc:brisque, I'd rather there not be a high speed block relay. That probably means there's a mining pool
20:23:35brisque:bramc: hm? not really. I don't think the block relay is pool related
20:23:57brisque:it's for pools but not necessary to be one to make good use of it
20:23:59instagibbs:bramc: wishes, horses, yada
20:24:20bramc:brisque, Don't all peers do block relaying? How is a 'high speed' relay any different?
20:24:25lechuga_:hmm i wonder who qualcomm or whomever sues if bitcoin decided to use raptor codes
20:24:50bramc:lechuga_, Probably everybody running a peer
20:25:21brisque:bramc: high speed relay is centralised, and builds blocks with a transaction cache. rather than getting a full 1MB block, you get the diff of what the relay already knows it has sent to you. you can usually get blocks in a couple of hundred bytes rather than 1MB.
20:25:56bramc:brisque, Why don't regular peers do that protocol between each other?
20:26:22bramc:That diff thing is a good idea, the main problem being that the transactions in a block don't have to be sorted :-P
20:26:43bramc:And, uh, is there a reference for that protocol somewhere?
20:27:18lechuga_:itd be a fun experiment to make block downloads swarm based with something like utp imo
20:27:19instagibbs:bramc: I think the answer is: messing with p2p code for such little gains for non-miners is probably not worth it
20:27:32yoleaux:Bitcoin / Mailing Lists
20:27:37lechuga_:but not using ledbat
20:28:30brisque:there's nothing stopping anyone from making alternate bitcoin network transports. it's actually preferable that they do.
20:28:31jcorgan:whatever happened to the bitcoin over DVBT project in Finland? I think they were planning to use fountain codes.
20:29:09bramc:Is this relay node thing actually deployed? Is it a specific set of blessed peers which work this way?
20:29:09instagibbs:To my mind separating p2p network of full nodes and what miners use is a useful separation of concerns. They have different goals; why conflate designs
20:29:37bramc:Supporting utp should be trivial. It's a drop-in replacement for TCP.
20:30:20bramc:instagibbs, I'm not sure what you just said
20:30:33lechuga_:does utp support drop-in cc or just ledbat
20:30:39bramc:miners should be running full nodes, or at least ones which know about all current utxos.
20:30:56bramc:just ledbat, but not sure what you mean by cc
20:31:10lechuga_:congestion control
20:31:15bramc:It backs off on both higher latency and packet loss
20:31:18instagibbs:I, as a fuill node runner, don't really carea bout a few seconds either way in getting a new block
20:31:24instagibbs:miners do
20:31:38instagibbs:(perhaps? probably? it's plausible!)
20:31:53bramc:instagibbs, fair enough, but if the protocol were properly designed the diff thing wouldn't come at any additional cost
20:32:10lechuga_:it plays to lose as i understand which wouldnt be a desireable property in this case
20:32:20maaku:bramc: read the email, there's deployment information at the bottom
20:32:55adlai:bramc: https://github.com/TheBlueMatt/RelayNode
20:33:18bramc:lechuga_, that's a bit of a mix. It keeps latencies low
20:33:24instagibbs:bramc: it's the unforunate centralization of mining that makes this a concern at all. Just for now, it really makes sense to separate. And new transport layers are A-ok regardless
20:34:55bramc:instagibbs, high latencies encourage centralization in mining
20:35:13bramc:maaku, My question was, 'did this actually happen?'
20:35:21instagibbs:I'm not arguing that. (sorry I'm not clear)
20:35:24maaku:yes it did
20:36:11bramc:Okay, one more thing for me to read through
20:36:32lechuga_:with utp nat nodes could become more useful
20:41:31bramc:Yes utp makes hole punching easier
20:49:30kanzure:JoiIto: howdy
20:49:37kanzure:amiller: ping
20:50:24JoiIto:hey... thanks for the email and the transcript.
20:50:40kanzure:sure, i figure nobody has time for video :)
20:52:17instagibbs:speaking of the SoK paper would it be a good idea to link a draft on bitcoin.ninja? The github repo link is um dated
20:54:14skittylx:kanzure: I love your anotations <3
20:54:32kanzure:my goal is real-time correctness proofs
20:54:39kanzure:inject coq proofs maybe
20:56:18CoinMuncher:Am I missing why you are talking about ecc and diffs and stuff, while the invertible bloom filters already solve sending blocks as "constant" (small) size? https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2 Sorry if I'm missing anything.
20:58:33sipa:CoinMuncher: they require much higher cpu time on sender and receiver side per transaction
20:58:54sipa:constant size transmission size doesn't gain you much if everything else becomes slower
20:58:55bramc:also add more to latency because of the extra round trip
20:59:34CoinMuncher:sipa: ok, didn't know it was significantly slower.
21:00:10sipa:i think constant time propagation is a dream
21:00:11CoinMuncher:bramc: I was under the impression it actually did everything in 1 round trip. (maybe I should shut up, among experts)
21:01:02bramc:CoinMuncher, Yeah that means that for me to send to you we need to do announce/request/response instead of me just sending
21:03:20CoinMuncher:bramc: I guess I meant half round trip actually... the sender can build the whole invertible-bloomfiltered block and just start sending it to everyone. It's only to prevent flooding the P2P network that it waits for an inv/request, isn't it. Or were you talking about another way to get around that?
21:05:06bramc:CoinMuncher, For peers to validate the block they need the whole thing, unless you're talking about using a bloom filter to specify which already distributed things are in the block, which does in fact work for compression but isn't the most elegant way of doing that.
21:07:16CoinMuncher:The point with this proposal is that the peers already have 95% of the transactions, even before the block itself exists/has been found/has been mined. So this is a little like ECC in that the sender creates a blob of data that receivers can extract an entire block from IF they have at least 95% of the transactions already. (Any 95%)
21:08:14bramc:It hits funny edge cases when there's false positives in the bloom filter which you have to hunt down
21:08:16CoinMuncher:But I'm really not the right person to explain it, so if you haven't read it, please do read it yourself.
21:08:48bramc:Oh i just saw you posted a link. Will read.
21:09:01kanzure:JoiIto: you may find this helpful http://diyhpl.us/~bryan/papers2/bitcoin/
21:09:08CoinMuncher:Sure. But as long as 90% of the peers get the blocks in 1 round trip, and a few edge cases are just unlucky once in a while. Does it really matter?
21:10:40brisque:CoinMuncher: higher CPU usage is probably a concern
21:11:43CoinMuncher:Gavin was attended to research around the topic and within a few months built it into a proof of concept. I'm sure there's still issues with it (CPU as sipa mentioned). So I have no idea whether it will ever be usable. But I hope so, cause it's so cool :)
21:12:14CoinMuncher:brisque: yeah sipa just mentioned that. I wasn't aware of that. I'll try to read up on that some more.
21:12:44bramc:CoinMuncher, I'll need to read through this in more detail later but my instinct is that it's better for peers to have more stateful connections which remember exactly what their peer has and send a diff directly off of that
21:13:41bramc:There are some subtleties to that, in that if you're sending me stuff and I want to send you a set based off of what you already have I need to specify what the last message number I received from you was. That's all doable though.
21:14:01bramc:The canonical block ordering is critical
21:14:14CoinMuncher:yeah I think that's what the relay thing does. And http://kryptoradio.koodilehto.fi/ too if I'm not mistaken.
21:16:19bramc:I'm not sure what benefit the invertible bloom lookup tables are supposed to bring
21:16:55bramc:In some sense they make it simpler because you can rebroadcast the bloom filter you already got but the amount of complexity in parsing and handling them more than destroys that efficiency
21:17:03CoinMuncher:That you don't need to know what the other peer knows. You just assume they already have x% and give them something that will guarantee they can reconstruct a the 100%.
21:17:14CoinMuncher:No matter what 100-x% they are missing.
21:17:50CoinMuncher:apparently yeah.
21:17:50bramc:But you should already know what your peer has already
21:18:05CoinMuncher:No, that's the cool trick about it. You don't.
21:18:08kanzure:wow i can't believe they said that-- "Zero of those companies should be downloading bitcoind."
21:18:26kanzure:that's a ridiculous position
21:18:39kanzure:a third party blockchain data service provider telling you to not use bitcoin
21:18:45kanzure:yeah that's secure -_-
21:19:00CoinMuncher:bramc: unless I'm totally mistaken.. you're making me feel insecure now :)
21:19:01bramc:When you have an open direction to a peer you should be actively sending all transactions bidirectionally
21:19:25gmaxwell:kanzure: who said that?
21:19:33kanzure:on the livestream
21:19:36instagibbs:kanzure: yikes
21:19:54bramc:kanzure, What, if anything, is their justification?
21:19:57instagibbs:zooko is there right, can he pester on qa
21:19:59brisque:CoinMuncher: you're not, reed solomon ECC will let you do that, but with significant CPU cost.
21:20:02gmaxwell:damnit. time to get away from the computer and find something to distract me from wanting to never see bitcoin again.
21:20:03kanzure:their justification is "use our api"
21:20:35kanzure:i have nothing against these people, i have something against bad ideas
21:20:38kanzure:and not using bitcoind is a bad idea
21:21:07CoinMuncher:brisque: Do you have any chance a link of a discussion about the CPU usage of the invertible-bloomfilter stuff? Or is that common knowledge for any ECC-thing related?
21:21:29kanzure:gmaxwell: i've been trying to formulate a short, succint and good argument against these third-party api providers. but so far i don't think i have anything strong enough.
21:21:39brisque:bitgo already has the nonsense with bitstamp where somehow it's claimed having bitgo co-signing their transactions will be of benefit and provide ultimate security. to make it easier for people to use, they have a proxy shim for their API so it looks like you're talking to bitcoind. there's something horrible implied there, that people working with other people's money can't even be bothered writing a new interface.
21:22:13kanzure:brisque: they weren't even verifying the change addresses
21:22:20kanzure:so the change addresses were just returned from the api
21:22:21instagibbs:brisque: ive been meaning to ask: does Bitstamp literally not run a bitcoind instance anymore?
21:22:30instagibbs:I read their blog post about the switch and became very confused
21:22:42instagibbs:I thought bitgo was supposed to be a signing oracle or something
21:22:43brisque:CoinMuncher: that's just from observations about using reed solomon ECC stuff before. I use parchive to add error correction to my binary backups, and it's fairly intensive to create.
21:22:53gmaxwell:kanzure: that defeat the whole point of bitcoin? if you were willing to trust a third party you could simply hand your funds over to them (a bank), and in doing so make things much more efficient? ... there is very little use of access to the network which does not create a theft risk for you. People think too myopically that control of private keys is sufficient; it's not.
21:23:11lechuga_:instagibbs: good question
21:23:11kanzure:gmaxwell: "but the real world involves trust" was one argument in response i've heard to that argument
21:23:33instagibbs:lechuga_: I was going to interview with them so I was reading their stuff... got concerned let's say
21:23:39kanzure:gmaxwell: their argument is also something about using them for blockchain data
21:24:05brisque:instagibbs: I don't know their internals. it was implied that bitstamp was using the bitcoind shim and that's why they could move to using bitgo for their transactions so quickly, but I don't know if that's what really happened. if nothing else, bitgo can't do anything by being a cosigner except doing some rate limiting. without other signals about the state of bitstamps database there's no use to having a second party at all.
21:24:17kanzure:brisque: i think they are using both bitgod and bitcoind at the moment
21:24:20instagibbs:there is *no* reason to not use bitcoind, signing oracles shouldn't be crippling you
21:24:37bramc:CoinMuncher, ECC and bloom filters are different things. The ECC stuff is for trying to optimize having to send blocks as one big glob, which is totally irrelevant if the transactions went into the block in canonical order so you can send diffs reasonably
21:24:43kanzure:i think they are still using bitgo as a hot wallet though
21:24:52kanzure:where withdrawal requests cause transactions to get signed immediately
21:24:59kanzure:so it's just pass-through to the remote api
21:25:02brisque:which is, for all intents, worthless.
21:25:06gmaxwell:kanzure: sure it does. As does paypal. The purpose of bitcoin is to produce an alternative with less dependence on it (from the horses mouth! http://p2pfoundation.ning.com/forum/topics/bitcoin-open-source ); and thats pretty much the _only_ thing it does fundimentally better than the classical alternatives. This isn't to say that there can't be trust in bitcoin, filling in where the tech goes; b
21:25:12gmaxwell:ut to add a ton of trust right at the base for the specific purpose the software was built to serve? thats insane.
21:25:21lechuga_:brisque: it makes an offline attack more difficult no?
21:25:31kanzure:"we have upwards of 30 exchanges building on us" -_____-
21:25:34brisque:lechuga_: offline attack?
21:25:41kanzure:"just helping them get out of the security business" hahahaha
21:25:46kanzure:holy crap
21:25:46lechuga_:someone grabs the keys and does whatever with no auditability
21:25:49brisque:kanzure: "we are a very high profile security target"
21:26:14instagibbs:brisque: there are tons of use cases for signing oracles. Just not to replace a person's view of the ledger!
21:26:27brisque:lechuga_: does that even matter? someone malicious at their control panel can just slowly make 100BTC transactions and bitgo will just keep blindly signing them.
21:26:44bramc:gmaxwell, I came up with a super lightweight and scalable cryptocurrency. Everybody keeps track of their own balance, and stops spending when they hit zero. Efficiency!
21:26:55lechuga_:u can at least see it happening and have an opportunity to stop it
21:27:05gmaxwell:bramc: no software required too. :)
21:27:47brisque:instagibbs: yes, I understand that, but the "bitgod" shim just implements a blind signing oracle. the only thing bitgo can do is rate limit based on the size of transactions, and knowing that limit will probably be in place you can do some analysis to figure out what it is and avoid it.
21:27:58bramc:gmaxwell, I'm sure trusted computing will be able to make it work properly
21:28:26kanzure:nobody is going to be around to call these people out
21:28:29instagibbs:brisque: understood. Hence my confusion
21:28:37kanzure:i mean maybe blockstream, but that's blood in the water
21:28:47brisque:instagibbs: oh you were agreeing with me, sorry I mis-parsed your response
21:28:50bramc:blood in the water?
21:29:02kanzure:bramc: blockstream calling this stuff out is politically inconvenient for them :(
21:30:01instagibbs:you need someone with cred, but no money on line. Which is like... academics i guess
21:30:09bramc:To a first approximation, all the major vendors in bitcoin space are incompetents, cranks, and charlatans, the only part which is well engineered and up front about what it can and can't do is core
21:30:55bramc:There are a few small exceptions of course, but mostly when looking at a major vendor the question you should be asking is whether they're an incompetent, crank, or charlatan
21:31:41kanzure:other developers wont find this obvious though
21:32:05bramc:CoinMuncher, in answer to your question, the relative CPU usage of doing bloom filter stuff vs. transaction state stuff is 'obvious'
21:34:31brisque:instagibbs: suffering a lot there from the simple fact that bitcoin knowledge is fairly limited to a small group of people. the ones you might hire based on popularity are fools like andreas antonopoulos, who have absolutely no applicable experience in advising these sorts of things.
21:34:42bramc:kanzure, The thing about how you can't be sure what's going on in bitcoin unless you're running your own peer is kind of fundamental
21:35:08kanzure:bramc: sure but then how is it possible for companies to take themselves seriously like this
21:35:12brisque:bramc: not in the least because these API services have got things horribly wrong in the past.
21:35:20kanzure:brisque: oh?
21:36:33kanzure:gmaxwell: perhaps if people absolutely insist on providing third party blockchain api services, then they should perhaps only be implementing things like simplified payment verification instead... or some other restricted set of features that might possibly be secure. and then anything else should be considered broken.
21:36:34brisque:kanzure: https://i.imgur.com/JNhoV1R.png
21:37:19kanzure:brisque: i prefer a more canonical url https://people.xiph.org/~greg/21mbtc.png
21:37:45brisque:kanzure: I don't.
21:38:08CoinMuncher:bramc: I think the link I sent you might not be best one to explain the trick here. It's not like ECC in that ECC makes the data larger. This trick actually makes it substantially smaller. Maybe you prefer to hear it from Rusty Russel: http://rustyrussell.github.io/pettycoin/2014/11/05/Playing-with-invertible-bloom-lookup-tables-and-bitcoin-transactions.html or the actual paper: http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p21
21:38:38brisque:kanzure: point was that it's not even a matter of trusting these third parties to be malicious, it's also trusting them not to be incompetent.
21:38:41bramc:CoinMuncher, thanks for the links, although I do understand the concept
21:39:21bramc:CoinMuncher, your link to the 'actual paper' is broken
21:40:46kanzure:"all transactions are independently verifiable from other sources" -_-
21:41:03CoinMuncher:bramc: I agree that if you have knowledge about what the other party already has, then it's obviously more efficient and simpler (both bandwidth and CPU wise) to figure out what to send them.
21:42:05bramc:CoinMuncher, Yeah that's the breakdown: I don't see why you'd want to avoid that
21:42:13CoinMuncher:bramc: Also: I forgot that nodes can actually have a pretty good idea of which transactions each of their peers already knows (and already do).
21:43:39CoinMuncher:bramc: sorry about broken link, not sure why. But rusty links to it early in his blogpost.
21:46:43bramc:CoinMuncher, I'm not wondering about your thought process so much and Gavin's
21:48:11CoinMuncher:bramc: Now that you made it clear to me, I do too :)
21:51:11gmaxwell:kanzure: that was the argument I made to electrum ever so long ago, and they agreed, and did. Dunno why people are so quick to trust totally unauthenticated blockchain views. Control of a targets view of transactions is somewhat equivilent to stealing everyone _elses_ private keys.
21:51:57bramc:Its not like running bitcoind locally is some huge drain on resources
21:52:48kanzure:gmaxwell: ah i wasn't aware that electrum listened to advice and took action on that. that's great.
21:52:53gmaxwell:bramc: To hear people talk it is. To be fair there are a lot of aspects of the expirence which are needlessly bad.
21:54:12bramc:Starting countdown to when bitcoin info services start doing DDOS to anyone running a bitcoind as part of their FUD campaign
21:54:33brisque:bramc: well, blockchain.info already do denial of service attack the network
21:54:46gmaxwell:e.g. bitcoin core could do more to give a better 'hot start' expirence.
21:55:26gmaxwell:brisque: I don't think intentionally; though piuk was pretty overly talking about some agressive deanon attacks intentionally on bct a long while ago (and then backed off when I WTFed him)
21:55:59skyraider:gmaxwell: what would constitute an authenticated blockchain view?
21:56:07brisque:gmaxwell: hah, did you see their original "transaction message" system?
21:57:18brisque:one of those UTXO exploding things where it just encodes "messages" as pubkey hashes and sends dust to them.
21:57:20instagibbs:bramc: re:resources for bitcoind, indeed. Makes me really hesitatant to talk of "scaling up" if even businesses can't be bothered to run full node.
22:01:17brisque:bramc: seriously though, I don't think people will actually denial of service attack full nodes at this stage, but they will design systems which are infeasible to run on your own.
22:02:13brisque:ie, if I make a transaction system that needs a 1TB index to run, or you can connect to my centralised API, you can guess which people will choose.
22:02:37skittylx:Divert % of fees to a monthly lottery. Client has to be connected for a certian % of time to be eligible.
22:03:17brisque:skittylx: we can't pay listening nodes, that's completely out of the question due to the sybil problem. you stand to make the network significantly worse by doing that.
22:05:37skittylx:right, thats the whole point of pow. Dunno why I didn't think of that.
22:06:40brisque:there's one sybil node at the moment broadcasting on 2**8 addresses. alone that's literally 5% of the network's listening capacity. if you incentivise that, well.
22:13:26otoburb:otoburb is now known as Guest2979
22:15:01kanzure:gmaxwell: perhaps the solution is to just repeat everything enough times until everyone forgets that they knew a worse idea
22:19:38bramc:Given that even heirarchical wallets aren't standard...
22:21:09jcorgan:kanzure: that only describes key derivation, it doesn't standardize wallet hierarchy layout
22:22:48bramc:kanzure, I meant aren't standardly used by actual wallets. Obviously there's a completely reasonable standard for doing them.
22:24:43bramc:Per the in person conversation from the other day, apparently Vitalik is living full time in Canada, but often in the bay area - http://fusion.net/story/47172/the-young-stars-of-bitcoin/
22:30:53kanzure:"If anyone is interested in using a bip44 Wallet to generate deterministic GPG identities, I have implemented a demonstration in javascript" http://memwallet.info/bip44ext/test.html https://github.com/taelfrinn/bip44extention/blob/master/README.md
22:32:09phantomcircuit:kanzure, wat
22:32:35bramc:I really wish people would give up on pgp already
22:32:56kanzure:bramc: what's your preference?
22:33:05phantomcircuit:bramc, but then what am i going to use this spiffy OpenPGP dongle for??
22:33:25leakypat:kanzure: that looks very interesting
22:33:52bramc:kanzure, There really isn't a decent standard for encrypted asynchronous communication at this point unfortunately, particularly email
22:34:09leakypat:Does it mean I can recover my RSA key pair from the same seed as the EC keys?
22:34:11kanzure:is this a usability complaint?
22:34:39bramc:kanzure, yes
22:34:54kanzure:you forgot your signature?
22:35:20kanzure:(i wouldn't recommend signing extra short messages though)
22:55:54gmaxwell:skyraider: the blockchain itself an authenticated datastructure which supports efficient access without breaking the authentication (SPV).