00:00:05	Taek42:	^
00:01:00	amiller_:	also the even/odd rule seems to flat out screw over small miners who can only afford the overhead of keeping up with one path vs all the paths
00:01:39	petertodd:	amiller_: yes they can, however the advantage is relatively small, because if users use it randomly distributed, the length of time you don't have the data to mine some path has decreasing probability for longer lenths
00:01:56	petertodd:	amiller_: not quite perfect, but it's plausible and close to perfect
00:03:05	amiller_:	dont follow yet
00:03:39	amiller_:	a big guy can afford the overhead of storing every path, the small guy is storing only a single path
00:03:49	amiller_:	but the goal is for the hashing effectiveness of the small single path guy to be equal to the large ugy
00:04:15	petertodd:	amiller_: so, if the rule doesn't let you mine a full-pow-strength block on one side, you can still mine a half-strength block valid for the child
00:04:40	amiller_:	yes but the big guy is merge mining bot hthe full-strength + half-strength blocks
00:04:51	amiller_:	each of the big guy's attempts has more ways of winning than the small guy
00:05:26	petertodd:	amiller_: I know, but you see how by keeping *some* of the data, but not all the way down, you're approximating what the "big guy" can do?
00:06:02	amiller_:	hm maybe i see
00:06:04	petertodd:	most of your hashing attempts won't run into the block because they won't be valid blocks for the parts of the chain where the rule matters
00:06:44	amiller_:	i understand how the top block has no even odd rule
00:06:49	amiller_:	and i think i undrestand what you mean for second layer
00:07:05	amiller_:	in the third layer, does each of the four 2 layer blocks alternate 1/4 of being valid
00:07:15	amiller_:	or is a quarter strength block valid half the time
00:07:32	petertodd:	amiller_: sorry, I think I'm going to need to draw this and write this down...
00:07:48	petertodd:	might be a waste of time without doing that, regardless of who is right!
00:08:03	amiller_:	yep
00:09:52	Taek42:	at some intuitive level, I feel like forced alternating is both harmful and unnecessary, you can encourage alternating with some incentive scheme.
00:10:22	amiller_:	the incentive schemes seem to have conflicting goals imo though
00:10:29	petertodd:	^ yup
00:10:40	amiller_:	i think if you could force people to spread out it would be useful
00:10:47	amiller_:	this is something i *don't* have a great solution for in permacoin
00:10:56	amiller_:	your public key determines your random assginment of things to store
00:11:14	amiller_:	but you can grind by drawing new public keys until you aren't assigned any of the child porn in Sector 1
00:11:30	amiller_:	(well not really because of erasure coding but still everyone could avoid the first big chunk of data for whatever reason)
00:12:05	petertodd:	amiller_: related to that, is I want to write a patch to analyse pushdata's and block anything that doesn't meet statistical randomness tests
00:12:23	petertodd:	amiller_: we really want to encourage embedded consensus schemes to steg their data
00:13:03	jgarzik:	* jgarzik starts reading at a random point in the conversation, and thinks: sounds like red-black trees, a bit, applied to block tree
00:13:21	amiller_:	jgarzik, that seems like a really way-off intuition
00:13:46	jgarzik:	it's out of context
00:13:56	jgarzik:	as I said, started reading at a random point.
00:14:10	jgarzik:	still, a fun nutter thing to think about
00:21:29	nsh-:	i've understood |o/ None Of The Things! in this conversation. still perversely interesting
00:22:10	petertodd:	nsh-: don't feel bad; amiller and I were actualy just trollin' nonsense to practice spitballin' for our new rap careers
00:22:20	nsh-:	ehehe :)
00:27:37	Taek42:	petertodd: http://pastebin.com/rT0AMP17, gtg for now. This is the best I could do, I'm not sure I understand treechains well enough for it to be valuable, but whatevs
00:28:42	petertodd:	Taek42: thanks!
01:21:09	wallet42:	wallet42 is now known as Guest18708
01:21:09	wallet421:	wallet421 is now known as wallet42
01:58:18	saivann__:	saivann__ has left #bitcoin-wizards
03:45:02	kanzure:	https://github.com/kanzure/bitcoin-incentives/blob/master/bitcoin-incentives.tex
03:45:14	kanzure:	this is an enumeration of bitcoin-related incentives from the software and also common-sense-related incentives
03:45:21	kanzure:	not complete, looking for feedback
03:45:41	x48:	x48 has left #bitcoin-wizards
03:46:37	andytoshi:	you also talked about trying to list how various changes would affect incentives ... do you think that should be a separate doc or this one should support it?
03:46:54	andytoshi:	my vote is separate, it would be nice to just have a list of "where bitcoin uses economics"
03:47:53	kanzure:	oh hm
03:47:58	kanzure:	i actually have no idea if it should be separate
04:25:01	kanzure:	wei dai musing about a defense against singularities http://extropians.weidai.com/extropians.3Q97/4356.html
05:00:51	Taek42:	kanzure how do I build your latex file?"Something's wrong--perhaps a missing \item"
05:02:06	Taek42:	oh wait I didn't realize how incomplete the file is
05:04:06	kanzure:	oh, i should fix that huh
05:04:21	kanzure:	seems like a thing worth doing
05:04:55	kanzure:	i'll drop in some Makefile soon
05:05:38	Taek42:	one thing that might be worth talking about is the effect a fluctuating price can have on mining - price drops mean offline miners, which means 'dark hashpower'
05:06:50	Taek42:	and a bubble can result in miners overbuying, anticipating a sellout at much higher prices, which can also affect the mining ecosystem when the bubble doesn't reach the anticipated heights
05:07:52	kanzure:	hm i seem to have missed general economic incentives in general
05:08:45	kanzure:	i also realize that miner incentives are dramatically easier to reason about compared to others (like transaction verification consensus stuff, or network protocol stuff), so miner stuff is presently over-emphasized
05:11:55	Taek42:	"Incentives to provide accurate timestamps" ==> what are those incentives? Isn't it in the miners best interest to make it look like the block took 20minutes or 70 minutes, or whatever they can get away with as to drive the difficulty down and mine coins faster?
05:12:34	kanzure:	i will be pestering andytoshi for that one soon
08:05:16	kornbluth.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
08:05:16	kornbluth.freenode.net:	Users on #bitcoin-wizards: andy-logbot mortale vmatekole aburan28 RoboTedd_ adam3us Dr-G Guyver2 tjopper drawingthesun p15 ericp4 pen Kretchfoop fanquake eristisk TheSeven tromp_ berndj-blackout [d__d] nsh_ koshii_ kmels jchp jcorgan qualiabyte nuke1989 DougieBot5000 copumpkin tacotime c0rw1n lysobit yoleaux irc88 Graftec devrandom jaekwon justanotheruser MoALTz Transisto todaystomorrow Iriez wizkid057 OneFixt_ Adlai davidlatapie hollandais ebfull Aquent Starduster
08:05:16	kornbluth.freenode.net:	Users on #bitcoin-wizards: lnovy spinza gribble go1111111 Tyrent hguux livegnik HaltingState rfreeman_w wiretapped stonecoldpat Dyaheon Fistful_of_coins Sangheili digitalmagus dansmith_btc2 jgarzik dgenr8 EasyAt BigBitz MRL-Relay artifexd _2539 mappum jbenet [Derek] zibbo_ kanzure SDCDev Luke-Jr petertodd optimator [\\\] Grishnakh warren puszl pi07r Adohgg K1773R xmj Hunger- Eliel HM gmaxwell amiller_ crescendo LarsLarsen cfields btc_ kgk bobke iddo samson_ arowser
08:05:16	kornbluth.freenode.net:	Users on #bitcoin-wizards: comboy Happzz wumpus NikolaiToryzin coryfields michagogo zenojis LaptopZZ Meeh poggy_ Emcy_ UukGoblin danneu catcow TD-Linux [Tristan] helo smooth otoburb gwillen ryan-c mmozeiko roasbeef pajarillo sl01 Keefe Gnosis ahmed_ Muis Logicwax nanotube espes__ andytoshi so epscy BlueMatt tromp a5m0 starsoccer midnightmagic Graet kinlo pigeons lianj BrainOverfl0w Apocalyptic mr_burdell fluffypony bbrittain SomeoneWeird forrestv Anduck Nightwolf
08:05:16	kornbluth.freenode.net:	Users on #bitcoin-wizards: Krellan Taek42 asoltys sipa nsh- phantomcircuit DoctorBTC harrow CodeShark throughnothing Guest47516 Alanius abc56889 lechuga_ burcin phedny @ChanServ
10:21:21	l1c:	Taek42: I'm not wholly convinced that "dark hashpower" is really a risk that applies to the network at the moment. from a home mining perspective the hardware is so dispersed that it's hard to imagine any coordinated attacks using them.
10:22:15	l1c:	for enterprises running large scale operations would be able to even do quick attack cycles with cold hardware? having all the miners lying around hooked up ready for an attack is going to be pretty expensive for an opportunity that might never arise. you'd still be paying the bills for the fat electricity lines, rent, security, etc. how quickly can you ramp up megawatts of miners without blowing stuff up?
10:23:23	l1c:	a much more realistic risk might be somebody compromising the embedded controllers mining equipment uses or just compromising pools themselves. is a mining pool worth dropping some obscure 0day on? quite possibly, there's a lot of money involved.
10:34:07	gmaxwell:	It would be very useful to have a list of "where bitcoin uses economics"; there are some situations where the economic incentives can undergo local reversal and it would be handy to have a list of things that would likely suffer attacks at the same time...
10:34:55	gmaxwell:	l1c: the pool is worth the zero day just to steal the coins; the question you should ask is it worth going beyond that to try to extract more via some double spends or other network attacks.
10:36:44	gmaxwell:	most pools have been compromised multiple times, in some cases via fairly sophicated attacks.
10:54:14	l1c:	gmaxwell: the main reason mining hardware would be desirable to attack is that it would be significantly harder to detect and control.
10:54:29	l1c:	if every piece of X hardware showed in it's interface that part of it failed and it was hashing 10% slower, would anybody notice that it was really attempting to mine alternate blocks with that percentage instead? it's sending traffic to a weird NTP server rather than a normal one? silly manufacturer X, they don't have a clue what they're doing.
11:30:29	samson2:	samson2 is now known as samson_
12:08:03	ericp4:	ericp4 has left #bitcoin-wizards
12:32:07	jgarzik:	dakami just sent me 0.005 BTC ;p
12:32:23	jgarzik:	as a test send
12:34:39	l1c:	why do people make test spends at all? if wallet software has the ability to drop bits during signing there's a lot bigger issues, and the fact that you didn't get memory corruption during the first signing doesn't suggest anything of the second.
12:35:53	jgarzik:	If you are about to send 10 BTC irreversibly, it makes sense to ping the address first.
12:36:12	jgarzik:	screw up with a small amount is preferable to a screwup with a large amount.
12:37:02	l1c:	what situation would that save you from though? the act of your client seeing funds it thinks it can spend doesn't speak to actually being able to sign for it. at least no wallet I know if attempts to sign for an output before declaring it as spendable.
12:40:28	kanzure:	the situation where you have an active man-in-the-middle that isn't aware of your test spend
12:45:24	l1c:	I suppose, though I made the assumption that GPG would be used for the address.
12:45:47	davidlatapie:	davidlatapie has left #bitcoin-wizards
12:46:48	l1c:	not sure that would work though, a man in the middle able to alter messages sent by both sides would see that it was meant to be a test, and they could pay out the same amount to the untampered address in order to make the test "pass".
12:49:58	kanzure:	presumably you are confirming with out-of-band communication of some kind
12:50:19	kanzure:	where it is unlikely that you are also being man-in-the-middled
12:52:03	l1c:	wouldn't that negate the use of a test transaction in the first place? the actual act of making a test transaction doesn't tell you anything above just communicating the address out of band.
12:55:34	kanzure:	i haven't really thought about whether or not it's a good idea, just the culture or process that tends to lead people to thinking it may be a thing they should be doing
12:56:30	kanzure:	i have seen this behavior elsewhere but i can't cite you anything specific
13:02:30	l1c:	there's a nice paper about that sort of behaviour in pigeons. a researcher fed pigeons food at random intervals, and they all developed erratic behaviour based on whatever they were doing at the time. through random reenforcement they would "learn" erratic behaviours like walking continuously in circles or whacking their heads into the corners of their cage.
13:03:05	l1c:	I can't really come up for a reason for people doing test sends at all that would actually save them against a realistic threat, possibly it's like the pigeons: I did a test send and nothing went wrong so I'd better do a test send next time just in case.
13:05:30	nsh-:	as a representative of the union of working pigeons i find your analysis highly problematic
13:13:40	l1c:	nsh-: there's photos of BF Skinner's pigeons and they look to be quite happy enough, I'm sure you could get ethics approval for that today. possibly not for the part where he wanted to pigeons into missiles to guide them.
13:16:56	kanzure:	andytoshi: thanks
13:18:30	l1c:	in the terms of Bitcoin storage you get similar strange behaviour. there's people describing methods of storage that have worked for them (ie, their money hasn't been stolen yet) involving insane combinations of software, buying laptops and destroying the hard drives, using printers once and then disassembling them.
13:18:56	l1c:	regardless of these actions actually having actually contributed to users actual security or not they'll be driven to repeat them because they worked before.
13:19:12	andytoshi:	Taek42: the incentive for correct timestamps is (a) why not? they don't affect anything unless you are doing the 2016th block, then you can only skew by ±2hrs if you want your block to be relayed, which gives you a difficulty skew of 0.6%, (b) any skew at all might cause others not to relay your block, (c) it's the default behaviour of your mining software
13:19:23	kanzure:	wait wait, that response should go into the file
13:19:40	andytoshi:	ok, one sec
13:21:04	l1c:	andytoshi: I have always wondered about that, can you not cause a split in the network by riding the very edge of the accepted timestamp? people will naturally not have their clocks set quite right.
13:23:06	andytoshi:	l1c: yes, you could, but one-block splits are pretty common, it'd be hard to find a double-spend victim doing this
13:23:39	andytoshi:	and actually you couldn't control the competing block or the next block with high probability, so i'm not sure you could double-spend at all..
13:23:54	andytoshi:	so basically you'd be dropping the chance you get your reward to 50% for no reason
13:24:25	Apocalyptic:	(c) it's the default behaviour of your mining software // is this really relevant ?
13:26:05	andytoshi:	Apocalyptic: it's probably the biggest incentive
13:26:22	andytoshi:	that plus "you don't gain anything from changing it"
13:26:24	Apocalyptic:	using default software behaviour when assessing incentives seems somewhat secondary at best
13:26:28	l1c:	andytoshi: if there was enough spread in clocks you could do nasty things like forcing a non-majority of the network to waste work on useless blocks at the same height as yours.
13:27:24	Apocalyptic:	as that default software code will probably adapt to the incentives rather than condition them
13:28:36	andytoshi:	l1c: maybe. miners are pretty well-connected, it'd be hard to get something that relayed to noticeably more than 0% but less than 100% of them
13:29:40	Apocalyptic:	Apocalyptic: it's probably the biggest incentive // your point (b) looks like the biggest, since it's economical
13:30:39	andytoshi:	Apocalyptic: yeah, you're right, i'll drop the "default" one
13:32:12	l1c:	andytoshi: a non-trivial portion of block timestamps do go backwards though.
13:33:15	andytoshi:	yeah, but not by "pushing 2 hours" amounts
13:33:24	andytoshi:	probably it's just people with shit RTCs
13:34:11	andytoshi:	in my PR to the incentives paper i do mention this
13:48:44	l1c:	andytoshi: for interests sake, the biggest backwards skip was 0000000082a8a3c3b71c81cf910a1a5c72c025906babeb0492cbf1f85b164bde with flies back 7115 seconds into the past.
13:50:12	andytoshi:	interesting, too bad we can't see how far forward the previous block was
13:50:12	andytoshi:	(relative to clock time)
13:55:14	l1c:	there's going to be forward skew too, due to the way miners work (set a block, work on it).
13:57:37	andytoshi:	yeah, but not cumulative skew, it'll just always be 0-10mins ahead
14:01:08	l1c:	it matters only in that you're more likely to get positive than negative skew
15:30:14	Taek42:	andytoshi adding to your response, at some macroeconomic level you flood the economy. I don't think your average miner worries about that, but the amount of liquidity in Bitcoin is low compared to the inflation. If you speed up the generation of coins by 10%, you're likely to affect the price a lot more dramatically because the Bitcoin market is particularly suceptible to dumping (at this stage anyway).
15:30:55	Taek42:	but all of those reasons together seem really fragile to me. Why wouldn't a set of pools collude to increase the amount of coins they are mining?
15:31:30	Taek42:	It may not take effect for 2 weeks, but after that you've increased your income by X percent with no growth in hash power
15:35:18	andytoshi:	because X is like 0.5, assuming you somehow get the entire mining community onboard, and it can only be done for a single difficulty period because "2 hours ahead of clocktime" is not cumulative
15:39:44	Taek42:	you couldn't just keep adding to the timestamp?
15:40:11	Taek42:	if you had 51% all agreeing to 'fast time', wouldn't people keep accepting the blocks?
15:40:17	Taek42:	oh wait nvm the clients would reject
15:47:29	Taek42:	alright so lets say I've 51% attacked the network
15:47:46	Taek42:	is it possible for me to create a bunch of forks by releasing blocks right on the edge of client timeouts?
15:48:05	Taek42:	so that some clients hear about the block in time to accept, but some don't and so they reject?
15:48:46	Taek42:	and so I've got a handful of clients following my longest chain b/c I've got 51% hashing power, and the rest follow a set of honest miners who've rejected my edge block and are mining on a fork
15:49:07	Luke-Jr:	Taek42: there is no limit on how old a block can be
15:49:42	Taek42:	Luke-Jr I'm talking about releasing a block that's timestamped into the future
15:50:13	l1c:	Taek42: does the client have logic to know to try validating that block again when the timestamp is valid?
15:51:18	l1c:	if it forever marked that block as invalid you'd cause a fork.
15:52:20	Taek42:	oh, right
15:52:58	Taek42:	this all makes so much more sense to me now
15:56:53	l1c:	easy enough to try out if you're so inclined.
15:57:29	Taek42:	true enough.
16:02:06	l1c:	from a quick look I don't think it would try to validate the block again once it failed CheckBlockHeader() the first time. I don't know any of this code well enough though.
16:06:04	l1c:	not sure why the time check failure is a 100% DoS trigger though. if a peer sends you a block they think the timestamp is right on and you don't, you immediately ban them on the spot?
16:06:55	l1c:	oh misread that, you don't apply any DOS score for that. looking at the wrong function.
16:07:08	Taek42:	you might be able to abuse this to fork the mining on the network
16:07:30	Taek42:	if you release a block that's right on the cusp, you can have half of the miners mining on your new block, and half will be mining on the old block
16:07:59	Taek42:	and so there will be a lot more orphans
16:08:24	Luke-Jr:	stales*
16:08:42	Taek42:	oh is there a difference?
16:09:12	Luke-Jr:	orphans don't have a known prevblock
16:09:21	Taek42:	oh
16:12:38	Taek42:	If you could use this technique to get enough miners mining on stales, could you reduce the barrier for launching double spends?
16:13:36	Taek42:	I guess a defense for that is merchants having an awareness that blocks are being launched on the cusp of invalid, and just wait for extra confirmations.
16:16:08	sipa:	/sb end
16:51:34	nsh_:	nsh_ is now known as nsh
16:51:38	nsh-:	nsh- is now known as [nsh]
17:08:29	l1c:	l1c is now known as magic8ball
18:19:16	x48:	x48 has left #bitcoin-wizards
18:38:06	samson2:	samson2 is now known as samson_
18:55:35	jgarzik:	amiller_, https://twitter.com/jgarzik/status/518473587410612225
18:55:44	jgarzik:	dakami requested "minimum pomp & circumstance"
18:56:30	fluffypony:	hah hah
18:56:59	[nsh]:	fair play
18:57:54	amiller_:	sweet.
18:58:25	amiller_:	hope you put it all towards security audits of bitcoin etc :p
18:58:42	[nsh]:	yes, i'll have a double security audit on the rocks pls
18:59:32	fluffypony:	our tweeting worked
18:59:51	fluffypony:	well petertodd and I are the only two that tweeted
18:59:59	fluffypony:	such social pressure
19:00:23	kanzure:	amiller_: thoughts? https://github.com/kanzure/bitcoin-incentives/blob/master/bitcoin-incentives.tex
19:03:13	[nsh]:	.t dealwaeit
19:03:13	yoleaux:	[nsh]: Sorry, I don't know a timezone by that name.
19:03:32	[nsh]:	.tw dealwaeit
19:03:34	yoleaux:	@dakami i have noted your non-welchingness and a smiley face has been drawn in your permanent record (@DealWaeIt)
19:21:53	ni638629:	hi
19:22:13	ni638629:	ni638629 has left #bitcoin-wizards
21:34:22	samson_:	With proof of work requiring a base primitive in the form of an sha256 digest, does anyone think that this could be expanded on to make the problem exponentially harder by adding additional steps ?
21:35:07	justanotheruser:	samson_: it has been made harder in altcoinns. Why do you think this is desirable though?
21:35:20	HM:	it already is made harder by requiring a 0 prefix
21:35:34	[nsh]:	btw, bit of light entertainment (hopefully): https://www.reddit.com/r/crypto/comments/2i9qke/openssl_bug_allows_rsa_1024_key_factorization_in/
21:35:54	samson_:	I'm talking about each iteration - all we use are basic hashes
21:36:53	samson_:	For example an sha256 digest which is then used as an ECDSA private key, pubkey is created by doing point addition - this is then ran through sha256 to get the final hash which requires the zeroes = hugely harder and much more complex
21:37:11	justanotheruser:	samson_: why would you want the additional complexity?
21:38:00	andytoshi:	sounds he is trying to violate every part of asic-faq.pdf at once..
21:38:05	samson_:	To slow down the miners and reduce difficulty - I'm thinking of alt security here - legacy hardware would be useless to attack them
21:38:11	justanotheruser:	samson_: you can do H1(H2(...H13(block header)...)), and it has been done, but it isn't desirable
21:39:12	samson_:	This would be highly experimental and not for Bitcoin itself but more as a test on an alt
21:39:35	justanotheruser:	samson_: slowing down miners by a factor of 10 just means someone who could own 10% of the network hashrate with their cluster at 10mh/s can now own 10% of the network at 1mh/s with their entire cluster
21:40:19	justanotheruser:	however, nodes now require 10x the CPU power to verify a block
21:40:29	xmj:	fluffypony: how's that freebsd port of monero coming along?
21:41:24	Luke-Jr:	samson_: for a PoW, you want the verify to be as easy/cheap/fast as possible; adding more steps slows that down
21:41:45	Luke-Jr:	samson_: in other words, making it harder is the opposite of what is desirable
21:42:10	Luke-Jr:	xmj: this is not #monero
21:42:51	justanotheruser:	samson_: useful reading https://download.wpsoftware.net/bitcoin/asic-faq.pdf
21:42:55	samson_:	Luke-Jr: Sure, there would be more overhead in verifying buy that's nothing compared to mining there it's only donw once
21:43:10	Luke-Jr:	samson_: you gain nothing from making each iteration harder
21:43:10	samson_:	Thanks for that link - I will have a good read through it
22:50:55	artilectinc:	artilectinc has left #bitcoin-wizards
23:20:49	justanotheruser:	gmaxwell: "a proof that the insert was done correctly"
23:20:50	justanotheruser:	is this another ZKP that has already been done, or did they design it themselves
23:22:01	gmaxwell:	what I was describing in #bitcoin-mining is just a 'bog standard' cryptographic accumulator. it's something there are many papers on, under many different sets of crypto assumptions, with different efficiencies and security tradeoffs.
23:24:09	justanotheruser:	is there a more common word for it? nothing here http://scholar.google.com/scholar?hl=en&q=bog+standard+accumulator
23:26:01	gmaxwell:	"cryptographic accumulator"
23:26:58	justanotheruser:	thanks