00:43:07Guest56997:Guest56997 is now known as maaku
00:51:10c0rw1n_:c0rw1n_ is now known as c0rw1n
01:13:24rdponticelli:rdponticelli has left #bitcoin-wizards
02:21:08rusty:Dumb q: is there any code yet for IBLTs and O(1) block propagation?
02:21:26rusty:(Or a BIP?)
02:24:06phantomcircuit:rusty, BlueMatt's relay network is iirc the best available which can be O(1) but i dont think it is
02:24:15phantomcircuit:(since not all the transactions in the block are available)
02:37:10rusty:phantomcircuit: I was referring to Gavin's O(1) block propagation gist
02:39:29phantomcircuit:rusty, the invertible bloom stuff?
02:39:35phantomcircuit:i dont think anybody has implemented that
02:40:33rusty:phantomcircuit: exactly. I'd be interested in how many of the transactions in the block have already reached other miners, which seems to be the critical component.
02:45:31phantomcircuit:rusty, BlueMatt 's relay network stuff does that and has that data
02:45:35phantomcircuit:run a node and you'll see
02:46:29rusty:phantomcircuit: thanks; googling now...
03:03:30bryanvu_:bryanvu_ is now known as bryanvu
04:46:04gmaxwell:::sigh:: http://www.reddit.com/r/Bitcoin/comments/2l83y5/an_attack_on_the_timestamp_semantics_of_bitcoin/
04:49:23gmaxwell:What magic property of Bitcoin is that that otherwise intelligent people make clowns of themselves on interaction with it?
06:18:58bryanvu_:bryanvu_ is now known as bryanvu
06:23:16c0rw1n:c0rw1n is now known as c0rw|sleep
06:30:15spiftheninja:spiftheninja has left #bitcoin-wizards
07:20:27contrapumpkin:contrapumpkin is now known as copumpkin
08:07:38gmaxwell:sipa: found a bug in frama-c while trying to prove that field multiply code correct. ... seems it is losing the typedefs when generating the theorems from the code... (stupidly I didn't notice that it was using 2^32-1 as the overflow check and wasted a bunch of time scratching my head as to why really simple theorems were not proving)
08:08:44gmaxwell:Now we just need a GCC bug to know we've really been testing it well. (You know you might be doing at least a barely acceptable job testing your software when you've found several bugs in your tools/dependencies)
09:05:15morgan.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:15morgan.freenode.net:Users on #bitcoin-wizards: andy-logbot adam3us bit2017 cbeams Jokosh damethos NeueWelt stonecoldpat aburan28 austinhill NewLiberty_ jaekwon_ copumpkin bryanvu DougieBot5000_ Keefe todays_tomorrow TheSeven PRab ryanxcharles justanotheruser c0rw|sleep prodatalab fanquake Emcy_ CodeShark hashtag_ devrandom heath johndoe01_ atgreen helo ericp4 phedny iambernie wallet42 shesek zwischenzug K1773R MRL-Relay fluffypony berndj [\\\] Flyer9933 samson_ phantomcircuit spinza
09:05:15morgan.freenode.net:Users on #bitcoin-wizards: kyletorpey Transisto maaku nuke1989 Luke-Jr waxwing sekoe iddo Baz__ zenojis mmozeiko SDCDev tacotime PaulCapestany pi07r btcdrak digitalmagus grandmaster2 fragiletag midnightmagic sl01 nsh wizkid057 Muis Alanius Guest1930 arowser LarsLarsen go1111111 sipa altoz Anduck poggy NikolaiToryzin cfields coryfields Sangheili mappum hollandais jbenet epscy bosma kjj21__000 DoctorBTC Taek Cory sneak EasyAt warptangent Hunger- optimator_ Starduster
09:05:15morgan.freenode.net:Users on #bitcoin-wizards: kumavis andytoshi dgenr8 BrainOverfl0w fds4345 gazab Iriez bbrittain BigBitz Apocalyptic emsid Starsoccer throughnothing warren tromp_ null_radix gavinandresen dansmith_btc Meeh kyuupichan Nightwolf AdrianG Logicwax pigeons nanotube Grishnakh lnovy asoltys weex_ kanzure gribble Krellan kinlo a5m0 superobserver artifexd fenn [d__d] LaptopZZ gnusha HM_ espes__ CryptOprah Graet burcin livegnik gmaxwell _2539 hguux bobke petertodd smooth BlueMatt
09:05:15morgan.freenode.net:Users on #bitcoin-wizards: @gwillen michagogo jrayhawk_ yoleaux amiller crescendo btc_ danneu catcow TD-Linux [Tristan] otoburb ryan-c roasbeef pajarillo Gnosis ahmed_ so harrow abc56889 lechuga_ @ChanServ wumpus myeagleflies Dyaheon firepacket kgk SomeoneWeird tromp zibbo_ Eliel mr_burdell
09:08:22phantomcircuit:gmaxwell, ha
09:24:42gmaxwell:boo ya
09:24:43gmaxwell:S_r[0..1] ∈ [0..67108863]
09:24:43gmaxwell:[2] ∈ [0..68157440]
09:24:43gmaxwell:[3..8] ∈ [0..67108863]
09:24:43gmaxwell:[9] ∈ [0..4194303]
09:31:14sipa:hmm?
09:31:56phantomcircuit:sipa, assuming he fixed the bug in frama-c
09:32:12gmaxwell:thats the ranges of the output r[] on the 'old' versions of secp256k1_fe_mul_inner (10x26)
09:32:39gmaxwell:the new one in pull 73 now is giving me
09:32:40gmaxwell:S_r[0..8] ∈ [0..67108863]
09:32:40gmaxwell:[9] ∈ [0..4194304]
09:33:12sipa:odd!
09:33:16sipa:73 normalizes stronger?
09:33:50sipa:oh, the new version of 73 may
09:33:59gmaxwell:thats what value analysis is telling me.
09:34:01sipa:i haven't looked at that yet
09:34:21sipa:what does it say about the version in my opt-mul-sqr branch? (which contains an older version of 73)
09:34:24gmaxwell:fortunately now that I have it working its no effort to run it again.
09:34:40gmaxwell:link me to the code?
09:35:08gmaxwell:the first numbers I gave were PR91.
09:35:13sipa:https://github.com/sipa/secp256k1/tree/opt-mul-sqr
09:36:23sipa:oh, opt-mul-sqr == pr91
09:36:31sipa:yeah, that's expected
09:36:33gmaxwell:yea. I was about to say. okay.
09:36:40sipa:interesting that 73 normalizes stronger
09:38:59gmaxwell:sqr in 73 is
09:38:59gmaxwell:S_r[0..8] ∈ [0..67108863]
09:38:59gmaxwell:[9] ∈ [0..4194304]
09:39:19sipa:should be the same as mul, indeed
09:45:33kefkius_:kefkius_ is now known as kefkius
09:47:25gmaxwell:sipa: sadly, frama-c doesn't support the __int128, alas.
09:51:46sipa:gmaxwell: also sadly, the rewritten 32-bit version seems slower when effectively compiled for 32-bit host
09:52:07gmaxwell:yea, just saw that. weird.
09:52:21gmaxwell:well not a shocker, probably running out of registers?
09:52:52sipa:the new version should use less temporary values
09:53:22sipa:but maybe the long-term ones were already swapped out of registers on 32-bit
09:53:29sipa:and there are more short-term ones now
09:53:51gmaxwell:try it on arm?
09:54:03sipa:* sipa has none
10:29:37gmaxwell:andytoshi: you see sipa is working on schnorr for libsecp256k1? https://github.com/bitcoin/secp256k1/pull/87
10:30:08gmaxwell:(including multisignatures)
10:40:11phantomcircuit:gmaxwell, neat
10:40:14phantomcircuit:sipa, ^
13:30:28wallet42:wallet42 is now known as Guest46835
13:30:28wallet421:wallet421 is now known as wallet42
13:35:29fanquake:fanquake has left #bitcoin-wizards
13:39:34andytoshi:gmaxwell: oh, nice! he told me that we was working on it (and had some disappointing perf improvements relative to what we'd hoped), but i hadn't seen the pull
13:41:06sipa:andytoshi: by now it should also have constant-time signing
13:41:32sipa:(apart from potential doublings/cancellations in the addings, but a blinding mechanism prevents exploiting that)
13:41:48andytoshi:the last couple days i've been trying to build cargo so that i can get back to rust dev and update the libsecp256k1 wrapper
13:41:54sipa:cool
13:42:03sipa:feel free to submit when it's clean enough
13:42:30andytoshi:cargo does not build from git HEAD right now, and i need a reasonably recent copy (i.e. not 2 months old) to do rust dev :/
13:43:12andytoshi:there is something like 5 commits/hour in the rust world, it's just a probabilistic game when it works :)
13:58:07kanzure:andytoshi: er, why don't they just not let people push to that branch unless it really, really works?
14:34:20andytoshi:kanzure: because there are like 20 different projects at play in a pre-1.0 environment moving at extremely high speed
14:35:14andytoshi:kanzure: even if there was one body in charge of them all the coordination hassle would freeze things. (fwiw people are claiming on IRC that the nightlies work. i have no disk space to try them)
14:36:16andytoshi:kanzure: also the stdlib is what's changing, which is what causes almost all of the breakage. you can't block that in a pre-1.0 language
14:41:40c0rw1n:c0rw1n is now known as c0rw|away
14:41:41kanzure:oh brother, developers running out of disk space
14:56:27penny:penny is now known as Guest3595
16:09:38ericp4:ericp4 is now known as eric
18:12:58c0rw|away:c0rw|away is now known as c0rw|timetravl
18:28:58c0rw|timetravl:c0rw|timetravl is now known as c0rw1n
19:12:14maaku:maaku is now known as Guest89369
19:30:10gandalf:so is sidechains appendix B currently under development?
19:31:24cryptokeeper:who has some good documentation on side chains
19:31:32cryptokeeper:i know basics and thats it... want moar info
19:32:03andytoshi:cryptokeeper: the whitepaper is best documentation right now
19:32:12Luke-Jr:cryptokeeper: http://blockstream.com/sidechains.pdf
19:32:27cryptokeeper:thank you sirs
19:32:47cryptokeeper:after i am done studying my vmware shit i want to go over that
19:49:27amiller:gandalf, the appendix B right now lays out a lot of good approaches but IMO more work is needed and its ongoing
20:32:59Guest89369:Guest89369 is now known as maaku
20:35:11maaku:gandalf: yes-ish. I have an open pull request that does the commitment mechanism
20:35:35maaku:and the scheme under consideration re-uses patricia trie stuff I've done for UTXO commitments
20:35:55maaku:using a heap structure that has been worked out, but still some work to be done in getting a reference implementation
20:38:06gandalf:sidechains will have a speed limit since they are blockchain based, are there any blockchain alternatives like maidsafe's transaction manager or Ripple?
20:39:43maaku:everything has a speed limit. there are certainly plenty of opportunites for alternative architectures
20:39:47maaku:but those can be sidechains too
20:40:04maaku:you send bitcoin to a sidechain which understands the alt ledger achitecture, and works as a middleman
20:40:17gandalf:how does blockstream plan to make money on this?
20:40:39gandalf:hoping for consulting services is nice, but the effort reward ratio seems off compared to other ventures.
20:41:01maaku:http://www.reddit.com/r/IAmA/comments/2k3u97/we_are_bitcoin_sidechain_paper_authors_adam_back/clhoo7d
21:18:01cbeams_:cbeams_ is now known as cbeams
21:21:12NewLiberty_:NewLiberty_ is now known as Joseph_of_New_Li
21:51:44cpacia:cpacia has left #bitcoin-wizards
22:03:23happycamper:hello
22:20:51Joseph_of_New_Li:Joseph_of_New_Li is now known as NewLiberty
23:02:29HM_:something that occurs to me is that the Bitcoin RPC could be protected by TLS-SRP
23:02:51HM_:it'd eliminate the complexity of having certificates
23:03:52HM_:sadly wouldn't play nicely with scriptable http/json clients though
23:05:42justanotheruser:HM_: the bitcoin RPC really shouldn't be accessed over the net in general
23:07:46HM_:then why does it support SSL? ;)
23:08:09justanotheruser:because people do it anyways.
23:11:06HM_:people can hijack your traffic on a LAN
23:11:23justanotheruser:you shouldn't do it over LAN if thats a risk
23:12:21HM_:malware on your machine can connect to loopback...
23:13:10justanotheruser:If you hvave malware on your machine, none of this is an issue anyways
23:16:02HM_:your just a party pooper
23:16:06HM_:*you're
23:20:21gmaxwell:HM_: you should go implement SRP over secp256k1 and submit it to sipa's library. IIRC it can be implemented over any group where discrete log is hard. :P
23:21:24HM_:yes, but then you'd need your own custom transport protocol.
23:21:47HM_:since, I'm pretty sure TLS doesn't support mythical SRP-EC
23:22:04gmaxwell:HM_: not so, since you could authenticate the ssl session from within it. :)
23:22:09HM_:what would that even be called hmm... SRP-ECDSA?
23:22:57gmaxwell:ECSRP I guess. certantly not ECDSA, since there would be no DSA in it.
23:23:20HM_:but there's a method called SRP-DSS in the TLS spec
23:23:40gmaxwell:Yea, but almost nothing implements it.
23:23:51HM_:yeah, i was looking at the wiki page
23:23:56gmaxwell:And god knows anything that does is probably even more buggy than everything that implements TLS already is.
23:24:10HM_:perhaps
23:24:20HM_:SRP is easier to verify than anything using certificates
23:25:20gmaxwell:yea, I like that you brought it up. we've talked before about having authenticated peerings for the p2p protocol with some custom encrypted transport before... supporting SPR natively would be nice. (e.g. your choice of asymetric key or SRP auth)
23:25:44HM_:SPR?
23:26:44gmaxwell:typo
23:27:16HM_:the major problem with SRP is you still need a protocol for registration, and some out of band authentication method so you can trust the server while you register your username and password
23:27:37HM_:like a CA
23:28:04gmaxwell:sure, SRP is no silver bullet by any means, it just basically makes any case where you'd use a password better.
23:28:10HM_:in that respect it's not much better than trusting a CA and then pinning the certificate
23:28:24HM_:oh absolutely
23:30:02HM_:I've been writing a toy echo server using TLS-SRP + GnuTLS before I consider integrating it in to some other projects
23:30:03gmaxwell:part of the recent SRP hasn't been adopted is because lucent was patent-fuding it and all other password based key exchange schemes; but the patents lucent was abusing for that have now expired (and didn't apply to SRP anyways, but whatever)
23:30:58HM_:Afaict the only broadly workable alternative is local binding + SSH
23:31:02gmaxwell:HM_: why not write a bitcoind rpc wrapper? I'd like to get TLS out of the daemon entirely. E.g. it could run in a seperate process. would make supporting things like SRP easier.
23:31:02HM_:or something like libssh
23:32:01phantomcircuit:gmaxwell, seems like pretty much everything except for the consensus code should be moved into a separate process
23:32:05HM_:gmaxwell, and locally bind plaintext?
23:32:58HM_:world <--tcp/tls --> wrapper <-- tcp/clean --> bitcoind
23:34:19HM_:I'm not sure if that's wise if you move the authentication to the wrapper
23:34:36gmaxwell:HM_: it could even be a unix domain socket or whatever between bitcoind and the wrapper. The rational would be to get the huge attack surface of TLS out of the daemon. You can use stunnel for this already, but it doesn't get you things like SRP support.
23:36:14HM_:sure, socketpair and execve
23:36:23HM_:no idea about how you'd go about it on Windows though
23:44:39phantomcircuit:gmaxwell, would probably be easier to add srp to stunnel than bitcoind though :P
23:45:36HM_:he has a point, stunnel relies on openssl, which implements srp as of 1.0.1
23:46:00HM_:https://www.stunnel.org/versions.html <-- this scares me
23:46:05gmaxwell:not interested in adding any anything to bitcoind atm. I would like to have an alternative P2P transport that support auth/encrypt (and doesn't use TLS because TLS is a huge attack vector). But thats seperate.
23:46:18moa:gnuTLS
23:46:34gmaxwell:all TLS implementations are a disaster, some know it better than others.
23:47:04moa:ha
23:47:30moa:whatever gets the job done sometimes
23:47:34phantomcircuit:moa, gnutls was a decent idea poorly implemented
23:47:39phantomcircuit:the docs were wrong until recently
23:47:55moa:just throwing another option into the mix
23:49:01HM_:having used gnutls today, i'll take it over openssl anyday
23:49:04phantomcircuit:i would bet that libressl will be the best implementation (if it's not already)
23:49:23HM_:botan supports SRP apparently
23:49:38moa:" I would like to have an alternative P2P transport that support auth/encrypt (and doesn't use TLS because TLS is a huge attack vector). But thats seperate." <---- but this sounds great
23:50:07HM_:if you want respect the only realistic alternative is SSH
23:50:30HM_:the only 3rd option i know of is zeromq's curvecp based transport
23:50:36HM_:and i'm not sure i'd take that seriously yet
23:51:27gmaxwell:nonsense.
23:51:45HM_:which bit?
23:51:48gmaxwell:(The SSH transport has also had a bad history too; including some long standing nasty exploitable vulnerabilties)
23:51:57moa:shhh
23:52:02gmaxwell:All of them suffer from too much flexibility.
23:52:29phantomcircuit:my favorite is environment variables transfered over ssh
23:52:32phantomcircuit:which is just bizarre
23:52:52moa:but really cool and useful
23:53:03phantomcircuit:how is that useful?
23:53:10moa:for taking control of remote machines that is
23:53:33HM_:gmaxwell, then maybe this is closer to your desired transport http://curvezmq.org/page:read-the-docs
23:55:02moa:IPSec?
23:55:20phantomcircuit:moa, ipsec == nasty
23:55:41gmaxwell:HM_: I'm familar with it. We already have a MACed transport in bitcoin, it's just unkeyed.
23:56:19HM_:moa, Ipsec solves no real world problems
23:56:37moa:but gets lots of use nontheless ... pick your posion
23:57:49HM_:bah, why the smeg did the zeromq guys factor out their secure protocol to libcurve if it depends on libzmq
23:58:00gmaxwell:moa: not really, a very very narrow subset of IPSEC gets used. (basically for point to point tunnels) It's really highly inapplicable to anything application level.
23:58:18HM_:it even depends on their C binding :S
23:58:39phantomcircuit:moa, afaict ipsec is only used because it's free on cisco equipment vs their ssl vpn
23:58:42gmaxwell:HM_: no shock there.
23:58:46phantomcircuit:i would bet that's like 99% of use
23:59:11HM_:i tried setting up IPSec/L2TP tunneling, it was a nightmare....ended up just using OpenVPN... then i realised that sucked too and just use SSH + SOCKS these days when on the road
23:59:18moa:right, but cisco routers are a big deal
23:59:22HM_:good old ssh -D
23:59:52HM_:so I leak DNS, meh
23:59:54moa:so total traffic on IPsec is not small