01:41:05	devrando1:	devrando1 is now known as devrandom
07:04:54	SomeoneWeird:	SomeoneWeird is now known as Guest58903
08:05:16	orwell.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	orwell.freenode.net:	Users on #bitcoin-wizards: andy-logbot pen devrandom Guest58903 Graftec CoinMuncher Meeh AaronvanW dgenr8 x48_ CoinHeavy qualiabyte RoboTeddy mortale TheSeven tacotime forrestv koshii OneFixt_ shesek justanotheruser K1773R fanquake livegnik jchp_ HaltingState mkarrer oujh wiretapped Anduck a5m0 nuke1989 go1111111 michagogo skinnkavaj atgreen gernika SDCDev epscy GAit amiller_ Nightwolf altoz Aquent spinza wallet42 rfreeman|afk Keefe roconnor wizkid057 Krellan BigBitz
08:05:16	orwell.freenode.net:	Users on #bitcoin-wizards: Starduster artifexd [\\\] dansmith_btc berndj-blackout kmels grandmaster2 Taek42 melvster1 mr_burdell samson_ nanotube jaromil bbrittain BlueMatt jaekwon nsh warren asoltys Hunger- LarsLarsen waxwing Iriez [Derek] CryptOprah_ mappum zlinn_ btc_ jbenet Emcy tromp_ EasyAt tucenaber Logicwax Transisto iddo tromp Muis Grishnakh sl01 comboy_ Luke-Jr digitalmagus7 drawingthesun emsid Graet UukGoblin espes__ sipa coryfields licnep [d__d] midnightmagic
08:05:16	orwell.freenode.net:	Users on #bitcoin-wizards: bobke postpre nsh- copumpkin Adohgg zenojis pajarillo crescendo jgarzik HM maaku phantomcircuit azariah4 zibbo gmaxwell Fistful_of_coins DoctorBTC poggy harrow rs0 Dyaheon roasbeef andytoshi mmozeiko Eliel CodeShark throughnothing Guest47516 Alanius nickler_ Starsoccer pi07r ryan-c kanzure gwillen BrainOverfl0w otoburb smooth pigeons helo Guest50253 weex abc56889 lechuga_ TD-Linux catcow danneu LaptopZZ_ burcin optimator_ jcorgan petertodd
08:05:16	orwell.freenode.net:	Users on #bitcoin-wizards: kinlo so @ChanServ Apocalyptic lianj wumpus nkuttler gribble phedny
08:19:11	Meeh:	Meeh is now known as mikalv
08:57:21	Guest58903:	Guest58903 is now known as SomeoneWeird
10:37:50	rfreeman|afk:	rfreeman|afk is now known as rfreeman
10:41:19	amiller_:	amiller_ is now known as amiller
11:15:03	wallet42:	wallet42 is now known as Guest89619
11:15:04	wallet421:	wallet421 is now known as wallet42
13:48:17	x48_:	x48_ is now known as x48
14:10:29	bbrittain_:	bbrittain_ is now known as bbrittain
14:46:49	SDC:	SDC is now known as SDCDev
14:48:45	samson2:	samson2 is now known as samson_
14:49:02	michagogo_:	michagogo_ is now known as michagogo
14:49:48	artifexd_:	artifexd_ is now known as artifexd
15:06:10	fluffypony:	oh well, there we go, may as well throw in the towel
15:06:11	fluffypony:	https://www.darkcoin.io/downloads/InstantTX.pdf
15:06:13	fluffypony:	:-P
15:17:21	vfor:	vfor has left #bitcoin-wizards
15:33:09	licnep_:	licnep_ is now known as licnep
15:34:22	brisque:	to save anybody the time, here's a tl;dr on the "instant transaction" system the DarkCoin developers have excreted and are pumping with.
15:36:15	brisque:	their system of "masternodes" (fixed nodes with listening IP addresses, locked funds) is used to generate an authoritative signed message. one node form the pool of 1000 (currently) signs the transaction.
15:36:37	nkuttler:	nkuttler is now known as Guest49485
15:39:35	brisque:	their idea is that sybil attacks are nullified by "locking" outputs of a certain value, rendering them unspendable for a certain period. it's fairly flimsy even just to the point that the "masternodes" can be denial of service attacked by design.
15:39:43	Quanttek_:	Quanttek_ is now known as Quanttek
15:40:09	fluffypony:	brisque: a fact that gets ignored every time I raise it
15:40:23	fluffypony:	because apparently they "fixed the DDoS issue"
15:41:05	fluffypony:	which is amazing, not only have they created instant transactions, but they have somehow managed to create a system that can null-route upstream traffic automagically :-P
15:41:28	brisque:	fluffypony: do you know why they require them to be listening, or even how the network gets an idea of the total number of masternodes? seems you could do very basic partitioning on somebody to become the "only" masternode.
15:42:12	fluffypony:	brisque: no clue, maybe they advertise themselves as masternodes? or maybe it's hardcoded IPs?
15:43:02	brisque:	last time I looked into it it was all binary releases with no source and no technical detail. I got the impression that the system relied on being able to directly connect to some central controller.
15:44:49	HobGoblin:	HobGoblin is now known as Guest58606
15:45:46	fluffypony:	well the commits don't really help in grokking it: https://github.com/darkcoinproject/darkcoin/commits/master-rc5
15:45:51	brisque:	looks like it still is, there's people complaining that their nodes crash with the function RegisterAsMasterNode which doesn't exist anywhere in the source.
15:46:07	Guest58606:	Guest58606 is now known as UukGoblin
15:46:07	fluffypony:	"version bump" is the description on most commits
15:46:18	fluffypony:	and it's literally a version bump
15:46:19	fluffypony:	lol
15:46:40	brisque:	looks like mastercoin node data is part of the version message?
15:49:10	brisque:	yeah. I
15:49:17	brisque:	ve no idea how this works. at all.
15:49:45	brisque:	if nodes are meant to pass the masternode addresses around, that's easy partitioning
15:50:14	brisque:	they won't be in blocks because a masternode isn't going to be a miner
15:50:55	nkuttler_:	nkuttler_ is now known as Guest36691
15:51:19	fluffypony:	well it looks like everything is in main.cpp
15:51:23	fluffypony:	because who needs abstraction
15:53:09	Quanttek:	Didn't he said that the publishing of the source had to get delayed multiple times because of "code refactoring & cleaning"?
15:53:13	brisque:	I'm not sure that includes the stuff you need to *be* a mastercoin node, I can't find that register function anywhere.
15:53:25	brisque:	er masternode.
15:54:10	brisque:	Quanttek: GetCurrentMasterNodeConsessus() not very refactored, not even spelt right.
15:55:08	Quanttek:	yup. I think there is a reason, that he doesn't work for Microsoft anymore
15:55:46	fluffypony:	"masternode genkey" is the command you're supposed to run
15:55:56	fluffypony:	but "genkey" doesn't exist in master or in master-rc5
15:56:00	fluffypony:	so I'm guessing that's closed-source
15:56:07	brisque:	let me see if it's in the binary
15:56:58	brisque:	fluffypony: yeah. that's in the binary from their website. not in the source.
15:57:48	fluffypony:	such trust.
15:57:49	fluffypony:	"here, run this unknown binary...and you have to put 1000 DRK in it...nothing bad will happen, we promise"
16:02:59	brisque:	haven't they been promising the source for like, a year?
16:03:15	fluffypony:	I lost track
16:06:02	brisque:	nice voting ring on reddit pushing their nonsense to the top
16:47:24	drawingthesun:	does viacoin pose any threat to bitcoin? I hear they have peter todd and he will make viacoin have side trees,
16:49:02	brisque:	drawingthesun: read andytoshi's paper on why PoS is a PoS.
16:49:18	drawingthesun:	link?
16:49:38	brisque:	http://bitcoin.ninja under "proof of stake"
16:50:38	drawingthesun:	brisque, thanks, any comment about why a respected core developer would be giving light to these other projects?
16:50:45	fluffypony:	point of sale is a PoS? :-P
16:50:51	sipa:	viacoin is not proof-of-stake, is it?
16:51:19	brisque:	yeah
16:51:41	brisque:	it's the one that got nuked by somebody stealing all the coins from an exchange, and the developers used the checkpoints to unsteal all of them again.
16:51:50	fluffypony:	brisque: no that's Vericoin
16:52:06	brisque:	serious;ly?
16:52:08	fluffypony:	Viacoin is this crowd: http://www.reddit.com/r/Bitcoin/comments/2c9700/peter_todd_hired_by_viacoin_to_work_on_tree_chains/
16:52:21	brisque:	there's too many shitcoins, I swear. I can't even keep track of the names now.
16:52:36	brisque:	sorry sipa, it's an scrypt one.
16:53:03	drawingthesun:	ok, so viacon is not not PoS, and it now has peter todd, what do we make of this?
16:53:18	fluffypony:	drawingthesun: he's paid to consult to them, just like he consults to us
16:53:27	drawingthesun:	I see
16:53:30	fluffypony:	the difference is we didn't call him our "chief scientist" and put out a press release
16:53:36	drawingthesun:	Ah
16:54:43	brisque:	fluffypony: you would if you bought Andreas though
16:54:53	fluffypony:	I mean, drawingthesun, this is the telling bit - http://www.reddit.com/r/Bitcoin/comments/2c9700/peter_todd_hired_by_viacoin_to_work_on_tree_chains/cjde4vt
16:54:58	fluffypony:	"Frankly I don't know much about Viacoin, so I can't comment yet. They simply asked me to do research on treechains and were willing to pay for it. My contract with them is such that all work will remain free of patents and be opensourced."
16:55:09	fluffypony:	brisque: doubtful
16:55:19	drawingthesun:	fluffypony, thanks, this makes more sense now. Cheers.
16:55:21	brisque:	fluffypony: deep sarcasm :)
16:55:39	fluffypony:	brisque:-P
16:56:51	fluffypony:	the only person we'd allow to be Monero's chief scientist would be someone who's literally willing to wear a lab coat and horn-rimmed glasses every day and speak with a German accent
16:56:55	fluffypony:	basically a real life Gag Halfrunt
16:57:24	brisque:	force todd to do it
16:57:26	fluffypony:	"vell, Monero's just zis coin, you know"
16:57:29	fluffypony:	hah hah
16:57:40	brisque:	sneak it into a contract
16:57:54	fluffypony:	good deal
17:03:35	andytoshi:	drawingthesun: peter todd isn't a "core developer" in the sense that he doesn't have push access to the bitcoind repo
17:04:05	andytoshi:	drawingthesun: he's contributed a lot to bitcoind, but so have many others, and it doesn't tie him to the project (or ties his projects to bitcoind)
17:04:18	drawingthesun:	andytoshi, I see,
17:05:43	amiller:	also they don't "have" petertodd just because they hire him as consultant
17:06:10	brisque:	amiller: makes for good promotion juice though
17:06:14	amiller:	he's pretty consistent about staying independent / not an employee, you might even just think of it as them sponsoring his research
17:08:24	fluffypony:	brisque: how else are you supposed to pump the price and justify spending your premined funds (sorry, "presale")
17:25:49	gmaxwell:	brisque: The kind of locking for instant payments has been proposed and deployed in bitcoin for some time. green-address (the wallet)'s instant transaction service does that. As you note it has some dos exposure.
17:27:19	fluffypony:	but how can it work without masternodes?! it is a miracle of modern computer science!
17:30:23	andytoshi:	guys, let's try to keep a high SNR here, busy people read all the scrollback, etc, etc
17:30:52	fluffypony:	aight
17:31:11	fluffypony:	in that event, can somebody sanity check this for me please - we pushed it out today
17:31:15	fluffypony:	http://openalias.org
17:35:55	grubles:	grubles is now known as Guest75935
17:38:17	pigeons:	pigeons is now known as Guest51572
17:46:51	Guest51572:	Guest51572 is now known as pigeons
17:49:24	brisque:	just another point of note
17:49:52	brisque:	why the hell did somebody write yet another ruby bitcoin full node?
17:50:01	sipa:	because ruby
17:50:16	brisque:	oh wait, it's coinbases again! that explains it.
17:50:30	brisque:	( https://github.com/coinbase/toshi )
17:51:12	brisque:	you'd think they would have learnt their lesson the first time.
17:51:22	brisque:	> PostgreSQL (300gb+ disk space required to sync mainnet)
17:51:35	brisque:	oh boy.
17:51:42	pigeons:	EventMachine too
17:53:48	brisque:	I don't understand at all. why are the blocks being stored in postgres?
17:54:15	sipa:	because SQL
17:54:23	sipa:	because webscale
17:57:25	fluffypony:	needs more JS + CouchDB
18:01:59	x48_:	x48_ is now known as x48
18:08:11	brisque:	fluffypony: hahahahahahahaha. I found out why the masternodes need a public IP address!
18:08:40	brisque:	every single darkcoin client connects to the "masternode"!
18:08:46	brisque:	every single damn one.
18:09:34	fluffypony:	O.o
18:10:08	sipa:	to all, or to a random one?
18:10:50	brisque:	it's not clear, I'm going to fire up a VM and find out. the comment I found suggests they connect to every one, but that's 800 sockets per client on the network which seems a bit extreme. only one way to find out.
18:13:11	brisque:	even if it was just the "selected" one for that round, you'd end up pretty much just causing a DOS on that particular node.
18:19:07	brisque:	"By using this software, you acknowledge and understand that Darkcoin is not intended for use in any illegal activity, and that no person or entity associated with the creation, development, marketing, or furtherance of Darkcoin shall be held responsible for use by any individual, group, or entity that is against the law in their respective jurisdiction."
18:29:15	grubles_:	grubles_ is now known as grubles
18:36:41	gmaxwell:	cargo cult contracts.
18:37:05	lechuga_:	brisque: u can construct interesting queries with the blockchain in SQL
18:37:09	gwillen:	gmaxwell: "No copyright infringement intended!"
18:37:13	gwillen:	(cargo cult disclaimers)
18:39:41	brisque:	fluffypony, sipa: well. I don't know. I can't get their annoying client to actually "enable" the darksend stuff. you can sometimes get it to be "enabled", but it does a variety of non-responses to the RPC commands. best answer is that it tries to connect to all of them.
18:40:04	brisque:	how it finds them is another question I can't answer.
18:49:55	brisque:	alright. so the "masternodes" are connected to by every single client.
18:50:15	brisque:	masternodes are found by passing addr-like messages around.
18:51:17	justanot1eruser:	my intuition says masternodes have the generals problem
18:51:34	justanot1eruser:	no way of a miner knowing if they're actually doing their work
18:53:12	brisque:	more to the point there's nothing stopping you from just being partitioned.
18:53:51	brisque:	if I only pass you the masternodes I own, how would you know?
18:54:23	gmaxwell:	http://bitzuma.com/posts/blockchain-info-paper-backup-stores-private-keys-in-the-browser-history/
18:56:05	brisque:	gmaxwell: bit strong to call them "paper wallets" if they're being made by blockchain.info's RNG.
18:56:28	brisque:	gmaxwell: did you catch the quote about what they'll do about it?
18:56:56	brisque:	> indicated that a fix would be considered
18:59:50	gmaxwell:	hah
19:00:02	gmaxwell:	"okay, we considered something. problem issue closed."
19:00:32	brisque:	looks like they have bigger problems today. they've nuked their database worse than usual.
19:30:15	bsm1175321:	So I'm concerned about "dark hashpower" as a future problem for Bitcoin.
19:30:21	bsm1175321:	bsm1175321 is now known as bsm117532
19:30:35	bsm117532:	That is, as BTC price drops, miners will choose to turn off their mining equipment.
19:31:09	bsm117532:	This creates a situation where, should they choose to attack the network, they could turn it all on for a short period of time and double the hash power of the network, successfully executing 51% attacks.
19:31:48	bsm117532:	Here's a potential solution: make the target difficulty be a function of time.
19:32:02	brisque:	.. no.
19:32:10	bsm117532:	At precisely the block time, the target difficulty will be the expected one.
19:32:27	brisque:	that just means you can partition a person, wait until their difficulty drops, and send them low difficulty blocks.
19:32:30	bsm117532:	At shorter times, the target difficulty is much higher, at later times it drops.
19:32:45	bsm117532:	What does "partition a person" mean?
19:32:51	brisque:	eh I answered something you didn't suggest, but whatever.
19:33:10	lechuga_:	it seems very improbable large enough defunct mining operators would suddenly instantly decide to turn all of their equipment back on again
19:33:13	lechuga_:	to attack the network
19:33:16	brisque:	part of bitcoin is overcoming the problem that you could be isolated from the network and be fed bad information.
19:33:20	lechuga_:	and very likely cause no real gain for themselves
19:34:04	lechuga_:	this is also predicated on the hashrate dropping due to mining reward halving
19:34:13	lechuga_:	its not clear if that will mean a net loss in their revenue
19:34:15	bsm117532:	lechuga_: Imagine the price of BTC drops to the point that the price of running miners is 1/4 of the electricity cost now.
19:34:18	lechuga_:	when bitcoin is at that stage
19:35:02	bsm117532:	Or rather just push BTC price down arbitrarily until people are turning off machines, and then keep pushing it down. What happens on the large scale then?
19:35:40	lechuga_:	u think mining operators would attempt to push the exchange rate with fiat down in an attempt to control more hashing power?
19:35:43	lechuga_:	is that the argument?
19:35:59	bsm117532:	No, let's assume the exchange rate is independent, and becomes low for some reason.
19:36:00	lechuga_:	/ concern
19:36:09	bsm117532:	(any reason)
19:36:14	bsm117532:	What's a miner to do?
19:37:20	lechuga_:	i suppose they would turn off their equipment in an extreme prolonged case
19:37:33	bsm117532:	Then what happens?
19:37:46	lechuga_:	bitcoin is likely already experiencing trouble at this point
19:37:51	lechuga_:	(major)
19:38:05	bsm117532:	I think so too. I'm very surprised the difficulty hasn't dropped yet.
19:38:19	lechuga_:	i mean in your hypotehtical
19:38:23	lechuga_:	i dont actually believe it is
19:38:25	bsm117532:	This event will be detectable by seeing a change in the difficulty curve.
19:39:28	lechuga_:	so why would they turn it all back on at once
19:40:54	lechuga_:	have u ever tried to get 3 toddlers into a car at the same time
19:41:48	bsm117532:	Hahaa. I'm just saying the technical capacity to dump hashing power for a short time will be available to someone.
19:42:06	bsm117532:	Already happens with alt-coins...
19:43:07	lechuga_:	i see your point and it would be interesting to model
19:43:27	lechuga_:	im not going to lose sleep over it
19:45:33	bsm117532:	Ok so the point of this was to present a solution ;-)
19:46:33	bsm117532:	Create a target difficulty that is a function of time. Specifically a function of (t-bt) where bt is the block time (10 min).
19:46:54	bsm117532:	By using a sigmoid function, the target difficulty can be made exponentially larger at short times and exponentially lower at late times.
19:47:25	bsm117532:	This has the effect of keeping the block time closer to the target block time, regardless of changes in hashing power.
19:48:01	bsm117532:	Furthermore rather than retargeting every 2016 blocks, one really should use some kind of moving average for the target difficulty.
19:50:32	gmaxwell:	bsm117532: I thought you groked the non-synchronous network stuff? Making difficulty change without blocks allows huge attacks and even attack-free failure modes.
19:51:03	bsm117532:	Mmmm okay, what don't I understand?
19:52:08	bsm117532:	So given that the network is non-synchronous, (t-bt) is not agreed upon by all nodes.
19:52:14	andytoshi:	bsm117532: by "time" you mean you look at the diff between last two timestamps, and have the difficulty be a direct function of that?
19:52:30	andytoshi:	bsm117532: so, by forging timestamps you can change the difficulty (within whatever limits you set)
19:52:37	gmaxwell:	bsm117532: maybe I don't understand what you're saying. It sounded to me like you're saying that the nodes local clocks ... which isn't agreed on. Also, if difficulty will change rapidly (generally) an attacker can isolate a node then simulate a plausable public network.
19:52:48	bsm117532:	So at some time, a node forms a block based on its evaluation of (t-bt). Other nodes will accept that block (or not) based on *their* evaluation of (t-bt) and whether it is of sufficient difficulty.
19:53:15	andytoshi:	bsm117532: what do you mean by "their evaluation"? are you using local clocks?
19:53:21	bsm117532:	Yes.
19:53:39	sipa:	that's a forking risk for starters...
19:53:49	andytoshi:	there's no consensus on that, and it's not clear how it would work for initial block download/historical blocks..
19:53:53	bsm117532:	A node could create a block of too-low difficulty and submit it, but others would reject it until a later time, if they do not have a higher difficulty block.
19:54:10	bsm117532:	sipa: yes it would create more 1-block forks.
19:54:34	lechuga_:	bsm117532: the proposal is to adjust diffiulty after every block based on an ewma?
19:54:59	bsm117532:	That's one of two proposals I wrote above. The other is that the target difficulty is a function of local time.
19:55:37	bsm117532:	sipa: Do you think the existence of more 1-block forks would be a problem?
19:56:01	gmaxwell:	bsm117532: who says they're 1 block forks?
19:56:45	bsm117532:	No one of course. But everyone would accept the highest difficulty block, even if more were created. So why would any of them persist to the next block?
19:57:41	gmaxwell:	because your clocks disagree and the correct difficulty is some other value.
19:57:57	andytoshi:	bsm117532: can you explain how this protects against 51% attacks?
19:58:23	bsm117532:	gmaxwell: Who cares if clocks disagree, if the network accepts the highest-difficulty solution?
19:58:35	sipa:	if you decrease the difficulty according to some formula, you need to change the amount of work those blocks are counted as too (or you give an advantage to people changing their clock)
19:58:47	andytoshi:	bsm117532: so, suppose that you had no timestamps at all, just "highest block wins"
19:59:03	andytoshi:	bsm117532: well, 1/N of the time you will find a block N times the expected difficulty..
19:59:11	gmaxwell:	bsm117532: Because you just stipluated a new rule above. If it isn't a rule then there are other points to make there.
19:59:23	sipa:	so if your effective difficulty decreases over time, you're actually losing work for that block
19:59:32	sipa:	a 51% attacker does not have that loss
19:59:40	sipa:	so you're giving an attacker an advantag
19:59:50	bsm117532:	This formula would govern when a node decides to create a block and broadcast it to the network, not what other nodes will accept.
19:59:57	gmaxwell:	I'm not sure if you understand how the difficulty of a block is determined. It's a committed value in the block. If it's apparent and not commited the relationship is different (it's double, in the limit of the expectation.. and has huge variance)
20:00:27	bsm117532:	Nodes would accept the highest work block (always) and use local time to adjust their (internal) target difficulty.
20:00:34	sipa:	how is your work defined?
20:00:41	gmaxwell:	Okay fine. So you let people pick their own difficulty and jackasses can always add +1 and reorg out earlier blocks, creating a pressure against consensus (better stand in place an reorg out the latest block)
20:00:44	bsm117532:	sipa: smallest PoW hash.
20:00:47	sipa:	bsm117532: die
20:00:51	bsm117532:	hahahaa
20:01:05	gmaxwell:	thats not a sound definition.
20:01:20	sipa:	that would pretty much instantly break, even in bitcoin
20:01:32	sipa:	1 time in 100, a block would reorganize 100 blocks before it
20:01:43	bsm117532:	Ok what don't I understand then?
20:01:46	gmaxwell:	bsm117532: highest "work block" meaning if I make a block 2 with a lucky low roll I replace the chain? ... presumably this isn't what you mean.
20:01:58	sipa:	work is how much work was expected for that block
20:02:26	sipa:	it's 2^256 / (highest acceptable block hash)
20:02:31	brisque:	if you went by lowest block, a miner could grind block 1 and randomly get a block that reorged the entire network down to one.
20:02:33	sipa:	not 2^256 / (actual block hash)
20:02:42	gmaxwell:	bsm117532: several things. The lowess of the block doesn't tell you the expected work. Rather, hashcash works by commiting to a target in advance and meeting it. If you use the 'apparent' work you end up with something that has huge variance and a mean 2x larger than reality.
20:02:55	gmaxwell:	lowest*
20:03:33	gmaxwell:	Then if you really did just mean the highest block, then you get what brisque said.. and otherwise you get the sand in place race of potentially forever +1 ing the prior block.
20:04:55	bsm117532:	I see what you're saying. This creates a reorg problem.
20:05:12	bsm117532:	The rule of taking the highest work block creates a reorg problem.
20:05:28	sipa:	you *could* commit to a difficulty, and have that difficulty be dependent on the time difference with the previous block
20:06:03	sipa:	but that would mean giving an attacker an advantage, as the amount of work for a block that you could would go down over time
20:06:11	sipa:	which means 'wasted' power
20:08:56	bsm117532:	So by "committing" to a difficulty, the network agrees to accept the first block matching that target. So forks only happen due to network communication latency when two solutions overlap. (no?)
20:09:12	sipa:	yes
20:09:16	bsm117532:	sipa: I think using the last 2 blocks is a better idea
20:09:23	sipa:	same thing
20:09:29	sipa:	just a bit harder
20:09:59	woah:	will energy consumption from mining on a network tend to increase in proportion to the price of the coin?
20:09:59	jtimon:	bsm117532 if price drops, hashrate drops and difficulty adjusts, I don't see what's the problem
20:10:53	jtimon:	if changes are too extreme you may want to hardfork to a different diff filter (at that point you can even hardcode a new current diff)
20:11:12	bsm117532:	jtimon: the concern is fast changes in hashrate.
20:11:20	bsm117532:	faster than difficulty adjustments.
20:11:33	jtimon:	you would change the diff filter
20:11:41	gmaxwell:	bsm117532: In bitcoin the first, valid, most sum difficulty (and difficulty is a commited value in the blocks) chain is the authoritative one from your nodes perspective. (just in case there was any lack of clarity in what bitcoin does)
20:12:03	gmaxwell:	bsm117532: any change to make the system adapt faster creates isolation vulnerabilties. (perhaps small ones)
20:12:32	sipa:	every valid chain is valid; if there are multiple valid chains, the one with the highest sum difficulty is chosen; if there are multiple valid ones with the same highest sum difficulty are chosen, the first _seen_ is chosen
20:12:44	sipa:	the first seen tip block, actually
20:12:58	bsm117532:	But difficulty is only adjusted every 2016 blocks, so increases in hash power result in shorter block times that last 2000 blocks long. No?
20:13:06	sipa:	yes
20:13:24	jtimon:	woah in perfect competition profits tend to zero, that means that the costs (energy and others) that miners are willing to incurr tend to equal the reward (subisdy + tx fees)
20:13:43	sipa:	bsm117532: there's always some deviation between the difficulty and the difficulty optimal for the actual hashrate
20:13:47	gmaxwell:	bsm117532: sure, and also means that an attacker must produce some multiple of 2016 blocks to create a bogus low diff chain to trick an isolated node.
20:13:58	sipa:	the problem is that the actual hashrate cannot be measured, only estimated with limited accuracy
20:14:07	gmaxwell:	blocks being a bit faster or slower is harmless (one reason why the target is 10 minutes)
20:14:33	bsm117532:	Do you know of any analysis for bitcoin's block time? Why not shorter/longer?
20:15:08	sipa:	it needs to be significantly longer than the time needed for a block to propagate through the network
20:15:14	bsm117532:	* bsm117532 kind of wants to create a 5s block time chain and make tons of forks, just to see what goes wrong and if it can be managed sensibly.
20:15:55	sipa:	that's just giving a massive advantage to a 51% attacker (who does not suffer for forks)
20:15:58	gmaxwell:	bsm117532: it was called liquid coin, and it broken into a thousand seperate networks which couldn't reach a consensus but just kept reorging forever.
20:15:59	sipa:	*from
20:16:03	jtimon:	and "the time needed for a block to propagate through the network" depends on the conectivity on the nodes you don't want to exclude from the network
20:16:07	sipa:	at best
20:16:11	sipa:	at worst, what gmaxwell says
20:17:00	bsm117532:	I wonder if block time itself could be dynamically adjusted based on the appearance of forks.
20:17:24	brisque:	no. you can't assume every client has even seen a side chain.
20:17:34	nejucomo:	sipa: Why does that give advantage to a 51% attacker? Shouldn't a recipient base their acceptance of a transaction on the total cost behind verifying a transaction (which is independent of block time, barring fork/join overhead)?
20:17:47	brisque:	how can you prove to me that the consensus rule is now altered based on information I can't verify?
20:18:08	bsm117532:	brisque: Is different nodes having different block times a problem?
20:19:04	nejucomo:	My threshold for acceptance should be "1 hour of Bitcoin mining hashpower" rather than "N blocks" thereof, right?
20:19:16	nejucomo:	-or some product of time and difficulty.
20:19:36	nejucomo:	Blocks are easy to count, I suppose.
20:19:46	sipa:	and hashrate is hard to meaure
20:21:23	Adohgg:	Adohgg is now known as twobltbot
20:21:34	twobltbot:	twobltbot is now known as Adohgg
20:23:31	gmaxwell:	bsm117532: it's possible to do closed loop control of time base on forks but it likely has very very bad incentives.
20:23:45	gmaxwell:	(amiller originally proposed this back in 2011 or 2012 I think)
20:24:10	bsm117532:	Let me put this another way: the hash distribution probability is uniform. I want to filter this probability distribution through a sigmoid function for the purpose of (a) rapidly adjusting to changes in hash rate and (b) centralizing the sigmoid about the desired block time, to achieve more consistent block time.
20:24:25	gmaxwell:	the problem is, then, of course the optimal strategy is for most of the miners to colocate in a single data center and no one more than a few milisconds distance from them can mine at all. :)
20:24:48	bsm117532:	gmaxwell: I see
20:25:09	bsm117532:	Perhaps there's a better way to implement what I want here.
20:25:39	gmaxwell:	bsm117532: This doesn't sound useful... no one cares if the time is that consistent, and to the extent that consistency is important... thats a controls systems question,-- which is its own area of engineering, which I promise almost never involves sticking a hoking infinitely non-linear function in the middle. :)
20:26:37	bsm117532:	Well I care...waiting an hour for confirmation is painful and I'd like it to push it as short as possible, in the long run... ;-)
20:27:46	tromp:	then you'll be happy to use Ethereum with its 12s block interval
20:28:13	bsm117532:	Maybe. If they can keep that.
20:28:52	dgenr8:	bsm117532: see nimblecoin. 5s blocktime simulation amongst others
20:30:24	bsm117532:	dgenr8: thanks!!!
20:30:36	gmaxwell:	bsm117532: so, you can trivially have 100ms confirmation, just use a centeralized signer. Done.
20:30:43	tromp:	surprisingly no coin has ever picked a block interval larger than 10min?!
20:31:29	brisque:	because that doesn't sell well.
20:31:31	bsm117532:	tromp: have you ever developed a system and had to wait hours to see if your code worked? My eyeballs don't need any more forks in them.
20:31:34	tromp:	for many uses, a one day wait for 6 confirmations would be ok
20:31:42	gmaxwell:	Don't defraud people by building a design that will natrually become the same trust model as the centeralized signer (because physics prevent you from mining more than a short distance from a single place in the universe), but obfsucate the trust model with a lot of overhead and inefficiency.
20:32:23	tromp:	bsm117532: testing can easily be done on accelerated time
20:32:43	gmaxwell:	tromp: 95% of the people working on altcoins don't have any clue what the time between blocks for is for at all. Some totally idiotic attempts have just replaced the timing with a fixed N minute timer.
20:32:52	bsm117532:	tromp: attacks only happen on non-accelerated time.
20:33:07	bsm117532:	gmaxwell: I've been wondering about that...
20:33:10	jtimon:	actually some systems do care more about block times than others, like freicoin where the demurrage depends on block counts (or another system using the same mechanism for itnerests)
20:34:35	jtimon:	but IMO "fastcoins" are stupid, they are "the coins that produces orphan blocks faster!!"
20:34:43	tromp:	a 4 hour block interval would allow for some seriously memory hard pow
20:34:46	gmaxwell:	bsm117532: there are completely seperate mechenisms that can be used for very fast confirmations which don't present these tradeoffs.
20:35:13	bsm117532:	gmaxwell: Yes, I need to read more about them.
20:35:30	lmatteis:	hello. i know this is a rather biased question given this is a bitcoin channel, but i was wondering what is the most interesting alt-coin to study/follow purely based on technical/innovative perspective
20:35:32	bsm117532:	gmaxwell: Also still waiting for sidechain implementations to appear from the vapor...
20:35:40	dgenr8:	gmaxwell: quite agreed
20:35:42	gmaxwell:	tromp: yes, longer times could be justified. Though it's actually good for the network as a whole to have some progress, so that an attacker actually has to race. (progress just has to be so limited so that single large miners don't enjoy an advantage mining selfishly)
20:35:58	brisque:	tromp: doesn't all this get into issues with not being progress-free?
20:36:06	gmaxwell:	brisque: opposite!
20:36:08	brisque:	er gmaxwell beat me to it.
20:36:12	brisque:	and I got it wrong.
20:37:13	gmaxwell:	haha.. four hour progress free blocks are fine, but they potentially have less security than .. say.. 10 minute blocks. Because the network making some progress also works against the attacker. (e.g. the network has the 'progress' gain)
20:37:24	tromp:	well, you have to view progess freeness as relative to those 4 hours, and consider a 5 min proof attempt to still be "fast" enough
20:37:30	gmaxwell:	er less security than waiting for 24 10 minute blocks.
20:37:53	gmaxwell:	ah, I see the point you're making is that you can make attempts slower but still effectively progress free.
20:38:29	jtimon:	bs117532 aren't 0 confirmation txs better than fast confirmations? here's an explanation (not my idea) http://sourceforge.net/p/bitcoin/mailman/message/32263765/
20:38:37	tromp:	the point is that the block interval should allow a few dozen proof attempts
20:38:43	gmaxwell:	I agree. (#include )
20:39:19	dgenr8:	gmaxwell: do you have a reference making a case for not-progress-free?
20:39:32	brisque:	isn't the problem with not being progress-free that the fastest clocked has a significant advantage?
20:39:48	jtimon:	Imatteis I'm biased but IMO freicoin is by far the most intersting altcoin ;)
20:40:02	tromp:	i like the idea of a pow requiring > 8GB as making it essentially botnet and GPU esistant
20:40:26	brisque:	today.
20:40:38	brisque:	today GPUs have 4GB of memory, what about next year?
20:40:41	tromp:	but that defininitely requires a very large block interval time
20:41:17	tromp:	the pow can scale in size over time, just like difficulty is scaled now
20:42:07	brisque:	that doesn't sound smart, doesn't that mean that with enough hardware you could push most of the other miners out of being able to complete the PoW at all?
20:42:58	tromp:	no more easily than with current bitcoin pow
20:43:00	bsm117532:	Let me go back a page or two. Is there any problem with using the EWMA of recent PoW hashes to set the target difficulty, rather than recalculating every 2016 blocks? Is there any reason such a thing would be better (or worse)?
20:43:55	nejucomo:	bsm117532: Lowering the block time does not lower confirmation time for a given level of desired assurance.
20:43:59	tromp:	what's EWMA?
20:44:14	brisque:	tromp: no, today increasing the speed never means that an old miner can't mine. if increasing the speed increases the memory requirements, you get to the point where portions of the network can't mine at all anymore.
20:44:16	bsm117532:	EWMA = Exponentially Weighted Moving Average. Intended to respond to fast changes in hashrate.
20:44:26	nejucomo:	I suppose it does allow lower than 10-network-minute levels of assurance.
20:44:31	brisque:	oh god this is going into an altcoin now.
20:45:06	jtimon:	bsm117532 again, you need to focus on what problem you're trying to solve, is it accept transactions fast? is it high hashrate variance?
20:45:20	bsm117532:	jtimon: hashrate variance.
20:45:34	tromp:	brisque: that's right, portions like majority of botnets wont be able to mine at all
20:45:38	bsm117532:	Forget about fast block time for the moment.
20:45:49	jtimon:	then what's the problem with 10 min blocks?
20:45:51	nejucomo:	bsm117532: Imagine bitcoin had 1ms block times, the same mining infrastructure as today, and magical instantaneous block propagation. Now, what's the difference between waiting for "10 seconds of confirmation" versus just assuming the other party is not malicious?
20:45:59	jtimon:	ok
20:46:26	nejucomo:	The difference is 10 seconds worth of confirmation. How much is that worth?
20:46:45	bsm117532:	nejucomo: I give up, what's the difference?
20:46:53	brisque:	tromp: I don't see why that's of a concern. they can't mine today either.
20:47:15	dgenr8:	jtimon: yes, 0-conf is a rich area for exploration. satoshi called it a "version 2 problem" that "can be solved fairly
20:47:15	dgenr8:	satisfactorily for most applications"
20:47:40	nejucomo:	Let me try to ask another way: Suppose there are 10 second blocks and no forking issues. In what cases would you prefer a single 10 second block confirmation over 0 confirmations?
20:48:05	bsm117532:	nejucomo: Oh you're going after 0-conf (which is always better).
20:48:08	nejucomo:	(This is an honest question about use cases, not a rhetorical question.)
20:48:21	bsm117532:	If you can do 0-conf.
20:48:35	nejucomo:	I'm not familiar with 0-conf.
20:48:41	bsm117532:	Ok then you've lost me.
20:48:59	tromp:	brisque: so miners may have to add memory to their rig from time to time
20:49:01	helo:	nejucomo: the actual security you get from 10 seconds of hashing isn't very high
20:49:36	nejucomo:	I meant merely accepting the risk that the payer is double spending and waiting 0 seconds for confirmation, versus waiting 10 seconds for a single "fast block" confirmation.
20:49:41	helo:	so the risk of accepting a 1-conf is much higher
20:49:48	nejucomo:	In what use cases is each preferable?
20:50:21	helo:	10 seconds means people will (ab)use it for all kinds of little piddly stuff, and the blockchain will get bloated
20:50:49	helo:	think it is suitable to use for buying 3 meals each day etc
20:51:17	nejucomo:	helo: That's my intuition. My intuition is that for every case where a 10 second confirmation would be used, the risk of 0 seconds of trusting the sender is a worthwhile trade-off for much less technical complexity.
20:54:01	nejucomo:	The decision about how much verification to require before accepting a payment actually should consider all other transactions in the given block and recent previous blocks, actually, since those other transactions may represent a different amount of risk of rollbacks...
20:54:44	nejucomo:	ie: If I am receiving 1 bitcoin, but there's also a 1 million btc transfer in the same block, then the incentive to rollback that entire block is much different than if my transaction is alone in a block.
21:22:22	bsm117532:	I've been bouncing around an idea of securing a blockchain by transactions instead... half baked at this point, but I think there might be a way.
21:22:36	bsm117532:	Because on most markets the transaction volume is much greater than the assets of any participant.
21:23:08	brisque:	markets have nothing to do with the block chain
21:23:22	brisque:	and indeed the block chain has no WAY of knowing markets even exist.
21:23:55	sipa:	and the purpose of the chain is linearizing transactions
21:24:14	sipa:	using transactions instead implies you need some external serialization mechanism
21:26:07	bsm117532:	External transactions.
21:26:27	bsm117532:	Internal transactions is PoS and largely doesn't work. PoW uses external incentives, and I think that's part of why it works.
21:27:33	bsm117532:	The required transaction has to be of the form that it forces nodes to commit external resources to one fork or another (to solve the "nothing at stake" problem).
21:27:55	bsm117532:	But "external resources" doesn't have to be computational work. There are other external resources...
21:33:10	waxwing:	interesting question whether there are really other resources than energy. time doesn't count because it doesn't really exist :) space maybe. true that certain materials are very difficult to get from energy (nuclear reactions are troublesome).
21:37:11	bsm117532:	waxwing: IBM stock. Gasoline futures. Government T-bills. If you're willing to commit something with external valuation, it might work to achieve consensus.
21:37:43	lechuga_:	waxwing: think just energy :)
21:37:47	waxwing:	contracts don't count as a limited resource.
21:38:47	lechuga_:	i wonder if ghash.io will ever build a dyson sphere
21:40:46	lechuga_:	i should make a kickstarter
21:40:54	lechuga_:	or better yet a lighthouse project
21:41:21	waxwing:	saw something recently explaining why dyson spheres are basically physically impossible. obvious in retrospect but disappointing anyway :)
21:41:29	lechuga_:	:/
21:41:41	lechuga_:	they said bitcoin was impossible too :)
22:15:38	nejucomo:	To the dyson sphere!
23:06:15	digitalmagus7:	digitalmagus7 is now known as digitalmagus8
23:38:29	a5m0_:	a5m0_ is now known as a5m0