00:16:58	rusty:	phantomcircuit: I'd like to see SPV nodes do something like "adopt-a-block" where they pick (one or more) random blocks and store and verify it, then maintain proofs of all spends of outputs in that block.
00:18:40	maaku:	rusty: how do you verify the inputs to the block though?
00:19:23	maaku:	i mean it's a good idea, but there's an engineering challenge there
00:19:26	rusty:	maaku: best effort; but I think it's kind of a ratchet as more people do this.
00:19:43	gmaxwell:	certantly easy to do that in pruned nodes; (though random blocks by themselves are not quite ideal as you have a discovery problem)
00:20:26	gmaxwell:	rusty: with the bitcoin commitment structure there is almost nothing to can verify statelessly like that, at least not without huge overhead-- can't verify signatures or fees or the coinbase output amount. :(
00:21:16	gmaxwell:	this old page https://en.bitcoin.it/wiki/User:Gmaxwell/features#Proofs walks over some of that (I may have shown that to you before)
00:21:18	rusty:	gmaxwell: sure, but you can provide proofs if future blocks have double-spends.
00:21:43	maaku:	rusty: I mean, for a given input all you have is the txid hash of the input. i suppose you could build a bloom filter of all the inputs to the block and do a bloom filter "wallet" sync.
00:21:57	maaku:	I shudder to think what that do to full nodes resource usage though :\
00:22:34	rusty:	maaku: yeah, don't do that. But you'd need something like that to get txs which spend from your adopted block(s).
00:22:38	maaku:	wait duh bloom filters are over scriptPubKeys not txids
00:23:11	gmaxwell:	rusty: well my point at that page was less the random checking and more the random verification a check, I was still assuming someone somehere ran a (pruned) full node and would notice the invalidity and then it would propagate.
00:23:30	MAKOHYPE:	MAKOHYPE is now known as bosnia
00:23:42	gmaxwell:	but indeed some kind of filtering could make actual fraud discovery also perhaps work.
00:23:43	cryptonaut:	cryptonaut is now known as Guest8949
00:24:06	rusty:	gmaxwell: I'm trying to push it to the extreme, where SPV nodes can fill archive and fraud proof requirements which currently require full nnodes.
00:24:53	maaku:	rusty: I think that's the desired end-state of pruned nodes
00:24:54	rusty:	gmaxwell: not sure it's possible, if most nodes won't relay txs to you they're not personally interested in though.
00:25:39	rusty:	maaku: yeah, and I guess the "last N blocks" is the thing you want assured in *practice*.
00:26:59	maaku:	so with txout commitments that's the goal -- you sync utxo state and work your way backwards N blocks
00:29:45	rusty:	maaku: That would be nice. adopt-a-block might still make sense for archival purposes. But as gmaxwell said, discoverability problem.
00:30:54	gmaxwell:	well I've suggested before that listening nodes could advertise a single short nonce and a size, and from that you can compute at any time what block range(s) they will have.
00:30:58	gmaxwell:	which solves discoverability.
00:31:09	gmaxwell:	but I was thinking that more in terms of pruned full nodes, not SPV adopt a block.
00:31:49	akrmn:	rusty: that's why I'm telling people subchains are good for scaling (you can constraint outputs to subchains). But still waiting for sipa's response to that.
00:32:38	akrmn:	Mike Hearn suggested SPV some storing random subsets of blocks but I doubt that would be reliable.
00:32:40	rusty:	gmaxwell: yeah, you could still hack it by relaying requests (and results) I guess. Might have to if SPV nodes are generally not listening nodes.
00:32:52	akrmn:	*SPV nodes
00:33:25	rusty:	maaku: BTW, I re-read my notes on SPV proof minimization. My conclusion was that it's far easier if we select a point to optimize for; I was using the genesis block but that's not actually what we want.
00:34:54	rusty:	maaku: it's an engineering question, really. 144 blocks ago? 1008 blocks?
00:35:11	moa:	pruned nodes could keep last-120 plus adopt-N-blocks
00:37:19	gmaxwell:	moa: bitcoin core won't even currently run without 288 of the most recent, fwiw.
00:37:40	moa:	oh right ... last-288
00:37:52	moa:	120 is coinbase spend
00:38:49	maaku:	moa: 100
00:38:55	moa:	hah
00:43:16	moa:	is there any work done on researching UXTO distributions over block height? ... i.e. are some block 'eras' more uxto dense than others?
00:44:01	gmaxwell:	very much so.
00:52:45	moa:	som inherently not all blocks are 'equal' in the snese that some blocks have more value than others in terms of informational content
00:52:58	moa:	so not som
01:24:14	DanielBTC:	DanielBTC is now known as Guest60637
01:37:05	Guest60637:	Guest60637 is now known as DanielBTC
02:33:42	bosnia:	bosnia is now known as bosma
02:38:16	bosma:	bosma is now known as BATTLEFRONTHYPE
02:42:07	BATTLEFRONTHYPE:	BATTLEFRONTHYPE is now known as bosma
03:04:13	jae:	jae is now known as Guest83499
07:23:16	antanst:	antanst has left #bitcoin-wizards
07:25:31	weex:	theymos: phantomcircuit do dns seeds do that sort of checking of nodes they're advertising?
07:26:14	gmaxwell:	weex: sipa's DNS seed (and other seeds running his software) perform some limit tests.
07:26:57	weex:	my other question is what does an spv node do when post-fork it ends up on the other side, rebuild from genesis block or just get all inconsistent with itself
07:27:26	gmaxwell:	I don't understand the question, where do you think an inconsistency is coming from?
07:28:03	weex:	first of all i don't know how it handles peers that are different forks
07:28:22	weex:	does it drop the minority or the ones that disagree with what it stored as its best block
07:28:50	gmaxwell:	SPV nodes follow the chain with the most apparent proof of work.
07:29:00	gmaxwell:	Number of peers is irrelevant unless you're partitioned.
07:29:45	weex:	most apparent being highest difficulty?
07:29:58	theymos:	weex: AFAIK none of the DNS seeds do any in-depth checks. I think they'd include hardforking XT nodes, for example.
07:30:48	gmaxwell:	weex: the most work. Not highest difficulty, if you just mean difficulty at the tip. The sum of difficulty of the blocks. Perhaps #bitcoin for basics questions. :)
07:32:03	weex:	heh, ok...i was just trying to figure out how the world of coffees might be affected by this proposed hard fork
07:33:12	weex:	i imagine a lot of code doesn't assume this kind of thing might happen so lots of conjecture is to be expected
07:40:19	theymos:	Peer discovery is something I've been thinking about for a while. I feel like Bitcoin Core should maintain more info about past peers and try to always connect to a few that seem long-term-reliable/trustworthy (in addition to some newer ones), and this data should also be used for the DNS seeds.
07:41:20	theymos:	I suppose it's difficult to do this in a way that wouldn't make things even easier for a patient Sybil attacker. But the current way of mostly connecting to "fresh" peers doesn't seem very solid.
07:42:22	gmaxwell:	theymos: it does. it maintains two tables, one of peers that have proven functional in the past; and one for the rest. If a peer is evicted from the first list it goes into the second. Obviously it could do more health testing of the first, but the gain from doing so may not be big since peers are not authenticated.
07:43:06	gmaxwell:	theymos: its initial connections are to old peers, not fresh ones. (also in current versions it won't DNS seed probe at all if it successfully gets connected fast enough)
07:45:54	theymos:	I know a little about the current mechanism, but it seems too simple. I don't have any testing supporting this, but I worry that it's too easy for you to fill up your tested-good table with relatively bad peers and evict excellent peers. I was thinking that it should maintain a score for peers, so peers would be considered a lot more trustworthy/valuable if they were the first peer to relay a ne
07:45:54	theymos:	w block to you, for example. I guess authentication would be necessary for this to be useful long-term.
07:46:41	gmaxwell:	theymos: tested good table can't be replaced, they can just age out by not working.
07:47:02	gmaxwell:	(thats something that was changed somewhat recently)
07:47:09	theymos:	oh, cool!
07:47:23	gmaxwell:	(in response to an academic paper that presented some attacks against the scheme.. some we knew about, some that were new)
07:48:54	gmaxwell:	right now the biggest problems with it, I think, are that its awfully slow to try more peers, and also learns nothing about the network once it's already connected up (e.g. no connection probing/rotation)
07:54:04	theymos:	Yeah, probing/rotation would probably be good. Only one of your peers needs to be honest, so there's a lot of room for connecting to possibly-untrustworthy peers. I feel like there's a ton of network data that Core could be collecting (but isn't) to ensure that it has at least one good peer.
07:55:07	gmaxwell:	theymos: the trick there is that you want the opposite behavior for wallet privacy.
07:55:22	gmaxwell:	because you want to not connect to _any_ spy nodes.
07:56:18	gmaxwell:	so then there are perhaps hybrid approaches where you have 4 long time consistent sockets which you never rotate and you do all your txn announcenet via those, and 4 that you rotate, and only take in txn via those...
07:56:56	gmaxwell:	theymos: though if someone builds an out-of-band relayer using the new functionality for that in 0.11 perhaps thats less of an issue.
07:57:13	gmaxwell:	but the fact that right now people are incentivized to setup socket sucking spy nodes is irritating.
07:57:35	gmaxwell:	and there are several commercial players effectively attacking the network at varrious levels in order to gather information on users.
07:57:55	gmaxwell:	(even if I were indifferent to user privacy, reducing the incentive to goof with the network would be good)
07:58:24	theymos:	It's pretty hard to protect against spying because you can never tell when a peer is spying. You pretty much have to use Tor, I guess.
07:58:37	theymos:	What do you think about including a high-latency mix network in Bitcoin? No commonly-used ones exist AFAIK.
07:59:27	gmaxwell:	The non-existance problem is what I think is the main barrier. Wumpus added a feature so you can disable p2p broadcast of wallet txn with a switch. Then a seperate (not yet existing, could be external) process can go broadcast for you.
07:59:41	gmaxwell:	e.g. over tor into a high latency mix network.
07:59:58	gmaxwell:	I'd like to ship such a think in bitcoin core if it existed and was reasonable.
08:01:04	gmaxwell:	high latency is relatively, some of the tor devs have been coauthors on papers about mixes where you can signal your desired latency... and even low latency traffic improves privacy for high latency traffic through the same relay.
08:01:09	c0rw|zZz:	c0rw|zZz is now known as c0rw1n
08:02:23	gmaxwell:	if the process is single hop you can largely prevent dos attacks by checking that the tx is valid, but if its multihop I dunno how to prevent dos.
08:02:33	gmaxwell:	other than hashcash.
08:03:12	theymos:	The no-broadcast thing is a good feature. I was thinking of creating a little script that would accept email containing a tx and then broadcast it on the network. Then you could use the old mixmaster-type networks (are these networks still maintained anymore, though?).
08:03:58	gmaxwell:	theymos: Yes, exactly. I hoped that it would be a reasonable starter project for someone since they could fuss around with whatever programming tools they want.
08:04:20	c0rw1n:	c0rw1n is now known as c0rw|away
08:04:46	gmaxwell:	theymos: I don't know, they were kind of a couple years ago, the email exit points are always weak because they get harassment complaints. Thats one reason why a bitcoin centric service would be easier to maintain.
08:05:18	holmes.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:18	holmes.freenode.net:	Users on #bitcoin-wizards: andy-logbot go1111111 dEBRUYNE rusty gill3s _biO_ b_lumenkraft AaronvanW CoinMuncher damethos jrayhawk hktud0 Mably grandmaster darwin_ priidu Crowley2k OneFixt mjerr rht__ goregrind shesek TheSeven jgarzik p15 kgk metamarc www nessence_ Dr-G2 Adlai GAit prodatalab moa mengine pollux-bts tromp_ alferz jmcn sparetire_ dc17523be3 dgenr8 Tebbo spinza hashtag_ robogoat Emcy c0rw|away tucenaber d1ggy Tiraspol adam3us sneak gielbier BitName sadoshi
08:05:18	holmes.freenode.net:	Users on #bitcoin-wizards: andytoshi ebfull badmofo hulkhogan_ MoALTz maaku jcorgan _whitelogger sparetire Starduster bosma sundance heath bsm117532 helo CodeShark copumpkin devrandom rustyn K1773R melvster ttttemp Relos cryptowest_ PRab @gmaxwell gwillen waxwing lclc koshii STRML kyuupichan catlasshrugged akstunt600 kanzure midnightmagic @Luke-Jr Iriez LeMiner fenn MrTratta bliljerk101 gnusha bedeho wizkid057 akrmn mariorz mikolalysenko Meeh Krellan ajweiss Cory so
08:05:18	holmes.freenode.net:	Users on #bitcoin-wizards: cornusammonis s1w elastoma poggy PaulCapestany lnovy HM jouke dansmith_btc tromp catcow btcdrak Xzibit17 prosodyContext vonzipper adams__ michagogo dasource yrashk CryptoGoon mappum artifexd Muis runeks kumavis platinuum jbenet phantomcircuit Madars yorick mm_1 amiller fluffypony livegnik mountaingoat a5m0 Apocalyptic triazo wiz wumpus EasyAt Alanius iddo forrestv theymos Taek AlexStraunoff luny null_radix smooth lmatteis narwh4l thrasher`
08:05:18	holmes.freenode.net:	Users on #bitcoin-wizards: otoburb Keefe weex pigeons sturles nephyrin [d__d] rasengan berndj harrow qawap superobserver stonecoldpat davout jessepollak huseby espes GreenIsMyPepper veox yoleaux comboy stevenroose kinlo gavinandresen nickler cdecker ggreer isis harrigan scoria brand0 larraboj nsh jonasschnelli leakypat epscy cfields coryfields azariah warptangent TD-Linux crescend1 Zouppen binaryatrocity BananaLotus optimator Eliel mr_burdell throughnothing_
08:05:18	holmes.freenode.net:	Users on #bitcoin-wizards: Fistful_of_Coins Jaamg xabbix dignork petertodd richardus afdudley SwedFTP guruvan nanotube warren sdaftuar eric roasbeef BrainOverfl0w @ChanServ AdrianG Anduck BlueMatt starsoccer d9b4bef9 gribble ryan-c indolering Graet jaromil [ace] merlincorey morcos
08:11:04	amiller:	(in response to an academic paper that presented some attacks against the scheme.. some we knew about, some that were new)
08:11:21	amiller:	which ones? are there new papers out on this out I don't know about yet?
08:11:35	gmaxwell:	Bitcoin eclipse attacks paper, lemme get you the cite.
08:12:00	gmaxwell:	https://eprint.iacr.org/2015/263.pdf
08:12:04	amiller:	ok got it
10:40:06	rustyn_:	rustyn_ is now known as rustyn
11:34:57	midnightmagic:	adam3us: fwiw, your writing is easy to read and calm. Thank you; the clarity of your posts is much appreciated.
12:41:31	adam3us:	midnightmagic: thanks. i try. here's hoping gavinandresen & Mike Hearn can be yet persuaded to abandon the unilateral fork and bypass of the code review and maintainership of bitcoin.
12:41:50	adam3us:	midnightmagic: its kind of ambiguous whats going to happen.
12:42:42	gavinandresen:	adam3us: stop with the FUD, please
12:42:51	adam3us:	but thanks to jgarzik for helping steer the conversation to a BIP review oriented approach. hopefully we'll have a few more BIPs and can review it in the context of a decentralisation plan also.
12:42:58	gavinandresen:	code has to be written before it can be reviewed
12:43:07	adam3us:	gavinandresen: pardon me? your clarification on the dev-list is welcome
12:43:24	kanzure:	gavinandresen: forcing a hard-fork is also FUD :-)
12:43:25	gavinandresen:	I'm busy writing code.... then I'll be busy writing a BIP....
12:43:42	kanzure:	gavinandresen: you sent a nuclear email just last week; surely you remember this. "fuck you guys, i'm forking the network whether you like it or not"
12:43:50	kanzure:	(you used much better language though!)
12:44:12	gavinandresen:	kanzure: how do you think the tech should be governed? Council of Elders?
12:44:13	kanzure:	((i would never imply that you have used poor language; i was paraphrasing in an uncharitable way))
12:44:15	adam3us:	gavinandresen: thats is good. but the question clearly that concerns people would be that you submit that BIP for review beside Jeff's and other proposals, and publicly not support the unilateral hard fork threat that Mike is pushing
12:44:34	gavinandresen:	you have an odd definition of 'unilateral'
12:44:59	gavinandresen:	... if supermajority of exchanges, merchants and miners is 'unilateral' then I'm not sure what to say
12:45:00	kanzure:	the question of governance here is completely irrelevant
12:45:07	adam3us:	gavinandresen: do you see anyone other than mike in here agreeing with you?
12:45:30	gavinandresen:	governance is completely relevant: is Bitcoin goverened by the code people choose to run, or is it / should it be governed in some other way?
12:45:39	kanzure:	false dichotomy
12:46:18	gavinandresen:	I'll say again: I'm happy to get behind some other proposal that reaches rough consensus. I like Jeff's proposal...
12:46:34	kanzure:	does that mean you are no longer threatening the hard-fork?
12:46:47	gavinandresen:	But I won't just sit on my hands and do nothing about scaling up because how and when is controversial
12:47:05	adam3us:	gavinandresen: as you know bitcoin is very technical and so if the entire technical community is telling you a unilateral fork is dangerous, that should be concerning no?
12:47:42	gavinandresen:	again, you have a very odd definition of unilateral. I'm 82% sure I've described the rollout plan to you before, and it is NOT unilateral
12:48:38	adam3us:	gavinandresen: not to discount the desire of the merchants exchanges at CEO level etc but i doubt they know the details at the level to judge safety, and seem completely unaware of the review and code change governance process which is in place for security & integrity of the system.
12:49:30	kanzure:	yeah, if those people actually have judged safety in a strict and rigorous way then i think that would be FANTASTIC news that we should be spreading all over the place; "bitcoin ceos most technically oriented ever"-- that would be like the greatest news ever.
12:50:01	kanzure:	"it turns out that all of the bitcoin company owners are actually coq wizards"
12:50:19	gavinandresen:	ok... so what is unsafe about bigger blocks?
12:50:25	adam3us:	gavinandresen: i thought i covered all of these topics mostly in my post to bitcoin-dev. but do you acknowledge the consensus review process for security review?
12:50:36	kanzure:	gavinandresen: wrong question... what is unsafe about hard-forks?
12:51:05	gavinandresen:	adam3us: not if Peter Todd is involved. He loves to think up miners-dancing-on-the-head-of-a-pin attacks that will never ever happen in practice.
12:51:10	adam3us:	gavinandresen: there are multiple questions but that is not the issue. that kind of issue could be, and is being hashed out in the technical discussion eg with jgarik's BIP
12:51:49	adam3us:	gavinandresen: i think this is not just petertodd.. it seems to be every core dev and everyone else who has made significant number of patches.
12:51:50	gavinandresen:	really? I haven't seen any discussion of jgarzik's BIP, where has that been taking place?
12:51:56	gavinandresen:	(well, I saw the reddit discussion....)
12:52:14	kanzure:	there was a bunch of discussion in #bitcoin-dev but i believe there were also emails?
12:52:29	gavinandresen:	If the safety argument is "hard forks are risky, therefore we can never do one" then... uhh... I dunno what to say.
12:52:31	adam3us:	gavinandresen: a number of people have been talking with him myself included (probably 6 or 7 technical people i think)
12:52:41	adam3us:	gavinandresen: that is a mischaracterisation
12:52:47	gavinandresen:	adam3us: great, so some secret Technical Council....
12:52:58	kanzure:	if you misharacterize basic conversation like this, why would you not make the same mistakes with bitcoin consensus code -_-
12:53:09	adam3us:	gavinandresen: he's been updating his BIP with the changes he's considered
12:53:31	adam3us:	gavinandresen: its public. i think some of this discussion would be better on list.
12:53:32	gavinandresen:	yes, and I've been wondering where the discussion for that is coming from.
12:53:38	adam3us:	gavinandresen: so i agree with you there.
12:54:05	adam3us:	gavinandresen: discussion for what?
12:54:17	kanzure:	bip100
12:54:36	gavinandresen:	discussion for the changes to jgarzik's BIP. e.g. he suddenly went from 2MB to start to 1MB to start, I hadn't seen any discussion about that, have no idea what the reasoning was...
12:55:06	gavinandresen:	... or the "I'll put in a 32MB cap so we have to go through this whole hard fork controversy again in a few years"
12:55:56	adam3us:	gavinandresen: so i think if you would post a BIP and retract the unilateral hard fork ultimatum that mike hearn is promoting daily, you would see more productive discussion on list. many people dont like controversy so this is creating the environment which fosters this kind of working is my guess.
12:55:58	gavinandresen:	I have a bunch of technical nits with that BIP, but I have little idea what gmaxwell/sipa think of it
12:57:11	gavinandresen:	Well, I'm not going to write a BIP until I've finished writing the code/unit tests/regression tests. And it seems to me that there is no danger to deploy that code for early testing to merchants and exchanges
12:57:33	gavinandresen:	It will do NOTHING until past a switchover date and a miner vote...
12:57:34	adam3us:	i have heard a whole lot of people - as far as i can tell its everyone who has a bunch of code checkins, saying that a hard-fork without consensus is unnecessarily dangers. we need to foster collaboration and consensus to reduce the risks.
12:57:37	kanzure:	if merchants, exchanges and miners just accept unreviewed code then i fear this network is going to implode
12:58:03	gavinandresen:	So if we DO need to do "an emergency hardfork" it will be much easier, because only the miners would need to update their systems.
12:58:10	jgarzik:	gavinandresen, private comments. reducing risk by starting out at 1MB, and then letting market take it from there
12:58:39	jgarzik:	gavinandresen, people dislike "unlimited" so 32MB seemed a compromise, where 2 hard forks are required to get beyond 32MB - thus two major user endorsements
12:59:04	gavinandresen:	jgarzik: cool. I actually have no problem with taking feedback privately, but I was reacting to the "but you've been TALKING to people in private!" comments from earlier....
12:59:09	jgarzik:	since we needed 32MB anyway
12:59:13	adam3us:	gavinandresen: it takes a while to get to 32MB if there are growth rate caps. so its not like today
12:59:19	kanzure:	feeding them private patches can easily change, in the future, to "feeding them patches that forks the network on their end into an altcoin". they can run whatever they want, but at the same time they might not be aware of the economic ramifications of hard-forking.
12:59:40	kanzure:	private unreviewed patches, even
12:59:51	kanzure:	and how do they know that you didn't feed the other parties a different patchset anyway?
12:59:59	kanzure:	this is just... wtf.
13:00:27	gavinandresen:	kanzure: THE CODE IS NOT YET WRITTEN. IT WILL BE PUBLIC AND REVIEWED AND THEN ROLLED OUT IN AN XT RELEASE.
13:00:43	gavinandresen:	geez
13:00:47	kanzure:	okay using caps is nice, but you said: "And it seems to me that there is no danger to deploy that code for early testing to merchants and exchanges"
13:00:58	gavinandresen:	yes, after testing and review.
13:01:15	kanzure:	and if there are nacks everywhere?
13:01:29	kanzure:	well anyway; yes that will fix the different-patchsets concern.
13:01:34	gavinandresen:	This conversation would go better if we all could assume that we all have best intentions and are competent. I try really hard to do that....
13:01:48	kanzure:	it is hard to make that assumption when we receive nuclear threats
13:02:01	adam3us:	gavinandresen: you might have noticed that i do to. at least i try to explain that.
13:02:26	gavinandresen:	oh please, forking the open source project for a limited period of time is not a 'nuclear threat'
13:02:46	kanzure:	uh, that's not what you threatened
13:02:51	adam3us:	gavinandresen: you nor mike have been particularly clear about how its going to be limited in time
13:02:54	gavinandresen:	that is how open source works. If you're unhappy with the direction the project is going, fork the code....
13:03:01	kanzure:	you're misconstruing the history here
13:03:20	kanzure:	we are talking about blockchain history forks, not repository forking
13:03:20	nsh:	forking a project is a notably different proposition to forking a distributed consensus system :)
13:03:35	adam3us:	gavinandresen: its not how a consensus system works though. fork the code fine, whatever. lobby non-technical people in private to run it without a balanced presentation of risks, that is not an open or safe way to behave.
13:03:37	gavinandresen:	adam3us: I thought we were pretty clear: either the network will upgrade to bigger blocks, in which case Core will be forced to follow and re-integrate.
13:03:59	gavinandresen:	Or it won't, in which case XT will drop the bigger block patches and go with whatever Core does.
13:04:09	kanzure:	no, you were not clear at all; you said "i have convinced all these companies to run it anyway, already, and also even if i see nacks it will go forward" (actually you didn't say this; mike did)
13:04:10	adam3us:	gavinandresen: you know that gmaxwell, sipa, heck everyone has said that a non-consensus hard fork is the worst possible risk.
13:04:36	adam3us:	kanzure: precisely.
13:04:46	nsh:	well, if we can a priori exclude all the possibilities where something goes wrong, then i agree there's nothing to worry about
13:04:46	kanzure:	((i apologize for misconstruing gavin vs mike comments))
13:04:50	nsh:	i'm glad we got this cleared up :)
13:05:09	gavinandresen:	A 50/50 split with half merchants/miners on one side and half on the other WOULD be terrible. That is not going to happen, CANNOT happen, with the patch I'm working on
13:05:36	nsh:	then the patch will be a proof of a hypothesis about byzantine consensus and i'll help proof read the paper the results
13:05:38	adam3us:	gavinandresen: i dont see how you can assure that it wont happen. that assumes the rest of the world takes your threat and runs with it.
13:06:21	nsh:	sorry, byzantine-consensus, macroeconomic and game-theory. prodigious :)
13:06:25	nsh:	*economics
13:06:30	adam3us:	gavinandresen: ie in the interests of pragmatism etc that you are going to force the issue and impose your BIP parameters over the majority views of everyone else, you are willing to play chicken with $3b of other peoples money?
13:06:33	gavinandresen:	adam3us: RE: lobbying in private: I have been extremely public this entire year about the need for bigger blocks. I've given at least three public talks, given interviews, posted to the -dev mailing list, written blog entries....
13:07:01	adam3us:	gavinandresen: yes and before that you had i gather many more months of private discussions where everyone technical NACKed the proposal.
13:07:06	gavinandresen:	adam3us: ... and my "lobbying" consisted of asking people whenever I met them: "what do you think needs to be done RE: scaling up?"
13:07:40	kanzure:	yes and if you ask a bunch of economists they will say get rid of the scarcity; who cares?
13:07:49	adam3us:	gavinandresen: look i think that is a poor question to shape here. everyone who is sane wants to scale bitcoin. the question is a technical one of how within safety, security etc
13:08:02	kanzure:	indeed
13:08:03	gavinandresen:	adam3us: the NACKs were "lets wait" and/or "more testing/analysis" . Well, it's been 6 months of waiting and testing and analysis....
13:08:40	adam3us:	gavinandresen: well u and mike did one good thing which was to remind everyone we are only within 3x-4x excess capacity.
13:09:01	gavinandresen:	adam3us: see, for example, sipa's analysis of block size / fees posted to bitcoin-dev mailing list. I am perturbed that he didn't respond to my questions about that analysis....
13:09:03	adam3us:	gavinandresen: but you could say you did that job, and there are public attempts to do this by consensus, which i think you have to admit, is less risky
13:09:57	gavinandresen:	consensus is great, I'll say again: I'm happy to follow consensus on another proposal, if another reasonable proposal can get consensus. Heck, I'll even write the code....
13:09:57	adam3us:	gavinandresen: pieter is very distressed by the escalation of model of working, so as i said above, i expect his non-public interaction is more to do with not liking to interact in a perceived hostile space.
13:10:06	kanzure:	in case it's not clear, we are concerned that you haven't taken back the nuke threat
13:10:35	adam3us:	gavinandresen: so at this point i dont see why you dont just climb down from the threat gracefully and persuade mike to abandon the bitcoin-XT fork.
13:10:55	adam3us:	gavinandresen: if your proposal is better than jeff's or others based on merit i think people would be very happy to ACK it.
13:11:45	gavinandresen:	well, I need to finish writing the code before I even HAVE a proposal. Pragmatic concerns like "how easy or hard will this be to backport" will influence the proposal
13:12:01	kanzure:	do you know which nuke threat we are talking about?
13:12:22	adam3us:	gavinandresen: i think the two things that are alarming people more than you seemed to account for, and i did warn about this privately, is overriding the code change governance model which is there for good reason; and secondly to push out a hard-fork without consensus
13:12:31	gavinandresen:	Releasing a version of XT that supports bigger blocks? Then asking merchants/exchanges to run it and announce "We're Big Block Ready!"
13:12:43	kanzure:	no, that's not what your email said specifically
13:13:11	kanzure:	* kanzure looks
13:13:22	adam3us:	gavinandresen: ^^ those are the questions which you are under-estimating the gravity of.
13:13:26	gavinandresen:	There is no "code change governance model" for Bitcoin-the-project. There is for Bitcoin Core, but I think it has been breaking down.
13:13:44	adam3us:	gavinandresen: i dont think anyone else thinks so. other than mike of course.
13:14:06	adam3us:	gavinandresen: you're well aware of the scalability work that has been done this past year for example.
13:14:07	ThomasV:	* ThomasV grabs popcorn
13:14:16	kanzure:	adam3us: where's this email :-(
13:14:22	gavinandresen:	Yes, the scalability work is great!
13:14:51	gavinandresen:	I would LOVE LOVE LOVE to be helping rusty with IBLT work instead of endlessly arguing in blogs, on IRC, etc.....
13:14:53	adam3us:	gavinandresen: and without that work changing a constant to 20MB might be problematic even on a host basis
13:15:08	adam3us:	gavinandresen: well there's a simple answer to that…
13:15:26	adam3us:	gavinandresen: go do it and stop?
13:15:34	gavinandresen:	Ok, well, THERE's a fundamental difference where I think reasonable people can disagree. I think we need to create headroom for that scalability work, so we can grow into it.
13:15:37	kanzure:	"encourage miners to roll out a soft-fork to start producing bigger blocks"
13:15:38	gavinandresen:	I don't think that is dangerous
13:15:46	gavinandresen:	... because miners aren't idiots.
13:15:48	kanzure:	hmm that wasn't the threat.. let's see...
13:15:51	adam3us:	gavinandresen: no i agree with that as does everyone else
13:15:56	gavinandresen:	If their blocks propgate slowly, they'll create smaller blocks.
13:16:14	gavinandresen:	Yay! agreement!
13:16:22	adam3us:	gavinandresen: i prefer jeff's proposal over yours, and if you want to later move the conversation back on list i'll be happy to comment on both publicl
13:16:42	gavinandresen:	adam3us: cool
13:17:05	kanzure:	http://sourceforge.net/p/bitcoin/mailman/message/34155307/
13:17:12	gavinandresen:	If Jeff's proposal gets consensus quickly, that'd be spiffy, I'll implement THAT instead of what I'm working on.
13:17:14	kanzure:	it was in this email that you threatened to hand everything over to the miners? hmm
13:17:23	kanzure:	still looking. i think there was one more.
13:17:37	adam3us:	gavinandresen: "There is no "code change governance model" for Bitcoin-the-project.  There is for Bitcoin Core, but I think it has been breaking down." i think that is a non-constrictive statement. yuo just admitted ^^ that you thought the work done under this model over the last year was great work.
13:17:44	gavinandresen:	kanzure: I don't think I ever said that. If I did, then I was high on crack.
13:17:58	kanzure:	i doubt it; most people write great code when on crack.
13:18:01	nsh:	* nsh smiles
13:18:37	JackH:	poor gavin lately :/ so much fighting
13:18:40	adam3us:	gavinandresen: and when you've implemented jgarzik proposal or your proposal or someone elses will you get mike to push it via Bitcoin-XT
13:18:50	kanzure:	((actually now i'm curious to hear how you think crack influences you; but that's off-topic i guess.))
13:19:00	adam3us:	JackH: no this is good, talking is better than not talking *always*
13:19:06	gavinandresen:	adam3us: Bitcoin Core process works OK for incremental changes. For anything controversial... not so much. See the P2SH controversy for the first good example.
13:19:29	nsh:	that analysis may not take account of all of the terrible changes that haven't been made, and their value
13:19:29	JackH:	I know, I have been following this alot myself. nice to see gavin in here, but still a rotten page in the book of Bitcoin with all this
13:19:31	adam3us:	gavinandresen: i dont know if you have this view, but the consensus afterwards was that the one you pushed for was worse than the one you overrode
13:19:53	adam3us:	gavinandresen: on p2sh. people just didnt care enough to fight. size limits on it.
13:20:02	gavinandresen:	adam3us: "get mike to push it..." Well, I'm being really mean to Mike-- I'm making him be Benevolent Dictator of the XT project
13:20:26	adam3us:	gavinandresen: well collaborate with mike, rather.
13:20:49	JackH:	what surprises me the most about this debate: gavin, is how you have fought so hard to keep in implementing XT
13:20:58	gavinandresen:	Sure, I think Mike and I will continue to encourage merchants/exchanges (and eventually miners) to upgrade to a codebase that supports bigger blocks.
13:21:00	JackH:	you made it into a goal
13:21:01	adam3us:	gavinandresen: the question is serious and the crux of it however: going ahead with unilateral actions.
13:21:11	gavinandresen:	If Core supports bigger blocks, then cool!
13:21:34	kanzure:	(isn't there something broken about using block version number "voting" from miners for a hard-fork about max block size. isn't that one of the things in the list of things that should never be done?)
13:21:44	Eliel:	There will be a chain with support for higher transaction throughput and lot of people will migrate to it. What I don't know is if it'll end up being named Bitcoin. It doesn't look like everyone here understands this.
13:21:45	adam3us:	gavinandresen: so as that looks to be happening anyway within the consensus process .. thanks in part to you and mike reminding people .. why is there a need even for bitcoin-XT as a vehicle now?
13:22:09	gavinandresen:	So... I've called Bitcoin Core the "reference implementation" .... implying that there will be other implementations. And there are, but none of them have really taken off yet.
13:22:18	Eliel:	it doesn't matter even if everyone here agrees 1MB blocks are the way to go. It will still happen.
13:22:27	kanzure:	Eliel: that's not helpful
13:22:39	kanzure:	Eliel: although your previous comment was more helpful
13:22:47	adam3us:	gavinandresen: you could save a lot of devs a lot of stress, and reduce risk etc etc by just retracting (even just temporarily!) the unilateral assertions that you and mike have been making about forking the codebase tied to a network fork overuling the rest of the core deve teams advice
13:23:04	gavinandresen:	If Bitcoin is successful, there will be a LOT of implementations. I think I agree with Mike that the governance model for Bitcoin Core (NOT the bitcoin project) cannot work in the long run
13:23:18	adam3us:	gavinandresen: yes but this is why libconsensus is being worked on, it can be dangerous to diverge via subtle bugs
13:23:52	kanzure:	gavinandresen: so more specifically it sounds like you do not want to participate in the bitcoin-core development team long-term?
13:24:08	adam3us:	gavinandresen: lets give you a hypothetical, say bitcoin is not $3b but $30 trillion. do you really think its appropriate that one person who disagrees with the rest of the technical experts can get away with bypassing all other opinions?
13:24:08	kanzure:	long-term, mind you
13:24:23	kanzure:	adam3us: he has already said yes- that's mike's position, yo
13:24:32	adam3us:	kanzure: but thats not rational
13:24:37	kanzure:	neither is mike
13:25:06	JackH:	so you just want to work on another reference implementation?
13:25:09	gavinandresen:	adam3us: sure, if that one person can convince a supermajority of people that their vision is correct.
13:25:09	adam3us:	kanzure: nah mike is rational, just pragmatic, and has different assumptions about scaling that ends with fiber channel links in datacenters.
13:25:15	JackH:	but, cant you do that without forking the network?
13:25:15	kanzure:	adam3us: fair enough
13:25:38	kanzure:	JackH: agreed; working on a different implementation can still occur without forking the network, or convincing miners to start pumping out hard-fork block version numbers
13:25:41	adam3us:	gavinandresen: should the super-majority include the technical people who understand the technical risks?
13:25:44	gavinandresen:	adam3us: history is full of times when one expert was right but conventional wisdom of the time was wrong...
13:25:55	gavinandresen:	If I was an asshole I'd claim I was the Galileo of Bitcoin :-)
13:26:03	adam3us:	gavinandresen: this thing feels like reactor design by lynchmob on the receiving end
13:26:05	hearn:	my ears were tingling ...
13:26:20	kanzure:	gavinandresen: nobody has ever claimed that the bitcoin currency will disappear with 20 MB blocks. they have claimed lots of risk related to a controversial hard-fork. these are separate topics dude.
13:26:33	adam3us:	kanzure: exactly.
13:26:43	nsh:	(history is devoid of times precedent here)
13:26:49	gavinandresen:	adam3us: there's another place reasonable people can disagree-- what are the risks versus benefits of proposed changes ?
13:26:51	nsh:	(to suggest otherwise is inexcusable folly)
13:26:57	nsh:	-times
13:26:59	adam3us:	hearn: afternoon. some air clearing, which hopefully gets somewhere productive.
13:27:07	hearn:	adam3us: with due respect, i think there's something important here. you and a few others have some deep expertise in a very narrow area of the bitcoin project (theoretical cryptography). as you have yourself said, many other areas are not really your cup of tea. for example, UX.
13:27:24	hearn:	now what i'm seeing in these discussions is a dismissal of everyone elses expertise. bitcoin needs everyone, with all their backgrounds
13:27:32	nsh:	($10 billion is not secured on cutting-edge UX)
13:27:33	hearn:	gavin and myself have both been around longer and written far more code
13:27:41	kanzure:	hearn: argument from authority; boring predictable try again please.
13:27:45	JackH:	but hearn, if we dont agree with that?
13:27:46	kanzure:	hearn: you can surely do better tha nthat
13:27:48	hearn:	so it would be nice if we could all start by recognising each others experience
13:27:50	adam3us:	gavinandresen: why would it be worth even the controversy to impose a view for your preferreed parameters vs jeff's for example thats where we are right now.
13:27:52	hearn:	kanzure: shush
13:27:58	JackH:	I mean, you need all the business to go along with your ideas
13:28:04	kanzure:	hearn: no; we should start yb abjectly rejecting all prior experience. we should not be speaking from authority.
13:28:05	JackH:	our business for sure wont switch to XT
13:28:09	JackH:	not under these circumstances
13:28:09	adam3us:	hearn: ack.
13:28:36	kanzure:	gavinandresen: there are some limits to where reasonable people can disagree.
13:28:38	hearn:	adam3us: do you recognise and understand the concerns myself and most other wallet developers have about what happens when blocks get full? we can start here, i think
13:28:49	hearn:	adam3us: that is, we think our wallets will break and our users will get very upset. understandably so.
13:29:13	hearn:	(well, we are already starting to see complaints, but that will get a lot worse)
13:29:19	kanzure:	block size topic is different from the nuclear threat prevention we were attempting above
13:29:23	Eliel:	... I'm appalled that people are using words like "impose" in this context... no single person is able to do that in this context. You'd have to misunderstand the most basic nature of Bitcoin to claim anything like that.
13:29:27	kanzure:	it is wrong to misconstrue these topics as the same one
13:29:46	nsh:	so best would be to try and formally model how your perception of that risk increases in line with the projections of transaction volume tend to the current capacity ceiling
13:29:52	adam3us:	gavinandresen: i think things have shifted - there are now multiple proposals in review in bitcoin-dev. why would you not once written submit a BIP there and see which one wins the design review and safety parameters etc and then help implement whichever that is?
13:30:07	nsh:	and to see where the point of transition is relative to the risk of problems associated with non-consensus hard-fork
13:30:32	nsh:	because it may vary between interest, and that might help us discuss facts, and not perceptions
13:30:36	hearn:	adam3us: a BIP is a document that describes what is being done - as the patch and its parameters are not yet finalised, it would make sense to write a BIP after the patch is written, or alongside it. which is what gavin is doing, i believe
13:30:45	kanzure:	i think that gavinandresen should consider that he can work on an alternative reference implementation without forking the network; if that's really what he wants, then he should be happy to learn that network blockchain forking is unnecessary for that to happen.
13:30:48	adam3us:	hearn: of course. i never said i didnt want to see a throughput increase that feeds into decentralisatoin work and later algorithmic work. i spelled it out at the bottom of my post you responded to
13:30:51	hearn:	beforethen other documents have been written and debated. they don't have numbers, but that doesn't seem like a big deal.
13:31:06	hearn:	adam3us: alright. then you understand why we are so concerned. that is good.
13:31:09	kanzure:	hearn: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08183.html
13:31:09	adam3us:	gavinandresen: i think things have shifted - there are now multiple proposals in review in bitcoin-dev.  why would you not once written submit a BIP there and see which one wins the design review and safety parameters etc and then help implement whichever that is?
13:31:29	hearn:	adam3us: so do you understand why we feel the block size needs to be increased, with the process starting now?
13:31:36	kanzure:	this is unrelated
13:31:43	nsh:	everyone understands why. the divergence is on the urgency
13:31:44	gavinandresen:	yes, that's what I'm doing. As I implement, tiny little details become clear-- for example, the code is much simpler if all of the information needed to decide how large a block can be is in the block header... (so dependent only on timestamp and version)
13:31:47	hearn:	adam3us: and why we feel frustration with the apparent inability to start that process?
13:32:15	adam3us:	hearn: the process seems to be moving along now.. (with some thanks to you and gavinandresen)
13:32:20	nsh:	is it not started? what would be the formal start, hearn?
13:32:30	adam3us:	hearn: i refer to the list of proposals kanzure just posted for evidence
13:32:53	gavinandresen:	adam3us: my impression is that until sidechains launched the process wasn't going to go anywhere, because greg and pieter were busy.....
13:32:55	hearn:	and yet this morning when i read my mail, i see a message from one of your coworkers (mark) saying that there's no consensus around any proposal
13:33:19	kanzure:	gavinandresen: completely wrong; gmaxwell was posting and discussing the most comments perhaps he ever has, during the weeks leading up to the sidechain release
13:33:26	hearn:	so who am i to believe? ultimately the decider is wladimir. but he has said for as long as a change is controversial, it won't be accepted.
13:33:32	hearn:	hence -> deadlock
13:33:41	kanzure:	gavinandresen: if you go look at his timestamps on his reddit comments emails etc. it's truly impressive that he was able to type on two keyboards at once one for bitcoin discussion and the other for sidechain development
13:33:41	adam3us:	gavinandresen: well i think fwiw sipa spent > 75% of his work time and free time on bitcon-core work with the exception perhaps of a week or two on crunch to push sidechains out.
13:34:11	kanzure:	((i am only an amateur at two-keyboard typing))
13:34:22	kanzure:	((( http://www.seanwrona.com/typeracer/profile.php?username=kanzure )))
13:34:25	gavinandresen:	kanzure: sure, but my last several emails to gmaxwell were just ignored, so I had no idea what he was thinking or what was going on. Hence, frustration on my part....
13:34:27	adam3us:	hearn: not everyone agrees on the ordering of things, maaku has a different view. we have independence in bitcoind matters
13:34:39	kanzure:	gavinandresen: fair enough
13:35:01	kanzure:	hearn: everyone is always going to point out when you misconstrue hard-fork threats for max block size scalability issues
13:35:05	JackH:	hearn: why dont you just accept that people think 20MB is too much?
13:35:23	kanzure:	JackH: i believe he has said other numbers he's okay with
13:35:25	hearn:	the exact number is certainly open to negotiation
13:35:26	kanzure:	JackH: so that's not fair
13:35:30	hearn:	i see today the chinese miners have reached consensus on 8mb
13:35:34	hearn:	8 is a lucky number, right?
13:35:40	adam3us:	gavinandresen: so now that the process has started (again thanks to you and hearn for pushing it forward) how about we work cordially and abandon the threat of unilateral hard-fork. work on reviewing and implementing various BIPs and decide a winner and plan and go deploy it?
13:35:41	hearn:	i am waiting to see what gavinandresen's patch does.
13:35:41	kanzure:	JackH: all i ask is that everyone has perfect recall and perfect memory of all statements that everyone has ever made; is that too much to ask? :-)
13:35:44	helo:	the sign of a stable government is slow (or no) change
13:35:45	gavinandresen:	8 IS a lucky number. Not as good as eleven....
13:35:54	nsh:	so there is discussion, there is interest, there is plenty of good-faith, there is code being made ready to present, and then BIP being written. seems to me things are moving along
13:35:57	hearn:	gavinandresen: haha :)
13:36:02	hearn:	* hearn doesn't have any favourite number, he feels left out ...
13:36:09	hearn:	maybe 99
13:36:10	helo:	NULL?
13:36:16	hearn:	i got 99 problems by 1 ain't 1
13:36:30	hearn:	oops. that joke was a bit mangled by bad typing
13:36:31	nsh:	aleph-gamel
13:36:32	JackH:	kazure: I know of the 8BM yes, but I am not sure if hearn explicitly said he was ok with that
13:36:41	adam3us:	gavinandresen: coincidentally i had suggested to jeff some different parameters including 8MB as a hard-cap. that will see that lasting for enough years to do quite a lot of other work.
13:36:51	kanzure:	JackH: i was kidding dude; i don't expect you to have perfect memory or to follow all posts simultaneously.
13:36:54	adam3us:	hearn: 1GB ;)
13:37:10	kanzure:	i am concerned by how nobody has disarmed the nuclear threat
13:37:18	adam3us:	hearn: sorry that was maybe not constuctive, perhaps not time for humor.
13:37:21	JackH:	yeah hearn, I actually posted something on bitcointalk, about how neither you or gavin can answer the question to what happens when we reach 20MB
13:37:21	nsh:	has anyone actually analyzed whether or not it's academic (like, if some other bottleneck will manifest before 32MB blocks)
13:37:22	nsh:	?
13:37:32	nsh:	at some size it becomes academic, certainly
13:37:32	JackH:	and if we should increase again
13:37:40	hearn:	nsh: i'm absolutely sure it will
13:37:47	adam3us:	nsh: gavinandresen tested somthings up to 8MB I believe
13:37:52	hearn:	nsh: there will probably be many bottlenecks on the way up. it's the nature of scaling things.
13:37:56	nsh:	* nsh nods
13:38:02	nsh:	might be worth trying to simulate
13:38:03	gavinandresen:	Parameters for the patch I'm working on: 8MB cap, earliest fork time 11 Jan 2016, requires 75% hashpower to support, two-week grace period (no big blocks) once 75% reached, cap doubles every two years.
13:38:08	hearn:	nsh: what's more simply making bitcoin popular enough to hit scaling problems is a whole other kettle of fish
13:38:14	nsh:	* nsh nods
13:38:35	gavinandresen:	... oh, and stops doubling after 20 years.
13:38:49	nsh:	hah
13:38:52	hearn:	nsh: at some point Bloom filtering will stop scaling, for instance. i have kicked around a few ideas for what comes after. but ..... let's cross these hurdles as we come to them. our understanding and resources will be better by then anyway.
13:38:59	nsh:	* nsh nods
13:39:02	gavinandresen:	That should be enough parameters to make EVERYBODY unhappy......
13:39:09	JackH:	you guys seriously actually believe that nodes will be serving many hundreds of gigabytes eh? eventually?
13:39:20	hearn:	JackH: it's kind of tough to imagine, isn't it
13:39:21	gavinandresen:	JackH: Sure, why not?
13:39:23	kanzure:	i think that not threatening people is a good start to making everyone happy
13:39:34	adam3us:	gavinandresen: oh auto-doubling? i think jgarzik had or review comments for example growth limiter at 50% or below/year.
13:39:37	gavinandresen:	JackH: if they can't serve hundreds of gigabytes, then they wont.
13:39:43	hearn:	JackH: but then i remember when the only person i could send bitcoins to was satoshi. the whole story of bitcoin has been unexpected and hard to imagine
13:40:11	adam3us:	gavinandresen: no growth rate limit?
13:40:22	gavinandresen:	adam3us: doubling every two years is 40% growth per year.
13:40:31	hearn:	JackH: anyway, the fact is, no technology grows exponentially for very long. growth slows and plateaus eventually. it's hard or impossible to guess exactly where
13:40:40	adam3us:	gavinandresen: sorry i thought you said per year.
13:41:07	Eliel:	kanzure: I think it'd be a good idea to realize that the very fact that those threats are credible means that gavin is actually just messenger. Not the origin of what you label a "threat".
13:41:07	hearn:	JackH: that's why successful systems tend to build the system they need to manage the next phase of growth, rather than try to design something that can handle infinite growth right up front
13:41:11	JackH:	the way I see it, is that your "patch" is killing my efforts of becoming a full node, thus I cannot verify, thus I cannot be part of the network
13:41:12	adam3us:	gavinandresen: but whats doubling the cap?
13:41:16	kanzure:	Eliel: can you elaborate?
13:41:25	JackH:	thus you are creating central points, like ISP's
13:41:43	JackH:	and then its bye bye to Bitcoin as a perfectly decentral system
13:41:48	gavinandresen:	adam3us: hmm? 8MB in 2016, cap would be 16 MB blocks in 2018, etc
13:41:53	adam3us:	Eliel: its clear everyone wants bitcoin to scale so that everyone can benefit
13:41:55	kanzure:	Eliel: they are credible only because i believe that companies miners and exchanges can be convinced to use patches that are against their interest or the interest of the network.
13:42:07	leakypat:	The nuclear threat should be withdrawn, creates a lot of uncertainty and divisiveness , I'm sure wallet makers are way more concerned about a split than the blocks hitting the hard cap at some point
13:42:31	helo:	50% max blocksize growth mid-subsidy starting from the first block
13:42:39	adam3us:	gavinandresen: ok. jgarziks' is 32MB hard-cap (that does not grow) and a growth limiter (i think 2x every 18mo) by soft-cap
13:42:43	JackH:	Despite the fact that our payment gateway, (yes we are running a payment gateway for Bitcoin in EU), is serving a full node and can scale hugely, this is still not enough for me.
13:43:03	adam3us:	adam3us: however not sure were exactly he is on the growth-limiter. someone could look at bip-100 latest
13:43:19	helo:	that would put it at 2.25MB right now, i think
13:43:23	hearn:	JackH: there are people who can't afford to run a full node today. shall we fix that by evicting the transactions your payment processor is handling so we get smaller blocks? the line has to be drawn somewhere.
13:43:28	nsh:	adam3us, what is the concern regarding unlimited growth?
13:43:30	gavinandresen:	adam3us: yup. As I said, that's OK with me, too, although the code is trickier.
13:43:32	adam3us:	gavinandresen: it does seem sensible to not provide system shocks, as a general principle. so jeff had mentioned that.
13:43:53	hearn:	JackH: anyway, this has been debated to death. look at http://www.gavinandresen.ninja for many articles discussing this topic
13:44:03	adam3us:	gavinandresen: ok so this sounds all agreeable and reasonable and i am sort of puzzled why we let this get so far out of whack.
13:44:10	JackH:	hearn: And even less will be able to run a full node. And if we get too many transactions we wont use Bitcoin itself anyway, but some sidechain or lighting. I wont take the risk of double spend for 10 min if we have 10 million transactions
13:44:18	nsh:	(is it wrong to assume abnormally-large blocks will be disincentivized by propagation time)
13:44:24	helo:	and it would be trivial to implement
13:44:33	gavinandresen:	adam3us: Bad timing maybe? I know everybody at blockstream has been super-stressed to get sidechains out....
13:44:58	JackH:	I have everything to gain in a sense from increased block sizes, from the point of view of the Bitcoin payment business. But I have everything to loose for allowing it to happen, by killing Bitcoin in the process
13:45:09	adam3us:	gavinandresen: so i think the thing that can simply return things to normal and get people focussed back on review simulations and network stats etc. is to clarify that (if you agree) you will participate with the BIP review process and take the winning outcome.
13:45:14	helo:	and it would be more likely to stay well below any system performance growth (bandwidth, etc)
13:45:24	helo:	and encourage off-chain uses for things that don't need to be on-chain
13:45:32	Eliel:	kanzure: There's enough pressure from the community to do something about this by now that if gavin doesn't do it, someone else will. Which is most likely very bad idea unless that someone else ends up being the entire bitcoin core team.
13:45:36	kanzure:	gavinandresen: blaming blockstream for your threats is poor form
13:45:50	nsh:	kanzure, that wasn't how i read it
13:45:55	kanzure:	nsh: go on
13:45:55	adam3us:	gavinandresen: there were a few too many 18hr days there for a few weeks for sure.
13:45:56	helo:	^
13:45:57	leakypat:	kanzure: come on dude
13:46:01	kanzure:	leakypat: i'm listening
13:46:14	gavinandresen:	adam3us: mmmm.... see BIP16 versus BIP17 for what I think is likely to happen with a "BIP review process"
13:46:26	adam3us:	gavinandresen: that was the p2sh one?
13:46:32	gavinandresen:	adam3us: yup
13:46:35	helo:	kanzure: "everyone that would be commenting was busy working on sidechains"
13:46:56	gavinandresen:	adam3us: Eventually I was just the bad guy and said "It's gonna be BIP16"
13:47:07	kanzure:	Eliel: i think that others forking the network is less likely to get wide adoption; companies are used to centralized systems so gavin going to them and saying "here's some patches yo" is something they would likely accept whereas anyone else bringing the patches would perhaps get significantly more suspicion.
13:47:16	adam3us:	gavinandresen: so you do realise that gmaxwell, luke-jr and others preferred luke-jrs bip over yours, and especially in hindsight realised that there is a defect in yours and luke's would have been better.
13:47:35	hearn:	please guys. let's not re-open P2SH
13:47:43	hearn:	it's done. it works. the world continues.
13:47:51	kanzure:	it can be used as a learning experience
13:47:57	hearn:	i agree with gavin that a "use the winner" process is rather the core of the problem here
13:47:57	kanzure:	i'm confused why you two are spouting different histories
13:48:01	hearn:	as there is no process to pick a winner
13:48:07	gavinandresen:	Yes, hindsight is 20/20, learn from mistakes and move on, perfect is enemy of the good, etc etc
13:48:09	kanzure:	was there a disagreement regarding which patch got merged?
13:48:23	kanzure:	e.g. i mean an issue of historical fact
13:48:29	hearn:	e.g. the consensus that is so often discussed is a consenus of ....... who? who gets to be in that group and how did they get there? so i'm not sure how such a process would work
13:48:36	adam3us:	kanzure: its because gavin tried to exercise sort of initiative to short-cut the discussion he's suggesting this is relevant here. which i think could be discussed.
13:48:52	kanzure:	adam3us: yes, i can see why others might not want to discuss that
13:49:06	Eliel:	kanzure: There isn't a shortage of people who can be convincing enough. Especially when almost everyone feels like some kind of a solution is needed.
13:49:10	adam3us:	gavinandresen: but as you brought it up i thought it relevant to actually point out that if you had not done that the other would have won, and they had misgivings and turned out to be correct.
13:49:14	hearn:	for what it's worth, i was not totally sold on P2SH either, but in the end realised i had got it wrong. i wanted a pure payment protocol based approach and hoped that requiring BIP70 to do multisig would incentivise (uh oh) the creation of the necessary infrastructure
13:49:23	hearn:	in practice that didn't happen. gavin was right - people weren't ready to leave bitcoin addresses
13:49:30	kanzure:	Eliel: yes, but the difference is how the solutions are implemented :-)
13:49:43	hearn:	lesson learned: trying to "incentivise" people to build what you want by blocking other solutions isn't a good idea
13:49:54	JackH:	hearn: would you change your mind if satoshi was to say that 20MB is not the right way forward?
13:49:56	kanzure:	helo: i didn't forget your message; i'm just confused what you wanted me to do or say in response to it.
13:49:59	nsh:	likewise consensus code updates, perhaps
13:50:09	hearn:	JackH: lol, he already did
13:50:20	JackH:	hearn: those were different times and you know that
13:50:24	nsh:	clearing your throat to get a discussion started is fine, and indicated
13:50:29	nsh:	growling the whole time to direct that discussion isn't
13:50:32	hearn:	JackH: satoshi said several times that the 1mb limit was only there until SPV clients existed, and after that the limit could be entirely removed.
13:50:33	JackH:	hearn: back then anything was a go
13:50:48	nsh:	and i'm sure no-one is trying to do the latter :)
13:50:57	kanzure:	this rewrite of history is inappropriate
13:51:19	JackH:	hearn: we were like what? 200 dudes?
13:51:19	hearn:	JackH: so why ask me what i'd do if satoshi said X, when he already said it, if you're just going to immediately say "oh well that was different times"? seems like not a very useful question.
13:51:20	adam3us:	gavinandresen: so given that there's momentum on multiple proposals in review it and its safer not have controversy for the success of the hard fork, and generally for public communication if the development people are acting colaboratively, how about using the process and implementing the winner?
13:51:28	helo:	kanzure: how i read what gavin said re: bad timing
13:51:48	hearn:	adam3us: can you outline *specifically* what the process you have in mind is?
13:51:48	adam3us:	gavinandresen: it seems like you are OK for example with jgarzik's proposal or presumably variants of it because the parameters are quite different from yours.
13:51:49	JackH:	hearn: I asked if he was to say something now, not back then. But an updated satoshi idea
13:51:53	instagibbs:	hearn: I agree "consensus" is fuzzy. But (N-1)-core dev opposition clearly isn't it. "I"ll know it when I see it" sort of applies here
13:51:55	kanzure:	helo: ah; but the evidence is that the sidechain developers were actually actively commenting on reddit and in emails. look at the timestamps.
13:51:57	hearn:	adam3us: e.g. to the level we could implement it in a little web app or something
13:52:24	gavinandresen:	adam3us: how about not putting all our eggs in one basket and not putting some fuzzy process with no clear endpoint on the critical path?
13:52:45	kanzure:	gavinandresen: so network consensus is definitely a basket
13:52:50	kanzure:	that's called a blockchain
13:52:54	instagibbs:	You clearly wouldn't say N/2 For, N/2 Against was consensus
13:53:02	instagibbs:	why is N-1 "maybe consensus"
13:53:09	hearn:	instagibbs: what is N equal to here?
13:53:17	instagibbs:	Specifically core dev set, to be clear
13:53:18	adam3us:	gavinandresen: because it is safer on several aspects that i explained in my post. its constructive, collaborative, benefits from peer review, gets more public discussion, stops us looking bad in public as the tech brains behind bitcoin, etc
13:53:24	nsh:	hearn, it's the bagholders of technical debt
13:53:36	nsh:	(you do not want to be the sole bagholder of bitcoin's technical debt)
13:53:38	hearn:	instagibbs: and who is in that set?
13:53:38	nsh:	(i promise you)
13:54:25	instagibbs:	hearn: Can you show me your list of core devs that have consensus for a fork?
13:54:44	instagibbs:	including dissenters
13:54:53	kanzure:	hearn: btw i think your time would be better spent replying to adam3us' email than replying in here
13:55:07	kanzure:	someone requested in-line responses
13:55:08	adam3us:	gavinandresen: i'm not sure you maybe explained very clearly and perhaps that bit wasnt what you were focussing on, but the message that hearn would be in sole control of bitcoin maintainership of bitcoin for a non-trivial period is not good for security, integrity, avoidance of speciali interest lobbying, blackmail, getting hit by a truck etc etc. and jsut perception wise. (no offence to hearn - same would be true of any one person)
13:55:30	hearn:	in the event that i have a bad date with a truck, the github fork button will still work :)
13:55:39	hearn:	but anyway, yes if bitcoin XT gets serious traction i would make gavin a maintainer
13:55:43	kanzure:	further misinterpretation
13:55:43	gavinandresen:	adam3us: you're confounding bitcoin-the-project with various implementations...
13:55:51	kanzure:	the fork button does not cause network hard-forks
13:55:54	JackH:	hearn: you will never get our business to follow you. I think that is all that remains to be said. Go ahead, fork away, try to split the network. But you wont gain consensus and we will never bow to centralisation from the people that paid you and Gavin
13:55:57	hearn:	i wouldn't worry about the mechanics of this. i have run several successful open source projects
13:56:06	kanzure:	you are clearly unable to read
13:56:18	kanzure:	do you really think adam3us meant "forking an open source project's source code repository"?
13:56:21	kanzure:	really?
13:56:29	nsh:	perhaps we need to use different words
13:56:31	adam3us:	gavinandresen: there is also quite a bit of infrastructure around bitcoin. the reviewer process requireing consensus approval to stop bugs getting snuck in if someones children were captive and they blackmailed for example.
13:56:33	nsh:	if this continues to be a problem :)
13:56:54	nsh:	what was the event that lead to the split between the western and eastern roman empires?
13:57:03	hearn:	kanzure: he was talking about maintainership so yes
13:57:04	nsh:	i'm sure it has a suitably cataclysmic name
13:57:14	kanzure:	hearn: okay so you think that maintainership has nothing to do with hard-forking?
13:57:30	gavinandresen:	ok, I think my time is better spent finishing writing regression and unit tests....
13:57:31	adam3us:	gavinandresen: and the security incident management etc
13:57:59	JackH:	we will never bow to XT
13:58:05	adam3us:	gavinandresen: no comment on choosing the winner from the BIP process to normalise relations and act with a unified technical view in public?
13:58:18	kanzure:	(why would anyone want to use a fork of bitcoin-core if the maintainers are incapable of distinguishing between repository forks and consensus hard-forks and multiple blockchains?)
13:58:36	adam3us:	gavinandresen: its not like you coudlnt back out if you though the process selection was supremely bad even…
13:58:56	helo:	the 20MB patch probably won't become more popular in the near future than it is right now. so the window of opportunity to shove it through is closing.
13:59:09	kanzure:	gavinandresen: to make it clear, we're still trying to get you to admit that the threat should be revoked, and replaced with the previous procedures instead
13:59:25	helo:	"if we can just postpone its depoloyment long enough" vs "if we can just deploy it post-haste"
13:59:28	kanzure:	gavinandresen: i think many good reasons have been presented for this
13:59:35	gavinandresen:	adam3us: consensus is, ultimately, the code people choose to run. I'm happy to propose a BIP, would be even happier if there was only one BIP that everybody agreed was best.
13:59:52	nsh:	so developer consensus is valueless :/
14:00:07	adam3us:	gavinandresen: proposing to fork it seems kind of pointless now that there are multiple public process, so why not just join the fray?
14:00:13	kanzure:	gavinandresen: do you think that asking companies to run your fork would be more or less likely to result in companies to run a hard-forking network, regardless of technical merits?
14:00:27	adam3us:	gavinandresen: it deescalates teh situation leads to better open public communication and should lead to a better technical result
14:00:29	hearn:	nsh: i would say it's rather, undefined
14:00:35	gavinandresen:	... but I'm not going to propose a BIP until I've written code that implements it, because I think BIPs should be descriptive, not proscriptive.
14:01:13	adam3us:	gavinandresen: thats fine of course. i dont know if jgarzik started implementing but i presume people would expect that.
14:01:20	nsh:	and of course you can't lobby without code or a proposal anyway
14:01:27	kanzure:	nsh: on the contrary?
14:01:28	nsh:	because peopel would be silly to sign up to something that doesn't exist :)
14:01:34	nsh:	unfortunately, people are silly
14:01:36	kanzure:	nsh: that's what the claims have been, so far
14:01:38	nsh:	so try not to lobby :)
14:01:46	gavinandresen:	I think that is a reasonable bar for BIPs : if you care enough to actually implement it, then your BIP deserves serious consideration. Otherwise the BIP process gets overwhelmed with half-thought-out proposals....
14:02:07	nsh:	it's just a matter of phrasing the solicitation that *is* required to draft a proposal such that it doesn't seem like a request for endorsement
14:02:08	adam3us:	gavinandresen: but again, sorry to keep badgering on this one topic, but its just sooo much more constructive and i rdo think will result in a better outcome if you would just agree to suspend the hard-fork threat for now. its not a big ask in the context that you even seemed to be ok with jgarziks proposal.
14:02:11	nsh:	and there, problem solved
14:03:25	nsh:	(i did market research. you don't end a survey with 'and will you buy the product we make with this feedback')
14:03:29	nsh:	(that would be prohibited, even)
14:03:32	gavinandresen:	adam3us: there will absolutely, positively be no hard fork before January. Is that sufficient?
14:03:35	adam3us:	gavinandresen: it will also save 100s of wasted bitcoin developer cycles lobbying companies CEOs and things like the bitcoin.org site that i'm sure you saw
14:04:07	kanzure:	gavinandresen: we're not talking about "any possible hard-fork", we're talking about the one you threatened....
14:04:16	adam3us:	gavinandresen: i'm not sure what you mean. is that the date code is rolled out. or rather when deployed hard-fork deployed in the next month that will trigger by 1st jan?
14:04:18	helo:	gavinandresen: so you're sticking with your contentious hard fork plan as-is?
14:04:35	gavinandresen:	adam3us: that's the trigger date. Obviously the code needs to be rolled out before then....
14:04:45	nsh:	great, now the nuke has a trigger
14:04:49	gavinandresen:	(well, that's the earliest-possible-trigger date)
14:04:49	adam3us:	gavinandresen: so then that wasnt really an answer i think.
14:04:51	nsh:	* nsh can't wait for the launch codes
14:04:52	nsh:	:)
14:04:53	JackH:	nuke indeed
14:05:32	Eliel:	adam3us: in other words, you don't think gavin should be placing the issue of whether or not to fork to a public vote.
14:05:37	hearn:	the answer is "no", adam
14:05:39	JackH:	impressive the person that was handed the reigns from Satoshi is the person that is trying to destroy that very same project now
14:05:45	kanzure:	Eliel: that's not what he claimed he was doing
14:05:59	kanzure:	Eliel: he claimed he was getting companies to adopt the patch regardless of bip process, and that a hard-fork will occur anyway
14:06:01	adam3us:	gavinandresen: i'm trying to be constructive here. this is causing a lot of very productive coders working on bitcoin-dev a huge amount of stress. i'm not asking you to give much up if you're anyway basically agreeing with jgarzik's proposal or ones similar to it.
14:06:01	Eliel:	kanzure: I don't care what he claimed he's doing. That is what he's doing.
14:06:16	kanzure:	Eliel: public vote was never an option
14:06:25	Taek:	JackH: no personal attacks please.
14:06:31	helo:	JackH: less hyperbole ;)
14:06:41	kanzure:	cool
14:06:50	gavinandresen:	adam3us: how about: I commit to writing a BIP, and I will ask Mike to not rollout an XT release until that BIP and the code has had at least... ummm, three weeks of review.
14:07:00	hearn:	please be aware of something important. i'm starting to hear from people that investors both current and "thinking about it" are realising that Blockstream appears to be able to block a change that has extremely strong, widespread commercial support. and they are freaking out about it.
14:07:03	JackH:	Taek: not a personal attack, just witnessing the irony of it all
14:07:13	kanzure:	gavinandresen: how about more specifically, "I will not ask companies to run this hard-fork, and I will not ask them to join me on hard-forking the network."
14:07:17	dgenr8:	* dgenr8 notes gavin broke is his self-imposed rule of only discussing alternative blocksize solutions that were implemented
14:07:21	nsh:	gavinandresen, can you submit a BIP about the three-week review hard-limit first?
14:07:23	nsh:	:)
14:07:36	hearn:	if you guys are really such strong supporters of decentralisation, you *must* accept that hard forks are a way to resolve problems when other paths have failed
14:07:39	JackH:	hearn: that is a lie, nobody is thinking anyone is blocking anything, people just think you are trying to destroy Bitcoin by forking it
14:07:48	kanzure:	hearn: that's good! companies can be threatened by the us government in general, even to accept bad or broken patches.
14:07:51	nsh:	hearn, we just don't believe in waving failure around as a bat
14:07:52	hearn:	otherwise what you are asking for is basically, a dictatorship of blockstream
14:07:54	adam3us:	gavinandresen: that seems good, but i was kind of assuming you would put the code for review anyway. the question is more about will you put your bip in parallel code review beside jgarziks and similar alternatives and let the technical reviews which include you and hearn agree on which is best.
14:07:57	JackH:	hearn: the only problem is XT
14:07:58	hearn:	and that's not really decentralisation, is it?
14:08:12	dgenr8:	has anybody other than gavin actually written any code around this?
14:08:12	adam3us:	gavinandresen: the proposals dont seem different enough to make an issue out of this. you already agreed to jgarziks
14:08:17	kanzure:	hearn: nice try, but that's not a good argument at all
14:08:33	hearn:	it's not an "argument". it's me repeating what i'm hearing other people conclude. and can you blame them?
14:08:41	kanzure:	yes, i can blame anyone i want
14:08:43	kanzure:	wtf?
14:08:46	hearn:	adam3us: you have failed to describe what this "BIP process" is, in anywhere near sufficient detail for anyone to agree to it.
14:09:03	JackH:	hearn: do you realize nobody in this very IRC chat right now seems to think what you are doing is a good idea? or does that not matter? XT 4 ever right?
14:09:07	hearn:	adam3us: what's the decision making algorithm, here?
14:09:22	gavinandresen:	adam3us: I have a bunch of technical nits with jgarzik's proposal, and I HATE the 32MB cap (just means we go through this again at some point), but sure, if that is consensus, then spiffy.
14:09:26	kanzure:	hearn: it really doesn't matter what delusions you inject into the conversation
14:09:37	hearn:	title: "Should the Bitcoin block size limit be raised within the next two years? - Poll Results"
14:09:41	helo:	gavinandresen: hearn: not deploying contentious hardforks > *
14:09:41	hearn:	http://www.poll-maker.com/results329839xee274Cb0-12#tab-2
14:09:46	hearn:	results: 92% say yes
14:09:59	kanzure:	haha
14:10:10	JackH:	LMAO
14:10:16	adam3us:	gavinandresen: well the point of the review process is that you get to pick nits in jgarziks and others and vice versa. so thats good. jgarzik i believe already made several updates based on feedback. (which would have been better made in public)
14:10:21	nsh:	how much did the measure that defined pi to be 3 in some US state pass by?
14:10:28	nsh:	i bet it was a strong, godfearing majority
14:10:35	hearn:	* hearn shrugs
14:10:54	JackH:	hearn: nice pool, odd it is closed and doesnt really prove anything.
14:11:00	adam3us:	gavinandresen: but it kind of makes a lie of the review process if one party is saying that they will overrule its outcome. i dont want to paint you wrongly as having said that. but clarification would really help just to clear the air and move forwards.
14:11:00	helo:	you obviously have the PR battle in pocket for your hard fork. but a lot of people that care about (and understand very well) bitcoin are in that 8%.
14:11:04	kanzure:	okay, so it sounds like gavinandresen is not going to answer adam3us at all
14:11:16	hearn:	ignore whatever evidence you like. i guess 10 minutes in #bitcoin-wizards is all the polling needed :)
14:11:36	kanzure:	hearn: yeah, because polling makes sooo much sense to decide the value of pi
14:11:41	adam3us:	hearn: no one is disputing that everyone wants to scale bitcoin.
14:11:46	JackH:	hearn: We have 20.000 clients right now for Bitcoin processing
14:11:54	JackH:	I can assure you one thing. NOT ONE of those will ever use XT
14:11:59	hearn:	the poll didn't ask about "scaling" in a general sense. it asked about raising the block size limit.
14:12:12	JackH:	you can poll whatever you want, we are all capable of seeing through this
14:12:14	adam3us:	hearn: including most saying they think the first step of which is a proposal to create extra throughput and time to work on a longer term solution.
14:12:25	hearn:	JackH: alright. just so i can keep track of things in my lists, which payment processor is yours?
14:12:26	helo:	so you can choose to leverage your (likely temporary) PR victory now and try to push through, or defer to the relevance of all of the people pleading with you to backpedal a bit.
14:12:36	JackH:	http://uk.prweb.com/releases/2015/04/prweb12672463.htm
14:12:49	kanzure:	.title
14:12:49	yoleaux:	NorthPayments, a leading payment processor in the UK, collaborate with BitcoinPayGate.com to introduce an alternative payment option for customers
14:12:51	JackH:	Go ahead and DDoS us now since we dont agree to bow to you
14:12:56	dgenr8:	gavinandresen: do you plan to submit the patch to both bitcoin and bitcoinxt?
14:12:57	nsh:	* nsh doesn't claim any relevance, for the record :)
14:12:58	hearn:	ok, thanks
14:13:05	hearn:	um, no, i don't DDoS people who disagree with me
14:13:11	kanzure:	you can't prove that
14:13:12	kanzure:	nobody could
14:13:16	nsh:	JackH, please.. :)
14:13:20	JackH:	no you just try to remove Bitcoin from the equation ;)
14:13:30	JackH:	how much did you get paid?
14:13:31	JackH:	seriousy now?
14:13:33	JackH:	7 figures?
14:13:39	kanzure:	uh...
14:13:47	hearn:	lol
14:13:49	JackH:	50% now, 50% upon hard-fork?
14:13:51	nsh:	maybe it's time for a break :)
14:13:52	gavinandresen:	dgenr8: I've been told no patch for increasing the blocksize is acceptable for Core, Wladimir and Greg will just NACK no matter what.
14:13:57	helo:	by pushing forward based on popular polling, you are presenting the view that the opinions of the people disagreeing with you in here are not relevant
14:14:10	nsh:	gavinandresen, why is jgarzik proposing one then?
14:14:11	kanzure:	gavinandresen: i think it reflects poorly on everyone that we're leaving adam3us hanging
14:14:13	nsh:	is he naive?
14:14:14	adam3us:	gavinandresen: thats not accurate
14:14:17	hearn:	helo: hardly. look at how much we've written in response to every raised concern.
14:14:23	dgenr8:	gavinandresen: so wha
14:14:41	adam3us:	gavinandresen: re-circling back to the discussion how about if you tell us what your conditions would be to participate in the bip review process and go with the winner of the process.
14:14:44	gavinandresen:	I'm happy to be wrong, and happy to submit a patch to Core
14:14:51	helo:	hearn: they've all read that stuff, and it has been inadequate (obviously)
14:15:06	kanzure:	we already knew you were planning a patch, but we were asking something else, gavinandresen
14:15:07	adam3us:	gavinandresen: i dont know who said that but they are wrong to the best of my knowledge
14:15:08	dgenr8:	gavinandresen: well it sends a message that you want it in core
14:15:35	gavinandresen:	adam3us: I'm happy to participate. I have no idea what "the winner of the process" means, though.
14:15:40	kanzure:	07:09 < adam3us> gavinandresen: but it kind of makes a lie of the review process if one party is saying that they will overrule its outcome. i dont want to paint you wrongly as having said that. but clarification would really help just to clear the air and move forwards.
14:15:54	kanzure:	gavinandresen: you made a public threat, we're asking you for clarification still
14:16:13	gavinandresen:	public threat? I'm going to write some code and then make it available for people to run.
14:16:21	gavinandresen:	They can run it or not....
14:16:21	hearn:	this is a stupid channel
14:16:27	kanzure:	hahaha
14:16:40	dgenr8:	it's actually already available. some crazy person could run it right now
14:16:42	adam3us:	gavinandresen: i think you do. the same way as the other BIPs over the last years have been decided (with the exception of BIP16/17 which in hindsight didnt work out ideally though it is a marginal loss only)
14:16:42	morcos:	gavinandresen: a lot of very reasonable people think you are taking this too far. you want progress, progress has started. i'd even go so far to say as most people are resigned to accepting an increase in the blocksize before they think its actually appropriate in order to maintain consensus. but please let that process play out. waiting 3 weeks for review of your one implementation before you roll it out to people
14:17:15	kanzure:	gavinandresen: you specifically said you already have companies committed to it
14:17:20	JackH:	they are paid off
14:17:21	kanzure:	gavinandresen: that's a threat. to fork the network. do you see why?
14:17:24	JackH:	no reason to talk any longer
14:17:28	nsh:	kanzure, i'm sure you misread that anyone had committed to it
14:17:38	nsh:	as gavinandresen is being assiduous not to get endorsements of something that doesn't exist yet
14:17:41	JackH:	this is by far the easiest way to take out Bitcoin
14:17:43	hearn:	morcos: i'm planning on letting the patch bake for a bit publicly before we spin some binaries, no worries
14:17:54	nsh:	i can only assume
14:18:06	nsh:	i want to live in the world where i can assume that safely
14:18:16	dgenr8:	morcos: nobody would be paying any attention at all but for gavin's work and actions
14:18:23	nsh:	* nsh nods
14:18:31	nsh:	there are no villains here
14:18:34	morcos:	if i go along with ACK'ing some proposal like jgarzik's at this point, i will feel coerced into doing it already at this point. but at least we'll all agree whether under pressure or not... if the momentum to do something dies down in a month or so, then no doubt you can pursue this path and not listen to entreaties to stop any more if you choose
14:19:21	morcos:	but i don't want to find out what happens when a substantial minority is left behind in a hard fork
14:19:38	nsh:	i do
14:19:42	morcos:	i think thats the danger of letting people pick which code to run
14:19:43	nsh:	i just want to find out without billions being lost
14:19:56	dgenr8:	morcos: with a flag day a year in the future, nothing is final upon release of some software product
14:19:56	nsh:	because simulating systems is tractable, undoing history isn't
14:20:04	hearn:	i don't think there's much chance of that. they'd have to choose to be left behind, or somehow be so disconnected from the bitcoin community and their own node logs AND -alertnotify etc, that they had no idea it was coming
14:20:09	hearn:	in which case their node is on autopilot anyway
14:20:12	gavinandresen:	Again, I think it is irresponsible not to plan for scaling up NOW. Reasonable people can disagree about that, but that's my strong feeling.
14:20:16	kanzure:	i think that in general you should assume the best in people, but in cases where safety is critical it is bad to assume the best, instead we should proceed with caution
14:20:28	kanzure:	gavinandresen: i think you should answer the exact question :-(
14:20:36	gavinandresen:	kanzure: what exact question?
14:20:37	helo:	when is the "upgrade to bitcoin XT!" alert going out?
14:20:50	hearn:	helo: i think Core already prints messages saying "Upgrade now" when it notices new block versions it doesn't know about
14:20:55	kanzure:	gavinandresen: are you going to campaign companies to run the hard fork even in the presence of nacks?
14:21:00	hearn:	helo: so that'd depend on miner adoption. at least that's my vague recollection of how the code works.
14:21:08	kanzure:	and even in the presence of limited miner adoption
14:21:17	JackH:	gavinandresen: you are not giving people a choice to upgrade . you are forcing them to upgrade by contacting them one by one and telling them what to do
14:21:42	adam3us:	gavinandresen: that is not what the vast majority of people are saying. it seems like most will support something in the ballpark of jgarik's with minor differences or something like it with those differences applied.
14:21:49	gavinandresen:	kanzure: yes, I will encourage companies to announce that they are "big block ready" by running code that will accept bigger blocks. If consensus emerges for some variant of how big / when / etc then I'll encourage them to run THAT code.
14:21:49	helo:	JackH: that still is a choice, as he's not in a position to fine them or anything
14:22:21	adam3us:	gavinandresen: consider: if we proceed like this people will be working in haste, in a distressed state of mind, and it is more likely that a mistake will be made.
14:22:37	JackH:	helo: he is using his star status to do it. the choice is not: "select A or B"
14:22:45	kanzure:	welp there's our answer folks
14:22:50	JackH:	helo: he is telling them what the best choice according to himself is, that is a huge difference
14:23:16	JackH:	again, having seen all this chat today, I no longer believe Hearn nor Gavin are having any intention of keeping Bitcoin going. They are either paid off or something else is happening
14:23:29	adam3us:	gavinandresen: i gave you an example of that in PM why this affects people. some people do not react well to stress.
14:23:40	helo:	JackH: again, rise above the conspiracy theories
14:23:43	nsh:	* nsh nods
14:24:03	morcos:	JackH: thats obviously not the case, but I think they place different priorities on what's most important for the health of bitcoin
14:24:03	hearn:	JackH: lol, you're hilarious. "you are forcing people by talking to them"
14:24:04	kanzure:	helo: at what size of the bitcoin network do you think it would be prudent to watch out for conspiracies?
14:24:04	JackH:	helo: and they should rise above the craziness or pushing 20x the amount of data through nodes
14:24:10	dgenr8:	* dgenr8 plans to go mine a hard fork, just for enlightenment. i can finally experience the thrill of mining bitcoin-ish
14:24:14	helo:	what you mention is possible, but not meaningfully actionable to any extent because there is no evidence
14:24:20	kanzure:	hearn: pretending to be an authority can be very damaging
14:24:38	kanzure:	hearn: companies are used to the authority model. it makes sense to them.
14:24:40	JackH:	hearn: if you think people dont implicitly trust you more than some random dude, you dont understand stardom. People will naturally listen to "core-devs" more. It is maybe wrong to say forced, but its definitely coerced
14:25:11	helo:	"convinced"
14:25:35	hearn:	it's quite debateable whether i'm a "core dev" or not. i've never much liked that label. it's about as well defined as the term "developer consensus"
14:25:50	nsh:	consent i'm sure will be giving willingly; informed-consent cannot be given by all
14:25:51	hearn:	if people listen to me or gavin, it's only because they think what we say makes sense.
14:25:56	hearn:	it's not like we have some kind of mind control rays
14:25:58	kanzure:	that sounds pretty close to "the development model doesn't match other systems or networks, therefore it must be wrong"
14:25:59	JackH:	hearn: if you had the best intentions, you would give people a choice without contacting them personally. You did not, thus we can assume you have another agenda
14:26:21	hearn:	rest assured, we have not and cannot contact everyone personally
14:26:33	kanzure:	hearn: you really think that the only reason that people listen to gavinandresen is because he makes sense? really?
14:26:59	kanzure:	you don't think that anyone, will ever make the mistake of trusting gavinandresen for reasons other than sensemaking?
14:27:05	nsh:	hearn, you can't discount that people must, by definition, but some degree of blind trust in the recommendations of developers
14:27:11	nsh:	because no-one can understand all the code
14:27:12	JackH:	I must however give it to you. You are admirable in your struggle to get everyone to switch to XT. Most people would have given up by now.
14:27:36	JackH:	We had this conversation for what, 2 months now, reddit, bitcointalk, here in multiple channels, on sourceforge etc
14:27:39	helo:	i prefer the anti-occam theory that their contentious hard fork announcement is what they thought was the best way to get everyone riled up and tackling the scalability problem in earnest
14:27:50	nsh:	* nsh nods
14:28:00	helo:	because in any case, that is what it is doing
14:28:09	nsh:	but, as said, it could transition from useful to counter-productive as people's anxieties rises
14:28:10	nsh:	*rise
14:28:36	nsh:	and we are trying to avoid that by making it seem less of a threat than a way to spur a multilateral process
14:28:44	nsh:	and that doesn't seem like much of a rhetorical compromise to be honest
14:28:49	wallet42:	hear: can xt nodes be pruned while still supporting getutxos?
14:29:11	helo:	the process has kicked off now, so yes... now would be a perfect time to back down and see what the process comes up with
14:29:25	nsh:	or soften the phrasing
14:29:32	nsh:	diplomatic words go a long way and cost little
14:29:50	helo:	WOTD
14:29:53	helo:	Q
14:29:53	kanzure:	the alternative is an immune response of massive proportions i think
14:30:20	kanzure:	alternatives (like in the presence of no disarming) should be better considered
14:30:43	sturles:	JackH: What is the point of switching to XT, except for the HD wallet features? I haven't seen the discussions you refer to.
14:30:46	kanzure:	i believe adam3us mentioned an interesting strategy of soft-forking the network ahead of a contentious partial hard-fork
14:31:27	JackH:	strules: there is no point of switching to XT at all
14:31:54	JackH:	XT is build to centralize Bitcoin in the hands of few people by killing off nodes
14:31:58	sturles:	Hmm, yes. It relays and highlights double spends. That's a feature.
14:32:16	sturles:	Huh? In which way does Bitcoin XT centralize anything?
14:34:25	JackH:	sturles: go ahead and download 20mb every 10 min. Let me know how it works for you relaying that at the same time
14:34:27	kanzure:	(also, communication is a form of mind control; it's how you control the perceptions of others and communicate or relay information. audio and vocal communication uses mechanical vibrations that are often emitted from other forms of rays.)
14:34:38	kanzure:	((perhaps my favorite is ultrasound rays))
14:35:00	sturles:	JackH: You are talking in riddles. Bitcoin XT doesn't download 20 MB every minute.
14:35:35	JackH:	not yet
14:35:41	JackH:	it is supposed to
14:35:47	adam3us:	kanzure: i didnt put much thought into it but it might be possible yes.
14:36:00	JackH:	basically its a "patch" that is supposed to knock out nodes in the network
14:36:19	JackH:	it will then be cheap to ringfence the rest of the network with malicious nodes and serve crap data
14:36:23	JackH:	and then its bye bye Bitcoin
14:36:35	gavinandresen:	JackH: I thought I just said the patch I was working on is 8MB.......
14:36:35	sturles:	JackH: Ah, you haven't grasped the basic concepts of bitcoin yet, it seems. Sure you didn't mean to be in #bitcoin-clueless?
14:36:37	GAit:	hearn: you and Gavin have been the most public media friendly developers around Bitcoin, people aren't following you because you are right but because you are more famous. gavinandresen, you should follow the consensus process with the BIP, not threaten to hard fork if things don't go your way oki doki
14:37:05	JackH:	gavinandresen: if that is the case then we are all the sudden aligned in what we want
14:37:33	JackH:	if you work on some of jgarzik proposals then I think it is a completely different situation
14:38:24	JackH:	if we get the chance to review the code, and not having it stuffed on us, and it sounds feasible in terms of increasing the block size, well then that is a completely different talk
14:38:27	sturles:	JackH: Bitcoin XT doesn't even support 20 MB blocks, and what you write now is the opposite of what the devopers wite here, so I don't get it. What is your _real_ problem with Bitcoin XT?
14:38:49	JackH:	and if its a BIP, that would be even better ;)
14:39:16	kanzure:	sturles: nobody cares that there is another patch set out there, really. nobody has ever brought that up as a problem.
14:39:20	sturles:	For a merchant the double spend detection feature is a good one.
14:39:20	GAit:	gavinandresen: I think is important to bring things back to collaborative state, no forced hard forking
14:39:35	hearn:	there will be a chance to review the code and comment on it before it's merged into XT, there will be a BIP and it's very likely that patch+bip will be for 8mb+stuff, which is, i think, what has been said all along.
14:39:42	sturles:	kanzure: What patch set?
14:39:47	kanzure:	sturles: xt is a patch set....
14:39:54	GAit:	hearn: the problem is your going ahead regardless of NACK
14:40:15	kanzure:	GAit: no, it's convincing companies regardless of NACKs
14:40:32	adam3us:	so here's a thought what if jgarzik and gavinandresen pooled BIPs.
14:40:54	adam3us:	they seem moderately similar and gavinandresen seemed reasonably ok with jgarzik's current parameters.
14:40:58	GAit:	GAit has left #bitcoin-wizards
14:41:03	adam3us:	combined them.
14:41:15	adam3us:	make BIP 102 out of 100+101
14:41:57	JackH:	Gavin and Hearn, I think you may also misunderstand people here. What we dont want is fragmentation and the possibility of the network effort to diminish in any way.
14:42:00	GAit:	adam3us: that would be great, collaboration between jeff and gavinandresen but is important gavinandresen calls off the contentious no matter what hard fork in XT, I am not sure Mike is prepared to support problems when they inevitably arise
14:42:48	GAit:	fragmenting a blockchain is much worse than fragmenting an open source project
14:42:54	JackH:	And by network effort, I mean, risking miner amounts and node amounts
14:42:59	helo:	back in P2SH days, there was some dissent (luke). the majority of the devs discussed and decided on a particular approach, and the minority dissenting devs aquiesced.
14:43:15	adam3us:	helo: exactly.
14:43:15	kanzure:	GAit: unfortunately they have both demonstrated an inability to understand "forking an opne-source repository" and "forking a blockchain using a contentious hard-fork".
14:43:42	helo:	luke never went on a big PR campaign to convince the ignorant masses and force a change that most developers disagreed with, although he could have
14:43:55	kanzure:	helo: i believe there were some differences there like limitations on the damage that could be caused or something, so the others were okay because of that reason
14:44:01	kanzure:	(not entirely sure i remember the details correctly?)
14:44:45	kanzure:	GAit: whoops i mean that the two things i quoted are different topics
14:44:55	GAit:	kanzure: here's hoping that people can come to a more collaborative approach. gavinandresen is declaring "WAR" to bitcoin core if he goes ahead with his contentious hard fork
14:45:20	kanzure:	GAit: right; and it's not related to forking the open-source project. it's related to campaigning companies to run a contentious hard-fork.
14:45:24	adam3us:	kanzure: "forking an opne-source repository" and"forking a blockchain using a contentious hard-fork". no i think thats not accurate. gavin said in answer to this kind of question on panel discussion etc that in his view others would see the trend line and follow it.
14:45:37	kanzure:	adam3us: please continue/elaborate
14:46:05	zooko`:	zooko` is now known as zooko
14:46:23	adam3us:	the point is more that we should strive for minimum dissent as it is the fact that people are upset and feel overruled or that th ebest proposal might not win that they would go propose alternatiave and also lobbyg companies or make soft-forks to break the hard-fork in flight.
14:46:34	kanzure:	for example, are you saying that he thinks that the companies he campaigns to are going to see the trend of the other companies following, therefore they will adopt the hard-fork and the rest of the network wont?
14:46:37	adam3us:	we minimise that if we get into a constructive mode of working in development
14:46:51	kanzure:	i agree that constructive mode minimizes that
14:47:30	adam3us:	(not to put words into gavinandresen mouth) but i understood from what was he thinks that game-theory wise its too much of a loss that everyone would get on the same page or risk armageddon.
14:47:42	kanzure:	right, that's what makes it a nuclear threat
14:47:44	adam3us:	which is why i characterised it as a game of chicken.
14:47:50	kanzure:	indeed.....
14:47:51	hearn:	a vote is not a "nuclear threat".
14:47:56	kanzure:	it's not a vote
14:48:07	adam3us:	kanzure: yes its a risk calculus something kind of like the risk of mutual assured destruction. some is expected to back down
14:48:07	GAit:	hearn: this is not a vote
14:48:09	Eliel:	GAit: I think it's unfair to call XT a "contentious no matter what hard fork". It's not "no matter what" since there's the 75% threshold that's required for an actual chain fork to happen.
14:48:32	GAit:	Eliel: what thereshold, the block version and some two weeks grace period? miners can game that all they want
14:48:39	kanzure:	Eliel: xt is not a contentious hard-fork. that's wrong.
14:48:49	Mably:	just wondering: aren't the miners the ones who decide at the end?
14:48:50	kanzure:	Eliel: xt is a fork of an open-source repository. it's unrelated to what we're talking about.
14:49:12	kanzure:	it is wrong to characterize forks of an open-source repository as causing a contentious hard-fork
14:49:24	GAit:	Eliel: the problem is that gavinandresen and hearn are threatening the security of the blockchain by going by hard forking without any technical consensus from the people most familiar with the details and with the people that contributed the most, is that not enough?
14:49:24	kanzure:	anyone can generate an unlimited quantity of open-source repository forks
14:49:37	kanzure:	without damaging the network
14:49:55	GAit:	running XT with 20MB patches is a contentious hard fork
14:50:10	Eliel:	kanzure: I'm quite aware of what the difference is in forking a repository and forking the blockchain. Thank you very much.
14:50:16	kanzure:	Eliel: alright
14:51:05	Mably:	Won't you have to convince more than 50% of the mining power to run XT for the hard fork to succeed?
14:51:15	kanzure:	what do you mean by "succeed"?
14:51:24	Mably:	longuest chain
14:51:30	Eliel:	Mably: over 75% is what the code will require before it even makes an attempt.
14:51:39	Mably:	Ah ok
14:51:40	kanzure:	there's ways around that, like hardcoded checkpoints (someone threatened this recently) (adam3us might remember who?)
14:51:47	hearn:	GAit: for what it's worth i have been around longer and written vastly more code than any of {adam,gregory,peter todd,etc}. that code included a reimplementation of bitcoin in another language. so, i rather think we are quite familiar with the details and are amongst those who are contributed the most.
14:52:07	kanzure:	what are you replying to
14:52:33	kanzure:	as far as i can tell that does not answer any question GAit has ever asked you
14:53:18	Mably:	Eliel: could you explain your 75%?
14:53:20	hearn:	his message to eliel
14:53:34	kanzure:	looking
14:53:39	GAit:	hearn: writing an SPV library is quite different from core work, you are not the first nor only one
14:54:01	GAit:	hearn: but again, irrelevant to the current discussion, which is going ahead with nuclear threats
14:54:20	kanzure:	yeah, i don't think your response to GAit's message to Eliel makes any sense.
14:54:26	adam3us:	kanzure: must've been someone else i dont remember hardcoded checkpoint. i think. could be misunderstanding what you mean
14:54:33	kanzure:	okay, yeah nevermind
14:54:36	kanzure:	i'll drop it since i can't cite it
14:54:40	hearn:	GAit: bitcoinj also has code to do full verification in it
14:54:46	hearn:	GAit: but the SPV mode is the focus, indeed.
14:55:08	hearn:	GAit: regardless, i was the first actually
14:55:41	helo:	direct democracy on a global scale is probably one of the worst approaches to deciding anything
14:55:45	hearn:	GAit: so you have said several things now that just aren't correct. and by the way, i've done work on Core too. for instance i proposed and then implemented support for leveldb
14:55:48	GAit:	hearn: is this an ego problem? you are good enough but your proposal are scary and risky, we can work on them with consensus, why threatening the others?
14:56:04	hearn:	along with designing BIP70, proposing and working on the design for Bloom filtering, etc
14:56:23	adam3us:	kanzure: but it seems plausible that someone so minded could harden existing code to against in-flight hard-fork in various ways. i don thtink anyone put a lot of thought into it.
14:56:25	hearn:	anyway, my point is, your comment about "without consensus by those most familiar with the details and the people that contributed the most" is really not that accurate nor helpful
14:57:00	helo:	hearn: my grandma's vote on what codebase to run is absolutely worthless
14:57:04	GAit:	hearn: i didn't mean to minimize your contributions to non consensus code but this area you are touching now is dangerous (and there have been problems with the leveldb migration if im not mistaken)
14:57:34	hearn:	no
14:57:37	helo:	popular vote is a terrible way to decide policy
14:57:42	gavinandresen:	GAit: Mike wrote the first draft of the BIP that is the March 15 fork post-mortem....
14:57:44	kanzure:	it's not really even policy
14:57:48	kanzure:	it's wrong to misconstrue this as policy
14:58:05	hearn:	GAit: as a refresher, BDB had design problems in it that made it hopelessly unsuitable for consensus work. Satoshi did not know that, and nor did we until the network spontaneously forked.
14:58:35	adam3us:	GAit: i think its not correct to blame mike for the leveldb.. he checked it in but others changed much afterwards, no one saw it coming.
14:58:35	hearn:	GAit: specifically, BDB could get itself into a position where two nodes, given the same inputs, could arrive at different decisions about a block!
14:58:42	kanzure:	so are you trying to say that "because we have written bips in the past, companies should be safe listneing to us for all time in the future"?
14:58:49	hearn:	GAit: LevelDB is a vastly better codebase and did not suffer such problems. good thing i proposed we use it, no?
14:58:58	GAit:	adam3us: I don't think I blamed him, I am suggesting that consensus related changes are dangerous
14:59:17	adam3us:	GAit: fair enough. and this is a very relevant point right now.
14:59:18	GAit:	nowhere in my phrasing i suggested Mike is at fault for it
14:59:20	gavinandresen:	I'll say it: not all developers have experience scaling up systems. I listen much harder to those who do.
14:59:20	hearn:	GAit: as LevelDB improved consensus robustness quite dramatically. unfortunately, bdb exploded before the LevelDB rollout was complete
14:59:45	gwillen:	kanzure: here's the message where mike threatened hardcoded checkpoints to fork off 50+% of chinese miners: http://sourceforge.net/p/bitcoin/mailman/message/34162353/
14:59:51	GAit:	gavinandresen: i doesn't seem like you are listening at all to the rest of the core team
15:00:21	GAit:	hearn: details, the point is that consensus changes are dangerous, stop thinking everyone is here to bite you or stop getting your *ego* in the way
15:00:33	zooko:	Hi, gwillen!
15:00:40	gwillen:	zooko: \o
15:00:53	hearn:	sigh. GAit, I am answering your concerns. you have said several times that gavinandresen and myself are ignoring experts who understand the details. when i told you about our own expertise, suddenly we're guilty of being all about ego.
15:00:59	hearn:	there is no way to satisfy you, i think
15:01:21	zooko:	hearn: In my opinion, you could just stop replying to GAit on this channel, at least for now, and nothing bad would happen.
15:01:40	hearn:	yeah, i'm getting rather tired of it myself.
15:01:52	zooko:	No offense, GAit, but while I sympathize with your concerns, I don't think your current comments are helping.
15:01:59	gavinandresen:	GAit: so... some of the core team was pretty busy with their own projects, and there was no feedback to listen to. I am ALWAYS happy to listen. I reserve the right to disagree....
15:02:13	kanzure:	there was lots of feedback; look at the timestamps
15:02:19	kanzure:	they were doing sidechain last minute work plus also commenting everywhere
15:02:26	kanzure:	there were volumes of text written on reddit, for example
15:02:55	GAit:	forget one second about the block size increase, you are underestimating the dangers of hard forks without consensus, I don't get why we don't put that option away from the table
15:03:29	temujin:	just fork the network already so i can buy $70 coins again and profit off the recovery
15:03:35	GAit:	it's like having a guy with the gun pointed at you, it makes everything more stressful
15:04:26	zooko:	GAit: I'm sorry you're feeling high anxiety. That makes it hard to do good work.
15:04:34	GAit:	you were quite quick to attack my qualitative assessment of contributions to core but very slow [read never] to answer about putting down the nuclear option
15:04:37	moa:	i'd rather listen to the people who actually making commits and technical contributions than al the part-timers who use threats and drama
15:04:55	Eliel:	gwillen: it's unfair to characterize that message as a (personal) threat. It's a potential scenario that's not completely impossible, that might happen regardless of whether mike does anything to push things that way or not.
15:05:55	adam3us:	moa: i get the concern. but we should acknowledge that gavinandresen wrote a ton of the code (if you look at github stats) etc.
15:06:15	helo:	gavinandresen: disagree as much as you want, but you should do what excellent bitcoin developers in the past have done, and ultimately go along with developer consensus. please, can't you publicly withdraw your contentious hardfork threat?
15:07:05	GAit:	gavinandresen: i also ask to please withdraw the contentious hardfork threat
15:07:28	helo:	your view deserves its equal consideration, and will get it
15:08:17	helo:	your proposal does not deserve to overcome the others based on your own popularity
15:08:48	helo:	which is what a public vote (or patched bitcoin xt release) would be.
15:09:21	zooko:	FWIW, I think adam3us's email has unnecessarily alarmed you, and that you are not actually in dire danger and you do not actually need to urgently plead and persuade someone else to do something or not-do-something in order to save yourself.
15:09:22	Eliel:	GAit: even if gavin withdraws this so called "threat", people are still liable to jump ship to an altcoin that is able to scale if nothing happens in Bitcoin Core.
15:09:57	GAit:	Eliel: one would think that if the alt is scalable people would notice and update bitcoin long before the alt takes over
15:10:07	kanzure:	zooko: there was an actual threat email, you know. this was before adam3us' email.
15:10:11	GAit:	or if the alt is better and bitcoin can't be fixed, i say so be it
15:11:01	Eliel:	GAit: yep, and that situation is almost exactly the same. The only difference is the name of the altcoin.
15:11:05	GAit:	zooko: the danger is very real, people failing to see dangers in contentious hard fork != no danger
15:12:52	kanzure:	zooko: specifically there was mention of campaigning to companies to run a hard-fork patchset that had received nacks.... this was sent before adam3us' email.
15:13:35	Eliel:	GAit: the point I'm making is that it'd only be a false sense of security that resulted if gavin withdrew his plan.
15:14:33	zooko`:	zooko` is now known as zooko
15:15:48	Eliel:	If gavin and hearn don't go through with Bitcoin XT plans, the most likely scenario is more fragmentation of the community than with it.
15:15:52	zooko:	kanzure: I am aware.
15:16:58	Eliel:	(assuming of course, that bitcoin core doesn't get anything done in regards to scaling implementation)
15:17:15	kanzure:	zooko: alright
15:18:44	adam3us:	back in a bit. getting hungry
15:19:22	Eliel:	From my point of view, Bitcoin XT hard fork is a necessary plan B. Plan A being that Bitcoin Core implements something that solves the issue.
15:19:25	gavinandresen:	helo: I already said I'm happy to go along with developer consensus, if such a consensus emerges. But I am not happy to sit on my hands and do nothing in case there is no clear consensus, doing that would, in my humble opinion, be irresponsible.
15:19:58	gavinandresen:	... and now I'm going to go back to writing regression tests....
15:20:02	helo:	o/
15:20:20	GAit:	gavinandresen: are you taking responsability for any loss caused by the fork?
15:20:40	kanzure:	what
15:20:52	GAit:	saying if consensus emerges otherwise i will do X is akin to say that you don't consider a possibility where status quo + plan is consensus
15:21:09	gavinandresen:	GAit: nope, if you are an idiot and refuse to upgrade when your software tells you it is time to upgrade then I have no sympathy.
15:21:22	zooko:	gavinandresen: Write good regression tests!
15:21:35	GAit:	what makes you think that core won't also upgrade the block version and cut off connectivity to XT?
15:22:09	GAit:	to even higher so that XT will tell you upgraden and you'd be an idiot not to
15:22:13	gavinandresen:	GAit: I think Wladimir would NACK that.
15:22:55	GAit:	in a situatuon where you need to protect the network and it requires a small change without soft or hard fork I'd say people may consider such things, node operators and miners could do such thing without asking Wlad
15:23:29	GAit:	it's quite simple to recognize XT with its getutxo, you'd have to make it look as much as possible to core
15:23:34	GAit:	it's a war
15:23:39	GAit:	which nobody wants
15:24:30	gavinandresen:	gotta ignore everybody now and write some code.....
15:24:34	GAit:	which could cause a fork of XT miners earlier than real threshold
15:24:58	Eliel:	GAit: treating it like a war will only serve to make things worse.
15:24:59	GAit:	gavinandresen: you shouldn't ignore security concerns about contentious hard forks, i'm sorry, you are being unresonable
15:25:10	GAit:	Eliel: people won't sit waiting for Gavin to destroy things
15:25:24	GAit:	not that he wants to but it's one of the possible outcomes
15:27:36	Eliel:	GAit: things blowing up is a possible outcome even if gavin does nothing. More likely in that case I think.
15:27:55	GAit:	Eliel: consensus disagrees, but good attempt
15:38:42	jae:	jae is now known as Guest31906
15:40:42	richardus:	mr. gavin please be sure to use your key to advertise bitcoin xt
15:48:48	wallet42:	gavinandresen, sorry one more question: will I be able to run a pruned XT node which supports getutxos?
16:22:11	c0rw|away:	c0rw|away is now known as c0rw1n
16:38:52	_biO__:	_biO__ is now known as _biO_
17:02:20	zooko`:	zooko` is now known as zooko
17:34:30	zooko`:	zooko` is now known as zooko
17:37:51	hulkhogan_:	that was quite a read...
17:38:52	hulkhogan_:	gmaxwell: earlier, were you speaking of a mixnet for bitcoin transactions? imo it would be easy to hack up in python with some hardcoded nodes, possibly with p2p/discovery to find other mixers ... simple design might be too simple, though
17:40:15	gmaxwell:	hulkhogan_: should be super easy.
17:41:15	hulkhogan_:	gmaxwell: awesome, appreciate that, i think i have time to fiddle on it a bit today actually... will update if something fruitful is produced.
17:41:20	kanzure:	wouldn't it need to be sybil resistant?
17:42:07	hulkhogan_:	kanzure: yea... this is one of the things i didn't think about wrt simple design, i think so /but/ there might be some encryption tricks that make snooping on relayed transactions harder
17:42:30	hulkhogan_:	i was planning on reading the mixmaster papers a bit to see how they figured that stuff out.
17:42:45	antanst:	antanst has left #bitcoin-wizards
17:42:48	gmaxwell:	if it's hardcoded its inherently sybil resistant.
17:43:08	kanzure:	well i'm sure it's at minimum the usual tricks: increase the size and diversity of your anonymity set, increase your tolerance for ridiculously long delays, etc.
17:43:11	gmaxwell:	My recommendation would be to make the network itself only reachable over tor. Therefor the lower bound on privacy is that which is provided by tor.
17:43:24	kanzure:	(if using tor correctly)
17:43:51	hulkhogan_:	well, and this is off the deep end because i havent done any reading-- what if you encrypted the transactions up until the last hop/hardcoded node?
17:44:22	hulkhogan_:	that might preserve privacy, but the first daemon/server you pinged might also ID you, so yes tor support should be baked in
17:44:32	gmaxwell:	hulkhogan_: thats what a mixmaster like system would do, an unfortunate issue there is that you can't then use the validity of the transaction as your anti-dos token.
17:45:08	kanzure:	i agree that hardcoding is a nice solution, and it doesn't seem particularly dangerous here
17:45:08	hulkhogan_:	gmaxwell: you might have trusted entry nodes that validate + encrypt, but thats a pretty bad idea, wrt privacy
17:45:17	gmaxwell:	which isn't the end of the world or anything.
17:45:23	kanzure:	well, the privacy alternative is much worse actually
17:45:31	gmaxwell:	hulkhogan_: that kinda moots the encryption part, might as well have a one hop network then.
17:45:37	kanzure:	so trusting some random group of people is an additional option that is presently unavailable in other schemes
17:45:44	kanzure:	er, i'm sure there's a better way for me to word that
17:45:56	hulkhogan_:	let me think some more... very unbaked thoughts
17:47:06	gmaxwell:	and a one hop network wouldn't be a bad starting point. e.g. single server, you reach over tor. You send it 64KB every 5 minutes... either a real transaction, if you have one, or a randomly selected new mempool txn, or nothing. then according to parameters set with the transaction it randomly dequeues into the network.
17:47:07	hulkhogan_:	well, what if the last node was the node you encrypt to- that way you decrypt + verify at the last hop?
17:47:53	hulkhogan_:	hmm
17:48:44	hulkhogan_:	could you explain some of those params, 64KB, 5minutes, i'm not completely following there
17:49:57	hulkhogan_:	also, is this something that needs to be set behind a hidden service? i feel there might be a simpler way to accomplish the goal ... the simple case, basically
17:50:29	kanzure:	5 minutes is probably for the delay attribute
17:50:39	kanzure:	otherwise if you send everything as fast as possible there's timing attacks and correlations that are much easier
17:50:43	hulkhogan_:	yea, bulk sends etc
17:51:02	hulkhogan_:	right, if possible i'd like to keep tor support as a feature for later
17:51:08	hulkhogan_:	(lots of gotchas)
17:52:20	kanzure:	http://diyhpl.us/~bryan/papers2/security/Comparison%20Between%20Two%20Practical%20Mix%20Designs%20-%202004.pdf
17:52:51	kanzure:	http://diyhpl.us/~bryan/papers2/security/The%20Pynchon%20Gate:%20A%20secure%20method%20of%20pseudonymous%20mail%20retrieval%20-%20Len%20Sassaman%20-%20Bram%20Cohen%20-%20Nick%20Mathewson.pdf
17:53:06	hulkhogan_:	here's the easy case: run a daemon that accepts tx's from other daemons, that eventually forwards it to a hardcoded node that sends it on the network
17:53:14	kanzure:	http://diyhpl.us/~bryan/papers2/security/Towards%20an%20information%20theoretic%20metric%20for%20anonymity%20-%202004.ps
17:53:59	hulkhogan_:	so p2p-bitcoin-tx-submission-as-a-p2p-service... privacy guarantees are hard to say with the scheme, but tor support would be a plus
17:54:17	hulkhogan_:	heh, thanks kanzure, i'll cache those for later reading :)
17:56:44	zooko`:	zooko` is now known as zooko
18:00:31	hulkhogan_:	also, wrt sybil: you can just create arbitrary entry critera (like uptime, pow) to limit that
18:01:01	hulkhogan_:	think uptime is used for tor guard nodes, so something along those lines
18:04:31	gmaxwell:	hulkhogan_: tor has a centeralized trust model, makes many thing easier!
18:06:15	hulkhogan_:	yeah, and for this project it makes sense to keep the trust within a few known params (hardcoded) (at least, initally, to get started..)
18:10:18	hulkhogan_:	but i think its a good effort, having a p2p-like system to submit txes is useful.. some block explorers expose this... indeed it can be useful for masking the originating node/IP (if you use a VPN) and a more robust/accessible soln would be useful..
18:21:49	nickler:	is the purpose of this network to hide the origin of a transaction from the network peers?
18:25:19	gmaxwell:	nickler: correct.
18:25:52	gmaxwell:	nickler: there is existing functionality in bitcoin core (0.11+) to not relay transactions created by the local wallet, which allows some rpc-speaking daemon to go handle it for you 'somehow'.
18:26:11	kanzure:	does it continue to not relay beyond a restart?
18:31:31	gmaxwell:	yes. until you switch the option back, unless there is some bug.
18:34:24	nickler:	I just want to remark that according to my calculations, 'trickling' does a surprisingly good job. Assume an attacker is connected to all peers of node A and we assume a reasonably small prior probability that the tx originated from A.
18:34:44	nickler:	So if an attacker first gets the transaction from A the posterior is still negligible.
18:35:15	nickler:	Trickling doesn't help of course when the attacker is connected to all nodes, as this University of Luxemburg paper showed
18:36:24	nickler:	The paper 'Deanonymisation of clients in Bitcoin P2P network' by biryukov et al.
18:37:17	gmaxwell:	nickler: yes, but it creates incentives to sybil attack the network, which we've seen commercial entities doing. :(
18:38:19	gmaxwell:	nickler: the trickling also loses its effectiveness fairly quickly when transactions are repeated.
18:38:32	nickler:	ok, just wanted to learn the purpose of the mixnet
18:38:39	gmaxwell:	::nods::
18:38:40	nickler:	you mean repeated broadcasting
18:38:46	nickler:	?
18:39:18	gmaxwell:	nickler: actually no, I meant when a single party transacts many times (with linkable transactions). But it also applies to rebroadcast if the transaction doesn't confirm.
18:40:20	nickler:	yeah linkable transactions would really degrade trickling
18:40:44	gmaxwell:	nickler: right, and people will make small payments to old addresses to increase linkability.
18:41:12	nickler:	speaking of that, are there already ideas how to get unlinkability onto a sidechain? :D
18:42:12	zooko:	speaking of that, here's a new blog post, fresh from the oven:
18:42:22	zooko:	https://leastauthority.com/blog/zerocash_and_confidential_transactions.html
18:42:29	gmaxwell:	nickler: what kind of unliability? (like do you mean make the transaction to the sidechain unlinkable? or unlinkable transactions on the sidechain?)
18:42:45	nickler:	gmaxwell: the latter
18:44:51	gmaxwell:	nickler: step 1. take your particular scheme, step 2. put in sidechain? :P dunno if you saw, elements/alpha has a kind of privacy scheme. By itself it doesn't create transaction unlinkability, but it can be combined with coinjoin and/or coinswap. It's certantly not the only way to do improved privacy/fungibility, see zooko's link. :)
18:46:04	nickler:	gmaxwell: could something like monero style ringsigs be reasonably implemented in bitcoin?
18:46:37	gmaxwell:	Sure, though I think CT+CJ is strictly superior.
18:47:20	gmaxwell:	(to the bytecoin/monero approach)
18:48:00	gmaxwell:	though there are a number of ways to improve that approach, e.g. the combination with OWAS is really nice. I haven't come up with a way to combine CT with it though; adam has tried some without success.
18:49:29	gmaxwell:	(I mean to do so while staying in the realm of boring cryptography, ZC is strictly superior from a privacy perspective)
18:50:02	nickler:	gmaxwell: ah thanks a lot. Last remark for today: you seemed to be very ambitious to make your confidential tx writeup understandable for the layman. I personally drop out at (In1 + In2 + In3 + plaintext_input_amount*H...) - (Out1 + Out2 + Out3 + ... fees*H) == 0.
18:50:29	nickler:	Would have rather expected to find a xG somewhere and (In1 + In2 + In3 + plaintext_input_amount)*H
18:51:29	gmaxwell:	nickler: ah. well the values themselves are In1 = blind G + value H hm. not sure how to make that clear, perhaps expand it out.
18:51:46	nickler:	ok that would make sense :D
18:52:07	fluffypony:	zooko: Table 1 is incorrect - Monero (and I think CryptoNote coins) mask the amount, unless you have a magic way of telling which outputs are change outputs
18:52:46	zooko:	fluffypony: Hm... :-/
18:53:14	gmaxwell:	fluffypony: I don't think that change uncertant really is enough to qualify there.
18:53:36	gmaxwell:	(I'd missed that the table mentioned cryptonote)
18:53:36	fluffypony:	fair enough
18:53:41	nickler:	what's OWAS?
18:53:53	kanzure:	one-way aggregate signatures
18:53:59	nickler:	thx
18:54:16	gmaxwell:	nickler: one way aggreatble signatures. Clever trick using aggregate signatures to get you something that works like a whole block level coinjoin which is non-interactive.
18:54:44	kanzure:	i was thinking of aggregate signatures for a multisig or coinjoin style payment channel approach, but didn't hash out the details yet
18:55:14	kanzure:	(where i could possibly use those funky history-free aggregate signatures to remove intermediate history)
18:55:19	nickler:	is there a bitcointalk thread about that?
18:55:47	gmaxwell:	for a while, for the privacy feature for elements/alpha I'd wanted to do monero RS + OWAS, but then the prospect of reduced sized range proofs started looking pretty attractive instead.
18:56:08	gmaxwell:	nickler: on OWAS? https://bitcointalk.org/index.php?topic=290971.0
18:56:27	nickler:	ah perfect
18:57:27	kanzure:	i think you could remove intermediate history if you could communicate with the original transaction signer to sign a different transaction instead
18:57:54	gmaxwell:	kanzure: well that sounds like the coinswap transform.
18:58:38	kanzure:	i want something like "bob sends 10,000 transactions to 10k hapless users, then each user sends 1k transactions to 1k other hapless users, and then bob's software rewrites his transactions so that the 1k transactions at the end are the only ones that get committed to the blockchain"
18:58:51	kanzure:	(or whatever the numbers work out to)
18:59:28	nsh:	loss of information is sufficient [just harder to guarantee]. equivocal histories requires more interaction
18:59:39	gmaxwell:	coinswap works by applying a general transformation to an atomic cross chain swap. The general transformation makes any two party contract indistinguishable from a 2 of 2 multisig (assuming the players cooperate).
19:00:07	gmaxwell:	(and where schnorr signatures are available, 2 of 2 easily looks just like 1 of 1)
19:00:55	nsh:	'The notion of compressing all the signatures in a block into a constant size output is very attractive, even if it retains a linear validation cost. The improvement of anonymity could be viewed as a side benefit.' # how is this done in the OWAS proposal?
19:01:17	nsh:	(the pdf link is 404)
19:01:31	nsh:	mirror: https://download.wpsoftware.net/bitcoin/wizardry/horasyuanmouton-owas.pdf
19:02:28	gmaxwell:	nsh: the BLS signatures just have this property where you can aggregate them.
19:02:49	nsh:	* nsh reads: http://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf
19:03:21	nsh:	(A Survey of Two Signature Aggregation Techniques, Boneh, et al.)
19:03:59	nsh:	oh, i see
19:04:06	gmaxwell:	Boneh tells me there is a way to do an efficient batch verification but I didn't see how to make it work with the aggregation (haven't tried to hard). One of the bigger costs in that system (beyond needing the bilinear strong assumption) is that it needs two pairing operations per transaction to verify. If those could be batched out it would be nice.
19:04:20	nsh:	* nsh nods
19:06:38	nsh:	i guess it's not easily possible to use sequential aggregation (weaker / more accepted assumptions) and delegate the strict ordering to miners
19:07:27	nsh:	nope
19:08:30	kanzure:	not sure why 2-of-2 multisig is the goal there?
19:08:45	kanzure:	oh, you were just describing coinswap's mechanism
19:09:06	gmaxwell:	kanzure: hides the contract. network never sees the script, which in an atomic swap breaks privacy.
19:10:33	nsh:	* nsh wonders if it's believed that all GDH groups are bilinear maps
19:10:41	nsh:	or those are just the ones we've found
19:11:17	fluffypony:	http://www.vdiscover.org/OS-fuzzing.html
19:11:19	fluffypony:	.title
19:11:20	yoleaux:	Using Machine Learning to predict the outcome of a zzuf fuzzing campaign
19:13:44	nsh:	(no, 'Consequently, if a group G is a bilinear group then G is also a GDH group. (The converse is probably not true.)')
19:15:17	gmaxwell:	nsh: yea, I expected that. since it's easy to see how you get the DDH test from bilinearity, but I could certatly imagine DDH being possible without bilinearity.
19:15:35	nsh:	* nsh nods
19:18:43	nsh:	is it possible to find/contrive curves of arbitrary bilinear security parameter? or is there some tradeoff between the useful size of the subgroup and the difficulty of the transport
19:20:09	nsh:	* nsh curses pdfs with unreadable-in-linux fonts :/
19:21:28	nsh:	also is the security parameter (alpha) equivalent to the embedding degree, or is that another thing? (latter is used here: http://theory.stanford.edu/~dfreeman/papers/ants-embedding.pdf )
19:21:42	gmaxwell:	nsh: going a little deep into the blackbox for me; there are several different known famlies for getting pairing friendly groups.
19:21:50	nsh:	* nsh nods
19:22:42	nsh:	oh, this says there is a construction for arbitrary degree, but it seems ~6-8 is commensurate with 2^160 bit ECC security
19:22:45	nsh:	so it may be academic
19:23:04	gmaxwell:	nsh: for security you want the CDH to be hard on both sides, so if your smaller group is size x then you need some k such that x*k is as strong a size for integer discrete log as x is.
19:23:13	nsh:	right
19:24:17	gmaxwell:	since e(G,P) = e(G,xG) = e(G,G)^x if you can solve the discrete log in the transfer....
19:24:44	gmaxwell:	(should have said and if you can...)
19:24:57	nsh:	* nsh nods
19:25:39	gmaxwell:	lots of handwave thoug that the special structure doesn't make things easier than expected.
19:26:31	nsh:	right
19:26:44	nsh:	i am apprehensive when i see the phrase "infinite family of [such] curves"
19:26:49	nsh:	because that's a lot of potential pathology
19:31:06	hulkhogan_:	quick q, if, when sending messages to a mix, the mix encrypts and sends to either A)another mix or B)the final destination are there any vulnerabilities that are easy to spot in this config?
19:31:49	hulkhogan_:	need to note, if passing through to another mix, its not re-encrypted
19:32:12	hulkhogan_:	the encryption is to the final destination's public key
19:33:17	hulkhogan_:	verification happens at the final destination, and since messages are batched, ddos shouldn't be an issue
19:34:17	gmaxwell:	hulkhogan_: hm? whats the 'mix encrypts' for? do you just mean transport level encryption?
19:34:44	gmaxwell:	the normal constructions for mixnets are with nested messages where each inner layer is encrypted to the next hop.
19:35:04	gmaxwell:	keep in mind that if the goal is to thwart traffic analysis (it is!) it may be important to make all messages constant size.
19:35:07	hulkhogan_:	yea i think so... in this case thats basically the use, and so the inner mixes dont receive any information about the transactions being passed through
19:35:14	hulkhogan_:	thats a good point...
19:36:14	hulkhogan_:	yeah, well the thinking is - expose a webservice to take in new transactions (Accessible via tor for privacy), those get handed to either another mix or the final node, we dont want to leak information if we are going over 1-hop, so we encrypt until the final dest
19:37:17	hulkhogan_:	you can think of it as three webservices, one to handle relay/broadcast, one that sits infront of the node for handling encryption/other necessary things, and perhaps a status webservice to get information on avaible mixes..
19:38:24	hulkhogan_:	i havent thought it all the way through, there may not be a need to have additional mixes, for example
19:38:30	gmaxwell:	it really should be tor reachable only, otherwise some idiots will reach it over the plain web (even if just accidentally) and then there will be big incentives to monitor the entry. :)
19:39:07	gmaxwell:	well a single hop doesn't provide any privacy (beyond the use of tor to reach it) from the operator of it.
19:39:46	hulkhogan_:	well, what if you're at a coffeeshop and want to submit with privacy? i think ip masquing tricks (vpn, coffeeshop) allow for some level of privacy, we shouldn't throw away those users, is my pov here
19:40:57	hulkhogan_:	ack, perhaps i need to do more reading..
19:42:55	nsh:	.title https://www.youtube.com/watch?v=oEmcKBLu8pg
19:42:55	yoleaux:	On the Cryptographic Hardness of Finding a Nash Equilibrium - YouTube
19:44:47	gmaxwell:	hulkhogan_: hm, tor should work from the coffeeshop. :)
19:45:07	hulkhogan_:	yea very true
19:45:24	hulkhogan_:	well it sounds like this should be set up as a hidden service, possibly
19:45:40	nsh:	(it's debatable whether anything should be set up as anything other than hidden service)
19:46:31	hulkhogan_:	well, originally i was thinking it was ok to expose a service/webpage accessible over tor, for IP masquing reasons
19:46:56	hulkhogan_:	so visiting the site over tor would not allow the service to id you via IP
19:47:27	gmaxwell:	yea, I wouldn't have done anything other than a hidden service, otherwise it's just too interesting to attack. Some idiot would start using it without tor and then getting traffic data from the site is suddenly very interesting.
19:47:30	hulkhogan_:	there are a lot of other ID leaks if you use a browser, so perhaps hidden service is best..
19:47:49	nsh:	* nsh nods
19:48:10	nsh:	"if your laptop can't find it, then neither can the market"
19:48:38	nsh:	(would be nice to have the converse of this unlearned from a few people)
19:51:11	hulkhogan_:	heh, privacy is tough /goes to think more
19:52:15	hulkhogan_:	i think having a check on the user-agent to ensure you use tor-browser would be important
19:52:28	hulkhogan_:	so then you get the assurance of tor + tor-browser to eliminate fingerprinting
19:54:11	gmaxwell:	using a plain socket and a uniform client is far far far less attack surface than even tor browser.
19:54:44	hulkhogan_:	although i dont know how to answer this, 'what makes this scheme better than starting tor and submitting transactions over socks to various block explorers that support pushing txs'
19:55:23	kanzure:	which ones support that
19:55:28	kanzure:	other than bci?
19:56:14	hulkhogan_:	a few, blockr?, coinbelly?
19:56:29	gmaxwell:	hulkhogan_: because the server would protect the user from traffic analysis.
19:56:54	gmaxwell:	by making private the amount of data sent and the timing.
19:57:02	gmaxwell:	(perhaps go read up on what mixmaster does!)
19:57:08	kanzure:	.wik mixmaster
19:57:08	yoleaux:	kanzure: Sorry, that command (.wik) crashed.
19:57:12	kanzure:	gah
19:57:14	nsh:	(bah)
19:57:28	nsh:	.wik Mixmaster anonymous remailer
19:57:28	yoleaux:	nsh: Sorry, that command (.wik) crashed.
19:57:36	kanzure:	perhaps this is related to their https rollout
19:58:00	nsh:	"Mixmaster is a Type II anonymous remailer which sends messages in fixed-size packets and reorders them, preventing anyone watching the messages go in and out of remailers from tracing them." - https://en.wikipedia.org/wiki/Mixmaster_anonymous_remailer
19:58:24	nsh:	( https://en.wikipedia.org/wiki/Mix_network#How_it_works )
19:58:36	hulkhogan_:	yea i have one of the comparsion papers kanzure posted ready to be read... it was helping, i should finish that first probably
20:54:01	isis:	a vpn will give you privacy, which isn't at all like anonymity. however, a vpn will also fail open, along with other various disaster modes within the design, making it an excellent footshotgun if you actually care about privacy or anonymity
20:57:10	isis:	gmaxwell is correct that a single hop of encryption for the tx isn't going to do anything w.r.t. privacy/anonymity. you actually do need a bare minimum of three, otherwise there are way too many attacks upon the mix network which become excessively easy… like path bias attacks with only two hops in between the client and the destination would be brutal.
20:59:44	hulkhogan_:	the designs changed a bit since then... using a hidden service protects against snooping the client/dest, the rest of the components would sit behind that in another network
21:00:28	hulkhogan_:	i think originally i had pseudoanonymity as the goal, reading more, i have tweaked the model towards anonymity a bit more
21:00:44	gmaxwell:	the whole thougth there was that tor gets you many advantages (including a bigger anonymity set) but not traffic analysis resistance, something riding inside tor can give traffic analysis resistance.
21:02:24	hulkhogan_:	i was just too concerned with accessibilty not considering the endgoal in mind
21:02:30	isis:	pseudonymity == anonymity, i.e. how can you have multiple (unlinked) identities without being able to have unlinked identities?
21:03:31	isis:	they are not exactly the same, but for purposes of designing a mixnet, they do go hand in hand, since an attack on one is usually an attack on the other
21:04:06	hulkhogan_:	isis: can you cite a reference? i'd be interested to read more
21:05:18	isis:	oh god, if i have a paper for that, it's going to be so old… but i'll look
21:06:38	hulkhogan_:	np
21:07:03	hulkhogan_:	but i think keeping things off clearnet, only hosting over hidden services eliminate 90% of the concerns earlier
21:07:47	hulkhogan_:	other concerns like sybil/ddos mostly something the software needs to handle using pow or uptime schemes, not sure
21:15:07	isis:	http://freehaven.net/anonbib/cache/terminology.pdf http://freehaven.net/anonbib/bibtex.html#terminology
21:16:26	nsh:	23hr ago -- https://www.youtube.com/watch?v=HZlIRr6Xwe8
21:16:28	nsh:	.title
21:16:28	yoleaux:	How to use Bitcoin to Enhance Secure Computation - YouTube
21:17:27	nsh:	How to Use Bitcoin to Incentivize Correct Computations -- http://people.csail.mit.edu/ranjit/papers/incentives.pdf
21:17:39	nsh:	How to Use Bitcoin to Design Fair Protocols -- https://eprint.iacr.org/2014/129.pdf
21:20:16	isis:	the lagginess of hidden services might be viewed in a more glass-half-full manner as providing builtin (D)DoS resistance :)
21:21:10	isis:	https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt describes the upcoming changes to hidden services, for those interested in building future systems on top of them
21:21:47	gmaxwell:	isis: did it ever gain some hashcash like DOS mitigation (not sure if you're aware but there is a proposal for TLS to support doing that)
21:25:44	isis:	we haven't added overt DOS mitigation yet… there have been a few rather fragile bugs which are fixed in the new design which should provide what you could call increased DOS mitigation/rate limiting, but other than that, no.
21:28:00	isis:	gmaxwell: the hashcash DOS mitigation, that means just the actual proof-of-work system, correct? or did hashcash have an additional mechanism?
21:40:14	gmaxwell:	thats all
21:41:39	hulkhogan_:	isis: thanks for sharing that terminology piece, its very helpful in decoding some of the stuff i was reading earlier
21:42:24	Luke-Jr:	gavinandresen: BIP16 vs 17 was a different situation IMO: both proposals were reasonable, and everyone agreed we needed one of them
21:51:36	Giszmo:	sudo npm install -g cordova
21:52:49	Giszmo:	(oops. wrong chat :/ )
22:23:17	waxwing:	andytoshi: i got my py script to verify a sig out of the tests.c :)
22:23:27	nsh:	\o/
23:14:20	eennaam:	eennaam has left #bitcoin-wizards
23:36:05	nsh:	.t https://www.youtube.com/watch?v=2L25KE61a4w
23:36:05	yoleaux:	nsh: Sorry, I don't know a timezone by that name.
23:36:09	nsh:	.title
23:36:09	yoleaux:	Provably Secure Blockchain Protocols and Applications to Secure Computation - YouTube
23:41:48	nsh:	--
23:41:48	nsh:	We overview recent and ongoing work investigating blockchain protocols from a provable security perspective. We discuss properties such as common prefix and chain quality and introduce proof techniques for establishing such properties in a synchronous anonymous communication model assuming bounded access to a random oracle. We discuss the consensus problem in this setting and its relation to robust transaction ledgers. We also introduce a new model and
23:41:48	nsh:	a construction for secure computation with fairness and output delivery guarantees that are conditional on a global transaction ledger.
23:41:49	nsh:	--
23:48:34	kanzure:	was this the yahoo group
23:59:26	nsh:	(Aggelos Kiayias, University of Athens)