--- Log opened Fri Jan 24 00:00:55 2014
12:58 < imsaguy> All you people don't get bitcoin.
12:59 < gmaxwell> 0_o
12:59 < _ingsoc> xD
12:59 < _ingsoc> Okay then.
12:59 < amiller> thanks
13:15 < midnightmagic> He's mocking me because I told him most people in #bitcoin* probably don't understand bitcoin.
13:16 < gmaxwell> ah
13:17 < tacotime_> we're way more knowledgeable over here in wizards
13:18 < tacotime_> what's a blockchain?
13:18 < amiller> i just met yet a few more unexpected people who are pursuing bitcoin research
13:18 < amiller> especially a pretty famous programming-languages person who apparently is about to publish a type-theory altcoin proposal
13:19 < nsh> yay
13:19  * nsh premines some functorcoins
13:19 < amiller> LOL
13:20 < amiller> it was weird, he was explaining the linear type system that it will use
13:20 < amiller> i said, cool, do you have any particular motivating example in mind
13:20 < amiller> he was like no not at all.
13:20 < gmaxwell> hahaha
13:20 < gmaxwell> <foo> but in a cryptocurrency.
13:21 < amiller> "welcome. you'll fit right in here."
13:21 < tacotime_> the screaming robot of cryptocurrencies.
13:21 < tacotime_> hahaha
13:22 < nsh> Linear type systems are the internal language of closed symmetric monoidal categories, much in the same way that simply typed lambda calculus is the language of Cartesian closed categories. More precisely, one may construct functors between the category of linear type systems and the category of closed symmetric monoidal categories.[7]
13:22 < nsh> -- http://en.wikipedia.org/wiki/Substructural_type_system#Linear_type_systems
13:22 < nsh> should be fun...
13:23 < amiller> linear logic is good for modeling resources
13:24 < amiller> for example from one quarter, you can derive two dimes and a nickel
13:24 < amiller> also from one quarter, you can derive five nickels
13:24 < amiller> but that doesn't mean you can take a quarter and derive six nickels and two dimes
13:24 < nsh> kinda like typing with accountancy baked in
13:24 < tacotime_> Hmm.
13:24 < amiller> you could probably express all the conservation rules about no inflation etc using linear logic (though i think it would be overkill)
13:25 < tacotime_> What's the real world application?
13:25 < amiller> well take ethereum scripts for example
13:25 < amiller> maybe you'd like to be able to typecheck them and prove they don't leak value somehow
13:25 < tacotime_> Ah
13:28 < tacotime_> So like proof-carrying code?
13:29 < amiller> i think so (but i'm really not sure)
13:29 < gmaxwell> amiller: I don't know why that really matters inside a cryptocurrency. We shouldn't have code in a cryptocurrency, we should have wittnesses for code other people ran.
13:30 < amiller> i told him about snarks and pinocchiocoin, he knew about pcp proofs
13:31 < gmaxwell> You can think of that stuff just as a performance optimization.
13:31 < amiller> then sure
13:32 < amiller> so when the witnesses about code that other people ran, are about values that are of global importance, like a monetary supply, then applying this sort of conservation logic would be relevant
13:32 < gmaxwell> Well, sure I think it's good to create things using tools for soundness, but there isn't any reason to leave them in inside the witness.
13:33 < tacotime_> You can provide withness for executed code without executing the code yourself to verify it?
13:33 < gmaxwell> type data is precisely the sort of thing you can omit in a witness when extracting it from an execution trace, even before you go the route of converting the execution trace into a snark.
13:34 < tacotime_> I'm unfamiliar with a lot of this "proofs" stuff used for ZRC etc
13:34 < gmaxwell> tacotime_: Yes, thats what a snark is, a proof that code was fairthfully executed which is logarithmic in the length of the exeuction (or smaller, with cryptographic assumptions they can be constant size in the security parameter)
13:34 < tacotime_> Ah, I see.
13:35 < andytoshi> tacotime_: thank you for acting incredulous about that. i wish more people here would explicitly mention how mind-boggling this is :P
13:36 < nsh> once you accept the existence of voodoo magic, it's a relatively trivial corollary
13:36 < gmaxwell> PCP theorem proves that any execution in NP is provable with arbitrary soundness compactly, though PCP doesn't directly give a pratical way to go about doing it.
13:37 < tacotime_> Hahaha.  Well, I never used to hang out here so a lot of this stuff is novel to me.  I only sat around bitcointalk and the issues over there regarding what they want in altchains is apparently very different.
13:38 < tacotime_> *are
13:38 < andytoshi> gmaxwell: is there a nice paper summarizing the pcp theorem's history and proof? wiki sorta says "it's smeared over 30 years of history, good luck friend"
13:38 < amiller> this stuff is at the front of theoretical cryptography, it should be novel to pretty everyone, it's pretty exciting we have a reason to discuss it at all (which is why even the cryptographers working on it are like, oh this is practical, it's even relevant for bitcoin)
13:38 < amiller> andytoshi, hah.
13:38 < amiller> http://courses.cs.washington.edu/courses/cse533/05au/pcp-history.pdf
13:38 < tacotime_> Thanks
13:39 < gmaxwell> Well I don't think proving in zero knoweldge is _that_ remarkable, that the proofs can be sublinear in size is somewhat remarkable.
13:40 < andytoshi> amiller: thanks!  gmaxwell: the sublinearity is weird, it feels like skirting P=NP in the same way as quantum entanglement skirts "can't send signals faster than time"
13:40 < nsh> hehmm
13:40 < andytoshi> that is, there is no actual violation, but it seems like -something- in the platonic realm must be violating it
13:40 < amiller> https://eprint.iacr.org/2012/215.pdf this is the big theoretical result that made SNARKs a hot topic
13:41 < amiller> it's underlying TinyRAM and Pinocchio etc
13:41 < amiller> some of its paragraphs are possible to read...
13:41 < nsh> andytoshi, i had similar intuitive feelings, but hadn't made that analogy. thanks
13:41 < gmaxwell> Thats the GGPR'12 paper. Meh. well, it's not the only thing that made it a hot topic.
13:42 < amiller> hrm, what's the best thing preceding it?
13:42 < gmaxwell> andytoshi: well it can be useful to think about what you give up in both cases.  SNARKS in sublinear size 'only' have computational soundness.
13:42 < amiller> proofs for muggles maybe
13:43 < amiller> no proofs for muggles is interactive
13:43 < gmaxwell> Really the major breakthrough that allows sublinear is bootstrapping, which I think was mostly really inspired by the FHE work.
13:43 < tacotime_> I can tell already that I will never understand that paper.  But that's what proves the sublinear size and makes 288 byte SNARKs possible?
13:43 < gmaxwell> You can make it non-interative with fiat shamir IIRC, most interactive things can be.
13:44 < gmaxwell> tacotime_: the GGPR'12 technique is constant size proofs.  There are a couple of high level ideas that can help you intutively understand why sublinear proofs are possible.
13:45 < andytoshi> fiat-shamir is also really cool philosophically. it's like you summon a random oracle to do the interactive proof with you and publish the transcript
13:47 < gmaxwell> tacotime_: imagine you have a system which can prove the validity of two operations: executing a single instruction AND verifying a proof that the prior state for that instruction.  If the proof verficiation is randomized/probablistic, then its not surprising that the proof size can be proportional to security rather than execution size... and then you nest these operations and get a constant size proof. (bootstrapping approach). ...
13:48 < gmaxwell> ... Efficient systems don't work directly in this way, but its an intutive way to see the possiblity.
13:48 < andytoshi> as for SNARKs being "'only' computationally sound", that seems to be strongly analogous to the quantum-entanglement scenario wherein your "faster than light correlation" can only be verified by communicating slower than light
13:48 < gmaxwell> andytoshi: thats why I pointed it out.
13:48 < andytoshi> gmaxwell: yeah, i realize that. but i'm that slow :)
13:49 < nsh> (slow is pretty damn relative here)
13:49 < andytoshi> realize that now*
13:49 < gmaxwell> amiller: yea, fiat shamir is insanely useful. I'm not sure why its not more widely known.  It doesn't help that the original papers on it are a bit opaque.
13:50 < andytoshi> the original paper pretends to be about the smart-card scheme, it's really not obvious that there is anything generally useful in there at all until you read it :(
13:51 < nsh> "The heuristic was originally presented without a proof of security; later, Pointcheval and Stern [2] proved its security against chosen message attacks in the random oracle model, that is, under the assumption that random oracles exist. In the case that random oracles don't exist, the Fiat–Shamir heuristic has been proven insecure by Goldwasser and Kalai.[3] The Fiat–Shamir heuristic thus demonstrates a major application of random oracles." - http:/
13:51 < nsh> /en.wikipedia.org/wiki/Fiat%E2%80%93Shamir_heuristic
13:51 < gmaxwell> yea, that article is useless.
13:51  * nsh frowns at irc client
13:53 < nsh> kinda provocative that you could have some empirical security difference that implies the existence or not of random oracles
13:53 < tacotime_> Is there a text book somewhere for this sort of stuff?
13:54 < jtimon> gmaxwell, if you were to design a concatenative merklized scripting language (joyscript), what would be important to take into account so that in the future it is "good for snark"
13:54 < jtimon> ?
13:54 < gmaxwell> Basically it says you can take an interactive protocol and make it non-interactive by commiting to your state with a random oracle, then using the random oracle to play the counterparty in the interactive protcol.  If the interactive protocol has the right properties then you can instantiate the system with a hash function in the place of the random oracle and make a secure conversion.
13:55 < andytoshi> jtimon: you want to be able to easily bound the time-to-execute for scripts
13:55 < andytoshi> for a concatenative language maybe that is as easy as computing a tree height
13:56 < gmaxwell> andytoshi: only if you can describe an efficient arithemetic circuit for evaluating the concatenative language such that execution = tree height. This seems unlikely to me.
13:59 < jtimon> wouldn't those problems be solved with the instruction counter?
14:00 < tacotime_> Okay, I think it's starting to make sense.  We have algorithm A, with non-arbitrary input I and output O.  The proof takes input I_ro from a random oracle (hash function) and produces output O_ro using A(I_ro).  We can then prove the execution of A(I) for some non-arbitrary input I.
14:00 < jtimon> btw, maaku, I don't think your message got to the concatenative group maybe you had to enter the tahoo group after all
14:01 < jtimon> http://groups.yahoo.com/neo/groups/concatenative/conversations/messages
14:01 < tacotime_> With some small amount of bytes using SNARK, because the proof is logarithmic in size?
14:01 < gmaxwell> jtimon: current constructions for snarks require costly preprocessing which is program generic but specific to the machine beging evaluated and specific to the length of execution.
14:03 < tacotime_> Is that the overall gist of what's going on?
14:03 < tacotime_> My background is in biochem, so sometimes I'm a little slow for CS stuff, forgive me.
14:04 < jtimon> gmaxwell I don't think I understood that, but I'm asking with the hope that those costly executions become cheaper in the future somehow
14:04 < gmaxwell> tacotime_: I'm not sure I followed what you were saying clearly enough there to agree or disagree.  Another way to look at it is that program validation and program execution are not the same problem. Imagine making a transcript of a program execution— you write down every instruction that gets run and then the state (memory, registers, etc) along the way.
14:05 < gmaxwell> The result is a transcript— or sometimes called a witness— of the execution.
14:05 < andytoshi> jtimon: the other problem is that the preprocessing step has a security parameter which can be used for forging. this is a serious problem when there is one guy (the coin creator say) who is doing the preproccessing step, but it'd kill the scheme if everybody was doing their own preprocessing
14:05 < gmaxwell> If I give you such a transcript I can ask you if its valid, to tell if its valid you walk through the instructions and then check that the instructions match the rules e.g. that an ADD instruction updates the state in the right way.
14:06 < tacotime_> Right.
14:06 < jtimon> for those who are interested in this joyscript thing, this is the message that maaku (tried to?) send to the concatenative mailing list http://pastebin.com/5ScNX7vy
14:06 < gmaxwell> tacotime_: what all of this stuff is based on is that there exist ways of encoding the transcript so that if you only check a tiny portion of it, that you can become very confident that the whole transcript was faithful.
14:06 < jtimon> andytoshi, I see, like zerocoin's trapdoor
14:06 < andytoshi> yeah exactly
14:07 < tacotime_> Given some non-arbitary input?
14:07 < andytoshi> i had some vague ideas about using a variant of FHE to obtain the security parameter from a random oracle in a zk way (so provable nobody knows it) but i ran into serious conceptual problems when i tried to make these ideas concrete
14:07 < gmaxwell> for any input. well technically what you do is provide the inputs and 'outputs' as inputs and then the whole program just decides to accept (inputs agreed with the program) or not... e.g. convert it into a decision problem.
14:09 < tacotime_> Okay.
14:09 < jtimon> and if anyone is more interested, I can forward what maaku has been discussing with an strong typed concatenative language expert (the guy who wrote that "why concatenative matters" article) [unless you maaku haave some objection to sharing it, which I doubt]
14:09 < andytoshi> basically, you want it to be verifiable that you actually got the security parameter from the oracle -and- you only used it for a specific circuit (zk-snark preprocessing) and couldn't have used it in a circuit which reveals the parameter
14:09 < andytoshi> but these two requirements conflict when you try to implement them in the 'obvious' ways it seems
14:11 < andytoshi> that is, if you tie the parameter to a specific circuit it's hard to make it random (it's hard to make it at all actually). and conversely if you want to make it random it's hard to tie it to a circuit, but if you don't then it's trivial to replace the circuit with one that reveals it, defeating the whole exercise
14:14 < gmaxwell> andytoshi: why can't you just pick a ciphertext input to the circuit at random (e.g. because you don't know the decryption key)?
14:17 < andytoshi> gmaxwell: to implement this "tie the input to the circuit" scheme, my thought was to make the key derivation depend on the circuit
14:18 < andytoshi> but when you do this, it becomes hard (or rather outside the things i'm aware of being possible) to create a decryption key without an encryption key
14:19 < andytoshi> the hope was, i could make the output-decryption key be "111111" or something which clearly has no input-encryption key. then i can put whatever i want as input and what the circuit sees will be random and unknown
14:20 < andytoshi> but it seems implausible that just using 111111 will get me a valid decryption key, since my key derivation is so complicated
14:21 < gmaxwell> I still don't understand how the reencryption used in bootstrapping FHE can even work at all, so that sort of leaves me powerless to speculate about how you can get unknown encrypted with known decryption key FHE. I think it would be very powerful and not just for this if its possible.
14:22 < andytoshi> ditto. i have been trying to meet with brent waters, who has published several papers with craig gentry about FHE, because i'm trying to seduce him into supervising me. but he's been out of the country a lot this semester. whenever i get ahold of him i'll bring this up and maybe he can speculate more intelligently
14:24 < gmaxwell> one of the limitations in all this verifyable computing stuff compared to MPC is that you can't keep secrets from yourself. ... but MPC doesn't really get you security in an anonymous model. if you had what you want you could have a publically verifyable version of everything MPC can do.
14:25 < gmaxwell> For example, you could have a captcha POW coin.
14:27 < andytoshi> yeah, and the mere fact that we could get so much magic out of this suggests its implausibility. but idk, maybe we can get all or partway there. i'd like to spend some time researching this.
14:30 < andytoshi> probably 100% of what we've discussed in the last hour, if you asked me 18 months ago if any of it were possible, i'd have said not a chance. so i'm optimistic.
14:31 < gmaxwell> well, perhaps the existance of one way functions sort of suggests the possiblity of it.
14:32 < andytoshi> my money is on their existence being ZFC-undecidable :P
14:33 < andytoshi> halting-complete rather
14:45 < andytoshi> another problem i thought of is that the key-derivation scheme could be malleable. that is, you can tweak the circuit and this changes the key in some predictable way, so you can still steal information about the input this way. so i thought, the KDF should basically evaluate the circuit but attach to each gate a one-way function which is somehow specific to that gate. and then i started to think
14:45 < andytoshi> it'd be very hard to preserve enough information through all this that i could decrypt the information in the end.
14:45 < andytoshi> decrypt the actual output*
14:46 < andytoshi> maybe you take the encryption key, run it though some shadow version of the circuit made of OWFs, then the output of that could be the trapdoor information needed to decrypt the output
15:47 < nsh> hmm
15:49 < nsh> occurs to me that the dynamics of difficulty adjustment are much more complex now you have pools supporting multiple-coins leading to positive feedback from hopping driving instability
15:51 < nsh> there was a significant first-mover advantage with bitcoin in that slushy liquid hashpower was not even a thing until it was relatively mature
15:51 < nsh> to what extent that is balanced by lessons (theoretically) learned is another question
15:56 < maaku_> nsh: fickle hashpower utterly destroys alts with bitcoin's stock difficulty adjustment algorithm
15:56  * nsh nods
15:57 < maaku_> most adjustment algorithms used by alt devs are broken, on the other hand
15:57  * nsh looking at vertcoin, which seems to be an actual effort, at least
15:58 < nsh> 67 pages of trollcointalk thread is quite depressing though. wish there was a way to getting the 5-10 posts that are actually worth reading out
15:58 < maaku_> amiller: do you have contact details for th type theory language person?
15:58 < maaku_> that's someone I'd want to talk to about scripting extensions
16:07 < maaku_> nsh: there's also this, which we spent considerable time crafting : https://github.com/freicoin/freicoin/commit/d82a66e10f413bc81889b48a498625829353d701
16:07 < nsh> looking
16:08 < maaku_> i think gmaxwell would have preferred using bessel functions, but an FIR filter has worked fairly well so far
16:08 < nsh> i recall gmaxwell demurring somewhat. but i guess it's held out pretty well?
16:08 < nsh> right
16:10 < maaku_> it has made the problem go from catestrophic to merely annoying
16:11 < gmaxwell> I watched it for a while and it seemed fairly poorly controled, but I never looked at it before the change.
16:11 < maaku_> there is still a major hopping pool which regularly hits us when profitability creeps up, but only snags a couple of dozen blocks before the difficulty adjusts back up
16:12 < gmaxwell> I'd worry that if there were two of those it might be unstable. but apparently not in practice.
16:13 < maaku_> I don't think there's anyone else using the same filter, but there are mare than two using fast-acting filters
16:13 < maaku_> and that's what the coin hopping pools are doing, jumping back and forth
16:13 < maaku_> i'd be interesting in hearing ideas about a better filter
16:14 < maaku_> although I think there are some fundamental problems here that won't go away
16:14 < maaku_> e.g. there's only so much you can do to mitigate the damage
16:15 < gmaxwell> creating strategic behavior isn't so hot though.
16:19 < nsh> a bunch of coins could probably dampen the effects of pools hopping with a profitability peg
16:19 < nsh> perhaps
16:19 < maaku_> nsh: vertcoin looks like stock bitcoin difficulty adjustment (+ time traveller patch)
16:20 < maaku_> nsh: well, you'd think profitability-seeking is, well, profitable. but it is not
16:20 < nsh> (could be. haven't quite figured out what the NFactor scrypt difference is they're pimping)
16:20 < maaku_> due to coinbase maturity & distribution delays, they get the coins *after* dips in prices due to their activities
16:20 < nsh> right
16:21 < nsh> i doubt the pool operators have analyzed it very deeply
16:21 < maaku_> i've seen people model this, and it's almost always 10% or so worse than mining a single coin
16:21  * nsh nods
16:21 < maaku_> although there could be other strategies - e.g., mine the 2nd most profitable coin, in order to stay in frant of the bigger pool hopper
16:21 < nsh> you could probably account for hysteresis to some degree but the uncertainty would eat into the profitability
16:22 < nsh> right, but that's not robust with many players
16:24 < maaku_> it does show that you'd have to do some serious game theoretic analysis to figure out what optimal strategies are
16:24  * nsh nods
16:24 < maaku_> and even then, you're battling human psychology, because we know that even the guiding hand of the market has led people to an inefficient strategy in practice
16:25 < nsh> i'm sure there's some law to the effect that people will always find a way to be more irrational than your models
16:25 < maaku_> so, in our case, we actually relied mostly on historical bitcoin data in the creation of our filter
16:25  * nsh nods
16:25 < maaku_> we figured it's better to design something which works well at that scale
16:25 < maaku_> than over-optimise to solve this particular problem, which by nature goes away if you are the chief coin (or MM against it)
16:26 < nsh> right
16:26 < amiller> maaku_, i don't want to say any more about it until i get his permission
16:26 < amiller> maaku_, but i showed him your utxo engineering page
16:26 < gmaxwell> maaku_: I'm not sure that I would have used that data in design other than a validation test. The problem you need to engineer for here is a dynamic system problem so just some static data trace from bitcoin doesn't show you data from miners switching on and off in response to the difficulty.
16:27 < maaku_> amiller: well if you want you can show him this too: http://pastebin.com/5ScNX7vy
16:27 < maaku_> it's what I want his opinion on
16:27 < maaku_> and sounds like it might be related
16:27 < maaku_> gmaxwell: we used bitcoin, litecoin, and freicoin data
16:29 < maaku_> and a success metric of how close the chain would have stayed to 10 minute block times
16:31 < maaku_> interestingly the curves (various parameters vs simulated performance) remained the same for all three coins despite the different problems encountered by each. just noisier in the case of litecoin and freicoin
16:31 < maaku_> so we picked the fastest-acting values which were noise free, which by coincidence were also the best for bitcoin
16:36 < nsh> how was noise-free defined?
16:37 < gmaxwell> maaku_: I'd think that what I'd want to do is use the bitcoin/litecoin blockchain and market data to derrivate parameters for a model of miner behavior. (e.g. how fast do miners add and remove hashpower when its (un)profitable.) and then calibrate the control system against the miner model.
16:53 < maaku_> nsh: 1000's of simulations run, results plotted, then eyeballed
16:53 < nsh> right
16:53 < maaku_> so, tight grouping of data points
16:53  * nsh nods
16:53 < maaku_> unfortunately all this work is on another hard drive
16:54 < maaku_> or i'd dig up some of the graphs
16:55 < nsh> no worries
19:30 < jtimon> gmaxwell maaku_ nsh I think it's the chain-hoping algos and not the filters what need to improve most, provided that you have a responsive enough filter
19:31 < jtimon> they are really dumb
19:31  * nsh nods
19:32 < jtimon> they believe anything that's in some webs that calculate profitability simply from spot price without any look to market depth, volume or vollatility
19:32 < jtimon> http://www.coinwarz.com/cryptocurrency
19:33 < jtimon> It's very easy to put a small coin on top of that list with little money
19:35 < jtimon> and hop-miners jump into shitcoin just to find out later that they broke the price when dumping their mined coins into the market
19:36 < jtimon> a good algorithm just needs to target a time period, the market should make profitability tend to 0%
19:38 < jtimon> just not yet
19:40 < jtimon> I think the non-merged-mined SHA256 are in the worse position for chain-hoping
19:40 < jtimon> so I'm pretty happy with freicoin's filter, things will only get better when MM
19:42 < jtimon> and other coins that don't use the block height for demurrage care less about not being always 10 min
19:43 < jtimon> even terracoin survives with its random-like filter
19:46 < gmaxwell> jtimon: I'm more worred about things like long term behavior with fees being compariable in magnitude to subsidy and miners mining near breakeven in power cost.
19:47 < gmaxwell> and then things like filter overshoot making huge chunks of hashpower go unprofitable and shut off automatically. such a system could very likely be quite unstable.
19:48 < gmaxwell> e.g. a small overshoot oscilation magnifies until all the hashrate is turning off.
19:48 < jtimon> for the filter it's the same, you need to adjust rapidly when big hashing comes and goes
19:49 < gmaxwell> "it's the same"?
19:50 < jtimon> I'm not saying it's not a difficult problem, I'm saying you can model the filter with against random curves without modeling any mining economics
19:51 < gmaxwell> No you can't. A filter with overshoot behaves very differently in a non-linear system than does one which is critically damped.
19:51 < jtimon> there could be an earthquake destroying 40% of the hashrate and you should be preapared as well
19:51 < phantomcircuit> gmaxwell, is there a cap on how large the change in difficult can be for any one period? (either up or down) ?
19:51 < gmaxwell> What I'm pointing out is that some filters can actually cause system failure under some mining economics models.
19:51 < gmaxwell> phantomcircuit: yes, 4x.
19:51 < phantomcircuit> oh
19:51 < gmaxwell> (in both directions)
19:52 < phantomcircuit> so that's effectively only relevant for down
19:52 < jtimon> gmaxwell I think all filters could fail under certain conditions
19:52 < gmaxwell> the box filter is probably unconditionally safe.
19:52 < jtimon> you must chose the conditions you're not prepared for
19:52 < gmaxwell> jtimon: forget "prepared", I'm pointing out that some designs can fail when nothing changes or goes wrong.
19:54 < gmaxwell> In an enviroment where miners turn off when not profitable and turn on when profitable, a design that has overshoot can drive the system into instability. miners turn on, diff goes up, but it goes up too much and then even more miners turn off. then when it goes down it goes down by too much and more miners turn on, and each swing a great portion of the hashrate is being pulled into the oscillation.
19:54 < jtimon> I haven't studied any of the filters so I believe a box filter could be better and there's designs that can failt with a constant hashrate
19:54 < midnightmagic> keynesian beauty contest to the rescue?
19:54 < midnightmagic> :-)
19:54 < jtimon> but when's the point in chosing those?
19:55 < gmaxwell> jtimon: I think the design in freicoin is one that can fail with constant hashrate!
19:55 < jtimon> gmaxwell you can also manually change diff with a hardfork
19:55 < gmaxwell> (it has a pretty substantial overshoot)
19:56 < jtimon> oh, I see
19:56 < jtimon> I didn't know
19:56 < gmaxwell> jtimon: which is part of the reason that worrying about black swans is probably a waste of time, esp if the result is something thats riskier.
19:56 < jtimon> like most times, it's a tradeoff
20:00 < jtimon> in any case, maybe you're right that a less "responsive" filter is better long term, with a mature market without so much subsidy
20:01 < jtimon> but in this case (allowing bitcoin asic miners to come and go, but not to mine both at the same time) we desperately needed something more prepared for wild swings
20:03 < gmaxwell> my complaint there is not about responsive.
20:05 < maaku_> gmaxwell: the overshoot is not that substantial
20:05 < maaku_> the prarameters themselves are slightly underdamped
20:05 < maaku_> and the overshoot comes from the 144-block window
20:06 < gmaxwell> maaku_: Hm. from the FIR filter I saw you using before it could be as high as 20%, IIRC though perhaps it got changed?
20:06 < maaku_> so with big square-wave changes, it takes a dozen or more blocks to react
20:06 < maaku_> no, it hasn't changed.
20:07 < maaku_> i just have a different opinion of those numbers - overshooting by 20% when someone is toggling an order of magnitude more hash power than your entire network is pretty good, imho
20:07 < maaku_> we were <1Th/s, and getting hit by 10Th/s chain hoppers
20:10 < gmaxwell> thats not what overshoot means, thats called group delay when it takes a long time to react at all.
20:11 < gmaxwell> Overshoot is when it does react that it can react more than the change.
20:12 < maaku_> yes, well you want a little bit of that
20:12 < maaku_> you want it to be underdamped, slightly
22:37 < justanotheruser1> How many inputs and how many outputs can be in a transaction? Is there a limit on this other than 1mb?
--- Log closed Sat Jan 25 00:00:57 2014