02:21:47	rhadamanthus:	rhadamanthus has left #bitcoin-wizards
04:35:15	rhadamanthus:	rhadamanthus has left #bitcoin-wizards
04:41:49	rhadamanthus:	rhadamanthus has left #bitcoin-wizards
05:09:01	fanquake_:	fanquake_ is now known as fanquake
05:26:36	siraj:	how are governments supposed to tax people in a DAO world? When everything is a DAO, nothing has to be incorporated, no tax forms required, earnings are pseudonymous since its all in crypto, income tax becomes impossible. if governments aren't able to tax people forcibly, how are things like public roads going to get funded and avoid the free rider problem? crowdfunding can't work for everything?
05:27:17	op_mul:	siraj: off topic, #bitcoin or #mild-paranoia
05:30:26	VOA:	VOA has left #bitcoin-wizards
05:34:27	gmaxwell:	hopefully someone in #bitcoin gives his insane question a reasonable answer.
05:35:30	phantomcircuit:	gmaxwell, he didn't ask it
05:38:25	siraj:	siraj has left #bitcoin-wizards
05:40:02	siraj:	siraj has left #bitcoin-wizards
05:47:20	jcorgan:	would it be considered #mild-paranoia to entertain the notion that TLAs have funded a program to send trolls to #bitcoin* ?
05:47:27	jcorgan:	:)
05:48:46	phantomcircuit:	jcorgan, there's been a decided uptick in crazy people recently
05:49:58	jcorgan:	yes. disturbingly so. just when bitcoin was getting boring and conventional.
05:51:53	gmaxwell:	I dunno I think it just comes in cycles, probably because its a small number of bad apples with many identities.
05:53:00	phantomcircuit:	maybe
05:53:04	phantomcircuit:	actually... probably
05:55:54	jcorgan:	i have to say i've been a participant in many communities over the years, and this one seems to attact the largest number of otherwise seemingly normal people suddenly going off on conspiracy rants.
05:56:49	jcorgan:	maybe just wide tails. lots of people at the other end, too.
05:58:29	op_mul:	I think it's just a subject that attracts that sort of person.
05:58:57	fanquake_:	fanquake_ is now known as fanquake
05:58:59	op_mul:	bitcointalk has some of the highest levels of insanity that I've ever seen on any forum.
05:59:03	jcorgan:	ah, well. back to your regularly scheduled -wizards
05:59:28	op_mul:	op_mul is now known as andytoshi-logbot
05:59:32	andytoshi-logbot:	* andytoshi-logbot is logging
05:59:38	andytoshi-logbot:	andytoshi-logbot is now known as op_mul
06:03:11	siraj:	siraj has left #bitcoin-wizards
06:06:31	siraj:	siraj has left #bitcoin-wizards
06:06:46	fanquake_:	fanquake_ is now known as fanquake
07:25:16	amincd:	As I understand it, having a UTXO commit in the block header is resource-intensive because it requires miners to continuously calculate new UXTO merkle root hashes as they include new transactions in the block they're working on. How about putting the merkle root of the UTXO set of the PREVIOUS block in the block the miner generates?
07:26:01	amincd:	And that way light clients can only store the last block, and the UTXO, to verify whether a transaction is valid
07:28:07	amincd:	*and the UTXO set
07:28:37	amincd:	or just the commit of the UTXO set
07:31:40	amincd:	s/store the last block/store transactions generated since the last block/
07:32:56	sipa:	amincd: that's an idea that has been suggested; i believe that's reasonable
07:33:37	amincd:	sipa: thanks for your assessment
07:34:17	gmaxwell:	amincd: it doesn't change the work required, though it would reduce the latency impact.
07:35:03	amincd:	gmaxwell: you only need to calculate the UTXO merke root once in this implementation, as opposed to every time a new tx is received
07:35:39	gmaxwell:	amincd: You don't otherwise need to compute it every time a new tx is recieved.
07:35:47	sipa:	you don't do it for every new transaction; just for every attempted block
07:36:07	sipa:	but that is likely still more than once
07:36:28	gmaxwell:	one will still need potentially a factor log(utxo size) more IO to process each utxo update, you just have more time to do it. Having more time /may/ result in more batching gain, but if the tree is large compared to the number of entries updated the batching gain is small.
07:41:09	phantomcircuit:	http://arstechnica.com/tech-policy/2015/01/silk-road-trial-how-the-dread-pirate-roberts-embraced-violence/
07:41:10	phantomcircuit:	"Every bitcoin transaction is published in a kind of digital-age public ledger at the blockchain.info website."
07:41:12	phantomcircuit:	for shits sake
07:41:41	justanotheruser:	phantomcircuit: andreas will be talking at the trial soon
07:42:58	op_mul:	phantomcircuit: my money is on some government raiding blockchain.info thinking they are the heart of bitcoin.
07:43:20	phantomcircuit:	op_mul, that would be
07:43:21	phantomcircuit:	lol
07:43:25	phantomcircuit:	i can see that happening
07:43:42	justanotheruser:	I hope they're smarter than that
07:43:50	op_mul:	there's a story in the bitcoin issues where someone is arrested based on the "relayed by" ip address blockchain.info shows.
07:44:20	justanotheruser:	I think a bc.i raid is a bit different, but I suppose it could happen
07:48:24	op_mul:	I was going to host DNS seeds at one point, and then realised they probaby attract a lot of unwanted attention.
07:48:40	op_mul:	if you wanted to poison new clients coming into the network, that's an easy target.
07:49:41	op_mul:	just make a bunch of nodes, have your seed only return those nodes, done.
07:58:08	phantomcircuit:	oops wrong channel
07:58:39	phantomcircuit:	you don't do it for every new transaction; just for every attempted block
07:58:45	phantomcircuit:	that is likely every transaction
07:58:54	phantomcircuit:	or very nearly so
08:01:58	gmaxwell:	phantomcircuit: bitcoin core won't even update the block template more than once every 30 seconds or so.
08:11:31	phantomcircuit:	gmaxwell, sure but it's easy enough to construct the merkle tree root yourself from the mempool
08:11:40	phantomcircuit:	just gotta get the dependency order right
08:12:08	phantomcircuit:	but yeah i bet most pools are lazy and assume getblocktemplate returns a sane list of transactions
08:12:46	op_mul:	if I was a large scale miner it would just be "you are not getting confirmed today".
08:12:55	op_mul:	(so not risking 25 BTC on my crashy code)
08:13:29	phantomcircuit:	op_mul, it's super trivial to get the transactions ordering correct
08:13:37	phantomcircuit:	the hard part is getting the multisig limits right
08:13:51	phantomcircuit:	it's trivial to check that you got them right though
09:05:14	verne.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:14	verne.freenode.net:	Users on #bitcoin-wizards: andy-logbot siraj SDCDev cbeams NewLiberty Graftec devrandom adlai orperelman CoinMuncher damethos GibsonA moa dgenr8 delll bosma_ fanquake cluckj TheSeven adam3us tromp_ copumpkin coiner HaltingState prodatalab_ amincd zooko d1ggy__ p15 op_mul Meeh nuke_ SubCreative hashtagg_ waxwing iddo mkarrer roconnor e1782d11df4c9914 binaryatrocity koshii antgreen` GAit wizkid057 so HM2 berndj wiz espes__ ebfull Krellan brand0 kinlo DougieBot5000
09:05:14	verne.freenode.net:	Users on #bitcoin-wizards: Guest46695 jaekwon epscy_ phedny btcdrak sneak lnovy d9b4bef9 crescend1 Taek azariah eric livegnik asoltys_ pigeons catlasshrugged kanzure heath lclc_bnc JonTitor yrashk fenn Adrian_G throughnothing helo Graet Apocalyptic lechuga_ ahmed_ ajweiss ryan-c Xzibit17 @ChanServ smooth DoctorBTC BananaLotus tripleslash petertodd bbrittain Keefe s1w nanotube morcos Eliel_ cfields forrestv mr_burdell jaromil EasyAt Fistful_of_Coins jcorgan weex optimator
09:05:15	verne.freenode.net:	Users on #bitcoin-wizards: coryfields jbenet Oizopower platinuum mappum kumavis Muis CryptOprah K1773R gribble warren veox dardasaba michagogo qwopqwop rw_8197 Emcy_ sipa cryptowest fluffypony deego artifexd amiller LarsLarsen hashtag tromp dasource^ poggy NikkiBenz null_radix comboy_ bobke_ Anduck MoALTz gmaxwell Hunger- nick1234abcd__ PFate use_zfs_yo btc___ midnightmagic Cory davout earlz brad_ nsh catcow yoleaux sl01 gnusha phantomcircuit alawson luny` a5m0 huseby
09:05:15	verne.freenode.net:	Users on #bitcoin-wizards: Logicwax Luke-Jr justanotheruser Iriez harrow starsoccer Starduster_ Alanius nickler Guest64313 MRL-Relay hollandais Dyaheon- wumpus BlueMatt burcin_ hguux__ sdaftuar_ BrainOverfl0w jgarzik ryanxcharles isis CodeShark PaulCapestany kobud dansmith_ grandmaster2 gwillen OneFixt roasbeef andytoshi maaku warptangent spinza_ TD-Linux stonecoldpat [d__d]
10:16:02	lclc_bnc:	lclc_bnc is now known as lclc
11:54:28	NikkiBenz:	NikkiBenz is now known as hexafluorideisaw
11:55:24	hexafluorideisaw:	hexafluorideisaw is now known as AlexisTodorov
11:57:12	AlexisTodorov:	AlexisTodorov is now known as AlexiTodorov
12:03:26	aburan28:	aburan28 is now known as aburan
12:34:32	Pan0ram1x:	Pan0ram1x is now known as Guest56212
12:48:25	stonecoldpat:	was good to meet some people last week! even if it was only briefly at some points :) now back to work... !
13:33:08	fanquake_:	fanquake_ is now known as fanquake
13:45:40	fanquake_:	fanquake_ is now known as fanquake
13:59:35	fanquake_:	fanquake_ is now known as fanquake
14:01:25	jgarzik:	jgarzik is now known as jgarzik_
14:12:37	fanquake_:	fanquake_ is now known as fanquake
14:18:14	fanquake_:	fanquake_ is now known as fanquake
14:23:28	fanquake_:	fanquake_ is now known as fanquake
14:46:52	fanquake_:	fanquake_ is now known as fanquake
14:51:39	fanquake_:	fanquake_ is now known as fanquake
15:01:14	fanquake_:	fanquake_ is now known as fanquake
15:16:59	fanquake_:	fanquake_ is now known as fanquake
15:38:08	zooko:	stonecoldpat: I didn't get a chance to say Hi, but I really enjoyed your talk.
15:38:18	fanquake__:	fanquake__ is now known as fanquake
15:43:42	fanquake_:	fanquake_ is now known as fanquake
15:53:56	stonecoldpat:	zooko: no worries, there were too many people to get talking to everyone (i took myself off to the jacuzzi quite often), I seen your twitter posts yesterday, cheers for the shout out about the talks :P
15:54:27	nsh:	what was the talk about?
15:55:26	stonecoldpat:	nsh: it was to do with using the bitcoin network as a command & control center for bots (so you can send commands as a legitimate bitcoin transaction)
15:55:48	nsh:	ah
15:57:41	stonecoldpat:	the idea itself isn't that complicated, its just thinking about what we can do about it, i think the crowd pretty much went with the idea of trying to make the network less attractive compared to other methods (so the fact that all commands are stored on the blockchain, may decourage people), so myself/taha (colleague) are gonna start looking into that aspect
15:59:57	nsh:	* nsh nods
16:09:51	hearn:	stonecoldpat: command line flag that downloads IP blocklists (or uses signed message p2p broadcast like alerts). botnet nodes, once identified, go on the ban list
16:12:31	fluffypony:	and then when that person has removed the malware they're banned forever
16:13:06	fluffypony:	and if you want to piss your boss / friend / neighbour off, just get them added to the IP ban list
16:15:51	Luke-Jr:	hearn: wtf? that's disturbingly centralised
16:16:19	hearn:	fluffypony: the assumption is the "these are botnet ips" list isn't maintained badly, yes
16:16:44	hearn:	Luke-Jr: if you have a good, robust, decentralised algorithm that can be quickly implemented and deployed to identify botnets using the block chain as a C&C network, i'm all ears
16:16:58	Luke-Jr:	hearn: better to not do anything, than to make Bitcoin centralised
16:17:20	fluffypony:	Luke-Jr: yeah that's nearly as bad as making address blacklists mandatory on Gentoo
16:17:22	fluffypony:	you tell him, Luke-Jr
16:17:51	Luke-Jr:	fluffypony: this is not a place for you to troll. I did nothing of the sort.
16:19:05	fluffypony:	hearn: I think it's infeasible to try and stop it - they can submit C&C signals as mined tx's, and bots can receive them via SPV / Electrum / blockchain explorers
16:19:23	hearn:	hence the simple IP list approach
16:19:44	hearn:	assuming someone, somewhere has a way to detect the botnet, that will interfere with it enough that maybe they'll go back to IRC or their own p2p network or whatever they were using before
16:19:46	hearn:	doesn't have to be perfect
16:20:26	fluffypony:	yeah, but if the bots aren't ever connecting to actual Bitcoin nodes then what are you going to block?
16:24:11	hearn:	if they aren't connecting to actual bitcoin nodes then where's the problem?
16:25:11	fluffypony:	ok let me explain the hypothetical more clearly:
16:25:55	fluffypony:	1. C&C command is packed into OP_RETURN and sent as a tx with some magic flag (say to a specific address within a group, or even to the next in a deterministic set of addresses)
16:26:20	fluffypony:	2. bots watch blockchain explorers, or connect to Electrum servers, to check for activity on that address, and then follow the C&C command
16:27:40	luny`:	luny` is now known as luny
16:27:47	AlexiTodorov:	AlexiTodorov is now known as AlexeiTodorov
16:30:09	hearn:	fluffypony: i understand the threat. i have discussed stonecoldpat's paper with the authors
16:30:24	hearn:	fluffypony: my point is - in that case, Not Our Problem. the operators of those servers can block the bots
16:30:47	hearn:	the risk of botnets abusing the block chain in this way is partially reputational, but botnets abuse everything so that's not such a big thing, and mostly load related
16:31:21	fluffypony:	yep I agree
16:37:27	stonecoldpat:	I don't know if there could be an algorithm to determine the bots and blacklist them (of course an anti-virus/malware can if installed on the infected machine, but i mean, if I were to try and identify other nodes that 'may' be bots on the network), in our example they were standard spv clients (so just normal nodes connected to the network), if they have bloom filters you could
16:37:27	stonecoldpat:	identify, but I don't imagine they would set a bloom filter (i didn't have bloom filters for awhile by mistake).
16:38:16	dansmith_:	dansmith_ is now known as dansmith_btc
16:39:49	stonecoldpat:	although their lack of activity (broadcasting their own transaction) could help (as its unlikely they will be sending a transaction), id be interested to know how often an average node broadcasts a new transaction to the network.
16:44:12	hearn:	stonecoldpat: remember that botnets do things beyond download commands
16:44:20	hearn:	stonecoldpat: the people the botnet is actually attacking will be able to spot them and produce IP lists
16:44:48	hearn:	stonecoldpat: we don't need (and I'd argue against) some kind of automatic botnet detector. all we need is better load management, and a way to shed load if there is too much
16:50:49	stonecoldpat:	hearn: true, that is a good way to get their IP, but i don't imagine the community would accept a blacklist approach using data given to them by a third-party who got "attacked"
16:51:05	stonecoldpat:	although on the mention of load management, it is interesting(came up in a convo last week) that at the moment there is no incentive for bitcoin servers (people who accept incoming transactions) to actually propragate transactions
16:51:16	hearn:	if bitcoin is broke because of all the bots trying to grab their instructions, i think they would
16:52:03	hearn:	but debates about what "the community" would do in random hypothetical situations are a bit dull. it can be argued either way
16:52:12	hearn:	doh
16:52:15	hearn:	of course there is incentive
16:52:18	hearn:	the incentive is "bitcoin works"
16:53:03	stonecoldpat:	thats the only incentive though which is essentially people's good will (who want to see it work)
16:53:36	fluffypony:	stonecoldpat: all consensus systems need at least some rational actors:)
16:54:24	hearn:	it's not good will, it's self interest - there's no point in running a bitcoin node or holding bitcoins if the system breaks. yes, you can get stupid/evil nodes, but the network can tolerate some of them as long as the connectivity is good enough
16:55:36	stonecoldpat:	argubly though, servers could just propragate transactions that interest them directly to the miners, theres no real reason for them to propragate other people's transactions which have nothing to do with them
16:55:48	stonecoldpat:	so for them, bitcoin would work, but not for everybody
16:55:59	hearn:	yes, there is
16:56:12	hearn:	gah :) i think i need to write an FAQ or essay on this, as variants of it come up so often
16:56:21	hearn:	money circulates. money that doesn't circulate is useless, including to the person holding it or trying to spend it
16:56:43	hearn:	there is no such thing as a transaction that "interests me directly". *any* transaction that doesn't pay me, might be the basis for one that does tomorrow
16:58:01	hearn:	bitcoin is designed to tolerate a minority of abusive or malicious nodes. it can't function if every node simultaneously decides to try and make micro-savings today with no regard for tomorrow
16:59:13	stonecoldpat:	in the real world, money circulates as someone is always profiting from it (person to person sales, bank to bank, etc), in bitcoin thats not the case, those middle-men who handle the flow of transactions on the network don't make anything but a working system that they may benefit from in the future, if bitcoin were to achieve visa-levels of transactions, i don't think people would
16:59:14	stonecoldpat:	still run bitcoin servers for free
16:59:14	kanzure:	can you demonstrate that
16:59:35	ajweiss:	if i was running a business that depended on the success of bitcoin, it is in my interest to run a few nodes and propagate transactions that don't directly interest me
16:59:58	hearn:	stonecoldpat: how do you know? perhaps by the time bitcoin is visa-level successful my smart watch will have a terabyte of ram
17:00:13	hearn:	i mean, bitcoin isn't going to handle that level of traffic anytime soon absent a major and unexpected change in how people use the network
17:00:23	kanzure:	hearn: arguably if it cannot function under a specific threat that you can identify, then you should be working on a proposal to mitigate that threat
17:01:27	hearn:	kanzure: that's the sort of thinking that dominated the security community in the 1990's and yielded horribly unusable software that nobody cared about. attempting to address every imaginable threat, no matter how realistic and no matter how costly the solution, results in "password written on yellow sticky notes" type problems
17:01:39	hearn:	kanzure: but sure if you can find a solution that has reasonable cost/benefit tradeoffs, and convince people of that, go for it
17:01:42	stonecoldpat:	thats the dream, and ajewiss: most good businesses would, but we could do better than that i think
17:01:44	kanzure:	node-majority threats are obviously not going to crash the bitcoin network, i'm not sure why you are saying that it would
17:01:59	kanzure:	i know you like to hate on distributed consensus, but you should put more thought into your complaints
17:02:19	kanzure:	the number of broken nodes does not directly influence whether or not proof of work is broken, for example
17:02:24	stonecoldpat:	it would be good if miners and bitcoin servers could both make a profit, make bitcoin server businesses who are dedicated to building a reliable network
17:02:28	hearn:	who is complaining? not me. i was responding to stonecoldpat saying that bitcoin shouldn't work because nobody has incentives to relay transactions :)
17:02:51	kanzure:	you are constantly complaining about malicious nodes
17:03:04	kanzure:	i mean, constantly complaining about bitcoin not being designed to handle malicious behavior
17:03:12	kanzure:	(sorry, i was imprecise)
17:03:23	hearn:	oh for goodness sake. no, i am not. i didn't even start this conversation.
17:03:24	stonecoldpat:	haha i didn't mean to say it shouldn't work, but I think it may deserve some attention for people to tuink about
17:04:02	hearn:	stonecoldpat: it's easy to do what you want - add some basic authentication protocol to p2p and then teach clients how to authenticate. charge for accounts.
17:04:19	kanzure:	haha what
17:04:20	hearn:	stonecoldpat: hey, it might even become a reasonable business model soon, not for tx relaying but because bloom filtering is sometimes a bit slow.
17:04:38	hearn:	stonecoldpat: but for tx relaying you have the problem of several thousand competitors who are charging zero
17:04:44	stonecoldpat:	perhaps even if the bitcoin server has 'better bandwidth' compared to others, so businesses could have a fast lane due to them helping the network, (lets not compare this to ISPS! more a thought)
17:05:47	stonecoldpat:	"prove to me you gave propragated my transaction, and i'll give you a better service in the future for it" - type of agreements
17:09:20	stonecoldpat:	hearn: while it would be good not to have a real charge (as im a cheapo), but that type of business could exist in the future if the network got really popular
17:09:29	hearn:	yup
17:09:33	hearn:	or many different interacting networks
17:09:38	hearn:	an interbitcoinnet
17:09:45	stonecoldpat:	lol
17:11:24	stonecoldpat:	i'm pretty sure there is something at the moment for miners, like a miners fast lane? (i've heard it on the grapevine, but dont know much about it), but I imagine if the blocksize did get increased, miners would rely on that more than the actual network and i'm sure someone may try to profit off that as well
17:14:23	justanotheruser:	at least in the past, most large miners were connected to most other large miners directly
17:17:29	dasource^:	dasource^ is now known as dasource
17:20:08	fluffypony:	stonecoldpat: are you thinking of BlueMatt's backbone thing?
17:21:45	fluffypony:	RelayNode
17:25:43	stonecoldpat:	yes, and by googling that I found a thread that discusses the idea about node incentives (y)
17:43:04	hearn:	stonecoldpat: yes bluematt's miner backbone network. i am not sure if there's any data showing it's useful, though
17:43:30	hearn:	stonecoldpat: iirc there was an attempt to get some pool owners opinions and the only answers that came back were like "we have bigger things to worry about that orphan rates right now"
17:45:07	bosma_:	bosma_ is now known as bosma
17:48:04	Iriez:	Iriez is now known as _Iriez
18:27:54	BlueMatt:	hearn: naa, most pools use it now
18:28:14	hearn:	BlueMatt: yeah but do they know how much it helps?
18:30:01	BlueMatt:	hearn: it seems to work pretty well, but its hard to tell....orphan rates are pretty low to begin with
18:30:09	hearn:	yeah
18:32:02	BlueMatt:	hearn: there has been one case where the code fucked up and the server didnt relay and it was pretty clear the orphan would have been avoided if it had worked
18:32:11	hearn:	hm, ok
18:32:26	hearn:	that's an interesting data point
18:35:38	ajweiss:	did the miner publish out on the regular network too?
19:30:05	fanquake_:	fanquake_ is now known as fanquake
19:35:56	SDCDev:	SDCDev is now known as St[3]baS
19:36:23	St[3]baS:	St[3]baS is now known as St2baS
19:38:26	St2baS:	St2baS is now known as |2ynomster
19:41:21	|2ynomster:	|2ynomster is now known as Rynomster
20:16:24	antgreen`:	antgreen` is now known as antgreen
20:18:33	Dizzle_:	Dizzle_ is now known as Dizzle
21:35:35	d1ggy__:	d1ggy__ is now known as d1ggy
22:40:01	nsh:	A Practical Methodology for Measuring the Side-Channel Signal Available to the Attacker for Instruction-Level Events -- http://users.ece.gatech.edu/~az30/Downloads/Micro14.pdf
22:58:56	earlz:	So, what is a decent way to store and query blockchain data?
22:59:06	kanzure:	wrong channel
22:59:10	earlz:	A faster way than just scanning through the blocks
22:59:14	earlz:	eh. what channel then?
22:59:17	kanzure:	-dev
23:01:53	fanquake_:	fanquake_ is now known as fanquake
23:07:12	imposter:	imposter has left #bitcoin-wizards
23:23:11	crescend1:	crescend1 is now known as crescendo
23:41:10	_Iriez:	_Iriez is now known as Iriez
23:54:14	Luke-Jr:	earlz: the answer is "no" ;)