00:25:17	maaku:	quantum computers
00:25:18	maaku:	* maaku runs
00:33:10	justanotheruser:	maaku: ?
00:37:24	dexX7_:	dexX7_ is now known as dexX7
00:54:54	sipa:	zk-SNARKS
00:54:56	sipa:	* sipa run
01:03:41	posita:	posita has left #bitcoin-wizards
01:03:46	posita:	posita has left #bitcoin-wizards
01:05:40	Pan0ram1x:	Pan0ram1x is now known as Guest21473
02:09:01	phantomcircuit:	[05:18:11] phantomcircuit: you're in the bay area?
02:09:02	phantomcircuit:	yeah
04:51:16	dsnrk:	petertodd: Shared Coin has been doing the bad mixes as far back as Nov 2013 e4abb15310348edc606e597effc81697bfce4b6de7598347f17c2befd4febf3b
05:14:08	petertodd:	dsnrk: I was thinking about it this morning, and it may be the system never worked, it's just that it looked like it worked if your specific satoshi-precision vout value happened to match one they already had unspent
05:14:32	petertodd:	dsnrk: I only did testing by hand, so I wouldn't be surprised if the "random" numbers I picked weren't actually all that random...
05:15:46	gmaxwell:	petertodd: may also be that they prepopulated their txout sent and it decayed over time.
05:16:14	petertodd:	gmaxwell: maybe, although they get a lot of users so I'd be surprised if running out was an issue
05:17:41	petertodd:	dsnrk: of course, I was first testing shared coin before it was even publicly released - that's pre november
05:18:16	dsnrk:	gmaxwell: they do delay by a block it seems.
05:19:35	dsnrk:	petertodd: they show an example transaction in October and it was broken as well.
05:19:49	dsnrk:	( 72316782bf48d0cd232b888a7b9ea03f88ba79fac28273cd2aa1804683235412 )
05:20:08	petertodd:	dsnrk: yeah, probably just bad luck on my part, and not very thorough testing
05:21:17	petertodd:	dsnrk: at least the people doing round numbers sends were being protected - I wonder what % of people that ends up being?
05:21:38	dsnrk:	I don't for a second blame you in that.
05:22:13	dsnrk:	by spends identified by reddit users were fairly round 0.015 BTC each
05:22:37	petertodd:	by spends?
05:22:43	dsnrk:	*my spends
05:22:47	petertodd:	ah
05:23:15	gmaxwell:	well there is the fact that their own funds are identifyable-ish, but at least that was known
05:23:40	petertodd:	dsnrk: yeah, doesn't take many bits of uniqueness to break the algorithm :(
05:24:14	petertodd:	gmaxwell: an early bug was that their funds were compressed keys and customer funds uncompressed :(
05:24:47	dsnrk:	their server seems to keep logs of all the private keys used for their spends, there's a function for dumping all the private keys to disk as they are being used. it's likely they have enough logs at this point to expose eveyr send made by the service, even if users couldn't do it as trivially.
05:25:01	gmaxwell:	sure.
05:25:10	gmaxwell:	These things at least we knew.
05:25:34	petertodd:	dsnrk: that's why I've always told people having the source code for the service isn't as useful as you'd think
05:26:02	dsnrk:	gmaxwell: it's implied in their pitch that they don't keep logs "no requirement to keep any logs"
05:27:19	petertodd:	dsnrk: so what happens if you send funds to an older address?
05:27:25	dsnrk:	petertodd: I'm half tempted to write a crawler to try and expose all of the coinjoin transactions made by them. I decided that's information I don't want to know though. you can identify them as being from bc.i by using the IP addresses they publish.
05:27:54	petertodd:	dsnrk: well, identifying the transactions isn't very hard even without ip addr info...
05:28:14	dsnrk:	petertodd: one of theirs or a temporary user ones in the CJ?
05:28:35	petertodd:	dsnrk: oen of their addresses - if they're keeping private keys they'll probably spend the funds
05:29:48	dsnrk:	petertodd: what fingerprint? currently I've got the number of outputs and inputs and the sizes involved, that there's a chain of minimum 1 block apart, and that only a small portion of the outputs carry from TX > TX. are there any other tells?
05:30:16	dsnrk:	oh and all the public keys are uncompressed.
05:30:38	petertodd:	dsnrk: that's incorrect, some of the keys are compressed
05:31:04	petertodd:	dsnrk: anyway, there aren't that many people doing transactions like that - just linking them all together is probably pretty close
05:31:34	petertodd:	but anyway, identifying bc.i cj transactions in general isn't too much of a privacy issue - identifying input and output links is the issue
05:32:54	dsnrk:	petertodd: that's interesting. some of the ones in the early SC are uncompressed, the ones in my later example are all uncompressed.
05:33:11	petertodd:	dsnrk: oh, maybe they finally fixed that bug fully?
05:33:30	dsnrk:	I didn't notice that change in the repo, but I could have overlooked it
05:34:27	dsnrk:	but yes, coinjoins aren't meant to be secret. the only reason it's an issue here is that you can easily deanonymise them once you find them.
05:34:51	dsnrk:	heck you can do them in real time.
05:35:04	petertodd:	yeah. also having all those extra inputs and outputs adds little to nothing to the privacy, and just makes it harder to notice it's broken
05:36:16	petertodd:	come to think of it, it'll also reduce privacy by increasing the velocity of their funds, making them more distinguishable from customer funds
05:54:56	justanotheruser:	justanotheruser is now known as bystander
05:55:07	bystander:	bystander is now known as justanotheruser
06:15:09	dsnrk:	petertodd: I hasn't thought of that. the coin-age of their mixes is actually ridiculously slow. for mine it took minutes for them to be spent again. that's probably the best fingerprint of all if you were going to automate it.
08:10:20	Pan0ram1x_:	Pan0ram1x_ is now known as Pan0ram1x
08:15:56	execut3:	execut3 is now known as shesek
12:56:30	nshsome:	nshsome is now known as [nsh]
14:56:01	posita1:	posita1 has left #bitcoin-wizards
15:52:41	hearn:	gmaxwell: so how much do you think can realistically be accomplished with snarks that only support hand-crafted circuits? any idea how complicated a circuit to do the core of the EC signature verify is? i mean using your scheme that moves the bulk of it out of the snark
16:05:13	gmaxwell:	hearn: my scheme results in only needing a point add inside the snark for the verify ... so a lot smaller than a full verify. though I haven't thought through what the most efficient construction would be for a point add over a differently sized larg arithmetic circuit.
16:06:12	gmaxwell:	Probably the easiest semi-useful thing to implement is a hash tree membership query. "This UXTO is a member of blockchain X"
16:06:43	hearn:	yeah, that's what i thought. the released code is _very_ basic. you get templates for: AND, OR, NAND, summing (not a gate), toggles, bit-packing and unpacking, demuxing, one or two other things. and that's about it.
16:07:34	hearn:	i guess a circuit for SHA256 is the first step
16:21:42	[BNC]dansmith:	[BNC]dansmith is now known as dansmith_btc
16:54:12	maaku:	phantomcircuit: I thought you were in the UK for some reason. you going to any of the meetups?
16:55:23	maaku:	maaku is now known as Guest84338
17:02:33	phantomcircuit:	maa
17:17:08	mr_burde_:	mr_burde_ is now known as mr_burdell
17:23:47	Guest84338:	Guest84338 is now known as maaku
17:24:06	maaku:	stupid internet
17:25:01	phantomcircuit:	[16:54:12] phantomcircuit: I thought you were in the UK for some reason. you going to any of the meetups?
17:25:06	phantomcircuit:	i havent' been in the uk for a while now
17:26:59	maaku:	ah well i hope we have a chance to run into each other
17:27:14	maaku:	i'm in san jose and don't often go to the meetups, but if there were wizards there i might
17:30:14	phantomcircuit:	maaku, where abouts in san jose?
17:35:32	phantomcircuit:	ah nvm
17:36:08	phantomcircuit:	maaku, that's mountain view not san jose :P
18:03:28	maaku:	i'm willow glen, but yes the meetup is mountain view i think
18:03:31	maaku:	sorry multi-tasking
18:03:57	maaku:	there's also one in SF, but I never make it that far
18:04:58	gmaxwell:	sunnyvale, but it's on tuesdays when I usually have other things to do.
18:05:20	maaku:	it moved from hacker dojo?
18:20:34	jonpry:	sipa when are more header-first patches expected?
18:22:57	jonpry:	we need this technology for miniblockchain project
18:25:39	gmaxwell:	"miniblockchain project"?
18:26:20	jonpry:	some info here http://bitfreak.info/mbc-wiki/index.php?title=Main_Page
18:26:39	jonpry:	it's similar to ultimate blockchain compression
18:28:28	gmaxwell:	Pretty troubling that the page there appears to make no mention of security assumptions.
18:31:30	jonpry:	some page has a list of attacks
18:31:46	gmaxwell:	jonpry: that white paper seems to be very confused.
18:32:01	jonpry:	yeah i know
18:32:17	jonpry:	it's also out of date. the real implementation looks not to much like it
18:32:57	jonpry:	users always have the option of not pruning the chain and not running from a pruned chain so there are no security implications in that case
18:33:23	jonpry:	also if you only prune behind checkpoints there are no practical attacks
18:38:04	andytoshi:	jonpry: a "checkpoint" in that sense seems to represent a point of trust in the consensus system.. but in bitcoin a "checkpoint" has nothing to do with trust or consensus
18:38:25	andytoshi:	i'm updating my alts.pdf to merge in the PoS stuff and elaborate on distributed consensus issues. it'll be done in under an hour, i encourage you to read it
18:39:23	andytoshi:	oh, i don't mean actually done, i just mean the distributed consensus section will be done
18:39:42	jonpry:	i mean checkpoint in bitcoin sense. it's simply a point which a user chooses to not accept forks behind
18:40:00	jonpry:	it doesn't matter is users choose the same point or if it is a correct point. it's just their choice
18:41:23	gmaxwell:	jonpry: sipa and I are hoping to remove those as part of the headers first change.
18:42:22	jonpry:	remove checkpoints?
18:42:29	gmaxwell:	They cause severe misunderstandings about the security model, and headers first largely removes the actual use of them.
18:42:58	gmaxwell:	They're only not a massive violation of the security model when— like now— they largely do nothing.
18:43:49	gmaxwell:	If you're talking about nodes that never retrive the history at all, thats a pretty substantial difference. (since it means that a short term burst of hashpower could basically violate any rule of the system)
18:44:05	gmaxwell:	non-transparently.
18:44:06	jonpry:	they have real implications for pruning system. once somebody chooses a fixed point in the chain it becomes possible to remove all tx data prior to that point without problem
18:44:17	gmaxwell:	Thats a misunderstanding of pruning.
18:44:50	gmaxwell:	We have pruning almost completely implement in bitcoin core and there is absolutely no impact on the security model, and no need for checkpoints.
18:45:27	jonpry:	thats doubtful
18:45:48	andytoshi:	jonpry: what attack do you believe checkpoints prevent?
18:45:49	gmaxwell:	jonpry: As I said, you misunderstand it.
18:45:59	jonpry:	pretty sure i don't
18:46:14	jonpry:	the fundamental problem is that you have to download the UTXO set at some point in time
18:46:30	gmaxwell:	jonpry: no, you download the blockchain— you do not, however, have to store it.
18:46:42	gmaxwell:	Since you produced the utxo set yourself there is no change in the security model.
18:46:49	jonpry:	we do not download block chain
18:47:06	andytoshi:	then how do you verify it?
18:47:21	jonpry:	the set is hashed into the block headers
18:47:41	jonpry:	and we have elaborate system to provide proofs of partial UTXO sets
18:47:43	gmaxwell:	Doing that is a non-trivial reduction in the security model.
18:48:09	jonpry:	it's all the same if you only prune behind checkpoints
18:48:14	gmaxwell:	(not that it doesn't have uses, I mean— I proposed this back in 2011)
18:48:16	andytoshi:	it's completely not
18:48:46	gmaxwell:	This is part of why we're going to remove them in bitcoin core, since they seem to inspire this kind of very severe misunderstanding of the security model.
18:49:56	jonpry:	its all a matter of scale. like say you issue a checkpoint every millenium for part of the tree that is 500 years old
18:50:27	gmaxwell:	jonpry: if you do things like that you are just left trusting people to give you valid data— in the design of bitcoin we work very hard to avoid having any third party trust. Miners are only trusted to provide ordering, the fact that it's viable to do this is— in part— because they're not able to do much while violating that trust.
18:51:15	jonpry:	i'm telling you that the only security violation is the same as using checkpoints
18:51:22	andytoshi:	jonpry: you are wrong
18:51:34	jonpry:	you have not seen the code or know the scheme so how do you know?
18:51:58	andytoshi:	because you are badly confused and the chances of you getting it right without understanding are zero
18:52:14	gmaxwell:	jonpry: you've asserted this, then linked me to a page which makes no concrete claims about security at all, and which linked a whitepaper where the author clearly had a fairly poor understanding of Bitcoin.
18:52:27	gmaxwell:	So I'm skeptical, but happy to see—
18:52:59	jonpry:	i don't have time to explain it all. when the code comes out people will have a lot of fun analyzing it
18:53:35	gmaxwell:	Well I guess there is nothing to discuss then; if you're nagging sipa for something as trivial as the headers first code I suspect you're not likely to ever implement anything at all.
18:53:56	jonpry:	i actually have it working
18:54:19	jonpry:	just the process of a new node syncing is not done. but local pruning works
18:54:26	gmaxwell:	jonpry: But in any case, I'm on the record saying that I am very skeptical about the security claims that you're making. If you want to go tell people there is no issue, okay— but with notice that sounds more like fraud than ignorance.
18:55:11	jonpry:	i am just getting paid to write the code. i have no interest in the coins success
18:55:25	gmaxwell:	Yea, thats clear enough.
18:55:40	jonpry:	and if it helps the guy insists on doing it in a way that is not secure so no such claims will be made
18:56:06	gmaxwell:	Thats better. :)
18:56:44	jonpry:	but what is interesting is that it is secure under same assumptions as checkpoints
18:56:54	andytoshi:	jonpry: in future, sipa is available on #bitcoin-dev and it's much less likely that we'll assume you're a researcher if you ask there ;)
18:57:09	gmaxwell:	If you go ask him about this in there you'll cause him to leave the channel.
18:57:16	gmaxwell:	I suggest you do not.
18:58:17	jonpry:	i don't understand the problem. i am working on semi difficult problems and have solved some things. i asked about some code you guys are working on and its turning into a flame war
18:58:39	jonpry:	the proof of security is simple
18:58:55	jonpry:	checkpoint is a block which is asserted by the user to be good right
18:59:15	andytoshi:	jonpry: you showed up on a low-volume research channel making false claims and demanding free code which you are going to turn around and charge somebody for
18:59:22	gmaxwell:	jonpry: The security model is not the same because the design undermines the assumptions that make checkpoints even remotely tolerable (though we consider them unfortunate and want to remove them even considering that)
18:59:58	jonpry:	block contains hash of UTXO set. it's infeasible to provide a UTXO set with same hash. so therefore the user by choosing a checkpoint has chosen a UTXO set
19:00:18	jonpry:	assuming that set can be found. no further problem arise
19:00:53	gmaxwell:	jonpry: Bitcoin core still verifies all the data, a checkpoint that e.g. invents a billion coins out of thin air.
19:01:32	jonpry:	yes the code cannot verify a checkpoint. but even bitcoin cannot verify a checkpoint is part of most work chain
19:02:01	gmaxwell:	jonpry: yes, in fact— it can and does. Assuming the user is not partitioned from the most work chain.
19:02:34	jonpry:	if another most work chain is found with fork point before the newest checkpoint it will be ignored
19:02:47	jonpry:	it allows the user to choose an alternate view of reality
19:03:12	jonpry:	which is arguably less extreme than what MBC offers, but i claim its just as bad
19:03:33	gmaxwell:	Yes, indeed, but also noisly logs it as an error condition. And we're publically committed to never creating one near or in competition in the reference)
19:03:48	gmaxwell:	* gmaxwell is reminded of 'It is difficult to get a man to understand something, when his salary depends upon his not understanding it'
19:04:06	gmaxwell:	jonpry: it's completely transparent and still audited by the user.
19:04:17	jonpry:	we could have the same rules of creating checkpoint
19:04:53	gmaxwell:	so the security is very clearly not the same, since the software cannot check any of its correctness.
19:04:56	Apocalyptic:	"and still audited by the user." // talking about checkpoints ?
19:05:01	jonpry:	the thing is that i don't think it is better. it is just different and better/worse is a matter of philisophy
19:05:09	Apocalyptic:	because I have yet to see a normal user audit them
19:05:15	gmaxwell:	Apocalyptic: its audited by the software.
19:05:34	gmaxwell:	(in fact, it looks like from the whitepaper that it can't even check the proof of work, which is pretty boggling)
19:05:54	jonpry:	the coin is just a reference implementation for others to looks at afaik. i can't see what the argument could be for not writing it
19:06:13	jonpry:	whitepaper is fubar
19:06:18	jonpry:	and it does check proof of work
19:06:50	gmaxwell:	jonpry: the whitepaper seems to indicate it doesn't (proof chains, and showing no headers in the past) but I believe you fixed that. :)
19:07:25	jonpry:	the proof chain goes all the way back to genesis for one
19:07:32	jonpry:	which i think is maybe not in the whitepaper
19:08:02	gmaxwell:	jonpry: What does that accomplish? If the headers aren't know, then I can just make up anything there.
19:08:15	gmaxwell:	(because they don't have difficulty— they're not costly to compute)
19:08:48	jonpry:	i don't know. like i said, the headers are now stored. not sure what he was thinking when that was removed
19:09:28	gmaxwell:	fair enough
19:09:47	jonpry:	and we have difficulty it's just computed once a chain is connected
19:09:55	jonpry:	something about saving 32bits
19:10:20	gmaxwell:	jonpry: in any case, a non-transparent fixed blockchain state snapshot is a reduction in the security (requires greater assumptions about the honesty of the authors of them and the level of interest in users in verifying them, as Apocalyptic said he's never seen a user manually verify anything). Perhaps thats fine. .. at the same time, as I said, we also have tenative plans to remove or at least drastically reduce checkpoints in the ...
19:10:26	gmaxwell:	... reference software as part of headers first.
19:10:50	gmaxwell:	I don't see any great problem with it existing, I do hope people are cautious with the claims about it.
19:11:20	jonpry:	i'm pretty sure that people will just store all history until some point in the future
19:12:52	gmaxwell:	Considering the terrible state of mining centeralization shifting more trust on to miners— e.g. with unverified utxo schemes— concerns me greatly. Esp since like a lot of security is's kind of a lemon market, I can make less secure software that works fine until it doesn't.
19:13:44	jonpry:	the block won't verify if the utxo set is no good
19:14:09	gmaxwell:	Generally I hope that people eventually advance the ZKP stuff until we can use it to give people signtures that prove utxo correct, but thats not viable yet (too expensive to compute the proof).
19:14:33	gmaxwell:	jonpry: I can mine a bogus block and give it to you, if you're not verifying anything you can't reject it.
19:14:51	jonpry:	but all nodes verify utxo
19:15:09	gmaxwell:	if /all/ nodes verified it, there wouldn't be a point in having it. :)
19:15:47	jonpry:	obviously we have some difference in model of what is happening
19:16:31	jonpry:	we use UTXO set to sync nodes at some point in the past. checkpoint or whatever. once node has that. they can apply transactions from an incoming block to the set. rehash it and verify the block
19:17:03	phantomcircuit:	jonpry, not all nodes verify the UTXO, that is specifically what an SPV node is
19:17:52	gmaxwell:	jonpry: right, now I can give you a utxo that has an extra fake output that gives me a billion bitcoins. Then later I can give you a block that spends it. You'll have no way of knowing this was completely bogus.
19:18:44	jonpry:	the utxoset with fake output wouldn't be accepted by other nodes so it would shortly become orphaned
19:19:26	gmaxwell:	jonpry: sure. Who cares? you're bankrupt now, because I just deposited a zillion coins that never existed and then withdraw all your other coins (as an example).
19:19:43	jonpry:	i'm not sure if SPV nodes are required in miniblockchain since we are talking about orders of magnitude in reduction of the amount of data to be stored and difficulty of verifying blocks
19:20:04	jonpry:	maybe SPV nodes don't work
19:20:08	gmaxwell:	jonpry: storage reduction can be achieved without any of that.
19:20:23	jonpry:	everything that works in bitcoin is probably not going to work in MBC
19:20:24	gmaxwell:	SPV is a reduced security model— explicitly so. Which is fine and useful.
19:21:19	jonpry:	you could require huge depth merkle proofs for SPV
19:22:08	gmaxwell:	You can run bitcoind today with about 1gb storage... go remove the test for the blocks being there and simply delete the old blocks. So long as nothing tries to fetch the history from you (e.g. you don't have inbound or use history fetching RPCs) it works fine, verifies all new blocks, etc.
19:23:09	jonpry:	we can sync without downloading all that history. just need history back to checkpoint and utxo set
19:23:59	phantomcircuit:	he does have a point about checkpoints and just shipping with the utxo upto that point
19:27:45	jaekwon:	gmaxwell: Remember when we had the argument about new-users needing to have trust in tendermint or proof-of-stake algorithms? I said even new bitcoin users require trust, and you countered that they don't. I think we were both right… new bitcoin users can download a trusted copy of the client and wait indefinitely before connecting to the network for the first time. So trust is required in acquisition of the program or algori
19:30:49	Apocalyptic:	"needing to have trust in PoS algorithm" // for bitcoin ?
19:31:45	jaekwon:	no, altcoins that rely on pure PoS.
19:31:52	Apocalyptic:	I thought it was a consensus that PoS is fundamentally broken since it allows to mine multiple chains at the same time
19:32:43	jaekwon:	that's been true of existing pure PoS algorithms, but tendermint overcomes that. come to #tendermint if you want to discuss it though.
19:33:21	jaekwon:	it's still contentious here and it turns into a flamewar, which nobody wants on bitcoin-wizards.
19:33:49	gmaxwell:	gmaxwell has left #bitcoin-wizards
19:42:18	diesel__:	diesel__ is now known as Dizzle
20:20:17	andrew:	andrew is now known as justanotheruser
20:55:13	samson2:	samson2 is now known as samson_
22:21:48	andytoshi:	i have a couple questions about bytecoin's ringsigs: (a) is escrow or any sort of multisig possible, (b) does the utxoset just grow super fast because you can't tell which exact outputs are spent?
22:29:35	maaku:	maaku is now known as Guest40907
22:37:21	pangpang:	pangpang is now known as pen_
22:46:34	andytoshi:	ok, page 14 of https://cryptonote.org/whitepaper.pdf explains that multisig is possible, though it's not clear if it interacts well with the ringsigs