01:42:36	propumpkin:	propumpkin is now known as copumpkin
08:05:17	hobana.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:17	hobana.freenode.net:	Users on #bitcoin-wizards: andy-logbot Pan0ram1x AllieSenbub hktud0 c0rw1n b_lumenkraft priidu Crowley2k fanquake RoboTeddy aakselrod ebfull Guest68867 d1ggy_ mkarrer_ unlord_ [7] p15x Dr-G Tiraspol moa CodeShark jhogan42 rusty DougieBot5000 Rynomster cluckj crowleyman arubi_ Iriez Starduster_ nullbyte tjader Kwelstr iugfhvybu GAit antgreen` airbreather shesek MoALTz__ waxwing vdo cornusammonis luigi1111w melvster binaryatrocity_ HostFat_ justanotheruser sadoshi
08:05:17	hobana.freenode.net:	Users on #bitcoin-wizards: bliljerk101 grandmaster omni_ jonasschnelli PaulCapestany mengine pollux-bts Emcy yorick merlincorey nuke1989 spinza gielbier koshii maaku [ace] eric a5m0 Cornholi0 nephyrin null_radix crescendo Sqt wumpus Madars richardus mikolalysenko LeMiner cdecker sturles prodatalab adams_ GreenIsMyPepper harrow vonzipper berndj Zouppen andytoshi Xzibit17 cfields manan19 comboy sneak realcr gmaxwell rustyn jaromil catlasshrugged_ Apocalyptic harrigan bosma
08:05:18	hobana.freenode.net:	Users on #bitcoin-wizards: PRab dasource Cory forrestv cryptowest_ runeks__ kanzure kefkius throughnothing Graet Eliel veox indolering K1773R Keefe petertodd jcorgan larraboj ryan-c jessepollak gribble tromp mr_burdell gnusha tromp_ d9b4bef9 wiz starsoccer dgenr8 btcdrak go1111111 weex SwedFTP Hunger- lmacken dc17523be3 HM Luke-Jr luny yrashk artifexd kumavis platinuum otoburb huseby midnightmagic BlueMatt warren TD-Linux mariorz hguux___ fenn wizkid057 ajweiss
08:05:18	hobana.freenode.net:	Users on #bitcoin-wizards: SubCreative Adlai Anduck iddo poggy nsh kyuupichan Logicwax phantomcircuit EasyAt lechuga_ luigi1111 isis nanotube yoleaux gavinandresen dignork AdrianG s1w livegnik optimator fluffypony Meeh cursive dansmith_btc morcos guruvan BananaLotus bedeho heath roasbeef_ Fistful_of_Coins stonecoldpat afdudley espes__ pigeons sipa warptangent phedny so STRML michagogo null sl01 lnovy [d__d] catcow Muis coryfields_ kinlo gwillen nickler Alanius sdaftuar
08:05:18	hobana.freenode.net:	Users on #bitcoin-wizards: epscy Taek Krellan Oizopower mappum jbenet leakypat CryptOprah NeatBasis davout brand0 @ChanServ btc___ azariah MRL-Relay BrainOverfl0w
12:20:20	skeuomor1:	skeuomor1 is now known as skeuomorf
13:34:38	fanquake:	fanquake has left #bitcoin-wizards
14:00:54	Guest68867:	Guest68867 is now known as amiller
15:05:58	gmaxwell:	https://plus.google.com/103188246877163594460/posts/WTrnyFsRmHv
15:07:44	jcorgan:	congrats
15:07:50	fluffypony:	go rusty!
15:09:24	amiller:	nice
15:43:44	kanzure:	.title
15:43:45	yoleaux:	Leaving IBM May 4. Joining blockstream.com May 11. In 1997 I went to Usenix's…
18:31:54	Taek:	rusty congrats
18:32:09	Taek:	also congrats to blockstream
19:20:13	jgarzik:	Taek, great addition to the _bitcoin_ dev team :)
19:20:30	jgarzik:	(meaning the wider bitcoin community)
19:20:46	jgarzik:	The BTC community needs more smart, capable people like Rusty.
19:21:01	bsm117532:	What happened?
19:21:13	andytoshi:	+1 jgarzik , and congrats rusty
19:22:07	jgarzik:
19:22:59	jgarzik:	I am vaguely tempted to see if I could find funding just to hire a "bitcoin intern" -- take a motivated C/C++'er and teach them bitcoin, to grow the community. Cheap payroll for me, intern learns bitcoin core, and the bitcoin community grows.
19:32:09	morcos:	you should definitely do that! get a Ga Tech CS student for the summer
19:35:46	jgarzik:	morcos, yup
20:21:51	IRCFrEAK:	IRCFrEAK is now known as thufir
20:24:48	thufir:	So, my NSA killing project is about to have the first public PREVIEW release. It is cloud 2.0, decentralized. Next step is incentivized. It will use bitcoin. The hash power cannot be split. I grok this. This is a purpose other than enabling cloud 2.0. It gives bitcoin intrinsic value that exists only on the internet (ie, no exchange needed, my project is an exchange for btc->bandwidth,storage,and more). Anyways, I come to ask.
20:24:48	thufir:	Is bitcoin ready yet!?! IE: I NEED NLOCKTIMEDLAY!!! (or something like that to do probabilitc payments, channels, etc.. i need massive transaction amount)
20:25:25	thufir:	please say yes and how...
20:26:53	sipa:	if by nlocktimedelay you mean checklocktimeverify (bip 65), feel free to help test the implenentation and contribute
20:27:18	thufir:	so that is enabled on test net at least?
20:27:55	sipa:	if you need massive transaction amount, the bitcoin blockchain won't help you (it is directly in conflict with the ability for the world to validate it)
20:27:55	thufir:	and thank you! for that information (i will read bip65)
20:28:08	sipa:	no, it is not even implemented entirely
20:28:11	thufir:	sipa: probabibilistic payments
20:28:29	sipa:	wrt killing the NSA: take it elsewhere
20:28:39	thufir:	1/1bill lotto ticket = 1 billion x transaction count
20:28:47	thufir:	sure, if you are afraid of satan i understand
20:29:06	andytoshi:	thufir: keep it civil
20:29:22	thufir:	andytoshi: i won't mention it again while sipa is around, i am civil.
20:30:00	thufir:	so is that nlock thing enabled on the test net?
20:30:59	sipa:	i just told you it is not even implemented entirely
20:31:09	sipa:	let alone an actual deployment plan
20:31:29	sipa:	let alone being in production
20:31:34	andytoshi:	thufir: it's not just sipa. this channel is about research and technology; while these sort of stuff is hard to separate from the political context there's no need for name-calling or manifesto-type comments
20:31:50	thufir:	don't be mad, i wasn't attacking you, i am just done with being afraid of them. we must be open, it is the antidote to their system. if we are open, we find each other. if we are closed, we find allies much slower.
20:31:56	sipa:	feel free to contribute to its development, however
20:32:04	thufir:	yes, sorry
20:32:27	kanzure:	inflammatory comments are obvious and they are very boring
20:33:14	sipa:	thufir: if i was afraid of them i wouldn't be asking you to stop talking about it in a publicly logged channel. this channel is about technical research. anything else is off topic, whether you agree with the statements or not
20:33:15	thufir:	i said none. only objective pragmatic fact. you are the ones who keep talking about that. i am here to yes, contribute to development
20:33:30	thufir:	asking me to stop is doing their job, so i would now guess yes, afriad
20:33:42	thufir:	lets stop talking about it then and talk about development, no?
20:33:48	sipa:	good
20:34:05	kanzure:	sipa: if he is this bad at thinking about that topic, why would you expect him to be capable of contributing on other topics
20:34:34	thufir:	so then, bip 65 is the state of the art in what I seek? (enabling probabilistic payments?) and it isn't implemented even in test net yet? i thought some nlocktimedelay was done and in testnet?
20:35:18	sipa:	i do not know what nlocktimedelay is, nor do i know the state of the art for probabilistic payments
20:35:40	thufir:	kanzure: not asking him then, but i don't judge, i hope he learns. i am open to all who want to join, regardless of their past.
20:36:03	thufir:	ok, i might have it wrong, sec...
20:36:49	thufir:	I guess it is just nLockTime (no delay)
20:36:50	sipa:	do you have some reference for s probabilistic payment scheme that uses nlocktimedelay (and do you have something describing what nlocktinedelay is, if not checklocktimeverify)?
20:36:57	andytoshi:	thufir: i think bip62 (non-malleability) is sufficient for probabilistic payments
20:37:14	thufir:	well, bip-65 is referenced as "revisiting nLockTime" by qntra.net
20:37:30	thufir:	i found now in search, thanks to you guys so thanks, and no hard feelings, i am just forward
20:37:44	thufir:	oh awesome andy!
20:37:51	thufir:	is that implemented in at least test net? :( :)
20:38:17	thufir:	because yes, only flaw of probabilistic payments is the darn malliability
20:38:34	sipa:	bip62 is not fully implemented
20:39:38	thufir:	because fixing malliability would save on tracactions.. nLockTime would require transactions still and might not really work for probabilisitc payments at the scale i know that fixing malliability would
20:39:56	andytoshi:	thufir: you can build and test systems which depend on bip62 since transactions which violate its restrictions are nonstandard to most nodes
20:40:06	andytoshi:	actual deployment would need to wait for it to be fully implemented
20:40:22	sipa:	andytoshi: the low-s rule is not enforced however
20:40:49	andytoshi:	oh, oops, i thought it was
20:40:53	thufir:	is it implemented enough that i could use testnet as the backing for my system? when you guys are ready i switch it over? testnet would be enough as my system is not gold if you loose it, just bandwidth
20:41:27	sipa:	no, it is not implemented enough
20:41:30	sipa:	nowhere
20:41:43	thufir:	ah ok, thank you!
20:42:07	sipa:	and implementation is not sufficient: you need the actual network to adopt it
20:42:56	thufir:	well, i might be joining your dev team to help because the free world needs cloud 2.0, and cloud 2.0 needs bitcoin (i refuse to use an alternative like creating a filecoin, i already know it must be bitcoin)
20:43:18	thufir:	but that sucks cause it will slow me down
20:43:23	sipa:	wth is cloud 2.0?
20:43:35	sipa:	stop using buzzwords
20:43:38	thufir:	my project. my purpose in life.
20:43:39	fluffypony:	sipa: it's just before cloud 3.0
20:43:58	fluffypony:	and inbetween IAAS 1.5 and SAAS 2.8
20:44:22	thufir:	ok, then you heard it here first. only the "unnamable" knows its name, and one friend. now you all do: morphis
20:44:40	thufir:	it deprecates bittorrent to start
20:45:27	sipa:	whitepaper? research? code? design documents?
20:45:44	thufir:	3 months in the coding, years and years of thinking and planning.
20:45:57	fluffypony:	guitar lessons: http://www.morphis.com
20:45:58	fluffypony:	.title
20:46:01	yoleaux:	Beginner Guitar Lessons :: morphis.com
20:46:08	thufir:	i say maybe a month until preview release that will sufficiently deprecate bittorrent
20:46:10	thufir:	yes, i don't care
20:46:12	thufir:	morph.is
20:46:14	thufir:	:)
20:46:20	thufir:	eat your heart out guitar guy
20:46:31	thufir:	oh btw, i taught myself classical guitar, will check out your site :)
20:46:32	kanzure:	what is your opinion of mkultra
20:46:36	fluffypony:	where's bramc when you need him...
20:46:45	thufir:	might be what created me,
20:46:50	fluffypony:	thufir: it's not my site
20:47:12	thufir:	ah :( i could use more guitar expert friends
20:47:21	thufir:	kanzure: why do you ask?
20:48:52	thufir:	well, i also know it to be a failure. unless you wanted your control of the interenet to be lost
20:54:33	thufir:	I see. we'll i guess I'll wait for Todd. Thanks for the info so far though guys.
21:11:22	Sub|afk:	Sub|afk is now known as SubCreative
21:16:30	thufir:	so what is the low-s rule?
21:18:20	andytoshi:	thufir: ECDSA sigs consist of a pair of numbers (s, r) which each live in a field of order roughly 2^256; turns out for each (s, r) that ($field_order - s, r) is also a valid sig, creating a degree of freedom that an attacker can use to change data on the wire (which doesn't affect any functionality but can confuse things); the low-s rule says that only one of these is actually valid, removing that
21:18:22	andytoshi:	degree of freedom
21:20:16	thufir:	so low-s means the sig is only valid if it is the lowest possible sig? so it is not implemented yet because? i guess it is impossible to know the lowest possible s (ie, someone might know math that would calculate a valid lower one) ?
21:21:25	andytoshi:	that's not what it means; it means exactly what i said. it's not implemented because it was overlooked that this degree of freedom could be problematic, it's still not problematic for systems in use today, and changes in a consensus system are slow to happen
21:21:59	thufir:	yes, i understand. i mean the low-s rule, it means only accept lowest s?
21:22:38	gmaxwell:	What do you mean not implemented? all Bitcoin Core nodes produce low-s signatures, but it cannot be enforced in the network currently because it would break existing wallets.
21:22:58	thufir:	I don't know what you mean by "rule says that only one of these is actually valid". one of what?
21:23:08	thufir:	oh, is that all?
21:23:30	thufir:	like you guys know you know the math to know the lowest s? so you could implement such a rule? if only it didn't break existing wallets with higher s's?
21:23:53	gmaxwell:	It's implemented in bitcoin core, but not enforced for other people's transactions.
21:24:19	thufir:	wow. damn. i understand the problem that we can't force old wallets to have to move their coins. damn
21:24:43	gmaxwell:	not move their coins, but not create incompatible transactions.
21:25:36	thufir:	so can't it be simple like: if coins come from < block (351720) then don't apply low-s rule, otherwise, transaction must be low-s to be accepted?
21:26:40	gmaxwell:	Great, and now your coins are all stuck becuase you have some unupgradable hardware wallet.
21:27:16	thufir:	because that hardware wallet might genereate a non low-s new address?
21:27:29	thufir:	only generate
21:27:40	gmaxwell:	this has nothing to do with addresses.
21:27:52	gmaxwell:	It's the /SIGNATURE/.
21:28:47	Taek:	while people are asking dumb questions: do schnorr signature schemes have curves? I confess I still don't understand them well
21:29:03	thufir:	hmm, ok i think i see. hardware wallet that makes high-s transaction signatures can't escape its coins
21:29:32	thufir:	gmaxwell: thank you immensiley. i am thinking :)
21:30:34	thufir:	it would be too much cpu or something for the rule i proposed to be instead of < block 351720, to instead be: if all input coins to a TX come from low-s signed transactions, then the TX must be low-s as well.
21:30:36	gmaxwell:	Taek: schnorr is a signature system based on groups where discrete logs are hard.
21:31:08	gmaxwell:	Taek: it can be used over integer rings or EC or other groups that have the right properties.
21:31:57	gmaxwell:	thufir: what software people who send you coins runs doesn't imply anything about the software you run!
21:34:25	thufir:	but i mean if me and alice want to do something that requires malliability fixed, then i can transfer my coins into a valid low-s TX if they are not already. then I can do my probablistic TX to alice. she knows that since the coins in this probabilistic TX come from a low-s TX that the lotto ticket is valid?
21:36:09	thufir:	valid i mean safe, not winning, you knew that probably
21:36:14	Taek:	gmaxwell: ok, I think I understand that. You could use secp256k1 as 'g' because discrete logs are hard in that field? But more typically a Schnorr group is used?
21:37:25	gmaxwell:	I have never personally seen schnorr implemented over an integer ring in deployment.
21:38:26	thufir:	gmaxwell: does that solve it? ie, anyone else doesn't care about low/high-s. but for those who do because they are looking at a probabilistic ticket, they can know it is valid if it is low-s signed and all input coins come from low-s TXs, because that is the new low-s rule?
21:40:15	thufir:	your pause is getting me excited... because it means you haven't found the flaw yet? ;)
21:40:46	gmaxwell:	thufir: I am unable to decode your request!
21:40:59	thufir:	lol (crying laugh) :)
21:41:04	gmaxwell:	what the heck is a "probablistic ticket"? :)
21:41:11	thufir:	probabilistic payments
21:41:18	thufir:	only broken due to malleability
21:41:19	andytoshi:	thufir: the problem is that -in transit- somebody can change a signature from low-s to high-s; it doesn't matter if everyone involved agrees to use low-s
21:41:28	thufir:	a cheap way for 1 billion x tx on btc
21:41:40	thufir:	yes, humans won't like it. but autonomous agents won't mind
21:41:40	gmaxwell:	I think you need to step back and understand actually the mechenism by which things are broken.
21:42:15	thufir:	andytoshi: so if that high-s tx has only coins from low-s txs then it won't be accepted with my proposed low-s rule.?
21:42:34	thufir:	gmaxwell: i think i do understand it :)
21:43:02	gmaxwell:	(also, I'm not aware of probablistic payment scheme which is broken by malleability)
21:43:17	gmaxwell:	thufir: the transaction _you_ accept isn't your issue in any case.
21:43:45	thufir:	if i know the ticket i was given is low-s and matches the rule so low-s rule will be applied then i know the network won't accept any other
21:43:53	andytoshi:	thufir: you're confusing different parts of the system; coins don't come "from txs" (see https://download.wpsoftware.net/bitcoin/bitcoin-faq.pdf ) for an explanation of low-s vs high-s see https://download.wpsoftware.net/bitcoin/malleability-faq.pdf
21:44:10	thufir:	andytoshi: thx
21:44:14	gmaxwell:	thufir: we just explained that the network cannot currently reject violating transactions because that will break existing wallets.
21:44:31	andytoshi:	thufir: btw everything in there about mt gox is probably false
21:44:36	andytoshi:	but the technical content is correct
21:44:36	thufir:	gmaxwell: so are you saying one of the probabilistic payments schemes does work 100%?
21:45:28	gmaxwell:	I'm saying that issues they have are not malleability related.
21:45:44	thufir:	gmaxwell: even with my altered rule? existing wallets would make non low-s txs, but the coins would come from non... shit, i guess it is random. its coins might be in low-s TXs but its next TX it would ever generate is high-s? that is the issue?
21:45:54	thufir:	gmaxwell: i've heard that before that the only issue is humans
21:46:08	andytoshi:	thufir: you aren't making sense, please read the PDFs i linked you
21:46:09	thufir:	gmaxwell: is that what you mean? human acceptance of a losing lotto ticket as payment?
21:46:31	thufir:	gmaxwell: if that is the only problem, my system doesn't mind that, it understands that is a valid payment.. the risk
21:46:40	thufir:	andytoshi: i am, thank you
21:46:45	gmaxwell:	thufir: thats a problem with it, most people reject the idea very agressively in my expirence. Not the only one.
21:47:22	thufir:	gmaxwell: ok, that one for me is 100% not relivent. I do understand it, but for my system to use it in the background it doesn't mind what humans think.
21:47:36	thufir:	gmaxwell: what are the other problems if not malleability?
21:48:00	thufir:	andytoshi: i did read these back in mtgox days, still thank you
21:48:24	gmaxwell:	What made you think malleability was an issue at all? All the proposals I've seen have double spending problems.
21:48:39	thufir:	exactly. isn't that due to malleability?
21:48:45	thufir:	that the double spend is possible?
21:48:49	gmaxwell:	No.
21:49:11	gmaxwell:	e.g. you use the same coin to probablistically pay many people concurrently instead of sequentially.
21:49:49	thufir:	hmm
21:50:42	thufir:	from https://en.bitcoin.it/wiki/Nanopayments: "If need be, this could be solved with hub servers that nanopayment recipients would use to announce coins currently in use to other nanopayment recipients."
21:50:47	thufir:	so that is what you are speaking of then
21:51:00	thufir:	that is the problem and if i fix that then malliability is for sure not a problem?
21:51:30	gmaxwell:	thufir: I still have no idea why you thought malleability was an issue to begin with!
21:51:31	thufir:	because my system deprecates 'hub servers' so very well might be the symbiant of bitcoin that fixes nano-payments
21:51:41	gmaxwell:	(for that application)
21:52:17	gmaxwell:	thufir: that fix requires they be a semitrusted cosigner on the coins.
21:52:18	thufir:	i am sorry, it is not fresh in my mind. i realized it when mtgox made it an issue. so i forget the thinking.
21:52:27	andytoshi:	gmaxwell: iirc a payment that goes through is a pair of chained transactions that get confirmed together
21:53:06	andytoshi:	so there's a potential loss if the first gets marred then confirmed
21:53:11	Cornholio:	Cornholio is now known as Cornholi0
21:53:19	thufir:	yes, what andy is saying sounds familiar
21:53:29	thufir:	if i had a winning ticket they can jam it or whatever he is saying
21:53:37	thufir:	before i broadcast it
21:53:49	gmaxwell:	andytoshi: in the last protocol I remembered all it did is jam.
21:53:50	thufir:	i think they invalidate the tx the coins in the winning ticket came from
21:54:23	thufir:	i can fix the semitructed cosigner to fix the double spend. i believe it in easy due to nature of my system
21:54:34	gmaxwell:	I find this doubtful.
21:54:43	thufir:	but that thing andytoshi is talking about I do not know how to solve unless my low-s rules sounds good??
21:54:44	andytoshi:	gmaxwell: the one in the wiki can't jam, the payer creates a tx and sends it to the payee, that is the entirety of the payment
21:54:54	andytoshi:	then if it happens to be valid, the payee broadcasts it
21:55:05	gmaxwell:	andytoshi: yea, indeed.
21:57:16	thufir:	so by your opinions, the link i sent nanopayments. if my code doesn't mind like a human (that isn't the issue), and i have a magic oracle to register the source tx with like the wiki says: "A hub server would be pretty simple, just a single lookup table. A merchant sends it a reserve message. The server checks that the signature matches the coin. If a reserve is already in effect for that coin, it returns an error, otherwise
21:57:17	thufir:	OK." (just assume like human problem this doesn't exist), then in your guys exper opinions, the wiki nanopayment is 100% perfect? no malleability problem?
21:57:21	andytoshi:	i also had some idea that double-spending wasn't a problem except with pretty low probability (if you send two payments then 0, 1 or 2 of the will go through; if you double-spend then the "2" case results in theft, but that's unlikely), but i can't remember the details
21:57:54	andytoshi:	and to double-spend you need your txid guess to be in-range for multiple probabilistic transactions, which if the range is small and random, is unlikely to occur
21:58:09	gmaxwell:	andytoshi: you _always_ concurrently spend, it's a direct division of your payment, undetectably, proportially to the parallelism you can achieve.
21:58:17	andytoshi:	thufir: ...but i really didn't think these things through, please don't go building systems based on these half-bakked thoughts!
21:58:26	thufir:	hehe
21:58:28	thufir:	no thank you so much
21:58:47	andytoshi:	gmaxwell: oh, right, derp
21:59:20	thufir:	andytoshi: i am sorry to say that i am already 3 months into full time development of it, 1 month until first version (0 bitcoin in it)
21:59:42	thufir:	andytoshi: but next step is what i've planned for years, since you first proposed nanopayments!
22:00:05	gmaxwell:	if you have a (semi-)trusted cosigner then you can stop the multiplication.
22:00:15	andytoshi:	thufir: i didn't propose them, it was mike caldwell i think, i had an old article about them that didn't cite him upfront (but it is now fixed to do this)
22:00:33	thufir:	i stand on the shoulder of giants. credit to you all
22:01:14	thufir:	thanks both of you for your time so far, i can't thank you enough. well, hopefully my contribution helps
22:04:10	thufir:	My name is Sam Maloney, btw. This is my usual nick on freenode. Take care for now.
23:21:36	Sub|afk:	Sub|afk is now known as SubCreative
23:27:04	Eliel:	if there's just one extra version of a tx producable through malleability, then couldn't you just produce continuation txs for both versions to effectively make malleability a non-issue?