00:00:42Taek:I'm not sure that officials always think through that far
00:02:01gmaxwell:depends on who you're talking about; obviously there is a layer of people who just say "but I want in!" without thinking at all.
00:02:03zooko:Yeah, it's not safe to assume internal consistency.
00:02:04Taek:I remember an officer 'shuddering to think' how many people would have gotten away if phone encryption was standard
00:02:17Taek:but these people had video evidence of their crimes *on their own phones*
00:02:39zooko:I think the safest bet is that each person is doing something that they think will improve their own social and/or economic standing.
00:02:46zooko:Beyond that it gets pretty hazy to me. :-)
00:08:50Taek:A lot of regulation seems to crop up from people not understanding how easily it can be avoided
00:09:06Taek:And some of this might come from a taboo upon looking for ways to bypass laws
00:09:27Taek:if the average person was a lot better at knowing how to avoid laws/regualtion, I wonder if our laws wouldn't be more effective as a consequence
00:17:46BlueMatt:zooko: keep in mind most of us are insane, so its hard to tell what people are thinking :p
00:27:39zooko:BlueMatt: :-)
00:29:01rusty:* rusty resists urge to completely rewrite protobuf-c...
00:29:13nsh:is it bad?
00:29:23zooko:Taek: well, that pattern fits in really well with my model, which is that the people proposing the regulation don't *actually* care, in an effective sense about the *consequences*, only about the nominal intent.
00:29:45zooko:If you pass a law banning murder of puppies, you improve your social and/or economic standing. Whether this results in more or fewer puppy murders is irrelevant.
00:29:51zooko:* zooko notices that he isn't in the politics chatroom.
00:29:56nsh:* nsh smiles
00:30:19rusty:nsh: It's... well-meaning.
00:31:01nsh:economic regulation is a little less vulnerable to political incentive issues, as it's usually compartmented such that the people doing the regulating are heavily vested some notional sense of the efficient functionality of the system
00:31:07nsh:as long as it favours their privileged position
00:31:35zooko:An important detail to what I said is "in an effective sense". I mean that those people
00:31:44zooko:may well *feel* strong feelings about saving puppies, and may completely
00:32:02zooko:honestly *believe* that their actions will save puppies, but I think the system
00:32:13zooko:selects for people who convincingly appear that way, including people who
00:32:23zooko:sincerely are that way, not for people that actually reduce the rate of puppy murders.
00:32:25zooko:See what I mean?
00:32:32zooko:I'm not accusing them of dishonesty, but of irrelevance.
00:32:37nsh:right, but the fed reserve board of governors is less concerned with voterfeels than projections, and economic policy, thankfully, is not written by politicians
00:34:41nsh:it's harder to be cynical than bored reading their minutes. one is inclined to believe in grand conspiracies because the real agenda of the most powerful in society is tragically mediocre and predictable for the most part
00:35:20zooko:Everything I wrote above applies to other incentives than voterfeels!
00:35:49nsh:* nsh may have missed some context; just reconnected to bouncer after lappy freeze
00:36:24nsh:* nsh looks at logs
00:36:41zooko:I did use the example of passing a law that voters like.
00:37:15zooko:But the general principle applies to, e.g. defending the honor of your intellectual tradition, getting a juicy consulting job after you retire, etc.
00:37:23nsh:* nsh nods
00:55:51nsh:i thought of a question i couldn't easily answer earlier that some of you will probably know: could you speed up WPA2-PSK cracking significantly by collecting lots of handshakes, rather than just trying to match a single one?
00:59:29nsh:it's a more complex protocol than i'd imagined
01:02:41nsh:i guess the trivial [active] answer is: yes, there are nonces involved and router uptime can be made arbitrarily low.
01:04:22nsh:but i've never seen any talk of using more than one handshake, so perhaps it wouldn't be worth it? not clear to me how to boil down the schematic protocol representation into a complexity analysis in terms of repeated handshakes
01:09:06nsh:* nsh muses about this in ##crypto instead
01:21:17nsh:oh, there is a weakness to the groupwise shared key, but it's somewhat mitigated by the fact that you have to have been associated in the past: http://www.airtightnetworks.com/WPA2-Hole196
01:21:23nsh:i did suspect there would be an issue there
03:35:39jae:jae is now known as Guest45171
03:53:47maaku:if nLockTime were compared against something else other than the height/timestamp of the block, what would that be? GetMedianTimePast()?
04:02:45fanquake1:fanquake1 is now known as fanquake
04:09:18dgenr8:maaku: that seems an odd question. what is the goal?
04:10:52maaku:well petertodd mentioned on a pull request the possibility of soft-forking nLockTime to be GetMedianTimePast() instead of the block timestamp
04:11:25maaku:which decreases some timestamp forgery incentives as far as I can tell, maybe has some other benefit too
04:11:32maaku:i'm not aware of the discussion surrounding that
04:12:22maaku:but while switching nLockTime to be based on GetMedianTimePast would be a soft-fork change, doing the same for a hypothetical relative locktime would be a hard-fork change
04:12:29maaku:so, kinda important to get it right...
04:13:20dgenr8:oh he tweeted about exploiting clock-nLocktime to induced propagation inconsistency
04:16:31dgenr8:my thought was why not let it into the mempool a bit early
04:36:34fanquake1:fanquake1 has left #bitcoin-wizards
04:38:02afdudley:is there a good reference for time-lock encryption somewhere? is there a non-bitcoin/trusted third party implementation somewhere?
04:38:40maaku:afdudley: i don't think there is a bitcoin implementation either :P
04:38:47afdudley:indeed :D
04:41:53afdudley:I am reading this: http://eprint.iacr.org/2015/478.pdf it's very interesting but... I think it might be slightly misnamed.
05:17:09petertodd:dgenr8: if you let it into the mempool, you make the problem worse...
05:18:24petertodd:afdudley: I've implemented timelock crypto here: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg05547.html
05:19:02dgenr8:petertodd: then i must have misunderstood your 140 chars
05:19:46petertodd:dgenr8: the problem is that not all nodes have the exact same clock; when you let the tx into the mempool is irrelevant so long as it's based on the local idea of what time it is
05:20:06petertodd:dgenr8: incidentally, you can doublespend coinbase that way pretty easily
05:22:36dgenr8:petertodd: if you let it in 2 hours before locktime, even nodes with slow clocks should have it when final
05:23:13petertodd:dgenr8: sigh.... again, that changes nothing. go try this yourself
05:24:11dgenr8:petertodd: have you described this somewhere?
05:24:59petertodd:dgenr8: no, why would I? it's pretty obvious how it works once you remember how nLockTime-by-time works
05:25:17dgenr8:petertodd: so we know what "it" is
05:25:43petertodd:dgenr8: meh, I don't get paid to fix zeroconf problems...
05:26:02dgenr8:petertodd: what's your price
05:26:08petertodd:dgenr8: $250/hr
05:26:19dgenr8:petertodd: how many hours will it take
05:26:33petertodd:dgenr8: dunno, it's probably not a fixable problem
05:27:48petertodd:dgenr8: and frankly, given that I'm going to get accused of having bad incentives for this... nah, screw it, I don't want the work
05:27:57dgenr8:petertodd: ... i meant to fix zeroconf completely.
05:28:13petertodd:dgenr8: do you want to still have a decentralized system? because if so, that's impossible
05:29:16dgenr8:petertodd: was sure a highball estimate was coming ;)
05:29:42petertodd:dgenr8: I'm not going to wreck my reputation on something stupid
05:32:19dgenr8:petertodd: question - how long should the tx replacement "feature" be available? did we get lucky and 10+-10 min is just right? or would it be nice to explicitly reneg txes for a longer period?
05:32:40petertodd:dgenr8: huh?
05:33:24dgenr8:petertodd: from your writings, i get the impression that RBF is a really cool feature
05:34:07petertodd:dgenr8: I mean, what does "10+-10" min have to do with it?
05:35:28dgenr8:petertodd: that's how long RBF works, generally. until next block. i use +-10 min as the standard dev. is 10 minutes
05:35:46petertodd:dgenr8: no, RBF works until the tx gets *into* a block
05:35:57dgenr8:petertodd: hence "generally"
05:36:40petertodd:dgenr8: I still don't see your point
05:38:06dgenr8:petertodd: no point, just a question
05:39:29petertodd:dgenr8: block interval is based on latency considerations; shorter block intervals reduce security significantly. Is 10 minutes optimal? Who knows, but like most things in security, arguing about how low we can reduce our security margin and still get away with it is dumb.
05:40:02dgenr8:petertodd: well that answers A question
05:55:52Luke-Jr:I'd argue that once it gets in a block, you don't *need* the replacement feature anymore ;)
08:04:36heath:http://www.jbonneau.com/doc/BFGKN14-bitcoin_bribery.pdf
08:05:16sendak.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:16sendak.freenode.net:Users on #bitcoin-wizards: andy-logbot Pan0ram1x b_lumenkraft Logicwax go1111111 hktud0 wallet42 Mably jcorgan ThomasV arubi akrmn frankenmint jeremyrubin zmachine isis GAit dgenr8 TheSeven PRab Dr-G2 nickler Cory roconnor d1ggy_ jmcn_ wonk_unit cryptowest_ gielbier sparetire_ LeMiner hashtag spinza mengine EasyAt Adlai lmatteis Emcy Tiraspol ttttemp sneak thrasher` mkarrer_ HM gill3s prodatalab__ grandmaster dc17523be3 antanst hashtag_ rustyn jrayhawk copumpkin Relos
08:05:16sendak.freenode.net:Users on #bitcoin-wizards: cdecker Starduster bsm117532 Apocalyptic zz_lnovy p15 harrigan andytoshi scoria stonecoldpat gavinandresen brand0 larraboj bedeho2 PaulCape_ OneFixt luny` melvster superobserver kyletorpey hulkhogan_ antgreen gmaxwell vonzipper mappum MoALTz Jouke weex harrow gnusha alferz tromp__ nsh triazo jonasschnelli mountaingoat CryptoGoon wizkid057 Luke-Jr berndj leakypat pollux-bts bosma platinuum Oizopower jbenet dasource waxwing btcdrak tucenaber
08:05:16sendak.freenode.net:Users on #bitcoin-wizards: kyuupichan helo Taek ebfull Madars iddo GreenIsMyPepper amiller epscy adams__ wiz michagogo mikolalysenko artifexd dansmith_btc lmacken c0rw|zZz yrashk cfields Krellan_ stevenroose coryfields Meeh BrainOverfl0w @ChanServ 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 morcos CryptOprah s1w
08:05:16sendak.freenode.net:Users on #bitcoin-wizards: roasbeef eric sdaftuar Xzibit17 warren Muis forrestv nanotube ajweiss guruvan SwedFTP pigeons afdudley phantomcircuit so phedny nephyrin richardus petertodd K1773R livegnik poggy Sqt runeks dignork smooth a5m0_ catcow mariorz xabbix se3000 Jaamg yoleaux Fistful_of_Coins fluffypony elastoma throughnothing_ mr_burdell koshii narwh4l Eliel optimator [d__d] face_ maaku BananaLotus heath binaryatrocity wumpus _whitelogger huseby Zouppen theymos mm_1
08:05:16sendak.freenode.net:Users on #bitcoin-wizards: veox crescend1 yorick TD-Linux comboy davout sparetire warptangent tromp_ azariah bliljerk_ kanzure null_radix Alanius catlasshrugged
08:18:32b_lumenkraft_:b_lumenkraft_ is now known as b_lumenkraft
08:41:03Krellan_:Krellan_ is now known as Krellan
11:10:25c0rw|zZz:c0rw|zZz is now known as c0rw1n
13:06:34frankenmint:frankenmint has left #bitcoin-wizards
14:03:17kanzure:"Bitcoin and Beyond: A Technical Survey on Decentralized Digital Currencies" https://eprint.iacr.org/2015/464.pdf abstract-only at https://eprint.iacr.org/2015/464
14:10:42kanzure:eh nevermind. not particularly thorough analysis.
14:11:55kanzure:i was expecting more like http://diyhpl.us/~bryan/papers2/bitcoin/Research%20perspectives%20and%20challenges%20for%20Bitcoin%20and%20cryptocurrencies.pdf
14:49:36b_lumenkraft_:b_lumenkraft_ is now known as b_lumenkraft
14:49:40nsh:what was unthorough about it, kanzure?
14:53:46kanzure:nsh: well based on its analysis of proof of stake (and only one reference?) ....
14:54:16nsh:* nsh nods
14:56:28zz_lnovy:zz_lnovy is now known as lnovy
15:05:45dEBRUYNE_:dEBRUYNE_ is now known as dEBRUYNE
16:05:09lnovy:lnovy is now known as zz_lnovy
16:11:08zz_lnovy:zz_lnovy is now known as lnovy
16:15:52lnovy:lnovy is now known as zz_lnovy
16:18:44zz_lnovy:zz_lnovy is now known as lnovy
16:19:40lnovy:lnovy is now known as zz_lnovy
16:40:35zz_lnovy:zz_lnovy is now known as lnovy
16:42:06lnovy:lnovy is now known as zz_lnovy
16:48:00zz_lnovy:zz_lnovy is now known as lnovy
17:02:55lnovy:lnovy is now known as zz_lnovy
19:29:19luigi1111:luigi1111 is now known as Guest95228
19:42:55mrkent:Why does these two testnet block explorers have different blocks? http://tbtc.blockr.io/block/info/427652 http://explorer.chain.com/blocks/427652
19:43:35Taek:https://www.reddit.com/r/ethereum/comments/37bnbv/important_fork_update/
19:44:06Taek:ethereum learns that running implementations of consensus code in multiple languages can lead to hardforks
19:46:52hulkhogan_:i sort of don't understand why they had to reimplement it three or more times just to launch it
19:47:21Adlai:it was lonely without all the python and C++ clients
20:08:58Eliel:maybe they want to avoid getting locked into a single implementation by diversifying early?
20:16:15gmaxwell:Eliel: unavoidable; certantly good to have multiple implementations to help _expose_ issues; but that doesn't itself remove the consensus risk from it.
21:19:20zz_lnovy:zz_lnovy is now known as lnovy
21:40:13GGuyZ:Not really bitcoin but perhaps someone could help :)
21:40:36GGuyZ:I'm trying to prove that a given set of shares cannot reconstruct a valid degree t polynomial. The verifier should at most know a commitment of these shares, but not the shares themselves. Any idea how to solve this? I'm thinking SNARKs but not sure if that's a good fit.
21:42:21GGuyZ:G*
21:42:30gmaxwell:join #btcd
21:42:32gmaxwell:oops
21:53:17GGuyZ:Actually I have a solution
21:54:32gmaxwell:GGuyZ: sorry just saw your question. Your question is insufficently clear to me.
21:54:50gmaxwell:Soemone can always know more shares that they leave out of the proof.
22:22:18GGuyZ:Thanks,
22:25:48GGuyZ:I'll try to be more clear if the line of thinking I'm trying doesn't work out. Tried to keep my question brief but I see why it lacks substance that way.
22:33:08gmaxwell:yea, understood. Sometimes it's just hard to tell what you're trying to accomplish. I'm guessing you want some commitment X and then prove that x,y,z,C(q),C(r) where x,y,z are shares of X and C(q), R(r) are commitments to shares of x.
22:34:07gmaxwell:(where X = C(x)) and some verifier wants to know that the shares agree with C(x).
22:34:37gmaxwell:So long as your commitment scheme is additively homorphic you should just be able to take the shares and the commited shares and interpoate the commitment to x.
22:35:11gmaxwell:and if you have all the shares (in either direct or commited form) then you can just try every interpolation.
22:35:32gmaxwell:(uh, I made some variable name screwups above; so ignoring those...)
23:12:29andytoshi:GGuyZ: ignoring concerns about what your goal is (and if it can be subverted by simply hiding information, say), it's unlikely you can prove anything about polynomial construct
23:12:39andytoshi:constructibility without something as powerful as multilinear maps
23:15:06HostFat:I've wrote my opinion about the block size debate https://www.reddit.com/r/Bitcoin/comments/37du43/market_of_blocks
23:17:19andytoshi:well, if you are OK with having large proofs, you can prove that a bunch of points G, xG, x^2G, x^3G, etc are constructed honestly with simultaneous schnorr signatures, cf http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.117.5343 which does something similar. then you can prove linear equations in x, x^2, x^3, etc using standard discrete log techniques
23:25:42gmaxwell:HostFat: Your post is uninformed with respect to how block propagation works.
23:26:14gmaxwell:HostFat: most large miners (and anyone who wants) use the block relay protocol for relaying blocks, it transmits blocks with time which is essentially unrelated to the size of the blocks.
23:26:40gmaxwell:(it's technically linear but with a very small constant)
23:27:17HostFat:do you mean transmitting to other miners or to all nodes?
23:27:21gmaxwell:HostFat: To whatever extent the size/time relation is consequential thats a pressure to centeralize in and of itself, since the more centeralized party isn't harmed by those costs.
23:28:01gmaxwell:HostFat: to anyone interested in recieving them efficiently; though transmitting to other nodes isn't time critical in terms of miners incomes or incentives.
23:29:41HostFat:so there is something that I don't know and/or missing. Can a miner release a 100 MB block all the time and still arrive before miners that release blocks of 1 MB?
23:29:54gmaxwell:HostFat: Yes.
23:30:01HostFat:woha!
23:31:00gmaxwell:HostFat: Almost all (or all, if you just avoid adding very new txn to your blocks) the transactions are already communicated and verified; and don't need to be transmitted again.
23:31:56gmaxwell:HostFat: The block relay protocol just sends a list of two byte indexes to previously communicted txids/txn; technically is possible to build protocols even more efficient than that using set reconcilation; but at two bytes per transaction you can specify all the transactions for a block hundreds of megs in size without a round trip; and its already widely deployed. Future protocols that just sen
23:32:02gmaxwell:d the discrepency between the block and an implied mempool would be even more efficient but because of cpu costs aren't likely a win without really gigantic blocks.
23:33:47gmaxwell:But even if we ignore this, and pretend the block relay protocol didn't exist and wasn't widely used-- go with your original knoweldge: lets say it is proportional. In that world miners could immediately make more income by moving to a bigger pool, which can produce bigger blocks for a given amount of orphaning risk; as the pool will not orphan itself.
23:36:23HostFat:hmm, but smaller pools/miners will still able to arrive to more nodes than the bigger pool, and even if there are two bigger pools, they will compete each other to arrive to the majority of nodes (if we still think that tis relay protocol doesn't exist)
23:37:04HostFat:by making smaller blocks
23:38:15gmaxwell:HostFat: if you imagine it doesn't exist, thats true but you can always increase your competitiveness by either increasing centeralization or decreasing blocksize. And if you are more centeralized than someone else you can use a larger block size (more fee income), meaning that if mining is at an equlibrium you might be making 0.1% more (say) and turning a profit, while the less centeralized min
23:38:21gmaxwell:er is losing money.
23:39:07gmaxwell:Block relay protocol was created to try to mitigate some of that centeralization pressure that was pushing the network to only one or two pools last year-ish.
23:40:11HostFat:so the block relay protocol is enabled for all nodes currently, right?
23:42:01se3000:se3000 has left #bitcoin-wizards
23:42:21gmaxwell:HostFat: it's something you download seperately. I think all major miners use it (they'd be foolish not to!) but there is no way to tell for sure. In any case, since anyone can trivially install it and we know that most of the hashpower uses it, it more or less moots your argument about some kind of market force there. (since the thing you'd do isn't decrease your blocksize, you'd install the blo
23:42:27gmaxwell:ck relay network client)
23:42:32HostFat:ok
23:42:56phantomcircuit:HostFat, it's almost important to note that larger miners can afford significantly more bandwidth than smaller decentralized miners
23:43:13phantomcircuit:to give you an idea i had a 10gbps line pushing blocks out in addition to the relay network
23:43:44phantomcircuit:(even the 10gbps line wasn't enough, to get really good propagation i was proposing 10x that)
23:44:24HostFat:that its true, but I don't see this as a problem, if it spread in a good way to all the nodes, than it's ok.
23:44:41gmaxwell:HostFat: There is another bit to consider there. Technically as a miner your income is optimized if only half the hashrate (including yourself) hears your block quickly; it's preferable that the rest takes a while to hear it (as it increases their orphaning rate).
23:45:16HostFat:the example of the 56k is good explain this I think
23:45:38gmaxwell:I don't believe anyone substantive is acting so strategically now; but if you want to terms about income maximizing behavior and market forces, it's something to consider; esp since the system self adapts towards zero profits. Meaning that it's possible that anyone who doesn't engage in that behavior may end up operating at a loss.
23:47:48HostFat:"it's something you download seperately. I think all major miners use it" so the majority of nodes aren't using it
23:48:06gmaxwell:(and the selfish mining paper argues that the above also means that if a pool mines selfishly they only want it to be heard by a third (themselves included), and if so additional participants will make more if they join their pool vs some other one... e.g. arguing the marginal return on centeralizating instead of the direct effect shifts the threshold to 1/3rd instead of 1/2.)
23:49:25gmaxwell:HostFat: They're not-- but it doesn't matter to miners what non-miners are using for that. (presumably they'll someday use it: it _halves_ the amount of bandwidth staying in sync with the blockchain takes; it just hasn't been a priority to formalize the protocol for use in Bitcoin Core)
23:50:54HostFat:so if there will be the block relay protocol on all the nodes, than it will be more likely a CPU problem than a bandwitch problem, right?
23:52:07gmaxwell:HostFat: accepting a block is neglible CPU, because again, the transactions are almots all (or all if miners delay accepting txn into blocks) already verified and relayed. They don't get verified a second time.
23:53:07gmaxwell:So the only cpu thats technically needed at accept time is verifying the hash agreement. And a boring desktop cpu can do on the order of 24 million sha256() compression calls in a second.
23:54:12gmaxwell:Before all the caching and such some miners had taken to just disabling validation on their nodes. :( (we recently had a problem with a miner with 1-2%-ish of the hashrate running with all signature validation disabled; causing them to mine transactions that were non-standard and had some risk of forking the network)
23:55:04HostFat:so now in this future case (block relay protocol on all the nodes), I'm missing the problem for bigger blocks ...
23:55:33gmaxwell:Presumably because you misunderstood the problem in the first place? :)
23:55:42HostFat:probably :)
23:55:59HostFat:I thought that it was a bandwitch problem
23:56:26gmaxwell:None of this reduces the cost of verifying the network (except by constant factors), it only takes it out of the critical path of accepting a block.
23:56:32HostFat:and by what I'm understanding about the block relay protocol, it seems fixing it
23:56:43HostFat:hmm
23:57:23gmaxwell:It's a one time halving of bandwidth costs, but you still must recive, verify, and potentially store the transactoin data.