00:04:55 | xenog_: | xenog_ is now known as xenog |
00:05:50 | lnovy: | lnovy is now known as zz_lnovy |
00:40:43 | c0rw1n: | c0rw1n is now known as c0rw|sleep |
01:04:59 | gnnr: | gnnr is now known as gavmatic |
01:34:33 | rusty: | rusty has left #bitcoin-wizards |
05:21:44 | fanquake1: | fanquake1 is now known as fanquake |
05:38:06 | zz_lnovy: | zz_lnovy is now known as lnovy |
08:05:13 | orwell.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 |
08:05:13 | orwell.freenode.net: | Users on #bitcoin-wizards: andy-logbot rubensayshi CoinMuncher u7654dec p15x_ llllllllll fanquake wallet42 gill3s hktud0 dEBRUYNE priidu NewLiberty_ kmels Mably berndj damethos adam3us arubi_ antanst KuDeTa tucenaber kyuupichan helo [7] superobserver afk11 bassguitarman Taek felipelalli d1ggy ebfull hashtagg Dr-G2 dc17523be3 Madars hulkhogan_ Emcy rustyn gmaxwell PaulCape_ shesek Adlai luny nuke1989 sparetire_ p15 lnovy LeMiner Tiraspol crowleyman bedeho cdecker iddo |
08:05:13 | orwell.freenode.net: | Users on #bitcoin-wizards: jonasschnelli OneFixt jmcn go1111111 justanotheruser spinza alferz mengine GreenIsMyPepper amiller antgreen prodatalab_ mkarrer sneak epscy adams__ wiz michagogo platinuum mikolalysenko jbenet artifexd grandmaster dansmith_btc SubCreative airbreather sadoshi lmacken Pan0ram1x bosma dgenr8 c0rw|sleep HM Cory larraboj brand0 nickler PRab yrashk vonzipper cfields nsh Krellan_ Luke-Jr stevenroose coryfields Meeh catlasshrugged cryptowest_ Alanius |
08:05:13 | orwell.freenode.net: | Users on #bitcoin-wizards: null_radix kanzure gavinand1esen Logicwax copumpkin stonecoldpat bliljerk_ melvster waxwing azariah harrow tromp_ ttttemp isis scoria andytoshi warptangent harrigan sparetire davout comboy TD-Linux yorick crescend1 veox mm_1 theymos Zouppen huseby _whitelogger wumpus binaryatrocity heath BananaLotus maaku face_ Apocalyptic [d__d] optimator Eliel gnusha tromp narwh4l lmatteis wizkid057 koshii leakypat mr_burdell throughnothing_ elastoma |
08:05:13 | orwell.freenode.net: | Users on #bitcoin-wizards: fluffypony Fistful_of_Coins yoleaux Jaamg se3000 xabbix mariorz catcow a5m0_ smooth dignork runeks CryptoGoon Sqt poggy livegnik K1773R petertodd richardus nephyrin phedny so BrainOverfl0w @ChanServ Oizopower gwillen kinlo sl01 STRML espes__ AdrianG luigi1111 Anduck BlueMatt midnightmagic otoburb kumavis starsoccer d9b4bef9 gribble jessepollak ryan-c Keefe indolering Graet jaromil sturles [ace] merlincorey Iriez EasyAt morcos CryptOprah s1w |
08:05:13 | orwell.freenode.net: | Users on #bitcoin-wizards: roasbeef eric sdaftuar Xzibit17 weex_ warren Muis mappum forrestv nanotube ajweiss guruvan SwedFTP pigeons afdudley phantomcircuit |
09:37:13 | c0rw|sleep: | c0rw|sleep is now known as c0rw1n |
09:53:07 | Adlai`: | Adlai` is now known as adlai |
10:03:17 | Mably_: | Mably_ is now known as Mably |
12:50:12 | NewLiberty_: | NewLiberty_ is now known as NewLiberty |
14:28:07 | maraoz: | IDK if this is the right place to discuss this, let me know.. would it make sense to create a script type similar to p2sh but without requiring the redeemScript to be included in the scriptSig? (it could be obtained via other means just with the script hash, for example, from a DHT) |
14:31:31 | maraoz: | I don't see the need to include the full script in the blockchain other than convenience of access, with extra costs to the network (storage, bandwidth, etc) |
14:32:27 | Taek: | sounds like it would be vulnerable to withholding attacks |
15:19:42 | NewLiberty_: | NewLiberty_ is now known as NewLiberty |
15:29:14 | CoinMuncher1: | Any wizards around? |
15:30:24 | CoinMuncher1: | Please shoot me down if I'm talking old news or bullocks. Currently receivers of a new block header can't immediately start mining on top of that block before they fully receive and verify the block (mostly for DOS attack reason I believe). |
15:30:29 | CoinMuncher1: | However: I was wondering what could be done if a miner puts a transaction sending x of his own BTC to fees (himself in most cases) in the block he's working on. |
15:30:34 | CoinMuncher1: | Basically he's saying: "I'm risking x BTC of my own as a guarantee that this block is valid, please build on it when you receive my blockheader+this special transaction." |
15:30:38 | CoinMuncher1: | Of course if his block gets orphaned he still loses that money anyway as the next miner can run with his transaction, but it might convince people to trust him to not be doing a DOS attack? |
15:30:43 | CoinMuncher1: | I'm not smart enough to oversee the deeper incentives and implications of this, so I'm just throwing it out there to the wolves... |
15:32:10 | Taek: | I'm not sure what the current mining software landscape is like, but I imgaine that the vast majority of blocks with valid headers (which require a lot of hashing to create) are going to be completely valid |
15:32:30 | Taek: | it should be profitable for a miner to immediately start mining on a new header and then validate after receiving the rest of the block |
15:33:07 | Taek: | the only risk is that the rest of the block never shows up, but you can just set a 10s timeout |
15:33:33 | Taek: | that would be very expensive to DoS, because each 10s that you waste requires an entire valid block header |
15:34:04 | CoinMuncher1: | yeah, but it's dangerous for a miner to start mining without verifying (according to core devs). They're assisting a DOS attack (even doublespend attack?) if it turns out to be invalid. I don't know the full details tbh. I wouldn't be surprised if a lot of miners do that anyway, but that's a different story. |
15:35:02 | Taek: | it's certainly dangerous if you don't verify asap. I think the core-devs are mostly talking about miners that never verify the block, not miners with start mining a block a few seconds before verifying |
15:55:00 | tromp: | I don't see how you can DOS attack with PoW satisfying headers, you could only produce only a few headers per hour?! |
15:56:36 | Taek: | tromp: it's a DoS if they are headers to invalid blocks and the miner doesn't verify the blocks |
15:59:25 | tromp: | right; but like you said, miners would not want to wait more than a few secs for getting the whole black to verify |
16:00:04 | Taek: | right. As long as they are verifying quickly after, it should be fine |
16:02:40 | tromp: | miners verify not because they fear this kind of attack but because they fear invalid blocks as result of stupidity or misconfigured miners |
16:03:40 | tromp: | would be nice to see statistics on invalid blocks with satisfying PoW... |
16:03:53 | tromp: | must be super-rare nowadays |
16:15:46 | CoinMuncher1: | yeah, I'm probably mistaken that it's for anti-DOS purposes. I mean any receiver of the headers would obviously check the hash. I'm fairly certain there is a good reason though for miners to wait until it's fully verified. Or maybe not for the miner individually, but for the Bitcoin network as a whole. |
16:15:48 | CoinMuncher1: | That's one of the reasons why block propagation of bigger blocks is such a big deal now, right? If everyone could just wait 20 sec for the full block but in the meantime mine the next block, it wouldn't be such a big deal. Plus that the new miner can't put any transactions into the new block if he doesn't know which ones are already in the existing block. |
17:49:46 | gmaxwell: | CoinMuncher1: verifying a newly recieved block normally takes virtually no time, because the transactions/signatures are already cached. |
17:51:20 | gmaxwell: | Failing to validate it, if widely done, would severely undermine the security of bitcoin from the perspective of common SPV wallets; because no confirmation count "1" and dozens would be meaningful anymore... since once a bad transaction made it in there would be a potentially unbounded amount of time before that chain was abandoned. |
17:52:58 | gmaxwell: | if they only verified later then it effectively means everyone needs to wait for more confirmations to have equal security; which might be tolerable-- but why? |
18:23:13 | temujin: | I'm not sure if there would be any amount of BTC you can put up as guarantee that would convince other miners to build upon your block; in fact I think the opposite would be the case, they'd simply reject that block and work on their own to try to capture the fee and avoid the risk of building upon a possibly invalid chain |
18:25:09 | zooko`: | Can I download logs of this channel so that I can grep them? The search feature on https://botbot.me/freenode/bitcoin-wizards/2015-05-11/?tz=Etc/UTC isn't finding me what I need. |
18:27:54 | tromp: | how do you know it's on that date then? |
18:27:58 | tromp: | (hi, Zooko!) |
18:28:57 | zooko`: | tromp: I didn't mean to link to that specific date. And: hi there! :-) |
18:29:07 | zooko`: | zooko` is now known as zooko_laptop |
18:29:38 | tromp: | ah, you mean the Search feature on that site didnt find what you were looking for |
18:29:54 | zooko_laptop: | That's what I meant. |
18:30:02 | zooko_laptop: | How are you doing, tromp? |
18:30:21 | tromp: | Doing fine, as usual:) |
18:31:14 | tromp: | I mean I'm slowly recovering from your loss of interest in deploying Cuckoo Cycle:-( |
18:33:42 | zooko_laptop: | Awww. |
18:37:20 | tromp: | but i guess i can always fork your code and "fix" the PoW :-) |
18:39:32 | zooko_laptop: | Yes! :-) |
18:41:58 | tromp: | do you expect to be ready by 2016? |
18:47:41 | zooko_laptop: | Yes! |
18:47:55 | zooko_laptop: | Don't tell anybody okay? This is top secret. |
18:48:05 | zooko_laptop: | But we're currently planning to launch a testnet in August. |
18:48:08 | zooko_laptop: | Of this year. |
18:48:22 | nsh: | * nsh smiles |
18:49:20 | tromp: | that's faster than (i) expected |
18:49:56 | tromp: | that suggests you started on the implementation already |
18:50:01 | zooko_laptop: | We have! |
18:50:12 | zooko_laptop: | I spend all of my time trying to raise money. |
18:50:16 | zooko_laptop: | Don't tell anyone that, either. |
18:50:29 | tromp: | so you're mostly done building out the programming team? |
18:50:32 | zooko_laptop: | But others of our team spend their time writing unit tests and other such useful stuff. |
18:50:53 | zooko_laptop: | Um, we're going to open source everything we have ASAP, so I can then point you to details. |
18:51:00 | zooko_laptop: | Let me see if I can summarize. |
18:51:15 | zooko_laptop: | There's a lot of QA/security/robustness/testing -type work to do. |
18:51:41 | zooko_laptop: | And, yes, a few pieces of functionality yet to be implemented. |
18:51:59 | zooko_laptop: | But the basic secure Pour transactions and the blockchain and network are all finished. |
18:52:45 | tromp: | pour it on! |
19:17:47 | Taek: | zooko_laptop: that's really exciting, looking forward to it. |
19:19:36 | nsh: | \o/ |
19:29:53 | zooko_laptop: | Taek: thanks!! |
21:10:19 | NewLiberty_: | NewLiberty_ is now known as NewLiberty |
22:37:20 | moa: | http://it.slashdot.org/story/15/05/20/1258251 the cynicism is strong with this one |
22:47:11 | nsh: | .title |
22:47:12 | yoleaux: | 'Logjam' Vulnerability Threatens Encrypted Connections - Slashdot |
22:47:27 | nsh: | cynical how, moa? |
22:48:09 | nsh: | our favourite TLA pals indisputably spend a lot of resources undermining virtual private network security, by as many means as fit into their budget (and secret budget) |
22:48:46 | nsh: | i'm not sure what's cynical except the behaviour of leaders of the free world |
23:22:46 | moa: | nsh: exploiting an obsolete compromised behaviour arising from laws enacted by their bidding |
23:23:25 | moa: | not to say that the current set of laws enacted by their bidding wont be cyncially exploited far into the future |
23:23:30 | moa: | either |
23:24:17 | moa: | you seem to think the 'leaders' of the free world have technical input into these laws :) |
23:24:19 | nsh: | ah, right; we're on the same page. i mistook that you were suggesting that commenters were being over-cynical |
23:25:22 | nsh: | well, to keep [vaguely] on topic. why did all these VPN implementations use standardized primes in the first place? |
23:26:01 | moa: | TIL: predicting the future is difficult, predicting human reaction to the future is next to impossible |
23:26:19 | moa: | srry OT |
23:32:17 | moa: | nsh: good question ... because "people shouldn't roll their own crypto"? |
23:33:32 | moa: | maybe the standardised ones are different from the standardized ones |
23:34:14 | hulkhogan_: | nsh: i thought it was b/c DHE export laws purposely demanded for crippled crypto |
23:36:08 | gmaxwell: | 16:25 < nsh> well, to keep [vaguely] on topic. why did all these VPN implementations use standardized primes in the first place? |
23:36:20 | gmaxwell: | because generating acceptable numbers for a DH group is computationally expensive. |
23:36:25 | gmaxwell: | (worse than generating RSA keys) |
23:37:43 | gmaxwell: | And assuming your group is good there is no known harm in using a standarized one--- (if your group is weak enough that doing the precomputation to crack many keys makes sense, then next year it'll be weak enough that just cracking single keys makes sense) |
23:37:55 | nsh: | * nsh nods |
23:38:13 | gmaxwell: | Also, if you'll note-- some of this logjam stuff has pointed out that things using their own groups are actually using groups which aren't safe primes or aren't even primes! |
23:38:30 | nsh: | why are DH group primes more expensive to generate/filter than primes for RSA exponents? |
23:38:45 | nsh: | heh |
23:39:40 | moa: | 'aren't even primes' ... lol |
23:39:57 | nsh: | * nsh reads http://security.stackexchange.com/questions/54359/what-is-the-difference-between-diffie-hellman-generator-2-and-5 |
23:39:58 | gmaxwell: | Because you need to check that p-1/2 is prime as well; also the primes you're looking for are larger (as for RSA you find half-sized P and Q) |
23:40:00 | nsh: | (goes into some detail) |
23:40:11 | nsh: | ah, right |
23:41:26 | nsh: | i think strong prime generation should be a public service under the auspices of the UN or some such organization that is maybe less bureaucratic and useless |
23:41:28 | gmaxwell: | these days its not really much of a consideration. But you could just as well ask why ECC stuff doesn't use per user random curves. |
23:42:09 | nsh: | i'd hazard there are more ways to pick a bad ECC curve than a bad DH prime |
23:42:47 | nsh: | but it's economies-of-scale that are the real problem here |
23:43:06 | nsh: | (combined with a network adversary that also has massive storage and computation resources) |
23:43:48 | gmaxwell: | nsh: just like picking acceptable DH primes-- if you only care about security and not speed-- there are a few known things to test for. otherwise random is fine. |
23:43:52 | phantomcircuit: | nsh, it takes minutes to generate 2048 bit DH primes |
23:43:57 | phantomcircuit: | it takes many minutes for 4096 |
23:44:23 | nsh: | then *vpn developers should be politely encouraged to make this part of the configuration |
23:45:36 | hulkhogan_: | thats quite interesting, in particular the aspect of group weakness being the spof for DH security |
23:46:41 | gmaxwell: | in any case, ISTM that group flexiblity was actually a liability here, as the defaults were okay but locally generated groups were sometimes insecure (for unknown reasons) |
23:47:33 | nsh: | heh, cryptokid actually asked a cogent question about this a couple of years ago: http://crypto.stackexchange.com/questions/1999/is-it-safer-to-generate-your-own-diffie-hellman-primes-or-to-use-those-defined-i |
23:48:11 | kanzure: | cryptokid does not appear on that link |
23:48:20 | nsh: | (kaepora, i mean. i reserve the right to be mean indefinitely, or at least until i meet him and determine that he's actually a nice person) |
23:48:28 | nsh: | *to be mean about him |
23:49:39 | nsh: | and in this SE he was actually being prescient, and the answering parties myopic, to a certain extent anyway |
23:49:50 | gmaxwell: | nsh: the thing we don't know now that would be interesting is why did the non-prime (or non-safe-prime) DH groups exist? It's not like the primality testing failed. |
23:50:22 | nsh: | subversion perhaps? |
23:50:26 | gmaxwell: | (the normal primality testing trivially reaches probablities thate are better than 1 failure in 2^100) |
23:50:34 | nsh: | can they be correlated with particular software |
23:50:40 | phantomcircuit: | nsh, oh and trying to generate large dh primes needs lots and lots of entropy |
23:50:49 | nsh: | * nsh nods |
23:50:58 | gmaxwell: | phantomcircuit: it doesn't really just crappy software needs lots of entropy. |
23:51:05 | nsh: | there's a perfect primality testing algorithm since 2012 or so, i believe |
23:51:10 | gmaxwell: | The prime isn't even secret, so you don't need any entropy at all! |
23:51:15 | kanzure: | "Actually, it's not actually true that "it doesn't matter what prime you use"; certain primes (say, primes where p−1 is smooth) are a really bad idea. In addition, it's a good to generate p so that you know a large prime factor q, so that you can generate a generator for a subgroup that size." |
23:52:19 | nsh: | .wik AKS test primes |
23:52:20 | yoleaux: | "The AKS primality test (also known as Agrawal–Kayal–Saxena primality test and cyclotomic AKS test) is a deterministic primality-proving algorithm created and published by Manindra Agrawal, Neeraj Kayal, and Nitin Saxena, computer scientists at the Indian Institute of Technology Kanpur, on August 6, 2002, in a paper titled "PRIMES is in P"." — http://en.wikipedia.org/wiki/AKS_primality_test |
23:52:34 | nsh: | okay, less recently than i remembered |
23:52:44 | phantomcircuit: | gmaxwell, openssl wants like megabytes of /dev/random output to generate a 4096 bit dh prime |
23:53:20 | phantomcircuit: | plausibly it's just a bug though |
23:53:52 | gmaxwell: | nsh: APR is from like the 1980s.. though I guess it's not quite polynomial but it doesn't really matter. |
23:53:58 | gmaxwell: | phantomcircuit: sure, because openssl is dumb. |
23:54:53 | gmaxwell: | It's not even a blinking secret. You do want to not generate the same as someone else (otherwise you'd just use the RFC ones), sure but reading 100-200 bits and using a CSPRNG (or just _incrementing_) for your test points would be fine. |
23:55:23 | nsh: | .wik Adleman–Pomerance–Rumely primality test |
23:55:24 | yoleaux: | "In computational number theory, the Adleman–Pomerance–Rumely primality test is an algorithm for determining whether a number is prime. Unlike other, more efficient algorithms for this purpose, it avoids the use of random numbers, so it is a deterministic primality test." — http://en.wikipedia.org/wiki/Adleman%E2%80%93Pomerance%E2%80%93Rumely_primality_test |
23:56:12 | nsh: | i wish i had enough maths to contemplate how these primality testing algorithms relate to the riemann hypothesis |
23:56:53 | nsh: | we were discussing something recently that related to a generalized zeta function. can't remember what though now |
23:57:46 | gmaxwell: | nsh: but really I dunno that for these applications that you care if its sound. For the probablistic ones every test iteration e.g. doubles your probablity rejecting a non-prime, so you can become arbritarily confident fast. After not many iterations its more likely that software errors, bitflips, or some fundimental misunderstanding of mathmatmatics has created greater risk than a false result f |
23:57:52 | gmaxwell: | rom the probablistic test. |
23:58:13 | nsh: | * nsh nods |
23:58:59 | nsh: | pragmatically, statistical testing to the desired confidence is fine for all intents and purposes. theoretically, deterministic testing is [possibly] more likely to help elucidate Hard Questions about number theory |
23:59:03 | phantomcircuit: | nsh, 4096 bit dh prime 7m52.618s |
23:59:12 | nsh: | oh, nice |
23:59:58 | nsh: | might be worth someone blogging some benchmarks to dissuade any laziness on the part of VPN provider mitigations |