00:31:58	OneFixt_:	OneFixt_ is now known as OneFixt
02:29:40	prodatalab_:	prodatalab_ is now known as prodatalab
03:11:26	lechuga_:	re: compact spv proofs, how will the verifier know the lucky PoWs actually exist in the chain? are they given merkle nodes to prove it?
03:12:19	rusty:	lechuga_: the proposal was to include a merkle of all previous block hashes in each block, so yes.
03:13:02	manara:	where can i learn more about the implementation of spv proofs?
03:13:36	lechuga_:	rusty: i thought only the root of the merkle was going to be added to blocks
03:14:17	rusty:	lechuga_: Yep, that was my "so yes": you need the merkle proof.
03:14:49	lechuga_:	i feel like i'd get so much more clarity with a simple drawing
03:16:42	rusty:	lechuga_: well, it's hard to draw all N-1 blocks being merkled into block N, for any reasonable N :)
03:16:44	gmaxwell:	lechuga_: what does 'added' in a block mean? in one sense a block is only 80 bytes, everything is just under a hash. In the case of the commitments to prior blocks, anyone who would validate that block normally inherently knows the prior blocks, so you don't need to include anything but the hash. When one prepares a proof you go and expand out the hash walking... basically walking back in leaps
03:16:50	gmaxwell:	and bounds through past blocks by traversing down the hash tree.
03:17:00	gmaxwell:	rusty: right but it works if you just show a few in any case.
03:17:41	lechuga_:	gmaxwell: added == 32 more bytes to the block header for the merkle root
03:17:56	rusty:	lechuga_: naah, you can stash it in the coinbase.
03:18:02	lechuga_:	oh derp sure
03:18:52	gmaxwell:	lechuga_: in a new system you likely would move a number of things higher up. Not to the header perhaps.
03:27:29	lechuga_:	so the proof is going to be something like a 'merklechain' msg which is similar in structure to a 'merkleblock' which will also be part of the proof for the block the tx exists in
03:27:40	lechuga_:	is that close to right?
03:28:42	rusty:	lechuga_: One step back. What are you using compact spv proofs for? Sidechains?
03:28:56	lechuga_:	trying to understand them in the context of sidechains, yeah
03:33:57	rusty:	lechuga_: it's a good question, I haven't seen a precise proposal as to how it would be encoded in the scriptSig. It's interesting, because the proof is going to be pretty big.
03:34:34	lechuga_:	i'm really terrible at reading an academic paper and seeing the code
03:35:19	rusty:	lechuga_: me too. Though in my case clarity was only provided by clue drops from gmaxwell :)
03:36:19	gmaxwell:	well maaku's post is helpful if you haven't seen it.
03:36:46	gmaxwell:	http://sourceforge.net/p/bitcoin/mailman/message/32111357/
03:36:47	lechuga_:	i actually got more mileage out of the high-value-hash-hwy thread
03:37:03	gmaxwell:	Probably not.
03:37:05	lechuga_:	need to re-read maaku's post a few more times though
03:37:30	gmaxwell:	HVHH is not the same thing. :) They're related.
03:37:57	lechuga_:	i more got from that the understanding of the lucky PoWs and why they prove the work
03:38:12	lechuga_:	not really any insight into the structure of the proof for sidechains
03:38:14	gmaxwell:	(I'd hang out and explain/chat but I'm exhausted and struggling to stay awake)
03:38:18	lechuga_:	lol np
03:38:24	gmaxwell:	lechuga_: fair enough.
03:38:26	lechuga_:	i need to bang my head against it more anyway
03:38:48	lechuga_:	and drive back home
03:38:59	lechuga_:	night!
03:42:12	rusty:	gmaxwell: oh, BTW, I ended up 4-line-hacking bitcoind to write out the missing/expected txs in each block, since BlueMatt's relay server was giving some weird results. Now I'll just run it for a week somewhere to get results. I'd really like to run one w/ relay client and one without at the same time though.
03:43:36	BlueMatt:	yea, I desperately need to spend a week on relay client digging out of the technical debt that thing's built up
03:44:02	rusty:	BlueMatt: it works, though.
03:44:32	gmaxwell:	BlueMatt: good, well I want to add a bunch of things to it. :P
03:46:06	tdlfbx:	tdlfbx has left #bitcoin-wizards
03:54:27	BlueMatt:	gmaxwell: I didnt say clean it up /that/ much :p
03:54:43	BlueMatt:	rusty: indeed, and thats why I havent yet :)
04:18:56	maaku:	lechuga_: the HVHH system doesn't work for this purpose
04:19:50	maaku:	as adversaries can produce fraudulent proofs with less than claimed expected work
04:20:40	maaku:	in the email I outline what the hash structure of the backlinks and commitments would look like, the serialization is "just details"
04:21:35	maaku:	there's a cute structure for the back links which is a merklized heap filled by pushing nodes down the right-hand side
04:23:14	maaku:	it's deterministically constructed, and the verifyer only needs to store the right-hand path through the heap in working memory (a reorg requires the headers of the now stale chain)
04:30:43	rusty:	maaku: I think I need a diagram to follow that...
04:33:12	rusty:	maaku: intuitively though, an unbalanced tree makes sense, since most proofs are going to be for recent blocks. Am I on the right track?
04:33:39	maaku:	it ends up being a not-more-than-1 unbalanced tree
04:34:08	maaku:	this isn't how i arrived at the structure, but it ends up being a binary patricia tree
04:37:20	maaku:	imagine representing the the path to a block as a big-endian bitness integer representation of the height
04:37:20	maaku:	meaning, store the height as an integer, and read off the bits starting with the MSB
04:37:24	maaku:	a 0- means take the left branch, a 1- means take the right branch
04:39:00	rusty:	maaku: OK, AFAICT this is exactly what you get if you take an array of values and naively merkle them together.
04:39:38	maaku:	,,, rusty: scratch what I just said. i'm not efficiently multi tasking and describing something entirely different. gah
04:40:40	maaku:	* maaku draws a paper and pencil diagram to make sure
04:40:54	rusty:	maaku: OK, well, it seems that the straightforward merkle-the-array-of-prev-blocks has the nice property that more recent blocks are generally on shorter paths.
04:41:12	maaku:	rusty: no, they're all at the bottom
04:41:27	maaku:	the one in the email has that property though
04:42:35	rusty:	maaku: so, if we have 3 blocks, wouldn't you H(0|1), then H(H(0|1) | 2) ?
04:43:33	maaku:	rusty: the way bitcoin does it it'd be H(0|1) | H(2,2)
04:43:51	maaku:	if you fix that stupdity, you do get that property sometimes for the last (few) blocks
04:43:57	maaku:	but there's a better way
04:44:00	rusty:	maaku: yeah, sure, but the effect is the same.
04:44:02	SubCreative:	SubCreative is now known as Sub|music
04:44:07	rusty:	maaku: Oh, OK. What's the better way?
04:44:33	maaku:	the goal is to fill out full trees, right?
04:44:33	maaku:	so take these rules
04:44:44	maaku:	if you have a full tree, extend the root so the old tree is the left branch of a new node
04:45:34	maaku:	then start filling out the right tree
04:45:34	maaku:	and you fill the right tree by "pushing down" nodes
04:45:37	maaku:	so the first entry into the right branch is the prior root
04:45:45	maaku:	at block height N, block N is the root
04:46:01	maaku:	and block N-1 is one of the branches (the right branch in this case)
04:46:22	maaku:	and continuing this exact case, block N-2 is the left branch, the root of that full tree
04:47:06	maaku:	anyway as you add blocks you keep pushing nodes of the tree down the right-hand path, preferentially taking left branches when empty
04:47:13	maaku:	until you reach the same depth as the rest of the tree
04:47:56	maaku:	it helps to draw this out on paper, starting with one node
04:48:21	maaku:	then you extend it to get node 2 in the root, with a final node 1 in the left branch
04:48:41	maaku:	then you push node 2 down to the right branch, where it is now final, and put node 3 as the root: 3 -> (1, 2)
04:49:34	maaku:	and continue ...
04:51:17	maaku:	this has the property that the most recent log(N) blocks are available in a direct chain from the root, with the most recent first, which is optimizing for the common case
04:51:42	maaku:	also, the max depth is one less then the construct-from-array approach because we're using internal nodes
04:52:47	maaku:	and the already mentioned fact that you only actually need to store the right-side chain of nodes that are being "pushed down" -- the rest can be pruned from validator state
04:55:36	rusty:	maaku: if you want internal nodes (which I hadn't considered previously), isn't the optimal layout N on top, N-1 and N-2 below, N-3, N-4, N-5, N-6 below that, etc.. ie. breadth traversal? That would seem to give the minimal total size of proofs.
04:58:05	maaku:	rusty: yes but that requires reconstructing the tree each block
04:58:52	maaku:	the question is how we can have a structure which achieves properties as close to that as possible, but with incremental construction and minimal storage requirements
04:59:16	rusty:	maaku: yeah, that does suck. But if you end up limiting to (say) 1024 blocks back anyway because of concern about lucky cheaters, it's not so much of a problem.
05:00:28	maaku:	rusty: long skips are important
05:00:40	maaku:	we have some requirements for going all the way back to genesis
05:01:05	rusty:	maaku: for sidechains, you need only link to a previous output which itself links to ... the genesis.
05:01:30	maaku:	maybe. there's multiple designs with tradeoffs
05:01:36	maaku:	but this is larger than sidechains
05:02:38	rusty:	maaku: sure, but you have to come up with an alternate method for preventing lucky cheaters. This one is simple, and everyone can understand breadth first without a diagram :)
05:03:09	maaku:	what i'm saying is there very well be cases where cheaters are not an issue
05:03:32	maaku:	e.g. you require short skips for recent history, but nevertheless have a requirement to link back to genesis
05:04:06	maaku:	as i said, compact spv is something used by sidechains, but not specific to sidechains
05:04:18	maaku:	you want links back to genesis for spv headers sync, for example
05:04:30	maaku:	cheaters isn't really a problem there
05:06:01	rusty:	maaku: OK, so another question. Why do you think that you need incremental construction and minimal size?
05:06:12	rusty:	(Other than the fact that it's obvious a cool property to have)
05:07:32	maaku:	incremental construction is necessary to have any chance of this being accepted into core. otherwise it could take 1-2 sec or more to rebuild the header history
05:07:46	rusty:	maaku: but you can prebuild it trivially.
05:07:48	maaku:	keep in mind this would be done on asic controllers, typically low-powered arm boards or worse
05:08:25	rusty:	maaku: and slot in the new block hash when you get it. I don't buy it.
05:08:28	maaku:	minimal size is nice because the validator state should not grow linearlly with history
05:08:36	maaku:	or else we're setting ourselves up for problems eventually
05:09:22	maaku:	comparing millinos of hashes vs a dozen or so? if you don't think that's a concern i don't know what to say
05:09:37	rusty:	maaku: not at 1.6MB per year, nope.
05:10:08	rusty:	maaku: millions? We get 50,000 block headers a year.
05:11:57	rusty:	maaku: gavinandresen proposed ordering txs, too. If we're doing that, it's hard to get upset about this.
05:30:36	rusty:	maaku: I'm still trying to figure out your datastructure though. Particularly trying to figure out when a block is in its final position.
05:45:35	bramc:	Could people please start using different length nicks? Y'all look the same in xchat.
05:50:19	Emcy:	do you relly not have nick colours
06:04:40	bramc:	There are nick colors, but for some reason everybody is blue now. Y'all are running a hash collision attack on my chat.
06:05:30	rusty:	bramc: is your monitor cable loose? :)
06:06:32	lechuga_:	lol
06:13:12	lechuga_:	ok so the proof is just a merkle (maybe represented optimally as a patricia trie via a method i haven't digested yet) and the end leaves are the lucky PoWs
06:14:16	fluffypony:	that reminds me of a recent post on a Facebook group for 3DR Iris+ owners, some guy asked if everyone with "funny characters" in their name could change their names to English, otherwise he can't type out their names when he mentions them, and they all speak English anyway, so therefore.
06:15:58	bramc:	Okay, I'm off for now, probably will spend a few days off irc. Somebody let Adam know I gave him a mea culpa when he comes back on.
06:19:53	lechuga_:	need 2 read backlog with paper and pencil in hand when more awake
06:20:18	adam3us:	eh? this adam3us?
06:29:58	adam3us:	bramc: ah i see it (scroll back skim) paul sztorc's argument applied to depreciating hw electricity use. yes that seems logical.
06:34:58	adam3us:	bramc: your second comment from scrollback "The best way to make cryptocurrencies be green is to lower mining rewards,"
06:36:26	adam3us:	bramc: i agree. i made the what-if comment on this that hypothetically bitcoin (community economic supermajority) could decide to cancel the remaining reward schedule. or defer the reward flattening the supply curve to spread the reward over a longer time.
06:38:37	adam3us:	bramc: or make the system reactive as a stabilising force which might reduce the problems miners are in right now (falling difficulty). my idea was maybe if difficulty rises above some threshold/time eg > 10% per 2week period, reward is deferred; and if it falls by > 10% per 2week period reward is brought forward.
06:40:17	bramc:	adam3us, Those are probably all political non-starters for the time being but likely to get interesting around 8-16 years from now. Assuming that interest in bitcoin hasn't already completely faded for other reasons by then of course
06:40:29	adam3us:	bramc: it would do something like gold price being self-stabalising because mining spins up and down in reaction to price. here using rate of hashrate increase as a proxy for price mismatch we would similarly adjust reward. one could adjust reward instead of difficulty (or some mix of the two)
06:41:40	adam3us:	bramc: yes my thought was what-if bitcoin is $100k/coin or $1mil per coin, the power usage might become problematic. the money will be spent and it might lead to wars, global warming, blackouts or crazy stuff. the meta-game theory then makes it plausible to voluntarily adjust to a reward adjusting rather than difficulty adjusting mechanism
06:42:29	bramc:	adam3us, I was thinking about the other contingency, where mining rewards have halved enough times that mining is barely happening any more
06:44:01	adam3us:	bramc: thats another open question is whether fees are enough to provide adequate security. it could be argued the market would have all the tools it needs to take care of that. pay higher fees. we cant have ongoing subsidty for ever probably anyway or thats supply inflation at the steady state.
06:46:11	adam3us:	bramc: on the former i sort of wonder if at the limit ($1mil btcusd) the other implication is that pure difficulty adjustment as a sole feedback loop in fact will limit the price past some point. maybe it even already is to some extent.
06:46:27	bramc:	I would argue that mining subsidies can easily be 2-3 orders of magnitude below transaction volume and it still won't be a security concern
06:49:12	adam3us:	bramc: all kinds of things are plausible in long run meta-game theory. say fees just dont seem to give adequate security. (market doesnt price security properly). then lack of security damages utility, and price falls, such that people become more amenable to the idea of 1% supply inflation ongoing, or demurrage to miners (per year security tax basically) as a way to repair security.
06:59:33	bramc:	The only real attacks are double spends, those aren't all that scary for the vast majority of transactions, and an attacker is only going to do a double-spend attack on transactions they themselves are involved in
07:31:05	bosma_:	bosma_ is now known as bosma
07:31:41	maaku:	lechuga_: no, you start with the block header. *IF* that block is a lucky block, you traverse the block-transaction merkle tree to the commitment tx (one of the last txns in the block, in a fixed pos), then traverse the block header merkle tree to the desired back link
07:32:07	maaku:	the back link itself might be a lucky PoW, but that's besides the point
07:39:10	lechuga_:	i thought the back links were to gather sufficient # of lucky PoW to probablisitcally determine true current difficulty of the presented chain
07:39:30	maaku:	so the setup is you want to prove block B is a descendent of block A, and to keep it simple B is 'lucky' enough so as to represent more work than was strictly necessary to build from A to B
07:40:02	maaku:	so you descend through the transaction merkle tree to the one which contains the commitment, the commitment being the root hash of a block header merkle tree as specified above
07:40:43	maaku:	you then descend to block A, which is at a known position
07:40:55	maaku:	lechuga_: no that is the high value hash highway
07:40:58	maaku:	nothing to do with this scheme
07:41:05	lechuga_:	oh i thought every block was going to have a committment to the block header merkle in the coinbase
07:41:15	lechuga_:	block header merkle root
07:41:38	maaku:	gotta run again :\
07:41:38	maaku:	not the coinbase, but yes
07:41:45	lechuga_:	k im too tired neway
07:41:48	lechuga_:	:)
07:42:01	lechuga_:	will read log
07:42:10	lechuga_:	thx maaku
07:43:42	maaku:	np
07:44:04	maaku:	also read sergio's mailing list post about merged mining header commitments
07:44:12	maaku:	that shows why the commitment is not in the coinbase
07:44:39	maaku:	the proof size can be made much smaller by making one of the last transactions at a fixed position
07:46:57	lechuga_:	k
07:50:55	maaku:	in the system i'm designing, the very last txn is used for data commitments (included merged mining), and then txns at positions N-1, N-2, etc. are used for consensus-checked commitments
07:51:21	maaku:	e.g. block header back-links, (U)TXO indices, etc.
08:17:21	Sub|music:	Sub|music is now known as Sub|zzz
09:05:17	barjavel.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:17	barjavel.freenode.net:	Users on #bitcoin-wizards: andy-logbot CoinMuncher rusty RoboTeddy adam3us Luke-Jr damethos Profreid d1ggy ebfull paveljanik ryanxcharles tacotime hashtagg_ berndj nuke_ Graftec Dr-G3 Starduster mortale NikolaiToryzin moa c0rw1n nullbyte prodatalab mkarrer OneFixt ompik zooko [d__d] jasonw22 devrandom rfreeman_w Emcy toddf jaromil HaltingState gues Adlai GAit bosma Guest35159 thrasher` Iriez hashtag_ tlrobinson Shiftos shesek luny [\\\] heath Guest3112 jgarzik Sub|zzz
09:05:17	barjavel.freenode.net:	Users on #bitcoin-wizards: waxwing go1111111 Graet_ Transisto copumpkin pi07r koshii bbrittain husebyAFK Baz___ spinza DoctorBTC BananaLotus dansmith_btc Apocalyptic phantomcircuit EasyAt tromp PRab_ isis espes___ jbenet null_radix hollandais midnightmagic Muis BlueMatt grishnakh__ starsoccer gavinandresen postpre danneu catcow TD-Linux ryan-c roasbeef amiller smooth optimator_ mmozeiko Alanius epscy kobud dgenr8 JonTitor Hunger- MRL-Relay fluffypony mr_burdell samson_
09:05:17	barjavel.freenode.net:	Users on #bitcoin-wizards: btc__ CryptOprah mappum kanzure warren Krellan nanotube fenn otoburb LarsLarsen coutts bobke jchp nsh_ asoltys_ sl01_ K1773R nickler_ a5m0 PaulCapestany @ChanServ Meeh wumpus comboy btcdrak ahmed_ lnovy eordano nsh gribble gwillen Nightwolf Anduck Dyaheon cfields digitalmagus8 stonecoldpat gmaxwell pigeons andytoshi lechuga_ artifexd hguux_ michagogo kumavis warptangent Fistful_of_Coins HM2 paperbot maaku Cory Guest38445 coryfields iddo kinlo
09:05:17	barjavel.freenode.net:	Users on #bitcoin-wizards: azariah yoleaux Logicwax lclc_bnc s1w Eliel_ sneak harrigan sipa AdrianG livegnik burcin wizkid057 tromp_ poggy Taek throughnothing petertodd crescendo so BigBitz helo Keefe phedny BrainOverfl0w harrow
09:13:54	rusty:	rusty has left #bitcoin-wizards
09:24:26	lclc_bnc:	lclc_bnc is now known as lclc
09:59:38	rusty:	rusty has left #bitcoin-wizards
12:33:11	lclc:	lclc is now known as lclc_bnc
13:48:30	lclc_bnc:	lclc_bnc is now known as lclc
13:55:21	wallet42:	wallet42 is now known as Guest22097
13:55:22	wallet421:	wallet421 is now known as wallet42
14:18:04	kanzure:	"Proof-of-concept: Deterministic SSH (ed25519) key generation from a master secret + key handle"" https://github.com/mithrandi/ssh-key-generator
14:18:07	kanzure:	"If you use the same keypair to access someaccount@somehost and otheraccount@otherhost, someone who observes that both accounts have the same public key for login knows that the two accounts (most probably) belong to the same person. Sometimes this is undesireable for privacy reasons, but the only way to avoid it is to generate two different keypairs for use with the two different hosts. Generating a keypair is not hard, but managing ...
14:18:13	kanzure:	... large numbers of keypairs like this (eg. one per host) individually is difficult and tedious to do; this proof-of-concept shows that you can have the multiple keypairs without needing to store / manage / back up anything more than a single "master key". Meanwhile, someone looking at the public keys can not tell that the keys are related, so privacy is retained."
14:20:12	op_mul:	kanzure: did you read about the hidden services that got exposed because they listened with the same host fingerprint on ipv4? :)
14:20:38	kanzure:	a little part of me just died a little
14:21:38	op_mul:	I don't know the detail, or even where I read that, but still
14:23:20	kanzure:	there are only so many remaining parts of me that are available to die, you know
14:30:07	op_mul:	"Student Uses the Blockchain to Develop Censorship-Resistant Messaging App"
14:30:12	op_mul:	is that helping?
14:30:45	op_mul:	it's a software kit that stuffs messages into bitcoin transactions!
14:36:20	adam3us:	op_mul: stupid idea
14:36:44	op_mul:	of course it is. but the author is dutch.
14:38:11	jgarzik:	I do worry that botnets will start using blockchain for C&C
14:38:31	kanzure:	why is that worrying?
14:40:04	op_mul:	jgarzik: seems like a horrible way to do it. you'd need to have a full node on every single zombie, or use a remote API which can be sinkholed.
14:40:40	kanzure:	i would be more worried about things like micropayment channels for DDOS etc
14:40:54	op_mul:	a small 100,000 zombie botnet would probably kill the bitcoin network entirely if you tried to fire up a SPV client on all of them.
14:42:00	op_mul:	take comfort in that it's probably impossible to do such a thing. or at least if somebody tried it would destroy bitcoin before any malicious use was made of it.
14:45:27	jgarzik:	You don't need to actually run clients at all
14:45:38	jgarzik:	just query public sites
14:45:55	jgarzik:	burden them
14:46:01	op_mul:	yeah. they'd just be abused to sinkhole the zombies, same as every botnet ever
14:46:15	op_mul:	it's not like blockchain.info and whatever other sites provide SPV proofs
14:46:30	op_mul:	they can make fake outputs all day long
14:48:17	jgarzik:	sure. it's always a game of whack-a-mole. bitcoin query sites are sufficiently spread out that you could easily have C&C compartmentalized, such that i.e. part of the botnet looks at blockchain.info, part looks at insight.io, other explorers.
14:49:14	jgarzik:	enough web apis and explorers out there
14:49:24	sipa:	what is C&C?
14:49:28	op_mul:	they could all sinkhole and control the botnet though
14:49:38	op_mul:	sipa: command and control. the heart of a botnet.
14:49:51	sipa:	lol
14:49:51	adam3us:	sipa: command & control
14:49:58	sipa:	really?
14:50:01	sipa:	that sounds ridiculously inefficient
14:50:19	sipa:	like, painfully slow and hard to implement
14:50:33	stonecoldpat:	jgarzik: thats what our paper @ fc will be talking about
14:50:37	op_mul:	most botnets use IRC as their C&C so. not bright people running them.
14:51:10	jgarzik:	"most" ? :) Or just the lower tier dumb ones that are easily spotted? :)
14:51:15	stonecoldpat:	you can stuff the commands inside the OP_RETURN and then just send it down the network, all the bots can simply be SPV clients...
14:51:20	op_mul:	(only know this because someone used an IRC network I was on to run their C&C from, nobody could work out what all the load was from until.. yeah)
14:51:30	jgarzik:	I've definitely seen several strains that use more sophisticated P2P techniques
14:51:43	jgarzik:	one botnet herder on reddit was quite sophisticated
14:51:56	adam3us:	but thats even stupider than this chat app - c&c for botnet can just implement or copy a simple p2p protocol.
14:52:34	jgarzik:	blockchain C&C free-rides on collective defense of everyone else wanting to keep bitcoin running
14:53:13	op_mul:	I think all the block explorer sites they are using would just be happy to poison the network and be rid of it.
14:53:37	op_mul:	if they tried connecting to the bitcoin p2p network, it would just collapse.
14:54:09	hearn:	sipa: if you have an SPV client, maybe not
14:54:26	op_mul:	hearn: an SPV client would cripple the network.
14:54:35	sipa:	hearn: sure, it's doable - but still massively harder than just implementing IRC
14:55:09	hearn:	IRC servers tend to get whacked by law enforcement. the biggest/most professional botnets use their own p2p structure for that reason, and i imagine using bitcoin or less work than doing your own p2p network
14:55:43	sipa:	hearn: still a huge difference between using the bitcoin p2p network as broadcast mechanism, and using actual transactions inside the blockchain
14:56:18	kanzure:	what was the blue/red malware page. hrm.
14:56:22	op_mul:	hearn: pretty sure there's a botnet with a C&C on reddit.com too. check these posts. https://www.reddit.com/r/A858DE45F56D9BC9/
14:58:21	hearn:	yeah
14:58:25	hearn:	botnets are scourge
14:58:42	stonecoldpat:	op_mul: it depends if you consider the bot doing anything malicious, they can just act as normal users (perhaps the stronger bots support the network and the weaker ones are SPV), which would in fact support the network
14:58:44	kanzure:	"blue pill" maybe?
14:59:50	op_mul:	stonecoldpat: if they were full nodes the people who's computers were being invaded would notice. if they were SPV they would overwhelm the bitcoin network. I don't think there's a balance to be had there
15:00:17	stonecoldpat:	op_mul: depends on the users getting infacted, not everyone would notice bitcoin traffic in the background
15:00:21	stonecoldpat:	infected**
15:00:40	op_mul:	most people would notice their CPU red hot, their disk full and their internet slow though.
15:02:09	stonecoldpat:	op_mul: I don't really think a lot of normal people would notice that, and who says that the bot cant be intelligent to throttle the download/upload speed to make sure a difference isnt noticed? (just do a speed test, and set a threshold of 30% under that)
15:02:21	stonecoldpat:	though it would be interesting to know how many SPV clients the network could handle
15:02:36	op_mul:	the answer is "not many"
15:02:39	sipa:	stonecoldpat: you're mixing his comments
15:02:42	hearn:	one botnet shipped with a fully copy of tor
15:02:59	kanzure:	there used to be an article on the interwebs describing a sort of malware that defended itself against other malware, as well as did optimal infection planning with its neighbor peers.
15:03:01	sipa:	stonecoldpat: if you're talking about botnet units running a full node, i'm sure many people would notice
15:03:08	kanzure:	for some reason i can't find this page anymore :(
15:03:34	op_mul:	there's only 6500 listening nodes on the network. that's not very many SPV peers.
15:04:19	stonecoldpat:	sipa: I mean, if your running a full node, you can still limit the amount of work the computer is doing to make it less noticable.
15:05:05	stonecoldpat:	although i would have imagined the botnet primarily being SPV users who connect/disconnect periodically
15:05:28	stonecoldpat:	if your relying on commands being stored in a blockchain
15:05:39	op_mul:	* op_mul shrugs
15:05:57	op_mul:	I don't know how botnets are used or operate, but controlling them with the bitcoin blockchain sounds moronic
15:06:55	stonecoldpat:	op_mul: thats not a lot indeed, it would be good to know what the upper limit of the network is for connections
15:07:16	op_mul:	125 per peer. you work it out.
15:07:57	stonecoldpat:	op_mul: assuming no ones changed that limit, then that would support 800k users...
15:08:05	stonecoldpat:	which is enough for a decent size botnet
15:08:20	op_mul:	that's assuming only botnets are connecting.
15:09:45	op_mul:	and that each SPV peer makes one outgoing connection. which is not true.
15:10:22	stonecoldpat:	thats all a bot would need, but fair point about the 8 connection default, so about 100k
15:10:47	sipa:	which is enough for _one_ decent size botnet
15:10:52	op_mul:	again assuming no other connections in the network.
15:11:42	op_mul:	my nodes are about half full. if it's indicative of the rest of the network, half our listening capacity is used.
15:13:06	stonecoldpat:	the problem that I have been thinking about for a while is if a botnet did hi-jack bitcoin, what would the network actually be able to do? if they act as normal users (perhaps SPV clients accepting all transaction traffic) then you wouldnt be able to identify them, and if they did use bloom filters, then you potentially identify them, but how would you co-ordinate their removal?
15:14:03	sipa:	well they would need actual BTC to send around, and pay fees
15:14:23	stonecoldpat:	and assuming they do not rely on commands being stored in the blockchain, so just transactions are sent periodically across the network with the command, then miners cant do anything
15:14:35	op_mul:	ha, right you'd only have one directional communication
15:14:56	stonecoldpat:	as a botmaster, you would just stick an upload website in the transaction and tell the bots to feed you there
15:15:08	stonecoldpat:	so i created some bots that uploaded screenshots to a server
15:16:14	stonecoldpat:	well when i say create, i ran some spv nodes on a few computers to try it out
15:18:43	op_mul:	this all sounds very implausible
15:22:25	stonecoldpat:	apologizes for spamming channel... lol, i think it is a realstic threat though, especially as the network grows
15:24:15	hearn:	stonecoldpat: it's the anti-DoS problem
15:24:51	hearn:	stonecoldpat: the answer is: it's really hard and Tor had exactly this problem. there isn't anything you can do technically if the bots simulate good users well enough. for bitcoin there's a lot of stuff we can do to try and separate real users from fake ones, but ultimately the only fix would be to get LE on the case and try to get the botnet nuked
15:32:26	op_mul:	hearn: as history has shown, even tor based botnets get kicked. dumbass criminals.
15:33:16	hearn:	botnets get taken down but the operators are caught much more rarely. so not that dumb, i think
15:33:44	stonecoldpat:	hearn: I think thats something we need to start thinking about as a community, what is it we can actually do
15:34:15	stonecoldpat:	op_mul: and whats more interesting, you now have a botnet inwhich you can get paid bitcoins to do some naughty things, so you dont even need to buy bitcoins to fund your botnet...
15:34:40	stonecoldpat:	coinjoin transaction, you pay me, i authorise command
15:34:59	op_mul:	I don't think it's interesting.
15:35:23	op_mul:	bitcoin is stupidly unprivate. anybody using it to do illegal things on any sort of meaningful scale will be caught.
15:39:42	hearn:	stonecoldpat: about botnets freeloading on the p2p network? or botnets in general?
15:40:55	stonecoldpat:	hearn: freeloading on the bitcoin network, though i don't think it could be solved in general
15:54:58	Eliel_:	... I'd think there would be a general p2p network toolkit by now to make implementing a basic one simple.
16:11:41	hearn:	Eliel_: there is TomP2P for doing DHTs
16:11:58	hearn:	but DoS in a p2p system is hard. it's basically unsolved. tor is the closest.
16:12:13	sipa:	tor is also pretty centralized :)
16:17:06	gmaxwell:	botnet people are just following a path of least resistance. You onlt need a control channel which is a fraction of a bit per second. It's impossible to surpress that. If you somehow get them off service X/Y/Z, they'll just become bots playing multiplayer video games and encoding their commands in patterns of plays.
16:20:07	hearn:	it is possible to win sometimes. botnet operators are like with any business, it's not infinitely profitable so they each have a pain threshold they won't go beyond
16:20:34	zooko`:	zooko` is now known as zooko
16:20:38	gmaxwell:	sure a particular botnet a particular guy, but there is always a next guy in line.
16:27:55	stonecoldpat:	ill be presenting about this theme at the bitcoin workshop @ fc this year, so anyone who wants to talk about it while we are there let me know, it would be nice to meet some of you (please ill be a lone wolf on the beach, so company is appreciated!)
16:28:12	stonecoldpat:	ps* not please... lol
16:39:52	amiller:	stonecoldpat, i'll be there!
16:53:02	stonecoldpat:	awesome :)
16:54:33	lclc:	lclc is now known as lclc_bnc
18:42:28	lechuga_:	isnt utxo committment required in order to prove an output referenced in an spv proof hasn't already been re-animated and spent?
18:44:22	gmaxwell:	No. The proof is showing the pegged sidechain has authorized a release of coins, ... it's not referring to any specific coins in bitcoin. (and if it were, it would just be 'obviously invalid' to the bitcoin side verification when the coins it referenced didn't exist)
18:46:38	lechuga_:	going from sidechain -> bitcoin, i would include an spv proof that i created a specific locked output on the sidechain
18:47:02	lechuga_:	bitcoin can validate this proof and say 'ok i agree that you did that'
18:47:32	samson2:	samson2 is now known as samson_
18:47:52	lechuga_:	why isn't that replayable
18:49:03	gmaxwell:	You just mean presenting the exact same proof twice?
18:49:06	lechuga_:	right
18:51:35	gmaxwell:	just by exclusion, the sidechain (but not the locking transaction itself) authorizing which bitcoins to release. If they don't exist, they don't exist.
18:55:43	lechuga_:	so going from bitcoin->sidechain, why cant the proof be submitted twice? there were no pre-existing sidechain coins to unlock
18:57:54	lechuga_:	will the newly created sidechain coin reference that proof?
18:59:21	gmaxwell:	By just tracking the coins created (E.g. a map of them), or by using the peg-asymetrically (e.g. where the sidechain fullnodes are bitcoin full nodes). (you seeing this andytoshi; I still contine to think the symmetric approach is actually more complex.)
19:00:25	lechuga_:	ok makes sense
19:01:26	lechuga_:	i suspect once i see the impl im going 2 feel pretty dense
19:01:31	lechuga_:	:)
19:07:12	MRL-Relay_:	MRL-Relay_ is now known as MRL-Relay
19:08:42	[\\\\]:	[\\\\] is now known as [\\\]
20:33:06	gmaxwell:	"Not only can Thelonious read, manage, and interact with multiple chains, the chains themselves have perhaps the most sophisticated genesis block currently deployed in a blockchain design."
20:36:25	sipa:	we should put a fractal in some sidechain's genesis block, or at least code to generate one
20:36:28	sipa:	many complex, wow
20:39:49	kanzure:	maybe i should have 1 million chains, and each chain will link to the previous chain.
20:40:14	lechuga_:	yo dogg i heard you like DMMSes
20:40:16	gmaxwell:	Thats not quite as gibberishy as it sounds, ... basically some {hard to tell what exactly it is} thing that is mostly talking about something that sounds like the 2112 "digital prospectus" kook proposal.
20:41:00	sipa:	which boiled down to "let's encode the consensus rules in the chain", afaik?
20:41:11	kanzure:	.g site:bitcointalk.org 2012 digital prospectus
20:41:11	yoleaux:	https://bitcointalk.org/index.php?topic=61575.0;wap2
20:41:24	kanzure:	whoops
20:41:36	sipa:	2112, not 2012
20:43:03	lechuga_:	hmm thats kind of cool
20:43:06	lechuga_:	is it feasible?
20:43:17	gmaxwell:	2112 is a kind of kooky guy on bitcoin talk. Used to be pretty active, a lot of people have him on ignore. (not because he emits weird ideas but because he's often also pretty nasty to people)
20:43:25	lechuga_:	(more speaking about sipa's understanding vs what it actually attempts to describe)
20:44:33	gmaxwell:	lechuga_: there is a cyclic dependency there. I mean, say I make a transaction saying "the rules now are all blocks must be signed by gmaxwell", and I mine it.. then I go off and produce my all gmaxwell signed chain. What should a node that witnesses this do?
20:44:56	gmaxwell:	Or say I do this, but against a fork from block 100?
20:45:26	sipa:	lechuga_: do you *really* want miners to determine (or at least have veto power) over rule changes?
20:45:44	lechuga_:	they do anyway dont they?
20:45:47	gmaxwell:	No.
20:45:47	sipa:	no
20:45:51	sipa:	god, what are you doing here?
20:45:53	lechuga_:	they can choose not to upgrade
20:46:00	gmaxwell:	sipa: learning
20:46:10	gmaxwell:	lechuga_: they can, sure, but if they violate the rules the simply aren't mining anymore.
20:46:11	sipa:	sorry, bad day; ignore me
20:46:30	lechuga_:	lol np, im sure i can be frustrating
20:46:30	gmaxwell:	All the other nodes will just ignore their blocks as if they didn't exist.
20:46:34	sipa:	lechuga_: what would happen if miners tried to increase their own subsidy?
20:46:50	sipa:	like 70% of all miners agreed that 100 BTC per block subsidy would be great
20:46:58	sipa:	so they all patch their software to do so
20:47:00	lechuga_:	ok thats really obvious fatal blow
20:47:01	sipa:	what would happen?
20:48:43	sipa:	lechuga_: want to try answering?
20:49:30	lechuga_:	i guess they could do that and it would negatively affect exchange rates and devalue every1s share
20:49:41	sipa:	nope
20:49:55	sipa:	exactly nothing would happen, except that we'd see 3 times slower blocks for a while
20:50:04	sipa:	the whole network would ignore the blocks those miners produce
20:50:24	sipa:	because every full nodes validates the rules; miners don't set them - they only try to satisfy them
20:50:48	tacotime:	well; that's ignoring that the miners would operate their own nodes on an independent fork/network
20:51:09	sipa:	i'm talking about bitcoin
20:51:27	lechuga_:	then they could arbitrarily attack the "real" network couldnt they? and incentivize people to join their alternate network
20:51:39	lechuga_:	since 70% of the hashing power moved to alternate chain
20:51:40	tacotime:	well, yeah, but the bitcoin network is really whatever the major exchanges nodes are operating on.
20:51:52	tacotime:	and major mining pools/miners.
20:51:55	sipa:	lechuga_: why would anyone would those miners even care about that other network?
20:52:19	sipa:	lechuga_: it's about economic power; if bitpay and coinbase and who knows who would decide that they'd also switch... sure
20:52:31	sipa:	but miners are not actually influencing the economy
20:53:14	tacotime:	we've never seen a coordinated fork using a majority hashrate of miners, so i'm not sure what would happen but i'd guess the outcome would just be 100% political.
20:53:16	sipa:	lechuga_: and they *already* can arbitrarily attack the real network
20:53:56	sipa:	the ability to do so is purely hash rate percentage
20:54:13	sipa:	the difficulty is (almost) entirely irrelevant for it
20:54:39	tacotime:	i think he means it increases the triviality of the attack if you let the forked network's hash rate fall; although they're already over 50%..
20:55:09	sipa:	the hash rate is not relevant (unless it drops very very dramatically, like 1-2 orders of magnitude)
20:55:35	sipa:	their (potential) share of the hash rate matters
20:56:37	lechuga_:	isnt the network fundamentally less secure if there is this lingering potential hashing power that exists but not being used to secure it
20:56:50	lechuga_:	and therefor less economically viable
20:57:57	sipa:	it affects our ability to judge it
20:58:35	jasonw22:	jasonw22 has left #bitcoin-wizards
20:58:41	sipa:	if every miner has 50% extra hashpower that they're not using, but could turn on in the case against (or in favor of) an attack, we don't know the actual % that each party has
20:58:54	sipa:	but instantaneously, the only thing that matters is % actually used hashpower
21:00:00	gmaxwell:	lechuga_: I've never found that argument especially compelling. The amount of hashing power isn't fixed, it can increase and decrease at any time. (e.g. people can produce more miners, they can throw them into the sun) If every bit of human economic capacity isn't being used as mining already, then there is always some more that could be diverted to mining. A more interesting to think about is
21:00:06	gmaxwell:	the incentives for parties who mine. E.g. are they better off mining honestly or not mining at all, than they are attacking?
21:02:04	lechuga_:	hmm it can't increase arbitrarily fast
21:02:18	lechuga_:	practically
21:03:38	sipa:	neither is it 'practical' that a miner would decide to suggest to unilaterally change the consensus rules, and expect to be followed
21:04:00	gmaxwell:	lechuga_: sure it can, 24 hour world fab capacity, if all running on creating bitcoin chips could replace the hashrate several times in a day, right now. ... there is some latency involved, sure. Though powered off miners also often have delays too.
21:05:25	lechuga_:	what if the change were to make the subsidy 25.2 btc. all miners decided to follow that rule. maybe it would make sense to follow them since for right now they have the required power to secure their network? (dont know just thinking aloud)
21:05:40	lechuga_:	and it's at a smaller cost to every1 else
21:06:42	gwillen:	lechuga_: the network would fork into "the miners who went along with the change" and "everyone else, who now sees those miners' blocks as invalid and won't accept them"
21:07:13	gwillen:	if any miners stayed behind, things would continue but very slowly until the next retarget; if no miners stayed behind then things would stop until someone mined on the old chain again (which someone would, because free bitcoins)
21:07:45	gmaxwell:	lechuga_: that result would be that it would suddenly be a lot more attractive for me to turn on and start mining the honest network. Hurray! more blocks for MEEE.
22:31:05	phantomcircuit_:	phantomcircuit_ is now known as phantomcircuit