00:02:59	contrapumpkin:	contrapumpkin is now known as copumpkin
01:03:02	kanzure:	http://sourceforge.net/p/bitcoin/mailman/message/33405247/
01:03:20	kanzure:	("The consensus system settles on a timeline")
01:09:36	nsh:	* nsh emotes approval
01:13:17	kanzure:	"Time is not a conspiracy against you" well...
01:35:03	rusty:	Hmm, dumb q. Has anyone proposed offering mining pools incentive not to remove txs from their templates? (ie. simple 0conf DS protection). Say running a lottery for 50 BTC a year, and you're only eligible if you don't remove txs?
01:36:48	rusty:	Seems like a business opportunity if someone wants to increase 0confirm reliability. Plus, if someone hates replace by fee, it's active opposition.
02:11:08	Taek:	I like a lot of the things that Jeff Garzik writes.
02:21:28	zooko:	* zooko too.
02:26:02	maaku:	maaku is now known as Guest52276
06:11:09	fenn_:	fenn_ has left #bitcoin-wizards
06:23:45	fanquake_:	fanquake_ is now known as fanquake
07:25:48	fanquake_:	fanquake_ is now known as fanquake
08:08:48	lclc_bnc:	lclc_bnc is now known as lclc
09:05:17	asimov.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	asimov.freenode.net:	Users on #bitcoin-wizards: andy-logbot rubensayshi ielo CoinMuncher jaekwon dc17523be3 hktud0 fanquake paveljanik Mably koshii bedeho fenn espes__ TheSeven devrandom p15_ linelevel Dr-G3 Starduster maaku_ d1ggy_ Starsoccer arubi_ dgenr8 copumpkin justanotheruser koeppelmann PaulCapestany hashtag_ Emcy_ LarsLarsen jbenet platinuum use_zfs_yo Oizopower mappum gonedrk1 harrow Visheate a5m0 Luke-Jr prodatalab delll melvster flower orik btcdrak hollandais hashtag PRab
09:05:17	asimov.freenode.net:	Users on #bitcoin-wizards: Xzibit17 dansmith_ c0rw1n OneFixt_ SubCreative luny Guest83163 nuke1989 Logicwax Zouppen comboy GAit Adlai yoleaux forrestv MoALTz lnovy burcin binaryatrocity deego d9b4bef9 spinza weex_ nanotube shesek gmaxwell nsh HaltingState DoctorBTC ryanxcharles bliljerk101 dasource CryptOprah artifexd Muis kumavis mr_burdell tripleslash waxwing cornus_ammonis ebfull NeatBasis [d__d] Hunger- davout wiz tromp bosma epscy_ iddo Alanius michagogo cursive
09:05:17	asimov.freenode.net:	Users on #bitcoin-wizards: nick1234abcd__ PFate yrashk BlueMatt brand0 @ChanServ Adrian_G throughnothing Cory andytoshi brad__ helo NikolaiToryzin catcow btc___ K1773R HM2 TD-Linux berndj azariah Krellan null_radix coryfields midnightmagic MRL-Relay morcos Anduck cryptowest Apocalyptic gavinandresen gnusha_ Meeh tromp__ qwopqwop huseby lclc indolering kinlo otoburb hguux__ ahmed_ wizkid057 so phedny stonecoldpat warptangent roasbeef gwillen CodeShark isis BrainOverfl0w
09:05:17	asimov.freenode.net:	Users on #bitcoin-wizards: sdaftuar wumpus nickler Iriez phantomcircuit sl01 earlz bobke_ amiller fluffypony dardasaba veox warren gribble optimator jcorgan Fistful_of_Coins jaromil cfields Eliel s1w Keefe bbrittain petertodd BananaLotus smooth ryan-c ajweiss lechuga_ sneak crescendo Taek eric livegnik asoltys_ pigeons catlasshrugged kanzure heath JonTitor Graet
09:16:54	lclc:	lclc is now known as lclc_bnc
09:58:59	lclc_bnc:	lclc_bnc is now known as lclc
11:26:41	lclc:	lclc is now known as lclc_bnc
11:43:06	lclc_bnc:	lclc_bnc is now known as lclc
13:30:26	kanzure:	"But, let's say, 5 years from now, some faction of miners who own soon-to-be-obsolete equipment will decide to boost their profits with a replace-by-fee pool and a corresponding wallet. They can market it as "1 of 10 hamburgers are free" if they have 10% of the total hashpower."
13:30:31	kanzure:	hamburgers?
13:31:51	fluffypony:	replace-by-cheese
13:32:59	kanzure:	hah i have not heard this argument before, "They won't be attacking Bitcoin, they will attack merchants who accept payments with 0 confirmations. This attack has nothing to do with Bitcoin consensus mechanism (as Bitcoin protocol doesn't provide a consensus over mempool contents), thus it is not an attack on Bitcoin."
13:48:29	lclc:	lclc is now known as lclc_bnc
13:48:34	kanzure:	"Deterministic Pay-to-script-hash multi-signature addresses through public key sorting" http://sourceforge.net/p/bitcoin/mailman/message/33408139/
13:58:26	lclc_bnc:	lclc_bnc is now known as lclc
14:02:08	instagibbs:	I think people over-estimate the damage a serious 0-conf double-spend against a merchant would do to overall system confidence. People that don't trust 0-conf won't care, and people that do will change behavior over time. Miners can and have easily done it profitably to no detriment.
16:12:30	linelevel1:	linelevel1 is now known as linelevel
16:35:30	op_mul:	holy shit.
16:35:56	op_mul:	hey guys, guys, trust us we can make a distributed consensus with all these awesome new features, it's released in a few weeks!
16:36:09	kanzure:	which thing are you replying to
16:36:32	op_mul:	only our ECDSA library leaks the privkey in 256 signatures.
16:36:50	kanzure:	make 'em count
16:36:54	op_mul:	ethereum.
16:37:08	nsh:	really? :/
16:37:09	op_mul:	"Attack scenario: The attacker can recover the private key of the victim as long as the victim used the go implementation and the attacker collected 512 signatures. The reason for this is that the nonce is "msg `xor` private key" which is not unpredictable as required by ECDSA."
16:37:24	nsh:	oh my
16:37:28	nsh:	link?
16:37:50	op_mul:	https://bounty.ethdev.com/users/6fqhe7yn6XDCBr6wM\
16:37:52	op_mul:	https://github.com/jonasnick/ecdsaPredictableNonce/blob/master/explanation/explanation.pdf
16:37:57	nsh:	ty
16:38:20	Apocalyptic:	op_mul, heh
16:38:55	nsh:	friday the 13th is a good day to publish such a finding :)
16:38:56	earlz:	lawl
16:39:15	earlz:	ethereum sounds like some really cool technology that won't ever actually work in practice heh
16:40:10	nsh:	it's all grist for the mill. even if it never goes anywhere, whatever progress and insight and intermediary tools/results are achieved will be reusable
16:40:10	kanzure:	i'm sure there are many parts of ethereum that will work, such as any gui components
16:40:16	nsh:	lol
16:40:17	earlz:	lmfao
16:40:56	op_mul:	nsh: I'm pretty sure the gist is going to be "writing 5 different core clients in 5 languages was a bad idea"
16:41:14	earlz:	5 different core clients, _that maintain consensus_
16:41:15	nsh:	lol :)
16:41:43	earlz:	Do they even have a conflict resolution mechanism when consensus breaks (like mining in bitcoin)
16:42:10	nsh:	do what the other silly did and reduce to a consensus of one
16:42:18	nsh:	the waffle about theory to justify it
16:42:21	op_mul:	it's set up a lot differently, but they are proof of work just like Bitcoin. the proof of stake stuff was just hot air.
16:42:39	earlz:	I know some retarded altcoin claimed to solve the 51% attack a while back.. by just ignoring any fork the wallet isn't currently on lol
16:43:37	fluffypony:	earlz: "solved" in much the same way Darkcoin has "instant transactions"
16:43:42	op_mul:	well there's no end to people making unworkable consensus systems like that. the current flavour is making proof of stake coins that can't reorganise more than X blocks.
16:44:14	op_mul:	fluffypony: ah yes, lets give masternodes the ability to invalidate blocks. that'll go well.
16:44:26	earlz:	I review the code in altcoins, and it's scary how many PoS coins don't even have sync checkpoints enabled
16:45:00	fluffypony:	no but you don't understand, op_mul, masternode operators are all friendly and they work in a spirit of cooperation because they're buddies, there could be no collusion or attacking of each other!
16:45:18	fluffypony:	best frendz 4 lyf, masternode ops 2015
16:45:27	earlz:	there really needs to be a tipbot in here rofl
16:45:39	op_mul:	fluffypony: of course not! it's not like they have a financial incentive to DoS anybody else for their own gain.
16:45:50	siraj_:	is it possible to send http api requests (to say, yelp) from a bitcoin script that lives on the blockchain?
16:45:52	fluffypony:	op_mul: incentivise *all* of the things!
16:46:07	earlz:	siraj_: wat/no
16:46:13	fluffypony:	siraj_: Bitcoin is specifically designed to be p2p and not reach out over other protocols
16:46:32	fluffypony:	except for payment protocol, but we don't talk about that :-P
16:46:37	earlz:	that's no on-chain
16:46:39	earlz:	not*
16:47:08	kanzure:	siraj_: wrong channel, use #bitcoin
16:47:40	kanzure:	earlz: checkpoints don't do what you think they do
16:48:02	op_mul:	kanzure: they do in proof of stake.
16:48:03	earlz:	they keep the coin centralized basically, but can allow for some double-spend/orphan attacks
16:48:09	fluffypony:	"checkpoints" in PoS aren't the same as "checkpoints" in PoW
16:48:15	earlz:	sync checkpoints* (ie, PoS oneS)
16:48:18	op_mul:	fluffypony: although probably illegal and totally unethical I did like block withholding / reorg proofs as proof of work.
16:48:20	fluffypony:	so yeah, what earlz said
16:48:31	MRL-Relay:	[tacotime] op_mul: ehm, kinda wondering why they just never used our lib https://github.com/btcsuite/btcd/tree/master/btcec
16:48:38	earlz:	Where there is a public key in the wallet and it listens to checkpoints broadcast from a server
16:48:47	MRL-Relay:	[tacotime] wheel reinvention..
16:49:13	fluffypony:	tacotime: because they don't understand Go?
16:49:39	MRL-Relay:	[tacotime] heh. we even wrapped it nicely into the native ec package!
16:49:49	op_mul:	tacotime: yours isn't innovative enough. needs a flashy name. does yours leak the private key in signatures?
16:50:19	fluffypony:	good point, and if you could please use "Dark" somewhere in the name that would be great
16:50:29	earlz:	that's a feature! it's for key recovery in case you lose it, right?
16:51:31	MRL-Relay:	[tacotime] op_mul: "aerialSecpK", uses k values from random.org
16:51:48	fluffypony:	ouch
16:52:01	fluffypony:	at least its RNG is deterministic :-P
16:52:17	fluffypony:	(in a manner of speaking)
16:52:35	op_mul:	tacotime: you jest but I've seen that mentioned on bitcointalk several times as a serious suggestion.
16:52:45	MRL-Relay:	[tacotime] sigh
16:53:01	earlz:	deterministic RNG? wat
16:53:46	op_mul:	well for ECDSA deterministic nonces are what you want. just not ethereum flavoured ones.
16:55:18	op_mul:	in a way it's a bit of security theater, if your software's author is so incompetent that they can't make random nonces then their private key generation is unlikely to be any good either.
16:56:44	fluffypony:	pffft, just write your own RNG in JavaScript.
16:57:13	MRL-Relay:	[tacotime] om_mul: well, they're cgo hooking libsecp256k1 it looks like, i guess they assumed if they wrote a wrapper they could do no evil unfortunately.
16:57:32	earlz:	Just make your own RNG real quick, but keep it closed source to make sure it's secure
16:58:11	fluffypony:	earlz: perfect
17:00:09	MRL-Relay:	[tacotime] just goes to show that even calling sane crypto functions is not so good if you're not sure how to use them... i'm not sure how much faster that is for go as cgo hooks are very expensive too.
17:10:13	op_mul:	tacotime: I'm baffled why they even support uncompressed EC keys. they're a legacy bitcoin thing and they've got some reason just thrown it into the new mix.
17:11:21	op_mul:	s/got/for/
17:14:13	MRL-Relay:	[tacotime] op_mul: i can see if you would support for the reason you just feel more comfortable working with X,Y in the math, but, ehm, choose one way or the other.
17:15:13	op_mul:	tacotime: doesn't everybody just unpack the compressed points into X and Y anyway?
17:15:45	MRL-Relay:	[tacotime] op_mul: yes, but i mean, if you're uncomfortable coding the unpack steps because you're afraid you might introduce more mistakes.
17:17:00	nickler:	I don't want to protect the Ethereum team but I believe vbuterin's story: "[...] it was an experiment that Gav and Jeff did back in March 2014 that was never changed back for some reason; it was not intended to go into production code". (https://www.reddit.com/r/ethereum/comments/2vn7nd/ethereum_bug_bounty_has_first_leaderboard_entry/cojitc1)
17:17:05	nickler:	Nonetheless I am relatively sure that the code will be full of bugs in the foreseeable future and it would be good to be open about it.
17:17:08	op_mul:	tacotime: point taken. I'd just see that as an indication that I shouldn't be working with EC to begin with.
17:17:08	nickler:	By the way, I should point out that my attack only works against the textbook method and not libsecp because it might sign the negative nonce (as I pointed out here: https://github.com/jonasnick/ecdsaPredictableNonce). If somebody finds a better attack (and my intuition says there is) I'd be happy to learn about it.
17:21:11	op_mul:	nickler: probably one more for andytoshi than me. for testing or not, it's quite insane that it made it into their codebase to begin with.
17:21:27	MRL-Relay:	[tacotime] nickler: that code is a weird trainwreck anyway; if msg is anything other than a 32-byte hash you get an oob panic
17:21:47	MRL-Relay:	[tacotime] well, anything greater than 32 bytes
17:22:25	op_mul:	I'm a big believer in indicative behaviour in people's code. that's a pretty good example of a moronic one that's not immediately exploitable, but an indicator of future fun.
17:24:44	nickler:	fun, I fully agree :)
17:28:38	gmaxwell:	nickler: "because it might sign the negative" is a non-issue, even if you can't deal with it any other way you would only need twice the signatures on average to manage to sample both sides.
17:30:06	gmaxwell:	more horrifying that anyone who could think for a moment that that was an okay thing to do was writing that kind of code. Then again that kind of stupidity is predictable and was predicted... it's why a couple months ago the libsecp256k1 API was changed to make it really hard to abuse in that way.
17:31:57	nickler:	but my method leaks only one bit per key and for that I have to know the nonce. You would end up with a linear system with 512 equations for 256 bits which has no solution.
17:33:02	nickler:	*one bit per sig
17:33:44	nsh:	what measures were taken to make it harder to footshoot in libsecp256k1?
17:33:51	gmaxwell:	ah, fair enough, you don't know which one was right, and searching would be 2^256.
17:34:06	nsh:	not intuitive to me how you'd achieve
17:34:09	nsh:	that
17:34:15	gmaxwell:	nsh: we removed the callers ability to control the nonce unless they write a callback function and pass it in.
17:34:22	nsh:	ah, neat
17:36:16	gmaxwell:	(little unfortunate in that RFC6979 is slow as crap, and doing that also requires we have an internal copy of sha256 that doubles the object code size of the library; but immunity to stupid was worth it (as demonstrated...))
17:39:36	op_mul:	at the risk of sounding stupid, is there a reason that RFC6979 is so complex? I was blown away by that.
17:44:23	nsh:	* nsh nods
17:46:32	nsh:	i think you can do detDSA more simply than RFC6979 but it might be some work to derive and prove secure
18:18:54	gmaxwell:	op_mul: because it's copying a pre-existing CSPRNG
18:19:20	gmaxwell:	doing so makes it easier to argue that 6979 isn't up to no good. But otherwise there is no reason for it that I'm aware of.
18:19:35	gmaxwell:	Partially it's not that complex, the RFC is just somewhat opaque.
18:21:21	gmaxwell:	(e.g. if you go look at the code in secp256k1 and were to write a spec for it, you'd likely end up with a much simpler description)
18:22:57	op_mul:	gmaxwell: ah. in a way you'd almost be better off just doing H(K + m) wouldn't you? in terms of simplicity and whatnot, I don't see any immediate problem with that.
18:25:23	maaku_:	maaku_ is now known as maaku
18:25:48	GAit:	I'm really impressed with libsecp256k1
18:27:17	GAit:	did some ctypes bindings for python that we'll probably release soon (up to 600X times faster than pycoin) and even tried to compile it with emscripten, 10-20X speed up on bitcoinjs
18:30:58	GAit:	I think 20X with firefox and 10x on chrome
19:11:37	lclc:	lclc is now known as lclc_bnc
20:04:49	phantomcircuit:	gmaxwell, i hadn't noticed that it was based on an HMAC function before
20:22:44	dogetime:	dogetime has left #bitcoin-wizards
20:27:02	gmaxwell:	it's based on one of the NIST HMAC DRBG functions.
20:27:27	gmaxwell:	I think the RFC itself doesn't actually point this out (or if it does its burried in it someplace)
20:27:31	sipa:	*brrr*
20:28:26	sipa:	it does mention this:
20:28:30	sipa:	Rationale
20:28:34	sipa:	The process described in the previous sections mimics the "Approved" generation process of k described in Annex D of [X9.62], with the "HMAC_DRBG" pseudorandom number generator.
20:28:42	gmaxwell:	ah good. this explains why I knew it was. :)
20:29:46	gmaxwell:	really for our use in bitcoin land it's super irrelevant that its slow.
21:11:04	phantomcircuit:	gmaxwell, right
21:11:15	phantomcircuit:	i assume there isn't any question of it's sanity other wise?
21:50:24	bramc:	Hey everybody I have questions/thoughts about replace-by-fee and the general stuff surrounding it
21:51:48	bramc:	First, a really dumb question: Does bitcoin support utxos being spent at the same layer as they're generated on? The complications behind that seem not worth it, although it's a relatively minor detail.
21:52:36	tromp__:	hi Bram. txs must redeem all inputs from earlier blocks
21:53:15	kanzure:	".. suggests that searching for a storage medium that lives forever may be a waste of energy, because the laws of physics themselves limit the amount of time that any information can be kept."
21:53:31	kanzure:	paperbot: http://iopscience.iop.org/1367-2630/16/12/123049
21:53:34	paperbot:	http://libgen.info/scimag/get.php?doi=10.1088%2F1367-2630%2F16%2F12%2F123049
21:53:42	kanzure:	hmph
21:53:53	phantomcircuit:	tromp__, i dont think that's right, iirc a transaction can spend outputs from any tx that appears in a prior block OR before it in the current block
21:53:55	bramc:	The other question, actually a thought/proposal has to do with the logic behind what transactions to accept/distribute
21:54:00	kanzure:	paperbot: http://iopscience.iop.org/1367-2630/16/12/123049/pdf/1367-2630_16_12_123049.pdf
21:54:12	bramc:	phantomcircuit, AUGH
21:54:19	paperbot:	http://diyhpl.us/~bryan/papers2/paperbot/e2eeadf8dbaf1a207adaaac0659729e8.pdf
21:55:06	phantomcircuit:	bramc, it's actually not that bad
21:55:14	phantomcircuit:	but yeah it can be kind of annoying
21:56:06	phantomcircuit:	bramc, basically you want to keep all valid non-confirmed transactions and then only make a decision about which to include in the next block if you actually are a miner
21:56:21	phantomcircuit:	but actually doing that is a trivial dos vector
21:56:33	phantomcircuit:	so you need to store a subset of all of the valid non-confirmed transactions
21:56:49	phantomcircuit:	the easiest way to do that is to simply not store conflicted transactions
21:56:50	kanzure:	wouldn't a miner be picking a subset anyway?
21:57:04	kanzure:	are you saying the subset is still vulnerable to a denial of service attack?
21:57:08	phantomcircuit:	kanzure, depends on whether theres > 1MB of transactions total
21:57:11	kanzure:	what if you have strict bounds...?
21:57:30	phantomcircuit:	you need to implement some sort of dos mitigation strategy
21:57:39	phantomcircuit:	what that is is entirely implementation dependent
21:57:42	bramc:	I'm basically sold on replace-by-fee and having priority be based on fee-per-byte, on the grounds that it will have to get there eventually so it might as well be done now
21:57:46	phantomcircuit:	like i have a server with 256gb of ram
21:57:56	kanzure:	ah i see (i thought you were saying "make a decision about which to include" is vulnerable to denial of service)
21:57:57	phantomcircuit:	i can basically just ignore dos mitigation on that server
21:58:34	phantomcircuit:	bramc, welllll for a miner what they actually want to do is calculate which block would result in the highest total rewards
21:58:53	phantomcircuit:	rewards include fees, block reward, but also modifications for increased orphan rates based on size
21:59:12	phantomcircuit:	this calculation is non trivial and potentially proprietary black magic
21:59:35	bramc:	phantomcircuit, yes that dos is exactly my concern as well, you can trivially dos the network as a whole by introducing lots of garbage transactions which won't get accepted but use up a ton of bandwidth everywhere, and the trivial fix for that (ignore transactions which don't meet the local threshold for acceptance) can result in transactions which are published when everybody's full never getting out there
21:59:36	phantomcircuit:	(not to mention heavily dependent on whether the miner has a high bandwidth block broadcasting network to rely on)
21:59:45	Mably:	Mably is now known as Skipppy
22:00:14	tromp__:	bramc: i was wrong and phantomcircuit is right; you can spent outputs of earlier txs in the same block
22:00:27	bramc:	phantomcircuit, What do you mean 'increased orphan rates based on size'? The decision of what to accept is trivial: make a list of everything, then start knocking out transactions with the lowest fee/byte first until you're under the limit.
22:01:20	tromp__:	which makes me wonder, what is the earliest tx to do so?
22:01:36	bramc:	tromp__, I have a sneaking suspicion that that functionality is hardly ever used
22:01:41	phantomcircuit:	bramc, well lets say im a very large sophisticated miner
22:02:04	phantomcircuit:	i might have a hundred nodes monitoring transaction propogation on the network to get a block propogation advantage
22:02:18	phantomcircuit:	the selection algorithm for transactions is potentially very much non trivial
22:02:25	phantomcircuit:	or it can be pretty dumb
22:02:58	phantomcircuit:	bramc, im sure it's been used since i've done it before
22:03:01	bramc:	Oh, you mean you're concerned about larger blocks propogating slower? Let's live in a shiny happy place and pretend that the transaction rate limit is low enough that that isn't a major issue
22:03:27	bramc:	phantomcircuit, you bastard, now that functionality must be forever supported because of your one stupid transaction in the block chain
22:03:28	phantomcircuit:	the limit is that bitcoin core wallet for a very long time refused to generate transactions with unconfirmed inputs
22:03:54	tromp__:	i'm also curious to know what is the longest chain of txs in a single block
22:04:05	phantomcircuit:	heh pretty sure you'd have to support it either way
22:05:54	bramc:	Anyhow, here's my proposal as to how to deal with transaction dos, which doesn't affect the issues of acceptance strategy because it's versatile enough to support all of them: There's a new message in the peer protocol which means 'don't send me anything with a fee/byte less than X', and when a peer locally accepts something with a lower fee/byte it remembers which peers it didn't send it to and forwards it along to them
22:05:55	bramc:	at such time as they decide they are willing to accept it.
22:06:26	bramc:	tromp__, I'm guessing 2 or 3, and that it's been used dozens, perhaps even hundreds, of times.
22:08:38	bramc:	Some people are freaking out about this all being a conspiracy to make zeroconf stop working. My instinctive rebuttal to that is 'get away from me you fucking moron'.
22:10:08	phantomcircuit:	bramc, zeroconf doesn't work to start with
22:10:11	phantomcircuit:	so that's easy enough
22:10:36	bramc:	phantomcircuit, Yes that's my point. It feels like debating with a flat earther.
22:11:19	bramc:	But on a more serious note I'd like to hear thoughts about my proposed anti-dos protocol extension, which I'm honestly surprised isn't already in there.
22:15:32	bramc:	Also I think petertodd's logic for replacement to require both a better fee/byte and a higher absolute fee is a little odd, because it doesn't guarantee canonical results. It seems better to go with simple fee/byte and use the transaction id as a tiebreak, so that the same transaction will always win regardless of order received.
22:17:14	bramc:	The headache here with new utxos is that you can get a whole bunch of transactions distributed and then invalidate them all by having their dependency get replaced if it's done greedily. A simple solution is for miner software to not distribute transactions dependent on unspent utxos even if the earlier transaction has been accepted. That seems unlikely to hurt any miner in a meaningful way.
22:23:12	bramc:	It seems there's a lot of idling on this channel
22:23:25	kanzure:	many of us don't type things unless they are stoic and awesome
22:23:31	kanzure:	you should be thanking them for not spamming you with crap :)
22:24:15	kanzure:	petertodd: dawg have you rationalized absolute fee and better byte in public and in a link that you could link?
22:24:28	bramc:	kanzure, That is appreciated, but sometimes I make a serious point and can't tell if people are idling, or think it's stupid, or don't have the spare cycles to evaluate it seriously at the moment
22:25:16	kanzure:	ah well people in here are quite vocal about identifying idiocy so you'll be informed in a timely manner
22:26:27	kanzure:	in the past i would have raised concerns about relying on txid but i'm not really sure what the current eventual plan is
22:28:29	kanzure:	bramc: regarding your anti-dos strategy i would be worried about things like penalizing a peer that relays a transaction that was actually included in a block that you haven't seen yet but that also in fact exists
22:28:39	bramc:	kanzure, Well that's reassuring. The core of what I'm working on now is highly controversial so getting into an involved discussion of that would likely set off a flame war again.
22:29:36	bramc:	kanzure, if a peer gives you a transaction which is invalid/redundant in your current head you just ignore it, not sure what you mean by 'penalize'
22:29:58	kanzure:	a lot of the current anti-dos stuff is about penalizing peers and marking them as shitrude
22:30:20	kanzure:	or at least the set of discussed things as relevant to anti-dos in bitcoin.. i haven't looked at what's actually implemented on this front (oops)
22:30:42	bramc:	kanzure, My thought is that my proposed extension would allow you to throw out all the shitrude detection code
22:32:07	kanzure:	also, in your experience from uh other relevant p2p networks, how imminently solvable is anti-dos and how much does bitcoind infringe on borders of things others know how to do well?
22:32:08	bramc:	kanzure, What's actually implemented appears to be a pile of miscellaneous hacky crap https://en.bitcoin.it/wiki/Transaction_fees
22:32:35	kanzure:	hmm that's not what i meant by anti-dos-- there's another set of things in the p2p network
22:33:07	kanzure:	for example, https://github.com/bitcoin/bitcoin/blob/66b473457bc94adcd3d277462f9d619f5a198d96/src/net.h#L578
22:33:30	bramc:	In my experience anti-dos can be done better than you expect up front, DHTs being the prime example. It appears to be in this case that it's totally reasonable to rely exclusively on the transaction rate limit and take it at face value though.
22:33:34	kanzure:	sorry i seem to have inflated a different anti-dos topic with another one
22:33:37	kanzure:	*conflated
22:34:41	bramc:	kanzure, The high-level comment in that link is a good one, I don't know what the specific logic does though.
22:37:10	bramc:	In general with anti-DOS the threshold you're trying to hit is to make it so that a peer can't do better than they can trivially by sending you garbage packets.
22:40:45	bramc:	Here's an annoying attack which someone could pull off: after a block is minted, fill the whole next block with transactions with fee epsilon, then 2*epsilon, then 3*epsilon, etc. causing the network to use a huge amount of bandwidth. That can be mitigated easily by limiting the rate at which you send along transactions so that the lower value ones get thrown out before they're even sent, although that has some downsides.
22:43:03	bramc:	Transactions with multiple inputs make the replacement logic more complicated. At a minimum it's likely to be a huge pain to make canonical, because if transaction A has X and Y as inputs and fee 7, and transaction B has X as an input and fee 5, and C has Y and 5, then it's going to be hard to make logic for acceptance which isn't order dependent
22:43:58	kanzure:	i'm not sure why you would transaction ids to factor into that
22:44:33	bramc:	Transaciton ids are a tiebreak in case there are two transactions which both spend X with fee 5 and you need to decide which one wins
22:45:03	kanzure:	in the past those transaction ids would have varied (because the outputs count when making txid)
22:45:39	kanzure:	unless you mean the input txids
22:46:02	NewLiberty_:	NewLiberty_ is now known as NewLiberty
22:47:53	bramc:	Not sure what you mean. A miner gets two different transactions both of which spend the same input and give the same fee, and needs to pick which one of them to include and forward along
22:48:14	nsh:	transaction IDs are malleable because change address can be grinded
22:48:26	nsh:	so someone could increase their chance of winning a tie
22:49:05	nsh:	(s/grinded/varied/)
22:49:43	bramc:	nsh, The transactions have to be signed anyway, so it isn't a matter of someone 'winning', it's a matter of someone causing mischief by giving different transactions to different peers
22:50:13	Skipppy:	Skipppy is now known as Mably
22:50:54	nsh:	okay
22:51:11	petertodd:	kanzure: my thinking behind requiring both higher absolute fee and fee/byte, is the former ensures that the bandwidth of the replaced transactions is being paid for, and the latter ensures the replacement is more profitable under any circumstance
22:51:29	petertodd:	kanzure: I'd rather err on the side of *not* replacing than replacing
22:52:17	petertodd:	kanzure: note how requiring both acts as an obvious "one-way-rachet" that guarantees any attacker will eventually run out of money to spend on the DoS attack, the same logic behind non-rplace-by-fee anti-dos
22:54:09	bramc:	It seems that the only thing really holding the status quo together is a lack of anybody doing sophisticated transaction dos attacks
22:54:41	petertodd:	bramc: re: the "2*epsilon" attack, remember that epsilon is you must pay at least as much in fees as the transactions you're replacing, and on top of that, you additionally need to pay as much fees as would be required to broadcast the transaction in the first place: nReplacedFees + nFeesToRelayReplacement
22:55:09	petertodd:	bramc: nah, the status quo isn't so bad - I've done a fair bit of work on doing transaction dos attacks and we've gotten most if not all the vulnerabilities out
22:55:42	petertodd:	bramc: main thing we don't have right now that would be nice to have is a size-limited mempool
22:55:53	bramc:	There's one interesting idea in the anti-spam stuff though, which translating to my proposed message would make the threshold be for transaction size * fee/byte instead of fee/byte
22:56:09	petertodd:	huh?
22:56:47	bramc:	petertodd, Backing up a bit, I proposed adding a message saying 'don't send me transactions of less than X fee/byte' to the peer protocol
22:57:03	petertodd:	bramc: oh, sure, but we already have that message, it's just implicit :)
22:57:35	petertodd:	bramc: everyone has a fixed minimum fee/byte lower limit, and transactions that don't pay at least that get rejected by everyone
22:57:52	bramc:	petertodd, You mean by ignoring any such messages? My concern is that in that case the peer doesn't know that you ignored the message previously
22:58:18	petertodd:	so? as long as the lower limit isn't variable this isn't an issue; your idea is a good one, but only if that limit is variable
22:58:20	bramc:	petertodd, Shouldn't it be set dynamically based on the currently outstanding transactions?
22:58:38	petertodd:	bramc: yes it should be, hence the size-limited mempool suggestion
22:58:53	bramc:	so basically there's a real-time auction for whose transactions get in based on fee/byte
22:59:31	bramc:	If you have a size-limited mempool, how do you decide what to throw out when it gets full?
22:59:40	petertodd:	exactly! we've implemented nearly that, modulo the fact that the mempool isn't limited in size. But using up ram globally requires access to a lot of bitcoins so we haven't seen many (any?) attacks
23:00:00	petertodd:	bramc: throw away the cheapest?
23:00:27	bramc:	It's a moderately sophisticated attack. Easy for you or me, but we aren't about to do it.
23:01:45	bramc:	So here's my concern: you have a transaction which gets sent to everybody, then gets thrown out by everybody because it gets nudged out by other transactions, then the fee/byte goes down later, but that earlier transaction was already permanently forgotten and has disappeared into the ether
23:02:34	bramc:	Also not sure what you mean by nReplacedFees + nFeesToRelayReplacement there's some piece of logic in there which I'm unfamiliar with
23:04:04	petertodd:	sorry, one sec
23:10:26	gmaxwell:	petertodd: per byte is also a one way ratchet in the limit.
23:11:12	gmaxwell:	bramc's comment about the path dependance is interesting; I'd missed that and I think it's important. At lunch today luke made some comment that was effectively saying that RBF makes mempools eventually consistent, but thats not actually true with the two fold rule.
23:12:36	gmaxwell:	(there is actually a design flaw in BGP due to multidimensional non-determinstic tiebreaking that causes networks to not converge that looks a lot like this (called MED oscillation)... there is no oscillation risk in bitcoin, but the two tier rule does mean mempools don't become more consistent over time under all conditions)
23:14:02	bramc:	gmaxwell, To be fair they have to eventually consistify as transactions are accepted. What the logic should be about transactions with multiple partially overlapping inputs should be is much less clear.
23:14:18	gmaxwell:	bramc: sure I mean in the absense of blocks.
23:14:43	gmaxwell:	It's not mandatory but a nice property that two nodes whove seen the same txn in any order that have the same policy should have the same mempool.
23:16:45	bramc:	Yes that's a good property, although it might have downsides
23:17:16	petertodd:	gmaxwell: my concern with pure fee-per-byte is that it means I can replace a large transaction(s) that consumed a lot of bandwidth with a smaller one with higher per-byte fees, but lower absolute fees. that could easily be used as a DoS attack
23:17:19	bramc:	for example if you want that property a peer can potentially do thousands of replacement transactions in order and get everyone to keep forwarding and replacing
23:17:53	bramc:	petertodd, Ah that makes sense
23:18:18	gmaxwell:	petertodd: indeed, though it's bounded. ... bleh. so that attack always exists in some form if you don't have a hurestis to prevent updating of some kind which implies order dependence. :(
23:18:23	gmaxwell:	so we can only have one or the other.
23:18:49	gmaxwell:	E.g. you can just have a "replace if the fee per byte is at least $non-negligible-higher" but thats order dependant. :(
23:19:13	petertodd:	gmaxwell: yup, I'd rather have the system that's obviously free from DoS attacks - after all everything is secondary to keeping relaying of blocks reliable
23:19:43	gmaxwell:	just irritating to not have the order independance. :(
23:20:17	bramc:	petertodd, What logic do you have for replacement of transactions with multiple inputs?
23:21:11	petertodd:	bramc: multiple inputs? um, why would that matter? multiple outputs is interesting, if they're already spent
23:21:17	bramc:	or by things with multiple inputs? It seems very different to have order independence there for different reasons
23:21:51	bramc:	petertodd, If you have inputs X and Y, then you can have a conflict with two transactions, one with input X and the other with input Y
23:21:59	petertodd:	bramc: ah ok, so if you replace with a tx with fewer inputs, then sure, the now unspent inputs can be spent (I should have a testcase for that actually)
23:22:24	petertodd:	bramc: I'm sure you can construct cases where this leads to non-convergence :)
23:22:52	bramc:	petertodd, I meant in terms of deciding which one takes priority, do you look at the fee/byte across everything being replaced?
23:23:26	bramc:	And yes, there's a very simple case of non-convergence which is hard to get around. It seems like convergence is a lost cause which shouldn't be worried about.
23:23:32	petertodd:	oh, absolutely, there's code that sums up total fees and total bytes for *all* transactions being replaced and compares against that - subject to a total visited limit to also prevent DoS attacks
23:23:48	petertodd:	that code is very fast as we cache nFees and nSize, so it's just walking memory via pointers
23:24:32	petertodd:	yeah, I'd be happy to see it converge later, but least risk is to ship something that prioritises Actually Working :)
23:28:20	bramc:	petertodd, So what was that about the increasing epsilons again? Something about nFeesToRelayReplacement
23:30:07	petertodd:	bramc: we don't relay a transaction unles it pays nSize * min-fees-per-kb. I'm just saying I won't replace unless the transaction pays more fees than the replaced transactions, and on top of that pays at least nSize * min-fees-per-kb additional fees, *and* also ends up paying a higher overall fees-per-kb than the replaced transactions
23:30:15	gmaxwell:	nickler: oh wow, nice result against bitcoinj. We knew before that it had nearly no privacy; but the intersection it a very nice observation.
23:30:19	maaku:	maaku is now known as Guest99135
23:32:19	petertodd:	bramc: (hmm... I should double-check all three conditions are actually possible... :P)
23:32:24	bramc:	petertodd, What's min-fees-per-kb set to?
23:32:34	petertodd:	bramc: 0.1uBTC/KB
23:32:45	sipa:	whatever is the relay fee is configured to, i suppose?
23:32:51	petertodd:	^
23:35:08	bramc:	petertodd, My back of the envelope calculation says that that amounts to 2 cents/block at max size
23:36:54	petertodd:	bramc: wait, no that's wrong, it's 10uBTC/KB
23:37:21	petertodd:	bramc: $2.5/block, which is absurd
23:38:46	bramc:	petertodd, isn't that $2/block? And that's a total of $500/day to stop anybody from being able to get any transactions done. That seems expensive but doable.
23:39:32	petertodd:	bramc: but fees are a market, so modulo shitty wallets that don't let you set them that attack will fail
23:39:44	phantomcircuit:	gmaxwell, ?
23:39:48	sipa:	well relay fee is different from mining fee
23:39:55	petertodd:	bramc: the real worry is using up bandwidth and especially memory
23:40:08	sipa:	relay fee gets your transaction across the network; i doubt it will be enough for getting it into a block much longer
23:40:42	petertodd:	sipa: which is potentially bad, because you shouldn't be relaying stuff that isn't going to get mined reasonably soon
23:41:02	sipa:	petertodd: agree
23:41:18	bramc:	petertodd, The problem being that wallets don't currently increase their fees when their transactions aren't going through
23:42:06	petertodd:	bramc: for awhile bitcoin wallet for android made it impossible to set fees; right now you only have a x10 option that's fixed
23:42:29	petertodd:	bramc: replace-by-fee will help that as it'll be easy to bump tx fees
23:42:43	bramc:	s/easy/possible/
23:43:19	bramc:	My concern about rebroadcasting a transaction isn't much of an issue if the wallet can be responsible for rebroadcasting
23:45:38	petertodd:	bramc: yeah, anyway, lots of work needs to be done on wallets for sure
23:46:32	petertodd:	bramc: main thing is will replace-by-fee make the DoS attack situation worse? a little bit, for replace-by-fee nodes, while it's getting adoption, but the basic principles seem sound
23:48:28	bramc:	petertodd, How does it make things a little bit worse in the short term? I totally agree with the basic principles.
23:48:28	petertodd:	bramc: because the replaced transactions are dropped, it's also *only* worse in terms of bandwidth DoS, not memory usage DoS, and it's being deployed on high-bandwidth nodes for the most part
23:49:14	petertodd:	bramc: basically because the replacement isn't guaranteed to get mined because few people are mining w/ replace-by-fee, so you can use up a bunch of bandwidth by replacing with long strings of transactions for relatively little cost
23:51:02	bramc:	petertodd, Well said for the ringleader of the conspiracy to destroy zeroconf :-) http://www.reddit.com/r/Bitcoin/comments/28jp0y/why_is_peter_todd_wrecking_zeroconf_security/
23:52:16	petertodd:	bramc: !@#$ coinbase promised I'd get hookers AND coke, and all I got was the hookers. Bitcoin was way cooler when it was unregulated.
23:52:46	kanzure:	they might honor that kind of invoice, you'll never know unless you try
23:53:21	petertodd:	kanzure: I did, they said only the hookers were legal, not the coke.
23:53:53	petertodd:	kanzure: meanwhile greenaddress tried to give me medical pot instead, and demanded to see my card... sheesh
23:54:10	kanzure:	terrible
23:54:28	bramc:	You guys should go on tour with me, I have more groupies than I know what to do with.
23:54:41	kanzure:	wouldn't that just increase your groupie count?
23:55:16	petertodd:	bramc: male or female groupies? (or both?)
23:55:25	nsh:	but we could increase his ideas-of-things-to-do-with-groupies count
23:55:32	nsh:	for example, human pyramids
23:55:52	bramc:	Real rock stars have groupies who are 19 year old girls. Programming rock stars have groupies who are 13 year old boys.
23:55:54	petertodd:	nsh: that's not how Metcalfe's law works...
23:55:59	petertodd:	bramc: lol
23:56:01	nsh:	lol
23:56:03	nsh:	damn
23:57:35	petertodd:	bramc: https://twitter.com/petertoddbtc/status/566385692276584449
23:58:35	nsh:	.t
23:58:35	yoleaux:	Fri, 13 Feb 2015 23:58:35 UTC
23:58:45	nsh:	ah :)
23:59:25	bramc:	I'm coming up with some more somewhat annoying dos attacks. It's a bit of a cat and mouse game