00:19:28	gmaxwell:	fluffypony: thank you for drawing my attention to that lovely thread; it's quite a source of chuckles. https://bitcointalk.org/index.php?topic=1001642.msg10925510#msg10925510
00:19:55	fluffypony:	hah hah
00:20:05	fluffypony:	they've invoked the name of AnonyMint
00:20:08	fluffypony:	SO SAY WE ALL
00:31:28	andytoshi:	that forum fascinates me, it's always so personal and so -fast- (ten pages of mudslinging in that thread since gmax's post six hours ago)
00:32:12	midnightmagic:	... 'links to NSA and Cicada' ?
00:33:07	fluffypony:	midnightmagic: as part of the BCN scam "authenticity" push they tried create links to Cicada
00:35:23	nik_unity:	nik_unity has left #bitcoin-wizards
00:35:48	fluffypony:	and then they wrote some crazy blog post trying to imply the NSA was involved: http://web.archive.org/web/20141106091836/http://www.cryptobang.com/2014/10/05/what-nsa-created-cryptonote-for/
00:36:05	phantomcircuit:	andytoshi, ironic for people people posting on a topic in which personal motivation should be essentially meaningless
00:36:48	fluffypony:	phantomcircuit: they can't argue technical merits, even those that think they can, so they inevitably fall back to ad hominems
01:05:45	kanzure:	some of that is probably because they are at a loss for how to acquire the knowledge required to evaluate technical detail
01:05:57	kanzure:	it's not like there's hyperlinks to all of the 300 hours of studying you need to perform
01:06:28	nsh:	there could be
01:09:30	kanzure:	but there weren't?
01:43:33	andytoshi:	kanzure: i think for many of these systems it'd be more than 300 hours of studying even for a very smart person with a good layman's cs/programming/crypto/cs background and who was thinking properly about trust models and the goals of cryptography as applied in these systems
01:43:54	andytoshi:	and that's just to spot the bs ... if one of these systems was actually correct, given how complex they are i don't think any human could determine this!
01:44:26	andytoshi:	but it's true that we can improve things a lot by providing information (and you've done a ton of very productive work in this regard)
01:52:17	Adlai:	* Adlai has spent over 300 hours, probably closer to 1000, in self-teaching; and still feels totally unqualified to make all but the most guarded of statements on such topics
01:54:29	Adlai:	* Adlai wouldn't be surprised if, had nobody unqualified to refute bitcoin's security model "bought in", the system would never have bootstrapped
02:12:49	gmaxwell:	it doesn't help that there are a lot of dead ends that impede learning; e.g. no one that spends much time around some of the people that emit nothing but non-stop technobabble are going to learn much; since if you try you can't make any sense of it.
02:22:14	Adlai:	also, "a little learning is a dangerous thing", or at best - useless
02:22:21	smooth:	gmaxwell: many of the people involved have no particlar interest in learning, it is a fantasy stock market game. that can't be helped unless there were another killer app for distributed consensus that did not involve finance at all
02:23:31	Adlai:	but people don't get this riled up about fantasy stocks, that forum thread reminds me of the drunken mobs around non-fantasy stadiums
02:24:01	gmaxwell:	yea, actually I think I've remarked before that the only other places I've seen the kind of poisonous behavior I've seen so often in the altcoin forums is the yahoo stock forums.
02:24:06	smooth:	Adlai: people dont really trade fantasy stocks for money because you can trade real ones
02:24:23	smooth:	and if you saw any of the tech stock forums around in the pre-2000 era it was much the same
02:24:44	gmaxwell:	Adlai: people do get this riled up about random ass stocks. See what smooth says; well it still goes on today too.
02:24:45	Adlai:	* Adlai is implying that for somebody to get so emotionally involved in these topics, it's not fantasy anymore
02:24:45	kanzure:	haha gmaxwell has looked at the yahoo stock forums
02:24:46	kanzure:	that's cute
02:25:02	kanzure:	by which i mean strange.
02:25:39	Adlai:	you know what's cuter? that real live cryptographers still read threads on bitcointalk...
02:25:51	gmaxwell:	kanzure: only because I was directed there in the past by people going "holy shit!" :)
02:27:07	Adlai:	* Adlai is being cynical... i'm actually impressed that yous have the energy to post reasoned/polite responses in such threads
02:27:43	smooth:	Adlai: i use the term fantasy because these are not real stocks in the sense of having actual real-world assets (even intangible ones). they are brands and people get attached and fight over them, much like sports, or as gmaxwell says random ass stocks
02:28:06	Adlai:	there is real-world value attached to these snake-oil brands.
02:28:39	gmaxwell:	"Sports fans", I call it. Apologies to any of you that are actually into some sport or another and haven't found yourself setting the other team's fans cars on fire recently. :)
02:28:57	smooth:	Adlai: only because the 'fans' attach that value. its little different from an sf giants shirt costing $50 and if I make up a 'smooth' short i'd be lucky to get 50c for it
02:29:02	gmaxwell:	It's not just the value, people get caught up in this stuff even when they don't have any direct monetary skin in the game.
02:29:10	smooth:	gmaxwell: jinx
02:29:45	smooth:	gmaxwell: agree, many of the 'combatants' dont have any real value at stake imo
02:29:56	smooth:	true in stock forums too
02:31:41	gmaxwell:	E.g. I had a journalist that reports on altcoin stuff, who says he owns none of it himself, basically cussing me out because of some of my comments that I think are pretty moderate (e.g. the 'network effect matters hugely' and 'its not in the interest of public adoption to go about rebooting network effect every time we want a new feature'). He was clearly very emotionally invested in the 'fight'
02:31:47	gmaxwell:	, but I totally believe his word that he doesn't actually own any cryptocurrency at all. Same way people get worked up about a sports team even though they don't own it, don't play in it, etc.
02:32:21	Adlai:	maybe he had reputational investment due to previously published words?
02:32:36	smooth:	gmaxwell: journalist that reports on altcoin stuff <= has a stake, though i agree about emotional investment too
02:33:09	gmaxwell:	Adlai: yea, some I'm sure. But at least it's not about expecting a huge payday when some altcoin or another somehow achieves widespread use.
02:45:04	xenog:	@gmaxwell, this guy should probably read Daniel Krawisz at the mempool.
02:52:13	c0rw1n:	c0rw1n is now known as c0rw|sleep
02:58:17	gmaxwell:	As far as why I commented on that thread-- beyond the whole basic amusement, and people being wrong on the internet... I've been musing about on a little essay for a while on what is cryptography. Back in the early 90s (and somewhat before, though that was before my awareness of) many people were enthralled by the potential of technology to equalize people and instutions, "information wants to b
02:58:23	gmaxwell:	e free"-- a common battle cry. I bought into it too, seeing great promise there. But information's power, has another side... they say sunlight is the ultimate solvent, washing away greed and corruption, and thats true... but like any other solvent its also morally indifferent without care it will just as easily wash away privacy, self-dignity, the freedom to conspire to promote justice against p
02:58:29	gmaxwell:	owerful interests. Uncontrolled it can cement the power imbalances we thought it would erase. Cryptography is our fire pit, where we tame the power of free information to suit human needs and human morality. And it's really hard because it shouldn't be possible at all. If you can prove any non-trivial cryptosystem secure in a strong sense you have a direct proof that N!=NP, and it's not good enou
02:58:35	gmaxwell:	gh to be mostly secure since the context is always adversarial. It seems unlikely but it may still turn out that secure cryptography is eventually discovered to be impossible. Civil engineers aren't trying to build buildings that can't be taken down, only ones that don't spontaneously collapse in the face of random natural forces, and thats hard enough. And because software is considered "cheap",
02:58:41	gmaxwell:	due to the zero marginal cost of reproduction, we underfund it enormously. AFAIK the most complex system built by mechinical engineers are on the scale of the space shuttle, with 2.5 million parts and a total program cost of around $200 billion dollars. Firefox, just one application used by hundreds of millions of people every day is about 20 million lines of code, and far far less funding. And
02:58:47	gmaxwell:	yet, ignoring any belief in gremlins, the shuttle doesn't need to withstand people actively trying to break it. The more cryptographic parts of firefox fail pretty much constantly, with every update fixing a multitude of severe bugs that would totally undermine your privacy or security (and the same for its competition). We just tolerate it, but in cryptocurrency we can't tolerate it. It's just a
02:58:53	gmaxwell:	mess, and really the first step in dealing it needs to be accepting the full scope and gravity of the problem.
03:01:09	Adlai:	* Adlai subscribes to the "tools magnify power" school of dystopianism
03:02:13	zooko:	awesome
03:02:17	zooko:	more rant please
03:02:28	petertodd:	gmaxwell: "yet, ignoring any belief in gremlins" <- I once talked to a nuclear plant engineer who claimed that the design of the candu reactors did have a criteria for resistance to delibrate sabotague - I'd be surprised if the criteria was very good, but at least they were thinking about it
03:02:33	moa:	a cryptographer's confession?
03:02:41	moa:	jk
03:02:54	Adlai:	s/confession/Apology/
03:05:17	moa:	yeah sabotage is hard to design for, like pilots willfully flying planes into the mountains, while sitting in cockpit packed with hardware and software designed to prevent such outcomes
03:05:45	gmaxwell:	Part of the general lack of adversaril models in civil engineering is because its sort of crazy. Build a building that can't be taken down in an attack? give me a break. We really should be more surprised that cryptography works at all.
03:05:46	moa:	most times the most delicate instrument in the machine is the human brain at the controls
03:06:24	petertodd:	gmaxwell: the other thing is you don't generally need it the way you do in crypto - the effect of actions is relatively easy to predict and localized in a way tht just isn't true in software
03:06:27	kanzure:	gmaxwell: ehh you would have to elaborate on the differences of the operational reliability and requirements of space shuttle software versus firefox (e.g. firefox gets many billion more hours per month than the an inactive space shuttle)
03:06:38	zooko:	moa: that reminds me of one of my side projects of fixing vulns in human brains.
03:06:52	gmaxwell:	petertodd: modern trend in reactor design is "intrensically safe"; but this is mostly because the original school of design (add lots of safty systems) kept blowing up. It's unclear if the modern designs really are much safer in practice than the old boiling water plants due to the general lack of construction or so I'm told. (or at least was the opinion of a nuclear plant engineer I knew in my t
03:06:57	gmaxwell:	eens)
03:07:00	kanzure:	zooko: that wont work, you will have to migrate to software
03:07:12	Adlai:	cryptography (even bitcoin) works up to a point. steel beams might buckle in the heat of burning jet fuel, but a single-prop plane doesn't take them down.
03:07:37	kanzure:	Adlai: what's your point
03:07:44	petertodd:	gmaxwell: yup, and note how modern security design is somewhat moving towards similar concepts of "intrensically safe" because "review it really carefully" doesn't work
03:07:52	gmaxwell:	kanzure: that arguably justfies a much greater investment; As I said, it's my view that we under invest in software integrity. Perhaps we must because the answer would be that we couldn't afford it otherwise; but that doesn't mean that we're investing adequately.
03:08:16	zooko:	kanzure: disagree
03:08:27	Adlai:	kanzure: systems are designed with a level of attack resistence in mind
03:08:39	gmaxwell:	Adlai: some are at least.
03:08:47	petertodd:	gmaxwell: meanwhile instead of investing in safer software US "cybercommand" wants to invest in offensive attack capability... :/
03:09:04	Adlai:	s/are/should be, for the sake of the engineers' sanity and peace of mind/
03:10:56	gmaxwell:	kanzure: the best counterargument I have to my position is that we have much better debugging tools for software than are available for mechnical or civil engineering. ... which is good because if we didn't we'd be totally screwed. It's not clear how much they help in the adversarial model as opposed to dealing with normal exposions.
03:11:16	moa:	triple redundant OS and intrinsically safe is standard design protocol in oil/gas and nuclear control systems
03:11:51	moa:	and fail to safe state
03:12:00	petertodd:	heh, in my last job it was frequently literally impossible to "debug"" things because you had circuits operating at physical limits - measuring anything in themwas imposible
03:12:54	petertodd:	moa: note how when you say "redundant" that often (and hopefully!) means the actual OS itself is built by a different team
03:13:25	moa:	maybe ... mostly just running in parallel for failover or watching each other
03:13:40	kanzure:	fail safes usually fail by failing to fail safe
03:14:03	kanzure:
03:14:05	moa:	sliding down the fault tree ..
03:14:07	gmaxwell:	right fail to safe state is a weaker condition then "intrensically safe", the later is more like "even if everything goes wrong, its safe" the fomer is thats like "if the control signal goes away the moderator rods are automatically inserted" (and then it turns out that the control system can fail in such a way that the signal gets stuck instead of going away, and everyone in a 40mi radius is sa
03:14:13	gmaxwell:	d).
03:14:14	moa:	into catastrophe
03:15:37	gmaxwell:	It's pretty interesting to read about industrial disasters and air crashes; they're virtual all multiple-faults... because the engineers that built the systems were not idiots and knew that there was danger and built in safeties.
03:16:20	kanzure:	i wonder if aerospace engineers have to have screaming matches to get the opportunity to design reliability into their systems
03:17:11	petertodd:	kanzure: the question isn't *if* they design reliability, but how much
03:17:20	gmaxwell:	(often three faults, at least one of which is usually a human error)
03:17:36	petertodd:	kanzure: equally, thescreaming matches generaly come from disagreements about how much reliability they got for their money
03:18:16	gmaxwell:	There is an argument that you can only do so much, and past that point doing more reduces safty; or kills the project due to cost and then you don't get the positive benefits of whatever you were building. At the same time there is moral hazard because the costs of failure are often externalized in one way or another.
03:19:15	kanzure:	petertodd: well i mean i was comparing ot the screaming that happens in software land ("uhh of course we need reliability and security")
03:19:16	jcorgan:	it only seems that when organizations have to pay directly the damages from their faulty software does the feedback loop get closed
03:19:43	moa:	imho reliability engineering in aerospace is not as much developed as in other industries because historically they just load it into pilot protocols, only relatively recently with advanced fly-by-wire and autopilots can they now consider triple sensor inputs, etc (like the one failed pitot tube that caused a disaster)
03:20:01	gmaxwell:	jcorgan: even that... kinda tricky. I mean, there is an incentive to gamble in large orgs. Make a high risk bet, get a bonus and a promotion. Bet fails? company folds and you go on to work someplace else.
03:20:14	petertodd:	kanzure: yeah, in my experience that's not the case, however unlike in software (seemingly) you expect really critical peer review constantly by everyone
03:21:02	jcorgan:	gmaxwell: well, that sorta proves my point--you have people that can make faulty decisions and not be held accountable
03:21:12	kanzure:	i have always expected that in software, and usually i only get that by irc )
03:21:15	kanzure:	:)
03:25:22	Taek:	As I said, it's my view that we under invest in software integrity. Perhaps we must because the answer would be that we couldn't afford it otherwise; ==> software with less features would help
03:25:38	Taek:	*the above is a gmaxwell quote
03:26:18	Taek:	it's my view that most software has many many unnecessary features
03:26:41	Taek:	fewer features means less surface area AND more time to invest towards reliability
03:31:23	gmaxwell:	Taek: hard to say, a nice -- if somewhat dated now-- example is the GNU utilities vs traditional unix tools. Back in the bad old days of unix (and less so today) each vendor shipped with their own implemention of all the basic commands, and in spite of being old and having almost no features they turned out to be constantly full of bugs... by comparison the GNU competition was often overflowing w
03:31:29	gmaxwell:	ith features, including stupid ones that probably no one ever uses, and yet were comparitively bug free. (There have been a number of studies pointing this out, e.g. running fuzzers on the tools shortly after fuzzers became a trendy thing).
03:32:39	gmaxwell:	I think a lot of that just came from a focus on craftsmanship over schedule. Features and fewer bugs were both side effects of caring about doing a good job.
03:33:22	Taek:	would 'many eyes' also play into that? Also, when you have 5 or 10 or X reimplementations of something, each reimplementation could be counted as its own set of features
03:34:16	jcorgan:	agree on craftmanship vs. schedule.
03:34:39	jcorgan:	releasing things with a commerical motivation is fraught with the risk that your competition will beat you
03:35:00	jcorgan:	and with software the cost to release a "patch" is low
03:35:25	jcorgan:	so you sort of get this rolling bugginess where old ones get fixed and new ones come online :)
03:36:13	gmaxwell:	I dunno that many eyes has ever worked all that well; and in the early days of the GNU utils they certantly didn't have as many eyes on using them as the vendor tools that shipped by default on each and every system... I can't say that more eyes has no effect, but I think its given too much credit. Even when it contributes to you knowing about bugs, it doesn't mean that you fix them.
03:40:30	kanzure:	well, at minimum open-source saves me a lot of time that i would otherwise spend reimplementing junk
03:40:42	smooth:	gmaxwell: eyes on using them is not the same as eyes on the code. there were many, many more eyes on most of the gnu tool code, with some exceptions such as compiler internals (I think)
03:41:35	Taek:	do you think that open source just draws a higher standard out of developers?
03:41:53	smooth:	for example, one way that eyes helped with gnu tools was porting. If you ported to a system with different character encodings you would come across edge cases and probably fix them, which later can lead to better fuzz-resistence even if that wasn't the original goal
03:42:21	smooth:	similary system call behavior, etc.
03:43:14	gmaxwell:	smooth: many more often means two people instead of one. My expirence across many projects is that the actual levels of detailed scrutiny on code is quite low, even when the project is widely used and very active.
03:44:15	smooth:	gmaxwell: agree on detailed scrutiny, not sure about the value of the long tail of many eyes looking a little bit, but lean toward seeing a lot of value there (granted not strong support in that statement)
03:44:55	gmaxwell:	In something like firefox you can be relatively confident that two sets of eyes have actually read every piece of code because there is a organized review process that requires it. But I would estimate the the eyes per line of code is under two in most projects and very seldom higher than 3 at least across whole projects... particular bits obviously get more attention.
03:45:28	kanzure:	random q, but did you ever read any of lkcl's rants on the mozilla issue trackers and did you have opinions about those rants
03:46:32	smooth:	gmaxwell: i dunno what the eyes per line of code is, there are a lot of eyes "out there". Firefox may be a worse case for this than say gnu tools becausse it is enormous, doesn't have a great starting point, and has evolved quickly to external demands
03:47:05	smooth:	also im somewhat skeptical of a formal process requiring things. you can require people to look,l but you cant require them to think.
03:47:05	kanzure:	not enough people are encouraged to read code. you can't get many people to even read bitcoin core source code (which explains why there's zero comments).
03:47:28	gmaxwell:	smooth: dunno, have any of you read the bash or grep source code? (I've read the grep source code, well parts of it)
03:47:39	kanzure:	yes but only by accident, i think
03:48:17	gmaxwell:	smooth: the process requirements for review help in more ways than you would expect. For one, it removes a default social pressure against review. Without it, people feel like you're obstructing them when you review their code. With it, you're doing them a favor by picking up the review.
03:48:25	smooth:	kanzure> yes but only by accident <= exactly
03:48:48	smooth:	btw, i have read parts of probably every gnu tool
03:49:00	kanzure:	many code reviews devolve into syntax nitpicking anyway, which is sort of silly since code formatting tools do that automatically (well, to some extent)
03:49:05	smooth:	and wrote some parts too, fwiw, so i guess im biased
03:49:50	gmaxwell:	kanzure: The nit picking is actually good too though, because it can act as part of a consensus process where we all agree that we're working hard to build something high quality, and that we're going to agree on what high quality means, and we're going to take the time to do it, even it does mean a few retries.
03:50:18	kanzure:	i agree with that aspect, i should have said nitpicking without critical design review
03:50:51	kanzure:	er, i mean syntax nitpicking is acceptable but i would better design commentary
03:50:56	kanzure:	*i would prefer
03:50:58	gmaxwell:	smooth: fair enough, though this isn't true for most people (I think I've read non-trivial amounts of GCC code, chasing bugs, and a few other things. well in recent years, when I was learning to program I read a lot more code; it's a practice I think that isn't generally encouraged enough)
03:51:22	smooth:	gmaxwell: agree, and afk
03:51:37	gmaxwell:	kanzure: sometimes the nits help break people out of their own lazyness, where you realize that it would be better to do it X way, but 'meh'. The reviewer doesn't have to write it, so the cost to them to suggest it is lower.
03:52:01	kanzure:	heh my nit to design ratio is like 4:1 at least
03:59:51	gmaxwell:	This is kind of a bummer; http://www.reddit.com/r/Bitcoin/comments/30q57y/question_for_core_devs_how_much_is_the_private/cpv4pcx
04:03:31	kanzure:	yes but that same argument can also be used to say "open-source software can be used by spy agencies" which is also a yawn statement
04:03:50	kanzure:	it's like people complaining about how food is "dual use" (eaten both by good/bad guys)
04:03:59	moa:	gmaxwell: that slur against blockstream's motivations in the last sentence seems misplaced?
04:04:38	zooko:	gmaxwell: I sent you IRC privmsgs. Never sure if those go through.
04:05:05	zooko:	Actually they always go through, but there was this one time years ago when they got silently squelched if somethingsomethingm and so I've never trusted them since. :-)
04:05:40	jcorgan:	gmaxwell: there you go again slumming on r/bitcoin, as if anything of importance happens there
04:05:55	gmaxwell:	moa: it's just a needlessly specific attack. If they want to argue that you shouldn't trust _anyone_, I'd certantly agree. But damn feels kinda shitty to be singled out after doing quite a bit to push user privacy and autotomy in ths space, and working hard to undermine survailance things.
04:07:24	moa:	and providing core dev time to protocol dev work ... maybe he meant to say blockchain and was confused
04:07:30	moa:	to many blocks
04:07:40	moa:	blockthingys
04:07:55	gmaxwell:	yea, indeed, if someone wanted to complain about bc.i and privacy, thats not hard to do.
04:11:45	zooko:	I looked at that just now, and my read of it is that the person was reaching for "Well-funded Bitcoin startup", and "Blockstream" is the thing that they find when they reach for that in their head.
04:12:17	zooko:	But, I feel your pain. The more successful you are the more of that pain you can look forward to.
04:12:41	kanzure:	nonsense, track records matter
04:13:25	jcorgan:	kanzure: success breeds resentment and envy, and even intolerance, from those who did not achieve that success
04:14:06	kanzure:	so?
04:14:29	gmaxwell:	well, it's just kind of a bummer, not the end of the world. And I just don't mean in the sense that being picked on is no fun, ... I'd rather have the good fortune of effective critics; that particular line of argument is probably the most misplaced of the ones they could make.
04:14:31	jcorgan:	so zooko's comment holds. unless yours was referring to something else and I misread
04:14:55	kanzure:	i am not convinced that gmaxwell would care about such a pathetic attempt at criticism, certainly not one so wrong
04:15:17	kanzure:	ah he said just as much
04:15:20	kanzure:	welp my job here is done
04:15:25	gmaxwell:	yea, I don't really mind it. Rather, sort of wishing for everyones sake that it were better directed. :)
04:15:32	gmaxwell:	(/constructed)
04:17:07	gmaxwell:	like, you know, not making a complaint of anti-privacy about a company formed by a group of people with some of the most efforts for privacy in that space; whos staff has been actively working on improving it (go look at sipa's recent commits, esp to 0.10 backports). They could complain that sidechains aren't a thing yet or something. :)
04:18:21	jcorgan:	meh. you guys just go execute and succeed, don't let the trolls occupy too much of your grey matter
04:19:54	gmaxwell:	I do try to avoid the trap of binning everyone critical as a troll... :) I've seen that not work out so well for some.
04:23:08	satwo:	gmaxwell: imagine how Satoshi must feel when he sees a comment along the lines of "bitcoin was invented by the NSA to institute a mandatory one-world currency under their complete surveillance and control"
04:23:50	gmaxwell:	"Darn, figured me out."
04:23:53	kanzure:	why should i imagine that
04:25:10	gmaxwell:	satwo: it's pretty flattering to hear that your works is really a secret plot by the best funded intelligence agencies and number one single employer of mathematicians. :)
04:25:56	moa:	the manhattan project?
04:26:25	satwo:	gmaxwell: touche.
04:28:59	phantomcircuit:	gmaxwell, lol
04:30:30	gmaxwell:	Someone at libre planet last weekend (aaron@snowdrift.coop) had asked me what other projects I worked on, and when I mentioned Bitcoin he said "I am not an Bitcoin apologist" and I said "Good, they get a bit tiring." and he then proceded to try to clarify what apologist meant, and was surprised that someone could work on the project without being the most extreme proponent of it that he'd encount
04:30:36	gmaxwell:	ered. I had a good time talking about all the varrious unknows and limitations that people gloss over. Worst fate ever is to have ineffective critics and misguided advocates. ::sigh::.
04:37:06	Luke-Jr:	lol
04:46:29	moa:	ha
06:36:55	maaku:	maaku is now known as Guest9869
07:34:44	maaku:	maaku is now known as Guest97134
08:05:15	wolfe.freenode.net:	topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
08:05:15	wolfe.freenode.net:	Users on #bitcoin-wizards: andy-logbot rusty Guest97134 terpo cbeams RoboTeddy arubi_ TRSullivan jcluck b_lumenkraft go1111111 Dwaddle spinza zooko luny` gonedrk amincd satwo coiner Adlai [7] bliljerk101 copumpkin p15 Guest77375 justanotheruser Dr-G2 moa NewLiberty d1ggy sadoshi raizor Cory cornus_ammonis c-cex-yuriy hashtagg_ irc88 jaekwon luktgf Chillum GAit dc17523be3 adam3us nubbins` jmaurice nsh MoALTz ebfull grandmaster fanquake Madars orik GibsonA dgenr8 luigiafk
08:05:15	wolfe.freenode.net:	Users on #bitcoin-wizards: Starduster JonTitor szumen yorick Emcy kyuupichan Logicwax d9b4bef9 tromp face runeks phantomcircuit EasyAt hashtag_ c0rw|sleep cgt_ OneFixt waxwing helo lechuga_ a5m0_ catlasshrugged_ luigi11111 isis PaulCapestany bosma nanotube Tiraspol Pan0ram1x yoleaux LeMiner PRab gmaxwell andytoshi berndj gavinandresen dignork AdrianG antgreen aakselrod maraoz_ s1w BrainOverfl0w MRL-Relay azariah btc___ throughnothing @ChanServ brand0 davout NeatBasis
08:05:15	wolfe.freenode.net:	Users on #bitcoin-wizards: mr_burdell Anduck CryptOprah leakypat TD-Linux K1773R indolering veox Eliel Graet warren gnusha jbenet mappum Keefe Oizopower platinuum Krellan kumavis artifexd smooth Taek starsoccer epscy null_radix Hunger- sdaftuar Alanius nickler fenn dasource @gwillen jaromil BlueMatt wumpus wizkid057 kinlo cryptowest_ coryfields_ Zouppen cfields Muis catcow kanzure petertodd NikolaiToryzin [d__d] jcorgan Apocalyptic Iriez lnovy midnightmagic larraboj
08:05:15	wolfe.freenode.net:	Users on #bitcoin-wizards: SwedFTP kefkius sl01 null pollux-bts ajweiss deepcore mariorz yrashk michagogo hguux__ Xzibit17 forrestv GreenIsMyPepper huseby harrow` STRML Luke-Jr Transisto adams_ rustyn nuke1989 so phedny melvster mkarrer_ ryan-c gribble lmacken warptangent sipa airbreather sneak jessepollak eric otoburb pigeons espes__ betarigs_admin ahmed_ binaryatrocity afdudley DoctorBTC nuke_ stonecoldpat SubCreative jgarzik crescendo HM tromp_ comboy_ jonasschnelli
08:05:15	wolfe.freenode.net:	Users on #bitcoin-wizards: dardasaba Fistful_of_Coins eordano_ roasbeef_ heath bedeho BananaLotus guruvan morcos dansmith_btc cursive Meeh fluffypony optimator livegnik
08:09:57	fluffypony:	moa: don't attribute to mistake what you can attribute to stupidity (re: blockthingys)
08:13:27	fluffypony:	I also don't get his assertion, he speaks about core/protocol dev and then jumps to talking about Jan Moller as an example of a dev who has been "bought"...except Jan Moller hasn't contribute anything to core?
08:14:06	fluffypony:	bizarre reductionist arguments
08:18:24	moa:	nor Cody Wilson afaik, it's all a pretty hodge-podge amalgam of half-ideas ... unfortunately his initial point that private companies building on top of bitcoin could contribute more back to core dev is worth making.
08:37:22	fluffypony:	moa: so basically he's decide how Bitcoin should be developed, and any deviation from that singular vision is clearly in violation of his imaginary perfect scenario
10:19:04	nsh:	andy-logbot, pointer?
10:19:04	nsh:	See http://download.wpsoftware.net/bitcoin/wizards/2015-03-30.html
10:19:22	nsh:	(stillb0rk)
10:20:06	fluffypony:	nsh: what's it supposed to do?
10:20:25	nsh:	point to the current entry in the logs (last line anchor), in theory
10:20:36	fluffypony:	oic
10:20:47	nsh:	which would be this: https://botbot.me/freenode/bitcoin-wizards/2015-03-30/?msg=35378024&page=3
10:25:19	luny`:	luny` is now known as luny
10:49:02	rusty:	Feedback welcome: http://rusty.ozlabs.org/?p=450
10:53:12	fluffypony:	nice rusty
10:53:17	fluffypony:	that is significantly easier for me to parse
10:54:11	rusty:	fluffypony: I ambitiously promised more to come... that's basically just 3.2 and part of 3.3 from the paper.
10:54:28	fluffypony:	I noticed
10:54:46	fluffypony:	I'm excited to read the next bi
10:54:47	fluffypony:	*bit
10:56:51	rusty:	fluffypony: Want to write it for me? :)
10:57:51	fluffypony:	I don't mind writing it *with* you :-P
10:58:46	rusty:	fluffypony: But... *I'm* only writing it because I want to read it! Reading the paper is *hard*!
11:00:43	fluffypony:	cryptography, in general, is hard...it just depends on if we're talking about discrete logarithm hardness or integer factorisation hardness
11:00:44	fluffypony:	* fluffypony makes joke
11:03:19	rusty:	fluffypony: I promise you I laughed, but not provably.
11:03:32	fluffypony:	* fluffypony tries to verify that
11:11:09	jcluck:	jcluck is now known as cluckj
12:38:04	rusty:	rusty has left #bitcoin-wizards
13:01:31	instagibbs:	rusty: nice writeup
13:16:39	Guest77375:	Guest77375 is now known as amiller
13:18:07	kanzure:	.title
13:18:08	yoleaux:	Lightning Networks Part I: Revocable Transactions - Rusty Russell's Coding Blog
13:21:28	kanzure:	"Breakthrough silicon scanning discovers backdoor in military chip" https://www.cl.cam.ac.uk/~sps32/ches2012-backdoor.pdf
13:21:34	kanzure:	(2012)
13:25:21	kanzure:	"Malicious SHA-1" https://malicioussha1.github.io/
14:43:37	Pasha:	Pasha is now known as Cory
15:42:18	luigiafk:	luigiafk is now known as luigi1111w
15:42:48	luigi1111w:	luigi1111w is now known as Guest45028
15:45:09	Guest45028:	Guest45028 is now known as luigi111111
15:51:22	fluffypony:	oh Reddit: http://www.reddit.com/r/Bitcoin/comments/30t3k4/proofofstake_is_more_decentralized_efficient_and/
15:51:29	fluffypony:	they've now suckered jgarzik into the debate
15:52:57	jgarzik:	fluffypony, I'm just a drive-by commenter, rather than a debater ;p
15:53:14	fluffypony:	lol
15:53:27	jgarzik:	fluffypony, as a public service I try to at least speak up and provide "this paper is bullshit" counter
15:53:36	jgarzik:	maybe that is too egotistical ;p
15:53:43	fluffypony:	no I think it's necessary
15:53:49	fluffypony:	it's just that they have an answer for everything
15:55:19	fluffypony:	this Neucoin crowd seem to have doomed themselves by alienating PoS supporters as well, they've apparently cherry-picked bits from NuBits and Blackcoin without attributing it to them
16:00:40	MRL-Relay:	[tacotime] are we still talking about neucoin
16:01:22	MRL-Relay:	[tacotime] oh, they're still posting in r/bitcoin.
16:01:30	fluffypony:	yes
16:15:26	fluffypony:	"The main purpose of PoS is not distribution. It's first and foremost an consensus mechanism. PoS coins can (and have: Peercoin, Blackcoin etc) use PoW as a distribution mechanism. The reason we didn't do it is we believe PoS allows to design a smarter distribution mechanism"
16:15:30	fluffypony:	* fluffypony rolls eyes
16:19:27	gmaxwell:	0_o
16:22:19	c0rw|sleep:	c0rw|sleep is now known as c0rw1n
16:22:39	kanzure:	jgarzik: "Separate of powers" -> "Separation of powers"
16:25:12	jgarzik:	kanzure, fixed
16:26:57	kanzure:	jgarzik: notfixed http://www.reddit.com/r/Bitcoin/comments/30t3k4/proofofstake_is_more_decentralized_efficient_and/cpvl80r
16:28:47	jgarzik:	kanzure, fixed for me, click reload. the other comment is not authored by me.
16:29:29	kanzure:	ah i forgot their page caching rules. yes, the individual link works.
16:30:31	Pasha:	Pasha is now known as Cory
16:35:47	satwo:	all the noise created by the altcoin/scamcoin scene may actually serve a positive, if unintended, purpose: keeping potential scammers and unscrupulous types from focusing their energy on what really matters in the long run (bitcoin and, I think, cryptonote/monero)
16:36:29	Chillum:	without scammers the bitcoin community would be in a terribly insecure state
16:36:44	Chillum:	consider it field hardening of the protocol and best practices
16:37:12	satwo:	good point.
16:37:30	DrGrid:	And the two are totally not Altcoins, lol! Choose your way either you're a maximalist or nothing.
16:37:55	satwo:	Monero is not an altcoin, it is a fundamentally different protocol.
16:39:19	fluffypony:	we're veering into #bitcoin territory, folks...
16:39:34	kanzure:	yes
16:39:47	satwo:	sorry, that's my fault... not really sure where to have those types of discussions
16:39:51	kanzure:	in #bitcoin
16:40:01	satwo:	(i gathered that :))
16:40:09	satwo:	but thanks for the heads up
16:51:41	a5m0_:	a5m0_ is now known as a5m0
16:59:12	fanquake_:	fanquake_ is now known as fanquake
17:38:30	luigi111111:	luigi111111 is now known as luigi1111w
18:03:36	andytoshi:	"The author even admits in his own conclusion: “there is no rigorous argument that it is impossible to obtain a distributed consensus without provably consuming some resource outside the system.”" what a dumbass, wasting time and energy on burden of correctness
18:11:37	andytoshi:	(for those missing context, i am faceteously calling myself a dumbass -- i don't mean to make this channel seem unfriendly :))
18:13:42	fluffypony:	I saw that jibe
18:13:48	fluffypony:	and decided not to mention it
18:14:14	Taek:	that would be a nice proof to have though - is anyone working on building one?
18:21:24	andytoshi:	Taek: it's really hard, try to even formalize the claim
18:22:28	gmaxwell:	Taek: those kinds of proofs usually are not so useful, they're often either circular or so narroly defined so as to be meaningless.
18:23:58	gmaxwell:	E.g. Assuming X, Y, Z you can't achieve exactly R, Q, N. They're not totally worthless because they can help focus your thinking when you're trying to do precisely the impossible thing. But usually the answer is to change the assumptions or deliverables slightly.
18:24:22	andytoshi:	ANN: for anyone interested in my school situation, i just sent an email to my supervisor in the CS department at UT saying that i'm leaving to return to the math dept. rather than doing academic crypto i'll be doing something like network information theory (not that i'll stop doing actual crypto here ofc :) the academic stuff was entirely a distraction from that anyway). the main reason is that
18:24:24	andytoshi:	switching departments would require me to do an extra couple years of coursework, which would be a thorough waste of my time (e.g. i'd have to do a compilers course, a database course, etc, because i don't have a CS degree). this also prevents me from joining the CS dept at any other schools; i am open to joining the math dept somewhere else if i could do more cryptographic work, but it's not a
18:24:26	andytoshi:	strong desire
18:25:11	andytoshi:	Taek: i think i made the statement much more concrete and useful in the new pos.pdf; there were some things i was thinking about really unclearly that i was able to figure out
18:25:58	andytoshi:	e.g. the realization that pos can (in principle and practice) give you a centralized consensus if the initial stakeholder always prevents others from joining. before i sorta assumed that consensus would always fail
18:26:50	andytoshi:	and how pos related to this fuzzy "DMMS" concept in my head; i thought pos was a broken dmms but now i think it's just totally different and trying to attack it for being a bad dmms would be a strawman
18:30:00	fluffypony:	andytoshi: would there be any value in the "learnings" from the extra few years, or is it too tangential to bother?
18:31:11	andytoshi:	fluffypony: no, zero value
18:31:22	fluffypony:	yeah I figured
18:31:34	fluffypony:	none of the core MRL guys are in comp sci, they're all pure maths
18:32:26	andytoshi:	fluffypony: in the last six years the "good" courses i've taken required nothing at all from me; the bad ones (like these) would involve a lot of gruntwork. but i have never attended lecture and never learned anything from them, they are always just in the way of my actual learning
18:32:59	fanquake_:	fanquake_ is now known as fanquake
18:39:19	fluffypony:	omg
18:39:23	fluffypony:	no
18:39:29	fluffypony:	* fluffypony bangs head into wall
18:39:41	fluffypony:	https://bitcointalk.org/index.php?topic=1001642.msg10932356#msg10932356
18:40:02	fluffypony:	"it's more like math hasn't got to the stage where it can describe complex systems, i.e. chaotic systems, e.g. weather, turbulence, market behaviour. That's not a 'human element', it's a 'chaotic element'. Cryptography's purpose is to obscure information for the purpose of un-obscuring it later. Which is essential for underpinnings of mechanics of crypto currency. But when you want to start to lose information like you do with
18:40:02	fluffypony:	anonymity, (in my opinion) it's not the best suited way. Because it's essentially reversible with the right tools (because the information is confined in one place, it security relies on your ability to decode it)."
18:40:26	fluffypony:	sorry, andytoshi, you may as well give up now. math just hasn't got to the stage where it can describe complex systems like MasterNodes
18:41:09	fluffypony:	pretty much all you can do with maths is like your bill at the restaurant and calculate the airspeed velocity of an unladen swallow
18:41:29	andytoshi:	fluffypony: ya, i am gonna type a response to that at some point
18:41:33	andytoshi:	he PM'd me asking me to
18:42:08	andytoshi:	this "cryptography is not appropriate for hiding information" thesis is bizarre
18:42:44	fluffypony:	"masternodes 'depend on humans for security' in the same way that bitcoin fullnodes 'depend on humans for security' dude. It's a misapplication of the concept of trustless operation."
18:43:04	fluffypony:	I feel like I'm watching a bunch of 3rd graders performing open-heart surgery
18:43:29	fluffypony:	maybe they even recognise some of the surgical instruments from TV, but they have no clue what they are doing
18:44:27	andytoshi:	that's a good analogy. i'm not sure if i should keep touching it
18:51:54	bramc:	Hey everybody, I have questions/thoughts about this post: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d
18:52:53	bramc:	The author seems to be saying that 0conf is important central functionality, which I think is a little nutty, but can buy the argument that 0conf is something which people are likely to do anyway so you shouldn't try to break it.
18:54:03	bramc:	Which leads to the question of why you can't have a totally reasonable middle ground: Why not allow for replace-by-fee, but only for transactions with the same inputs and outputs with the same unlock scripts? What's wrong with tacking on child pays when you don't have scorched earth?
18:55:00	bramc:	I'm guessing that 'scorched earth' here refers to the very specific practice of a peer throwing out an unconfirmed transaction when a new one with the same input and a different output but a higher transaction fee shows up.
18:55:43	instagibbs:	I think a lot of e-ink is wasted on scorched earth, per se. Either you believe the steady state will be RBF, or not. You can't force miners to run policy like that.
18:55:45	bramc:	But that only matters if the unlock script has changed, which isn't wanted for the fee increasing functionality anyway
18:57:05	bramc:	instagibbs, Yes there's a large amount of people needing to give up on 0conf already, but there's a practical question of what you can get into the standard codebase today, and my proposed middle ground seems like it should be acceptable to everybody.
18:57:15	sipa:	bramc: allowing limited replacement was the original design
18:57:20	sipa:	of bitcoin
18:57:43	bramc:	sipa, Do peers currently support limited replacement?
18:57:47	sipa:	no
18:57:55	sipa:	it was disabled years ago
18:58:02	bramc:	Uh... why?
18:58:47	sipa:	it complicates wallet design
18:58:47	instagibbs:	what did limited replacement do? Tack on an additional input/output pair?
18:58:47	bramc:	People should fix the damn wallets anyway :-P
18:58:50	bramc:	child pays should work fine but doubles transaction size, which is a serous problem.
18:59:00	sipa:	(cpfp and rbf also requre wallet complication)
19:00:04	bramc:	sipa, The current flame war doesn't seem to be about wallet design, it seems to be about 0conf
19:00:19	sipa:	yes
19:01:00	sipa:	oh, the limited replacement functionality was only for nonfinal transactions
19:01:10	bramc:	What does 'nonfinal' mean?
19:01:14	sipa:	which were a huge dos attack surface
19:01:37	sipa:	nonfinal == cannot go into the blockchain yet
19:01:50	bramc:	That sounds backwards
19:01:52	sipa:	through locktime and other means
19:02:55	bramc:	You want limited replacement for transactions which aren't going through because their fees are too low, those are by definition not nonfinal
19:04:12	sipa:	the original replacement feature was for certain contracts
19:04:22	sipa:	not for postfacto fee increases
19:04:53	bramc:	Okay, let's assume that the original replacement feature is long gone and irrelevant
19:05:01	sipa:	okay
19:05:19	sipa:	cpfp is enough for fee increases
19:06:05	dgenr8:	bramc: in your proposal, could the replacement pay more to output 0, but an overcompensatingly less to output 1, to get to net higher fee? If so I could rip somebody off.
19:06:35	bramc:	sipa, What is cpfp an acronym for?
19:06:49	instagibbs:	child pays
19:07:31	bramc:	dgenr8, I'm proposing requiring that the output script(s) have to be the same
19:07:40	dgenr8:	i'm only changing the amounts
19:07:59	bramc:	dgenr8, Oh sorry, amounts should have to be the same as well
19:08:18	dgenr8:	then you have to add inputs to raise the fee
19:08:22	bramc:	oh wait, but then you have to decide whose amount goes down when the transaction fee goes up. That's an interesting question
19:08:40	bramc:	Let's say that the rule is that outputs can only go down
19:08:48	bramc:	bbiab, lunch
20:11:35	Guest97134:	Guest97134 is now known as maaku
20:28:47	bramc:	Okay, more thoughts: It should be okay for a new transaction to add both new inputs and new outputs, as long the old outputs are kept to their same level.
20:30:55	bramc:	Lowering output has the problem that you can spitefully destroy
20:32:00	bramc:	Actually, dumb question: Is there a way with cpfp for a child transaction to depend on a parent transaction even without spending its outputs in any way?
20:33:14	gwillen:	... that's actually a really interesting question
20:33:15	bramc:	That would get around some (most?) of the bloat problems of cpfp by allowing aggregation of a whole bunch of smaller transactions to be paid for by a bigger one with a consolidated fee without all that much blowup
20:35:11	bramc:	It would be trivial to add an extension to support that
20:35:28	bramc:	OP_HAS_BEEN_COMMITTED_VERIFY
20:36:30	gmaxwell:	bramc: yea, that kind of replacement has been discussed before. to prevent DOS you really want to also demand the fee goes up by some reasonable quanta at each step.
20:37:02	bramc:	Also interesting to design a lottery protocol so one of a set of parents has to refund, picked at random
20:37:41	bramc:	gmaxwell, That fee going up thing can be a matter of policy instead of being baked into the spec
20:39:00	kanzure:	at the moment there is no way to check for the presence of another transaction
20:39:35	kanzure:	iirc there are many fair proposals for a hard for kto introduce that (although no particularly written-down proposals), and so far no soft forks? i think?
20:41:00	gmaxwell:	bramc: sure well any of this is "just policy", the important point there is keeping the bandwidth usage finite.
20:41:25	gmaxwell:	kanzure: there is a very straightfoward way to do that-- spend one of its outputs.
20:41:33	kanzure:	but his criteria was.. er..
20:41:34	bramc:	kanzure, Shouldn't require a hard fork, an OP_VERIFY should work fine
20:41:55	kanzure:	"without spending its outputs in any way"
20:42:10	bramc:	gmaxwell, spending an output is much larger. A new opcode could use a total of 256 + 8 bits
20:42:20	gmaxwell:	kanzure: most things that people propose there are scale-fails.
20:42:41	kanzure:	can you elaborate?
20:43:27	bramc:	OP_HAS_BEEN_COMMITTED_VERIFY: one byte to specify opcode type, 256 bits of specifying what it's reliant on. If that tx isn't in the committed set, it rejects
20:43:33	gmaxwell:	kanzure: e.g. multiplicatively increasing the IO cost of verifying a transaction, breaking pruning, etc.
20:44:02	gmaxwell:	(much of the cost of verifying a transaction is simply looking up each of its inputs)
20:44:08	kanzure:	bramc: there are many good reasons to do that. another approach is OP_PLEASE_HAVE_THIS_BLOCKHASH_IN_HISTORY
20:44:34	gmaxwell:	blockhashes are easier to test and scale.
20:44:43	kanzure:	oh right i did forget about the scaling problems of these proposals
20:44:45	bramc:	kanzure, blockhash doesn't work for child pays because the parent and child are pending at the same time
20:44:48	kanzure:	hmm i will have to look more closely at this sometime
20:45:02	kanzure:	bramc: yes i think you are solving a more specific problem than the one i'm thinking about
20:45:38	bramc:	kanzure, The one and only problem I'm trying to solve is that child pays bloats up the history by a factor of 2
20:46:23	kanzure:	gmaxwell: you could make the scalingness matter much less.. i mean, you could artificially limit it to transactions from the last N blocks, where N is totally arbitrary. and if they want to reference something older, they should switch to a lbockhash maybe.
20:46:27	kanzure:	*blockhash
20:47:01	bramc:	How about OP_IS_COMMITTED_IN_SAME_BLOCK_VERIFY ?
20:47:23	kanzure:	when would i want something to be in the same block, but not want to know whether it was in a previous block?
20:47:36	kanzure:	*when would i want to know something was in the same block
20:47:55	gmaxwell:	kanzure: last N things are not reorg safe.
20:48:01	bramc:	Er, what kanzure said, where I was proposing n=1, but allowing n to be a small number more
20:48:05	kanzure:	they are if you do something like 100 <= N <= 150
20:48:35	kanzure:	heh i guess it's less useful if it's already 100 blocks deep anyway
20:48:44	bramc:	Transactions are not reorg safe :-P
20:48:44	kanzure:	i mean if the parent is
20:49:23	gmaxwell:	bramc: there is a big difference between things that will _spontaniously_ fail on their own, and things that require malicious action to fail.
20:49:46	kanzure:	yeah i suppose not baking in spontaneous failure would be a nice thing to do
20:50:09	bramc:	gmaxwell, Isn't the lookup requirement of my proposed extension exactly the same as handling child pays normally?
20:50:48	gmaxwell:	bramc: no because child pays works fine if the txn end up split across two blocks.
20:51:16	bramc:	gmaxwell, But it's the same number of lookups total, isn't it?
20:51:34	bramc:	Also I'm thinking that the number of verifies isn't generally huge, it's like 100 or something
20:51:52	bramc:	Some value where the metadata overhead is insignificant
20:52:11	bramc:	The 2x factor of child pays is a real issue
20:53:18	gmaxwell:	bramc: depends, like if something has implemented a freeform lookup tx it may be enormously more work per unit of blocksize limit. Also, 'has x' is a query against the complete history, as opposed to 'spends x' is a utxo query.
20:54:08	bramc:	Ooooh, the issue is whether it's unspent or not
20:54:37	bramc:	Because the unspent set is smaller
20:55:06	gmaxwell:	perhaps for the very narrow purpose of a CPFP you can do something like the child is only good in the same block, and it's not reorg safe.. but it's a narrow application. But ::shrugs::
20:55:34	gmaxwell:	bramc: right, bitcoin core doesn't even keep a database of the other stuff. The full UTXO database is about 600MB.
20:55:38	kanzure:	cpfp = child pays fee pillowfight?
20:55:55	bramc:	Child Pays For Parent
20:56:19	kanzure:	throw in some 4s into that, man
20:56:26	bramc:	gmaxwell, How about dependency on the transaction being in the unspent set? Also not reorg safe...
20:57:46	bramc:	Requiring it be in the exact same transaction is likely to start failing if you have a big set and a few things get accepted early
20:59:06	bramc:	Although it might be unusual for a transaction to get accepted and spent when it was having trouble even going through, and whoever did the payment transaction can just reissue.
20:59:29	bramc:	Although, hmm, the remember first policy gets in the way of that.
21:02:15	bramc:	Oh I know, you have the opposite OP_VERIFY, which is that something *not* be in the utxo set, and you apply it to the grandparent
21:03:15	bramc:	With the edge case of being spent in the same block defined as passing
21:05:22	bramc:	gmaxwell, Is OP_NOT_IN_UTXO_SET_VERIFY to your liking?
21:10:16	gmaxwell:	as in, you can't include this txn if that other one is still spendable? thats probably better.
21:10:46	gmaxwell:	that sounds like it has reasonable scaling behavior and reorg safty.
21:12:57	phantomcircuit:	damn left the space heater on overnight
21:13:09	phantomcircuit:	if it was a miner i'd be tens of cents less poor
21:30:35	petertodd:	bramc: re: zeroconf "safe"/"honest" replacement, that's been implemented by aalness: https://github.com/petertodd/bitcoin/pull/3
21:31:12	petertodd:	bramc: it's pretty easy to use, as inputs can be changed, letting you swap out a smaller input for a larger one, and then increasing the nValue of the change txout with the difference minus the new tx fee
21:31:31	petertodd:	bramc: I'll submit it as a pull-req for bitcoin core sooner or later
21:33:00	petertodd:	bramc: re: "giving up on 0conf" it's remarkably hard to actually find any major users relying on 0conf right now at all; standard pattern seems to be services enable it, get ripped off, and quickly turn it off (e.g. atm operators)
21:33:45	petertodd:	bramc: https://shapeshift.io/ is another example, that claims to accept 0conf but doesn't appear to actually do so
21:34:25	gmaxwell:	Whats interesting to me is that people _really_ do not understand the tradeoffs/risk exposure there. E.g. they keep being surprised by things which I think are really not surprising.
21:36:01	justanotheruser:	petertodd: there are small scale 0conf attacks in the wild? I thought there was some security through obscurity while replace-by-fee wasn't the norm.
21:36:37	petertodd:	gmaxwell: doesn't help that people don't make their failurs public... e.g. aalness seems to indicate coinbase doesn't want to talk about it: https://twitter.com/petertoddbtc/status/582207428193714176
21:36:55	gmaxwell:	justanotheruser: If you deployed accepting zero conf without really understanding the risks, you're also probably likely to overreact when you do get ripped off.
21:36:59	petertodd:	justanotheruser: for sure, lots of them, and people do the rational thing and quickly turn 0conf off after one or two successful attacks
21:37:40	petertodd:	justanotheruser: e.g. just a few weeks ago I talked to another atm operator who saw once, and switched to requiring a confirmation after the first $100 or something loss
21:38:04	pigeons:	yes coinbase has come in here and admitted they are getting ripped off from 0 confirms, then blamed it on eligius for not mining the 1st tx because one of the inputs was a known gambling game
21:38:16	justanotheruser:	is that because their first tx isn't relayed about the network yet, or because some miners do the rational thing?
21:38:31	petertodd:	pigeons: ah, ok, so that's something like the third time that's happened then
21:38:51	justanotheruser:	LOL they blamed eligius?
21:38:52	petertodd:	pigeons: (er, third as in what I personally know about)
21:39:03	petertodd:	justanotheruser: yes, as did mike hearn on his recent blog post
21:39:05	pigeons:	yes coinbase asked for help and the answer was, "wait for confirmations" they said that isnt a good customer experience
21:39:57	petertodd:	pigeons: it's not clear to me that they actually understand what "wait for confirmations" really means re: UX
21:40:22	justanotheruser:	don't fiat withdrawals tend to take more than 10 minutes? What exactly is the problem for them with waiting for confirmations
21:40:59	gmaxwell:	sort of ironic for coinbase blaming something for not assc. with a known gambling address, considering that sending to one of those from your coinbase wallet reportadly results in your account being immediately frozen and closed.
21:41:12	petertodd:	gmaxwell: lol
21:41:12	pigeons:	justanotheruser: it doesnt answer your question or the question in general, but this particular instance was not a fiat withdrawal but coinbase acting as a payment processor for a 3rd party merchant
21:41:36	gmaxwell:	(unless that has changed since the initial reports on reddit)
21:41:51	petertodd:	pigeons: was this merchant actually relying on 0conf? or was it the more usual case where losses are zero? (e.g. shipping a product hours later)
21:42:45	justanotheruser:	pigeons: that makes sense then. The rational thing is probably to evaluate the fraud rate and give the merchant an ultimatum of 1-conf or 0-conf and high fee
21:42:46	pigeons:	petertodd: my uunderstanding was the merchant relies on coinbase saying "you have been paid you can release the goods", not that the business case actually required 0 confirms
21:43:12	petertodd:	pigeons: right, coinbase is taking on a huge risk doing that...
21:43:58	pigeons:	yes then they told everyone how to do it to them more
21:44:22	petertodd:	pigeons: they were so angry at replace-by-fee that they canceled a contract with me to implement proof-of-reserves
21:44:43	gmaxwell:	it's hard. You're trying to sell vendor X on accpeting bitcoin via you. Explaining zero conf security tradeoffs is not a good sales pitch.
21:45:24	petertodd:	gmaxwell: indeed, and coinbase is big enough to fool themselves into thinking they can pull it off anyway by throwing engineers at the problem; if they start throwing lawyers at the problem...
21:45:29	justanotheruser:	maybe they should contract you to implement green addresses and payment channels
21:46:20	pigeons:	in ruby
21:46:38	petertodd:	justanotheruser: that was discussed earlier actually; curiously they brought up "conflicts of interest" as one of the reasons to cancel the contract - wonder if they realise I don't have any clients doing that stuff...
21:46:53	justanotheruser:	pigeons: beating a dead horse :P
21:47:31	justanotheruser:	petertodd: I think the conflict of interest in their eyes is you increasing their fraud risk and being paid to implement the solution
21:48:31	petertodd:	justanotheruser: could be, however there's a lot of people who are more likely to get paid to fix that problem than me
21:48:54	bramc:	petertodd, The rumor I heard is that coinbase has contractual obligations to accept 0conf
21:49:12	petertodd:	bramc: I think it's highly likely that rumor is true
21:49:48	petertodd:	bramc: their api docs say they do that, minus the contractual obligation part
21:51:13	gmaxwell:	Whats interesting to me is that some people (e.g. tom, and it sounds like coinbase) are actually confusing RBF assisted double spends (which there should be absolutely zero of now, as AFAIK there are no miners with that policy); and the inevitabilities of asynchronicity in the network (or other unavoidable or long term existing differences in state)
21:52:17	phantomcircuit:	gmaxwell, i kind of wonder if discuss fish is rbf
21:52:29	phantomcircuit:	they seem to get the blocks very close to being full
21:52:36	phantomcircuit:	which i think would be easier with rbf
21:52:43	phantomcircuit:	(maybe not)
21:53:52	gmaxwell:	see the conversation in #bitcoin-dev last night with Tom; he linked https://gist.github.com/aalness/a78e3e35b90f52140f0d and I pointed out that RBF does nothing interesting there, sender just sends t1 and t2 concurrently and he can more or less precisely pick which nodes have one vs the other, which is much better than RBF in the sense that it actually works whereas RBF currently does not. For
21:53:58	gmaxwell:	some reason this didn't seem to click for him, at least not right away. Maybe there is some way we're explaining bitcoin to people which is inherently confusing?
21:54:22	dgenr8:	jeez. i have never misunderstood the speed of light. the fact that I think improvement is possible, does not mean I believe in the impossible.
21:55:07	bramc:	According to our psychoacoustic studies we need a 100 millisecond round trip time between new zealand and spain. Make it happen.
21:55:49	phantomcircuit:	heh
21:57:13	petertodd:	bramc: I'll get all my top men on that, for your top dollar
21:57:14	gmaxwell:	dgenr8: Didn't say you did there. What I'm pointing out is that you seem to keep being surprised by things like me pointing out that concurrent transmission has the same result. I don't mean to pick on you, you're not alone. But to me this is the most obvious thing possible, and it makes me wonder if something isn't being expressed poorly if you're failing to have really good intutions on the ho
21:57:20	gmaxwell:	w things like that work.
21:57:31	lechuga_:	that gist was wrt btw: https://github.com/aalness/bitcoin/commit/659399cc941db14d25f6a29494bdc01acd2ae458
21:57:48	lechuga_:	(that patch was just an experiment)
21:57:58	dgenr8:	yes andy also sent me that, haven't had time to look at it
21:58:07	petertodd:	phantomcircuit: I doubt they're rbf, as I recently did a test designed to only get mined by rbf miners, which showed somewhere between 0% and 1% adoption
21:58:13	gmaxwell:	lechuga_: ah, thats the "allow output supersets"? Cool that you went and implemented it.
21:58:29	petertodd:	phantomcircuit: which funny enough hearn was going around saying the test was proof rbf doesn't work...
21:58:31	lechuga_:	gmaxwell: nod. wanted to think more about the behavior. ultimately don't like it.
21:58:47	petertodd:	lechuga_: why?
21:58:49	gmaxwell:	lechuga_: What don't you like about it?
21:59:07	phantomcircuit:	petertodd, lold
21:59:41	lechuga_:	if the intent is to increase confirmation priority seems like child-pays-for-parent would be smoother
21:59:50	petertodd:	lechuga_: cpfp uses much more blockchain space
21:59:57	justanotheruser:	petertodd: you sure the 0-1% isn't just latency?
22:00:10	petertodd:	justanotheruser: that's why the range I gave includes 0% :)
22:00:14	justanotheruser:	heh
22:00:42	petertodd:	justanotheruser: it's actually kinda tricky to design tests like that to avoid latency false-positives
22:00:48	gmaxwell:	lechuga_: CPFP is really terrible to implement in terms of mempool management, and it's less efficient (= more fees). Both probably have a place.
22:01:37	gmaxwell:	lechuga_: optimal block filling under CPFP is probably NP-complete, and even the hurestic soltions for it seem to produce hairball code... which is why we don't have it in Bitcoin core yet.
22:01:41	petertodd:	gmaxwell: also, cpfp doesn't currently work in the case where the parent didn't have enough fees to get relayed
22:01:44	phantomcircuit:	the CPFP stuff is a DoS magnet
22:01:59	phantomcircuit:	chain a bunch of transaction together and then adjust the fees just a little
22:02:22	lechuga_:	ic
22:02:26	gmaxwell:	petertodd: yea, we don't have an INV that can transmit TX as groups.
22:02:45	bramc:	gmaxwell, A greedy approach of highest fee first should work okay for prioritizing cpfp
22:02:52	petertodd:	gmaxwell: exactly, same reason why I've never implemented rbf se w/ cpfp
22:03:04	petertodd:	gmaxwell: yay acronyms!
22:03:14	dgenr8:	Maybe there is some way we're explaining bitcoin to people which is inherently confusing? <--- spare me the passive aggressive alpha-geek bullshit. please ;)
22:03:18	bramc:	Not ideal for adding together grandchildren and great-grandchildren, but good enough.
22:03:42	petertodd:	bramc: I've actually done a fair bit of work implementing that, and it's really complex compared to the current stuff
22:03:59	lechuga_:	also dont like introducing another simple finney attack vector re: gist
22:04:01	petertodd:	bramc: er, s/stuff/implementation/ to be clear
22:04:18	gmaxwell:	dgenr8: Thats out of line.
22:04:22	bramc:	petertodd, I'm sure, my point is that NP-completeness isn't something to be terribly worried about
22:04:22	petertodd:	lechuga_: all IsStandard() changes do that; do you suggest we never change anything?
22:04:36	petertodd:	bramc: yeah, well, I'm a fine arts grad :P
22:05:16	lechuga_:	are those my only choices?
22:05:27	petertodd:	lechuga_: what do you mean?
22:06:04	lechuga_:	nm, but point taken
22:06:29	gmaxwell:	lechuga_: I think PT's comment was that _any_ difference in node policy gives you that, so it's not very interesting to avoid. Actually he wasn't expansive enough, really any difference in _state_ gives you that. See my example with just concurrently announcing t1 and t2.
22:06:51	gmaxwell:	Its unfortunate (IMO) but I think unavoidable, so not a reason to shy away from something useful.
22:07:39	gmaxwell:	bramc: the "pick highest fee first" by itself doesn't work, e.g. you make a huge bloated chain of low fee txn, then add a single high fee cap.
22:07:46	lechuga_:	then i guess i'd prefer 'honest' rbf behvaior since i think a well-connected observer can have a much better chance at detecting the fraud
22:08:28	petertodd:	lechuga_: well, like I said, submit it as a pull-req and I'll ACK it
22:08:29	bramc:	gmaxwell, Caveat of using highest fee/byte including all uncommitted ancestors, yadda yadda yadda, a bunch technical details which are annoying to implement
22:08:59	petertodd:	bramc: remember that any tech detail that you didn't understand fully can easily lead to a DoS exploit here
22:08:59	dgenr8:	gmaxwell: sorry. it is your forum, after all
22:09:06	gmaxwell:	bramc: yea yea, then you end up with the hairball stuff thats been written already, and has laid fallow because no one wants to review it.
22:09:32	lechuga_:	petertodd: i did
22:09:40	petertodd:	lechuga_: no, I mean to bitcoin core
22:10:40	lechuga_:	meh
22:11:06	lechuga_:	would rather spend time on a real solution to 0conf
22:11:12	petertodd:	lechuga_: hey, if you submit it, you can call it "honest replace-by-fee" - I'll just call it "firstseen safe" :P
22:11:19	lechuga_:	heh
22:11:36	petertodd:	lechuga_: we do need a fix for fee bumping...
22:11:51	gmaxwell:	lechuga_: I don't think we had any opposition to that kind of superset replacement so long as the fee goes up every time.
22:13:51	gmaxwell:	(fee needs to go up some minimum threshold amount to prevent someone from making it into a DOS vector where they make a single very low priority txn and then keep updating it; same as why we don't realy non-final txn)
22:14:25	petertodd:	gmaxwell: my rbf patch makes fee go up by same amount per byte as min relay fee
22:14:36	gmaxwell:	petertodd: yea, that seems reasonable to me.
22:15:53	gmaxwell:	There is some increased 'successful sender mutation risk' there, but I don't think it's an interesting attack vector because it can't be much worse than what you can get from concurrent broadcast already.
22:16:46	justanotheruser:	Has block withholding + replace-by-fee DoS been discussed?
22:16:47	gmaxwell:	e.g. I send you a txout. You make a spend of it while unconfirmed. I successfully mutate the payment out from under you, invalidating your spend.
22:16:56	petertodd:	justanotheruser: ?
22:17:17	petertodd:	gmaxwell: which is a practice damn near no wallets allow anyway
22:17:36	justanotheruser:	petertodd: If I am guaranteed to win I can spam the network with 100BTC worth of transactions incrementing each time without risk of miners eating my 100BTC in fees
22:17:59	justanotheruser:	s/incrementing each time/incrementing the fee each time/
22:18:01	petertodd:	justanotheruser: right, however that's not any different from what you can do right now anyway
22:18:15	justanotheruser:	yeah...
22:18:27	petertodd:	justanotheruser: you can just spam 100BTC worth of standard transactions, and anywya, spamming transactions as a DoS vector is hard
22:18:45	gmaxwell:	petertodd: yea, it's crazy to do that in any case already; but I'm just trying to think inclusively.
22:21:12	phantomcircuit:	Its unfortunate (IMO) but I think unavoidable
22:21:47	phantomcircuit:	there's probably some shenanigans that can be played by measuring hashrate working on a tx
22:21:53	phantomcircuit:	but that certainly cant be done today
22:25:35	petertodd:	phantomcircuit: I proposed that awhile back actually: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02868.html
22:38:01	phantomcircuit:	petertodd, to be fair it's kind of an obvious solution :P
22:38:10	phantomcircuit:	(im sure someone else has suggested this before)
23:10:20	petertodd:	phantomcircuit: well, at the time it wasn't obvious to me, lol
23:11:07	bramc:	What do bitcoin atms do when they don't support zeroconf? Do they require you come back after a few minutes to get your cash?
23:18:07	justanotheruser:	bramc: get your identity
23:18:53	bramc:	justanotheruser, identity meaning what? Something more than the owner of a particular pubkey?
23:19:53	justanotheruser:	bramc: I think you need to go through a verification process before using one and then you can identify with your fingerprint. Though that is just one ATM a year ago
23:20:32	bramc:	justanotheruser, That doesn't sound very bitcoinish
23:20:41	justanotheruser:	it involves bitcoin doesn't it?
23:20:51	justanotheruser:	not much they can do when AML/KYC laws exist
23:21:30	moa:	palm scans, facial photos, ID scans ... atm are full on KYC/AML dragnets in some places
23:22:18	moa:	and then limit transactions sizes to less than $1000 lol
23:23:29	moa:	like columbian cartels are using bitcoin atms to wash their cash ...
23:37:33	petertodd:	bramc: that's exactly what they do; some operators are even better and let you deposit funds in advance on a website prior to actually going to the atm in person
23:39:58	bramc:	petertodd, Better than giving people the cash without authentication and making them pinky swear that they'll hand over bitcoin later.