02:30:08	bramc:	zooko, anything deterministic can be canonical the trick is finding something which is canonical and can be verified to be canonical quickly, has to be at least parallelizable to check and ideally should be spot checkable.
02:30:40	bramc:	Also it's good for it to be based on AES-128 because that already has fairly good hardware acceleration readily available.
02:37:15	gmaxwell:	PHC seemed to not like "uses AES hardware" as a feature.
02:37:59	phantomcircuit:	PHC ?
02:39:39	gmaxwell:	password hashing competition.
02:40:09	fanquake_:	fanquake_ is now known as fanquake
02:41:33	phantomcircuit:	oh
02:43:00	phantomcircuit:	gmaxwell, something about the round functions not being effective without the setup?
02:43:25	gmaxwell:	to be fair, it was a bit more complicated in that if you didn't use an _entire_ run of AES there is no promise your construction will be compatible with future AES hardware, even for people that have AES hardware.
02:43:59	phantomcircuit:	yeah that
02:44:07	gmaxwell:	and I think many of the 'uses aes hardware' proposals in that space were really "uses one execution of the AES round function" or the like.
02:44:09	phantomcircuit:	the setup step is too expensive for a hash function
02:44:50	Aesthetic:	Aesthetic is now known as Logicwax
02:45:04	gmaxwell:	well you can assume that the hardware will let you setup once and run multiple blocks, but I think these "memory hard" functions really want to do a memory access e.g. per every _round_ and not wait for a whole AES block.
02:48:18	phantomcircuit:	oh yeah
02:49:17	phantomcircuit:	anyways i suspect the round function by itself isn't a great hash function
02:53:40	gmaxwell:	doesn't need to be.
02:55:00	phantomcircuit:	yup
02:58:53	bramc:	gmaxwell, That's consistent with what's bothered me in my own attempts to make a password hashing algorithm
02:59:27	bramc:	I came up with this, which I think is a great general construction but leaves open the question of what to use as the round function: http://bramcohen.com/2014/11/18/a-mode-for-password-hashing
03:07:33	phantomcircuit:	bramc, raw sha256
03:07:45	phantomcircuit:	length extended with csprng output
03:08:07	phantomcircuit:	allows for increasing the "strength" of the hashes without the user entering the password
03:08:09	phantomcircuit:	neat huh
03:11:21	tromp:	bramc: if the custom hardware doing spow is 10 times faster than your avg server, then the latter needs 100mins to fully check the spow. something fishy about a full node needing to trust others to find discrepancies in a timely manner...
03:19:06	bramc:	phantomcircuit, that doesn't introduce unpredictable memory accesses
03:19:55	bramc:	tromp, things can be checked in parallel and, uh, yeah, that part of the protocol is a bit odd.
03:20:18	bramc:	Although a full node can always check everything lazily
03:21:20	bramc:	For the purposes of spow AES's slowness when used to make a hash function isn't an issue because, uh, spows are supposed to be slow. What matters is how fast they are to verify, and the acceleration on the verifying machines helps a lot.
03:22:27	tromp:	but 10mins of spow by fastest hardware imaginable is an insane amount of work for all full nodes to have to check, parallelized or not. i think you really need spow verification to be orders of magnitude cheaper than its computation
03:23:14	bramc:	It is, you spot check
03:23:49	tromp:	full nodes should be more authoritive than presenting a "likely to be correct" picture of the ledger state
03:24:16	bramc:	And peers can tell their peers when a spow is busted, and checking the one part which is reported to be busted is very fast.
03:24:56	bramc:	In bitcoin all you have is a 'likely to be correct' picture of the ledger, it just gets more likely as the amount of stuff at the end increases
03:25:24	bramc:	If somebody accepts a bad spow then their later work will quickly fall behind
03:28:04	bramc:	Although it's hard for someone to wind up on a bad spow, because peers which have different spows for the same pos will notice almost instantly.
03:29:15	bramc:	That's the upside of the spow being canonical
03:30:11	tromp:	that's true; it's easy ti tell which of two different spow proofs is wrong
03:30:20	bramc:	So I came up with a neat trick for making lamport signatures very strongly single use without making them much bigger
03:30:40	bramc:	tromp, or at least which one is right at their first point of divergence
03:31:50	tromp:	what's the neat trick?
03:32:25	bramc:	As you may recall, in lamport signatures there's a merkle root published, and to do a signature you publish a corresponding set of the things leading up to the root
03:34:55	bramc:	My idea for making it strongly one time is to make the number of things revealed rather large, like n-n^.5 of them, so that if two signatures are done they probably collectively reveal everything, but this of course makes the signatures bigger, which leads to the next trick
03:35:49	tromp:	https://en.wikipedia.org/wiki/Lamport_signature doesn't mention the merkle tree except for some variant at the end
03:35:50	phantomcircuit:	bramc, memory hard hash functions are basically silly
03:36:43	phantomcircuit:	a cpu hard hash function is very likely to scale linearly with cores
03:37:02	phantomcircuit:	a memory hard hash function might scale non linearly with reductions in memory latency
03:39:55	bramc:	When generating the things to be preimaged, do it off a seed, where you basically walk down the tree instead of up to go from the seed to the things to be revealed. When doing the reveal, if a whole section of the tree needs to be revealed, you do it by revealing the part of the seed which generated that whole section
03:40:00	bramc:	presto, shorter signatures
03:40:22	bramc:	tromp, in practice you use the hash root as the public key because it's shorter.
03:40:49	bramc:	phantomcircuit, All the work on password hashing functions is on making them memory hard, whether that's a good idea is another matter.
03:41:58	phantomcircuit:	bramc, that's an unfortunate waste of time then
03:42:34	bramc:	phantomcircuit, Well if you assume that it's a good property to have, I came up with a useful construction for doing it.
03:44:37	tromp:	that trick seems to work, but is rather lacking in elegance:(
03:45:20	bsm117532:	Sorry I missed the beginning of the conversation, but I kind of gather there's a deeper motivation than just making a memory-hard PoW?
03:45:32	tromp:	did you read the mahmoody et. al paper on proofs of sequential work?
03:45:48	bsm117532:	and now I know why you guys are spowing.
03:46:56	bramc:	tromp, Yes I've read it and have some big improvements on it, but they aren't canonical and don't wind up being smaller at practical sizes anyway
03:47:51	bsm117532:	Ah bramc you want to use a tree to verify a memory hard function, therefore making it logarithmic in verification time?
03:48:09	bramc:	bsm117532, We're having two interleaved conversations here, one about sequential proofs of work, the other about password hashing functions. That second one we're just discussing for shits and giggles.
03:48:51	bramc:	Oh, and a third interleaved conversation about strongly one-time signatures. This is likely all a bit confusing for those tuning in in the middle.
03:48:58	tromp:	bsm117532: bramc is hoping to replace pw by proof-of-time alternating with proof-of-storage
03:50:10	bsm117532:	Good thing I have a glass of vodka then. Continue, gentlemen. I'll try not to interrupt. Thanks.
03:51:02	bramc:	tromp, What are you abbreviating to 'pw'? I know the concept but not sure the acronym
03:51:17	tromp:	typo; should be PoW instead of pw
03:52:03	bramc:	tromp, and which thing did you mean isn't very elegant?
03:52:45	tromp:	revealing n-n^.5 out of n preimages
03:55:29	tromp:	maybe there is a somewhat simple cheaply verifiable spow waiting to be discovered
03:55:52	bramc:	tromp, oh year the magic numbers are a bit arbitrary, that amount makes it so that about half the time two signatures will literally reveal everything between them, and of course an attacker can easily grind small variations if they're missing only one or two preimages
03:56:24	tromp:	yes, i realize why you chose that n-n^.5
03:57:35	tromp:	which results in having to square your n, which you then compensate for with other tricks
03:58:40	bramc:	tromp, you can improve on the spow in the mahmoody paper by having your spow be done by revealing a hash root of a tree where the leaves are generated by hashing together the already finished branches, then using the root to decide what the challenges for leaf reveals are
03:59:07	bramc:	Problem: totally not canonical, and not terribly efficient at small sizes. Trying to improve on it basically degrades to what I'm using now.
03:59:13	tromp:	unfortunately i have only located but not read that paper:(
03:59:28	tromp:	i'm still making my way through the zerocash paper:)
04:00:01	bramc:	zerocash is no my list of 'that was very interesting but way too crazy to use right now'
04:00:08	bramc:	maybe in, like, 20 years
04:00:22	bramc:	In the meantime nobody's even made a decent change making service.
04:01:47	bsm117532:	In the context of bitcoin, the conversation about new PoW algorithms generally revolves around the flawed assumption that no one could POSSIBLY develop specialized hardware to evaluate my bizarre function.
04:02:41	bsm117532:	bramc: I'm missing the n-sqrt(n) bit. I found http://bramcohen.com/2014/11/18/a-mode-for-password-hashing but you seem to be discussing something else?
04:03:15	tromp:	for cuckoo i'd use PROFITABLY instead of POSSIBLY
04:04:10	bramc:	bsm117532, Yeah this is about making a secure hash based signature which has the property that if you sign more than one thing with it you've well and truly given away the private key
04:04:16	everettForth:	bsm117532: that's not what Evan Duffield says about X11. He says the purpose of X11 is to try to make a PoW algorithm that follows the same path bitcoin did from cpu->gpu->fpga->asic
04:04:40	bsm117532:	new PoW algorithms are boring.
04:04:56	bramc:	tromp, my issue with cuckoo is that although it seems plausible that it can defeat asics, it can't stop the bottleneck from being electricity usage.
04:04:59	bsm117532:	All will follow that path. who cares?
04:05:05	tromp:	no, new hash functions to stick into hashcash are boring
04:05:51	bramc:	cuckoo is an interesting piece of research, unlike X11, which is a shit smoothie.
04:06:22	Luke-Jr:	* Luke-Jr wonders if Cuckoo is interesting enough to add ot BFGMiner
04:06:40	bsm117532:	I'm actually contemplating a system which involves brute-forcing private keys in assymetric encryption as it's PoW.
04:06:57	tromp:	yes, bram, cuckoo reduce electricity use, but not more than an order of magnitude
04:07:00	bsm117532:	I'm concerned about incentivizing the creation of key-cracking hardware...
04:07:09	bramc:	The whole side discussion about password hashing functions is besides the point because password hashing functions are by nature very different beasts. PoW is supposed to be quick to verify, PHF is specifically not.
04:07:25	Luke-Jr:	bsm117532: then you don't have a realistic concern ;)
04:08:03	bramc:	Luke-Jr, the whole point of cuckoo is that it would be extremely painful to put it into something like bfgminer
04:08:26	bsm117532:	If the PoW is brute-forcing private keys, it allows parties to encrypt something with the (known, publicly distributed) public key.
04:08:40	bsm117532:	Which presents interesting ideas.
04:10:06	bramc:	bsm117532, You could do that by truncating the hash of the last block to represent a brute forceable length public key
04:10:25	bsm117532:	exactly
04:10:36	bramc:	Or something like that. That trick is much more clever from a protocol standpoint than everything else we're discussing
04:10:37	bsm117532:	Use the low bits of the last PoW hash...
04:10:49	bramc:	The problem with that is that it can be precomputed and stored in a look up table.
04:11:01	bsm117532:	Salt it.
04:11:19	bsm117532:	(how to to that I haven't worked out...)
04:11:34	bramc:	Salt what?
04:11:39	bsm117532:	exactly.
04:12:09	bsm117532:	OTOH on the assumption of ever-increasing hashing power, rainbow tables aren't much of a concern here.
04:12:57	bsm117532:	So you made a hash table for 4-bit keys? wonderful. The difficulty is now 27 bit keys. Good luck with that.
04:12:59	bramc:	My proposed proof of storage is to find a public key whose hash matches the previous block's hash as closely as possible, by the way, with it being precomputed in a lookup table being the entire point.
04:13:26	bsm117532:	ooh. I have to read then.
04:13:48	Luke-Jr:	bramc: what, it works without anything on the CPU? :P
04:13:51	bsm117532:	bramc: I think I'm missing a link. re-link me the idea?
04:13:51	bramc:	bsm117532, there isn't a good writeup so far, there's some discussion in the bitcoin-wizards logs
04:14:05	bsm117532:	aaaaahhhhhh gum flapping logs suck.
04:14:29	bramc:	Sorry, we also had a meatspace meeting about it yesterday which got fairly deep into the details and I'm iterating
04:14:38	bsm117532:	gotcha
04:14:41	bramc:	hence the lack of good writeup, that 'still iterating' part
04:15:11	bsm117532:	FYI, just moved to NYC, I'm interested in meeting any of you in this space...
04:15:31	bramc:	A bunch of us are in san francisco, no idea if anybody's in nyc
04:15:33	bsm117532:	As in, #wizards, not #dev or #bitcoin.
04:16:12	bramc:	Luke-Jr, that is, of course, the whole point.
04:17:37	everettForth:	What are you trying to do, bramc ? decrease power consumption for PoW?
04:18:41	bramc:	everettForth, trying to make it so the bottleneck on mining is storage used, so the resources going into it will be already extant depreciating hard drive space rather than new electricity.
04:19:46	bsm117532:	PoW is the expenditure of an external, economic resource. I don't think "decreasing power consumption" will lead anywhere because whatever you replace it with will be tied to an external financial resource.
04:19:54	bramc:	Which (a) results in less environmental destruction from mining, and (b) allows a massive security parameter to be set on the whole thing because that unused hard drive space is already out there and this adds no cost to utilizing it for mining
04:20:18	kanzure:	bramc: what's the best argument that the environmental concerns are not fearmongering and/or FUD? a link would be nice.
04:20:22	bramc:	bsm117532, the external resource in this case is unused hard drive space, of which there are mass quantities out there already
04:20:37	everettForth:	bramc: miners will still spend in variable cost roughly the revenue they can generate. If that means buying new storage, they will do it. Also, most of the cost of keeping hard disk storage online is electricity
04:20:57	bramc:	kanzure, it's a straightforward result of the coal burned to make the electricity used for mining
04:21:09	kanzure:	also: the existence of an environment with finite resources should not necessarily cause you to abandon decentralized consensus by proof of work, say in a universe where only proof of work works.
04:21:16	rusty:	bramc: if you're right and successful, why won't this become a botcoin?
04:21:25	kanzure:	oh, well coal concerns aren't real-- everyone knows that terraforming works
04:21:30	bsm117532:	If you could design an algorithm that could transparently use the free space on people's hard drives...that would be pretty awesome. But they're risking premature hardware failure to secure your financial system. It's not costless.
04:21:34	kanzure:	i mean, they aren't real concerns of the type that you should worry about
04:21:58	kanzure:	save your worrying for things that are far less likely to be solvable
04:22:49	kanzure:	also, i don't hear you complaining about the sun burning up hydrogen-- what's with the focus on coal anyway
04:22:57	bsm117532:	everettForth: "most of the cost of keeping hard disk storage online is electricity": only if the access pattern is basically absent. You insert a disk-space hard algorthm that makes your heads seek like mad or your SSD to rewrite like mad, and it will cost you drives.
04:23:00	Taek:	who would be contributing the spare hard drive storage?
04:23:12	bramc:	everettForth, the idea is to engineer out possible variable costs, and for nobody to want to buy hard drives specifically for this purpose because there's so much depreciating space out there that it would be a money losing proposition to specifically buy storage for it
04:23:49	bramc:	Taek, I have a few million users I'm hoping to get interested for starters. But really anyone with spare disk space who would like to mine, including lots of companies
04:24:13	bramc:	rusty, It may well be bot-mined, but lots of companies with enterprise storage setups can do it as well.
04:24:16	Taek:	I don't think it would be financially valuable to anybody with less than a dedicated server full of hard drives
04:24:27	Luke-Jr:	bramc: were* in SF; I've back in FL (and others have left also)
04:24:31	Taek:	but I guess datacenters also have a lot of deprecating hard drives
04:24:42	rusty:	bramc: no, either there's heaps of spare storage capacity out there (=> the bots win), or there isn't (=> centralization)
04:25:13	Taek:	rusty: the bots win == botnets? Or something else?
04:25:14	kanzure:	"the bots win" is centralization too (malware groups defeating one another)
04:25:36	bramc:	everettForth, People might also wind up doing funny things like taking old hard drives which it isn't worth keeping running any more, and setting them up powered down and only power up the one they need for each mining operation.
04:25:41	rusty:	kanzure: indeed.
04:25:47	kanzure:	you can't really control the reasons why people would want to buy hard drives, bramc
04:26:11	bramc:	rusty, there's lots of storage space at places which aren't owned by bots. They're happy to use it if it's no additional costs to them.
04:26:29	bsm117532:	Yeah, anything can be optimized and economies of scale can enter. ANY PoW algorithm WILL be centralized by economies of scale. At the best you've only got economies of scale in electricity, but it still exists, even if you magically invented a CPU-only algorithm.
04:26:39	bramc:	kanzure, All I'm banking on is that there are lots of them already bought and only partially used, and that extra space is gravy
04:26:40	kanzure:	also you have skipped my environment comments
04:26:53	Taek:	I think botnets will be less of a problem than with CPU mining, lots of storage is moving to the cloud
04:26:57	bramc:	kanzure, I'm specifically ignoring your environmental comments
04:27:08	kanzure:	bramc: because?
04:27:19	bsm117532:	bramc: Are you increasing the seeking of "spare" space, and increasing the failure rate of spinning rust?
04:27:23	bramc:	waste is a bad thing, I'm not going to argue the point further
04:27:32	kanzure:	but what if you're wrong?
04:27:38	kanzure:	like what if it actually isn't waste and you're wrong?
04:27:39	bramc:	bsm117532, the amount of seeking is deminimis
04:27:55	bramc:	bitcoin mining is waste
04:28:16	bsm117532:	agreed there. Still looking for something better.
04:28:23	kanzure:	are you the sort of person that claims "all non-reversible computation is waste"?
04:28:24	everettForth:	bramc: why would I want to use up my spare personal computing resources if it doesn't net me very much value?
04:28:33	everettForth:	I guess regular people seed bit torrent files
04:28:58	bramc:	everettForth, it doesn't use up your spare hard drive space, at least not in a way that you notice. It uses up the unallocated sections of your physical media
04:28:59	Taek:	the incentive model is different for bittorrent. People will do silly things for 100GB of imaginary internet credit
04:29:08	Aesthetic:	Aesthetic is now known as Logicwax
04:29:10	Taek:	less valuable if you're looking at is as 25 cents a month
04:29:20	kanzure:	Taek: there's a bit of a reputation game going on for trackers and bittorrent
04:29:23	rusty:	bramc: I don't think you'll find many data centers with lots of idle disk lying around. Your best bet is home users. That's also the botnet operators best bet.
04:30:29	bsm117532:	Personally, I've seen tens of personal spinning rust drives fail, and then try to reconstruct files...I would massively avoid anything that increased the load on my HDD, even if write-only with logarithmic reads (sounds like what you're talking about).
04:31:24	bramc:	rusty, I think the data centers have small amounts proportionately but large amounts in absolute terms. Also if you present me a question of botnets vs. central operations and they're both bad I can't give an option which isn't bad.
04:31:43	Taek:	kanzure: it works very well for bittorent. Reputation is a great motivator, but I don't see how you'd apply the same motivations to a decentralized system.
04:31:56	bramc:	bsm117532, It's a single writing over the whole drive, followed by one seek every few minutes and no writes.
04:32:39	kanzure:	bramc: imagine a world where decentralized consensus absolutely requires proof of work. by your own axiom (bitcoin mining is waste and waste is bad), could you please describe your opinion of decentralized consensus in this totally hypothetical strawman universe?
04:32:53	bsm117532:	Hmmm...
04:33:07	bramc:	Well, one write every few minutes as it gets more of the block chain. It's a lot like any other lightweight server
04:33:16	everettForth:	There's no way I would put something on my computer that taxed resources, even if I was promised it wouldn't affect my usage for the potential reward less than a few dollars per month.
04:33:19	bramc:	kanzure, I've... been describing that
04:33:31	everettForth:	However if it was a hobby, I can see something like setting up a tor node
04:33:54	kanzure:	bramc: i see your statements regarding bitcoin mining being waste, but i don't see if you have speciified whether you think decentralized consenuss should be abandoned if it is necessary
04:34:06	everettForth:	Supporting a network for the sake of trying to keep a service going
04:34:09	kanzure:	whoops i mean i don't see where you specified
04:34:29	bsm117532:	Nothing is costless. Even writing the free space on home computers slightly raises someone's electricity costs.
04:34:41	bramc:	kanzure, I'm saying I've come up with a way of achieving decentralized consensus which leverages existing depreciating resources as the cost rather than new electricity burning as the cost
04:34:49	bramc:	or rather, am in the process of coming up with, still iterating.
04:34:57	kanzure:	that doesn't answer my question :(
04:35:02	kanzure:	and it is wrong of you to pretend it does?
04:35:12	everettForth:	bsm117532: the cost curves are very strange when you look at home users spare usage vs datacenter cost
04:35:14	bramc:	kanzure, Would you like the technical details?
04:35:30	kanzure:	bramc: please read my question again. i could also try to ask it again.
04:35:37	kanzure:	with different words and stuff.
04:36:19	everettForth:	using an extra GB of my drive is not costless, but it's less than what it costs amazon to add another GB of disk
04:36:53	everettForth:	of course, that's assuming I had the drive and computer running anyway
04:37:08	rusty:	bramc: I think you end up centralized anyway. You just hope they repurpose old drives from data centers, rather than buying new ones.
04:37:09	bramc:	kanzure, bitcoin burns a bunch of electricity to achieve decentralized consensus, which is 'waste' if you can achieve the same result without burning the electricity. The electricity burning doesn't add anything to the moral value of the consensus
04:37:11	kanzure:	bramc: (just as a point of clarification, i was not asking whether you claim to have or be working on an attempt at non-wasteful decentralized consensus)
04:37:47	bramc:	rusty, Could be, I don't view that as such a bad thing, it still results in a massive security parameter
04:38:23	bsm117532:	If burning external resources is the value in PoW, why not use burning of BTC? (or other cryptographically-provable resource destruction) Saves the environment.
04:38:43	kanzure:	bsm117532: bitcoin is part of the environment, btw
04:38:50	everettForth:	Just curious, is there a reason why not to consider PoS, PoSV, or Tendermint's approach?
04:39:11	bsm117532:	everettForth: Don't get me started. They're all fucking jokes.
04:39:26	bramc:	rusty, I'm expecting/hoping that the ones mining will be a heterogenous lot, because of the marginal cost of mining being de minimis
04:39:27	bsm117532:	If you really want to talk about that, let's start a private chat and I'll rip them each to shreds.
04:39:59	rusty:	bramc: I don't think that happens, that just leads us to warring botnets mining.
04:40:21	rusty:	bramc: and unlike bitcoin it won't happen slowly, given the tech is now already on the shelf.
04:41:29	bramc:	bsm117532, anything which drives up the price of burned resources will cause more waste, but that's basically the argument for merge mining over starting new cryptocurrencies
04:41:51	kanzure:	where's our physicists argh, they should be showing up any moment to talk about the thermodynamics of reversible computation and how burning works
04:43:01	kanzure:	there's a few steps that i'm missing in the thermodynamics of computation that would be very useful to insert here in this conversation
04:43:12	everettForth:	kanzure: we are many orders of magnitude away from that limit
04:43:16	kanzure:	oh sure
04:43:29	kanzure:	why would you mention that though
04:43:30	bramc:	rusty, Why wouldn't a counterparty mine if they can do it at no additional cost to the capacity they already have sitting around depreciating?
04:44:05	bsm117532:	bramc: I'm all over merge mining.
04:44:39	kanzure:	"The implementation of reversible computing thus amounts to learning how to characterize and control the physical dynamics of mechanisms to carry out desired computational operations so precisely that we can accumulate a negligible total amount of uncertainty regarding the complete physical state of the mechanism, per each logic operation that is performed. In other words, we would need to precisely track the state of the active energy ...
04:44:45	kanzure:	... that is involved in carrying out computational operations within the machine, and design the machine in such a way that the majority of this energy is recovered in an organized form that can be reused for subsequent operations, rather than being permitted to dissipate into the form of heat."
04:44:51	kanzure:	hmm this is a rather preachy wikipedia article
04:45:21	Taek:	bramc: if it's already not worth spinning up the drives and using them in a cloud service like s3, why would it be useful to spin it up for something that would make less money than selling over a cloud service? (maybe lower overhead to participate in your financial network?)
04:45:25	rusty:	bramc: Because google or any cloud operator have more profitable things to do with their hdds. So what's left? Lots of home capacity, and medium businesses.
04:46:04	bramc:	Taek, a lot of unused capacity is already spun up
04:46:09	kanzure:	"Any non-equilibrium physical system (whether a computer or a rock) dissipates energy at some rate, however small, because of the always non-zero probability of interaction between parts of the system (or between a part of the system and a part of its environment) that are at different temperatures, or in different physical states. Even the very atoms in a computer (or a rock) are very slowly dissipating away into its surrounding ...
04:46:15	kanzure:	... environment. Furthermore, no real physical system is ever in absolutely perfect equilibrium, since the only true equilibrium state would be if the entire universe were uniformly filled with a gas of elementary particles that was neither expanding or contracting, but such a state is unstable in general relativity, even with a nonzero cosmological constant. An equilibrium scenario is not a possible future state of our universe."
04:46:27	bramc:	rusty, there's always unused capacity at any given moment, even for an efficiently run operation
04:46:54	Taek:	oh, that makes sense
04:47:02	everettForth:	yes kanzure x86 cpus are many orders of magnitude away from entropy due to bits being erased being a significant part of the energy usage
04:47:24	rusty:	bramc: sure, but they keep it as low as possible. There's more fat in smaller operations, which feeds your "many small players" scenario. And also, botnets.
04:47:28	bramc:	kanzure, reversible computing is decades out if ever, and the costs to the stuff I'm talking about for mining, while technically not zero, is very close to it
04:47:46	bramc:	rusty, Undoubtedly botnets will participate
04:48:05	kanzure:	no, your concerns were waste, not cost :(
04:49:09	rusty:	bramc: if there are enough warring botnets, at least that will add to your network security :)
04:49:34	bramc:	kanzure, sunk costs are costs too
04:49:58	everettForth:	kanzure: cost is directly proportional to waste when talking about computing resources
04:53:29	bramc:	tromp, even though n-n^.5 requires squaring n, it doesn't result in that much of an increase in the signature size, thanks to my new trick. It mostly winds up undoing some compression tricks, one of which gets you a factor of 2 and the other of which, winternitz compression, gets you a lot more at the expense of lots of cpu
04:58:12	kanzure:	i am still considering "The electricity burning doesn't add anything to the moral value of the consensus" might take me a while to cook on this on
04:58:15	kanzure:	*on this one
04:59:16	kanzure:	if decentralized consensus doesn't work at all and is completely broken, then it is very easy to argue that mining is definitely waste
04:59:26	kanzure:	but the other scenarios are more difficult to figure out
05:00:03	Taek:	also you could pretty easily argue that mining is a waste if there was some magical way to get superlinear security on your input resources.
05:01:06	kanzure:	i am not deep enough into maaku's headspace to argue that one at the moment haha
05:06:01	kanzure:	alright here's some relevant reversible scifi since i'm gonna sleep now On the last night of the world, the gods decreed for themselves a revel, a final masquerade in which they took on their long-discarded human forms and spent themselves in orgiastic and drunken festivity. It was a wake for spacetime itself.
05:06:06	kanzure:	The numbers of the gods had dwindled through the long middle age of the Universe. Each was a vast and unique information structure, grown from a merely human seed. Augmented and elaborated first in magnitude and then in kind, each became a god, a single mind as complex as a civilization or an entire ecosystem, with instrumentality capable of manipulating individual molecules or entire galaxies. A wave of transformation had spread out ...
05:06:12	kanzure:	... from the birth-world of the gods, a phase-change that swept through all space-time and transformed it to the liking of the gods. Their capabilities were bounded only by the limits of what was possible.
05:06:16	kanzure:	whoops
05:06:19	kanzure:	http://heybryan.org/docs/The%20Masque%20of%20the%20Heat%20Death%20-%20David%20Krieger.html
05:08:15	kanzure:	(i think asimov also had a reversible computation pro-negentropy thing too?) /sleep
05:23:55	PRab_:	PRab_ is now known as PRab
06:32:57	fanquake_:	fanquake_ is now known as fanquake
07:14:19	contrapumpkin:	contrapumpkin is now known as copumpkin
07:26:05	fanquake_:	fanquake_ is now known as fanquake
07:37:46	fanquake:	fanquake has left #bitcoin-wizards
07:56:37	lclc_bnc:	lclc_bnc is now known as lclc
09:05:13	cameron.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:13	cameron.freenode.net:	Users on #bitcoin-wizards: andy-logbot rusty fanquake orperelman koeppelmann adam3us1 SDCDev Pan0ram1x copumpkin hktud0 p15 PRab justanotheruser NewLiberty [7] siraj_ prodatalab bsm117532 OneFixt d1ggy_ wizkid057 koshii_ PaulCapestany hashtag xabbix nuke1989 grandmaster binaryatrocity Adlai hollandais Adrian_G hashtag_ GAit devrandom arubi waxwing Dr-G alawson Iriez delll__ oujh lechuga_ [d__d] cornus_ammonis jaekwon shesek null_radix GreenIsMyPepper coiner bosma
09:05:13	cameron.freenode.net:	Users on #bitcoin-wizards: antgreen Emcy_ ebfull elevatio1 starsoccer ryanxcharles grubles dignork Krellan Starduster_ flower btcdrak kinlo Cory droark jessepollak ahmed_ Luke-Jr luny Graet ryan-c s1w Eliel veox amiller warptangent indolering huseby tromp K1773R TD-Linux LarsLarsen go1111111 airbreather iddo midnightmagic leakypat maaku mariorz CryptOprah sdaftuar_ Apocalyptic tromp_ coryfields Xzibit17 platinuum artifexd epscy_ Muis kumavis dasource guruvan cluckj
09:05:13	cameron.freenode.net:	Users on #bitcoin-wizards: spinza Anduck bedeho brad__ gmaxwell burcin dansmith_btc paperbot dc17523be3 sipa melvster fenn espes__ dgenr8 jbenet Oizopower mappum harrow Visheate a5m0 sneak crescendo Taek eric livegnik asoltys_ pigeons catlasshrugged kanzure heath JonTitor ajweiss smooth BananaLotus petertodd bbrittain Keefe cfields jaromil Fistful_of_Coins jcorgan optimator gribble warren dardasaba fluffypony bobke_ sl01 phantomcircuit nickler wumpus BrainOverfl0w isis
09:05:13	cameron.freenode.net:	Users on #bitcoin-wizards: gwillen roasbeef stonecoldpat phedny so hguux__ otoburb lclc qwopqwop Meeh gnusha_ gavinandresen cryptowest morcos MRL-Relay azariah berndj HM2 btc___ catcow NikolaiToryzin helo andytoshi throughnothing @ChanServ brand0 BlueMatt yrashk PFate cursive michagogo Alanius wiz davout Hunger- NeatBasis tripleslash mr_burdell bliljerk101 DoctorBTC nsh nanotube weex_ d9b4bef9 deego MoALTz forrestv yoleaux comboy Zouppen SubCreative
10:30:25	lclc:	lclc is now known as lclc_bnc
12:26:23	fanquake_:	fanquake_ is now known as fanquake
13:02:20	fanquake_:	fanquake_ is now known as fanquake
14:02:32	lclc_bnc:	lclc_bnc is now known as lclc
15:19:25	kanzure:	"The ledger is openly viewable by all, so no PoR audits are necessary" big mistake
15:38:08	nsh:	PoR? proof-of-[revenue?]
15:38:40	nsh:	retriveability?
15:39:05	kanzure:	reserves, i think
15:40:39	nsh:	ah
15:40:49	nsh:	yeah, that's bad logic
17:31:27	lclc:	lclc is now known as lclc_bnc
17:32:32	adam3us:	i think proof of reserve is slightly limited in the sense that its good to see real time status but you can also watch in slo-mo as someone steals the hot-wallet. visibility but still lose your money.
17:34:59	kanzure:	yes but they were saying have a list of addresses and outputs instead
17:35:16	kanzure:	which tells you nothing about whether the corresponding private keys are known
17:35:54	adam3us:	yes improvement over that or nothing for sure
17:39:19	dabura667:	https://gist.github.com/dabura667/875bb2c159b219c18885
17:39:54	dabura667:	I tried to make it legible. Sorry English is not my forte.
17:40:08	kanzure:	.title
17:40:09	dabura667:	Anyone with comments please let me know, I'd appreciate it.
17:40:09	yoleaux:	A proposal for an improved HD wallet generation algorithm
17:40:32	Luke-Jr:	improved how?
17:40:36	dabura667:	Title: A proposal for an improved HD wallet generation algorithm
17:41:01	sipa:	dabura667: there was a talk at FC15 about to extend the bip32 derivation to an arbitrary (but fixed) number of leaks
17:41:42	dabura667:	sipa: if you set it to tolerate 1 leak, you can use convention to prevent the attack.
17:42:49	dabura667:	Anywho, my propsal gets into some specifics.
17:43:47	dabura667:	I have already received feedback from sipa before on the attack method with 2 leaked keys. Now I am just hammering down the details and would appreciate any criticism or help.
17:45:48	sipa:	dabura667: read the fc15 paper, it gives a generic construction for an arbitrary number of leaks
17:46:33	sipa:	http://fc15.ifca.ai/preproceedings/paper_15.pdf
17:47:16	dabura667:	thx
17:55:23	dabura667:	my proposal tolerates unlimited key leaks as long as rules are followed. So instead of having a 700 byte xprv for a 20 department company, 2 keys (A and B) are all that is needed in the extended keys.
17:56:24	dabura667:	maybe my dirty proposal is not worthy of disproving, but I think it is sound. I will start coding an implementation soon to test it out in python.
17:57:36	sipa:	coding it will not teach you how it can be broken
17:57:57	dabura667:	yes I am aware.
18:10:21	lclc_bnc:	lclc_bnc is now known as lclc
18:26:16	stonecoldpat:	dabura667: all reasonably written proposals that are interesting in my books are worthy of being disproven ;)
18:27:22	nsh:	unfortunately, this tends towards attrition of the limited time of people capable of disproving things
18:27:35	nsh:	which for any given proposal might often be better spent elsewhere
18:32:26	stonecoldpat:	nsh: thats true, i mentioned the disclaimer "interesting" for that reason :)
18:33:09	nsh:	* nsh nods
18:33:46	nsh:	the problem is that the number of ways to not quite achieve interesting properties >> interesting properties
18:33:49	nsh:	sadly :)
19:48:28	lclc:	lclc is now known as lclc_bnc
21:41:22	Adlai:	kanzure: (i think asimov also had a reversible computation pro-negentropy thing too?) << maybe http://www.multivax.com/last_question.html ?
21:44:09	kanzure:	possibly.
21:44:46	nsh:	so did the vedas...
21:44:52	nsh:	nothing is new under the sun
22:30:11	gmaxwell:	I thought about mentioning the last question but it didn't quite match and you didn't ask for the most sublime piece of short science fiction ever authored, and so I figured that wasn't what you were asking for.
22:30:45	Adlai:	dunno, Feeling of Power comes close in my ranking
22:31:14	Adlai:	http://downlode.org/Etext/power.html (also asimov)
22:32:10	nsh:	* nsh smiles
22:32:32	gmaxwell:	Asimov himself said that TLQ was his favorite :)
22:32:34	nsh:	feeling of power gave me much more of an impulse than the end of the last question
22:32:53	nsh:	but they're complementary anyway
22:33:11	nsh:	i think TLQ is a bit more bellygudfeels
22:33:41	nsh:	oh wait, i was conflating feeling of power with another story even
22:33:45	nsh:	the one about jokes
22:35:03	nsh:	(jokester)
22:35:31	nsh:	the reveal in that is a kind of conceptual hitchcock zoom
22:35:43	Adlai:	nsh: haven't read this one yet, thanq
22:35:49	nsh:	enjoy :)
23:56:28	zooko```:	zooko``` is now known as zooko