00:14:53	c0rw1n:	c0rw1n is now known as c0rw|sleep
00:35:15	AlexStraunoff:	AlexStraunoff is now known as stqism
03:20:23	bramc:	I'm working on a less-technical post about the current goings-on. It's making me really, really mad.
04:05:50	bramc:	My prediction the other day of the end result of this being that gavin and mheard leaving bitcoin development is looking more and more likely.
04:06:57	justanotherusr:	why do you think that?
04:11:25	bramc:	justanotherusr, Because they're making it come to that https://twitter.com/petertoddbtc/status/611368079117942786
04:12:26	justanotherusr:	it looks like hearn is just stirring up the pot to me
04:13:34	justanotherusr:	In that same interview he said if miners don't support >1MB blocks he might delegate a central authority to keep consensus
04:13:47	justanotherusr:	split consensus I should say
04:14:01	bramc:	There's stirring the pot, and there's being hellbent on cramming disastrous ideas down everybody else's throats
04:14:08	bramc:	justanotherusr, That's... also an awful idea
04:16:01	justanotherusr:	I don't really know what to say other than that his camp accepting centralization wouldn't be that surprising https://youtu.be/DB9goUDBAR0?t=122
04:18:02	bramc:	Yeah, umm, he's crazy
04:20:40	bramc:	The stupid thing is that the supposed crisis which this is all supposedly meant to avert isn't even a real crisis.
04:20:55	bramc:	Transaction fees might rise above two cents! The sky is falling!
04:21:49	jcorgan:	suggesting the nuclear option suggests that there is no further common basis for negotiation
04:43:05	leakypat:	it's been eye opening his whole episode
04:52:36	bramc:	mhearn's fixation on zeroconf was always bizarre, but this is just unglued.
05:16:14	petertodd:	bramc: the conf I just got back from on blockchain tech was full of financey types looking to use bitcoin for various purposes - e.g. cross-border settlement - who were dumbfounded at how much people were caring at tx fees
05:16:44	bramc:	petertodd, Transaction fees might climb above two cents! The sky is falling!
05:17:11	petertodd:	bramc: e.g. one quote was basically "tx fees going up to levels that we can't afford would basically mean fiat is dead"
05:17:21	petertodd:	bramc: (and they knew damn well about the 1MB limit)
05:17:27	justanotherusr:	justanotherusr is now known as {`0__0`}
05:17:42	bramc:	petertodd, Nobody eats there any more. It's too crowded.
05:17:50	petertodd:	yup!
05:19:16	leakypat:	Exactly
05:19:18	petertodd:	equally, it's pretty easy to explain to people why tx fees matter, and we can't rely on the inflation subsidy - at least when those people are looking at things like eris that would only use the bitcoin blockchain for last-resort global consensus
05:19:46	leakypat:	"Bitcoin transaction fees rise on demand for blockchain space"
05:21:00	petertodd:	speaking of, anyone looked at replace-by-fee lately? I'm getting nervous because no-one is finding any bugs :P
05:40:18	bramc:	I wonder how much of gavin and mike's increasing arrogance is driven by thinking they have the chinese miners in their pocket (not like miners have that kind of power anyway)
05:40:22	{`0__0`}:	{`0__0`} is now known as justanotheruser
05:40:36	bramc:	petertodd, What are the latest replace by fee acceptance heuristics?
05:41:46	petertodd:	bramc: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08122.html
05:41:48	bramc:	Not allowing any new outputs to be added or have their value increased is 'conservative', although at this point I'm feeling like 'fuck zeroconf. Really. Fuck it.'
05:42:28	petertodd:	bramc: well, I've written both; I have reasonably firm commitment to implement the conservative option at a reasonably large pool so long as the code can pass peer review
05:43:24	bramc:	Much as it sounds interesting to work on, I'm not up on the bitcoin codebase and that looks like a serious time sink
05:43:38	petertodd:	haha, yeah, I can't blame you there
05:43:45	petertodd:	though, it's a good way to learn! :P
05:43:48	bramc:	The biggest potential issues have to do with introducing a transaction which pays x, then x+e, then x+2e, x+3e, etc.
05:44:01	petertodd:	how so?
05:44:20	petertodd:	oh, you mean e as in epsilon?
05:44:22	bramc:	It's a way to get the network to waste lots of bandwidth
05:44:26	bramc:	Yeah, e is epsilon
05:44:47	petertodd:	it makes sure you pay at least as much in increased fees as the min relay fee, so you're just as better off spamming normal txs
05:45:19	bramc:	It seems like transaction size should be included in there somewhere
05:45:38	petertodd:	it is! min relay fee is calculated as feerate * tx size
05:45:48	bramc:	oh good
05:46:40	bramc:	There's also potential issues where an attacker gets around that minimum by bumping two transactions back and forth out of the pool
05:47:17	petertodd:	how would that work?
05:47:18	the_last:	petertodd: Why not just increase the blocksize to say, 4mb. To postpone all of these issues until Lightning Network is complete?
05:47:59	petertodd:	the_last: if all you're doing is a small 4x increase, why bother with all that work and risk?
05:48:13	bramc:	Like, I give you a large transaction which just barely makes it in, then another one which pays epsilon more which bumps that one out, then another one which pays out of the first input which gives another epsilon and pushes that second one out, etc.
05:48:49	bramc:	Obviously this is dicey to do in practice, but worth considering
05:48:59	the_last:	petertodd: Prevent the necessary rise of txn fees in the mean time and allowance for low-value txns to continue on the network unimpaired?
05:49:34	bramc:	the_last, What does that accomplish?
05:50:30	the_last:	bramc: I'm sure there are companies out there that utilize the blockchain like that (if not, there will be), it would allow them to stay in business.
05:50:39	petertodd:	bramc: well, it has to pay epsilon = tx_{i+1}_size * min-relay-fee, so at every replacement you're paying for bandwidth roughly speaking (assuming at least one of them will get mined)
05:51:14	bramc:	petertodd, No there's a loophole: You're using your new transaction to bump out your old transaction, thus saving yourself money
05:52:48	petertodd:	bramc: nope, the new tx has to pay at least as much in total fees as the old one, as well as for it's own bandwidth
05:53:51	bramc:	petertodd, I'm not sure where our disconnect is here. My point is that the old transaction will get pushed out, so I don't have to pay for the bandwidth to send it out after all
05:54:57	bramc:	Say I create a 500k transaction which just barely makes it, wait for it to go everywhere, then make another 500k transaction which just barely bumps out the old one, wait for it to go over the whole network, make a new one, etc.
05:55:54	bramc:	If the amount of time it takes for these transactions to propagate is short enough I'll have succeeded in sending out a lot of them before a block is minted, and I only have to pay the fee on the last one because the others don't make it
05:56:28	bramc:	If I'm bouncing back and forth between two inputs I don't even run the risk of having to pay more than double in the end
05:56:50	bramc:	I'm feeling very collegial today, sort of like this: https://www.youtube.com/watch?v=mvTCr5Z-0lA
05:57:30	justanotheruser:	bramc: what do you mean by "just barely" bumps out the old one?
05:57:34	petertodd:	ok, so tx1 will pay 500k * min_fee_rate in fees, and tx2 will pay (500k * min_fee_rate) + (500k * min_fee_rate) in fees
05:57:49	petertodd:	if tx2 pays less it gets rejected
05:58:08	petertodd:	replace-by-fee is *not* a mechanism to make mempools come to consensus, just a mechanism to replace transactions
05:58:14	bramc:	petertodd, Wait, so transactions which get introduced sooner have a big advantage? that seems unfair
05:58:44	bramc:	petertodd, To be clear, I'm talking about transactions with different inputs, so they aren't replace by fee, they're bump out the other one
05:58:46	petertodd:	bramc: what does "unfair" have to do with it?
05:59:05	bramc:	Maybe this sort of attack is already possible on the existing deployed network
05:59:16	petertodd:	bramc: the purpose is to be able to replace one transaction with another - there's no "fair" involved as both txs are (basically always) created by the same person
05:59:40	petertodd:	yeah, you've always been able to send multiple txs at once that are mutually incompatible
06:00:31	bramc:	okay, so let's say the attack I'm talking about doesn't even hit the replace by fee codepath. Is there any defense against it in the replace by fee or existing logic?
06:00:55	petertodd:	no, nor can there be - that's just a standard zeroconf doublespend
06:01:12	bramc:	I'm not communicating a critical point here
06:01:21	bramc:	Let's say I have two coins, A and B
06:01:54	bramc:	I introduce a huge transaction to spend A, then bump it out with another huge transaction to spend B
06:02:13	petertodd:	right
06:02:15	bramc:	At this point, will peers forget about the first transaction completely or simply stop relaying it?
06:02:27	petertodd:	yeah, they forget about tx #1
06:03:11	bramc:	So then even if there is no replace by fee logic, I can create a new transaction which spends A which pays epsilon more in fees and use it to bump out the existing spend of B, which will cause everybody to forget about the transaction which spends B...
06:03:12	petertodd:	(and actually, you have to have *three* coins, because you need a conflict)
06:03:36	bramc:	Let's say that my transactions are greater than 500k, so any two of them will conflict
06:03:37	petertodd:	no, w/o replace-by-fee the first tx that spends a given output is the one that is kept
06:03:54	petertodd:	also, max standard tx is 100k - larger than that won't get relayed
06:04:22	bramc:	But the first transaction was forgotten completely! The double-spend logic won't even notice that it's a replacement
06:04:38	bramc:	Also I can use ten 100k transactions, that doesn't fundamentally change the attack
06:05:03	petertodd:	wait, double-spend logic? what double-spend logic exactly?
06:05:44	petertodd:	and again, without replace-by-fee, transactions don't get removed from the mempool, except by being mined, or double-spent by a tx in a mined block
06:06:12	bramc:	In the existing deployed logic, if I get a transaction to spend A, then another transaction to spend A, I ignore the second one. But, if the first transaction got completely bumped out I'll have forgotten about it, so I'll accept a new one
06:06:25	petertodd:	right
06:06:29	bramc:	Didn't you just say that if a transaction gets bumped out because its fee is too low it will get forgotten completely?
06:07:04	petertodd:	so, if I have outputs A, B, C, I can create tx1 that spends A,C, replace it with tx2 that spends B,C, and then broadcast tx3 that spends just A
06:07:12	petertodd:	what's the exploit exactly?
06:08:00	bramc:	Oh that's a different kind of bumping out than I was thinking, I was thinking of things getting bumped out because the 1meg limit has been hit
06:08:09	bramc:	So there's no C. Let me think about using C.
06:08:20	petertodd:	nah, the mempool knows nothing about the blocksize limit, indeed, the mempool is unlimited in size...
06:08:43	bramc:	I think your logic will stop the bumping out due to using C just fine
06:09:14	bramc:	Requiring it step up by a full min relay fee seems a bit hash. Maybe half would be good
06:09:22	bramc:	harsh I mean, not hash
06:09:50	bramc:	Ah, so you keep whatever transactions you get but you don't relay them if their fees aren't high enough?
06:10:09	petertodd:	actually, there's potential issues re: block propagation where the min relay fee might be too low to account for the tx's signatures not being in the sigcache of other nodes
06:10:22	petertodd:	no, txs that aren't re-relayed aren't kept
06:15:23	bramc:	So say a new block happens, and you have transactions locally which are for inputs which are still unspent, what do you do with them?
06:15:51	petertodd:	they stay in the mempool; the mempool is only changed by txs either getting mined or double-spent
06:18:48	Adlai:	(or by having the process restarted!)
06:21:07	justanotheruser:	petertodd: I assume the possibility of transactions spending different sets of inputs with different fees leading to a transaction replacing cycle being created has been considered?
06:22:01	petertodd:	justanotheruser: yup! that is allowed, but the cycle will eventually end due to the rule that fees must always increase on every replacment
06:22:46	justanotheruser:	petertodd: oh, so even if a 100kb tx is being replaced by 100 1kb transactions, all the 1kb transactions individually must have a greater fee than the 100kb transaction?
06:22:55	petertodd:	yes!
06:23:15	petertodd:	sure, you could try to do better, but that's a rare case so no sense adding complex code to handle it
06:23:30	bramc:	petertodd, How do peers prevent you from making them run out of memory by stuffing them full of extremely low fee transactions?
06:23:40	petertodd:	bramc: they don't
06:23:44	petertodd:	bramc: long-standing bug
06:24:08	bramc:	Come to think of it, you couldn't stuff them full of more than the utxo set's worth of data, which isn't all *that* big
06:24:57	petertodd:	well... a GB of mempool space requires $2.5k worth of btc
06:25:04	petertodd:	the attack *is* possible
06:26:16	bramc:	How are you getting that value?
06:26:33	petertodd:	work out the minimum relay fee/KB * 1GB * exchange rate
06:26:41	petertodd:	10uBTC/Kb
06:26:44	petertodd:	*KB
06:27:29	bramc:	Isn't the minimum relay fee set based on the other fees being offered, essentially zero if there's less than 1meg worth of transactions total?
06:27:38	petertodd:	nope! it's hard-coded
06:28:36	bramc:	Is it already hard-coded or is this new with your new logic?
06:28:45	petertodd:	it's always been hard-coded
06:30:27	bramc:	What's the current minimum transaction fee on a standard size transaction?
06:31:00	petertodd:	10uBTC/KB * 0.2KB or something - it's purely a $/KB calculation
06:31:26	petertodd:	anyway, go read the code, it'd do you some good :) AcceptToMemory
06:31:34	petertodd:	*AcceptToMemoryPool() is the relevant function
06:31:43	petertodd:	bbl later, bedtime
06:31:47	bramc:	Good night
06:44:05	bramc:	petertodd, It would take a few weeks of making new utxos to get a gigabyte's worth
06:54:42	the_last:	https://blockchain.info/charts/n-transactions?timespan=all&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=
06:57:12	leakypat:	the_last: and?
07:03:40	bramc:	the_last, hitting the transaction rate limit isn't a disaster, it just means transaction rates go up
07:15:35	the_last:	bramc: and when the cost of the transaction outweighs its purpose?
07:16:01	bramc:	the_last, transaction fees won't exceed the value people are getting out of them
07:16:16	bramc:	Because if it did, they wouldn't pay it :-P
07:16:25	the_last:	we won't ever see fees above, say, $1?
07:17:22	the_last:	i mean, for microtransactions even something like a 20cent fee would be expensive, a 20cent fee for a $1 burger for example
07:18:35	mountaingoat:	minimum bound on tx fee is the cost of mining + margin to make it worth it for a miner (excluding current subsidy), upper bound is whatever people are willing to pay to get their tx into a block faster
07:19:04	mountaingoat:	otherwise it's a free market, at least in theory, and most people would probably pay market rate the_last
07:19:26	bramc:	the_last, microtransactions directly on the block chain are a bad idea. There are proposals for enabling microtransactions, most promisingly lightning network, but trying to cram them into the block chain itself is not happening from both a transaction fee and a time to close standpoint
07:21:45	the_last:	i see, thanks
07:21:49	mountaingoat:	trying to keep zero fee txs ad infinitum because block reward subsidy exists is just putting off the necessary migration to a fee market, which i wish would happen sooner than later. of course part of the debate is probably a question of when is the right time, iiuc
07:22:40	moa:	hey bramc
07:23:20	bramc:	mountaingoat, More than one core developer has expressed a desire to temporarily and artificially have miners lower the limit to make sure that everything can handle real transaction fees and be able to let it go back up again to the real limit in case there's a serious problem. That of course isn't happening in the current political climate.
07:23:34	bramc:	Yes moa?
07:23:36	moa:	what do you think about btc payment channels in a tit-for-tat for bittorrent bandwidth model?
07:24:09	moa:	btc metered torrenting
07:26:04	bramc:	moa, bandwidth value doesn't work that way. It isn't a commodity.
07:26:17	moa:	big pipes are valuable
07:26:26	mountaingoat:	bramc: limit of free transactions per block??
07:26:45	mountaingoat:	-?
07:27:11	bramc:	You can't take bandwidth and stick it on a shelf to use later. You can only offload uploading onto peers who also have the content
07:27:39	bramc:	mountaingoat, meaning, have some fraction of miners continue to accept 1meg blocks, but only generate 500k blocks themselves
07:28:03	bramc:	That way you can test the limit-hitting logic now and not be totally fucked if it fails
07:28:11	mountaingoat:	ok, i see
07:29:24	moa:	interesting take
07:49:06	fluffypony:	moa: you mean like justusranvier's proposal?
07:50:50	fluffypony:	this one: https://bitcoinism.liberty.me/economic-fallacies-and-the-block-size-limit-part-2-price-discovery/
07:54:50	moa:	yeah, kind of ... but he only ever proposes things
07:55:31	moa:	would be better if he was implementing to get direct feedback for his concepts i think
07:56:11	moa:	icbw
08:04:52	fluffypony:	I think the cost of implementing a scheme that doesn't have broad-base support can be exceedingly high for individuals
08:05:16	orwell.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:16	orwell.freenode.net:	Users on #bitcoin-wizards: andy-logbot wallet42 arubi_ c-cex-yuriy n0n0_ AaronvanW gill3s dEBRUYNE antanst b_lumenkraft mengine moa priidu SDCDev fanquake the_last mjerr jgarzik TheSeven koshii goregrind bramc p15 Dr-G2 GAit _whitelogger mkarrer go1111111 d1ggy nessence justanotheruser jmcn PRab sparetire_ heath mm_1 dasource spinza superobserver MrTratta paveljanik grubles kyuupichan Logicwax badmofo catlasshrugged_ execut3 Starduster_ Burrito triazo LeMiner Adlai
08:05:16	orwell.freenode.net:	Users on #bitcoin-wizards: yoleaux Relos pollux-bts Cory [d__d] Tiraspol ebfull rustyn luny devrandom stqism ThinThread jouke Tebbo` melvster dc17523be3 cluckj Emcy SubCreative Madars helo sl01 jrayhawk grandmaster OneFixt tromp_ alferz dgenr8 hashtag_ c0rw|sleep tucenaber sneak gielbier sadoshi andytoshi hulkhogan_ MoALTz maaku jcorgan sparetire bosma sundance bsm117532 CodeShark copumpkin K1773R ttttemp cryptowest_ gwillen waxwing lclc STRML akstunt600 kanzure
08:05:16	orwell.freenode.net:	Users on #bitcoin-wizards: midnightmagic @Luke-Jr Iriez fenn bliljerk101 gnusha bedeho wizkid057 akrmn mariorz mikolalysenko Meeh Krellan ajweiss so BrainOverfl0w @ChanServ AdrianG Anduck BlueMatt starsoccer d9b4bef9 gribble ryan-c indolering Graet jaromil [ace] merlincorey morcos roasbeef eric sdaftuar warren nanotube guruvan SwedFTP afdudley richardus petertodd dignork xabbix Jaamg Fistful_of_Coins throughnothing_ mr_burdell Eliel optimator BananaLotus binaryatrocity
08:05:16	orwell.freenode.net:	Users on #bitcoin-wizards: Zouppen crescend1 TD-Linux warptangent azariah coryfields cfields epscy leakypat jonasschnelli nsh larraboj brand0 scoria harrigan isis ggreer cdecker nickler gavinandresen kinlo stevenroose comboy veox espes huseby jessepollak davout stonecoldpat qawap harrow berndj rasengan nephyrin sturles pigeons weex Keefe otoburb thrasher` narwh4l lmatteis smooth null_radix Taek theymos forrestv iddo Alanius EasyAt wumpus wiz Apocalyptic a5m0 mountaingoat
08:05:16	orwell.freenode.net:	Users on #bitcoin-wizards: livegnik fluffypony amiller yorick phantomcircuit jbenet platinuum kumavis runeks Muis artifexd mappum CryptoGoon yrashk adams__ vonzipper prosodyContext Xzibit17 btcdrak catcow tromp dansmith_btc HM lnovy poggy elastoma s1w cornusammonis
08:05:17	orwell.freenode.net:	[freenode-info] if you're at a conference and other people are having trouble connecting, please mention it to staff: http://freenode.net/faq.shtml#gettinghelp
08:05:47	moa:	yep
08:25:25	bramc:	Well, I've now written almost 2000 words of vitriol for a post about the subject at hand. Will finish it up and send it off for review tomorrow.
08:28:12	mountaingoat:	has anybody written about the known milestones of scalability left for bitcoin and what the plan as the project is to achieve them?
08:29:00	mountaingoat:	i'd imagine the tx fee market is one of them, but i wonder what else i don't know about that. i'm also sure there's plenty that wouldn't be known until they're encountered in the wild.
08:29:18	mountaingoat:	-that
08:30:43	phantomcircuit:	mountaingoat, improving algorithmic scaling
08:31:09	phantomcircuit:	which means implementing net settlement systems which use bitcoin
08:31:27	mountaingoat:	i'm not sure i follow ... what's net settlement?
08:32:26	phantomcircuit:	mountaingoat, you pay me 1BTC i pay you 2BTC but instead of doing both i simply send you 1BTC
08:32:49	leakypat:	mountaingoat: eg. Performing 1000s of small transactions off the blockchain and then netting them out and settling on chain in a single transaction
08:32:49	phantomcircuit:	that's what micropayment channels and lightning do
08:32:57	mountaingoat:	ah right
08:34:18	mountaingoat:	yeah, that would seem important to adapting rate to the bitcoin blockchain
08:34:26	bramc:	It's interesting how quickly core devs have come around to seeing lightning network as the future.
08:34:59	bramc:	The lack of any other serious proposals is probably a big part of it...
08:35:35	leakypat:	bramc from my understanding it would need a lot of things to happen to make it work
08:35:57	phantomcircuit:	bramc, lightning is an extension of micropayment channel hubs
08:36:11	bramc:	leakypat, Depends what you mean by 'a lot'. None of them are crazy.
08:36:18	phantomcircuit:	micropayment channels in general have been widely understood to be the solution to scaling bitcoin
08:36:26	phantomcircuit:	for years now
08:36:34	leakypat:	Even if all the coding is done and it is up and running . It still needs to get enough usage that I can route a payment via existing channels etc.
08:36:39	leakypat:	(I think)
08:37:01	antanst:	antanst has left #bitcoin-wizards
08:37:20	bramc:	phantomcircuit, Fair enough, one can say that lightning network is the finishing details on the concept of micropayment channels
08:37:37	phantomcircuit:	bramc, as interesting as lightning is i feel pretty confident that even better approaches are not only possible but will come out relatively quickly given actual scaling pressure
08:37:48	phantomcircuit:	at present there is no real pressure
08:37:50	bramc:	leakypat, There needs to be an ecosystem of payment intermediaries, but the requirements on how they're set up for the whole thing to work is actually quite loose
08:38:00	leakypat:	Eg. I don't have a channel open with company x, but company x does with User y and I do with user y
08:38:11	leakypat:	I have to be able to find a path for my payment
08:38:15	bramc:	phantomcircuit, What deficiencies in lightning would you like to see addressed?
08:38:25	bramc:	leakypat, Yeah it supports that
08:39:25	bramc:	Much larger systems have already been made to work in the wild. BGP, for example.
08:40:09	bramc:	Well, it's way past my bed-time. Today's bitcoin-induced aneurysm is over. Good night everybody.
08:40:21	phantomcircuit:	bramc, nobody has yet come up with a mechanism to do net netting
08:40:48	bramc:	phantomcircuit, lightning supports that just fine
08:40:49	phantomcircuit:	bramc, in other words it would be nice if the settlement could be safely delayed if both parties agreed
08:41:02	phantomcircuit:	bramc, no you have to close out the channel eventually
08:41:25	bramc:	phantomcircuit, No you only have to close out the channel if the balance goes past the deposit amounts
08:43:08	phantomcircuit:	bramc, i suspect that in general it wont make a huge difference either way
08:43:32	phantomcircuit:	most channels will simply go one direction
09:28:41	moa:	moa has left #bitcoin-wizards
13:54:46	c0rw|sleep:	c0rw|sleep is now known as c0rw1n
14:43:40	c0rw1n:	c0rw1n is now known as c0rw|afk
15:05:21	LeMiner2:	LeMiner2 is now known as LeMiner
15:37:03	hearn:	theymos: did you seriously suggest earlier attempting to break the DNS seeds in order to fuck with bitcoinj based wallets? *eyepop*
15:37:54	hearn:	(not just bitcoinj. other spv wallets too)
16:25:30	theymos:	hearn: I didn't suggest breaking them, and not to cause havoc/DoS. I suggested causing them to return only nodes on the correct side of any hardfork, to prevent SPV nodes from blindly going along with a hardfork even if it's supported by miners.
16:27:10	jcorgan:	such illustrative differences in demeanor
16:31:04	bramc:	That's rich. Hearn just accused someone of trying to 'wreck havoc' for making a proposal to try to contain some of the havoc created by his own proposal.
16:34:38	shaul:	shaul has left #bitcoin-wizards
16:36:10	shaul:	shaul has left #bitcoin-wizards
16:58:36	nsh:	(i pointed out this would happen to kanzure yesterday when he made a similar suggestion. it's not diplomatic to attempt to preempt a failure of consensus update process by proposing a similarly non-bilateral countermeasure. this raises temperature/anxieties and doesn't tend towards amicable resolution)
17:05:02	bramc:	nsh, The possibility of an amicable resolution seems to have already been precluded
17:05:17	nsh:	* nsh is an optimist
17:05:25	nsh:	and assumes good faith :)
17:07:11	GAit:	theymos: i think they shouldn't be implemented until there is code distributed that is preprogrammed to attemp a contentious hard fork, as for discussing possible countermeasures that could be taken in the contentious situation i think it's fair game, hearn loves to discuss hypoteticals and extreme situations in his interviews and talks
17:09:34	theymos:	It wouldn't be a bad idea in general for DNS seeds to try and check that peers they recommend are real full nodes that are properly handling blocks. Currently they do only a few basic checks, and could probably be fooled by Sybil attacks.
17:11:45	GAit:	theymos: sure but it would be quite hard to detect PseudoNode
17:12:04	GAit:	well, maybe not, i don't know how
17:12:14	GAit:	timings and things like that seem flaky
17:12:41	theymos:	Yeah. Though Tor directory authorities face similar problems, and they've done basically OK.
19:20:49	bramc:	This is some Fidel Castro shit right here: http://sourceforge.net/p/bitcoin/mailman/message/34220412/
19:21:24	bramc:	I gave a rousing speech and the people agreed with me! Clearly the rough consensus says I'm right!
19:22:24	bramc:	The reality is that there is a rough consensus. The rough consensus says he's wrong.
19:23:16	petertodd:	theymos: until we get DNS seeds to be authenticated with a way to prove they gave you bad results, I'd argue we should go the other way and have them periodically return lies for robustness
19:28:54	gavinandresen:	bramc : if you have specific technical objections to raising the max block size, I'd love to hear them (via email) if I haven't already addressed them in a gavinandresen.ninja blog post.
19:29:09	gavinandresen:	bramc : discussion about governance of Bitcoin Core probably belongs in #bitcoin-dev
19:29:31	gavinandresen:	... and discussion of bitcoin in general probably belongs in #bitcoin
19:30:35	bramc:	gavinandresen, You're going to cause a fork. It will not be a simple change. There will be two separate currencies. And it will be a disaster.
19:31:04	bramc:	gavinandresen, And the problem you're claiming to solve isn't even a problem. Transaction fees might go above two cents! The sky is falling1
19:36:30	temujin:	please fork bitcoin so i can buy during the panic low
19:40:19	bramc:	Everybody, basic question here: is bip100 a hard fork or not?
19:40:41	tromp_:	absolutely
19:41:34	bramc:	I thought it was a formal writeup of this: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07937.html
19:43:05	tromp_:	it (http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf) mentions "hard fork" 12 times
19:43:47	bramc:	Ugh
19:43:50	bramc:	*headdesk*
19:43:54	tromp_:	"Schedule the hard fork on bitcoin main chain for January 11, 2016. "
19:45:10	tromp_:	looks like a reasonable proposal to me
19:48:05	tromp_:	although the miner voting process adds rather a lot of complexity
19:49:48	tromp_:	compared to, say, doubling every 2 years until it reaches 32MB
19:50:18	tromp_:	in which case the miners can still self-impose lower soft-limits
19:54:20	kanzure:	bramc: i think it's interesting that he thought you were talking about max-block-size.
19:54:28	kanzure:	bramc: clearly there's miscommunication going on here :-)
19:59:27	fluffypony:	kanzure: I liked your most recent email
19:59:29	fluffypony:	<3
20:02:03	fluffypony:	fluffypony is now known as o1he
20:03:57	o1he:	o1he is now known as fluffypony
20:50:35	kanzure:	fluffypony: much of this is similar to mission integrity in projects that require as-safe-as-possible random number generators
21:02:42	amiller:	anyone looked at this "spacecoin" paper http://eprint.iacr.org/2015/528
21:05:58	nsh:	heh
21:12:39	amiller:	some things it doesn't address: how it's any "greener"... if you spend $80 million dollars on hard drives i dont see how that's any better for the environment than $80 million on asics and power
21:14:02	ThinThread:	how do i find out exactly when the fork will happen
21:14:27	ThinThread:	bitcoin node outputs "Hard fork detected" ?
21:16:32	kanzure:	hard-forks are not always detectable
21:19:04	kanzure:	amiller: oh no :-( "Our solution to this problem is based on penalizing miners who try to work on more than one branch of the chain."
21:19:10	kanzure:	amiller: it's really weird how nobody reads -wizards logs
21:19:31	rusty:	rusty has left #bitcoin-wizards
21:22:11	kanzure:	also it seems to assume that miners don't use unique keys?
21:23:20	kanzure:	being able to steal rewards from the past is problematic because it might mean a 10k-deep fork, then all the coinbase transactions are stolen later, thus disrupting the .. hrm.
21:27:52	fluffypony:	lol
21:28:08	kanzure:	it's sort of a proof withholding attack
21:28:17	kanzure:	in addition to all the regular forms of attacks that have been previously discussed
21:31:56	bramc:	amiller, If done properly, proofs of disk can work off the already existent unused disk out there, so the ROI on buying new equipment to do mining would be negative
21:32:39	bramc:	From the abstract, it appears that the authors have independently reinvented at least some of the ideas I've come up with, although it looks like they're missing some critical points. I'll have to read through it to have a more informed opinion.
21:34:15	gmaxwell:	I was talking to Michael Hamburg (from curves @ modern crypto) and he has a neat method to efficiently factor out the cofactor on twisted edwards curves with cofactor 4 like ed448-goldilocks (but not 8 like ed25519). So you can get a prime order group using the construction.
21:34:35	bramc:	gmaxwell, What is that construction for?
21:35:06	bramc:	gmaxwell, You've made some comments about objective metrics on the optimal size of the block chain seemingly indicating that the current limit is too big. What are those metrics?
21:38:00	bramc:	Oh yech, the spacecoin paper is using pebbling graphs. The straightforward approach is so much easier. Also they don't seem to have figured out the trick of interleaving proofs of time.
21:38:34	gmaxwell:	bramc: there are a couple of negative indicators, node counts, business outsouring of processing instead of running nodes, number of VPS offerings that you can even run a node on, hashpower behavior-- explicitly and intentionally consolidating to reduce orhpaning (esp pre-matt's relay network) (also things like miners disabling signature checking, though that may be a fluke). I wrote a better li
21:38:40	gmaxwell:	st someplace I'll go look in a bit.
21:40:14	bramc:	by 'consolidating to reduce orphaning' do you mean miners including fewer transactions because the value they get in transaction fees is worth less than the risk that they'll get orphaned?
21:40:54	Sub|afk:	Sub|afk is now known as SubCreative
21:41:04	bramc:	Businesses not running nodes is weird. It would be really nice if wallets ran full nodes themselves.
21:41:14	gmaxwell:	bramc: wrt construction, people sometimes use EC curves where the group formed doesn't have prime order (ed25519 is one example). You generally need to assure that your points are in a particular subgroup. For things like ECDH this is easy (make your keys a multiple of the cofactor) and not of grave consequence if you get it wrong. For fancier ZK protocols like ZK auth/password based kdf or thin
21:41:20	gmaxwell:	gs like range proofs it's both harder to assure you're in the right subgroup and more important (as which subgroup you are in leaks data)
21:41:32	kanzure:	bramc: businesses are often campaigned by certain other businesses that "develoeprs find it hard to use bitcoin core" etc
21:42:26	helo:	you pretty much need a programmer that understands the fundamentals well to integrate with it
21:42:38	helo:	vs a service like bitpay that works like paypal
21:43:05	gmaxwell:	bramc: it's hard to sort out whats a accident of market dynamics vs a fundimental.
21:43:07	helo:	(i think that is the problem more than the block size or hardware requirements to run a full node)
21:43:27	bramc:	gmaxwell, Why not use a group of prime order? My recollection of the discussion of ed255 vs. secpk is that ed255 doesn't have odd order and the most recent secpk code is roughly comparable in performance.
21:44:05	bramc:	It could be that a lot of businesses just don't like running servers
21:44:06	gmaxwell:	E.g. yes, it would be much healthier if wallets on high power systems always became (pruned) fullnodes in the background; but the software doesn't exist for that currently. So the fact that this hasn't happened may have nothing to do with the blocksize (though obviously it cannot happen for blocksize over _some_ threshold)
21:45:25	gmaxwell:	bramc: yes, thats one reason I like secp256k1-- that it has prime order. Though for curves where this projection trick works, may be just as good. (and perhaps better in some other ways).
21:45:40	leakypat:	Are you referring to desktop wallets like armory or wallet services with central servers?
21:46:15	bramc:	gmaxwell, In a very immediate practical sense not breaking heirarchical wallets is a good thing
21:47:21	gmaxwell:	leakypat: desktop wallets. WRT centeral servers; well that might be some kind of indicator regarding blocksize too but it's really hard to sort out the varrious effects.
21:48:08	bramc:	Ideally even mobile wallets would be full nodes
21:49:00	ajweiss:	i've played with running pruned nodes on fairly beefy android phones before
21:50:00	lmatteis:	to decentralize mining again, was it ever considered to embed P2pool sort of technology inside bitcoin core?
21:50:01	ajweiss:	it works, but practicality is tbd... also this is with zero optimizations or tweaks
21:50:31	gmaxwell:	ajweiss: I believe luke was running bitcoin core on his nokia 810 at one point in the past. :P
21:50:34	bramc:	ajweiss, moore's law is on our side, as long as the size of the block chain doesn't go up :-P
21:50:58	ajweiss:	the problem is battery life and catching up
21:51:10	gmaxwell:	bramc: I think mobile wallets could quite plausably be the kind of fraud proofed full security lite nodes that we can't currently do in Bitcoin.
21:51:40	gmaxwell:	e.g. where it's mostly not checking things except a bit at random, but it can accept and verify proofs hat a block is bad and then reject it.
21:51:42	ajweiss:	it made me wonder if maybe running your own trusted and authenticated nodes that your thin clients can talk to would make more sense
21:51:48	bramc:	gmaxwell, What do you mean by 'can't'?
21:52:32	gmaxwell:	see checklist: https://en.bitcoin.it/wiki/User:Gmaxwell/features#Proofs (I think that list was missing something but I forget; anyways it makes the point)
21:53:23	ajweiss:	the whole blockchaindataforyou.com vs. running your own node in a business might be solved by some dead simple and well marketed APIs for verifying things that could be used in tandem with the commercial service
21:53:31	gmaxwell:	part of the difficulty there is that the extra commitments are expensive to maintain (IO cost wise for full nodes)
21:54:34	gmaxwell:	ajweiss: so I've heard from some commercial service offerings that offer an API which also can talk to a local full node that very-few of their users use it, even with nagging.
21:54:36	helo:	using your home computer/connection to host services for your mobile phone should really be a thing in general...
21:54:47	helo:	but it really is not
21:55:05	gmaxwell:	helo: I have friends at https://sandstorm.io/ that woudl agree...
21:55:50	ajweiss:	that's been a longrunning dream
21:55:52	helo:	dyndns + vpn would be close
21:56:21	gmaxwell:	helo: what the sandstorm stuff does is creates a generic sandbox where you can 'app market' like install common webapps and they're all isolated from each other.
21:57:00	gmaxwell:	but who knows thats a movement bigger than bitcoin; though its not unimportant.
21:57:17	bramc:	Very few companies run their own email servers either
21:57:32	bramc:	The fraction of all email currently controlled by google is quite alarming.
21:57:49	ajweiss:	afaik there's no FOSS alternative that's even close yet
21:58:07	Eliel:	email takes a crapload of administration effort that doesn't really increase with the number of users that much.
21:58:21	gmaxwell:	bramc: even if you run your own and you're happy, google and hotmail will randomly blacklist you.
21:58:42	Eliel:	yes, part of it is randomly getting blacklisted :P
21:58:59	bramc:	gmaxwell, I've been unhappy even with hosted services for the most part
21:59:08	ajweiss:	and the ongoing spam saga is pretty annoying... especially since it seems most of the development moved from oss to services
21:59:11	gmaxwell:	This has been a basically constant problem for several orgs I know about that self host mail on coloed servers. (e.g. wikimedia, creative commons).
21:59:35	helo:	google hosting or... use gmail directly -.-
21:59:59	gmaxwell:	Of course, for personal mail its almost crazy to use a personal service if you care at all about privacy, since in the US we have crazy legal perspective that you have no expectation of privacy for mail stored by third parties, and so virtually no legal protection for it.
22:00:16	bramc:	I just use gmail, because the alternatives are a joke. I hope that microsoft gets their offering to be reasonably comparable.
22:00:30	bramc:	Anyway, the point is that the trend towards centralization is very strong and difficult to counter
22:00:53	Tiraspol:	https://protonmail.ch/
22:00:55	gmaxwell:	Centeralization has inherent efficiencies, as well has incentives simplicity.
22:01:13	zooko:	I use gmail. It spam-filters mail from Jeff Garzik and Mark S. Miller to me. Always.
22:01:19	zooko:	Which I think is hilarious.
22:01:24	ajweiss:	Our email service safeguards user data with strict privacy protections and our secure datacenter facility hidden inside a Swiss granite mountain.
22:01:56	ajweiss:	zooko: just on list, or in general?
22:02:01	gmaxwell:	in general.
22:02:40	gmaxwell:	of course every one of us who uses gmail creates pressure on those people to use it too... due to screwups like that.
22:02:59	bramc:	One of the few places where centralization is all awful is bandwidth. Hence BitTorrent.
22:03:01	ajweiss:	weird. that should happen on list because they're using DMARC and the list is breaking the signature... why individual mail would break makes no sense to me...
22:03:03	gmaxwell:	(nevermind that these people are in my address book and I've emailed them before... to the spamcan with them!)
22:03:46	Eliel:	I think a lot more companies would run bitcoin core if you could run one bitcoind and then have several wallets on different systems that all use the bitcoin core for their operation. if bitcoin core was zeroconf (and worked instantly) and wallet configuration only needed the ip-address/domain to the bitcoin core.
22:03:50	bramc:	I've only rarely had spam filtering problems lately, but this is mostly due to hardly using email at all.
22:04:17	bramc:	Eliel, zeroconf is busted
22:05:16	gmaxwell:	Eliel: yea wallet/backend seperation would be nice; I've wanted that for a long time. There is motion in a direction which should eventually admit that... but there are so many fires burning.
22:05:21	helo:	Eliel: that will probably be possible in a few more releases... i think the wallet is moving further and further from bitcoin core center stage, at least
22:05:57	helo:	then it may be pretty simple to point your various wallets at one node at home
22:06:00	gmaxwell:	helo: dunno about that; wallet in bitcoin core had no one working on it for some time, though thats not true anymore.
22:06:41	fluffypony:	that's the architecture we have
22:06:48	helo:	hopefully we'll be close in a year
22:06:49	fluffypony:	complete separation between wallet and daemon
22:06:53	Eliel:	(I'm working on a WIP bitcoinj based wallet software that's partially compatible with bitcoin core wallet RPC.)
22:07:24	fluffypony:	but then it used RPC, which is messy, so we're moving to 0MQ (pub-sub over the IPC->TCP transport)
22:08:48	gmaxwell:	fluffypony: yea that seemed like an obviously better design. (not true of everything in monero, but I'm glad it learned something from bitcoin's mistakes! :) )
22:09:47	fluffypony:	we're still having to go through the same pain as you guys with delicately pulling consensus-critical stuff out into a library of its own, though, so there's that
22:09:59	Eliel:	the main problem with bitcoin core is that while running it on one server is ok, it's very much not ok if it quadruples the resource requirements for every server you need a wallet on.
22:10:45	fluffypony:	Eliel: the "quick fix" is to only allow one node on the network external access, and force the rest of the nodes to peer with each other
22:10:54	fluffypony:	then the resources are all eternal
22:14:55	kanzure:	could some clarify; is monero using zeromq?
22:16:01	Eliel:	fluffypony: if bitcoin core had SPV mode, then it'd be usable in that sort of setup.
22:16:07	fluffypony:	kanzure: not merged into master yet
22:16:16	kanzure:	fluffypony: waiting on bitcoin to merge zeromq stuff..?
22:16:27	fluffypony:	lol no
22:16:31	kanzure:	k
22:16:36	fluffypony:	https://github.com/oranjuice/bitmonero
22:16:54	fluffypony:	still some calls that haven't been completed
22:17:16	fluffypony:	so PR soon (tm)
22:19:13	gmaxwell:	Eliel: some of the resorces requirement stuff is just stupid. there is no particular reason for it to be so resource hungry now. The fact that you can't run it in basic tier VPSes has been a huge issue.