00:30:18	c0rw|away:	c0rw|away is now known as c0rw1n
00:35:28	phantomcircuit:	[23:03:20] WHAT IF ALL OF HUMANITY IS STUCK IN A LOCAL MAXIMA?!
00:35:38	phantomcircuit:	what makes you think we aren't?
00:36:17	kanzure:	too ambiguous
00:36:27	gmaxwell:	there are worse fates.
00:36:36	kanzure:	ambiguity is pretty rough
00:40:28	sipa:	well as long as we are _stuck_ in a local maximum, we're fine, right?
00:42:40	phantomcircuit:	sipa, ha
00:54:26	ajweiss:	nobody freak out. everything's cool. as long as we're here, we don't know there exists, and if we don't know there exists, we can't possibly know that there is better than here. so as long as some library jockey doesn't show up and throw some physical approximation of simulated annealing at everything, it will all be OK.
00:55:28	gmaxwell:	"And this is how the vacuum collapse was started..."
01:14:41	danneu:	danneu has left #bitcoin-wizards
01:42:46	Adlai:	has there not yet been an implementation of coinswap?
01:43:30	artifexd_:	artifexd_ is now known as artifexd
01:43:35	op_mul:	not sure there's even been any popular coinjoin ones. there's andytoshi's and the one in darkwallet. the latter probably gets the most use but I doubt it's a huge volume.
01:44:51	Adlai:	not coinjoin... https://bitcointalk.org/index.php?topic=321228.0;all
01:45:30	op_mul:	I know, I was taking the popularity of coinjoin as a measure for how likely it was for the newer and less heard of coinswap.
01:45:52	Adlai:	blah i basically started reading at "coinjoin", sorry about that
01:46:05	op_mul:	not bothered
01:46:30	Adlai:	are you familiar with the protocol?
01:47:13	Adlai:	i'm trying to wrap my head around it. maybe do one manually on testnet, if somebody else is up for that
01:47:33	Adlai:	although i could do it with myself as well
01:47:43	op_mul:	I'm not really
02:28:52	jcorgan:	last i heard discussed, coinswap was vulnerable to a malleability attack
02:30:27	gmaxwell:	This doesn't prevent you from using it or building software for it.
02:31:03	gmaxwell:	Even given that, it's certantly more secure than just sending coins and hoping the other party does the right thing; which is the next alternative.
02:31:22	gmaxwell:	(or prevent you from using it on testnet with play money)
02:31:41	nsh:	((all money is play money; some just take the rules very seriously))
02:32:02	gmaxwell:	play-ier money then.
02:32:10	nsh:	* nsh smiles
02:49:32	op_mul:	gmaxwell: pretty sure we're going to need DarkerCoin with CoinSwap.
02:59:13	zz_lnovy:	zz_lnovy is now known as lnovy
03:09:17	artifexd_:	artifexd_ is now known as artifexd
03:18:39	zz_lnovy:	zz_lnovy is now known as lnovy
03:46:34	zz_lnovy:	zz_lnovy is now known as lnovy
03:54:20	jcorgan:	AA is going on in twitter about blockchain difficulty retargetting. Seems to have never heard of sybil attacks.
03:58:23	gwillen:	jcorgan: I see a bunch of stuff about how we could get in trouble if the difficulty drops a lot and slows the next retarget
03:58:33	gwillen:	what's he tweeted that bears on sybil attacks?
03:59:46	jcorgan:	he's worried about a sudden reduction in hash power just after a difficulty regtargeting, making the next 2016 blocks take a really long time.
04:00:11	jcorgan:	and proposes a temporary decrease in difficulty in the consensus rules
04:00:56	jcorgan:	but an attacker who controls your ISP can filter blocks to you, or set up himself as all 8 of your outbound connections
04:01:29	maaku:	jcorgan: haven't read the tweets, but there are safe ways to do that, e.g. a flag day
04:01:38	jcorgan:	then when you think the hashrate has decreased so much and you kick in a lower difficulty target, now they can send you whatever low difficulty blocks they want
04:02:17	jcorgan:	i think there were some altcoins that tried this and failed
04:03:23	maaku:	there are others (e.g. freicoin) which have had such a flag day with no ill effect
04:03:24	maaku:	other than that it is a one-off hard fork change and all that goes with that
04:03:53	jcorgan:	i'm not talking about how a hard fork would be easy or hard
04:04:20	jcorgan:	but about how that "emergency difficulty adjustment" algorithm is vulnerable to a Sybil attack
04:04:35	kanzure:	ah, you mean if you fool the person into thinking that a super low difficulty is appropriate
04:04:41	jcorgan:	exactly
04:05:28	maaku:	jcorgan: right, so don't use an emergency algorithm. Do an emergency one-time adjustment
04:05:43	jcorgan:	oic what u mean
04:06:17	kanzure:	also, the attack would be something like both fool the person and then get them to broadcast some transaction in your favor?
04:06:58	jcorgan:	or send a block with a tx to them that will get reorged out when they get normal connectivity again
04:07:19	jcorgan:	need to run, bbiab
04:15:58	gmaxwell:	jcorgan: yea, any of those things just fails. meanwhile "flag day" works fine: you have basically no risk of it being triggered when the network is really fine; not adding vulnerablities to 'fix' far out failures.
05:04:08	zz_lnovy:	zz_lnovy is now known as lnovy
05:32:52	contrapumpkin:	contrapumpkin is now known as copumpkin
05:58:01	zz_lnovy:	zz_lnovy is now known as lnovy
06:07:16	zz_lnovy:	zz_lnovy is now known as lnovy
06:09:10	NewLiberty_:	NewLiberty_ is now known as NewLiberty
06:48:12	op_mul:	gmaxwell: what's a flag day in this context?
06:49:04	op_mul:	it's sort of insane that the king of bitcoin knowledge doesn't know why there's adjustment periods at all. wonder how long it's going to take for him to dredge up some support to go and change it to adjustments every block.
06:57:52	op_mul:	"
07:08:59	gwillen:	op_mul: I think a flag day in this context would mean "we push out a new client that declares a changeover by fiat at a particular block height"
07:12:08	op_mul:	weird.
07:15:35	gwillen:	op_mul: weird why?
07:16:49	op_mul:	never mind.
07:22:42	zz_lnovy:	zz_lnovy is now known as lnovy
07:25:48	Guest73562:	Guest73562 is now known as wiz
07:37:32	zz_lnovy:	zz_lnovy is now known as lnovy
07:40:04	gmaxwell:	op_mul: the notion there is that no matter how strong the social contract is, ... it's not so strong that it prevents the system from being fixed when it's just not working.
07:40:34	gmaxwell:	though really if you have to make a fix like that something deeper is probably wrong.
07:42:34	op_mul:	I think it's a can of worms that should never be opened. it leads into "well we fixed that with a quick fork, why not this too?"
07:45:02	op_mul:	I can't remember the name of it, but there's a human state of mind that basically says you have a much higher chance of doing something you know is wrong if you've already broken the rule recently.
07:45:02	op_mul:	I got to work late, the day's already screwed I'll just bail after lunch and go get a beer. that sort of thing.
07:45:10	gmaxwell:	sure sure; but if it's "systems worthless because its not working at all" vs "system's worthless because we're not confident the rules are set in stone"; the latter is better.
07:46:21	gmaxwell:	the whole zomg hashrate might drop thing is some concern most people have when the first get up to speed with the system. but a factor of 2, 3, or 4 drop isn't a huge deal in terms of transaction clearance performance.
07:46:54	gmaxwell:	and given power sensitivity spreads larger seems unlikely
07:48:16	maaku:	gmaxwell: that said I've personally seen (in an altcoin context) where a drop of ~4x led to a price decline which hurt mining profitability in a vicious cycle
07:49:03	maaku:	but it is far, far too early to be crying wolf
08:57:53	zz_lnovy:	zz_lnovy is now known as lnovy
09:05:13	sinisalo.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	sinisalo.freenode.net:	Users on #bitcoin-wizards: andy-logbot koshii benten lnovy Logicwax nsh damethos weex CoinMuncher prodatalab Transisto justanotheruser Burrito wiz null_radix siraj samson_ coiner copumpkin yoleaux nullbyte Luke-Jr TheSeven btc__ huseby wallet42 d1ggy__ artifexd zooko OneFixt hguux_ Muis rasengan jbenet pgokeeffe Taek42 Dr-G2 roconnor pi07r mappum DougieBot5000 coryfields_ CryptOprah kumavis BrainOverfl0w Adlai wumpus e1782d11df4c9914 midnightmagic butters Graftec
09:05:13	sinisalo.freenode.net:	Users on #bitcoin-wizards: nick1234abcd__ Krellan yrashk LarsLarsen MRL-Relay michagogo forrestv kyletorpey zwischenzug ahmed_ phedny warptangent asoltys_ isis HM2 berndj sadgit maaku tacotime so fanquake harrow` kanzure crescendo sipa sneak azariah Guest38445 comboy K1773R EasyAt heath nanotube helo jaromil eric btcdrak Apocalyptic espes__ v3Rve petertodd @gmaxwell sdaftuar lechuga_ amiller roasbeef Anduck BananaLotus bobke jcorgan s1w Meeh nuke1989 epscy atgreen
09:05:13	sinisalo.freenode.net:	Users on #bitcoin-wizards: Fistful_of_Coins poggy_ tromp__ starsoccer optimator throughnothing wizkid057 fluffypony livegnik PRab waxwing gribble catcow TD-Linux ryan-c smooth Alanius AdrianG tromp pigeons Dyaheon- Cory dansmith_btc gavinandresen mortale Hunger- Shiftos Iriez BigBitz [d__d] BlueMatt dgenr8 bosma DoctorBTC Starduster c0rw1n cjc xabbix_ catlasshrugged Eliel Emcy hashtag_ grandmaster Guest96271 tripleslash ebfull cfields brad___ mkarrer_ SubCreative
09:05:13	sinisalo.freenode.net:	Users on #bitcoin-wizards: bbrittain jaekwon_ iddo thrasher` Tjopper NikolaiToryzin op_mul cluckj Greed ajweiss mbelshe Graet JonTitor Keefe morcos sl01 otoburb mr_burdell brand0 nickler warren fenn phantomcircuit PaulCapestany a5m0 Nightwolf spinza luny Grishnakh burcin hollandais stonecoldpat gnusha @ChanServ gwillen andytoshi kinlo
10:33:55	zz_lnovy:	zz_lnovy is now known as lnovy
13:39:08	hearn_:	hearn_ is now known as Guest66524
13:58:48	Kloeey:	Bitcoin to 100$ look at this graph from China,Russia omg.. 100$ coming... http://www.bitcoinwisdomapp.com/#BitcoinGraphToday
13:59:27	fluffypony:	Kloeey: no.
14:02:52	op_mul:	that's malware, if nobody guessed. don't click.
14:38:39	kanzure:	is it interesting malware at least?
14:41:19	narwh4l:	* narwh4l opens vm, clicks link
14:43:00	op_mul:	I doubt it
14:43:22	op_mul:	a rarball I can't be bothered getting the VM out for. it'll be some off the shelf RAT trojan.
14:49:41	jtimon:	http://bitcoin.stackexchange.com/questions/35461/ripple-only-a-sub-network-reaching-a-consensus-is-largely-enough-to-be-decentra#comment40350_35461
14:49:56	jtimon:	maybe someone else wants to give a more detailed answer...
16:11:59	wallet421:	wallet421 is now known as wallet42
17:07:55	d1ggy__:	d1ggy__ is now known as d1ggy
17:34:19	mbelshe_:	mbelshe_ is now known as mbelshe
19:09:42	zooko`:	zooko` is now known as zooko
19:28:46	lclc_bnc:	lclc_bnc is now known as lclc
21:00:19	Luke-Jr:	earlz: having miners vote on max block size doesn't seem like the best idea - they can easily put other miners out of business that way (or prevent entry from new guys easier)
21:00:44	Luke-Jr:	proof-of-stake might make sense for this, but I'm not sure if it's feasable
21:01:21	gmaxwell:	"John Dillion" had a genreal idea that I thought was interesting. Along the PoS lines.
21:03:56	earlz:	yea, that's what I was thinking as well
21:04:02	earlz:	(re: miners voting)
21:04:29	gmaxwell:	Then there was one that that I had that I don't think has seen much discussion. Where basically you can increase the size over some median up to a hard limit (there to make sure non-miners aren't left out), but only by mining at a higher difficulty... the parameters can be set such that there is no incentive to include low fee transactions just to jump ahead of other miners.
21:05:01	gmaxwell:	(this idea was used in bytecoin, but the based it on fee burning which triviall doesn't work; using difficulty adjustment seems like it would)
21:05:47	earlz:	yea, having block size similar to difficulty could be interesting
21:06:14	earlz:	I imagine like if average block size over retarget period is >75% of current max, increase max block size
21:06:28	earlz:	I can't imagine that being very gameable
21:07:28	gmaxwell:	earlz: hm? thats trivially gamable. you just pad your blocks with crap transactions.
21:07:44	earlz:	but why would a miner do that? It makes their blocks more expensive ot broadcast
21:08:15	gmaxwell:	infinitesmally so; and improved block propagation tools more or less eliminate even that small cost.
21:08:27	earlz:	plus bigger blocks with less actual transactions means less fees for miners (since priority isn't as imporant)
21:08:58	gmaxwell:	earlz: you take all the fees, then pad out the rest to maximum; doing to pushes other miners out of business.
21:09:16	earlz:	why would it push other miners out?
21:10:08	gmaxwell:	Because the cost of operating a node become macroscopic which favors single big entities because they only have to do it once.
21:10:10	earlz:	I mean miners could do that now if they wanted, since I don't think most blocks are close to full
21:10:44	gmaxwell:	doesn't have an effect now, because blocks cannot be big enough to make the costs macroscopic.
21:11:10	gmaxwell:	(though even with as low as the costs are we have seen huge consolidation)
21:11:38	earlz:	running a node isn't cheap because of diskspace, but other than that are there any other concerns?
21:11:54	gavinandresen:	bandwidth will be the bottleneck
21:12:04	earlz:	I imagine miners stuffing blocks not with just crap transactions, but expensive to process transactions
21:12:41	gmaxwell:	earlz: perhaps but as gavin points out; bandwidth is the main concern.
21:13:05	earlz:	yea
21:13:20	gavinandresen:	earlz: what problem are you trying to solve with a dynamic maximum block size?
21:13:27	earlz:	I can't see any reason we'd need >20Mb blocks in the foreseeable future
21:13:31	gmaxwell:	Really the long term histor shows that of all of storage/bandwidth/cpu bandwidth seems to grow the slowest (no surprises: there is serious infrastructure costs) and right now if you take your own capacities you'll likely find your transaction throughput limits are mostly bandwidth related.
21:14:24	phantomcircuit:	gavinandresen, iirc cpu time currently exceeds download time for my systems
21:14:45	phantomcircuit:	maybe that will change with faster validation
21:14:54	gavinandresen:	phantomcircuit: that’ll change with libsecp256k1....
21:15:09	earlz:	I'm not trying to solve a problem with dynamic block size, I just saw it's a proposal and was wondering how that'd work
21:16:08	phantomcircuit:	gavinandresen, possibly (i also have more bandwidth than most)
21:16:08	gavinandresen:	earlz: all the proposals for dynamic max block size I’ve seen don’t address the problems that a max block size is meant to solve
21:16:27	gavinandresen:	There are only two reasons I can see to limit the block size: 1) limit transaction spam
21:16:31	gmaxwell:	phantomcircuit: I assume "my systems" are e.g. gigabit connected; If you were paying 1% of your three year bandwidth costs for a CPU that wouldn't be the case.
21:16:32	earlz:	max block size is there for propogation time and node cost limits right?
21:16:44	gavinandresen:	and 2) prevent possible over-centralization
21:17:16	gavinandresen:	Satoshi slapped on the 1MB limit to limit transaction spam. We’ve got that under control with the dust rule, transaction fees, free transaction rate limiter.
21:17:51	earlz:	it'd be nice if dust rules were a concensus rule
21:17:53	gavinandresen:	… so the only reason I see to limit the max size is the centralization concern. Which depends on real-world resource constraints, which can’t be determined by on-blockchain navel-gazing
21:18:47	gmaxwell:	gavinandresen: You seem to be omitting, "preserving fee income as a mechenism to pay for ongoing security";
21:19:18	gavinandresen:	gmaxwell: did you read my ‘blocksize economics’ blog post? I think fee income is, and will be, unrelated to block size
21:19:31	gmaxwell:	Which is something the perhaps dynamic sizing could help with, though I'm unsure. "security" is something outside the system, just as the centeralization concern.
21:20:04	gavinandresen:	gmaxwell: I’m curious why you think limiting block size will increase overall fees.
21:21:10	earlz:	I assumed it would because priority would be more pressured, so more people would want their transactions faster, so they'd pay higher fees
21:21:34	gavinandresen:	Fewer transactions with higher fees does not mean more fees overall… more transactions with lower fees might be better.
21:21:48	gmaxwell:	gavinandresen: because it creates a reason to pay non-trivial amounts for fees; which is actually behavior we've seen in the network today. I believe that it's likely that there is some optimal blocksize limit where fee income is maximized; too large and there is no reason to pay anything. Too small and there isn't enough room to gather the fees available (and perhaps adoption of the system goes
21:21:54	gmaxwell:	down)
21:22:08	gmaxwell:	(and that curve might have multiple local maximums, sure)
21:22:21	phantomcircuit:	gmaxwell, well lets see
21:22:42	gavinandresen:	gmaxwell: my objection is your trying to reason about two fundamentally different things. There are lots of ways to secure transactions against double-spends that dont’ involve paying fees or relying on fast confirmation
21:23:28	gavinandresen:	e.g. we could end up in a world of very few high-value transactions that pay zero or minimal fees, because the banks involved all have contracts with each other and don’t have to pay miners to secure those transactions.
21:23:46	phantomcircuit:	5253 seconds to reindex on a system with a Intel(R) Xeon(R) CPU E5-1620 v2 @ 3.70GHz and the entire blockchain in fs cache
21:23:55	gmaxwell:	gavinandresen: sure; but we're talking about the blockchain; whos purpose is to provide independant long term security against double spends. If you're happy to use some other mechenism than the behavior of the blockchain doesn't matter to you at all, perhaps.
21:23:58	gavinandresen:	… or we could end up in a world of gazillions of very-low-fee transactions that are secured by a third-party “I promise never to doublespend” instant confirmation service.
21:24:24	phantomcircuit:	blockchain is ~35GB currently
21:24:39	phantomcircuit:	which is 280000 megabits
21:24:51	phantomcircuit:	which is ~53mbps
21:24:55	gmaxwell:	gavinandresen: yes yes all these things are true. And if those are successful it just may be uneconomical to have a blockchain at all. If so, that'll be pretty sad-- because it does give a very different kind of security than the alternatives.
21:24:55	gavinandresen:	My point is that we can’t reason about fees and block sizes. So the engineer in me says “make them as large as is safe, becase more is better"
21:25:03	morcos:	my fraction of a bit cent of input here is that we dont' really know how a free market for fees would work, and it might make sense to let blocks fill up so we can figure that out sooner rather than later
21:25:10	phantomcircuit:	and i cheated and added a checkpoint at like block height 330000
21:25:44	gmaxwell:	phantomcircuit: a lot of the reindex time is not signature validation, alas.
21:25:51	gavinandresen:	morcos: blocks won’t fill up— what happens is low-value transactions just stop happening.
21:26:21	phantomcircuit:	gmaxwell, doesn't that effectively just clear the utxo and then read the raw block files?
21:26:48	phantomcircuit:	ie time spent muching about with weird block files is likely going to be just as bad as or worse than getting them from peers
21:26:55	phantomcircuit:	mucking*
21:28:01	morcos:	gavinandresen: well thats what i mean, right now no transactions are discouraged except literally by the hard coded dust or fee relay limits. those are so close to zero, that it might make sense to see what happens when market forces cause slightly higher value tx's to be discouraged (but still low value)
21:29:03	morcos:	i suppose though that this could be through default miner policy instead of hard coded consensus limit, so that its easier to increase capacity if that min economical tx value starts getting too rich
21:29:58	gavinandresen:	some people already think the min economic value is too rich… I get asked by people who want to bring Bitcoin to India or Africa to please support lower-value transactions
21:31:02	phantomcircuit:	im not sure you can actually do that without completely destroying the transaction fee incentives
21:31:33	gmaxwell:	phantomcircuit: right now if you assume sig 72+ pub 32+ vin 40 + 2 bytes push overhead. then libsecp256k1 on a quadcore i7 does about 81mbit/sec of verification. OpenSSL is about 10mbit/sec.
21:31:59	phantomcircuit:	gmaxwell, right but there's a certain amount of overhead to that
21:32:14	phantomcircuit:	remember this is with a cheater checkpoint at 330000
21:32:21	phantomcircuit:	so i was doing almost no signature validation
21:32:35	phantomcircuit:	50mbps is almost entirely just overhead
21:33:18	gmaxwell:	phantomcircuit: I'm just pointing out that if you have less than 80mbit/sec bandwidth and a basic quad core cpu, then verification should not be your bottleneck. Other cpu bound parts contribute though, so cpu might be though that can be optimized out.
21:33:20	gavinandresen:	phantomcircuit: a 1MB block full of 1-cent-per-kilobyte transactions is about the same as a 10MB block full of 0.1-cent-per-kilobyte transactions … both pay miners the same. For users, the 10MB block is better. Better for users means more BItcoin utility, which should mean more valuable coin....
21:33:41	gavinandresen:	… which drives my intuition on why the block size should be as large as possible.
21:33:44	phantomcircuit:	gmaxwell, right ok
21:34:21	phantomcircuit:	gavinandresen, that's only going to work if there's size pressure at 10MB though
21:34:51	gavinandresen:	phantomcircuit: we have no size pressure at 1MB right now, why is anybody paying a fee?
21:34:52	phantomcircuit:	gmaxwell, oh you know what, i had txindex=1
21:34:59	phantomcircuit:	i'll run again with that disabled
21:35:33	gavinandresen:	actually, let me disagree: we DO have size pressure, because some miners produce smaller-than-1MB blocks.
21:36:00	gavinandresen:	I think we’ll always have size pressure, because some miners will choose to produce smaller-than-whatever-the-max-is blocks.
21:36:14	gavinandresen:	For either philosophical or practical reasons
21:36:41	jcorgan:	isn't there size pressure at any time just from the increased possibility of orphans? might only be a small contributor.
21:37:01	gmaxwell:	jcorgan: not really; it's small and can be made basically zero with more intelligent transport.
21:37:11	gmaxwell:	Maybe at the moment there is; but it's not fundimental.
21:37:16	jcorgan:	got it
21:38:39	gavinandresen:	I have a sneaking suspicion that we should try to establish a social convention that large-value transactions pay a 0.01% ‘health of the network’ fee….
21:38:40	gmaxwell:	gavinandresen: I am not sure that some small number of participants producing small er blocks actually counts as pressure in a system which is otherwise unlimited. It's basically the same as if those miners weren't mining at all, and you just had an unlimited system with blocks slightly less frequently.
21:38:47	phantomcircuit:	jcorgan, interestingly the underlying structures strongly discourage mining blocks with unbroadcast transactions
21:38:56	phantomcircuit:	which seems like a happy coincidence
21:40:24	gavinandresen:	gmaxwell: if it is in the best interest of miners to produce smaller blocks then it shouldn’t be too hard for them to band together and agree to produce smaller blocks....
21:40:30	morcos:	gavinandresen: large unmoving balances also benefit from the 'health of the network'
21:40:33	gmaxwell:	gavinandresen: social conventions seem to be remarkable unrelialbe for systems where relationships aren't persistent. I wish I knew how to encourage that sort of thing in a convincing way... there are also some variance issues with it; e.g. 10000 btc transaction happens and the returns just go to a single miner, not exactly ideal for hashrate stability.
21:41:49	morcos:	i know this question is blasphemy, but do people ever think it would have been better if the system were designed with a small but permanent inflation rate in the steady state
21:42:38	gmaxwell:	gavinandresen: Yes, it might also be in their best interest to agree that they want a 10% cut of each transaction. "We'll conspire over and above the rules" has its negative uses too. Ideally we should have a system which doesn't instutionalize that kind of behavior. Especially because making such an agreement "only mine fees of x" stick requires things like non-anonymous mining and/or soft-fork
21:42:44	gmaxwell:	ing out / punishing blocks that don't agree with the cabal.
21:42:46	gmaxwell:	morcos: it might have been, but it seems impossible to calibrate.
21:42:50	gavinandresen:	morcos: if I was Satoshi I would have done the Milton Friedman thing and had a steady 2%-per-year inflation .....
21:43:39	gmaxwell:	morcos: say that the rate was was 1% of 21e6 per year.. but then varrious computer disasters happen (as they have happened) and over time only 1 million doins remain unlost. Now your inflation rate is more like 20%!
21:43:57	gavinandresen:	gmaxwell: I’m tempted to pull out that famous Hayek quote about the curious task of economics.....
21:44:47	morcos:	gmaxwell: interesting.. but only temporarily right... not sure that makes that disaster that much worse does it
21:44:54	gavinandresen:	gmaxwell: we can go around and around arguing about angels dancing… I mean theoretical fee market dynamics.
21:45:22	gavinandresen:	I don’t want to make policy… which is why I want the block size to be as large as feasible, engineering-wise.
21:45:37	gavinandresen:	Then let the economics fall out however they fall out.
21:45:59	gmaxwell:	gavinandresen: thats also policy too.
21:46:17	gavinandresen:	That is “as simple as feasible” policy.
21:46:42	gavinandresen:	The only policy that would be simpler would be NO max block size, which is actually my preference, but which I won’t propose.
21:47:04	gmaxwell:	But it's not simple; it completely undermines the "what will pay for security" fold of the system; or at least replaces it with an even more complex set of armwaving which we already had.
21:47:24	gmaxwell:	gavinandresen: thats just incompetent engineering-- no block size. We can't even make software that could accomidate that without falling over.
21:47:39	gavinandresen:	The “what will pay for security” when the block subsidy goes to zero has NEVER been determined, though!
21:48:01	gmaxwell:	"oh sorry, your mission criticial infrastructure is just going to stop at some unspecified time in the future because third parties-- who might gain economically from your failure-- have done something which cost them nothing.
21:48:24	gmaxwell:	gavinandresen: That is _explicitly_ what transaction fees are for.
21:48:26	gavinandresen:	gmaxwell: no hard-coded consensus-rule max block size… of COURSE there would be a soft maximum block size that nodes would refuse to process
21:48:50	gavinandresen:	gmaxwell: … sigh …
21:49:09	phantomcircuit:	something something video of you saying sigh
21:49:15	gmaxwell:	gavinandresen: Yes, different potentially on every system. Which is not acceptable.
21:49:27	fluffypony:	I remain unconvinced that tx fees will be enough to sustain it
21:49:30	gavinandresen:	Satoshi did not impose the 1MB limit because he was worried that transaction fees would be zero if blocksize was unliminted.
21:49:39	gmaxwell:	morcos: well coins are always being lost and the system has no real way to know. If you say that you'll have unmoved coins expire in order to know they're lost; then there is an incentive to suppress transactions to reduce supply then. :(
21:50:52	gmaxwell:	gavinandresen: Perhaps not (or the 32MByte limit befor that 1MB one). But it doesn't change that the expectation has always been that transaction fees would pay for decenteralized security; and absent some scarcity in block size I really have no argument as to how thats possible.
21:52:07	gavinandresen:	gmaxwell: but the argument that the 1MB block size will be sufficient to force fees to pay for security is… well, not an argument
21:52:11	justanotheruser:	gmaxwell: what about increasing odds of stale with more transactions, isn't that a pretty good incentive?
21:52:12	gmaxwell:	I agree that 1MB forever is brain damaged and also unlikely to work out great in the long run; so I haven't been responding in public disagreeing with your approach much.
21:52:33	gmaxwell:	justanotheruser: its not a fundimental effect.
21:52:37	morcos:	@gmaxwell: my point was only that if you add 21e4 coins per year, then your supply is growing so your inflation rate becomes less until loss rate = inflation rate. then you temporarily bump to high inflation on loss shocks.
21:52:54	gavinandresen:	gmaxwell: I don’t know what the answer will be to secure the blockchain in the future. I expect it will be something like assurance contracts....
21:52:56	morcos:	@gmaxwell: i agree expiring coins is risky. anyway, wishful thinking at this point, it is what it is
21:53:14	gavinandresen:	… unless some ‘send money to transaction fees to establish identity / create a bond’ becomes popular
21:53:50	gmaxwell:	gavinandresen: The assurance contract stuff mike has written about don't really make any sense. I mean, they equally pay for people to create malicious forks. So, I think thats not so helpful.
21:54:09	gavinandresen:	gmaxwell: My basic economic reasoning is that we should do everything we can to maximize the value of the Bitcoin system, for all applications / uses / etc.
21:54:16	gmaxwell:	gavinandresen: sadly "burn coins" seems to be more attractive than "pay fees" because it eliminates the 'risk' that the miner themselves creates the bonds for free without a complex protocol. :(
21:54:44	gavinandresen:	gmaxwell: If we do that, I am convinced that some way will be found to keep the chain secure enough for those uses
21:55:18	kanzure:	convinced by what?
21:55:34	gmaxwell:	gavinandresen: I don't disagree with you there, but I believe the all of the value of the Bitcoin system (as opposed to the many vastly more efficient alternatives) is owed to its decenteralization. And part of that means we must have a security mechenism which doesn't depend on a clique of signers that can do whatever they want.
21:55:36	gavinandresen:	I don’t claim to know HOW people will do that. Maybe BitPay will run a huge mining operation to limit double-spend risk.
21:56:13	kanzure:	(isn't that a clique of signers?)
21:56:20	gavinandresen:	gmaxwell: I agree with keeping things decentralized, and that’s the reason I agree that limiting the max block size is a reasonable thing to do
21:56:22	gmaxwell:	kanzure: thanks.
21:56:35	kanzure:	i seem to have stumbled into the wrong alternate reality
21:56:54	kanzure:	you see, sometimes my irc client messes up like this
21:57:31	gmaxwell:	gavinandresen: the decenteralization losses can come from multiple angles; one is being able to run at node at all. Another is having mining actually be a security mechenism. I mean, you can let the diff fall to one and use signed blocks and have "security", but at the loss of decenteralization.
21:57:45	gavinandresen:	gmaxwell: … maybe the chain will be secured by “voluntary” $10 transaction fee on every greater-than-$100,000 transaction… who knows?
21:58:01	kanzure:	well, arguably we know, by reasoning
21:58:07	jcorgan:	why would you put "voluntary" in quotes?
21:58:45	gmaxwell:	jcorgan: certantly thats one of the things that concerns me. "let the market figure it out" ... well sure it will, you might not like the answer.
21:58:54	gavinandresen:	gmaxwell: let me ask a different way: if we didn’t have the 1MB max block size, what max block size would you choose right now? How would you decide?
21:59:01	kanzure:	yeah, isn't the market-friendly solution something like completely centralized?
21:59:54	justanotheruser:	if the market friendly solution was centralized, would bitcoin have any chance of success?
22:00:11	kanzure:	yeah i phrased that poorly, sorry
22:00:49	gmaxwell:	kanzure: yes, I think so. But markets are not simple, and people aren't perfect economic maximaxers; and such.
22:00:54	kanzure:	miners have no particular reason to prefer decentralized designs in the long-term, as long as the centralized options tend to favor them
22:01:37	gavinandresen:	For reference: https://blog.bitcoinfoundation.org/blocksize-economics/
22:02:14	justanotheruser:	Short term miners may favor centralized solutions, but since centralization causes them to not be needed/paid, longterm miners should favor a decentralized solution.
22:02:30	kanzure:	you can be paid even in centralized solutions
22:02:32	gmaxwell:	gavinandresen: If I knew for sure I would be saying "We need to do X now" whatever that X is. Absent knowing I'd probably set it as low as possible where the system could still be widely used. A some number of years ago I might well have picked 1MB since thats 14kbit/sec.
22:02:53	justanotheruser:	but why would anyone pay for miners in a centralized solution
22:03:06	kanzure:	justanotheruser: they wouldn't, they pay some bank or whatever, who cares, that's not my specialty
22:03:15	gavinandresen:	gmaxwell: I think we’re in violent agreement, then. I’m proposing to set it low enough to ensure it can be widely used
22:04:21	gavinandresen:	(and growing it a little slower than technology is growing)
22:07:47	gmaxwell:	Something like 40x larger than the current offered load seems a little shocking to me. Especially in that I think we have strong evidence that we're failing to maintain good decenteralization with the levels we have right now. (though I'm hesitant to pound on that point because 0.10 and 0.11 will improve things a lot)
22:09:18	gavinandresen:	gmaxwell: okey dokey. Not sure what I can do to convince you that 20MB blocks are not insane besides what I’m already doing....
22:10:30	gavinandresen:	All of the transaction fee pressure arguments seem like red-herrings to me: same arguments apply to 10K blocks as 1MB blocks as 20MB blocks, unless you have some way to compute the optimal size there’s not much to talk about there.
22:11:14	morcos:	decentralization is 2 issues to me, full nodes and mining. to the extent they are both problems i think 20MB blocks is a bit of a jump for the full node issue.
22:11:23	gavinandresen:	morcos: why?
22:11:40	gmaxwell:	I don't yet know if its insane or not; you just started doing these tests recently; though we'd talked about it a long time back. As I said right now, I've been too concerned with just the current level, and I think right now we have very strong evidence that the current scale is not sustainable, but I think the evidence is no good because it can be resolved with straight forward software improve
22:11:42	gavinandresen:	morcos: you don’t expect block sizes to jump to 20MB immediately just because MAX_BLOCKSIZE changes, do you?
22:11:47	gmaxwell:	ments.
22:11:49	morcos:	but i don't see as to how it matters for mining. speaking of someone who has never mined, there are far greater overheads in mining than worrying about bandwidth and other capacity constraints of a full node
22:12:30	kanzure:	gmaxwell: right, absent some of the recent bitcoind changes, i would agree that increasing block sizes would be particularly dangerous
22:12:36	gmaxwell:	morcos: actually it's horrible; because already miners hand over their mining to centeralized pools (and miner rental services) blindly very easily. The friction there is bad.
22:12:38	kanzure:	*some of the other recent bitcoind changes
22:13:06	morcos:	gavinandresen: just a "bit" maybe, i mean until we have autoprune and other things, the blockchain is already unwieldy in size
22:13:07	earlz:	is there any ideas out there for replacements to PoW or ways to decrease centralization?
22:13:11	earlz:	other than the obvious one, PoS
22:13:15	kanzure:	although i'm not sure if i should consider headers-first to be recent or not, now. what year is this?
22:13:41	kanzure:	earlz: that's not really an option
22:14:07	morcos:	gmaxwell: maybe i'm just not in tune with what miners do, but seems to me that the hard part is getting competitive hashing hardware and hosting facilities..
22:14:08	gavinandresen:	morcos: I assume autoprune and optimizing initial block download will happen in any case— it HAS to if we want the number of full nodes to start going back up.
22:14:18	earlz:	I mean modifications to PoW even
22:14:27	gmaxwell:	gavinandresen: and as I talk businesses in the bitcoin space and engineers, I am being told that people do not want the costs of running their own nodes; and that they had problems and turned them off. (even in my case; I stop all my nodes one a week for a conference call, because the bandwidth spikes make VoIP unusable for me)
22:14:35	earlz:	idk.. I know it's all crazy talk, but eh
22:14:59	gmaxwell:	But I don't think this is fundimental; I think we can fix it. So I can't hold that against 20MBytes.
22:15:06	morcos:	hooking up to a pool is for variance reduction, not because running a full node is hard. if i was going to make the jump to do mining, i can't imagine i'd think anything of runnign a full node
22:15:07	gavinandresen:	gmaxwell: right, that needs fixing in any case.
22:15:15	kanzure:	gmaxwell: isn't there an rpc bandwidth limiting parameter thing?
22:15:22	kanzure:	* kanzure looks
22:15:46	gmaxwell:	kanzure: there isn't yet, without headers first it really screws up nodes behavior if their peer during IBD is throttled.
22:15:49	gavinandresen:	I don’t think either of our current centralization issues (mining and number of full nodes) are tied to block size.
22:15:51	gmaxwell:	Next version.
22:16:38	gavinandresen:	gmaxwell: are there concrete proposals yet for how to tackle mining centralization? Besides hope pools use getblocktemplate more....
22:17:34	gmaxwell:	gavinandresen: I know with absolute certanty that the are; I am not sure how much. But I watch constantly as miners _try_ to run full nodes and give up after 2 days of syncing and switch to using conman's 1% fee "solopool".
22:18:25	gmaxwell:	gavinandresen: luke's been working on protoocol enhancements that split coinbase and work selection, I'm soon hiring someone to help on that; which might help... but still requires someone to run a node.
22:18:57	gavinandresen:	gmaxwell: so we need to get consensus on UTXO commitments in the chain, so syncing up a full node takes less than 11 minutes.
22:19:17	gavinandresen:	… err, syncing up a “fully validating but not all historical txns” node
22:19:30	morcos:	and we need to hope top of the line mining hardware becomes more of a commodity
22:19:44	gavinandresen:	That plus pruning solves the problem, no matter the block size, yes?
22:20:06	gmaxwell:	gavinandresen: We're down to 2.5 hours synctime in 0.10 on fast hardware without libsecp256k1.
22:20:16	kanzure:	cool
22:20:25	gavinandresen:	gmaxwell: yes, but 11 is my favorite number. SO eleven minutes.....
22:20:27	kanzure:	full blockchain sync?
22:20:33	gmaxwell:	kanzure: yes
22:22:38	gmaxwell:	gavinandresen: Having you just sign all the blocks "solves" things too. "Just ignore the history" isn't a free trade-off, and the utxo commitments greatly increase the runtime costs for full nodes (though we don't know how much; they probably double the utxo set size at a minimum). We need to address the non-security impacting improvements (pruning; bandwidth shaping; secp256k1 library) first.
22:24:08	earlz:	why is it so expensive to run a full node? I'd assume for running a pool, the node would be the cheapest thing
22:25:09	gmaxwell:	earlz: it's a constant cost regardless of how much hashpower you have, so it amortizes well (favors centeralization)
22:26:48	ajweiss:	but minimum viable hashpower is orders of magnitude more expensive, no?
22:26:56	gmaxwell:	Stupidly implemented a comitted utxo takes N hash operations per txout created or deleted, and N additional disk IO, and 2*N storage (assuming a txout is the same size as a hash). As opposed to 1, 1, N. (where N=ceil(log2(txouts)) == 23, right now)
22:27:55	gmaxwell:	ajweiss: huh, there is no such thing as "minimum viable hashpower", mining is linear. I mean if you account for the cost of your time, then there is some threshold there; but if you're talking about running a node and mining the running a node part probably takes more of your time and attention than the rest.
22:28:29	gavinandresen:	gmaxwell: mmm… well, if the problem is “get fully-validating nodes up and running quickly” then O
22:28:39	gavinandresen:	… I’d be OK with compromising on utter decentralization
22:28:53	kanzure:	would you be okay with a central authority validating transactions
22:28:55	ajweiss:	fair, unless there's a mining "distribution"
22:29:10	ajweiss:	plug in p2pool or something
22:30:20	gmaxwell:	We do in an number of ways already; so I agree but being intelligent about that requires facing the tradeoffs. We're obviously not better off in a situation where there are very full full nodes because we didn't have a good halfstep.
22:30:36	c0rw1n___:	c0rw1n___ is now known as c0rw1n
22:30:57	gmaxwell:	ajweiss: a distribution though increases your cost to a whole extra computer; which is actually fine for some; and ought to be more widely done/supported.
22:34:29	ajweiss:	yeah true, i suppose i keep forgetting that miner margins can be pretty thin
22:35:03	ajweiss:	although, i dunno, i'd argue if they're sufficiently thin that that would be a problem, you've probably got bigger problems
22:36:07	gmaxwell:	people don't know what their margins actuall are, even at industrial scale; it results in some really weird behavior.
22:36:29	gmaxwell:	E.g. microoptimizing on costs you feel you can control, while being pound foolish on the others.
22:37:34	gmaxwell:	A modern miner is super trivial to setup if using a centeralized pool. I think I had my SP20 I just go running in 10 minutes after the package showed up (against my local p2pool, which is just as easy if it's already running; but only if its already running).
23:01:49	PRab_:	PRab_ is now known as PRab
23:12:06	phantomcircuit:	so removing txindex=1 dropped the reindex time (with my cheater checkpoint)
23:12:10	phantomcircuit:	down to 4836 seconds
23:12:28	phantomcircuit:	which is ~57mbps
23:12:54	phantomcircuit:	gmaxwell, ^ does that seem reasonable for overhead not including 99% of signature validation?
23:16:41	gmaxwell:	pretty darn slow, really. though you've still got a bunch of signing. it would be good to just turn off all signature validation (bool fScriptChecks = false;) and benchmark a reindex.
23:21:34	PRab_:	PRab_ is now known as PRab
23:22:57	phantomcircuit:	gmaxwell, can do
23:25:51	phantomcircuit:	actually checkpoint was at + (338856, uint256("0x00000000000000000deb14265ff457fe242adaf83c11f2785dc70b1643834be4"))
23:26:16	gmaxwell:	oh... thats almost at the tip.
23:26:20	gmaxwell:	well thats just as good then.
23:26:26	gmaxwell:	yea, so thats ... slow.
23:26:36	phantomcircuit:	yup
23:26:37	gmaxwell:	phantomcircuit: what dbcache are you running with?
23:26:44	phantomcircuit:	4096
23:26:57	phantomcircuit:	system has 80GB of ram
23:27:05	gmaxwell:	yea, so even leveldb should not possibly be at fault for that, since basically the whole sync should be in ram then.
23:27:20	phantomcircuit:	actually even has 6.3GB of entirely free ram
23:27:27	gmaxwell:	Know how to use oprofile? :P
23:27:49	phantomcircuit:	nope, usually run perf
23:27:52	phantomcircuit:	unless
23:28:06	phantomcircuit:	same interface?
23:28:21	gmaxwell:	perf works too.
23:34:28	phantomcircuit:	gmaxwell, oh and this is built with --disable-wallet also
23:34:45	phantomcircuit:	so this is likely very close to optimal performance
23:34:58	phantomcircuit:	at least with current systems
23:56:23	phantomcircuit:	hmm
23:56:27	phantomcircuit:	well that's vaguely annoying
23:56:38	phantomcircuit:	perf doesn't seem to be updating the record until i exit
23:57:04	phantomcircuit:	no that's not right...