00:25:52	jgarzik:	hum. is there any fancy math (CP-ABE?) that gets around the problem of an oracle having to store private keys? Ideally, an oracle should be able to prove+unlock stuff, without having to control private keys. (paradoxical request perhaps, but that's the ideal)
00:29:33	gmaxwell:	jgarzik: No. (the closest in that space is indistinguishability obfscuation, but it doesn't do what you want and isn't remotely pratical if it actually turns out to work). Though with multisig you can usually arrange things so that the oracle(s) can't unilaterally steal anything.
00:30:04	jgarzik:	indeed
00:30:14	gmaxwell:	If the contract is a 0/1 kind of thing, you can refactor it into a form where the oracle releases a private key (or one of several private keys), and then you can do some nice oracle blinding.
00:30:24	jgarzik:	gmaxwell, I was hoping -wizards had something more fancy than "N oracles with N keys"
00:30:29	jgarzik:	and M of that
00:30:59	gmaxwell:	well not N oracles with N keys, but you can do "one of two users, plus m of n oracles."
00:32:45	gmaxwell:	e.g. a good form for a two party oracle mediated contract is is often 4 of 7, where the users have two keys each, and then three oracles. So user+user (no oracle) or user+oracle+oracle can redeem.
00:35:02	jgarzik:	indeed. I still $wish there was some way to reduce the amount of trust in the oracle, beyond simply using multiple independently operated oracles.
00:36:21	gmaxwell:	Wrt blinding, e.g. say the oracle judges a 1000 person vote, if cookies wins, it releases S1 and if Icecream wins it release S2. Prior to the election you query the oracle in a setup phase and have it tell you P1=G*S1, P2+G*S2. Then you can take the cookie vendor pubkey PC and compute P1C = P1 + PC, and the same for the icecream vendor P2I = P2 + PI ... now pay your dessert budget to 1 of 2 {P1C,P2I}. Beyond making it so the ...
00:36:27	gmaxwell:	... oracle can't unilateraly steal the funds, this also make the oracle unable to identify the transaction it arbritarted on the blockchain.
00:36:34	jgarzik:	Random flight of fancy before disappearing for kid bedtime: Put a moxie sandbox in every bitcoind, and if NODE_MOXIEBOX (etc.) is advertised, you may connect to that node, offer some bitcoin, and receive execution in return
00:36:57	jgarzik:	right
00:37:21	jgarzik:	bbiaw
00:37:41	gmaxwell:	jgarzik: Yea— would be nice. Best I can suggest for greater oracle integrity in the near term is remote attest. In general secrecy makes it hard. Oracles implemented as multiparty computation give you what you want, but thats not terribly realistic right now.
00:39:10	gmaxwell:	(if you go down the rabbit hole of reading about multiparty computation, be aware that the lit is full of stuff under not-very-useful security models, like "semi-honest" or "passive" security where it's assumed that the participants may try to passively snoop but won't violate the protocol.)
02:09:28	OneFixt_:	OneFixt_ is now known as OneFixt
03:50:43	copumpkin:	copumpkin is now known as wildebeest
03:50:46	wildebeest:	wildebeest is now known as hyena
03:50:51	hyena:	hyena is now known as copumpkin
04:56:40	HobGoblin:	HobGoblin is now known as Guest86934
07:59:18	gmaxwell_:	gmaxwell_ is now known as gmaxwell
08:54:30	[Tristan]:	[Tristan] is now known as Guest875
08:59:39	lclc:	lclc is now known as Monetas_CEO
09:01:15	Monetas_CEO:	Monetas_CEO is now known as lclc
09:49:15	gmaxwell:	I did eventually break and post in that R30 thread: https://bitcointalk.org/index.php?topic=698460.msg8210906#msg8210906
09:49:53	gmaxwell:	the poster claiming that " the R30 hash function acts well as a random oracle" was just too much for me to continue to bite my tongue.
09:53:56	sipa:	invoking xkcd #386 is perfectly acceptable in such cases
09:54:18	dsnrk:	gmaxwell: I find this to be completely painful. https://bitcointalk.org/index.php?topic=279249.msg8210622#msg8210622
10:33:56	Emcy:	visual represenation of gmax posting in threads on bitcointalk http://i.imgur.com/dZp1Bea.gif
12:51:04	pigeons:	gmaxwell: the person's response is getting familiar now too: "no, that's from before i fixed that stuff, check again, this time it really is secure"
12:52:12	gmaxwell:	pigeons: I would have taken a 10 BTC bet that I would have gotten exactly that response.
12:52:24	gmaxwell:	Thats precisely why I didn't post in that thread previously.
12:53:17	gmaxwell:	When people are in some design fugue it seems to be impossible to get through to them that they are going to hurt someone.
12:53:26	gmaxwell:	but I didn't post for his benefit.
13:06:29	gmaxwell:	In any case, I should point that that to those of us who are actually interested in being competent at this stuff, _breaking_ cryptosystems is really the only way to learn, and this guys attitude makes it not unlikely that his function is an easy practice target.
13:23:07	fanquake:	fanquake has left #bitcoin-wizards
13:58:42	Guest86934:	Guest86934 is now known as UukGoblin
15:14:22	atgreen:	jgarzik: did you sort out that crt0.o issue?
15:14:34	jgarzik:	atgreen, not yet
15:14:52	jgarzik:	atgreen, simplest thing appears to be to revert the Makefile.am changes eliding the libsandboxrt.a
15:14:58	atgreen:	you just need to symlink your crt0.o into the directory that ld is expecting to find it in
15:15:08	atgreen:	${prefix}/moxiebox/lib
15:15:26	atgreen:	same with libsandboxrt.a
15:15:37	atgreen:	just see the end of the toolchain build script
15:17:09	nsh:	is anyone blogging or anything about moxie/bitcoin work? it'd be nice to follow progress somehow
15:18:15	jgarzik:	atgreen, That seems sub-optimal, because it may change in-tree, and we need the build to pick that up automatically without symlinks and such
15:19:02	atgreen:	you can also try "-L /path/to/runtime" on the link line
15:20:04	atgreen:	but in the end, expect, users will have the toolchain installed from RPM/deb, and then they'll have installed versions of moxiebox where crt0.o and libsandboxrt.a are dropped in the right directory for the toolchain, right?
15:20:42	atgreen:	But for the in-tree test directory, -L might be the better answer.
15:21:02	atgreen:	"I expect", not "expect".
15:21:35	atgreen:	hmm.. -L may not pick up crt0.o. I'll have to test.
15:22:55	gmaxwell:	I am really uncomfortable with the casual discussion about tx expiration bitcoin-development. "Oh lets just change the meaning of nlocktime so that it expires transactions!" ... nevermind that it invalidates existing transactions, it's a soft forking change, and the implications of transactions which cannot be restored in a reorg is not well studied (and the current behavior is very clearly not accidental).
15:26:18	wumpus:	gmaxwell: I'm not convinced of the need to expire transactions at all
15:27:38	wumpus:	sure, in the software it makes sense to throw transactions after a while to avoid that the mempool grows without bounds
15:31:25	gmaxwell:	Sure. Agreed that mempool expiration of some form makes sense. (though mempool should get synced to disk too, to lower any pressure there)
15:31:43	wumpus:	but I'm not convinced that it is necessary to make a guarantee of expiration part of the protocol... I suppose the typical use-case is if you want to 'cancel' a transaction that doesn't confirm within the time that you want it to
15:32:44	wumpus:	and then resubmit it with a higher fee... but that's what replace-by-fee would do, too
15:33:09	gmaxwell:	There are uses, some may even be good— though you can already cancel by issuing a successful conflicting spend. Mostly my concern is that it adds a new non-fungiblity vector to txouts, and also the people talkign about it are proposing really broken things that would harm existing applicatoins.
15:33:30	wumpus:	but how it would interact with reorganizations is a mystery to me
15:34:24	gmaxwell:	wumpus: we need additional word for replace-by-fee-that-isn't-totally-highest-bid-wins, since thats adequate for fee updates.
15:34:40	wumpus:	suddenly some transactions are bounced back to the mempool and instantly expire
15:34:55	wumpus:	with no way to bring them back, because the expiration is hardcoded into the transaction
15:35:41	gmaxwell:	e.g. if you do a replace if the new transaction pays at least ε more fee, and it pays equal to or greater than all the prior outputs, and it doesn't invalidate any children you know about. ... thats adequate for the update-my-fees case but doesn't involve the other impacts that a true replace-by-fee does.
15:36:43	gmaxwell:	wumpus: yea, and then does that create any weird incentives for miners?
15:37:19	wumpus:	gmaxwell: yes, a restricted update-my-fee would be good enough, the advantage would be that it's under control of the user. When they get impatient they can increase the fee. No need to wait for expiration...
15:38:35	gmaxwell:	yea, I think expiration is a poor tool for this particular problem— for one, it requires psychic users to set the expiration they would have wanted in the future— and if they're that psychic why didn't they get the fee right to begin with? :)
15:40:39	wumpus:	gmaxwell: weird incentives for miners... hmm, I don't know, maybe they want to grab soon-expiring transactions first, before they are unminable?
15:41:04	hearn:	wumpus: surely for bumping tx fee CPFP is what we need?
15:41:10	hearn:	feels like this comes up every three months or so :)
15:41:55	gmaxwell:	CPFP is one approach, but it only allows a reciever to drive it— doesn't include the sender if there is no change. Eligius (and a couple other, IIRC) pools have CPFP in service already.
15:43:24	wumpus:	hearn: well, CPFP is not under control of the sender, so it doesn't work in the 'transactions doesn't confirm! I want to resubmit it with more fee' case
15:43:58	hearn:	right, but it's only the recipient who cares about confirmation
15:44:08	hearn:	the sender "knows" they are honest
15:44:32	wumpus:	hearn: the sender cares because they will only get the they ordered if the transaction confirms
15:45:08	wumpus:	hearn: anyhow, CPFP is a good idea too, but for other cases
15:46:37	hearn:	technically, the only point of confirmations is to avoid double spending, and the only person who cares about double spending is the recipient of the funds. the seller is best place to judge the risk (how many confirmations etc). at least this is how things should work in theory, yes, in practice today sellers tend to communicate what they want out of band and expect users to make it happen
15:48:10	jgarzik:	Fill-or-kill does make sense in the context of miner acceptance (as implied by confirmation or lack thereof).
15:52:06	jgarzik:	Having the default behavior be an open-ended "confirm sometime before $infinity, or maybe not" limbo is not the best long term path for bitcoin.
15:54:04	gmaxwell:	jgarzik: Introducing a whole new failure mode is not something that should just be done casually though, especially not as a response to a need which is better addressed with replacement / CPFP.
15:54:34	gmaxwell:	hearn: in some strict sense thats true, but if I'm Joe Six pack paying some automated service which doesn't mind waiting forever, the onus may be on me.
15:54:59	jgarzik:	gmaxwell, Yes, and it is not being done casually.
15:56:01	jgarzik:	gmaxwell, Part of the process is talking about it in public, working through the problem, understanding the new problems created by any new feature.
15:56:39	gmaxwell:	Well maybe I'm just being thrown off by the fact that the thread has multiple people posting things in it that would _severely_ break the system and cause large monetary losses (breaking nlocktime) and thinking it is no big deal, even after it was pointed out that it has non-trivial not well understood implications.
15:57:14	jgarzik:	n00bs. What can ya do?
15:57:15	jgarzik:	:)
15:57:30	wumpus:	I think the open-ended behavior is fine. you submit a transaction with the idea that you want it irreversibly done...
15:58:39	jgarzik:	wumpus, yes, but the result achieved is "done | limbo", so that goal is not fulfilled
15:59:10	wumpus:	CPFP and replacement already provide two options to avoid the limbo
15:59:25	wumpus:	not convinced a third one is needed
15:59:45	wumpus:	I'm not even convinced it is possible without messing with reorganizations
16:00:12	wumpus:	and making the system itself way less robust
16:00:37	jgarzik:	expiring transactions that fail to confirm out of the mempool does not do that
16:01:05	jgarzik:	Let's not conflate multiple different proposals
16:01:06	wumpus:	it does: a reorganization can makes transactions fall back into the mempool
16:01:24	wumpus:	if they have a hardcoded expiration time, that time will have expired by then, and they will get dropped
16:01:54	wumpus:	so the damage causes by the reorg is much larger
16:02:02	jgarzik:	wumpus, that is true of the proposal which adds an expire time to transactions [naively], but not mempool expiration
16:02:18	wumpus:	jgarzik: what do you mean then?
16:03:52	wumpus:	I already said that something that is limited to the implementation is fine with me, so transactions get evicted but not permanently expired
16:05:33	jgarzik:	wumpus, _I_ mean precisely what I put into the github PRs. Transactions that are not "precious" yet fail to confirm after $large_reorg_buffer number of blocks are removed from the local mempool. Clients are free to retransmit if they like.
16:05:47	jgarzik:	It is easy to put in additional just-had-a-massive-reorg protections to such a scheme.
16:05:53	jgarzik:	at the local node level
16:06:00	jgarzik:	100% implementation, are all my proposals
16:06:01	wumpus:	you're really misunderstanding me
16:07:08	wumpus:	your pool manager wouldn't matter at all for a reorganization
16:07:30	wumpus:	the eviction is just one-off, transactions can always be brought back
16:08:00	jgarzik:	reorgs also add to the mempool with a $now timestamp
16:08:25	wumpus:	in a large rorg, someone could resubmit the old transactions manually, I'm not worried about them getting lost
16:08:43	wumpus:	what I'm worried about is hardcoded constraints that prevent them from getting mined again
16:08:53	wumpus:	which some people propose
16:09:04	jgarzik:	yes, those proposals are broken
16:26:30	gmaxwell:	whew
16:26:53	gmaxwell:	wumpus: I too didn't previously realize jgarzik was on the same page as I. Glad to hear we're mostly thinking the same things.
16:28:11	gmaxwell:	For the record (and since this is #bitcoin-wizards), I am not of the opinion that a blockchain enforced expiration is an impossibility... just that it's got a lot of risks, and isn't worth considering for solving the problems that mempool janitor + CFPF + soft-replacement address.
16:28:45	gmaxwell:	It might be worthwhile for some other purpose, so I think so far every time I've thought a protocol needed it I've been able to convince myself it didn't.
16:29:40	gmaxwell:	(in particular, you can do a tx style where you write a conflicting spend which is nlocktimed, so thats your 'expiration')
16:32:43	hearn:	if we could figure out resource consumption i'd like to see the p2p network learn to store time locked transaction on disk/in the mempool once again
16:32:51	hearn:	then you could do expiry with a timelocked transaction indeed
16:33:02	jgarzik:	IMO this would be great material for the mailing list. I think the m-l is better for thought-bubble, education, etc. topics as well as explaining BIPs, etc.
16:33:04	hearn:	you know, you'd have a --use-disk-space=500MB type flag
16:33:36	maaku:	you definately need it for things bitcoin currently doesn't do -- e.g. order expiration in a HFT exchange
16:33:41	jgarzik:	I like to thought bubble stuff like "network TX" concept. Maybe it's dumb. But hopefully somebody will point out why it is dumb _on list_ so that the knowledge is archived.
16:34:07	jgarzik:	I think some of this "man your proposal is quite dangerous actually" feedback needs to bubble up
16:35:01	jgarzik:	hearn, in general, I agree it is a problem worth solving $somewhere, $somehow
16:35:25	gmaxwell:	jgarzik: Not quite sure about it though, I mean, we had some of that there and it got dismissed. I don't want to overplay it, but I'm also not happy about it being ignored. My reflex is basically to retreat from the "fools", ... this is lazy and perhaps not the best though.
16:35:44	jgarzik:	hearn, absent a fixed buffer at local nodes, I just come up with third party schemes that helpfully store your transaction until $conditions
16:35:52	gmaxwell:	I only have limited capacity to deal with Wrong People On The Internet, so I try to spend those tokens with some care.
16:36:18	jgarzik:	gmaxwell, we get waves of n00bs
16:36:31	gmaxwell:	speaking of third parties storing, this may be relevant to your interests: https://bitcointalk.org/index.php?topic=726495.0
16:36:33	jgarzik:	gmaxwell, with n00b proposals and of needing education ;p
16:37:02	jgarzik:	hearn, ie. not just store-until-timelock, but dead man's switch and other more fancy "time release" gadgets
16:37:56	gmaxwell:	Fortunately for things like that you only need a 'few' copies in the whole world, not every node. (thats also why I linked the wallet backup thing, I think it also has that storage model)
16:38:12	jgarzik:	Really, people need their own personal IFTTT storage space + executor
16:38:18	gmaxwell:	perhaps the same infrastructure could store those wallet backup messages, dos protected by the same stuff.
16:40:19	wumpus:	yes that would be really useful
16:43:10	jgarzik:	so, at a high level, I tend to think of this as separate from the mempool
16:43:27	jgarzik:	even for the basic case of a timelock'd refund TX
16:43:38	jgarzik:	*separate, storage-wise, from bitcoind
16:44:12	jgarzik:	time is but one of many factors that might cause a dormant TX to become alive and spendable
16:48:37	hearn:	jgarzik: yeah, there's a java library called tomp2p that implements a DHT storage mechanism complete with UPNP NAT traversal and stuff. it's pretty mature.
16:48:53	hearn:	i keep pondering making a tx storage network with that, but it's a project for after lighthouse at least. also i keep wondering about replication levels.
16:49:04	hearn:	disk space is soooooooo cheap and txns sooooooo small i keep thinking, maybe every node should store everything after all
16:50:45	jgarzik:	hearn, I keep wanting a data chain...
16:51:05	jgarzik:	and also an ephemeral chain
16:51:54	jgarzik:	There were some people in London terribly excited about their ephemeral-messaging-on-the-blockchain business plan :(
16:52:31	gmaxwell:	just figure out how to convert it into an investment scam^wscheme and people will apparently be falling over themselves to pay hundreds of btc to implement it, even if you show no signs of a viable design. :-/
16:53:31	jgarzik:	really, a bitmessage-like chain might take some pressure off bitcoin
16:53:41	jgarzik:	p2pool-ish, expire things after a week or somesuch
16:53:58	gmaxwell:	"Bloatcoin"
16:54:03	jgarzik:	:)
16:54:38	gmaxwell:	One gets Bloat-capacity by virtue of having immobile bitcoin UTXO.
16:54:46	jgarzik:	lol
16:56:01	hearn:	haha
16:56:42	hearn:	gmaxwell: it's gonna be a 2.0-level appcoin design that has smart crowdcontracts integrated into its block chain, and only 80% premine!
17:00:36	jgarzik:	OK, that's my thought bubble -wizards exercise for the day. Ephemeral messaging chain. Burn bitcoin (1 way) to get em-tokens. In addition to simply a bitcoin-like, scriptable coin, introduce the concept of "mailboxes" which is a container that collects encrypted messages based on public key. messages disappear when PK-signed msg deletes, or $expiration (1 week) goes by. Like bitmessage, all messaging is on-chain, everyone-receives-eve
17:00:37	jgarzik:	rything.
17:01:11	jgarzik:	records added/updated via em-tokens.
17:03:09	gmaxwell:	why burn? Why not just show you have bitcoin sitting in the utxo set that you can sign for?
17:04:41	jgarzik:	gmaxwell, Seemed like a usefully lazy way to constrain the supply of em-tokens? :)
17:05:08	jgarzik:	* jgarzik ponders
17:05:43	jgarzik:	interesting to think through the economics of that
17:08:05	gmaxwell:	non-burning may have less of a altcoinish effect, I think that any kind of scarce thing is probably workable, and we already use utxo holding scarcity as a anti-dos metric in bitcoin.
17:09:26	jgarzik:	gmaxwell, I can see.. hmmm That utxo-holding proof seems much more fluid and difficult to get right
17:09:48	gmaxwell:	jgarzik: well you just require bloatcoin nodes to be bitcoin nodes too, and then its trivial.
17:10:30	hearn:	jgarzik: e.g. if you want to store an expiry tx for a given tx, you watch out for spends of the outputs the pending tx spends. once the pending tx confirms, you can delete the expiry tx
17:10:34	gmaxwell:	e.g. gettxout your proof could even just be an infinitely locked transaction spending the coin.
17:10:54	jgarzik:	heh
17:12:38	hearn:	actually with bitcoinj master + getutxo such an app would be quite easy to write. and bcj probes for a local node and uses it in preference to the p2p network automatically now, so to upgrade from spv-or-less to full security just means running Core and restarting the app
17:13:32	hearn:	i mean bcj master + tomp2p for the DHT
17:14:59	jgarzik:	My point RE fluidity was that the utxo may be spent at any time, regardless of provided proof validity.
17:15:07	jgarzik:	A burned bitcoin is by definition spent (once confirmed).
17:15:30	jgarzik:	The state of the proof can change at any moment
17:15:37	hearn:	right. but then you just delete the data.
17:15:38	gmaxwell:	jgarzik: yea so the cool thing you do there is that you can store data in the system so long as your utxo stays put, after that its just a hash.
17:15:41	jgarzik:	which means em-chain consensus could change with it.
17:16:01	jgarzik:	gmaxwell, hmmmm
17:16:03	hearn:	well do you need a block chain for raw data storage?
17:16:08	hearn:	i doubt it
17:16:15	jgarzik:	hearn, bitmessage
17:16:15	gmaxwell:	so it's a consensus for commitments, but then only a tip-consensus for the actual data.
17:16:17	hearn:	the "files" would not depend on each other would they
17:16:24	jgarzik:	hearn, offline data storage, mailboxes, deniability, ...
17:17:00	jgarzik:	hearn, ephemeral messaging is the stated goal, so theoretically small bits
17:18:08	jgarzik:	you just need some sort of anti-DoS, same old story for any decentralized app
17:18:36	gmaxwell:	yea, to some extent there is a class of service that can't exist for lack of a good enough anti-dos... and maybe we can solve that.
17:20:36	jgarzik:	another issue is granularity. you can prove you spent-with-infinity-locktime a UTXO, but that gives you at most N proofs, for N UTXOs.
17:21:30	jgarzik:	you can always introduce faux-change (a transaction with infinity locktime, that creates faux-UTXOs for further faux-spending)
17:35:15	gmaxwell:	jgarzik: I figure it can just be reused: E.g. every N bitcoins of UTXO you have entitles you to Y storage. once you're at Y you have to delete something.
17:35:37	gmaxwell:	no need to make change. It's just a capacity management issue.
17:36:02	jgarzik:	true
17:44:01	jgarzik:	hmmmm. for ephemeral-coin (bloatcoin-lite), letting each node set a maximum block size (== data rate) might be an implicit way for the market to automatically set Y
17:44:58	jgarzik:	fun resolving all those forks, but ultimately you have an incentive to come to a consensus at a human level
17:45:03	gmaxwell:	jgarzik: well you could convert storage to rate: e.g. data that is retained from N blocks ago counts against the current block's limit.
17:47:32	nejucomo1:	nejucomo1 is now known as nejucomo
20:02:54	NikolaiToryzin:	NikolaiToryzin has left #bitcoin-wizards
20:21:08	nejucomo1:	nejucomo1 is now known as nejucomo
20:27:55	e4xit__:	e4xit__ is now known as e4xit
22:17:47	super3:	http://metadisk.org/metadisk.pdf thoughts?
22:23:28	zooko:	* zooko looks at http://metadisk.org/metadisk.pdf
22:24:36	coinheavy_:	coinheavy_ is now known as coinheavy
22:26:35	zooko:	super3: you might be interested in https://Tahoe-LAFS.org
22:28:19	super3:	zooko: yeah. very aware. perhaps i should have cited it along with maidsafe and storj
22:28:37	zooko:	That would be nice.
22:28:39	zooko:	☺
22:28:52	nsh:	(mixcase hostnames make ascii jesus cry)
22:29:15	zooko:	Or, let me put it another way: if it predates your work, if it has substantial similarities, and if you are aware of it, then yes you should.
22:29:17	super3:	would like to integrate it as a data source, along with the rest of them
22:29:44	zooko:	Actually even if it doesn't predate your work, you should. But in this case it does. :-)
22:41:31	super3:	kinda sad that it doesn't seem to have any updates since 2013
22:41:44	super3:	but yeah ill be looking more into than i have before
22:44:12	zooko:	Tahoe-LAFS? Hm, that's a good point. I'm one of the main maintainers, you know, so that's largely my fault.
22:44:27	zooko:	We have a few nice improvements written, but haven't put out a stable release.
22:45:02	super3:	zooko: how many people are working on the project?
22:49:12	zooko:	Sort of hard to estimate. I operate a small company that is commercializing it, and a few of us employees of the company poke at improving the project every week.
22:49:16	zooko:	So, count that as about 3.
22:49:39	zooko:	Then there's this kid who has been doing a lot of great integration between Tahoe-LAFS, Tor, Tails, and Twisted. All T's. But anyway, it seems like he's doing some good work!
22:49:59	zooko:	Then there's the fork of Tahoe-LAFS which is maintained by the I2P hackers, so count that as, I dunno, 1/100 of a person? :-) Hard to tell.
22:51:23	super3:	ha ha, perhaps storj and Tahoe-LAFS could work together more directly, no need to reinvent the wheel
22:51:36	super3:	oh this is in Python? now i'm actually kinda excited
22:53:17	zooko:	Great! In my ever so humble opinion, Tahoe-LAFS has many things going for it, including that it is already implemented and used, and a few of the bugs and vulnerability have already been found and knocked out.
22:53:33	zooko:	Also, it has some very subtle and sophisticated crypto ideas in there, which I'd like to see other people pick up and run with.
22:53:49	zooko:	Feels like there's some unexploited potential in there, in my obviously completely biased opinion. ☺
22:55:40	super3:	it being in python changes everything, means its in line with the rest of our stack
22:55:44	zooko:	Sweet.
22:55:57	zooko:	Yeah, to be honest, I've never regretted using Python for this.
22:56:25	super3:	i just assumed it was in the most convoluted c++ like with every other crypto project
22:56:30	zooko:	Maybe in a few years I would try Rust or something even newer and shinier that doesn't exist yet, but for now, a relatively unglamorous tool that does the job suits me just fine.
23:15:34	e4xit_:	e4xit_ is now known as e4xit
23:23:55	gmaxwell:	16:22 < iii> but let me asure you i know what i'm talking about after 2 years in cryptos :o)
23:59:53	maaku:	"CoinShuffle: decentralized CoinJoin without trusted third parties" <--- sigh. why do people think coinjoin requires trusted parties?