01:00:49	nOgAnOo:	nOgAnOo is now known as n0gAn0o
01:01:31	n0gAn0o:	n0gAn0o is now known as nOgAnOo
08:29:17	phantomcircuit:	gmaxwell, blargh
08:29:42	gmaxwell:	hm?
08:30:05	phantomcircuit:	somehow my $HOME was wiped out
08:30:13	phantomcircuit:	cant figure out how
08:32:55	gmaxwell:	rm -Rf $HOME ... damn, keys are right next to each other
08:33:01	wumpus:	probably some script with an over-eager rm -rf, what is the last thing you did?
08:33:16	phantomcircuit:	mathematica install
08:33:28	phantomcircuit:	wumpus, that's my best guess also
08:33:47	phantomcircuit:	im thinking something in it's cleanup was using a variable with rm -rf and the variable didn't get set
08:34:03	phantomcircuit:	from now on mathematica gets installed in it's own vm >.>
08:34:45	phantomcircuit:	but i cant see how that's possible
08:44:34	phantomcircuit:	wumpus, the weird thing is /home/phantomcircuit the directory was still there
08:44:52	phantomcircuit:	but /home/phantomicrcuit/.config etc were gone
08:44:56	wumpus:	your user cannote remove that directory
08:45:07	phantomcircuit:	oh
08:45:08	phantomcircuit:	right
08:45:36	phantomcircuit:	yeah must have been the mathematica install script
08:45:38	phantomcircuit:	that's unfortunate
08:45:54	wumpus:	also are your files in /tmp and such gone? if so, it was probably running a rm -rf / as you
08:46:18	phantomcircuit:	system was rebooted since then
08:46:21	phantomcircuit:	so i have no idea
08:46:31	wumpus:	pretty unfortunate, btw why are you still here instead of doing forensics (or are your backups that good?)
08:47:17	phantomcircuit:	backups are pretty good
08:47:20	wumpus:	depending on the fs it is possible to restore deleted files, but only if you act immediately
08:47:21	wumpus:	ok
08:47:23	phantomcircuit:	it's a vm with snapshots
08:47:46	phantomcircuit:	it's ext4 there's basically no way to recover except to pick around at individual files
08:48:03	phantomcircuit:	silly thing zeros the inode when you delete a file
10:48:41	edulix_:	edulix_ is now known as Edulix
12:57:02	qwertyoruiop:	qwertyoruiop is now known as tjk9357
13:20:25	tjk9357:	tjk9357 is now known as qwertyoruiop
17:08:30	andytosh1:	andytosh1 is now known as andytoshi
19:07:06	sipa:	roconnor: maybe here :)
19:07:20	roconnor:	ok
19:07:42	sipa:	what properties an ideal PoW should have... there's much debate
19:08:25	sipa:	some like to make it favor general-purpose hardware over specially-designed ones (or at least try to limit the advantages custom hardware can have)... which, even if possible, encourages botnets
19:08:45	sipa:	an assumption was that making it memory-bound would have this property
19:09:27	sipa:	but gmaxwell argued that heath dissipation actually becomes the limiting factor, rather than memory bandwidth (correct me if i'm wrong), so there is still much to gain from that
19:10:02	sipa:	other things that have been proposed are PoW functions which mimick bitcoin validation as much as possible, proving as a miner that you have fast access to the UTXO set for example
19:10:23	sipa:	*heat
19:12:01	maaku:	*gmaxwell argued, and experience with 1st gen scrypt ASICs showed
19:13:07	roconnor:	sipa: Is the suggestion that POW should be designed to increase heat output?
19:13:17	tromp__:	memory bound does not imply heat
19:14:09	sipa:	roconnor: the assumption was that a memory-bound hash function would lead to optimal implementations using general-purpose memory chips
19:14:25	sipa:	roconnor: so custom-designed hardware wouldn't be able to improve things much
19:14:47	sipa:	roconnor: turns out that this is not correct, because the limiting factor is not memory throughput, but the cost of heat dissipation
19:15:21	tromp__:	how does memory-latency-bound computation generate much heat?
19:15:26	roconnor:	isn't the theoretical limit for heat use independent of the hashing function?
19:15:49	roconnor:	though perhaps bringing theoretical limits for heat use is inappropriate now.
19:16:06	sipa:	gmaxwell or maaku can probably comment better than i can
19:17:49	pigeons:	specialized hardware can gain efficiency due to better heat dissipation than commodity hardware, overcoming the purpose of making the function memory hard to keep away specialized hardware that is more efficient
19:17:55	maaku:	* maaku wonders if it possible to construct a p2sh script which puts a bounty on ECDSA malleability
19:18:03	gmaxwell:	not just heat dissapation instantly, but in the total cost of operating a computing infrastructure fabricated on modern process, if your compute job spans more than a month or so, power costs dominate your operation.
19:18:52	tromp__:	gmaxwell: i disagree, for a latency bound pow
19:18:57	gmaxwell:	So in terms of talking about commodity vs specialized hardware advantage, if you have something which reduces the total energy used on the commodity hardware, it may actually have provided less strength.
19:19:47	gmaxwell:	tromp__: I know you do, and you've not substantiated this position except to repeat it. We now have an existance proof that the 'scrypt' mining asics have more cost advantage over cpus than sha256 ones did.
19:20:48	tromp__:	i've subvstantiated that cuckoo cycle spends 5% on hshing and 95% on memory latency, whether single threaded or dozen-threaded
19:21:07	gmaxwell:	tromp__: yes, and the point there is thats bad.
19:21:09	michagogo|cloud:	maaku: Like the hash collision bounties?
19:21:37	gmaxwell:	hardware costs are amortized by reuse.
19:22:01	michagogo|cloud:	maaku: Seems to me you'd need to first eliminate all non-ECDSA malleability (non-DER encoding, etc) on a protocol rule level, not just IsStandard
19:22:20	gmaxwell:	I'm not going to waste my time arguing this with you right now. I suggested you take a crack at writing up a complete cost analysis, including operating costs.
19:22:49	sipa:	michagogo|cloud: https://gist.github.com/sipa/8907691
19:23:04	michagogo|cloud:	sipa: Yeah, I saw your gist
19:23:22	michagogo|cloud:	* michagogo|cloud checks if it's changed since he last saw it
19:23:55	sipa:	i updated it yesterday
19:24:22	michagogo|cloud:	7 revisions?
19:24:28	michagogo|cloud:	I think it was at 3 when I saw it
19:25:00	sipa:	it's just tiny changes, semantically
19:25:09	sipa:	there's 7th new rule now
19:25:54	maaku:	michagogo|cloud: yeah i think it'd be trivially doable if sipa's hard-fork were implemented
19:26:00	maaku:	*soft-fork
19:26:06	michagogo|cloud:	maaku: Right, but that's a prerequisite
19:26:06	maaku:	sipa: thanks for adding #7
19:26:41	maaku:	michagogo|cloud: I was thinking it might be doable with SUBSTR & CONCAT, but that's even more a moot point ;)
19:26:45	tromp__:	gmaxwell: i dont yet have the required data for a detailed cost analysis. i have to determine the limits of cpu and gpu multithreading first. i'm hopeful though that a cuckoo data center can run with passive cooling only.
19:27:38	maaku:	tromp__: the point is the goal you are optimizing for is actually really bad for the health of the network, and does not achieve what you purport to want
19:27:43	michagogo|cloud:	Heh, I'd never considered a script using OP_CHECKSIG without providing a pubkey or the hash of one
19:27:56	maaku:	but this has been argued here a hundred times, and like gmaxwell we all have better things to do than rehash it
19:28:39	sipa:	all except #1 and #3 could be added as IsStandard rules right now, i think
19:28:54	sipa:	#2 and #5 already are
19:29:36	michagogo|cloud:	sipa: Why except #1 and #3?
19:29:41	michagogo|cloud:	* michagogo|cloud thinks
19:30:14	sipa:	#1 would mean pretty much 50-80% of transactions created by non-bitcoind/bitcoinj wallets become non-standard
19:30:20	sipa:	#3 kills some script functionality
19:30:25	gmaxwell:	maaku: well I'm unsure if it can achieve what it proports to want. I consider it unclear right now. I have some evidence that it doesn't.
19:30:42	michagogo|cloud:	Oh, I see
19:30:48	gmaxwell:	sipa: oh is bitcoinj using low-s already?
19:31:02	sipa:	gmaxwell: not sure if any release does, but i hear mike implemented it
19:31:04	michagogo|cloud:	So it's not that they couldn't, just that doing so would have bad effects
19:31:25	michagogo|cloud:	(because people are routinely not doing that)
19:31:39	michagogo|cloud:	s/at/ose/
19:31:43	sipa:	#4 already exists as an IsStandard rule too
19:32:02	sipa:	but we could add #6 and #7 now
19:38:20	michagogo|cloud:	Heh, apparently there's a marketplace for trading "Real BTC" and "Gox BTC"
19:41:05	RBRubicon:	not just apparently
19:43:53	maaku:	sipa: does #3 kill any script funcationality we care about?
19:44:14	maaku:	*which isn't blockchain spam
19:45:01	sipa:	maybe
19:45:06	sipa:	i believe there are some potential cases
19:45:43	gmaxwell:	reason to make the network rule a switch on the transaction.
19:46:58	sipa:	of course no problem making #3 an isstandard rule, as there currently is no standard transaction type that requires it
22:36:34	amincd:	we had a problem a while ago with people encoding messages in the Bitcoin blockchain using dust transactions. and it was solved by creating a minimum transaction value for txs that nodes will relay. I was wondering if the following alternative solution would work: relaying dust transactions (txs with below a threshold value) if the pay to address is a public key + a signature of the bitcoin address that the public address ha
22:37:43	gmaxwell:	no, you can can just embed data via the signature that way— plus, it makes you reveal the public key, which is unfortunate.
22:38:01	gmaxwell:	not to mention it would make the addresses huge.
22:38:17	gmaxwell:	though thats somewhat analogous to the P2SH^2 thing I suggested.
22:39:39	amincd:	from what I understood, the P2SH^2 is not a protocol rule, in that nodes wouldn't be required to follow it. I'd be concerned that malicious nodes/miners would include them in blocks
22:40:01	amincd:	^ would include transactions that don't follow the convention
22:40:05	gmaxwell:	amincd: it could be a protocol rule no less than what you suggest.
22:40:17	gmaxwell:	and again, if the signature is actually in the transaction you can encode data in it.
22:40:41	gmaxwell:	e.g. adopt a convention that K=1 the 'data' is your private key, now recover the data from the signature.
22:41:14	gmaxwell:	Alternatively you could use my self-certifying hashes, but they double the size of the hash, and probably take ~1ms to verify.
22:44:47	amincd:	what I suggested could be made into a protocol rule, rather than a convention, through a hard fork, but if it's possible encode messages in the signature, then it's DOA. I haven't heard read about the self-certifying hashes, I'll read up on it
22:46:14	amincd:	is the self-certifying hashes the P2SH^2 proposal or something different?
22:46:44	sipa:	something else
22:46:47	gmaxwell:	what I suggested could also be, and again, what you suggested still allows the covert channel.
22:47:21	gmaxwell:	Self-certifying hash is P = G*data, P2=to_point(H(P)), hash (what you put in the tx) = {P,P2*data}. To verify, compute P2 and check that P,P2,hash is a DH tuple by using pairing to solve the decisional Diffie-Hellman problem: pairing(G,hash) == pairing(P,P2)
22:50:38	amincd:	gmaxwell: if the P2SH^2 were made into a protocol rule, wouldn't the inner hash have to be included in the blockchain?
22:51:24	gmaxwell:	amincd: no, because a protocol rule could apply differently to non-burried blocks than it does to burried ones.
22:52:16	gmaxwell:	and — YET AGAIN— if you actually embed the data into the transaction so you can verify it on burried blocks (with either what you suggested or P2SH^2) you _do not eliminate the high bandwidth side-channel_.
23:10:08	amincd:	If the protocol rule is that non-buried blocks are treated differently than buried blocks, is that a form of 'cementing', and would that create issues with network splits, where some part of the network is disconnected from the rest for a long period of time?
23:14:44	tromp__:	tromp__ has left #bitcoin-wizards
23:14:57	gmaxwell:	nah, because the criteria can just be how many blocks exist on top of it. So it can be objectively performed the same by all nodes.
23:15:26	amincd:	thanks for the food for thought, I'll think on all this
23:17:36	gmaxwell:	this isn't to say I like it. I don't like any of these solutions _that_ much. SC-hash is cryptographically speculative (but a well tested construct for other purposes, which could only fail safe) and slow. P2SH^2 is a partial solution because you could still temporarily relay data.
23:18:18	gmaxwell:	Probably moving the entire transaction into zero knoweldge is the only way to really eliminate substantial side channels, and small side channels (e.g. like 8 bits per scriptsig) can never be eliminated.
23:43:32	roidster:	roidster is now known as Guest6827