00:12:53	Keefe_:	Keefe_ is now known as Keefe
01:38:25	realz:	realz is now known as Guest7756
01:46:56	jgarzik_:	jgarzik_ is now known as jgarzik
03:02:20	ghtdak:	ghtdak has left #bitcoin-wizards
03:27:44	Guest26703:	Guest26703 is now known as gmaxwell
04:26:42	gmaxwell:	I was telling sipa, bluematt, maaku, and jtimon elsewhere today about brisque's bloom comments.. one thing I forgot to mention is that the same approach would be useful for making rescans faster.
04:26:59	gmaxwell:	or continuing to support rescans for pruned nodes.
05:23:44	tacotime:	gmaxwell: I added blinding, albeit in a sloppy way as I sign hsx concatenated with hsy https://github.com/monero-project/urs/blob/master/urs.go#L547-L752
05:23:50	tacotime:	with the ephemeral key
05:25:07	tacotime:	And it uses the URS scheme, so you generate two useless hsx, hsy values that consume an extra 256 bits but ehm
05:25:36	tacotime:	I need to change the comments too, tomorrow i guess.
05:27:17	moa:	tacotime: blind ringsign?
05:27:44	tacotime:	moa: refer to https://download.wpsoftware.net/bitcoin/wizardry/ringsig-blinding.txt
05:27:59	moa:	thnx, that was my next question :)
05:28:22	tacotime:	I also added the same Q to each pubkey, I didn't think it mattered and it saves space
05:28:43	moa:	any limit on the number of signers in the ring?
05:29:20	tacotime:	only internal ones from memory allowances in golang, so not really as far as i'm aware.
05:29:37	moa:	so physical not theoretical i guess
05:29:42	tacotime:	yeah.
05:29:54	moa:	really really interesting
05:30:01	tacotime:	the signatures also scale linearly so, eventually they'll get big too
05:30:08	moa:	ah
05:57:54	Guest37774:	Guest37774 is now known as SomeoneWeird
08:05:16	kornbluth.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:16	kornbluth.freenode.net:	Users on #bitcoin-wizards: andy-logbot shesek Guyver2 nsh- ericp4 mapppum ebfull lclc drawingthesun copumpkin dgenr8 mortale melvster TheSeven Graftec eslbaer_ nuke1989 atgreen epscy Adohgg jaekwon mr_burdell zenojis Jason SDCDev moa prepost pajarillo cym qualiabyte BlueMatt koshii jchp jbenet bbrittain crescend1 jgarzik SomeoneWeird wiretapped bsm117532 zling______ go1111111 GAit waxwing cannon HM Guest10131 Emcy oujh Krellan phantomcircuit sl01 asoltys Sangheili
08:05:16	kornbluth.freenode.net:	Users on #bitcoin-wizards: azariah4 espes___ zibbo gmaxwell OneFixt samson2 Keefe Fistful_of_coins DoctorBTC grubles poggy harrow kmels spinza Hunger- Grishnakh Muis tromp [\\\] CryptOprah_ digitalmagus7 rs0 warren michagogo iddo btc_ licnep artifexd Dyaheon Taek42 cfields sipa Luke-Jr roasbeef berndj-blackout andytoshi Meeh mmozeiko Eliel eAndrius CodeShark throughnothing tacotime Guest47516 BigBitz Transisto K1773R Alanius_ nickler_ nanotube midnightmagic Logicwax
08:05:16	kornbluth.freenode.net:	Users on #bitcoin-wizards: mkarrer Starsoccer nsh tucenaber tromp__ LarsLarsen comboy jaromil pi07r ryan-c kanzure EasyAt gwillen BrainOverfl0w otoburb smooth pigeons bobke Anduck helo Guest50253 weex abc56889 lechuga_ TD-Linux a5m0 catcow amiller dansmith_btc danneu LaptopZZ_ burcin optimator_ jcorgan petertodd UukGoblin wizkid057 kinlo so phedny gribble nkuttler wumpus lianj Apocalyptic @ChanServ
08:06:17	Jason:	Jason has left #bitcoin-wizards
11:10:53	amiller:	https://ripple.com/forum/viewtopic.php?f=2&t=7801#p56432 let me know if anyone wants to join me in critiquing the ripple whitepaper...
11:11:14	amiller:	the main thing i posted is a counterexample to their 'theorem'
11:11:36	amiller:	the idea is that they describe a minimum condition for "overlap" among nodes UNL lists of nodes on the ripple network
11:12:04	amiller:	the condition is that among any two nodes, their UNLs must contain X nodes in common, where X = 1/5 (the maximum size of *any* nodes UNL list)
11:12:50	amiller:	the theorem (to the best I can recover it, it's not stated explicitly) is that if this condition holds for the network, then there are no forks
11:13:48	amiller:	the problem is that since different nodes can have different size UNLs, and "A is on B's UNL" doesn't mean "B is on A's UNL", it's easy to make a network topology that satisfies that requirement, yet there would clearly be a fork
11:15:25	amiller:	i have two other avenues of criticism
11:16:19	amiller:	1. i'm not sure how their approach can be fixable. For example, suppose I add a new node to the network that has 100000 nodes on it's UNL list.
11:16:33	amiller:	that would throw off any heuristic based on the maximum overlap of the network etc
11:17:23	amiller:	it would also throw off the plausibility of the fault tolerance, since now 99% of "the network" could be malicious
11:17:44	amiller:	maybe the thing to say is that the theorem should apply to *any subnetwork* that satisfies the heuristic
11:21:30	amiller:	2. there are known lower bound results for synchronous networks and digital signatures are available and where nodes have to "finally agree" after some fixed finite time, which I think is close enough to Ripple's setting to be applicable.... in particular the amount of time to reach agreement is proportional to the *absolute number* of nodes that can fail http://www.cs.toronto.edu/~samvas/teaching/2221/handouts/t+1lowerbound.pdf
13:30:00	samson2:	samson2 is now known as samson_
14:59:42	andytoshi:	does anyone remember an altcoin that got wrecked by bad diffchange algorithms?
15:04:21	mr_burdell:	didn't dogecoin change their algorithm because of something like that?
15:05:09	mr_burdell:	btw, if you're writing something about bad algorithms, KGW is pretty bad for light clients
15:05:38	andytoshi:	oh? can you link me to something about KGW, i have avoided it thus far
15:05:45	tacotime:	terracoin heh
15:05:49	andytoshi:	but i am writing the diffchange section of alts.pdf now since there was a q on #bitcoin last night
15:06:14	andytoshi:	thx tacotime
15:06:19	mr_burdell:	i ported electrum to vertcoin and it takes forever to just verify the header chain
15:06:47	mr_burdell:	because it has to do the KGW calculation for every block, which looks back a semi random number of blocks
15:06:47	andytoshi:	weird, i thought it just changed the discretization to something smoother
15:06:53	andytoshi:	oh, weird
15:07:02	tacotime:	https://bitcointalk.org/index.php?topic=167493.0
15:07:57	tacotime:	and that thread https://bitcointalk.org/index.php?topic=261986.0
15:08:00	mr_burdell:	https://bitcoin.stackexchange.com/questions/21730/how-does-the-kimoto-gravity-well-regulate-difficulty
15:08:10	tacotime:	TRC was kind of lulzy
15:24:19	andytoshi:	sigh, wtf is even going on with KGW
15:26:32	mr_burdell:	here's my attempt at SPV with KGW: https://github.com/paybee/electrum-vert/blob/master/lib/blockchain.py#L298
15:26:52	mr_burdell:	I don't think anyone has looked at it to verify if it works... I just know it claims to verify the chain
15:28:24	mr_burdell:	basically, each block is given a mass, and the mass is used to weight that block with respect to its deviation from current difficulty
15:28:33	mr_burdell:	and the mass of blocks trails off as they get older
15:29:25	andytoshi:	ok, cool
15:38:36	andytoshi:	tacotime: mr_burdell: would you mind glancing at section 6.3 of https://download.wpsoftware.net/bitcoin/alts.pdf ?
15:43:44	davispuhh:	davispuhh is now known as davispuh
15:51:21	mr_burdell:	andytoshi: i haven't read all of it yet, but I have another thing you can add: coins with multiple proof of work algorithms (myriadcoin) have an issue of how to compare work from different algorithms
15:51:54	mr_burdell:	some scaling factor is needed to decide how much work is in a chain consisting of blocks with different pow algos
15:52:15	andytoshi:	oh, good idea
16:17:01	Eliel:	scaling factor that modifies the scaling based on how many blocks were found with each algo, trying to balance them out sounds reasonable on first glance.
16:19:26	mr_burdell:	you mean an extra factor for the difficulty or just to change the scaling factor? The difficulty adjustment is supposed to keep the blocks spaced correctly
16:19:55	Eliel:	scaling factor adjustment.
16:19:57	mr_burdell:	the scaling factor is only for deciding between two blocks at the same height
16:21:49	mr_burdell:	lets say sha256 is getting more blocks because it has "more work"... but if you change the scaling factor so the other algos will be considered more work, then won't the difficulty for sha256 actually drop?
16:26:42	andytoshi:	i added a note saying that you've got a lot of extra complexity to handle, i think that's all that needs to be said
16:27:31	andytoshi:	there is an overarching theme to the whole paper that adding complexity for no reason at all is idiotic, and it links to asic-faq.pdf which argues that SHA256 is optimal anyway
16:46:14	Eliel:	mr_burdell: there's no way to have a single difficulty that applies to several hash algos. any scaling factor is necessarily a scaling factor on the difficulty.
16:50:49	gmaxwell:	amiller: did you see my comments in the backlog here about the paper? I was completely perplexed by the topology constraint saying that it didn't matter if the linking hosts were malicious or not.
16:55:52	amiller:	gmaxwell, hm i see that now
16:55:54	amiller:	gmaxwell, i think that constraint was just mentioned as an aside
16:55:56	amiller:	paraphrased "it's interesting to note that no assumption is made on whether the overlapping nodes are malicious or not"
17:03:58	Guest10131:	Guest10131 is now known as maaku
17:05:23	gmaxwell:	Yea, I think thats nuts though. A malicious node might as well not bee there. Imagine you have the two clique network like they show there in the 'good' topology. But one end of each of the two links in the min-cut is malicious. In that case they can simulate varrious degress of complete disconnection or false consensus. And malicious out of the total count there is supposted to be an amount they can handle.
17:11:57	Alanius_:	Alanius_ is now known as Alanius
17:28:45	amiller:	hi gmaxwell\
17:28:57	amiller:	i ;liokvw h";b
17:28:57	amiller:	\
17:45:58	sipa:	amiller's cat, is that you?
18:02:00	Brizo_:	Brizo_ has left #bitcoin-wizards
18:09:22	gmaxwell:	Where I gave up thinking about the necessary and sufficient topology criteria was to imagine considering all possible mixtures of malicious nodes, and then querying every node and checking that no more than a threshold of their peers were malicious. ... and then I realized that test wasn't sufficient because you could meet it while still having a pair of nodes who were partitioned by malicious nodes. At that I threw my hands up, I ...
18:09:28	gmaxwell:	... saw no obvious way to solve it or even know what your security was without very artificial topology constraints... then I posted the two clique example in the ripple thread and I still think they've done nothing to answer it.
18:11:15	gmaxwell:	And maybe they shouldn't have. It's sufficient (but not necessary) to have the trust fully meshed. This is a reasonable requirement in a centerally administered system, and given an apparent lack of guidance on setting up trust relationships at all, that must be what they have.
18:12:57	gmaxwell:	(well I mean, it's sufficient for security if the trust is fully meshed to simply meet the threshold of honest nodes required by the consensus algorithim)
18:23:08	jgarzik:	Meanwhile, on a completely different subject, I'm confounded by the problem of trying to replace IRC without having trusted users run servers/routers of some sort, just to communicate with one's own circle of trusted peeps.
18:23:41	jgarzik:	Need to find some incentive to get people to exchange IRC-like messages in a network
18:23:42	sipa:	you mean twitter? :p
18:23:47	jgarzik:	decentralized!
18:23:55	sipa:	you mean real life?
18:24:00	jgarzik:	virtual!
18:24:33	jgarzik:	sipa, More concretely, I would like a secure IRC replacement that doesn't require me to change all my IRC habits ;p
18:25:09	jgarzik:	sipa, I already wrote & tested the IRC proxy part, just need to find something useful to connect it. https://github.com/jgarzik/dirc
18:25:33	kanzure:	i'm not sure if i should bother reading this http://cdn.anonymousbitcoinbook.com/darkcoin/darksend-paper/Atlas_Darksend-Analysis-v001.pdf
18:26:14	jgarzik:	For "decentralized IRC", I think you would have digitally signed administrative domains (== IRC network). Within that domain, you have channels/users.
18:26:48	Dr-G:	what about SILC?
18:26:50	jgarzik:	Then people can agree to route certain domains (networks), for bitcoin
18:27:27	lechuga_:	i dont think silc addresses decentralized routing
18:28:12	jgarzik:	Indeed. For robustness, deniability and other attributes, it is useful to decouple users & routers if possible
18:31:26	jgarzik:	owel. I guess I can work out router incentives later... Just creating a router that will route digitally-signed messages for , each with a bandwidth limit, should get things going.
18:32:48	jgarzik:	Another fun problem: establishing a session with (logging into) a decentralized service. getting some sort of temporary, secure session token.
18:33:31	kanzure:	is a temporary token necessary if you have pubkey signing anyway?
18:35:19	jgarzik:	a fair question. I guess... the administrative domain digitally authenticates a list of pubkeys (users). from there, you can prove a user is allowed to use the network. and you can prove a user has certain rights on publicly acknowledged channels.
18:35:54	jgarzik:	but some channel management seemed to need more active user acknowledgement and monitoring
18:36:27	kanzure:	was there anything interesting in jabber's federation-based architecture, or was it more holey than swiss cheese?
18:37:23	jgarzik:	Nobody ever tried to create a fully enclosed system (from digital authentication perspective) AFAIK
18:39:04	jgarzik:	the dataset feels chain-esque. no need for proof-of-work, just proof you are within the digital envelope, and have certain rights to manage namespace, user or channel state
18:39:36	jgarzik:	I don't mean putting messages in a chain, just the metadata about the admin domain
18:42:31	kanzure:	someone wrote a proposal involving namespace registration using a bitcoin address scheme (and i was asked not to distribute the proposal)
18:42:49	kanzure:	(but then it turned out that he got criticism and backed down, so i don't know how that changes whether or not i should be sharing the link)
18:43:36	Taek42:	jgarzik if decentralized file storage ever becomes a thing you could just have each irc channel be a different file, people make comments by appending to the file. You could register usernames against public keys on some other file that everyone checks, and use signed messages to verify that a message came from a trusted handle
18:43:50	kanzure:	it was something like, storing data inside of an address that gets paid, and the latest address sent to is the one that gets used for the most recent data (like an ip address)
18:44:47	gmaxwell:	kanzure: I've seen the proposal, it was a pretty nasty spam the blockchain proposal; as has been suggested many times before (though this time in IETF draft form)
18:45:37	kanzure:	my description is lacking but yeah that's the one
18:45:54	gmaxwell:	I don't think namespacing is really the interesting problem in this sort of thing. If nothing else "pubkey is the name" is workable if ugly.
18:46:36	Dr-G:	Dr-G is now known as Shlomogolddoge
18:49:29	Aquent:	have you guys read this tweet: https://twitter.com/NickSzabo4/status/510207346807959552
18:49:40	Aquent:	is he talkng about using the blockchain to secure nicknames?
18:49:42	grubles:	grubles is now known as Guest987
18:50:27	jgarzik:	namespace itself isn't an interesting problem at all. People like readable names. An administrative domain provides a single namespace (a la IRC). You can implement IRC-like channel creation policies within a digital secure envelope.
18:50:35	jgarzik:	No need to restore to unreadable names.
18:50:38	jgarzik:	*resort
18:51:30	kanzure:	if you can't figure out how to get people routing irc messages in an incentive-compatible manner, maybe just the ability to shift channels around to different central nodes would be an improvement from the current situation (but also a little more boring)
18:52:06	jgarzik:	I think people would be willing to say "I'll donate X bandwidth to Y network"
18:52:24	jgarzik:	and software can take it from there, since messages are provably within a network
18:54:58	gmaxwell:	jgarzik: I'm just saying that if you had it all working with unreadable names then mapping one to the other "reduces to a previously solved (if poorly) problem"... it's not an issue unique to the IRC stuff.
18:58:40	tacotime:	andytoshi: will have a read through when i get a chance
19:04:31	jgarzik:	gmaxwell, indeed
19:05:17	jgarzik:	gmaxwell, it's a balance of philosophies at that point. I would ideally like a system where "#bitcoin-dev" is long lived and has clear channel owners
19:05:57	jgarzik:	one way to do that is with an admin db, another more-decentralized way is just pubkeys, no toplevel at all
19:07:13	jgarzik:	a decentralized freenode, in the former design, would devolve down to "staff" being the folks that hold keys and control top level policy via digitally signed message
19:08:26	mist:	[Global Notice] Reminder - This weekend freenode staff identified some compromised binaries present on a number of servers in the network. These servers have been taken offline. Since password-sniffing may have taken place, we advise all users to change their passwords. /msg nickserv set password newpasshere. More information will follow later in the week. http://blog.freenode.net/2014/09/server-issues-2/
19:08:42	gmaxwell:	Well, you can imagine a system where every channel has some descriptor stored in something like namecoin. The descriptor lists what hosts you should connect to as the meeting points for the channel. The operators of the channel can update the descriptors (and the list of operators). Meeting points would mostly be trusted to not drop messages.. with everything encrypted and authenticated the meetings points couldn't spy (beyond ...
19:08:48	gmaxwell:	... traffic analysis) or forge messages.
19:09:24	gmaxwell:	though that kind of design leads to namesquatting, e.g. where atlas registers #bitcoin-dev and there is no way to get it from it, leaving actual technical people to #bitcoin-dev-for-real
19:12:29	mist:	[Global Notice] Please note - this is not a new issue, just another notice of the same issue from the weekend. If you already changed your password following the previous announcement you do not need to change it again. Sorry for any confusion.
19:13:37	Luke-Jr:	IMO this kind of namespace issue can only realistically be resolved with UUID-type identifiers that people can assign aliases to.
19:26:26	jgarzik:	gmaxwell, Yes, that's the tradeoff
19:26:42	jgarzik:	gmaxwell, top-level control permits namespace conflict resolution
19:27:13	jgarzik:	And I think that's fine, in a universe of many networks. If you don't like a network, there are others.
19:28:15	jgarzik:	Someone can just as easily create an administrative domain with zero intervention, first-come-first-served, anything-goes policy.
19:29:12	jgarzik:	Nodes choose to route a list of networks, and can easily include or exclude the FreeNode, Garzik, or AnythingGoes networks.
19:30:32	jgarzik:	You could route a namecoin-secured domain, with proof taken from namecoin indeed
19:32:45	Guest987:	Guest987 is now known as grubles
19:34:01	jgarzik:	Ah, yes, now I remember why I wanted logins / sessions.
19:34:19	jgarzik:	Each router needs to prove that a message belongs to a certain network.
19:35:25	jgarzik:	The simplest way to do that is have a list of network pubkeys, ONE per network, and each message is verified against that. However, that requires $some entity other than a router wrap each user's message in a network envelope. Not workable.
19:35:51	jgarzik:	The alternative, as just discussed, is for the router to prove each user is permitted to send a message on the network.
19:36:34	jgarzik:	A third option is a compromise between the two, where you prove you're credentialed on the network for a little while, yet not exposing the full public key list to each router.
19:36:43	jgarzik:	full public key *user list
19:38:00	jgarzik:	routers see session granularity, but not user granularity. If a user rotates sessions on a regular basis, this is useful.
19:38:34	jgarzik:	Session tokens, like the network envelope, require a provider $somewhere
20:05:46	Aquent:	jgarzik how come we dont already have decentralized provable identity
20:06:44	jgarzik:	Aquent, we do. PGP and SIN are two examples.
20:07:25	Aquent:	I'm refering to this https://twitter.com/jgarzik/status/511226752690315265
20:13:22	Aquent:	or did you mean pgp will get bigger than bitcoin?
20:20:42	jgarzik:	Aquent, the base tech exists. just need to build it out.
20:24:26	kanzure:	i am surprised that freenode hasn't kicked all the altcoins (or even bitcoin) off entirely, given the huge potential for spam
20:24:43	kanzure:	i don't know if they made a public decision about this
20:31:09	jgarzik:	I would not be surprised if bitcoin/altcoins were the primary source of their headaches
20:34:09	kanzure:	on the other hand, it is endlessly amusing and useful to me that the entire cryptocurrency world gets routed through freenode/irc
20:45:27	Aquent:	a decentralized freenode with fully encrypted communication would be awsome
20:54:57	nsh:	unless it was awful
20:56:10	Aquent:	yes, I guess thats implied
21:13:31	phantomcircuit:	You could route a namecoin-secured domain, with proof taken from namecoin indeed
21:13:46	phantomcircuit:	except namecoin is constantly broken
21:24:46	midnightmagic:	ehh, sort of.
21:29:15	jgarzik:	phantomcircuit, ok namecoin-like chain
22:46:49	Shlomogolddoge:	Shlomogolddoge is now known as Dr-G
23:53:18	Taek42:	Would someone like to take a look at this for me?
23:53:32	Taek42:	It's about randomly assigning files to hosts in a byzantine environment
23:53:34	Taek42:	https://drive.google.com/file/d/0B9mQIFwx4-0NUFRaZzEwZWQzaFE/edit?usp=sharing