02:07:52	kanzure:	(nothing new, but nothing bad) "This issue could totally be fixed by adding something to the Bitcoin protocol where a transaction can specify what chain it is on, and it would be invalid for miners to include the transaction on any other chain. (For example, the transaction could include the hash of a previous block inside it.) Since we don't have that feature, it is pretty difficult for me to treat the bitcoin I own on both forks ...
02:07:58	kanzure:	... independently."
02:10:31	phantomcircuit:	kanzure, wat
02:11:16	kanzure:	an opcode that checks for a blockhash in history is not very wat
02:11:40	phantomcircuit:	kanzure, how about, why?
02:12:59	kanzure:	see spendonlyafterblockhash http://gnusha.org/bitcoin-wizards/2014-12-23.log
02:13:15	gmaxwell:	kanzure: hm. you've now given me an argument against the transaction checkpoints.
02:13:48	gmaxwell:	it's undesirable to be able, e.g. I feed you a fork where I've paid you, secure in the comfort that the transaction won't show up on another chain.
02:14:46	kanzure:	oh right there's probably some sort of collective prisoner's dillema game theory stuff going on there if everyone is only giving out anti-reorg transactions or something
02:15:00	kanzure:	and presumably reorg-compatible transactions would be more "expensive" heh
02:15:06	kanzure:	expensive for the receiver.. er..
02:15:29	kanzure:	i mean: you would have trouble convincing people to give you a more regular type of transaction
02:17:58	kanzure:	i'm not sure what you mean by fork feeding, why would the rest of the network care about your fork blockset?
02:19:04	kanzure:	also you could possibly just make it a rule that your transaction checkpoints or spendonlyafter[blockhash] must have a certain minimum blockheight difference like 500 or something
02:22:13	kragen:	hi, I heard people were talking about IPFS?
02:22:19	kanzure:	hello kragen, if you wait long enough you can also bug zooko
02:22:31	kanzure:	no, i'm sorry, i didn't intend to mislead you about that (my message was unrelated to IPFS)
02:22:58	kragen:	oh
02:23:01	kragen:	kragen has left #bitcoin-wizards
02:40:25	justanotheruser:	Sorry if this has been covered, but when there are two top blocks, don't miners have an incentive to try to come to consensus on which one is "more correct"? If the network mined on top of the lower hash block between the two then the odds of another set of competing blocks and a two block reorg would be lower. If a pool just goes by which block it got first then the network would be more evenly split between the two ...
02:40:31	justanotheruser:	... blocks, maybe 60% would be on fork A and 40% on fork B. If you go by the lower hash, presumably only the miner who made the higher hash block would end up mining it on top of it while the rest would be mining the lower hash block to avoid a fork.
02:43:43	justanotheruser:	One problem I can see is that if there is a block that is just below the target, the "difficulty" may only be 5% higher to try to get that block out. Maybe that can be fixed with miners considering the lowness of the hash, but also how long it took for the block to get to them after the first.
03:54:56	op_mul:	the "lowness" of the hash is quite irrelevant, what matters is that they hit the target.
03:55:34	justanotheruser:	op_mul: Not sure what you mean? I am discussing a possible consensus improvement, not how it works now.
03:55:55	op_mul:	a chain is evaluated by the cumulative target difficulties, not the cumulative "achieved" difficulties.
03:56:11	justanotheruser:	I know
03:56:17	justanotheruser:	please read what I wrote again
03:58:50	op_mul:	the bit about how long a block took to get to the miner doesn't really make sense in context, the block timestamps are never correct, and doing it like that would give an incentive to warp backwards.
03:59:02	op_mul:	oh you weren't talking about that.
03:59:17	op_mul:	sorry, I'll shut up.
04:00:31	justanotheruser:	yeah, I'm just thinking there is a better way to select which fork to mine on top of when they both have the same height other than which you got first
04:02:41	op_mul:	I'm not sure you'd actually one block at the same height after another anyway
04:03:34	justanotheruser:	?
04:03:40	justanotheruser:	could you rephrase that
04:04:43	op_mul:	I can't remember how the client deals with seeing the headers of two blocks at the same height.
04:05:10	justanotheruser:	I think it only cares about the first one
04:05:22	phantomcircuit:	op_mul, if they're both the tip then first seen wins
04:05:38	op_mul:	yes, but you don't even download the alt block do you?
04:06:04	phantomcircuit:	bitcoin core entirely ignored the other block
04:06:07	phantomcircuit:	ignores*
04:54:59	dgenr8:	justanotheruser: that has the undesirable property that the lower has could be seen quite a while after the first block at given height
04:55:06	dgenr8:	*hash
05:05:21	justanotheruser:	dgenr8: why is that a problem?
05:05:53	justanotheruser:	dgenr8: you already have an incentive to mine on top of the top block.
05:06:40	dgenr8:	justanotheruser: only because he needs to switch what he is wokringon, afaik
05:13:01	justanotheruser:	I'm not sure what your argument is
05:13:59	dgenr8:	it's just a minor amount of housekeeping for the software. the other problem you pointed out seems significant though. whole new fork-off vector
05:15:25	justanotheruser:	Right now miners minimize the risk of a large reorg by mining on the block they think most other people are mining on. This is done by accepting the first propogated block usually. This is imperfect and I am proposing that by accounting for the time the block was sent to you and the lowness of the hash, you may have a better chance of choosing the block the majority of the network is working on (assuming the also follow ...
05:15:31	justanotheruser:	... the low hash rule)
05:16:18	dgenr8:	yeah i think i got it. let's see the actual formula ;)
05:18:59	justanotheruser:	mine on the block with the lowest tslb * hash^(1/N) where N is some variable that is optomized for this purpose. A high N means that the hash won't matter at all most the time, a low N means that an attacker may try to create a fork since his hash being a bit lower means people will mine his fork.
05:24:47	dgenr8:	that's close to what I thought you were considering ... i thought it might be luckiness^something. your 60/40 scenario doesn't represent a very common case btw...
05:25:51	op_mul:	it's hard to get stats about how often stale blocks even happen
05:28:30	op_mul:	miners like the antminer don't even bother submitting a result if it thinks it's a stale
05:29:57	phantomcircuit:	op_mul, that's silly
05:30:40	op_mul:	yep. messes with p2pool because a stale p2pool share could be a valid block, and the antminer just throws it out.
05:32:18	op_mul:	I'm sure other hardware does that too
05:32:26	phantomcircuit:	the pool software i wrote even tries to submit stale shares to the network
05:32:35	phantomcircuit:	there's virtually no reason not to push them upstream
05:44:14	op_mul:	phantomcircuit: have you ever won with that?
05:44:42	op_mul:	phantomcircuit: oh, and extending on that, how many blocks have you solved that were DOA?
05:46:03	phantomcircuit:	op_mul, we never won with that but we did get 2 1 vs 1 races
05:46:05	phantomcircuit:	lost both
05:46:37	phantomcircuit:	total orphan rate is ~1.5% which is mostly blocks that were stale when received
05:48:06	op_mul:	phantomcircuit: thank you. my farm was all so far down in the noise that I never got good stats.
05:48:55	op_mul:	(0% orphans, though!)
05:49:04	phantomcircuit:	ha
05:49:38	gmaxwell:	justanotheruser: the next block is the consensus on this one; using lowness leads to a profitable withholding attack.
05:50:12	gmaxwell:	justanotheruser: where you a rationally incented to conceal your block from others when it had a low value that made it likely to be successful in a race even if announced later.
05:53:16	justanotheruser:	gmaxwell: I don't think the hash should weigh in very much. If someone releases a lower hash block 1 minute later then it shouldn't be considered in most cases.
05:54:11	justanotheruser:	But when the times are really close, like 10 seconds then the hash might be a useful tool for getting most of the hashpower on the same fork and prevent a 2 block reorg.
05:54:55	gmaxwell:	justanotheruser: you can remove the attack by making it not matter; yes. is it possible that there is some amount of use which is safe? maybe but if you've made it mostly ignore it in the process what actual thing did you hope to gain except making the software more complex? Especially when it seems to already be unmanagably complex?
05:55:30	gmaxwell:	justanotheruser: if they were 10 seconds apart they would have already agreed.
05:55:36	justanotheruser:	The gain would be less >1 block reorgs
05:55:45	gmaxwell:	(90pct propagation is under that time)
05:56:33	gmaxwell:	justanotheruser: I'm not actually sure that it would.
05:58:56	justanotheruser:	If more people are mining the same top block I would at least expect that
05:59:55	gmaxwell:	actually what you're describing doesn't close the attack.
06:00:37	gmaxwell:	I mine, if I get a winner, I do not announce, and I try to mine the next one. if someone announces, then I announce. I win as your hurestic still applies as I'm only a second behind.
06:01:02	dgenr8:	gmaxwell: withholder might get surprised by what other withholders show up to the party with... but not a good milieu to be sure
06:01:36	gmaxwell:	dgenr8: you know based on your numbers how likely that is and can optimize income.
06:02:11	justanotheruser:	I'm not sure what you mean. The times are based on the time you receive the block, not the timestamp.
06:02:28	justanotheruser:	Withholding will continue to cause your withheld block to not be mined on
06:02:36	gmaxwell:	justanotheruser: please read what I described again.
06:02:41	gmaxwell:	justanotheruser: no, it doesn't.
06:02:56	gmaxwell:	You'll be mining on it all along; and everyone else will be when you announce it.
06:03:33	justanotheruser:	okay, I see what you're saying. This will make withholding profitable when you get a low hash value block.
06:03:48	justanotheruser:	Basically everytime I get a low hash value block I might as well withhold.
06:03:53	gmaxwell:	yes
06:09:27	op_mul:	op_mul is now known as q16
06:48:14	q16:	q16 is now known as op_mul
07:23:06	lclc_bnc:	lclc_bnc is now known as lclc
08:02:54	[\\\]:	[\\\] is now known as completejerk
08:03:07	completejerk:	completejerk is now known as [\\\]
08:37:06	SDCDev:	SDCDev is now known as Rynomster
09:05:18	hitchcock.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:18	hitchcock.freenode.net:	Users on #bitcoin-wizards: andy-logbot adam3us fanquake soundx wiz damethos Rynomster paveljanik contrapumpkin benten waxwing bendavenport TheSeven DoctorBTC pgokeeffe d1ggy_ nick1234abcd__ Dr-G3 PaulCapestany execut3 bosma Emcy justanotheruser Graftec SubCreative adlai dgenr8 Starduster gribble Burrito samson_ atgreen mkarrer fluffypony bbrittain jbenet grandmaster jaekwon_ ryanxcharles spinza austeritysucks wumpus Guest62409 iddo HarusameNyanko delll irc88
09:05:18	hitchcock.freenode.net:	Users on #bitcoin-wizards: Fistful_of_Coins thrasher` Shiftos yoleaux butters Tjopper PRab NikolaiToryzin nsh epscy wizkid057 luny tacotime nuke1989 mortale catlasshrugged op_mul maaku cluckj Hunger- hashtagg kyletorpey ebfull Greed Iriez ajweiss BlueMatt mbelshe Graet dansmith_btc midnightmagic starsoccer huseby Grishnakh Luke-Jr BrainOverfl0w burcin [d__d] gavinandresen danneu catcow TD-Linux ryan-c smooth Alanius AdrianG tromp pigeons Dyaheon- Cory livegnik
09:05:18	hitchcock.freenode.net:	Users on #bitcoin-wizards: MRL-Relay pi07r sadgit throughnothing lechuga_ poggy JonTitor hollandais amiller LarsLarsen Muis kumavis michagogo artifexd lnovy cfields btc__ rasengan hguux_ Meeh yrashk a5m0 jgarzik Keefe berndj morcos Logicwax stonecoldpat sl01 optimator null_radix roasbeef_ hktud0 BigBitz [\\\] mappum gnusha otoburb mr_burdell s1w go1111111 HM2 Apocalyptic sdaftuar btcdrak CryptOprah jcorgan forrestv tromp_ lclc harrow @gmaxwell isis brand0 eric Krellan
09:05:18	hitchcock.freenode.net:	Users on #bitcoin-wizards: @ChanServ jaromil petertodd helo v3Rve espes__ nickler ahmed_ warren fenn phantomcircuit kanzure bobke BananaLotus coryfields Anduck Eliel nanotube gwillen heath EasyAt asoltys_ K1773R comboy andytoshi warptangent Guest38445 phedny so crescendo Taek @sipa sneak azariah kinlo
10:52:54	Rynomster:	Rynomster is now known as SDCDev
12:53:18	lclc:	lclc is now known as lclc_bnc
13:13:37	d1ggy_:	d1ggy_ is now known as d1ggy
14:22:21	atgreen:	I just hacked moxiebox to optionally record basic block counts for use with gprof: http://ur1.ca/jevjn
14:22:40	atgreen:	emitting call graph info should be easy as well. I'll submit patch tonight.
14:46:44	wumpus:	atgreen: nice!
14:59:43	nsh:	atgreen
15:04:07	lclc_bnc:	lclc_bnc is now known as lclc
17:38:39	lclc:	lclc is now known as lclc_bnc
19:07:39	kanzure:	seems dangerous to ask exchanges to rely on a third party for listunspents
19:11:25	justanotheruser:	welll, do you trust the third party the exchange is trusting with your money? Because they can pretty easily take it if they aren't verifying the utxo themselves :P
19:11:27	kanzure:	and the transactin seems to be created by the remote server essentially
19:11:42	kanzure:	https://medium.com/@bendavenport/no-sleep-till-multi-sig-7db367998bc7
19:11:57	kanzure:	bendavenport: they were okay with this?
19:15:05	kanzure:	justanotheruser: yeah, that's my understanding..
19:15:40	kanzure:	*transaction
19:33:02	kanzure:	justanotheruser: i suppose one possible defense is if the change address is not a value returned by the api.
20:04:43	kanzure:	hmm https://github.com/BitGo/BitGoJS/blob/3b72ab19f6620f4ab11c21ab7e326de020f4d340/src/wallet.js#L73
20:06:53	kanzure:	so the attack is: return one very large unspent for listunspents from the remote api, return hack custom change address, will receive everything 'cept whatever the original withdrawal was for
20:09:34	phantomcircuit:	kanzure, they're trusting the remote server to give them valid change addresses?
20:09:35	phantomcircuit:	wat
20:10:08	phantomcircuit:	that kind of defeats the purpose of an hd wallet...
20:30:11	zz_lnovy:	zz_lnovy is now known as lnovy
20:40:10	NewLiberty:	NewLiberty is now known as NewLiberty-afk
22:03:07	Eliel:	phantomcircuit: well, at least it should be possible to verify the given address locally given that it's a deterministic process that creates them.
22:26:05	Profreid_:	Profreid_ is now known as Profreid
22:34:05	Dizzle__:	Dizzle__ is now known as Dizzle
22:38:11	op_mul:	Eliel: I bet they don't verify it though.
22:54:38	kanzure:	op_mul: bitgojs does not seem to verify it. and i think they are using bitgojs (because what other clients do they have?).
22:56:01	op_mul:	kanzure: yes, that's not a new flaw either sadly. other people have made similar mistakes in their clients where change addresses aren't validated.
22:57:05	kanzure:	go on?
22:57:32	kanzure:	where did other implementations fetch from? i mean there can't be that many ways to get this wrong.
23:01:36	op_mul:	I'm not going to disclose that.
23:25:37	kyletorpey:	kyletorpey has left #bitcoin-wizards