00:59:39	maaku:	maaku is now known as Guest66151
05:05:04	lecook:	man vitalik made a huge payday
05:09:29	justanotheruser:	for nothing working :O
05:11:50	lecook:	whoah whoah the ethereum people are under the impression it is
05:12:04	lecook:	proof of concepts get you millions
05:12:12	lecook:	even though people don't understand it.
05:12:38	justanotheruser:	To my understanding they have a testnet running with sha3 PoW
05:13:40	lecook:	and they are planning on launching next quarter
05:14:18	justanotheruser:	oh, "in two weeks" X 6 then?
05:15:10	lecook:	in my opinion ethereum has the potential to surpass bitcoin
05:15:45	lecook:	in the end marketing always wins.
05:16:41	Luke-Jr:	lol
05:17:22	justanotheruser:	lecook: dogecoin is a counterexample of that
05:17:48	lecook:	dogecoin is pure marketing, we are talking about competent developers + marketing here
05:17:52	justanotheruser:	ethereum marketers may be able to convince you that marketing always wins though :)
05:18:13	lecook:	vitalik is a marketing genius. i'm gonna start writing too.
05:18:14	justanotheruser:	lecook: I don't care about competent developers if their product doesn't do anything bitcoin can't do
05:21:53	Luke-Jr:	give it time
05:22:01	Luke-Jr:	people will go back to Bitcoin after the Nth exploit
05:29:18	wumpus:	people are always arguing that their specific altcoin will do well because of marketing, but there are so many of them, it goes up against a rabble of marketeers driving people crazy and possible away from cryptocurrencies completely...
05:29:47	gmaxwell:	wumpus: yes, that concerns me greatly. Also the self defeating infighting.
05:30:07	wumpus:	it's like walking through a street and all shopkeepers try to violently make you enter their shop, the next time you'd avoid the street completely
05:30:16	gmaxwell:	If you were to setup a strategy to undermine cryptocurrency you could hardly do better than to create a bunch of infighting.
05:30:18	lecook:	https://github.com/orisi/wiki/wiki/Orisi-White-Paper this is a very interesting project on top of ethereum
05:30:45	gmaxwell:	lecook: it's on top of bitcoin...
05:30:47	dgenr8:	ethereum, bah. i'm waiting for taligent, if not that, transmeta
05:31:12	lecook:	ah yes sorry, wrote it w/o thinking lol
05:31:16	gmaxwell:	(and it's an example of why ethereum isn't all that interestin)
05:31:20	gmaxwell:	er interesting.
05:31:53	gmaxwell:	lecook: as much as I love cool script capabilities we have a ton which are almost never used in bitcoin. This complicates selling having even more of them.
05:31:57	wumpus:	gmaxwell: right; too many people doing their own thing, fighting others instead of working together
05:32:38	gmaxwell:	(I suspect there are opcodes where I'm the only person whos ever used them in a transaction… (and if not me then petertodd))
05:32:57	lecook:	i think it's about 100 opcodes?
05:33:35	wumpus:	woohoo, your own opcode :)
05:33:44	gmaxwell:	OP_GMAXWELL what would OP_GMAXWELL do?
05:34:59	wumpus:	that's hard to describe without a phd in math :)
05:35:45	jcorgan:	OP_GMAXWELL: six novel cryptographic constructs per minute, requiring hours of reading obscure papers to understand <= "proof of hard work"
05:37:19	gmaxwell:	One issue is, I think, that testnet seems to not be successful. There seems to be a gap where if a cryptocurrency is worthless it's too boring to mess with, but if its too valuable it becomes too valuable to toy around with.
05:37:36	copumpkin:	OP_GMAXWELL goes and makes up a new opcode on the fly and binary patches it into your bitcoin executable
05:39:49	gmaxwell:	I'm not sure how to span that gap. Perhaps if running multiple parallel daemons were easier, and you could just set some switch to always run testnet too.. Or perhaps if testnet coins has some specific kind of value, like you could redeem them for postcards from developers.
05:40:10	wumpus:	gmaxwell: that's true, there is little in the way to experiment with new ideas without creating an altcoin, and if testnet was valuable it'd be an altcoin
05:41:03	gmaxwell:	unused cryptocurrencies are really just kinda boring, even a lot of the altcoins are failures in this respect (E.g. litterally just three or four nodes on the network— a mining pool or two and an exchange or two)
05:41:42	wumpus:	it's a binary proposition, either your chains coins are worthless in any amount, or they are valuable in some amount, in which case it's a speculation target
05:42:54	gmaxwell:	right ... being worthless isn't so much a problem, except that when they're worthless no one will do anything with them, so they're boring.
05:43:32	jcorgan:	we could make testnet coins redeemable for core developer trading cards
05:44:17	gmaxwell:	yea, thats along the lines of what I was thinking... useful in a way that makes them worthy to play with but not in a way that makes them good for speculation.
05:46:36	dgenr8:	today's bitcoin valuation will look less than miniscule someday
05:48:54	gmaxwell:	hm? no. bitcoin is already too valuable for experimentation. (thus my speculation on there being opcodes only I've used) Which is probably fine since expirementation on the main network might trigger some third parties bugs... but sadly testnet is too worthless. We seem to have nothing in-between. But this might be just due to a genuine shortage of people actually interested in expirementing.
05:49:54	Emcy:	a moderately valued alt?
05:49:56	[nsh]:	interest can be courted
05:50:31	gmaxwell:	Emcy: no, then it just gets speculated on. once the value is non-zero its large if only you acquire enough of it. :)
05:50:31	[nsh]:	at the very least, someone should be handing out lab-coats, goggles and bunson-burners in a controlled environment with knowledgeable supervisors present
05:51:07	gmaxwell:	well I've thought of in the past requiring making a testnet transaction to get +v in here, and setting the channel to require it to speak.
05:51:19	Emcy:	i thought for a minute we could have thrown the dogecoin people a bone
05:51:38	[nsh]:	gmaxwell, that's not so bad an idea
05:52:16	[nsh]:	it pays to think about the ladder of engagement
05:52:31	gmaxwell:	Emcy: demonstratibly those things have not become hotbeds of expirementation, even though the varrious ltc forks are now (thanks to warren's efforts) based off a new enough code base to do interetsing things.
05:52:39	jcorgan:	does getting a testnet faucet to send coins to you count? :)
05:53:15	Emcy:	hm
05:53:27	gwillen:	jcorgan: nah, require an outgoing non-IsStandard testnet transaction ;-)
05:53:35	gwillen:	(and require that it be successfully redeemed)
05:53:35	Emcy:	is there any scrypt fork that has sensible scrypt parameters
05:54:14	gmaxwell:	But there are some people who like puzzles and would dig in and some people who wouldn't bother.
05:54:31	gmaxwell:	And they're not necessarily less good or useful folks because they're in the latter group.
05:54:38	gwillen:	I suppose that's fair
05:54:52	gwillen:	writing a testnet transaction is not that large of a puzzle though
05:55:01	gwillen:	for someone who wants to be a bitcoin wizard
05:55:58	lecook:	i do my tests on the main net is this good?
05:56:53	gmaxwell:	gwillen: yea, well my thought would be some bot that you have to send it some coins with a funny script that also encodes a return key for you, and it returns them with a novel puzzle script which you must satisify. Then after doing that you can just use that key to authenticate with an irc bot.
05:57:07	gwillen:	ahhh, nice
05:57:49	dgenr8:	if bitcoin totally stagnates feature-wise, eventually it will get eclipsed by something
05:57:55	gmaxwell:	but at the moment its actually rather difficult to create a custom signature that has an actual ecdsa sig too.
05:58:44	gmaxwell:	dgenr8: I'm not sure if you're referring to the discussion here, but I think a bigger concern is getting people to actually huge a huge amount of latent functionality which is already part of the bitcoin system
05:59:25	dgenr8:	quite agreed. just saying, not experimenting at all is also dangerous
06:00:18	gmaxwell:	I think I wasted an embarassingly long hour or two authoring 54fabd73f1d20c980a0686bf0035078e07f69c58437e4d586fb29aa0bee9814f (mainnet) due to making some stupid mistakes.
06:00:44	gmaxwell:	(knowing what I needed to do was trivial, actually computing the correct hash for the signature was not)
06:02:04	lecook:	nice address gmax
06:05:13	gmaxwell:	lecook: meh, vanity address are pretty bad for the ecosystem. I created it mostly to brag about the gratitious waste of computing power, though amusingly it was a long time before anyone noticed how long a prefix it was.
06:05:56	gmaxwell:	I don't even want to think about the current value of the bitcoin I didn't mine while I was computing that. :P
06:08:20	dgenr8:	* dgenr8 goes to look up OP_1NEGATE
06:08:53	gmaxwell:	you should look at the scriptpubkey that its spending.
06:10:05	lecook:	are there any faster alternatives to bitmessage?
06:10:31	lecook:	to my understanding tor is completely pwned.
06:10:55	gmaxwell:	bitmessage and tor are pretty orthorgonal (actually you should only ever use bitmessage over tor)
06:11:20	lecook:	i really don't like the 2 minute lag. :/
06:12:21	gmaxwell:	lecook: it's more like email than IM.
06:12:26	dgenr8:	ah its just a trivial OP_DUP 0 OP_LESSTHAN OP_VERIFY OP_ABS 1 16 OP_WITHIN OP_TOALTSTACK 0378d43027
06:13:34	gmaxwell:	yea knowing how to satisify it was trivial. a little less trivial to actually do so because you have to compute a signature too. (the private key is some well know 'brainwallet' string, but using a compressed key)
06:14:24	dgenr8:	lol I was kidding......
06:14:36	wumpus:	lecook: what do you mean pwned? any low-latency anonymizing network can be subjected to timing attacks, so your requirement of 'faster' is likely in conflict with what you want
06:14:46	gmaxwell:	dgenr8: well work through it, its no so hard. :)
06:15:29	lecook:	do you guys think the talk withdrawn on blackhat on tor was fud?
06:16:26	gmaxwell:	lecook: no, go see the post on tor dev about it. Basically it sounds like they had a technique that makes timing attacks more effective, it's since fixed in the latest tor... but ultimately the upper bound on tor's privacy is fairly weak due to tor being realtime.
06:16:56	gmaxwell:	(The tor project is very upfront about this limitation— but if you're not real time it's hard to get users, and any anonymity system's privacy is also bounded by the size of its userbase)
06:16:56	wumpus:	like in every software project, bugs in tor gets found and fixed in it all the time
06:18:24	gmaxwell:	the ideal thing to do is build non-realtime systems and run them over tor and you get both bigger userbases to hide in and better privacy. This is what pond does, and bitmessage can optionally run over tor.
06:19:10	jcorgan:	i thought i read somewhere the idea that Tor could also offer a second option to have a random-delay service, and use that traffic to help obscure the near-realtime traffic
06:19:26	jcorgan:	heh, it must have here
06:19:34	jcorgan:	been here
06:19:55	wumpus:	that could have been here, it would be a nice thing to have in tor, though a service over tor could also work
06:20:43	lecook:	well my userbase will only contain 1000-10 000 nodes at most not that big.
06:21:23	gmaxwell:	jcorgan: I've mentioned it, Roger (@tor) co-authored a paper on it: http://freehaven.net/anonbib/cache/alpha-mixing:pet2006.pdf
06:21:49	jcorgan:	OP_GMAXWELL
06:23:19	gmaxwell:	there are a lot of challenges though— e.g. resisting dos attacks. Once you start doing non-trivial storage for people you need a way to prevent attackers from flooding out the storage.
06:23:32	Emcy:	im still shocked tor is NOT using some sort of random delay thing already, i asumed it was
06:24:29	wumpus:	well the major use of tor today is web browsing, so there's an inherent and obvious conflict there
06:24:58	gmaxwell:	Emcy: if you're adding delays you start to make things unusable... and small random delays aren't really enough to prevent timing analysis. (Esp confirmation attacks)
06:25:00	Emcy:	browing on tor is already probably 10x slower than normal
06:25:13	Emcy:	and if people go tot he traouble of downloading TBB in the first place
06:26:14	wumpus:	exactly, there is already a lot of latency added, adding more latency per hop will make it worse and possibly unusable
06:26:37	gmaxwell:	Emcy: hm? I think it might depend on the stuff you use, it's not that hugely slow most of the time.
06:26:47	wumpus:	at least for web browsing. many other applications wouldn't care, so it could be something that is configurable...
06:27:02	gmaxwell:	(but indeed, it is already at least somewhat slow)
06:27:25	Emcy:	gmaxwell wouldnt a delay of a few tens or >100 ms at each hop be enough to obsfusicate you in with the rest of the packet flow, since tor has decent thruput now
06:27:39	gmaxwell:	absolutely not
06:27:55	wumpus:	the download speeds are pretty ok these days, but it can add quite some latency
06:28:17	gmaxwell:	Emcy: e.g. in a confirmation attack I'd just block your whole connection for 1 second at a time and count the arrival at the other end.
06:28:29	[nsh]:	it's more "emailing webpages to yourself" RMS-style before the low-latency risk goes away
06:28:42	Emcy:	oh yes you mentioned that before
06:29:04	Emcy:	but still that takes away the passive attacking capability
06:29:15	Emcy:	dropping your flow for seconds is noticable
06:29:15	gmaxwell:	reading offline is actually pretty nice, I wish the web had more facilities for that.
06:29:26	wumpus:	[nsh]: yes - you'd have to set up a queue of information to fetch, wait, and then come back later to read it... a very different paradigm than web browsers
06:29:36	[nsh]:	tighy
06:29:59	[nsh]:	*right, but not an unworkable one, if better supported, as gmaxwell says
06:30:00	gmaxwell:	Emcy: in any case, every user you lose from tor means a smaller anonymity set. Consider the bomb threat assclown at .. harvard? last year... identified him because he was the only person on campus using tor around the time in question.
06:30:19	[nsh]:	(one of a handful)
06:30:25	Emcy:	thats a good point
06:31:20	gmaxwell:	anyways the alpha mix paper describes how you can reasonably have both in one network.
06:32:30	Emcy:	perhaps tor could be best used as a substrate for the real countermeasures, for those that require it
06:32:57	Emcy:	there has to be a way of comprehensively defeating even the GPA
06:33:21	Emcy:	it must be a CS research issue
06:34:21	gmaxwell:	research really isn't the problem.. there are a lot of ideas... but making good implementations is hard, as you can see with all the attacks on tor they need to do a lot of work just to keep the basic functionality secure.
06:34:41	Emcy:	yea
06:34:49	Emcy:	but thats flattering in a way
07:41:32	maaku:	maaku is now known as Guest16810
09:54:52	gmaxwell:	[Semi-OT, since it's less of an issue for crypto than some other fields] https://www.openaccessbutton.org/ basically a bookmarklet that helps you find alternative sources when you hit a paywall, and also logs the event to generate figures for people to use in talking about the impact of paywalls.
10:07:57	Emcy:	is that news or things like journals
10:08:23	Emcy:	welp if i clicked it first id see its journals
11:16:52	sl01:	would be interested to hear your thoughts on section 3 of the tezos paper (http://tezos.com/position_paper.pdf), it discusses why they chose proof of stake, basically they use checkpoints and/or statistics (what fraction of coins moved on a given fork) to prevent very long chain forks, and slasher style punishment to prevent short forks
11:18:34	Luke-Jr:	sl01: this is not ##altcoin-dev where crazy ideas flourish, it is #bitcoin-wizards, where Bitcoin people discuss serious practical ideas.
11:18:41	sl01:	they make the argument that nothing is perfect (bitcoin PoW) and that PoS can be made to work in practice
11:18:50	sl01:	Luke-Jr: yea but that paper was posted here, and given props by some wizards
11:18:59	sl01:	otherwise I wouldn't have mentioned it
11:19:37	Luke-Jr:	sl01: your mention was the first link to it here.
11:19:54	Luke-Jr:	or mention of tezos for that matter
11:21:05	sl01:	pretty sure zooko posted it here, as well as on his twitter
11:22:25	sl01:	maybe it was only on his twitter :[
11:26:15	sipa:	Luke-Jr: i'd say it is on topic here
11:27:02	sipa:	doesn't mean it's a good idea
11:30:10	Quanttek_:	Quanttek_ is now known as Quanttek
11:56:30	jgarzik:	jgarzik is now known as home_jg
12:13:58	dsnrk:	ugh. I decided to write a tool to find address reuse.
12:14:03	dsnrk:	wishing I hadn't.
12:18:39	hearn:	find address reuse? it's not hard to find
12:19:15	dsnrk:	naturally, but I wasn't aware it happened so much.
12:20:49	dsnrk:	last block has 420 transactions, 91 transactions spent change back on themselves.
12:22:33	dsnrk:	sorry, 119 transactions re-used, of those 91 keys were unique.
12:30:47	hearn:	sounds like bitcoinj is popular :-)
12:30:57	hearn:	though i think blockchain.info might do that too, i didn't use it for a long time
12:31:29	hearn:	it'd be nice if there was a graph of that somewhere. i've got a couple more patches to go and then I think we can start releasing the new HD bitcoinj that doesn't reuse addresses anymore
12:31:37	hearn:	it'd be cool to see some graph line go down over the following months
12:31:46	dsnrk:	it's mainly blockchain.info transactions.
12:32:13	dsnrk:	you can tell them apart by scraping against blockchain.info.
12:32:56	hearn:	yes, well, world domination isn't quite possible yet :)
12:33:01	hearn:	(for me)
12:33:25	hearn:	i'm hoping once multibit HD releases then we can start to make some more inroads against blockchain.info transactions
12:33:36	hearn:	though i think we'll need a wallet with a whole other level of polish to get people away from web wallets
12:34:17	dsnrk:	blockchain.info's wallet is pretty shit, it just has momentum.
12:34:44	dsnrk:	people don't realise how much address reuse is biting them in the ass, which is unfortunate.
12:34:52	hearn:	i've put quite a bit of work into spiffing up lighthouse. ok it's not a "regular" wallet but most of the graphics code can be reused to make one
12:35:09	hearn:	well, i think people often do realise, but the alternatives are worse
12:35:24	dsnrk:	no, they don't.
12:35:51	dsnrk:	"you know blockchian.info wallets have no privacy right?" "that's fine I used Shared Coin to get it back"
12:36:09	hearn:	alright. let me put it this way. i realise, but i still use wallets that reuse addresses, because i trust my ability to reliably make backups less than i value extra privacy.
12:36:11	hearn:	(for now)
12:36:27	hearn:	ah yes well coinjoin is an idea that holds far more fascination than it really should imo
12:36:29	hearn:	perhaps it's the new web of trust
12:36:45	dsnrk:	shared coin is NOT coinjoin.
12:37:08	dsnrk:	in any way, shape of form.
12:38:14	dsnrk:	Shared Coin is an expensive, totally worthless service that in no way resembles a coinjoin.
12:38:18	hearn:	heh
12:38:39	hearn:	but regular end users don't see it that way ..... they see big messy transactions and think "privacy solved!"
12:39:05	dsnrk:	I taught a reddit user how to deanonymise shared coin transactions.
12:39:27	dsnrk:	just gave them the general idea, and they exposed my example transaction in a couple of minutes.
12:40:04	dsnrk:	if anything it gives you even worse privacy because it paints a big "I WANT TO KEEP THIS SECRET" on your transaction.
12:44:29	dsnrk:	hearn: I think above all, people don't know that multibit and bc.i reuse addresses, and they don't know this is an issue for their privacy.
12:44:58	hearn:	that could be true. the new "choose your wallet" page on bitcoin.org should help with this
12:45:30	hearn:	although i just noticed there's a "source code" button, wtf
12:46:13	dsnrk:	I can't even compile multibit. I tried, but yeah, java.
12:49:00	wumpus:	is it supposed to flip when you move the mouse over the page? it gives me a headache
12:49:20	hearn:	compiling java apps is about a billion times easier than most native apps i've tried, although iirc multibit is a pain because it relies on a fork of bitcoinj that you have to fetch and install first.
12:49:26	hearn:	most wallets don't
12:49:37	hearn:	and multibit HD is a rewrite which also doesn't, i think
12:49:52	wumpus:	I also failed to compile multibit (then again, I probably gave up too soon)
12:50:08	dsnrk:	native apps can be a lot easier.
12:50:23	wumpus:	well it's not that it's difficult but I don't know all the tools for java building
12:50:24	dsnrk:	git clone https://github.com/bit-c/bitc.git; cd bitc; make
12:50:57	dsnrk:	yes I wager that's probably the problem for me too.
12:51:17	hearn:	dsnrk: it lists four dependencies there
12:51:30	wumpus:	I'm fairly sure building native apps is harder, especially for platforms that are not first class
12:51:47	hearn:	wumpus: there are only two ones in wise usage really, maven and gradle. both of them use the same network repository protocol so the differences boil down to the config syntax and command line tools.
12:52:26	hearn:	maven uses a fairly verbose form of XML, but i found it to be quite fast. gradle uses a scripting language and the build files are much, much simpler and cleaner in most cases, but gradle itself seems to be quite slow for mysterious reasons.
12:52:41	dsnrk:	hearn: I suppose. all the sort of thing most people would have anyway though.
12:52:43	hearn:	for both of them you just run the main command they download and install all needed libraries recursively
12:53:24	wumpus:	hearn: that's good at least
12:53:29	hearn:	also the source tree layouts are standardised and they figure out build rules and such automatically, so once set up you mostly can leave the build system alone, which is nice
12:53:48	dsnrk:	bit-c would be a really sweet client to use if it just had a little more polish.
12:53:50	hearn:	they also know how to auto-discover unit tests and run them, generate coverage reports, etc. they're quite impressive really.
12:54:14	hearn:	you get a lot of functionality for free. and they're cross platform. anyway.
12:55:25	wumpus:	dsnrk: yes, would be great if someone took over maintenance
12:56:14	dsnrk:	I've patched the worst of the weird stuff, but I don't know enough crypto to be sure what I write is safe
12:58:28	hearn:	weird stuff?
12:59:21	dsnrk:	logs are a bit verbose sometimes, testnet mode is broken
12:59:44	dsnrk:	in the public master you can enable testnet mode but the address version bytes are wrong
13:04:22	hearn:	that's pretty basic
13:07:16	wumpus:	I'm sure you can't have made many crypto mistakes with that
13:27:35	dsnrk:	I know, but I would like a HD version of it.
13:27:47	dsnrk:	that's where I would end up nuking Other People's Money
13:33:55	Alanius_:	Alanius_ is now known as Alanius
13:44:20	hearn:	dsnrk: what do you like about bit-c the most?
13:44:28	hearn:	the fact that it's written in c? the ncurses ui?
13:45:36	dsnrk:	hearn: it's lightweight, it's in c, and the ncurses UI is pretty. checks all of the boxes in that regard.
13:48:08	hearn:	why is being written in C a benefit? surely that just opens the possibility of security holes
13:50:33	sipa:	before i actually started writing things in c++ (but even after beware aware of the language features), i would have chosen c for anything, anyday
13:51:00	sipa:	(over c++, not for every conceivable software obviously)
13:51:16	sipa:	s/beware/being/
13:51:23	sipa:	c++ is just scary if you're familiar with it
13:51:32	sipa:	*not
13:52:02	hearn:	i'm quite familiar with c++ and it scares me rigid. though frankly even working in java scares me, so maybe i'm just a scaredycat :)
13:52:13	hearn:	c++ is a lot safer than c for sure, but still quite dangerous
13:52:20	dsnrk:	for me at least, I understand what's going on in C
13:52:57	sipa:	yup; in c++, even though perfectly controllable, things happen without you being aware of it
13:53:02	hearn:	do you? think about all the ways the compiler is allowed to exploit undefined behaviour
13:53:04	sipa:	copying, destructors, ...
13:53:13	hearn:	i'm not sure i'd ever say for sure i know what a C program is doing once compiled
13:53:42	hearn:	too many ways to accidentally do something that violates some obscure part of the spec and have gcc decide to cleverly remove e.g. security checks
13:53:49	sipa:	i like c++ for being able to abstract things like memory management away, so i don't need to care about it
13:54:02	sipa:	i dislike c++ for it abstracting things away that i should be aware of :)
13:54:07	wumpus:	C is nice for low-level work, such as codecs and drivers, but as soon as you start working with strings, having std::string is very nice
13:54:13	sipa:	and RAII
13:54:24	wumpus:	or indeed, anything that is dynamically allocated
13:54:39	sipa:	I'd love C with structs that have destructors...
13:54:51	hearn:	well, you can use C++ that way
13:55:30	hearn:	but C++ only partly abstracts memory management. i have too many memories of my team at google losing a week because someone introduced an mm-related race condition into some component of gmail
13:55:44	hearn:	and then we'd have to try and figure out what the hell was going wrong when one server out of a thousand crashes a few days a day
13:56:11	hearn:	it's mostly safe until you need to start doing things that are unsafe, which eventually you always do
13:56:45	wumpus:	c++ is absolutely a dangerous language, and very easy to shoot yourself in the foot
13:57:33	hearn:	the other day i was asking the kotlin team to make all integer math checked. it looks like overflow free integer programming might be feasible on the latest jvms, though i need to find good benchmarks and try it
13:58:01	wumpus:	now that would be great
13:58:05	hearn:	we just need to systematically crush entire bug classes out of existence to keep scaling software to more important and more complex tasks
13:58:35	hearn:	apparently hotspot compiles Math.addExact() and friends down to just "add" + "jo" opcodes on modern jvms and CPUs. so with branch prediction it might actually be free
13:58:47	hearn:	or close enough to free that it makes no odds
13:58:56	hearn:	of course to invert the default you'd need some way to bring back unsafe math
13:59:25	hearn:	apples new Swift language has &+ &- &* etc opcodes to do unchecked maths. the rest of the time it's always overflow checked
13:59:34	wumpus:	sure, for crypto and bitwise operations you need to be explicitly specify that rolling over is allowed
13:59:50	wumpus:	be able to*
13:59:55	wumpus:	but it is an exception rather than the rule
14:00:20	sipa:	just have int32_t and int_mod2pow32_t
14:00:31	sipa:	the former has overflow checking, the latter hasn't :)
14:00:39	wumpus:	right
16:02:24	fanquake:	fanquake has left #bitcoin-wizards