01:31:45	kanzure:	andytoshi: do you have a paper that enumerates the various bitcoin incentives?
02:22:17	gmaxwell:	andytoshi: we've got a N of M non-interactive schnorr approach (with interactive setup) that produces a indistinguishable from 1 signature and does not require a trusted dealer; Thanks to Dan Boneh applying a clue stick to us. .. it's all signer side, requires no fancy verifer logic.
02:23:20	gmaxwell:	I'd say its "obvious" if you're sufficiently frank about your actual security assumptions when establishing the threshold, that no N of M are compromised.
02:23:29	sipa:	it has comb(m of n) computation/network overhead, though
02:23:34	sipa:	at setup time
02:23:54	sipa:	but is equal to n-of-n schnorr threshold signing at runtime
02:24:32	gmaxwell:	(maybe you'd like to come up with it on your own from these hints, so I'll refrain from just giving it to you until you ask)
02:25:16	sipa:	it does make the assumption that keys are single use, though
02:25:35	midnightmagic:	i like dan boneh's lectures, he's easy to listen to
02:25:55	gmaxwell:	sipa: I'm not sure that it does. /me goes to hash it out with sipa in pm
02:28:33	gmaxwell:	sipa and I have resynced and I would clarify "not single use, but you generate keys as a result of the interactive setup and shouldn't use them outside of the context of signing with the group you just created"
02:28:49	sipa:	ac
02:28:50	sipa:	k
02:30:12	gmaxwell:	(because doing so might compromise your security; kind of a silly example, but good, from sipa:... if you use a key in a 1 of 3 in this procedure; you best not use it elsewhere if you don't want the two other signers running off with your coins.)
02:34:12	phantomcircuit:	gmaxwell, you have a clever way for a pool to prove it's hashrate?
02:34:51	sipa:	phantomcircuit: p2pool :p
02:35:26	gmaxwell:	phantomcircuit: sure. Just publish shares just like miners prove themselves to pools. Adjust difficulty for an acceptable bandwidth vs variance tradeoff
02:36:37	gmaxwell:	The log scaling spv proofs would also work and make much smaller low variance proofs of work... but also probably more work to implement than is justified for that application.
02:38:02	phantomcircuit:	gmaxwell, hmm
02:38:03	phantomcircuit:	can do
02:38:10	phantomcircuit:	bandwidth is irrelevant
02:38:15	phantomcircuit:	unmetered lines ftw
02:39:42	gmaxwell:	you'd want to have the pool's name in the work (or at least H(poolname,nonce)) so it couldn't be forged by buying shares from someone else... or some other method (e.g. paying to a known address)
02:40:51	gmaxwell:	amiller_: wrt ecological privacy; you can see petertodd and I making a similar argument for creating auditing motivations for off chain systems in the very first discussion in this channel in the logs.
02:42:41	gmaxwell:	In it we were talking about off chain systems secured by auditing and fiedlity bonds, with things similar in design to the proof of solvency used for auditing... but how do you make sure the users reconcile their balance and the audit logs? You require them to sign statements from time to time; and if they don't-- the rules of the system allow the 'bank' to reclaim their funds. E.g. instutionalize the fraud you can't prevent.
02:43:41	gmaxwell:	I suspect it's hard to do for privacy. In that e.g. if you make it some if party X can link your coins he can steal them, EvilBank could just decline to steal them; lest they lose their reputation and their ability to monitor everything.
02:57:58	gmaxwell:	amiller_: plenty of services where the user gives up their privacy also let the users know their own private keys.
02:58:46	amiller_:	gmaxwell, yeah, i have even less of an idea how to approach that part
03:00:57	amiller_:	gmaxwell, something along the lines of, if someone can identify your deposit to your withdrawal, then they can take your lottery tickets
03:02:52	gmaxwell:	lets assume we have a accumulator that has the property that you can add key value pairs to it, but if a duplicate is added a random one wins. Then we pick values to be the lottery winners.
03:03:09	gmaxwell:	in this way if someone else knows your private key, they can secretly lower your lottery odds.
03:05:02	gmaxwell:	really, even there they will just promise to play nice. already lots and lots of people happily keep coins in places where they have little or no evidence the coins aren't actually gone.
03:05:17	gmaxwell:	much less some reduced lottery payout.
03:10:04	gmaxwell:	really the classical solution to this kind of ecological problem is to prohibit it via regulation; or for industry self orginization to stamp it out (reputation, best practices, standards, etc).
03:11:34	amiller_:	well, you could have both
03:12:56	dgenr8:	imo the point is to get people to take matters into their own hands and put less in custody
03:13:23	gmaxwell:	well those don't seem likely to work for us in the nearterm in any case, since they require powerful instutions to act; but the self-same groups are hurt the least (or benefited the most) by the bad practices... so it's asking the foxes to guard the henhouse. alas.
03:14:00	dgenr8:	a la the GLD ETF
03:15:39	dgenr8:	the game played with custodial deposits is to sell them to drive the price down
03:16:31	dgenr8:	it will be a shame if COIN does not choose to prove reserves
03:20:08	gmaxwell:	One of the motivations behind the previously proposed proof-of-parked-coins for admission control to things like bitmessage was the idea of making coins in your control more valuable.
03:21:33	gmaxwell:	though ... I can just see now people wanting to use some system that was coin ownership controlled, but not wanting bitcoin volitility exposure; so they buy coins to use (hurray) then short COIN to cancel out the exchange rate risk... "unanticipated consequences"
03:32:04	dgenr8:	amiller_, speaking of bitmessage, the lottery site could require a bitmessage to claim a prize. or just let them comment on it.
04:25:39	jgarzik:	jgarzik has left #bitcoin-wizards
05:07:45	grandmaster:	grandmaster is now known as dansmith_btc2
05:26:00	fanquake:	fanquake has left #bitcoin-wizards
07:36:29	lnovy:	lnovy is now known as zz_lnovy
07:38:01	zz_lnovy:	zz_lnovy is now known as lnovy
07:44:19	davidlatapie:	davidlatapie is now known as rpietila
08:05:15	orwell.freenode.net:	topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
08:05:15	orwell.freenode.net:	Users on #bitcoin-wizards: andy-logbot waxwing davidlatapie adam3us RoboTedd_ Guyver2 digitalmagus pen mortale x48 p15 fanquake Transisto coinheavy dansmith_btc2 ebfull jgarzik Graftec qualiabyte TheSeven Adlai Dr-G2 justanotheruser todaystomorrow dgenr8 vmatekol_ Ress EasyAt jchp BigBitz altoz_ atgreen eristisk MRL-Relay artifexd _2539 mappum jbenet [Derek] Starduster shesek devrandom [d__d] berndj tromp__ zibbo_ _Iriez kanzure livegnik_ OneFixt SDCDev Luke-Jr spinza
08:05:15	orwell.freenode.net:	Users on #bitcoin-wizards: petertodd optimator nsh [\\\] HaltingState wiretapped Grishnakh jaekwon1 ericp4 warren puszl irc88___ tacotime rfreeman_w pi07r Adohgg K1773R melvster nuke1989 xmj lnovy Hunger- gribble mkarrer Eliel drawingthesun HM gmaxwell amiller_ crescendo LarsLarsen cfields btc_ kgk bobke iddo samson_ arowser comboy Happzz copumpkin wumpus MarekTerlecki coryfields go1111111 michagogo hollandais zenojis jrayhawk LaptopZZ Meeh poggy_ Emcy_ UukGoblin danneu
08:05:15	orwell.freenode.net:	Users on #bitcoin-wizards: catcow TD-Linux Guest50253 helo smooth otoburb gwillen ryan-c nickler_ mmozeiko roasbeef pajarillo sl01 Keefe Dyaheon rs0_ Gnosis ahmed_ Muis Logicwax nanotube espes__ andytoshi so epscy Fistful_of_coins BlueMatt tromp wizkid057 a5m0 starsoccer midnightmagic Graet kinlo pigeons BrainOverfl0w lianj Apocalyptic mr_burdell fluffypony bbrittain SomeoneWeird forrestv Anduck Nightwolf Krellan Taek42 asoltys sipa nsh- phantomcircuit DoctorBTC harrow
08:05:15	orwell.freenode.net:	Users on #bitcoin-wizards: CodeShark throughnothing Guest47516 Alanius abc56889 lechuga_ burcin @ChanServ phedny
08:05:15	orwell.freenode.net:	[freenode-info] why register and identify? your IRC nick is how people know you. http://freenode.net/faq.shtml#nicksetup
08:05:29	sipa:	i don't believe it!
09:56:30	davidlatapie:	davidlatapie has left #bitcoin-wizards
11:59:31	Guest50253:	Guest50253 is now known as _Tristan_
12:00:11	_Tristan_:	_Tristan_ is now known as [Tristan]
13:15:17	andytoshi:	kanzure: re bitcoin incentives, no paper, i think that should be part of alts.pdf one day
13:15:27	andytoshi:	gmaxwell: thx, sipa's hint will probably give it to me, i'll work on it today
13:17:45	andytoshi:	gmaxwell: ok, so a minor problem with adapting this to ringsigs is going to be that users will need to commit to the ring they're using in the setup phase
13:32:19	andytoshi:	oh, that's more than minor ... because at ring generation time every pk except the one being created will have already appeared in the blockchain. i.e. the newest pk will always be the "real" one
13:35:14	andytoshi:	oh, not quite, you can do the nonce generation as a separate (still interactive) phase after the key generation ... so you have two interactive setup phases and non-interactive signing
13:58:56	andytoshi:	sipa: gmaxwell: is the scheme "key is x_1 + ... + x_M", where each x_i is signer i's private key; during setup each signer i acts as an SSSS dealer and gives shares to all other parties such that any N of them can construct his secret; ditto for the nonce?
13:59:20	andytoshi:	quoting fail, the whole line after "key" should be in quotes
14:12:38	gmaxwell:	yea, effectively. though consider two out of three, parties A,B,C parties compute shares A and B, key is A+B now A gives his private key to B, generates R and gives it to B,C and B gives his private key plus R to C. So A+B sign normally. B+C signs normally using C's copy of A's key. C+A has A sign with his key minus R and C signs with B's key plus R.
14:14:34	gmaxwell:	so the secret sharing dealing is pretty trivial. Boneh says it generalizes to all monotone circuits, though obviously the complexity explodes if its too complex.
14:15:24	andytoshi:	very cool, i feel silly i did not see this earlier given that i was thinking about secret sharing..
14:17:00	gmaxwell:	yea. I felt a little silly explaining our verifier N of M scheme only to have him go oh you can just do this simple thing. doh. :) This does have some weirder consequences.
14:17:21	gmaxwell:	consider a 1 of 3 scheme. ... you generate a private key, and give it to the two other signers.
14:17:44	gmaxwell:	which, uh. indeed is 1 of 3. And its secure under the implied assumption that all signers are not corrupt.
14:18:05	gmaxwell:	Thats what I meant about it made you be frank about the security model. :)
14:18:16	andytoshi:	yup, got that, a weird feeling :)
14:19:09	andytoshi:	this is only O(n^2) setup right? sipa said comb(N,M)
14:19:14	gmaxwell:	I wish we had a solution to needing the nonce interaction; otherwise the verifier adds scheme (or tree scheme) would be less interactive.
14:20:16	gmaxwell:	I think the setup needs as many round trips as there are levels of AND in the boolean circuit, which is the important restriction.
14:21:18	andytoshi:	i think, s/AND/threshold gate/ ?
14:21:40	gmaxwell:	the verifier adds form we were thinking of before still requires less interaction in that you can do group establishment before nonce interaction, assuming pubkeys were already published.
14:23:15	gmaxwell:	andytoshi: maybe? I haven't really though about the other cases. (I think it was if you laid out all the circuits, you could do all the ands at a level in parallel in one RTT but if they were seperated by an or you'd need another RTT between them)
14:23:53	gmaxwell:	(and this can represent non-threshold circuits, e.g. A&B | C&D ... A&B generate and then give copies of their keys to C and D respectively)
14:24:18	andytoshi:	that sounds right
14:24:27	andytoshi:	i'd have to write it down to be sure, but that's just algebra grinding
14:24:50	andytoshi:	what do you mean by "verifier adds" scheme?
14:25:13	andytoshi:	oh i got it, nvr mind
14:25:58	gmaxwell:	The one where you give M pubkeys and a boolean predicate over them which must be satisfied to the verifier; and the signer gives a boolean input that satisfies it and signs using N of N using the satisifying keys; and the verifier just constructs the N of N on the fly.
14:26:06	andytoshi:	yup
14:26:08	gmaxwell:	(or the merkeled precomputed version of it)
14:26:44	gmaxwell:	it's still the case that doing that is the best I've got for doing a 1500 of 3000 since the setup for the secret sharing scheme would be insane.
14:27:58	gmaxwell:	and also the verifier adds scheme has a weaker setup. In particular, a third party can define a group out of preexisting keys.. then the signers can interact to pick their nonces, then they can one-pass for signing.
14:28:41	andytoshi:	yeah
14:29:15	gmaxwell:	I feel like there may be a way to eliminate nonce interaction. E.g. each signer has a nonce pub and a homomorphic derrivation scheme. but the linear relations seem to suggest to me that a signature share would leak the users private key.
14:30:45	andytoshi:	i think it might have to ... there is a property of sigma protocols "special soundness" which is that if you can answer two challenges with the same initial message (after fiat-shamir tranform this is exactly "sign two messages with same nonce") it should produce a witness to the statement being proven (for signature of discrete log this means "leak the key")
14:31:10	andytoshi:	where "sigma protocol" is just jargon for 3-step "commit to nonce; receive challenge; send response" interactive NIZK protocol
14:31:56	andytoshi:	the "two" above can be changed to be polynomial in the security parameter and the definition is still ok ... but the idea is that property is needed to ensure the prover actually has posession of a witness
14:33:33	andytoshi:	there should be some other way to express "prover actually has a witness", all you really need is "some minor bastardization of the protocol will extract a witness", but i can't think of how to do it in a way that you can't get the secret key from knowledge of the nonce
14:35:35	andytoshi:	(does that make sense? i might've totally jumped subject there... the idea is a signature is just a NIZK proof of knowledge with a commitment to a message; one class of NIZKs are "sigma protocol" which are challenge/response protocols; these can be fiat-shamir transformed really easily, e.g. schnorr signatures are an example of this; then this notion of "special soundness" maps directly to "nonce
14:35:38	andytoshi:	reuse vulnerability" which is almost-but-not-quite "knowledge of nonce => knowledge of secret")
14:37:05	andytoshi:	with the moral: if you want to avoid nonce interaction you have to do something really fundamentally different from schnorr
14:38:01	andytoshi:	ofc this is just hand waving, maybe it is possible after all
14:41:02	stonecoldpat:	is there any posts to describe what you guys are trying to do? or is it just word-of-mouth atm? sounds quite interesting
14:46:56	andytoshi:	stonecoldpat: just IRC history i think ... but the goal is pretty simple actually
14:47:50	andytoshi:	stonecoldpat: for schnorr signatures, it is possible to create N-of-N signatures that look like a regular single-party sig, roughly by just adding a bunch of signatures together (and the result is a sig with a public key which is the sum of all parties' public keys)
14:48:22	andytoshi:	stonecoldpat: what we're trying to do is generalize from N-of-N to N-of-M or even general boolean circuits, like "a signature by A || (B && C)"
14:48:43	andytoshi:	while maintaining this "looks like a regular signature" because that's good for privacy and also makes verification very cheap
14:49:49	andytoshi:	stonecoldpat: so, for schnorr signatures we've succeeded, though there are some tradeoffs such as a fairly expensive setup (fine for 15-of-20, not fine for 1500-of-3000). i have a secondary goal of extending these techniques to also work with monero-style ring signatures
14:54:46	stonecoldpat:	i see, and the n-of-n schnorr signatures is not using anything like shamir's secret? (so each party are holding a valid priv-pub key pair that could be used)? does sound really cool. does this mean schnorr's signature is coming to bitcoin in the foreseeable future?
14:57:59	tacotime:	i wish
14:58:23	tacotime:	i think that'll be forever reserved to the hardfork wishlist
14:58:59	tacotime:	monero and a few other cryptocurrencies do currently use schnorr sigs though.
15:01:10	gavinandresen:	tacotime: OP_SCHNORRVERIFY would not necessarily be a hard fork
15:01:51	justanotheruser:	would any opcode additions be a hardfork?
15:02:24	gavinandresen:	Sure, any opcode that modifies the execution stack.
15:02:38	gavinandresen:	… or doesn’t act like a NOP for old clients
15:02:45	justanotheruser:	but why would you do that?
15:03:12	gavinandresen:	why would who do what? If we wanted to re-enable OP_XOR then that would require a hardfork.
15:03:31	justanotheruser:	gavinandresen: I don't think so? You could just re-enable it with OP_EVAL
15:03:51	justanotheruser:	"who"? the person implementing the change
15:04:18	tacotime:	So to softfork, old clients would observe OP_SCHNORRVERIFY as OP_NOP, however newer nodes would actually evaluate the signature and use it to decide how outputs can be spent?
15:04:25	gavinandresen:	tacotime: yes
15:06:12	justanotheruser:	the new clients would have to run the script twice, once as a NOP though right?
15:06:17	gavinandresen:	justanotheruser: sure, you can redefine a NOP opcode to hide all sorts of changes, and that will work. As long as it always behaves as a NOP for old clients.
15:06:54	tacotime:	Huh, that's interesting. I used some unused OP codes as tags for outputs for spendability rules for a proof of stake system, but they actually just evaluate to OP_NOP on the client. Didn't realize that actually makes the changes technically a Bitcoin soft fork. :)
15:06:55	justanotheruser:	And if so, isn't it a bit tricky to do that with complex scripts? You're going to have an additional stack item.
15:07:07	tacotime:	Although, all the horrendous changes I made to the block header don't.
15:08:17	gavinandresen:	justanotheruser: yes, you have to be very careful. But as the successful rollout of P2SH shows it can be done safely.
15:09:14	justanotheruser:	gavinandresen: p2sh seems much simpler since the operations are the same, you just need the hash to be a valid script
15:09:29	justanotheruser:	with this, you are popping an item from the stack in the new version
15:09:33	justanotheruser:	while the old version does nothing
15:21:02	amiller_:	jgarzik, still no update from dakami?
15:30:41	andytoshi:	stonecoldpat: that's correct. in our new M-of-N scheme we do involve secret sharing so the trust setup is more complex than that (well, in short, don't share keys between M-of-N signing groups)
15:30:59	andytoshi:	i mean N-of-M, sorry
15:31:10	andytoshi:	stonecoldpat: but there's still no ability for fewer than N participants to forge a sig
15:40:38	MarekTerlecki:	MarekTerlecki is now known as NikolaiToryzin
15:53:46	jgarzik:	amiller_, nope
15:55:11	amiller_:	jgarzik, alright well how do you want to handle it
15:55:59	jgarzik:	amiller_, well, it's not like I'm going to send a debt collection agent, is it? :)
15:56:24	jgarzik:	amiller_, Continued occasional public mockery is the cost, I suppose. He _claims_ to want to pay it, heh.
15:57:06	amiller_:	i don't have any inspired ideas atm for how to amp up the public shame
15:57:26	amiller_:	his community is infosec rather than bitcoiners
15:58:16	gavinandresen:	we can replace the Qt splashscreen with a big picture of him and a “DOES NOT PAY HIS DEBTS” label.
15:58:41	gavinandresen:	… we can send an alert message…
15:58:56	gavinandresen:	… lots of ways we COULD amp it up. Good thing we’re not evil.
15:59:11	amiller_:	good old fashioned bitcointalk scammer tag
16:01:54	jgarzik:	rofl
16:03:21	fluffypony:	amiller_: they don't even give those out anymore
16:03:31	fluffypony:	best you can do is ask theymos to change their nick to "free hugs"
16:03:43	pigeons:	who is this debtor?
16:04:06	amiller_:	pigeons, dan kaminsky, he lost a bet with jgarzik
16:04:10	amiller_:	http://storify.com/socrates1024/bitcoin-pow-bet-10btc-jgarzik-vs-dakami-may-2014
16:04:11	pigeons:	oh
16:06:31	pigeons:	good insight into him here http://web.textfiles.com/ezines/ZF0/zf05.txt
16:12:15	fluffypony:	there, I tweeted at him
16:21:51	jgarzik:	http://secondlookforensics.com/ngro-linux-kernel-bug/
16:22:07	jgarzik:	Interesting, and vaguely related to bitcoin (in RE randomness)
16:35:40	stonecoldpat:	+1 love the bet story
16:42:22	Ress:	Ress is now known as Aquent
16:52:48	Aquent:	Aquent is now known as Ress
17:04:41	altoz_:	altoz_ is now known as altoz
17:56:56	Ress:	Ress is now known as Aquent
17:57:02	Dizzle__:	Dizzle__ is now known as Dizzle
17:58:23	davidlatapie:	davidlatapie is now known as ristopietila
18:10:58	davidlatapie:	davidlatapie is now known as ristopietila
18:58:42	c0rw1n:	c0rw1n is now known as c0rw|f00d
19:20:58	Aquent:	Aquent is now known as ded
19:21:10	ded:	ded is now known as DeD
19:21:21	DeD:	DeD is now known as Ded
19:28:25	c0rw|f00d:	c0rw|f00d is now known as c0rw1n
20:26:07	Taek42:	I don't know if this has been discussed before, but what if the block header included a merkle tree of all existing utxos?
20:27:10	Taek42:	Then merchants could verify transactions by seeing a transaction in a block and a proof that the utxo was in the state
20:27:10	hearn:	Taek42: it has indeed been discussed before, many times.
20:27:19	hearn:	there is even a guy (maaku) working on it
20:27:59	Taek42:	what are the major hurdles?
20:28:10	sipa:	higher costs to validation
20:28:27	sipa:	and compatibility
20:29:27	Taek42:	compatibility meaning compatibility with the current blockchain, or compatibility meaning making sure that everyone has implemented it in the same way?
20:29:55	sipa:	both
20:30:14	hearn:	Taek42: for merchants, they can already just run Core. it's not very expensive.
20:31:53	Taek42:	but it would be if you had a coin designed to manage a much higher volume of microtransactions (IE decentralized cloud storage)
20:33:27	hearn:	i'm not sure i agree with that statement, but whatever
20:39:00	Taek42:	is it unreasonable to assume that we might end up with an Internet of Things where each device makes transactions on a decentralized ledger? That could result in an extremely high volume of transactions and utxos
20:39:46	hearn:	it's not unreasonable but it's also not reasonable unless you support it with more evidence ;) what would these devices be doing exactly and why would micropayment channels not suffice
20:42:30	tacotime:	hearn: I can't think of a single merchant I know running on core, heh.
20:42:57	Taek42:	just spitballing, but one example could be a cell phone that connects to a decentralized set of carriers (instead of AT&T, etc.). When moving from place to place, you're potentially interacting with many towers that you haven't established a microchannel with yet
20:43:30	Taek42:	or perhaps you're even doing communication with other phones in a mesh, and you're touching hundreds of phones per day that you only transact with for a few minutes
20:43:38	tacotime:	btcd is trying to facilitate future spv modes dependent on utxo I think... I think if you use a merkle tree for the ledger and embed it somewhere in the coinbase, it's not a super big deal for additional validation.
20:44:05	sipa:	it's pointless if not validated
20:44:10	sipa:	so you need a consensus rule for it
20:44:15	hearn:	Taek42: the channel would be with the mobile provider.
20:44:17	sipa:	which means additional cost for validating nodes
20:44:47	hearn:	Taek42: but yes in such an environment you would need lots of channels. that's potentially ok though. read the FAQ entry on scalability. bitcoin scales better than you'd imagine.
20:44:59	tacotime:	yeah, but the additional cost i think is rather trivial, the utxo set isn't that large.
20:45:23	sipa:	tacotime: merkleizing the UTXO set at least doubles its storage footprint
20:45:39	sipa:	which means double the amount of cache/ram, to keep the same validation performance
20:46:01	sipa:	which may be small now, but in a setting like the one described by Taek42 that may be very nontrivial
20:47:05	Taek42:	hearn the specific use case that I'm worried about is a decentralized storage platform. My design currently has each file as it's own transaction, and I would expect a global system to have up to trillions of files.
20:47:25	hearn:	"each file as its own transaction"?
20:47:37	tacotime:	sipa: well, a b+ tree might be more appropriate, with some kind of leave hashing scheme. with updates to the root hash for insertion of any element being O(1)
20:48:02	Taek42:	"each file..." I mean that to create a file, you commit a transaction that 'funds' the file.
20:48:09	tacotime:	... or log(n), it's been a bit since i had into algorithms.
20:48:13	tacotime:	*intro
20:48:52	Taek42:	sipa it only doubles the storage requirement if you store all of the hashes. You could pretty easily recompute most of them each time, storing only the first N levels.
20:49:03	tacotime:	then make the blockchain a rolling proof by committing the root hash of the b+ tree per block.
20:50:17	tacotime:	but i haven't looked at this in a long time, i figured maaku's scheme was something similar but he's using red-black trees (which are more or less the same thing)
20:51:29	Taek42:	does maaku have a writeup or wiki somewhere?
20:51:55	hearn:	Taek42: i suggest taking a look at PayFile. it does use micropayment channels for file downloads, adjusting it to support uploads too would be quite straightforward
20:52:57	tacotime:	Taek42: um, he had source code on github for it but i can't find it now. i think it's part of pybitcoin though
20:53:05	Taek42:	I found it
20:53:16	Taek42:	mikehearn/payfile
20:53:59	gmaxwell:	maaku's work is linked from the posts here: http://utxo.tumblr.com/
20:54:10	Taek42:	oy thanks
20:54:13	tacotime:	ty gmaxwell
20:54:24	gmaxwell:	There is a cost. There is no debating this. The cost is jusitfyable in some cases, sometimes not.
20:54:53	gmaxwell:	(as an example of how old and oft repeated this concept is https://bitcointalk.org/index.php?topic=21995.0 ...)
20:55:04	hearn:	Taek42: payfile builds a channel with a file server. you can then download on a pay-per-kb basis.
20:56:06	hearn:	Taek42: i think that probably makes a lot more sense than one-tx-per-file.
20:56:31	tacotime:	gmaxwell: yeah, someone reinvents it once a month. :) sadly i've been one of those people already.
20:57:06	sipa:	Taek42: recomputing the entire merkle tree for the current bitcoin utxo set already takes several seconds on top-notch hardware, that is unacceptable
20:57:18	gmaxwell:	The advantages of this kind of commitment are often overstated. There is also a related commitment approach (e.g. commiting to all txouts, spent or not) which has some different tradeoffs— in particular because it can be insertion ordered.
20:58:37	Taek42:	hearn the big difference between payfile and Sia (my wip coin) is that Sia provides a topology of hosts, and tracks which files each host is supposed to be storing.
20:58:40	gmaxwell:	(in think in the long run some kind of commitment in this space is likely to exist. But it's not a light decision or a free choice)
20:58:48	Taek42:	Uploading is somewhat of a 'set and forget' for consumers
20:59:09	gmaxwell:	Taek42: if you're unaware of this discussions already then IMO you have absolutely no business creating a new "coin".
21:00:09	hearn:	Taek42: you can do full blown p2p file storage incentivised by bitcoin without a new coin and without changes to bitcoin
21:00:11	Taek42:	gmaxwell trying to catch up, but yes I realize I'm underqualified.
21:00:54	Taek42:	hearn if you've got something that explains this I'm super interested
21:01:57	hearn:	Taek42: you want to start small and work up. PayFile is small - it does downloads only, incentivised with micropayments, so the server can pay for the bandwidth it consumes. useful as an alternative to bittorrent. but, it has a GUI, it's somewhat usable, etc.
21:01:58	tacotime:	Taek42: https://bitcointalk.org/index.php?topic=88208.0
21:02:02	tacotime:	that's a good place to start
21:02:09	hearn:	Taek42: it's not entirely finished but someone could turn it into a real app that real users could download and run.
21:02:39	hearn:	Taek42: then you say, ok, now let's add file upload, with payments to incentivise storage. you would add a basic proof of storage protocol.
21:02:48	hearn:	Taek42: distribute that as an update to your (smallish) userbase.
21:02:57	hearn:	Taek42: then after that's working, you can think about a p2p network of nodes
21:03:14	hearn:	but it's a BIG project. don't underestimate that. and most of it, is not cryptocurrency related. it's just network and ui code.
21:06:35	gmaxwell:	Taek42: A cryptocurrency is a cryptosystem, and demands the same kind of careful consideration. I don't mean to insult you, but on top of the damage that dillution additional altcoins cause the bitcoin ecosystem, the proliferation of broken and ill concieved altcoin cryptosystem erodes trusted in the whole space.
21:06:47	gmaxwell:	Taek42: I assume you've read the in progress alts.pdf
21:07:16	Taek42:	gmaxwell I've recently read the whole thing. I've been working on Sia for about a year and the past month I've realized how far over my head I am
21:08:06	Taek42:	The last thing I want to do is release another altcoin that's complex and not peer-reviewed and damaging to the ecosystem
21:10:59	tacotime:	I'm a little more forgiving in this regard -- I think you should attempt to make new distributed cryptosystems whatever your level of skill, just don't market them as things that they're not. I've spent forever working on my wacky PoW-PoS system and I'll be the first to admit that it may be a terrible catastrophic experiment. But I'm also coding the entire thing volunteer and not launching a cryptocurrency myself.
21:12:21	tacotime:	I think responsibilities are different if you're planning to market something as secure and unbreakable, but, ehm, I'll let people who use my source code do the damage that they want to to themselves.
21:15:22	helo:	i think scary warnings should be good enough, if they're scary enough
21:15:54	Taek42:	like Facebook's privacy policy?
21:16:16	Taek42:	IE people are pretty quick to disregard warnings if everyone else is doing something
21:16:51	tacotime:	Or Ethereum's "we don't have to actually deliver a product" warning, I liked that one.
21:17:57	justanotheruser:	tacotime: link?
21:18:07	tacotime:	The really dangerous forks will be the ones people have dumped their retirement funds into in the hopes of them being the next Bitcoin, and I'm not sure that we can control this sort of thing unfortunately.
21:18:43	justanotheruser:	tacotime: it can be mitigated through sidechains
21:18:47	helo:	people can waste money in any number of bad investments
21:19:09	tacotime:	justanotheruser: https://www.ethereum.org/ "Terms and conditions of the ethereum genesis sale" on the right side
21:20:03	fluffypony:	https://news.ycombinator.com/item?id=8072340
21:20:12	fluffypony:	"The premine is being conducted by "EthSuisse", a Swiss entity which will be prompty dissolved after the premining period ends. The Ethereum team makes no guarantee that development of Ethereum will continue after the dissolution of "EthSuisse""
21:23:04	justanotheruser:	tacotime: I see no guarantee of governance over the product
21:23:10	justanotheruser:	is that what you mean
21:24:56	justanotheruser:	I don't look forward to the desparate pumping of ethereum when it begins to collaps
21:25:34	tacotime:	I think that was the part, it's been a while since i read it