00:02:36	shesek:	Luke-Jr, reusing K values isn't really a weakness of re-using the same key
00:02:58	shesek:	but side channels attack are definitely made easier by key reuse, and could be a concern
00:03:21	shesek:	s/channels attack/channel attacks
00:20:00	iddo:	shesek: "made easier" is an understatement, if you don't reuse then attacker has 10mins on average to mount sidechannel attack (if miners are rational)
00:20:18	adam3us:	shesek: people should be using deterministic dsa
00:22:01	adam3us:	shesek: otherwise the dsa algorithm is quite fragile. bliechenbacher apparently discovered an rn bias problem in an earlier version of dsa and reported it to nist. vaudenay wrote about it in section 5 of https://www.iacr.org/archive/pkc2003/25670309/25670309.pdf
00:22:37	adam3us:	shesek: sorry section 2.2
00:23:10	iddo:	adam3us: btw only drawback of deterministic dsa that i could come up with is sidechannel attacks, actually, but it's pedantic
00:24:50	iddo:	dsa people made a mistake not to use determinsitic k in the algorithm, there are even papers that formally prove that it's at least as secure as random signatures
00:24:51	shesek:	adam3us, yeah, implementing rfc6979 for generating K values is on my todo list
00:25:17	shesek:	its implemented in vbuterin's bitcoinjs-lib, I'll be porting it to cryptocoinjs's ecdsa library
00:29:12	iddo:	posts #18 and #22 are why sidechan attack on rfc6979 is a non-issue: https://bitcointalk.org/index.php?topic=285142.0;all
00:30:29	iddo:	so i'm still vague on why DSA chose to go with random k, probably an oversight
00:31:08	jcorgan:	probably thought the entropy in K couldn't hurt things
00:31:40	iddo:	random k is supposedly the "most general" option
00:31:50	iddo:	but it does hurt things
00:32:27	iddo:	like linux routers without proper randomness of init boot, which led to attacks
00:32:40	sipa:	hmmm, does int(2^256 / x) == int((2^256-1) / x), for every x>1 ?
00:33:05	sipa:	nope, of course not
00:33:12	shesek:	jcorgan, can it? is something like H(privkey||data||random()) less secure than H(privkey||data)?
00:33:31	shesek:	or did you mean using a random source alone, without basing it on the key/data?
00:33:40	jcorgan:	^^
00:33:51	sipa:	shesek: i don't think mixing in entropy can hurt (assuming the hash function is good)
00:34:16	sipa:	but it's silly *not* to use the entropy you already have (message and private key, which together should be enough already)
00:34:48	iddo:	yes H(privkey||data||random()) is at least as good as anything else in terms of security, but not for testing implementations across machines
00:55:57	Luke-Jr:	[00:32:27] like linux routers without proper randomness of init boot, which led to attacks <-- if it isn't random, it isn't random.
01:01:22	iddo:	Luke-Jr: it was actually a bug in linux kernel, iirc linus fixed it after the attack was reported to him
01:02:01	iddo:	but none of this would have happened if dsa used deterministic k
01:02:57	Luke-Jr:	sure it would, you'd just have weak private keys instead
01:06:05	iddo:	maybe in that scenario, unless privkey was derived from hardware MAC address or something
01:06:51	iddo:	but in general, better to rely on randomness for privkey keygen once, and then use deterministic k
01:09:09	iddo:	i think android bitcoin clients re-use addresses, though mostly because of complexity, rather than source of entropy concern?
01:10:29	sipa:	yeah, because of backup concerns
01:13:00	iddo:	ahh, so bip32 will help
01:13:52	iddo:	but i though it's also because of complexity on lite device (to derive new key pairs) ?
07:03:20	zzyzx:	zzyzx is now known as roidster
10:17:18	nsh_:	nsh_ is now known as nsh
13:07:37	roidster:	roidster is now known as Guest86254
16:48:14	[-krypto-]_:	[-krypto-]_ is now known as [-krypto-]
19:55:08	phantomcircuit:	[20:13:52] but i though it's also because of complexity on lite device (to derive new key pairs) ?
19:55:21	phantomcircuit:	an argument could be made that fewer keys make an spv client more efficient
19:55:33	phantomcircuit:	however i cannot imagine the improvement is enough to justify the reduction in security
19:56:53	gmaxwell:	iddo: derriving key pairs has practically no complexity at all, it's cheaper than verifying a signature.
19:59:12	iddo:	hmm i suppose it's a single EC mult that you'd save, per keypair
19:59:51	iddo:	IIRC i remember that i read Mike Hearn mention once that android re-uses keys in part because of complexity, but maybe i mis-remember
20:01:22	gmaxwell:	if so, I suspect the complexity being referred to is simply that of the software doing the dumbest possible thing or not.
20:05:15	iddo:	BIP32 has the nice feature that you don't need to re-encrypt the wallet when you generate new addresses, but yes, nothing is more efficient than using only a single key
20:06:40	gmaxwell:	iddo: thats not true
20:06:56	gmaxwell:	iddo: it would be more efficient to not use ECDSA at all, and to simply hashlock your coins.
20:07:21	iddo:	but then miners can steal when you try to spend?
20:07:57	gmaxwell:	Sure but if you're making a user privacy/security tradeoff to avoid the <1ms it takes to compute a new key then that implicitly says you care so little about security that the hashlocking would be an even better tradeoff. :)
20:08:28	iddo:	not just miners, any node can re-broadcast your preimage and attach a higher fee (assuming that miners will be rational)
20:09:15	gmaxwell:	yup. And anyone can interlink all your payments if you don't use new addresses. It's a much larger speedup!
20:09:53	gmaxwell:	(seriously, any developer that intentionally reuses keys because they think there is a performance consideration needs to turn in their tools: they have no business writing software for other people to use)
20:10:58	iddo:	yes, i like the example where even if the user doesn't care at all about his own privacy, he buys a toaster and donates to wikileaks with same key, and now toaster shop own might not like it that his customers are associated with wikileaks, etc.
20:11:39	gmaxwell:	Yes, sadly there is no place where losing the privacy is completely harmless due to network effects.
20:12:09	nsh:	* nsh tries to elaborate a pollution analogy to explain this
20:12:16	nsh:	(not very successfully, so far)
20:12:45	iddo:	so what's the current state of android wallets? they use a single key? or random keys? i supposed that BIP32 isn't deployed yet?
20:13:22	gmaxwell:	No idea, I've never used it. I believe they _will_ be moving to BIP32 but I don't believe they have yet.
20:13:55	sipa:	single random key
20:14:18	jaekwon:	random question…. besides proof of solvency (assets + liabilities), is there an easy way to prove that an exchange only executed valid orders ( and thus that its reported liabilities are correct ) ?
20:14:19	iddo:	sad current state of affairs :(
20:15:45	gmaxwell:	jaekwon: Without knowing what aspect of proof-of-solvency you're trying to avoid it's hard to suggest anything else.
20:16:49	gmaxwell:	usually its the assets that the commercial folks don't want to disclose.
20:17:15	iddo:	jaekwon: what would be an example of an invalid order?
20:17:43	jaekwon:	gmaxwell: I'm not trying to avoid proof-of-solvency, rather, do something more…. that is, prove to a third party that all of its reported liabilities are correct, such that say, the exchange could run on a sidechain, and the mainchain can know that the withdrawal requests are safe to process. since the assets are in the mainchain, its assets are already disclosed and under control.
20:18:57	jaekwon:	iddo: if the sidechain (or exchange) tried to "withdraw" a ton of coins to some address, even though no account of that exchange actually has that many coins, that's the main "invalid" order i'm trying to prevent. does that make sense?
20:19:09	gmaxwell:	jaekwon: well thats pretty easy then. Every user's transaction must be signed by a private key known to the user and not the service.
20:20:13	jaekwon:	gmaxwell: yes, and it should also be committed in the sidechain. but i'm thinking of a sidechain (with 1 signer, centralized exchange) that processes a LOT of transactions per second, such that the mainchain can't afford to verify the entire blockchain by scanning it.
20:20:26	gmaxwell:	Then don't verify it.
20:20:52	gmaxwell:	It still gives you public disclosure, which means you can do a federation of multiple signers that only sign valid appends to the log.
20:21:14	gmaxwell:	Which is a catagorical improvement over anything else that exists today, at least if you believe some of the signers are really independant.
20:22:06	iddo:	objective of an exchange is to do price discovery in real time? bids/asks that get added/removed would need to be signed? sounds complex
20:23:25	jaekwon:	hmm...
20:25:23	gmaxwell:	iddo: if you're not seeking to prove that the service doesn't reorder orders, then the only thing that needs to get recorded is the trades that actually execute.
20:26:39	jaekwon:	if you had say a million exchange users, and the exchange kept an updated list of "user balance states" that each user must sign before submitting an order, and there was enough information for each user, such as the balances & the possible bounds based on the last set of orders….
20:27:02	jaekwon:	maybe just a couple hundred megabytes to capture an updated state of all the liabilities?
20:28:08	jaekwon:	at least the users who have a lot of funds in the exchange & haven't done crazy trades, would have most of their funds guaranteed, or something like that.
20:28:17	gmaxwell:	e.g. you setup some threshold scheme where the service and 3 of 5 auditors have to sign their blocks... the service matches orders and seralizes them out, signs the result and sends it off to the auditers... the auditers can keep an independant tally of balances... and every block could include a summary so a newly syncing auditer doesn't have to start from the beginning.
20:28:59	iddo:	i still don't exactly see what these extra proofs give? compared to just proving that the exchange owns coins that sum up to its users balances
20:29:16	iddo:	BTW how does the exchange proves that it owns the correct fiat amount ?
20:29:39	gmaxwell:	It doesn't— all it can do there is have audits performed.
20:29:47	justanotheruser:	Is there any way to force these services using op_return to collectively use one op_return tx and construct their merkle tree with that one tax having the root?
20:29:51	jaekwon:	iddo: that works because each user is doing the verifying… i'm looking for the mainchain (miners) to verify withdrawal requests from the exchange.
20:30:16	justanotheruser:	s/tax/tx
20:30:17	gmaxwell:	justanotheruser: no, that is one of the arguments against having OP_RETURN IsStandard.
20:31:03	gmaxwell:	iddo: there are a couple problems with the proof of solvency stuff— it's not realtime, for example, — you can prove you are solvent and then in the next moment take all your coins to vegas.
20:33:01	iddo:	gmaxwell: i think there's a substansive difference between ZK proof that you own coins, and non-private proof where you simply publish signatures for the addresses that you control... if it's the latter then users can see whether these coins will move ?
20:33:57	gmaxwell:	iddo: not really, because there is not a 1:1 mapping between coins and users. If some coins move, but not so many that even mine aren't left, then how do I know it was a go-to-vegas and not just a bunch of withdraws?
20:33:59	iddo:	(by ZK proof i mean do these same signatures, but run it as a zk-SNARK)
20:34:26	iddo:	ahh
20:34:49	gmaxwell:	the idea proposed above with the external audits lets you tell if a withdraw was authorized by its user or not. (Of course, in theory, such a system could be run under a zkp and remain honest to... but wow, lots of computation for that. :) )
20:36:06	jaekwon:	the updated-snapshot-of-userstate seems promising too. it requires no auditors and can protect some large fraction of each user's coins.
20:37:30	gmaxwell:	jaekwon: if you go look at the very beginning of the logs for this channel you can see petertodd and I discussing, at length, ideas around what would be required to make an anonymously operated IRC tipbot more trustworthy.
20:37:52	gmaxwell:	some of that will be applicable to your thinking.
20:37:52	jtimon:	gmaxwell if you publish all your deposits on a private chain, you can provide a new proof of wonership after each desposit/withdrawal, proving that deposits in the private chain (IOUs for the user, liabilities for the gateway) equal bitcoin reserves
20:38:13	iddo:	still, if an exchange proved without ZK that it controls e.g. 200k coins without privacy, and you see that say 190k coins are still unmoved (until next time that the exchange does the proof), then you'd know that most of the coins are not stolen (yet)
20:38:19	jaekwon:	thanks gmaxwell.
20:39:22	jaekwon:	jtimon: hi, we're on similar wavelengths here.
20:39:23	gmaxwell:	iddo: of course at the point its still too late.
20:39:59	jaekwon:	jtimon: i'm wondering if you can do that without requiring the main chain to scan the *entire* sidechain blockchain history. something to make that faster.
20:40:24	jaekwon:	jtimon: because, some exchanges will have a *lot* of orders going through, probably more than the main chain itself.
20:40:37	jtimon:	the users may have many addresses for the each users so user's balances don't have to be known even if the entire private chain is published
20:41:23	jaekwon:	jtimon: that's true.
20:42:03	jtimon:	jaekwon I'm not sure what you mean by sidechain and mainchain in this context, I think you call "exchange" what I call "private chain"
20:42:14	jaekwon:	yup.
20:42:46	jtimon:	and you don't need 2-way peg for what I'm saying
20:43:26	jaekwon:	i want the 2-way peg.
20:43:36	jtimon:	on another topic, any thoughts on this? http://www.theregister.co.uk/2013/11/03/crypto_boffins_propose_getting_rid_of_cas/
20:43:40	jaekwon:	jtimon: i call it a sidechain because, there's a mainchain from which deposits go into the "sidechain" via moving funds to the "sidechain address". For the exchange to process user withdrawals, i want the mainchain to first verify to some degree that the withdrawal requests are valid.
20:44:38	iddo:	instead of all this business of moving your coins to centralized control of an exchange, wouldn't it make more sense to convert fiat to some kind of colored coins (where 1 colored coin = $1), and have decentralized exchange, if we could somehow have reasonable assurance (backing by the community?) that those colored coins could be converted back to dollars?
20:44:57	gmaxwell:	iddo: all you've done there is added indirection that reduced efficiency.
20:45:22	iddo:	hmm
20:45:23	jaekwon:	iddo: also, a centralized exchange is still needed to process the volume of orders at the speed that i'm interested in.
20:45:31	jtimon:	iddo you could easily do that on a p2p chain, unless you want a million tps
20:45:47	gmaxwell:	and indeed, the fast order matching is still neded for price discovery.
20:46:12	gmaxwell:	jtimon: a million is by far an overstatement of what you can do on a "p2p chain".
20:46:33	iddo:	gmaxwell: if that colored coin is respected by many different entities, then it's more secure to convert fiat to this colored coin, instead of trusting a centralized exchange, not?
20:46:35	jtimon:	that's my point, you will need a private chain if you want 1 M
20:46:46	gmaxwell:	10k tps is probably doable on something which isn't really p2p but is more like auditers.
20:47:26	gmaxwell:	iddo: no, all that does is create a bigger systemic risk. MTGox's green addresses didn't make bitcoin more secure. :) (fortunately they'd turned off that service before going tits up)
20:47:48	jaekwon:	i believe i just proposed a way to do this on the private chain at 100k tps without the need for auditors, while having a high level of security.
20:47:57	gmaxwell:	jaekwon: you did not.
20:48:05	gmaxwell:	(at least if you did I missed it entirely!)
20:48:42	jaekwon:	np, it was easy to miss. and i didn't write everything down. let me write a full draft and paste it…
20:49:04	jtimon:	gmaxwell I believe 1 M tps is doable in a private chain
20:49:16	jaekwon:	jtimon, nobody is disagreeing with you.
20:49:18	phantomcircuit:	gmaxwell, iirc petertodd was talking about having essentially a large number of secondary exchanges which would operate independently to bring total throughput to whatever number you wanted
20:49:23	phantomcircuit:	although i argue that's cheating :P
20:49:29	gmaxwell:	jtimon: anything is doable in private. :)
20:50:27	gmaxwell:	I was just objecting to "1M" in connection with P2P, especially since a state of the art cpu can only does about 10k verifies per second per core.
20:51:09	jtimon:	gmaxwell you also need to verify signatures in a private chain
20:51:17	gmaxwell:	jtimon: yes but you can throw hardware at it.
20:51:37	gmaxwell:	where as anything rightfully called p2p can't really expect there to be 50k in hardware at each peer just doing ecdsa verification. :)
20:52:11	gmaxwell:	(hell, it seems hard to get miners to keep accurate clocks or run on anything more powerful than a rpi... :) )
20:52:12	jtimon:	ok seems we agree on everything
20:52:45	iddo:	gmaxwell: can you elaborate on systematic risk? i'm thinking of different exchanges offering services to deposit/withdraw this colored coin for dollars, with different fees that each such service offers depending on how it operates, but all these services agre to respect that this colored coin = $1 ?
20:53:55	gmaxwell:	iddo: uh becase one of those parties goes dishonest and creates double the existing coulred coins without having the dollars to back it up.. then vanishes.
20:54:04	gmaxwell:	and now all the other parties are insolvent
20:54:27	iddo:	ahh
20:54:31	iddo:	right :(
20:55:00	jtimon:	iddo gatewayAusd and gatewayBusd are different assets, they're not fungible
20:55:19	gmaxwell:	well if you make them fungible you have the potential for resulting doom. :)
20:55:51	iddo:	yes, i don't see any good ways to exchange fiat for cryptocurrency without a centralized service :(
20:55:57	jtimon:	if gatewayA runs with the money gatewayBusd holders don't need to be affected
20:57:20	jtimon:	iddo a p2p exchange in a public chain with fiat gateways would work just fine, it would just be very slow compared to a private server/centralized system
20:57:33	gmaxwell:	iddo: if there were you could just eliminate the cryptocurrency entirely and the system would just be a payment network for fiat.
20:59:11	iddo:	jtimon: this fiat gateway is centralized, so it sounds like just an inefficient regular fiat/bitcoin exchange, does it have any advanages do have this gateway?
20:59:26	phantomcircuit:	oops
20:59:38	phantomcircuit:	firmware upgrade on hundreds of ct boxes without delay
20:59:43	phantomcircuit:	inb4popallthebreakers
21:00:00	nsh:	ct?
21:00:10	phantomcircuit:	cointerra
21:00:12	jtimon:	iddo how does centralized imply unefficient? the gateway and private chain operator don't need to be the same entity
21:00:15	nsh:	at
21:00:17	nsh:	*ah
21:01:15	jtimon:	and what you gain using private chains instead of opaque servers is more "trustlessness"
21:01:39	jgarzik:	centralized is usually highly efficient, but not resilient
21:01:51	iddo:	jtimon: what does this gateway offer? exchange fiat for a colored coin that it issues? why would users wish to do this, instead of directly exchanging fiat for bitcoins?
21:01:56	phantomcircuit:	jtimon, in practice if you have a coin that is backed by some issuer the only thing you gain is the ability to trade it w/o the issuer controlling the exchange
21:02:00	jtimon:	if you add 2 way peg you can have truly irreversible transactions even in private chains
21:02:15	phantomcircuit:	except in practice most issuers restrict who can own something because of redeemability
21:02:24	jaekwon:	* An exchange has a publicly known deposit address in the main chain.
21:02:24	jaekwon:	* Users deposit by simply moving funds to the exchange address.
21:02:25	jaekwon:	* The exchange operates in a side chain with itself as the sole signer for all blocks.
21:02:25	jaekwon:	* Users, when submitting an order to the exchange, signs the order. the data signed include: current balances, and based on the limit-order price & amounts submitted so far, a short description of the possible bounds for its balance after any number of the user’s orders go through.
21:02:25	jaekwon:	* The point is, the user signs a short data structure that represents a totality of possible future states. For example, if the user never submits orders where the limit sell price is 0, then the user can never end up with zero coins.
21:02:25	jaekwon:	* The exchange publishes the block chain of all the orders, but also publishes (and signs) a snapshot of all the signed user states, which serves as a proof-of-liabilities-now-and-later.
21:02:25	jaekwon:	* Withdrawals are signed by the exchange and submitted to the main chain in batches, along with the most recent snapshot. Withdrawals simply go back to the originating user address.
21:02:26	jaekwon:	* The main chain does not process withdrawals that violate the bounds as signed in the snapshot (by the exchange and also by each user).
21:02:40	phantomcircuit:	ie lets say issue PCUSD
21:02:47	phantomcircuit:	and some iranian dude in tehran gets some
21:02:52	jtimon:	"why would users wish to do this, instead of directly exchanging fiat for bitcoins?" because paper bills are hard to send through the internet and trade atomically and trust-lessly for bitcoins online?
21:02:54	phantomcircuit:	i cant redeem the PCUSD for USD
21:03:50	jaekwon:	And lots of details omitted, but that's the general idea i'm going for.
21:04:13	iddo:	jtimon: but what about someone who currently only has fiat ? do you agree that he would prefer to exchange this fiat for bitcoin, rather than for this centrally-issued colored coin ?
21:05:07	phantomcircuit:	not to mention a broad reading of us law would say an issuer of such a redeemable coin was engaged as a money transmitter anyways
21:05:11	jtimon:	iddo depends on a lot of things, does he need high volumes? need to make the trades online?
21:05:19	phantomcircuit:	so you might as well just be an mt
21:06:08	jtimon:	maybe he wants to have the gatewayUSD to have them ready to buy BTC but doesn't want to expose to btc price risks yet
21:06:12	iddo:	jtimon: but his initial step is to send his fiat somehow, so why would he want to receive in exchange the centrally-isued colored coin, instead of receiving bitcoins ?
21:06:18	jaekwon:	gmaxwell: the above pasted thing is the protocol that requires no auditors.
21:06:54	jtimon:	iddo basically currency risks
21:07:15	phantomcircuit:	iddo, assuming the issuer of the USDcoin was 100% trustworthy, the USDcoin would probably me more useful than any other form of USD
21:07:17	jtimon:	well, liquidity really
21:07:23	phantomcircuit:	however that is a pretty massive assumption
21:07:47	phantomcircuit:	i should mention that this model is almost exactly how liberty reserve operated
21:07:55	phantomcircuit:	and that did not end well
21:07:56	jtimon:	he exchanges the fiat paper or fiat deposits in a bank for fiat deposits on a gateway (which could actually be a bank)
21:08:22	jcorgan:	exit
21:08:23	phantomcircuit:	jtimon, you realize bearer bonds are illegal in most countries right?
21:08:37	phantomcircuit:	so a bank could not issue you coins
21:08:42	phantomcircuit:	as they are effectively bearer bonds
21:09:01	jtimon:	yes, not in some countries like saint vincent and the granedines, but yes
21:09:50	jtimon:	phantomcircuit that's why freimarkets has "authorizers" to support legally complaint fiat deposits
21:09:56	iddo:	i agree with what phantomcircuit said about if USDcoin issuer was 100% trustworthy, then jtimon's advantages make sense... but things get much more murky in reality because issuers aren't trustworthy
21:10:33	iddo:	maybe it could work in the context of some reputation system
21:10:59	jtimon:	iddo: what does it need to be 100% trustworthy most money is not paper but bank deposits so "as trustworthy as a bank" should be enough it seems
21:11:45	jtimon:	people even trust prepaid balances in phone companies when they're allowed to be transmitted (see m-pesa)
21:11:53	gmaxwell:	jaekwon: sorry, what you're saying is still not clear to me. How can you succinctly produce a proof which distinguishes a new valid user joins in and buys 1 btc from each of 10000 different traders then withdraws it, from the exchange stealing 10000 btc?
21:13:08	iddo:	jtimon: there's difference between offering fiat money services to your clients (in terms of law enforcement), and offering to give a colored coin to your clients and ask them to assume that you'd convert this colored coin to fiat in the future
21:13:47	jtimon:	what you mean by fiat here? bank deposits?
21:14:02	jtimon:	why not? what if the gateway and the bank are the same entity
21:14:04	jtimon:	?
21:14:44	jtimon:	do you trust their IOU more if it's only on their centralized serrver than if it exists as a colored coin?
21:15:17	jtimon:	it's just a number in a screen they say they owe you, nothing more
21:15:28	jtimon:	in both cases
21:15:48	iddo:	jtimon: well, if the bank will give a colored coin to its customers, that sounds nice... no bank does that though, right?
21:15:52	jaekwon:	gmaxwell: the main chain knows all the withdrawals, so that's easy. the main chain also knows that the user couldn't have ended up with 100000 BTC after trades, because none of the other users ever signed their balances-and-bounds-for-possible-future-balances that give room for a loss of 100000 BTC.
21:17:28	jaekwon:	does that make sense? lets say, the exchange only ever received 100000 BTC in deposits. the mainchain knows this. and in order for the mainchain to process a complete withdrawal of all BTC to a single user's address, it would first have to see a signed thing from all users who ever deposited BTC into the exchange, that they created trades that allowed them to lose all of their bitcoins.
21:17:42	jtimon:	iddo no, it would be illegal with non-authorized colored coins (you would need authorized assets like in freimarkets)
21:18:03	jtimon:	iddo but what's so different about the company owing you being a bank?
21:18:06	jaekwon:	gmaxwell: The exchange of course would require all users sign such things on every order. I think this protocol works!
21:19:33	jaekwon:	gmaxwell: oops, *the mainchain knows all the DEPOSITS.
21:19:52	jtimon:	iddo you at least have some chance of the gateway having 100% reservees if the company it's not a bank ;)
21:20:14	jaekwon:	gmaxwell: so it knows the initial condition for all users who ever deposited to the exchange, so the mainchain expects at least that in the snapshot, or something more recent as signed by that user.
21:20:56	iddo:	jtimon: if someone owes you a colored coin, and he refuses to pay, the judge may decide that the market value of this colored coin is zero, so you'd lose?
21:21:19	phantomcircuit:	jtimon, authorizers do not avoid the fundamental compliance issue
21:21:39	phantomcircuit:	the issuers would need to be financial institutions of some kind
21:21:48	gmaxwell:	jaekwon: I don't see how the proof is compact. Sorry.
21:21:57	phantomcircuit:	at which point they have very little advantage over simply being used as a bank
21:22:13	jtimon:	iddo unless the colored coins it's backed by a legal contract that makes it equivalent to a paper IOU
21:22:34	jaekwon:	gmaxwell: it's O(number of users). It's much shorter than the sidechain. It's practically at most a couple hundred megabytes.
21:23:06	gmaxwell:	jaekwon: you are not putting a couple hundred of megabytes in a transaction.
21:23:38	jtimon:	phantomcircuit "at which point they have very little advantage over simply being used as a bank" their deposits can be atomically traded for a lot of other p2p issued assets, tha's an advantage!
21:23:57	jaekwon:	gmaxwell: it's a thing that can be pruned except the last valid one (or two).
21:24:19	jaekwon:	gmaxwell: well, i think just one. so each snapshot doesn't need to reside in the blockchain.
21:24:31	jtimon:	phantomcircuit you integrate your deposits on a useful trading network which allows new possibilites like smart concert tickets and other cool stuff
21:24:54	gmaxwell:	jaekwon: I still can't see how this results in a succinct proof. To process a single withdraw you need to show the fidelity of all contributing balances, which may potentially have exponential size due to prior trades.
21:25:04	iddo:	jtimon: so initially the user has fiat only, he exchanges the fiat for a colored coin created by the issuer, how will he also obtain this legal contract ?
21:25:13	phantomcircuit:	jtimon, shrug
21:25:50	justanotheruser:	Is it an abuse of then
21:25:55	jaekwon:	gmaxwell: exponential size? it's a small thing for every user, period. nothing that grows with past trades.
21:26:15	phantomcircuit:	clearly i should start a new merged mined coin 100% premine it w/o block reward (tx fees only) and then issue them as redeemable 1:1
21:26:20	phantomcircuit:	for dollars
21:26:21	jaekwon:	gmaxwell: and, it should be batch withdrawals from the exchange, say once every hour or day.
21:26:23	jtimon:	the issuer can sign a contract that says "I owe fiat for the amount specified to any holder of this p2p asset I'm issuing"
21:26:38	justanotheruser:	Sorry. Is it abuse of the blockchain to have a service built on the block chain with a single daily opreturn containing the merkle root?
21:27:23	gmaxwell:	jaekwon: You haven't defined it well enough for me to follow. I hear you making these assertions but I do not see how they are true.
21:28:47	iddo:	jtimon: ok... if digital signatures are respected by courts
21:28:58	jtimon:	phantomcircuit you can just issue it on an existing side chain that supports asset issuance, don't you want the withdraw and transaction fees? Bitstamp is already doing something very similar on ripple.com with the only difference that ripple.com is not really p2p like pow
21:29:29	jaekwon:	gmaxwell: sorry, let me try to define it better. a snapshot is a thing that the exchange publishes every hour or day, along with batch withdrawal transactions. it consists of at most some 200 bytes of data signed by each user of that exchange.
21:29:47	jtimon:	iddo in my country everybody is mandated to carry an id at all times which has an electronic chip which supports legally valid digital signatures
21:30:48	jaekwon:	gmaxwell: that 200 byte thing represents the user's current balance along with a succinct (lossy) representation of all of its pending limit orders.
21:31:16	iddo:	jtimon: nice... but in more common scenarios there's a problem of identity, i.e. you'd need to trust the website's pgp key or something..
21:31:19	jaekwon:	which was signed by the user, submitted to the exchange when the user submitted the order.
21:32:28	jtimon:	iddo of course you need to trust the issuer, as said, just like you trust your bank and your phone company if you use prepaid services, just like nigerians trust m-pesa
21:32:42	jaekwon:	let's call that 200 byte thing, a waiver. the waiver was signed by the user, allowing the exchange to match trades and adjust balances, as long as the resulting balance for the user fits within the bounds as set forth in the waiver.
21:33:05	jaekwon:	the snapshot is a set of all the waivers for all users who ever deposited funds into the exchange.
21:33:08	jtimon:	just like you trust that the pub owner will honor his free beer coupons
21:33:12	gmaxwell:	jaekwon: right, so you can steal 100% of the coins available for order but no more.
21:33:26	jaekwon:	something like that, yeah!
21:33:29	gmaxwell:	jaekwon: unfortunately you have proofs O(N) on the number of people with outstanding limit orders.
21:34:20	jaekwon:	gmaxwell: yup. should take some processing time, say a minute or so to verify.
21:34:35	gmaxwell:	This is not acceptable in the public blockchain, however.
21:34:50	jaekwon:	you don't need to store historical snapshots.
21:34:55	jtimon:	jaekwon what's so wrong about updating the solvency proofs every time there's a deposit/withdrawal (that can be at most every bitcoin block) ?
21:35:08	gmaxwell:	who cares about storage? you still have the bandwidth and computation.
21:35:28	jaekwon:	oh, this isn't for bitcoin. :)
21:35:45	jtimon:	whatever, xcoin
21:36:36	jtimon:	whatever you're calling the "mainchain" you will have deposits for in your private chain
21:37:01	gmaxwell:	effectively you've proposed a two stage system where you have a secured system where users funds can't be stolen, but also can't be traded, where they can instantly move a portion of their balance to an insecured system, where funds can be stolen or traded.
21:37:04	jaekwon:	not in the ripple model, with gateway ious. all the deposits are in the mainchain.
21:37:43	jaekwon:	gmaxwell: i would call it a partially secured system.
21:38:07	jtimon:	mhmm, can you give us a trading pair example? LTC/BTC?
21:38:13	jaekwon:	gmaxwell: and it doesn't even need to publish a blockchain, so it can go ahead and run 1M trades per second.
21:39:10	jaekwon:	gmaxwell: come on, you kinda like it for its own sake.
21:39:31	gmaxwell:	jaekwon: I'm not saying I like or don't like it. It's a lot less secure than the thing we discussed above with full auditing.
21:39:42	jtimon:	jaekwon the balances/deposits in your 1M tps private chains are IOUs unless you're doing 2-way peg
21:39:56	jaekwon:	gmaxwell: well you haven't solved anything with auditors. you've only moved the problem.
21:40:34	gmaxwell:	jaekwon: You really have, you can make a fundimentally different claim about what threat is needed to cause theft.
21:40:41	jaekwon:	i've completely partially solved the problem, and my thing allows for arbitrary speed, that auditors maybe can't afford to run.
21:40:45	gmaxwell:	(also, it's not incompatible with the two stage thing you're suggesting)
21:41:04	gmaxwell:	jaekwon: I don't think you really have, alas.
21:41:25	jaekwon:	gmaxwell: how not? what's the problem?
21:41:27	gmaxwell:	Compare what you're talking about with some of the multisignature stuff people are currently talking about implementing (not sure if anyone has actually deployed it yet)
21:42:11	gmaxwell:	jaekwon: basically you have fully centeralized non-security for all of the funds which have active orders, which are really the only funds with had any real reason to be on deposit in any case.
21:42:12	jaekwon:	gmaxwell: yeah, i've thought a lot about it. i was going to launch an exchange platform, in partnership with one well known startup working on multisig escrow.
21:43:09	gmaxwell:	So basically it is exactly the same security model that the multisig escrow things have— basically funds which are on quasi-deposit are secure but can't be traded, when you sign them over to an active order, you lose your security for that portion of the funds.
21:43:47	jaekwon:	gmaxwell: like i said, partial security. if the user only signs limit orders with sane prices, the 200 byte waiver can capture enough information that most value is preserved.
21:44:03	gmaxwell:	I don't think that follows.
21:44:27	jaekwon:	lets say i deposited 100 BTC.
21:45:34	jaekwon:	then i create 100 orders to purchase 1 CTC for prices between 1BTC and 1.2BTC, each order is small, say 0.01 BTC total each.
21:46:26	jaekwon:	my waiver would say that i have 100 BTC, and I will still have at least 99 BTC after all of my orders have executed, and for each BTC gone, i should have at least 0.8 CTC, or whatever.
21:47:13	gmaxwell:	Great, now I steal the 0.01*100 = 1 BTC you had on order (which you could have just only deposited 1 BTC, or done multisig escrow). You don't have the 0.8 CTC in any case, but the spend was authorized.
21:47:51	jaekwon:	I must have the 0.8CTC. it says so in the waiver.
21:48:13	gmaxwell:	Bitcoin has no fucking idea if you have 0.8 CTC or not.
21:48:24	jaekwon:	this isn't fucking bitcoin.
21:48:35	jaekwon:	this is a fucking distributed exchange platform with its own coin.
21:48:55	jaekwon:	and BTC/CTC are IOUs on some trusted gateway.
21:49:03	gmaxwell:	gmaxwell has kicked jaekwon from #bitcoin-wizards
22:07:40	jtimon:	ugh, "why freicoin doesn't add fast transactions like quark and is based on the old bitcoin instead?" http://freicoin.freeforums.org/viewtopic.php?f=14&t=796
22:08:30	gmaxwell:	"9 rounds of encryptions!"
22:08:51	gmaxwell:	notice the person's username
22:09:03	gmaxwell:	I suspect thats shilling, not an honest question.
22:10:00	Emcy_:	speak of fasts txn
22:10:06	Emcy_:	sidechains can be nested right
22:10:13	gmaxwell:	jtimon: notice it also here: http://www.reddit.com/r/freicoin/comments/23jat7/why_bitcoin/
22:11:14	jtimon:	Emcy_ I think I know what you're going to say...
22:11:51	Emcy_:	sidechains all the way down
22:12:12	jtimon:	didn't even knew freicoin had reddit...
22:12:53	gmaxwell:	jtimon: nor did I, I googled a chunk from his message because it gave me a spammy vibe.. I expected to see it repeated elsewhere.
22:13:49	Emcy_:	are you really saying that reddit is a hive of shills
22:13:55	jtimon:	Emcy_ yes, suddenly it comes to mind that 10 minutes could actually be "too fast" and you want it to be just 2-aypegged from a slower more secure 20 min chain chain, with comes from a 1 hour block chain....
22:13:58	Emcy_:	is that what you are implying here sir
22:14:21	Apocalyptic:	are you really saying that reddit is a hive of shills // how surprising
22:14:26	Apocalyptic:	who would have thought of that...
22:15:29	Emcy_:	reddit as a whole is pretty directed shall we say, it has enough readership towarrant it
22:16:03	Emcy_:	and the posts that arnet you can tell because theyre just "this little guy" cat posts or shitty lazy image macros
22:21:19	jaekwon:	So, I'm developing a distributed exchange & coin consensus protocol. If you want to hear more about it, join me at #dxp .
23:06:33	jtimon:	have you read our p2p exchange + trust-less private servers proposal ? join us at #freimarkets
23:37:39	midnightmagic:	ooOOoo trustless private servers?
23:39:38	jaekwon:	where is this proposal?
23:41:35	sipa:	i believe a summary was posted to bitcoin-development
23:48:17	jaekwon:	not sure how this private server audit log works.