01:22:18	PRab_:	PRab_ is now known as PRab
03:02:44	kanzure:	19:49 kanzure: somewhat emberassing, but the only one here with a copy of Greg's slides is greg, and he's currently presenting them
03:02:47	kanzure:	19:49 we'd like to post them to #bitcoin-wizards
03:02:54	kanzure:	https://people.xiph.org/~greg/blockstream.gmaxwell.elements.talk.060815.pdf
03:11:32	Taek:	It would be interesting for the first proof-of-concept sidechain to have 20mb blocks
03:12:35	sipa:	Taek: its performance characteristics are very different from Bitcoin's; it wouldn't offer a useful comparison
03:13:37	Taek:	I am misunderstanding something then. (slide 10/34). I thought sidechains were essentially alternate blockchains that used the bitcoin currency
03:13:53	sipa:	they are
03:14:39	Taek:	if it's nearly an exact fork, why would the performance characteristics be 'very different'?
03:14:39	sipa:	but Elements Alpha (which Greg is presenting) has very different validation rules than Bitcoin itself, so things like propagation/validation time, and cost for running a full node are not comparable to Bitcoin
03:14:56	gwillen:	Taek: a sidechain won't have the same volume of users, miners, transactions, etc. as bitcoin itself
03:15:16	gwillen:	so the performance characteristics won't necessarily be similar
03:16:51	Taek:	gwillen: that is true, but it would relieve political pressure I believe. Perhaps it wouldn't. sipa: hadn't gotten that far, is EA the cryptosystem greg mentioned earlier this week?
03:19:08	sipa:	yes
03:20:52	sipa:	Taek: how would it relieve political pressure?
03:21:44	Taek:	currently, many people believe that the only way Bitcoin is going to survive is by increasing the block size to 20mb. With a sidechain implementation that's identical to bitcoin, they can move their coins to a blockchain with more room without forking the original network.
03:22:43	Taek:	if recognizing this new chain just requires a client update by the merchants, it's no more difficult to implement than a hardfork
03:22:49	sipa:	Taek: that's in no way a better solution than just increasing Bitcoin's block size
03:22:50	Taek:	(*for the merchants)
03:23:25	Taek:	sipa: it leaves the old 1mb chain intact, not everybody has to switch to the new chain if they don't like the consequences
03:23:29	sipa:	If people expect that resulting sidechain to be actually usable, ~everyone will need to validate it just the same as they have to validate Bitcoin, and it comes at a huge security cost.
03:23:56	Taek:	merchants could choose to only accept the 1mb coins
03:24:27	sipa:	and they'll lose every customer
03:24:28	Taek:	it also would not seem so difficult for merchants to accept both, then users who prefer the 1mb could keep using their 1mb coins
03:24:54	sipa:	I agree it has significantly lower risk, but massive security trade-off.
03:25:25	sipa:	our purpose with sidechains is unlocking experimentation with new technology
03:25:33	sipa:	it's not a substitute for a stable main chain
03:26:22	Taek:	security tradeoff as in mining security, or another type of security?
03:26:36	sipa:	sidechains transfer only has SPV security
03:27:50	maaku:	A pre-recorded version of Greg's talk : https://s3-us-west-1.amazonaws.com/blkstrm/video/elements-gmaxwell.mp4
03:28:16	Taek:	I grok
03:29:12	Taek:	Using homorphic encryption to hide transfer amounts is very interesting
03:30:19	moa:	elements has implemented homomorphic encryption?
03:30:27	sipa:	Yup.
03:30:31	moa:	!!! wut
03:30:32	gribble:	Error: "!!" is not a valid command.
03:30:49	Taek:	(wait this is all implemented???)
03:30:50	moa:	yous guise been busy
03:30:56	sipa:	Taek: yes
03:31:04	Taek:	wow! congrats
03:31:45	sipa:	I'm not sure homomorphic encryption is the correct term, though. But yes, EA has a feature called Confidential Transactions, which blind the amounts transferred, while retaining cryptographic proofs that the values add up.
03:32:23	sipa:	Downside: ~kilobytes per output, and significantly slower to validate
03:33:31	sipa:	These don't go into the UTXO set, though.
03:34:45	moa:	makes sense
03:35:25	gwillen:	it's not fully-homomorphic, but it allows homomorphic addition of values
03:35:33	gwillen:	so you can add blinded values and get blinded results
03:36:47	sipa:	ironically, the hardest part of confidential values is guaranteeing that no negative amounts were used
03:37:18	moa:	yeah I got that partial homomorphic ... but good enough for what we want to do, nice job
03:38:46	moa:	sipa: why's that, the negative sign bit handling?
03:39:24	sipa:	moa: because you could cancel out things (have a 1 BTC inputs, and a 3 BTC + -2 BTC output... and never reveal the -2 BTC one)
03:39:45	sipa:	https://github.com/ElementsProject/elements
03:39:49	sipa:	source code public :)
03:41:45	Taek:	so, the idea is to test new concepts in a sidechain, and then potentially implement them in the main chain after they've been battle-hardened in a less-critical economy?
03:42:57	moa:	sipa: so elements is a fork of Core it looks like, does the depends build work?
03:43:22	sipa:	moa: unlikely
03:51:19	moa:	Euclids elements?
03:59:47	maaku:	Taek: maybe, in the very very long term
03:59:50	maaku:	for now, experiment
04:00:21	maaku:	moa: frankly a lot of the integration is alpha quality
04:00:22	maaku:	(groan)
04:00:35	moa:	it built fine here
04:00:42	moa:	not sure what I built though :)
04:01:02	maaku:	well i hope it does build! but if 'make check' works it's because we commented out a bunch of tests ;)
04:01:15	maaku:	this isn't a polished product. it is an opening up of development into an open source project that we hope will be larger than ourselves
04:01:30	moa:	yeah i see that
04:01:34	maaku:	moa: there should be a readme in the root directory
04:02:21	morcos:	at what point is it forked from Core? 0.10?
04:02:27	moa:	so there is a chain running on port 18332?
04:02:49	maaku:	morcos: somewhere between 0.10 and 0.11. getting it rebased to 0.11 is a near-term thing to do
04:03:19	maaku:	moa that's testnet3's rpc port, which the alpha sidechain connects to to perform verification
04:03:28	moa:	ah ok
04:03:36	maaku:	alpha p2p port is 4242, rpc port 4241
04:03:46	moa:	how is testnet3 significantly different to testnet?
04:03:57	maaku:	moa it is bitcoin testnet
04:04:13	maaku:	bitcoin testnet has been reset twice in the past, the current version is 3
04:07:12	morcos:	this looks like a lot of fantastic work. congratulations guys! i look forward to diving in when i can get back in front of a computer.
05:12:57	kanzure:	transcript http://diyhpl.us/wiki/transcripts/gmaxwell-sidechains-elements/
05:16:43	nsh:	ty kanzure
05:18:21	Luke-Jr:	kanzure: do you have a transcript of the live one too that we can diff? <.<
05:24:31	kanzure:	Luke-Jr: i was not in the audience
05:24:49	kanzure:	also, for future reference, if you can get him to speak more like BlueMatt, it's way easier on my hands
05:25:12	kanzure:	really- this was practically effortless to type by comparison http://diyhpl.us/wiki/transcripts/mit-bitcoin-expo-2015/matt-corallo-sidechains/
05:27:10	Luke-Jr:	kanzure: in what way? (not that I have much influence on how gmaxwell speaks :p)
05:27:36	kanzure:	i have no idea, i wish i knew
05:27:45	kanzure:	also, rpcblockchainexplorer links are still broken https://alpha-explorer.elementsproject.org/block/8e7533b7dff7879809dc246d7166e52f8c35437de9e081da0e1a122e161b3e60
05:28:28	amiller:	is there a clear figure on what's the size of these transactions?
05:31:09	kanzure:	amiller: in the transcript search for "kilobytes"
05:31:38	amiller:	"2.5 kilobytes"
05:32:08	kanzure:	well, for zero-knowledge range proofs
05:51:18	sipa:	amiller: the ouputs need a range proof, which is several kilobytes in size, depending on the log of the number of possible range values
05:51:34	sipa:	amiller: 2.5 kb for 32-bit
05:52:02	amiller:	i see.... i guess it could go down very low if i only want to like, hide my most significant few bits or something
05:52:11	sipa:	indeed
05:54:40	sipa:	the implementation supports up to 64-bit, though there is a consensus limit to 52 bits
05:54:47	Luke-Jr:	kanzure: unfortunately, I've no clue how that is supposed to be setup; I think warren would be the one to poke
05:55:18	sipa:	indeed, it is known to be broken currently
05:55:52	kanzure:	well let me know if you have any errors and i can look at those if you post them in the issue tracker
05:55:59	kanzure:	* kanzure proceeds to sleep with one eye open
05:56:08	frankenmint:	frankenmint has left #bitcoin-wizards
05:56:22	sipa:	amiller: also, 80% of the range proof data size can be used as private communication channel between sender and receiver
05:58:12	amiller:	sipa, i missed that part.... so even with a 32-bit range is the on-chain proof size is 2.5kb or less?
05:58:38	sipa:	the on-chain proof for 32-bit is 2.5 kn
05:58:40	sipa:	kb
05:59:00	sipa:	2kb of which can be used to transfer information from sender to recwiver, though
06:00:08	sipa:	(you'll need to ask gmaxwell for details here, i don't know how that works)
07:14:45	gmaxwell:	amiller: yes, the size is 2 + 8 (or 0 if no minimum value) + ceil(n/8) + 5*n*32 bytes where n is the number of digits in base-4 for the mantissa of the rangeproof (if the number of bits isn't a multiple of 2, the last digit is in base two and takes 3*32 instead of 5*32)).
07:15:32	gmaxwell:	The size of the mantissa is selectable in one bit increments, and there is a seperate exponent that scales the hidden part by 10^x for x in 0..18, as well as an optional minimum value that moves the zero point.
07:15:44	gmaxwell:	I have a longer description, lemme see if its posted yet.
07:16:30	gmaxwell:	ah okay, they're here: https://people.xiph.org/~greg/confidential_values.txt
07:18:46	fluffypony:	gmaxwell: really cool work :)
07:22:51	gmaxwell:	here is the underlying crypto code, if you want to look at it without disentangling it from the elements-alpha sidechain code: https://github.com/ElementsProject/secp256k1-zkp/commit/bd067945ead3b514fba884abd0de95fc4b5db9ae
07:22:57	petertodd:	gmaxwell: +1 (though hopefully it actually works!)
07:23:39	gmaxwell:	petertodd: well, bugs are always possible. But the cryptographic construction itself is fairly boring, as such things go.
07:24:20	gmaxwell:	I wouldn't consider it production ready, though it has had ~some~ level of review and about a cpu-year of fuzz testing.
07:24:48	petertodd:	gmaxwell: just need to figure out a way for people to steal lots of money by breaking it... :/
07:25:04	gmaxwell:	Done.
07:25:21	gmaxwell:	(I mean, use it with non-testnet coins and you have that)
07:25:41	petertodd:	hehe, yup
07:26:15	gmaxwell:	Perhaps I've snowed myself with the nice layering, but at least it decomposes into nice subsystems that you can analyize independantly.
07:27:54	gmaxwell:	Also, wrt development, basically the amount of over-design is inversely proportional to how high in the stack it is. E.g. the ring signature is quite carefully reviewed (at least as much as something new can be), while the bitcoin integration is... well. There are chunks of code that have probably never been run, and maybe only reviewed a bit by the person who wrote them. :P
07:28:42	petertodd:	which is fine, given that the pool of people who can review it goes up the higher the stack you go :)
07:29:34	gmaxwell:	In any case, matt, pieter, and luke should all understand the integration fairly well and should be able to answer questions on it as well as I can (or likely better)
07:30:10	petertodd:	I'm going to find some time to go through all the changes in Elements sooner or later
08:03:55	gmaxwell:	amiller: also if you run across anyone claiming to have a plain ECDL-assumptions range proof with efficiency better than 2.5 elements per bit, I'd love to see it. Lit on this seems kinda fragmented because the earliest schemes were not formally published; there are lots of papers on schemes with efficiency worse than that even with bilinear crypto. There are schemes for groups of unknown order
08:04:01	gmaxwell:	(e.g. usually trusted setup) which are super elegant and pretty efficient for /very/ big numbers.
08:04:16	gmaxwell:	fluffypony: thanks!
08:05:15	barjavel.freenode.net:	topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
08:05:15	barjavel.freenode.net:	Users on #bitcoin-wizards: andy-logbot AaronvanW mjerr catcow btcdrak Xzibit17 pollux-bts prosodyContext dabos vonzipper adams__ damethos michagogo priidu hktud0 dasource yrashk mariorz Mably gill3s CryptoGoon mappum ThomasV_ mikolalysenko CryptOprah artifexd mkarrer Muis runeks kumavis platinuum jbenet shesek SubCreative antanst catlasshrugged_ fenn NewLiberty bliljerk101 Guest53541 [7] phantomcircuit p15_ Madars sipa Emcy dc17523be3 Dr-G yorick PRab moa d1ggy
08:05:15	barjavel.freenode.net:	Users on #bitcoin-wizards: tucenaber_ jmcn gielbier mm_1 hashtagg_ waxwing sparetire_ melvster spinza tromp_ Iriez Pan0ram1x sneak go1111111 justanotheruser Adlai sadoshi gwillen amiller cryptowest_ fluffypony livegnik PaulCapestany mountaingoat Jouke a5m0 Apocalyptic triazo wiz wumpus ebfull EasyAt Alanius heath iddo maaku koshii Starduster Luke-Jr HM MoALTz bedeho2 ttttemp forrestv theymos ircLuigi rustyn kyuupichan Taek hashtag_ zmachine AlexStraunoff luny
08:05:16	barjavel.freenode.net:	Users on #bitcoin-wizards: midnightmagic antgreen copumpkin Tiraspol akrmn null_radix helo smooth grandmaster lmatteis robogoat narwh4l thrasher` c0rw|zZz elastoma gmaxwell otoburb Keefe weex pigeons sturles nephyrin dgenr8 [d__d] rasengan berndj harrow akstunt600 metamarc STRML qawap lclc mengine superobserver wizkid057 stonecoldpat Meeh davout jessepollak huseby espes GreenIsMyPepper Logicwax CodeShark veox lnovy yoleaux comboy stevenroose kinlo sl01 gavinandresen
08:05:16	barjavel.freenode.net:	Users on #bitcoin-wizards: nickler cdecker jrayhawk K1773R ggreer Hunger- isis bsm117532 harrigan andytoshi scoria brand0 larraboj OneFixt gnusha nsh jonasschnelli leakypat epscy lmacken cfields Krellan coryfields kanzure azariah warptangent TD-Linux crescend1 Zouppen _whitelogger binaryatrocity BananaLotus optimator Eliel mr_burdell throughnothing_ Fistful_of_Coins Jaamg xabbix dignork poggy petertodd richardus afdudley SwedFTP guruvan ajweiss nanotube warren
08:05:16	barjavel.freenode.net:	Users on #bitcoin-wizards: BrainOverfl0w @ChanServ AdrianG Anduck BlueMatt starsoccer d9b4bef9 gribble ryan-c indolering Graet jaromil [ace] merlincorey morcos roasbeef eric sdaftuar
08:05:22	gmaxwell:	also, anyone get it running yet? There is a faucet with coins already on the sidechain.
08:05:41	c0rw|zZz:	c0rw|zZz is now known as c0rw1n
08:08:55	amiller:	gmaxwell, the borromean thing was great, i dont suppose you have a writeup in equal detail, like in between the confidential_values.txt and the code?
08:09:02	gmaxwell:	amiller: not yet.
08:09:13	amiller:	i want to look at the floating point algorithm really carefully
08:10:07	gmaxwell:	amiller: the borromean thing started off morely like that txt, and with illustrations like https://people.xiph.org/~greg/sign.svg and andytoshi made it awesome. Not quite there yet.
08:10:22	amiller:	ok, i understand :)
08:11:20	gmaxwell:	amiller: the decimal float works quite simply though; normaly the basis thats proved is 0 or 1; 0 or 2; 0 or 4 ... (well technically 0,1,2,3 0,4,8,12...) when the exponent is 1 instead the basis is 0/10 0/20 0/40...
08:12:13	amiller:	hm
08:12:22	gmaxwell:	and so on for higher exponents. There is actually a way to make the exponents somewhat priviate (you only make their differences public when you combine them; though I don't implement that; as it has a base level of inefficiency (have to carry around a blinded exp) that makes it seem like not a win.
08:15:16	gmaxwell:	The 'cute' optimizations in my system are this: use of base 4 OR instead of base 2, which takes the cost from 3 elements a bit to 5 for two bits. Elimination of the commitment for the last digit by reconstructing it from the value being proved and all the other bits .... and the "proof rewind" that lets someone sharing the provers coins recover a message sent by the prover 80% of the size of t
08:15:22	gmaxwell:	he proof.
08:15:33	gmaxwell:	the things like the variable mantissa size and exponent are more pedesterian.
08:18:04	gmaxwell:	Taek: phantomcircuit was joking that we should reduce the block size to 999999 bytes just to double emphasize that this thing isn't currently a scaling expirement.
11:23:26	Taek:	gmaxwell: I'm not sure where I got the idea, but I had been under the impression that sidechains were set up as a migration tool
11:23:51	Taek:	you would make sidechains, and then if people liked them they would move their coins over and just use that chain instead of the original chain
11:24:00	Taek:	I'm not the only one who had/has that idea
11:24:19	sipa:	Taek: the idea of sidechains grew indeed from the question of a safe upgrade mechanism
11:24:33	sipa:	and they can be used for that
11:24:42	gmaxwell:	Taek: Thats a possible mode, one we mention in the whitepaper; and it was the original motivation for adam proposing the one-way peg.
11:27:47	Taek:	[23:25:44] our purpose with sidechains is unlocking experimentation with new technology
11:27:48	Taek:	[23:25:52] it's not a substitute for a stable main chain
11:27:48	Taek:	these statements had confused me
12:00:17	c0rw1n:	c0rw1n is now known as c0rw|afk
12:58:19	waxwing:	so in Confidential, it looks to me from a read through, that people will probably still want/need coinjoin like approaches to anonymise the transaction graph, right?
12:58:37	waxwing:	or is there some plan to implement ring sigs in a side chain for actual txs?
12:59:07	waxwing:	one could see a lot of scenarios where just blinding the amounts might not be good enough
13:01:17	andytoshi:	waxwing: coinjoin becomes much more powerful; yeah, there is still a motivation for it to avoid people determining the shape of the transaction graph
13:01:38	andytoshi:	but there is a big benefit just from having amounts hidden; a lot of stuff in http://www.coindesk.com/merge-avoidance-privacy-bitcoin/ is blocked for example
13:02:39	andytoshi:	as for ringsigs, they break pruning and would require a lot of design work .. i'd like to see them but i don't think there are concrete plans for them (tho if we found some asymptotically more efficient ringsig scheme maybe we'd change our minds)
13:04:56	waxwing:	break pruning, yes. it would be interesting to hear what some big institutions' reactions are to "we can provide confidentiality of amounts, but the utxos are still traceable". what i always find difficult is that coinjoin is already there, so it's a bit weird trying to figure out what you're actually trying to do there.
13:06:32	gmaxwell:	waxwing: coinjoin is quite weak in practice and annoying to use (so it isn't used more universally) due to the amount non-privacy.
13:07:26	waxwing:	i see; so you envision that this is the main confidentiality feature (amounts) and coinjoin is just kind of there if anyone is motivated to do it.
13:07:42	gmaxwell:	Also, realize that we have a very weird way of looking at this in bitcoin: Transaction graph privacy is metadata privacy; indeed metadata privacy is important, but its fundimentally harder than content privacy (often impossible to be completely metadata private), and often less valuable than content privacy.
13:08:19	gmaxwell:	I think both would be used, it's specifically design to work with coinjoin (and the rpc interfaces in elements should be all setup for someone to build a coinjoiner on top)
13:08:39	gmaxwell:	but at the same time, I do think that value privacy is more important generally.
13:08:49	waxwing:	btw thanks for the write up. my brain nearly melted but i think i finally understood how you prove the commitment to zero :)
13:09:03	gmaxwell:	! HURRAY!
13:09:03	gribble:	Error: "HURRAY!" is not a valid command.
13:09:38	fluffypony:	lol gribble
13:09:55	waxwing:	grumpy gribble
13:09:55	fluffypony:	¡ olé !
13:10:11	gmaxwell:	waxwing: I'm overjoyed to hear that; the range proof is a slick trick that I feel like everyone whos into the technical stuff can understand if they care to...
13:21:31	waxwing:	yes, i guess it's the privacy vs anonymity thing again. wrt my "big institutions" question, it's the former they want, not the latter. metadata is not a bad analogy (at least, once you actually have the amount privacy).
13:22:01	MrTratta:	I don't remember who but someone suggested some ncurses based console app that was great to monitor bitcoind, does anyone remember the name? I couldn't find it on github
13:24:31	c0rw|afk:	c0rw|afk is now known as c0rw1n
13:26:13	gmaxwell:	MrTratta: https://github.com/azeteki/bitcoind-ncurses
13:27:27	zooko:	gmaxwell: way to go on releasing Elements!!
13:28:02	gmaxwell:	zooko: thanks!
13:29:04	gmaxwell:	zooko: seen the confidential transaction technical primer I wrote? (it needs a more proper writeup like we did on the new ringsignature, but ... soooo many things to do so little time.)
13:29:15	zooko:	I haven't read it yet.
13:34:36	MrTratta:	gmaxwell, thanks
13:40:29	waxwing:	huh, already a quote from the Blythe Masters company in a WSJ article: "DAH Chief Technology Officer Shaul Kfir said it could be a “very powerful way to protect investors from having to disclose sensitive business information, even while providing complete transparency to regulators.”
13:40:43	waxwing:	that's kind of in line with what we said.
13:44:30	Taek:	It would be useful in employment scenarios too.
13:55:42	kanzure:	https://lists.linuxfoundation.org/mailman/listinfo/sidechains-dev
14:08:15	StephenM347:	gmaxwell: I'm reading over your confidential transactions proposal, nice! In it you have `H = to_point(SHA256(ENCODE(G)))`, which could be interpreted incorrectly (as I did at first) as `SHA256(ENCODE(G))*G`, instead of taking SHA256(ENCODE(G)) as the x coordinate of a new pub key
14:11:20	sipa:	StephenM347: would H = RecoverPoint(x = SHA256(Encode(G)), y = even) be less confusing?
14:12:03	gmaxwell:	StephenM347: damn, you know I was trying there to avoid precisely that misunderstanding.
14:14:07	gmaxwell:	I think in some earler draft I'd tried H.x = SHA256(ENCODE(G)) and that was confusing in some other way. :) I'll try to fix.
14:14:24	StephenM347:	sipa: less confusing, but maybe not clear as it could be. RecoverPoint isn't terminology that I'm well versed with anyway.
14:14:32	gmaxwell:	StephenM347: point for your understanding that you reconized that SHA256(ENCODE(G))*G would be fatally busted.
14:15:03	StephenM347:	gmaxwell: Haha, thanks. I read it and was like, that can't be what he means. Specifying the x in that type of a syntax makes more sense
14:15:32	sipa:	H is defined as the curve point with X coordinate equal to SHA256(G) and corresponding Y coordinate to be on the curve. The important part is that it is exceedingly unlikely that anyone knows the value h such that H = h*G.
14:15:47	kanzure:	win 12
14:15:49	kanzure:	ehrjoiqjeq
14:16:10	gmaxwell:	yea, thats why that misunderstanding is so unfortunate: it's like the one and only way you cannot produce H, almost any other procedure is okay, just not that one! :)
14:21:20	stonecoldpat:	for elements did you guys change the alpha consensus library? (libalphaconsensus) my build keeps failing on it with architecture x86_64, i thought it was me, but i just compiled bitcoin core usign the same ./configure with no problems
14:21:55	stonecoldpat:	with "symbols not found ofr architecture x86_64", the most frustrating error code in the world :(
14:22:23	sipa:	did you try a make clean, or a git clean -dfx (warning: wipes all non-committed files) ?
14:22:58	sipa:	it's forked off 0.10.2 with a few commits from 0.11, but nothing build system related
14:25:30	stonecoldpat:	yeah, tried both (and upgraded brew, re-installed boost etc, upgraded to yosemite too)
14:25:32	kanzure:	hmm.. https://github.com/ElementsProject/elements/compare/bitcoin...alpha
14:26:30	StephenM347:	gmaxwell: it would also be good to check that there is an associated y coordinate for the x coordinate SHA256(ENCODE(G)) (there may be no point with such an x coordinate)
14:28:12	sipa:	StephenM347: if there wasn't, he would have chosen something else than SHA256(G) :)
14:28:21	gmaxwell:	StephenM347: turns out that there is, so long as ENCODE is uncompressed DER. :)
14:28:31	sipa:	gmaxwell: not DER
14:28:49	gmaxwell:	sipa: someday I'll remember the correct name of that encoding.
14:29:04	StephenM347:	Ah, okay, great
14:29:23	stonecoldpat:	http://pastebin.com/GBinzzw0 is the console log when the error happens
14:29:28	gmaxwell:	StephenM347: actually the first two things I tried were not on the curve.
14:29:54	StephenM347:	gmaxwell: interesting, sha256d and hash160?
14:29:57	gmaxwell:	(SHA256(G.x) and SHA256(compressed-seralized-G))
14:30:20	sipa:	gmaxwell: i wonder if it has a name besides "The encoding specified by SEC1v2 in section 2.3.3"
14:30:27	gmaxwell:	no-- wouldn't hae used hash160, too small, would make a non-uniformly distributed X would would perhaps be harmless but seem weird.
14:30:51	StephenM347:	yeah, bad choice with hash160
14:31:00	StephenM347:	bad guess, I mean
14:32:54	StephenM347:	gmaxwell: How can we be sure that `(In1 + In2 + In3 + plaintext_input_amount*H...) - (Out1 + Out2 + Out3 + ... fees*H) == 0.`, won't it just be some multiple of G?
14:33:34	andytoshi:	StephenM347: that first H should be a G right?
14:33:52	andytoshi:	StephenM347: it'll be a multiple of G, specifically 0*G ;)
14:34:04	StephenM347:	andytoshi: I don't think so, copied from source
14:34:11	sipa:	the formula is correct
14:34:42	sipa:	StephenM347: the creator of the transaction must guarantee that all blinding values cancel (i.e., all blinding factors summed in the outputs must equal the sum of blinding factors used in the inputs)
14:34:43	andytoshi:	oh, right, i always get the blinding factor and actual inputs crossed
14:34:59	andytoshi:	i feel like our design is backward with respect to my intuition..
14:35:14	StephenM347:	sipa: oh, that makes sense, so all but one of the blinding factors are chosen randomly
14:35:27	andytoshi:	StephenM347: correct
14:35:29	sipa:	StephenM347: bingo
14:35:48	sipa:	StephenM347: which is why you can't have a transaction with blinded inputs but without blinded outputs
14:46:47	gmaxwell:	gmaxwell is now known as Guest94462
14:47:30	Guest94462:	Guest94462 is now known as gmaxwell
14:47:42	gmaxwell:	StephenM347: "If the author of a transaction takes care in picking their blinding
14:47:45	gmaxwell:	factors so that they add up correctly,"
14:49:11	gmaxwell:	andytoshi: I also wanted to use "G" for the value, but you see it's the value that gets handled in unusual ways.. where as the blinding factor is just treated like a secret key.
14:49:37	gmaxwell:	andytoshi: so for example my H constant time table is setup to only work for 64 bit values and such.
15:01:20	StephenM347:	gmaxwell: I'm really intrigued by the whole homomorphic commitments process. Do you hope/expect that this will be a feature of a side chain that eventually becomes the predominant chain?
15:03:30	gmaxwell:	or another scheme (e.g. more efficent; perhaps unconditionally sound; I'm confident there is room for improvement)
15:11:25	StephenM347:	gmaxwell: If there are many chains, and a merchant wants to receive coins from a customer who uses a different chain, won't it take a long time to transfer the coins back to the main chain and then onto the merchant's preferred chain?
15:11:44	sipa:	StephenM347: atomic swaps
15:12:04	sipa:	they're much faster than the sidechain transfer mechanism
15:12:26	StephenM347:	sipa: hmm, I need to read more on side chains. How much faster?
15:12:43	sipa:	one transaction on each side
15:12:54	sipa:	or 2, i misremember
15:13:27	StephenM347:	Is it possible to do it across a hub and spoke micropayment channel?
15:13:37	StephenM347:	i.e. if I'm a hub that can send and receive on both chains
15:13:44	StephenM347:	could be instant
15:15:13	antanst:	antanst has left #bitcoin-wizards
16:28:24	andytoshi:	gmaxwell: oh, that's a good reason
16:28:54	andytoshi:	i was worried that there was an algebraic reason, which i don't see (and am pretty convinced there is not), that'd make me worried about my understanding of the system :)
16:30:58	gmaxwell:	andytoshi: no, it's just boring engineering reasons.
17:33:20	temujin:	gmaxwell: awesome video on side chain elements, do you guys have a blockstream IRC channel?
17:33:59	gmaxwell:	we have a sidechains irc channel, #sidechains-dev though no public blockstream IRC channel right now.
17:34:21	temujin:	perfect thank you
17:50:20	kanzure:	"There was this wonderful technology invented a few years ago to deal with spam. It's called Hashcash. All these hacky heuristics like block size are just dancing around the problem, and the natural solution is already present in bitcoin: smaller blocks, (down to the point of individual transactions) each mined. Don't relay things that haven't been mined. As spam or transaction levels go up, mining targets for submission go up too. Of ...
17:50:26	kanzure:	... course this is a pretty serious redesign of bitcoin, and I'm not offering a concrete proposal at this time (but have one in the works, and I'd like to see others). I call the parameters of these hacky heuristics "Consensus Threatening Quantities" (CTQs) because changing them induces a hard fork. Bitcoin is full of them (block time, block size, target difficulty, retarget time, etc) and bitcoin would do well to face difficult ...
17:50:32	kanzure:	... redesign questions head on, and remove them entirely. (Proposal to appear...)"
17:50:54	sipa:	I wish him godspeed.
17:51:19	maaku:	there is #blockstream. but for sidechains related stuff please use #sidechains-dev
17:51:41	kanzure:	hmm for some reason i thought the quote was saying something else
17:52:23	kanzure:	i could have sworn i saw a proposal like "all of these quantities should be balanced against proof-of-work difficulty and perhaps also transaction fees"
17:55:04	fluffypony:	just wait for his proposal to include an elastic block time
18:04:58	shen_noe:	shen_noe has left #bitcoin-wizards
22:10:44	bramc:	Hey everybody
22:12:08	tromp_:	hi Bram
22:13:43	sipa:	ohai
22:13:57	frankenm_:	frankenm_ has left #bitcoin-wizards
22:17:27	zooko:	Hi, bramc!
22:17:59	fluffypony:	ohai bramc
22:20:33	bramc:	I have some questions about elements: http://elementsproject.org/
22:22:24	sipa:	shoot
22:22:33	sipa:	also, #sidechains-dev
22:23:14	bramc:	(1) What is signature covers value? I'm a little perplexed as to what it means
22:23:35	sipa:	that the amount being spent by a txin is part of the signature hash that is being signed
22:24:07	bramc:	You mean, the size of an input?
22:24:11	sipa:	this means that a signing device does not need to know the full previous transaction whose output gets spent - if it receives incorrect information about the amounts, the transaction will just be invalid
22:24:17	bramc:	Isn't that implicit in what is referred to?
22:24:30	sipa:	it is implicitly referred to by the txin prevout hash
22:24:37	sipa:	it's not a security argument
22:24:46	bramc:	It seems like a waste of a few bytes
22:24:54	sipa:	hashes are constant size
22:25:04	sipa:	adding data to the hash input does not change anything :)
22:25:11	sipa:	apart from a few microseconds in hashing
22:25:17	bramc:	oh, hmm
22:25:29	bramc:	I still don't understand the point, but fair enough, no harm no foul
22:25:32	sipa:	ok
22:25:35	sipa:	here is the use case
22:25:45	sipa:	you have a hardware signing device
22:25:49	bramc:	(2) what are mitmask sighash modes
22:26:05	sipa:	you need to give that device some transaction to sign
22:26:24	sipa:	you clearly don't trust the software creating that transaction, or you wouldn't need a hardware device
22:26:37	bramc:	What's wrong with giving the device the whole previous transaction?
22:26:40	sipa:	nothing
22:26:43	sipa:	it may just be large
22:26:51	sipa:	this makes it unnecessary
22:26:56	bramc:	Oh okay, simple little optimization then
22:27:00	sipa:	yup
22:27:09	sipa:	as i said: not a security improvement
22:27:19	sipa:	not sure what mitmask is
22:27:27	bramc:	Bitmask Sighash Modes
22:28:01	sipa:	those are not in elements
22:28:13	bramc:	It's under 'proposed elements'
22:32:39	bramc:	(3) What is there to prevent a memory exhaustion attack using string concatenation?
22:33:40	sipa:	there is no dup command
22:33:44	sipa:	i think?
22:33:47	sipa:	oh, there is
22:36:22	bramc:	string concatenation is listed as one of the reintroduced commands
22:37:08	bramc:	I can see why, it's specifically meant to enable the use of a merkle root of possible ways to unlock a utxo
22:37:36	sipa:	there is a maximum size on the result of a cat
22:37:46	sipa:	(it was a good question, i had to go check the code)
22:38:05	bramc:	Is it a fixed max size?
22:38:45	sipa:	yes
22:38:53	bramc:	What is the max?
22:39:18	sipa:	520 bytes
22:40:27	bramc:	I think with one more simple opcode siacoin functionality could be added: BLOCKID, which takes the value of a specified height block and pulls it in (obviously this causes a timelock)
22:41:28	sipa:	siacoin?
22:42:26	bramc:	http://www.siacoin.com/ the basic idea is that I can pledge an amount of coins to be paid to you at some time in the future if you can prove that you still have a copy of a certain file at that time
22:44:43	bramc:	The pledge contains the merkle root of the file I want stored, and some future block id is used to specify which part of the file you have to cough up to retrieve the reward
22:50:03	bramc:	I think the new elements add enough that all that's left is the thing to pull in the block id
23:50:12	c0rw1n:	c0rw1n is now known as c0rw|zZz
23:57:22	kanzure:	http://sidechain.fairlystable.org/