18:55:08	orwell.freenode.net:	topic is: This channel is not about Bitcoin today | "Bitcoin research, hardfork wishlist, ideas for the future - see also: https://en.bitcoin.it/wiki/Hardfork_Wishlist https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas. This channel is logged at http://download.wpsoftware.net/bitcoin/wizards/. For questions about the logs talk to andytoshi."
18:55:08	orwell.freenode.net:	Users on #bitcoin-wizards: andytoshi-logbot spinza spinza_ mappum gonedrk adam3us qwertyoruiop wallet42 ghtdak orperelman eristisk bobke coke0 MoALTz nsh jchp Fundraise espes__ LarsLarsen Emcy edulix nOg4nOo davidlatapie WalterA nessence johndriscoll pajarillo shesek DougieBot5000 zack1 burcin Burrito jaekwon mr_burdell Quanttek torsthaldo c0rw1n roconnor_ hearn rdponticelli melvster Krellan_ realz ericp4 george_p TheSeven ebfull drawingthesun a5m0_ emsid ewust
18:55:08	orwell.freenode.net:	Users on #bitcoin-wizards: Eliel quickcoin [Derek] pigeons maaku OneFixt_ digitalmagus gavinandresen tacotime arubi Cory justusranvier Sangheili dexX7 nikitab Luke-Jr shinybro_ jcorgan dsnrk d34th lnovy wumpus andytoshi ageis forrestv mapppum samson_ cajg alferz nickler dansmith_btc asoltys dgenr8 stonecoldpat crescendo Krellan nanotube coyo Alanius Kretchfoop sipa go1111111 gmaxwell Anduck K1773R helo Dyaheon- HM kanzure jaromil zibbo hno` mmozeiko Mikalv kiddouk
18:55:08	orwell.freenode.net:	Users on #bitcoin-wizards: michagogo amiller tromp DoctorBTC stephenreed so kinlo Graet artifexd waxwing stqism gribble mumu warren harrow Fistful_of_Coins coryfields [\\\] zenojis flammit weex EasyAt BlueMatt poggy rs0 phantomcircuit quackgyver lenticulis mhanne otoburb optimator UukGoblin Muis BCB justanotheruser sl01 copumpkin iddo epscy @ChanServ midnightmagic ryan-c keus LaptopZZ_ comboy Logicwax [Tristan] Hunger- lechuga_ petertodd Apocalyptic lianj heakins
18:55:08	orwell.freenode.net:	Users on #bitcoin-wizards: roasbeef
18:55:09	andytoshi:	11:54:36 bash@shavo /store/home/apoelstra# systemctl restart irc-logger
18:58:09	andytoshi:	i think i should just auto-restart it every day, the perl code is somehow awful at detecting disconnections (and it's in the lib code, i don't know how to change it)
19:02:02	nsh:	* nsh nods
19:02:13	nsh:	andytoshi, any PoS write-up material yet?
19:03:09	andytoshi:	nsh: not yet, i've lost a lot of time this week fighting the rust compiler
19:03:41	tromp:	any winner yet?
19:03:46	nsh:	kk
19:06:55	andytoshi:	nsh: i'll type something up now, i'm tired of rust. gimme a couple hours
19:07:12	andytoshi:	tromp: i'm slowly winning as i learn the language. thank god for #rust :P
19:12:20	nsh:	<3
19:12:45	hearn:	andytoshi: how do you find it?
19:13:27	hearn:	andytoshi: i read some article/tutorials about it, but found the memory management mind-numbingly complicated. i couldn't quite convince myself it's worth it outside of specialised domains these days. GC is so much cheaper than it once was.
19:14:04	andytoshi:	hearn: how long ago? it is much more consistent now (just as complicated as ever, but doesn't feel so much)
19:14:31	hearn:	not that long ago. a month or two. i forgot
19:14:48	andytoshi:	ok, it hasn't changed too drastically in that time
19:14:49	hearn:	i mean, memory management in C++ is quite complicated, but rust seemed about 100x worse
19:14:56	hearn:	i like the _idea_
19:15:02	hearn:	but the _reality_ of it left me a little cold
19:15:13	andytoshi:	C++ is more complicated than rust, but gives you absolutely no compiler support
19:15:45	andytoshi:	rust makes lifetime tracking explicit, so it feels more complicated
19:16:02	hearn:	right
19:16:19	hearn:	what kind of app are you writing that you're interested in rust for?
19:16:43	andytoshi:	but you care about that stuff even in C++..ofc there are shortcuts that you can take with your giant human brain and rust can get in the way of that, which is annoying
19:17:19	andytoshi:	but once you understand the compiler's model of lifetimes (which is really not as bad as it first seems) then it is no problem, and gives you a lot more confidence in the correctness of your code
19:17:32	andytoshi:	i'm writing a SPV wallet/node
19:18:05	hearn:	cool!
19:18:34	hearn:	though, i must put on my troll hat here - is the complexity of avoiding GC worth it for this class of app? they are not very heap intensive when using Bloom filtering
19:19:00	andytoshi:	sure, for two reasons..
19:19:30	andytoshi:	1. in addition to preventing the usual gang of memory errors, this lifetime/ownership model is also good for handling data shared across threads and lets the compiler do a lot of static analysis there to prevent races
19:20:06	andytoshi:	i forget the second one, it was a variation on that :)
19:20:17	andytoshi:	i think, 'there are more resources than just memory'
19:21:08	andytoshi:	basically, GC lets you avoid thinking about lifetimes. but you still want to think about ownership if you want your code to be correct
19:21:48	andytoshi:	and rust handles that very carefully. you wind up with much more confidence about what is happening to your objects when you send references to them into black boxes
19:22:44	hearn:	right, ok. good answer.
19:26:25	andytoshi:	it is also good at the things it didn't invent, e.g. i like its object model, its type system, its unit test system, etc., for all that's worth
19:26:38	andytoshi:	i haven't yet explored go so i can't comment on how it compares there
19:30:37	hearn:	i should take a second look. though giving up all the libraries is painful
19:31:53	nsh:	pain is the breaking of the shell that encloses your understanding --gibran
19:32:15	andytoshi:	well, in the last month they changed ~pointer and renamed their string type twice :P. they are planning for 1.0 this year (so probably next year), and the surrounding libraries should start appearing then
19:32:30	andytoshi:	there is a ton of enthusiasm around this project, it's just totally unstable
19:34:01	hearn:	renaming string types twice in one month is impressive
19:35:06	hearn:	yes, well the solution to concurrency in the intro is basically thread affinity for everything
19:35:22	hearn:	which you can do in other languages as well, of course, though the move pointer construct undoubtably makes it easier to enforce
19:36:23	andytoshi:	yeah, it is enforcable at compile-time. if you don't like it you can use other primitives like Arc (atomic refcounting) or Mutex (locking), whose semantics can also be enforced by the compiler
19:37:25	andytoshi:	interestingly, there is also Rc (refcounting) and Gc (garbage collection) if you wanna manage your memory that way
19:40:29	hearn:	right
19:40:31	andytoshi:	so there is a rust runtime (and a way to disable it, losing you most of that stuff), but except for threading you can pretend it doesn't exist
19:41:07	hearn:	i've often thought about alternative threading models for bitcoinj, which is a pretty classical locks and threads type codebase.
19:41:18	hearn:	the problem is the need to be easy to use with gui apps.
19:41:36	hearn:	most principled approaches to concurrency i see these days are all thinking about server side stuff
19:42:20	andytoshi:	i'm gonna try to use rust's no-locks-anywhere for my wallet. right now there are no gui toolkits for rust that keep up with the compiler breaking changes quickly enough, and sans gui it is very straightforward to just use message passing for the network stuff
19:42:47	hearn:	yeah
19:42:49	hearn:	exactly
19:43:01	hearn:	or just run everything in one thread
19:43:06	hearn:	for SPV wallets you don't need big scalability
19:43:11	andytoshi:	oh, this is true
19:43:37	andytoshi:	the point of this project is a base to build wizardly projects, coinjoin, probabilistic payments, custom scripts, etc
19:43:42	andytoshi:	i will put a gui on it, i want this to be usable for normal people with no more than a "you're playing with fire" warning
19:44:47	nsh:	TrueCrypt suggesting migration to BitLocker (sourceforge.net) -- https://news.ycombinator.com/item?id=7812133
19:44:47	hearn:	right. so the problem with guis is the toolkits invariably have thread affinity. having one toolkit with that restriction is awkward. joining two together is horrible. that's why i try to make bitcoinj classicaly thread safe, at least in most places
19:48:22	diesel_:	diesel_ is now known as Dizzle
20:02:59	maaku:	andytoshi: have you considered haskell and haskoin? it's a bit more stable a language with good type safety
20:04:29	nsh:	i don't think manf of the things people imagine rust will fix you'd ever convince people to implement in haskell
20:04:36	andytoshi:	i've tried haskell, i really like it but find it's awkward for ordinary imperative code. rust stole a ton from haskell so i get a lot of the benefit there, with a bigger (and less weird) community
20:04:49	nsh:	*differently weird
20:06:17	maaku:	meh sounds like you just haven't gotten over the functional programming hump
20:06:33	tromp:	i find c awkward for ordinary functional code:-(
20:06:42	andytoshi:	* andytoshi is wounded
20:07:20	andytoshi:	yeah, you might be right. i have taken a lot of ideas from functional programming (make everything pure, everything immutable) but i treat it as a "my code is easier to thing about way" kinda optimization
20:07:21	maaku:	having finally grokked the purely functional way, I find C++ terribly awkward for everything :\
20:08:01	andytoshi:	think about this way*
20:08:39	andytoshi:	i think my big thing with haskell is that i didn't read through to the monad section of 'learn you a haskell', so i'm working with like 10% of the language
20:08:43	Dizzle__:	Dizzle__ is now known as Dizzle
20:08:51	andytoshi:	it's on the todo list
20:08:53	maaku:	didn't mean that as a jab -- it's honestly my experience that for 6+ months working with haskell just doesn't make any lick of sense, as everything seems way harder than it "should" be
20:09:39	andytoshi:	oh, fair enough, i have definitely not made it over that hump
20:09:53	andytoshi:	just went back to my old familiar languages and used .map() and .filter() more :)
20:10:25	jcorgan:	i've tried for years to grok the functional stuff, and still struggle with thinking that way. but--with fine grained concurrency and message passing, a lot of the ugliness of imperative type stuff goes away
20:10:32	hearn:	i always got the feeling that haskell was a bit like java was in the mid-nineties: a grab bag of research ideas, some of which in hindsight proved better than others
20:11:50	maaku:	hearn: i think that would have been true 4-5 years ago. now haskell is definately being refined for production use instead of academic research
20:12:13	hearn:	yeah. i last played with haskell about 7-8 years ago :)
20:12:23	maaku:	e.g. GHC has extended the language considerably to fix its various warts
20:12:52	maaku:	A bit like what C++11 has done
20:13:01	hearn:	well, again, a bit like java. you can fix a lot with lots of good engineering but are the fundamental ideas sound? e.g. i do not know any lazy-by-default languages other than haskell
20:13:06	andytoshi:	oh, i haven't tried it in 4-5 years either
20:13:11	hearn:	seems no modern language designer likes that idea
20:13:45	andytoshi:	though there is a lot of laziness-but-not-by default, e.g. iterators
20:13:59	tromp:	i can't think of any language more fundamentally sound than haskell. it's basically lambda calculus with a ton of syntactic sugar
20:13:59	hearn:	sure
20:14:09	hearn:	optional lazyness is different
20:15:16	maaku:	ah now you are religious war territory
20:15:48	maaku:	i prefer lazy-by-default as it is more expressive by default, but it definately demands more infrastructure (e.g. for proper code profiling)
20:16:54	jcorgan:	heh, the older I get, the more languages I learn, and the fewer I seem to be productive in. :)
20:17:32	maaku:	other than performance, lazy by default only gets weird when you have side effects though. so it' snot a big deal imho
20:21:47	maaku:	anyway andytoshi, i honestly think you should consider it. i love rust but cringe at the idea of building financial apps on something so unstable...
20:22:25	andytoshi:	instability is temporary, i'm certainly not going to release something to the public when the language is in this state
20:23:25	andytoshi:	in principle i am more confident using a language with the kind of strong type (including lifetimes and ownership) guarantees that rust has
20:24:32	maaku:	well it is very likely to get used much earlier than you'd think ... i have a project i would consider using it for in a 6mo timeline
20:29:32	hno`:	hno` is now known as hno
20:30:02	hno:	hno is now known as Guest1195
20:30:54	Guest1195:	Guest1195 is now known as hno
20:38:05	samson:	samson is now known as samson_
22:13:34	ghtdak:	ghtdak has left #bitcoin-wizards
23:20:52	andytoshi:	i have a draft of a PoS article: http://download.wpsoftware.net/bitcoin/pos.pdf it is missing citations but other than that says everything i think i want to
23:20:59	andytoshi:	it's a slog, but i'd appreciate review or comments
23:21:01	andytoshi:	nsh: ^
23:23:22	Eliel:	andytoshi: about haskell and monads, you really should make the effort to understand what they're for. I don't think you can really get what haskell can be without understanding what you can do with monads.
23:24:30	andytoshi:	thx Eliel, i will
23:30:32	justanotheruser:	andytoshi: you should mention stake grinding because nothing at stake attacks are still arguably costly
23:30:57	maaku:	justanotheruser: yes, and that is rather the point as PoS devolves into PoW...
23:31:17	maaku:	should be mentioned if it isn't yet (haven't read it myself)
23:31:18	copumpkin:	+1 on the haskell
23:32:44	andytoshi:	justanotheruser: grep for the word 'grind', i mention it
23:33:17	maaku:	andytoshi: proof reading on page 1, drop the 'm' from $100m, or change the denomination that follows (jumping from $100m to $100 is not an error, but confusing)
23:33:55	andytoshi:	in fact i deliberately mention it before the phrase "costless simulation" because i want to be clear that it's the individual grind iterations that are costless
23:33:55	justanotheruser:	"that opportunity cost was forfeited". Is opportunity cost the right word here? Or is it energy/money?
23:34:37	andytoshi:	oh good call maaku, i spent a while playing with those numbers, i'll change $100m to $1m
23:35:05	andytoshi:	justanotheruser: i mean energy/money, but i want to be more general. i'm not sure if opportunity cost is correct
23:38:24	justanotheruser:	andytoshi: What inaccuracies do you see in this? https://en.bitcoin.it/wiki/Altcoin#Proof_Of_Stake
23:39:02	maaku:	justanotheruser: just fyi, don't trust *anything* on the wiki
23:40:01	justanotheruser:	maaku: Which is why I phrased the question the way I did :)
23:40:26	justanotheruser:	I doesn't mention previous stake owners colluding is one thing
23:42:40	andytoshi:	justanotheruser: doesn't mention peercoin's centralized consensus, gives a wildly impractical example of 'nothing at stake' and suggests that you'd need such a large outlay to do it
23:44:15	andytoshi:	oh, it does point out that peercoin and blackcoin are centralized, but cites NXT's security by obscurity as its saving grace <.<
23:44:22	justanotheruser:	andytoshi: It does mention the centralized consensus. al. Because this attack exists, proof of stake cryptocurrencies including Peercoin[3] and Blackcoin[4] have "master" public keys that control the blockchain
23:44:53	andytoshi:	basically it looks ok, it just suggests that the problems with PoS are ad hoc attacks (and therefore maybe can be evaded with enough clever tricks) rather than requiring solving a very deep problem
23:46:06	justanotheruser:	andytoshi: Doesn't 51% of the forging power need to collude to fork the chain successfully ignoring stake grinding attacks?
23:46:22	justanotheruser:	Or 51% at a certain part of history
23:47:43	andytoshi:	justanotheruser: 51% of the voting power at a certain part, for practical reasons you always only have a tiny fraction of stakeholders actually voting
23:48:24	andytoshi:	but you need to stake-grind to keep control of your fork