--- Log opened Fri Nov 29 00:00:17 2013
00:26 < maaku> has the zerocash paper made its way around yet?
00:33 < warren> it was renamed?
00:33 < maaku> he said on twitter that's what they're calling zerocoin 2.0
00:33 < maaku> matt green
00:33 < maaku> also are there any generally known limitations of TinyRAM?
00:33 < maaku> i know there was some discussion of this a while back on -wizards, but I can't find it in my logs
00:39 < maaku> ugh there's no rotate opcode in TinyRAM...
01:34 < gmaxwell> maaku: if you want something efficient, best not to use TinyRAM. TinyRAM has the benefit of being general, but…
01:36 < gmaxwell> It would be interesting to evaluate all the well studied cryptographic hashes and see which would result in the most efficient quadratic span program proofs.
01:37 < gmaxwell> sha2 is probably mixed, the additionas are super cheap as QSPs but the circular rotations probably are not.
01:51 < maaku> gmaxwell: i'm looking for something general
01:52 < maaku> is there a better architecture than TinyRAM?
01:52 < gmaxwell> maaku: in any case, what tinyram is optimized for is the size of the QSP circuit that implements the tinyram validator, since thats the primary consideration in proving time and memory consumption.
01:54 < gmaxwell> they give a bunch of figures in one of their papers for compiling varrious programs to tineram, the cycle overhead from its limitations isn't so bad on most of the things they characterized.
01:55 < gmaxwell> directly designing your algorithim at the circuit level will probably always produce a much more efficient (proving time wise, at least) result...
01:56 < maaku> gmaxwell: i'm curiuos about replacing/augmenting the bitcoin scripting language with tinyram
01:57 < gmaxwell> right, well if that were done the part inside bitcoin wouldn't be tinyram, it would just be a proof validator.
01:58 < gmaxwell> wrt replacing script with tinyram, it would probably be prudent to add to tinyram a number of opcodes like sha256 or at least sha256_round
01:59 < maaku> yes
01:59 < maaku> i found it strange how some basic opcodes were missing from tinyram, like rot, and was wondering if that was a fundamental crypto limitation, or just an oddity
02:00 < gmaxwell> what might be interesting is to add asm {} blocks to a compiler for tinyram that could just let you include a circuit description directly.
02:01 < gmaxwell> maaku: no they intentionally left things out that weren't needed to get a basically good high performance implementation and which were either redundant or required larger validation circuits.
02:01 < maaku> if i went forward on this, iwould probably look at extending tinyram to be the MIPS-I isa, plus some crypto accelerator primitives
02:01 < maaku> hrm
02:02 < maaku> ok so this is really just infrastructure anyway, right? the fundamental "machine code" is the circuit
02:02 < maaku> which tinyram compiles down to
02:04 < gmaxwell> well not quite, the way it works is that there is a circuit they've already designed which verifies transcripts of tinyram execution, which is generic and can be reused for multiple instances (important because the keys needed to prove and veryify the circuit are not tiny).
02:04 < gmaxwell> (I guess that would get in the way of asm {} blocks...)
02:05 < gmaxwell> of course you could have arbritary circuits, but thats a fair amount more data you need to communicate.
02:05 < gmaxwell> vs if everyone uses the same tinyram circuit, then your proof is just a small number of field elements and the hash of the program being run.
02:07 < gmaxwell> (the validator is really validating a stament of the form  "The signer knows a transcript with a program of hash(x) and inputs of hash(y) and unspecified private inputs, is a valid transacript of tinyram execution which returns true."
02:07 < gmaxwell> )
02:08 < gmaxwell> which is how they're able to make validation time quasi linear in the length of the program... the time it takes to hash the program and its inputs is linear, and the rest is just proportional to the security level.
02:08 < gmaxwell> (well not just quasi linear, it's linear in the length of the program plus some security dependant constant)
02:10 < gmaxwell> I think the verifying keys for tinyram are on the order of tens (hundreds?) of kilobytes... but if everything is tinyram the verifying keys are just part of the system, all bitcoin would have to send is a hash of the script being run.
02:11 < maaku> so it doesn't really matter how complex then the extended-tinyram instruction set is, so long as the verifying keys are small enough to fit in a client (no more than a few megabytes, say)
02:15 < gmaxwell> well it doesn't matter for the verifier. It may matter greatly for the prover.
02:16 < maaku> ah, right
02:16 < gmaxwell> the performance figures in the scip paper were fast enough that it was feasable but not so fast that you could go sticking in a factor of 2 and not seriously degrade the usefulness of it.
02:17 < maaku> and the performance of the prover scales with the size of the validator key not the subsets of the circuit actualy used, right?
02:19 < gmaxwell> not sure,.. well actually some parts of the prover should scale well if parts of the circuit aren't used, but there are some parts (which I think all have log() scaling which wouldn't) ... but I don't know how it would work out pratically. These would be questions for Eli and team (Iddo may know). I haven't thought at all about extensions.
02:20 < gmaxwell> I think their main goal was to demonstrate feasability for general programs. So it made sense to be pretty ruthless in what they had in tinyram.
02:27 < maaku> yes, and as an engineer I'm wondering why "feasibility for general programs" dpesm
02:28 < maaku> doesn't equate to a general-purpose ISA used in a real general-purpose computer
02:28 < maaku> of which MIPS-I is about as simple as you can find
02:28 < maaku> plus a minimal set of crypto opcoce extensions, of course
02:29 < maaku> I'll look at the code first
02:29 < maaku> i really need to understand this better
02:41 < EasyAt> Hey guys, anyone know of a stragne attack.  I've been doing TXs and occasionally as soon as I send I receive about .0001 from a random address
02:41 < EasyAt> It's indeterministic
02:45 < wumpus> they sometimes send dust to addresses in the block chain, it's not an "attack" as such although if you spend the dust it can be correlated to other addresses, so it may help them discover a bit more information about how addresses are related
02:45 < wumpus> you could use this to remove the dust https://github.com/petertodd/dust-b-gone/
02:47 < EasyAt> Hm, so what does me receive dust do.  All they are doing is signing an output to a pubkey of mine.  What am I actually leaking?
02:47 < EasyAt> Oooh, because when I send I'll send their dusts and they can corrolate too addresses?
02:47 < wumpus> nothing, unless you spend it together with some other input
02:47 < EasyAt> s/twoo/many
02:47 < wumpus> yes
02:47 < maaku> yes, to whatever other addresses you use in the spend
02:47 < EasyAt> interesting.  Do you think it is specifically against me?
02:48 < wumpus> I don't think so
02:49 < EasyAt> Has there been any analysis on this... analysis or whatever you call this
02:50 < wumpus> but it's (among other reasons) why implementing schemes such as coinjoin is important
02:50 < EasyAt> Clever way to keep track.  I wonder if it's for transactions over a certain amount.  Maybe aligned with another currency's value
02:51 < EasyAt> wumpus: Agreed, an dI sign everything with an unconnected cold, unwritable boot drive
02:51 < EasyAt> But, It is a bit worriesom.  With the jdillon thing now I am quite paranoid
02:52 < EasyAt> I wonder if he had coins taken :\
03:03 < joecool> fucking dandan sends me dust all the time
03:04 < joecool> just because he's a little wanker
03:05 < EasyAt> dust doesn't do anything, though
03:05 < EasyAt> Except leak information, apparently
03:05 < joecool> or annoy the receiver
03:06 < EasyAt> The UTXO set is static at any given point in time, correct?  At the smallest inrement of time?  There is no question unless there is a current fork war(or whatever you call it)
03:11 < EasyAt> While no transaction is taking palce
03:13 < phantomcircuit> EasyAt, it's those idiot researchers trying to tag wallets with small payments
03:23 < michagogo|cloud> EasyAt: given a certain blockchain, yes, the UTXO set is deterministic
03:25 < midnightmagic> EasyAt: Spam from blockchain.info too. Check out the tx in b.i and see if there's a message there. If there is, it's just spamdust. dust-b-gone removes it. Or at least helps remove it.
03:25 < midnightmagic> And likely not douchebags trying to track.
03:36 < EasyAt> I'm not trying to be paranoid, but I was reading the other day that someone notcied ~70% of theire connections being filled by essentially junk nodes that didn't forward blocks or do anything.  And some of the main devs postulated that it might be a tracking or minging attack
03:36 < EasyAt> I'm curious if they could be correlated
03:38 < EasyAt> Erm, not mining blocks but an attack from some unknown mining pool
04:25 < maaku> EasyAt: these were connections from an academic institution in switzerland
04:25 < EasyAt> Kinda of intrusive. Bugs me. reminds me to send Txs through tor
04:25 < maaku> it's probably just a poorly configured tracking nodes
04:26 < maaku> well i got news for you: the majority of nodes are not useful
04:26 < maaku> and it's been that way for a while
04:27 < EasyAt> Why do you say that? Don' they at least verify and forward?
04:27 < EasyAt> Or you mean most nodes are light?
04:28 < maaku> no
04:28 < maaku> most nodes are light, dns seeders, tracking nodes, who-know-what
04:28 < maaku> i shouldn't say most nodes
04:28 < maaku> most connections is what i meant
04:29 < petertodd> maaku: depends a lot on where you're node is - my ec2 nodes got nearly 100% full-node connections. Supposedly this has something to do with clustering
04:29 < EasyAt> Heavy clients are heavy :)
04:29 < maaku> interesting, i don't run my nodes on ec2
04:29 < EasyAt> Has there been any write ups, even broad strokes about http://utxo.tumblr.com/?
04:30 < maaku> ?
04:30 < petertodd> maaku: I stopped recently because bandwidth usage was getting nuts
04:30 < maaku> i'm working on some new posts, and a few bips
04:30 < maaku> it's on the documenting stage
04:30 < maaku> was that your question?
04:31 < EasyAt> Mine?
04:31 < maaku> yes
04:32 < EasyAt> maaku: A few bips regarding the link I posed/
04:32 < EasyAt> Sorry. keyboard bleh
04:32 < maaku> yes
04:32 < EasyAt> fun
04:32 < maaku> regarding the index structure, and various applications of it
04:32 < EasyAt> I look forward to reading.  Is that you?
04:33 < maaku> yes
04:33 < EasyAt> omg
04:33 < EasyAt> nice
04:33 < EasyAt> \o/
04:33 < EasyAt> I'm quite excited to hear more of your ideas
04:33 < petertodd> maaku: are you still going into the UTXO set direction?
04:34 < maaku> yes. the authenticated prefix tree is more broadly useful though so I want to take a generic approach now
04:34 < EasyAt> While speaking with my firend the same approach accored to me
04:34 < petertodd> maaku: huh, generic how so?
04:34 < EasyAt> I really like it
04:36 < EasyAt> maaku: Are things progressing nicely/
04:36 < EasyAt> bad keyboard :\
04:36 < maaku> merged mining, document timestamping, namecoin-like record updates,
04:37 < maaku> things like that which we have been discussing here on wizards
04:37 < EasyAt> I love the doc timestamping
04:37 < maaku> also i want to explain MMR for a lay audience, and the tradeoffs vs. commited tree hashes
04:37 < EasyAt> Sorry, I am normally away from #wizards.  I don't mean to be redundant
04:38 < petertodd> maaku: ah, yeah, merge mining a UTXO commitment seems reasonable to me - can always be ditched later.
04:39 < petertodd> maaku: it might even be ok to reject blocks that have an invalid merge-mined UTXO commitment, but not reject ones with no such commitment at all
04:39 < EasyAt> indeed, it isn't bad. It's and it's easy
04:39 < maaku> petertodd: there's an application of the index structure to enabling zerocoin double-spend protection without requiring validating nodes to keep the double-spend db in memory
04:39 < EasyAt> petertodd: that's a very good idea
04:39 < petertodd> maaku: it creates a less than 51% attack of course, but with sufficient hashing power that may be deemed ok
04:39 < EasyAt> Or that should be in the software to check whether the commitment is valid
04:40 < maaku> also proof-of-stake voting.. lots of applications showing up
04:40 < EasyAt> if not ignore and trust nothing until a block with a valid utxo stamp and highest in chain
04:40 < maaku> yeah, the hash commitments will probably be merged mined first
04:40 < petertodd> maaku: yeah, I was thinking about that... I think what you've done is shifted the burden of updating that tree from the miners to those using it - it doesn't scale any better, but at least the people affected by the bad scaling aren't miners
04:41 < petertodd> maaku: (shifted in the sense that because it's a random access tree it doesn't scale)
04:41 < maaku> well i think it does scale better - you just have to keep up with your own proofs, not everyone's proofs
04:41 < maaku> same reason MMR scales better
04:42 < maaku> still limited by the processing speed of the minimum-requirements validator node, but there's plenty of room to grow there
04:42 < EasyAt> Sorry, can you tell me what MMR is or keywords to google for
04:42 < EasyAt> because MMR bitcoin yeields nothing useful :)
04:42 < maaku> not really, that's the problem
04:42 < petertodd> MMR = merkle mountain range == https://github.com/opentimestamps/opentimestamps-server/blob/master/doc/merkle-mountain-range.md
04:42 < maaku> i need to write up a better description
04:42 < petertodd> maaku: heh, me too
04:43 < EasyAt> petertodd: thank your
04:43 < maaku> ^^^ is peter's document, but probably opaque unless you have a strong bitcoin-dev background
04:43 < petertodd> maaku: hey! I have pretty pictures in that one at least! :P
04:43 < maaku> :)
04:43 < petertodd> maaku: my ex understood it... so she claimed...
04:43 < EasyAt> maaku: I like to think I have a moderate knowledge
04:44 < EasyAt> I have written code to push through the chain and check all values.  But haven't contributed yet.  Still leveling up
04:44 < petertodd> maaku: so, I think the thing with tree stuff for zerocoin and similar will be that you can't get away from storing the whole tree. OTOH I agree that bandwidth could potentially be split up into shards with some careful work.
04:44 < EasyAt> But you guys are contirbuting so fast there is a lot to study
04:44 < maaku> petertodd: it's a fine document. you just didn't go over motivation & such which you need to explain it to a wider audience
04:45 < petertodd> maaku: yup, that's completely correct - and the motivation when I wrote it was timestamping too
04:45 < maaku> petertodd: in the zerocoin application, the entire tree is recoverable from the spend history in the block chain, but nodes don't have to keep it resident in the UTXO set
04:46 < maaku> since a spend provides the path to the place to insert the newly spent token
04:46 < petertodd> maaku: right, but to construct that spend you need access to the whole set, although that access can be distributed across multiple nodes
04:46 < petertodd> maaku: so it's in between the scalability basically
04:47 < maaku> yes, or offloaded to librarian nodes with an explicit fee, etc.
04:47 < petertodd> yup, all better options than the alternatives
04:47 < maaku> actually not the whole set, no
04:48 < maaku> you just at one time need to get your path through it, and then you just maintain that path
04:48 < maaku> so er, yes the whole set, but not at all times
04:48 < petertodd> right, but I mean, out there *somewhere* needs to be a copy of all that data. Sure it can be split up and you don't have to have it all on hand at once, but it can't ever be deleted. (unless coins have expiration times)
04:48 < maaku> once you get your path which you can have at any time, you just update that as spends are seen
04:48 < maaku> but unlike MMR, it requires an update on every spend :\
04:48 < EasyAt> Do you think fees will eventually not be distributed amongst just miners, but that perhaps miners will not nexessarily keep full chains and that a portion of funds will go to nodes that only maintain and issue work
04:49 < EasyAt> Or am I just describing a mining pool
04:49 < petertodd> yup, MMR is unique that way... if only just barely powerful enough to be useful at all
04:50 < petertodd> EasyAt: miners don't have to keep full chains - heck, they don't even have to validate...
04:50 < EasyAt> indeed
04:50 < petertodd> EasyAt: they should, but nothing forces them to do that
04:50 < EasyAt> just take work and chomp
04:51 < maaku> EasyAt: the MMR proposal or a proof-updatable prefix tree could be used to require transactions to provide proofs of their own validity
04:51 < EasyAt> Has there been a proposal for a blochain solution to voting.  As in in real life politics?
04:51 < maaku> then nodes don't have to store UTXO data at all
04:51 < EasyAt> intersting
04:52 < maaku> EasyAt: not a complete one, but that's a project i'm working
04:52 < maaku> it has special application to freicoin
04:52 < EasyAt> fun
04:52 < EasyAt> I have not looked at feicoin
04:52 < EasyAt> bitcoin is still too immersive
04:52 < petertodd> EasyAt: https://bitcointalk.org/index.php?topic=230864.15
04:53 < EasyAt> jdillon! so cloak and dagger
04:55 < petertodd> EasyAt: yeah, and good ideas too
04:55 < EasyAt> hm
04:55 < maaku> once again, i've found a way to apply the index structure to recording proof-of-stake votes without requiring validating nodes to track that data
04:55 < petertodd> EasyAt: note what he's proposing very carefully avoids the usual trap of having miners vote on anything
04:55 < petertodd> EasyAt: er, I mean, having miners able to control the vote
04:55 < maaku> but the bigger problem is the usual stuff for voting - miners have significant control over the election process by being able to block votes
04:56 < EasyAt> I like it a  lot
04:56 < EasyAt> maaku: correct
04:56 < EasyAt> Until every single node is homogeneous there will always be power dispairties
04:56 < petertodd> maaku: yeah, jdillon's blocksize limit vote might be the *only* case where miners can't control a vote, and that's because in one sense they alredy can control half of the possible outcome
04:56 < maaku> you can mitigate that somewhat by encrypting votes, somewhat like committed transactions
04:57 < maaku> but then they can always block the revelation
04:57 < maaku> petertodd: yeah
04:57 < maaku> freicoin has a substantial perpetual mining subsidy (4.9% of the monetary base per year), so we're looking at ways to do proof-of-stake voting on distribution
04:58 < maaku> but miners would be naturally hostile - their best outcome is to gerrymander a 100% to the miners budget, then block all votes thereafter
04:58 < maaku> overcoming that is tricky... and I don't have funding to look at it now
04:58 < petertodd> maaku: makes sense - in that case the "anti-miner-option" could be that without the proof-of-stake the mining subsidy goes into thin air
04:58 < maaku> but if you can think of a solution let me know :)
04:59 < maaku> yeah a sort of nuclear option
04:59 < petertodd> it's MAD, but it just might work
04:59 < EasyAt> How much of a consideration does altruism take?
04:59 < EasyAt> 0?
05:00 < warren> maaku: btw, your coin is currently sha256 PoW?
05:00 < EasyAt> I suppose in sec. it should be 0. right?
05:00 < maaku> warren: yes
05:00 < warren> how do you avoid reorg attacks?
05:01 < EasyAt> How does ones reorg attack unless constantly producting 2 blocks at very similar times?
05:01 < maaku> the same way bitcoin does? not sure I understand the question
05:01  * EasyAt looks up reorg attack
05:02 < maaku> by reorg attack you mean 51% / 100% attack?
05:02 < petertodd> maaku: oh! actually, this is perfect: voting on the inflation rate naturally has an opposed set of incentives - set a minimum rate, and let people proof-of-stake vote increases in it.
05:02 < petertodd> maaku: or really s/inflation/demurrange/ to make it PR acceptable
05:02 < EasyAt> maaku: I'm curious what warren means by reorg attack
05:03 < petertodd> maaku: which is perfect because demurrange is the only sane way to fund mining long-term (+ tx fees, but never only tx fees)
05:03 < warren> maaku: lots of the little pure PoW coins seem to come under reorg attacks often
05:03 < warren> but I never hear of it happening to freicoin
05:04 < petertodd> maaku: I suspect with rates like 0.1% to 3-5% the loss per year is low enough that users may be willing to vote it up, which is fine, and gives some agility to attacks that might do soem good.
05:05 < EasyAt> petertodd: Is it still demurrange implies the value is being redstributed to miners whether the currency is tranferring or now.
05:05 < maaku> petertodd: we haven't found a way to auto-regulate demurrge rates, or voting scheme which doesn't assume the electorate is alturistic macroeconomics professionals
05:05 < EasyAt> As in you have a tax just for holding and not moving currency
05:06 < EasyAt> inflation essentially
05:06 < maaku> hence the fixed 4.9% ... a fluctuating rate would actually be ideal, but I don't know how to do that securely and safely
05:06 < maaku> EasyAt: no, it's a fee on all money, fullstop. moving or hoarding doesn't make a difference.
05:06 < EasyAt> intersting
05:06 < EasyAt> So no penalty whether you move or hold
05:07 < maaku> well, the same penalty i guess
05:07 < maaku> warren: we've not really been subject to such attacks
05:07  * maaku knocks on wood
05:07 < maaku> but really it makes no difference what pow algorithm you use
05:07 < warren> I know
05:07 < maaku> i assume you're talking about 51% attacks
05:07 < warren> yes
05:07 < petertodd> maaku: right, but my point being, the worst outcome is the rate drops down to some low minimum value hopefuily high enough to keep attackers at bay indefinitely. The best outcome is that if it looks like miners do need more incentive, human alturism can do some good. Will that happen? Who knows, but the downside is just technical risk.
05:07 < EasyAt> Is a reorg attack a 51% attack? or something very similar
05:08 < maaku> warren: long term, we're moving to merged mining
05:08 < EasyAt> maybe less hash stake then 51% but getting lucky and reoring in your favor?
05:08 < warren> EasyAt: You don't need 51% to do a "51%" attack.
05:08 < EasyAt> warren: that's what i mean
05:09 < EasyAt> maybe less hash stake then 51% but getting lucky and reoring in your favor?
05:09 < EasyAt> is what i said
05:09 < maaku> petertodd: if the goal is just to provide limited income to miners, that's a good strategy. i could see it reaching steady-state at the security & profit  break-even point (but maybe there are some game dynamics at play too)
05:09 < maaku> but with freicoin, the desire is 0% basic interest, which I don't believe such a scheme would achieve
05:11 < maaku> warren: we have done the easy stuff (fix time traveller bug, no asymmetrical diff adjustment, etc.), but also we have a much faster acting (but stable!) FIR-filter difficulty adjustment algorithm
05:11 < maaku> so that also helps
05:13 < petertodd> maaku: thing is you don't care about profit, you just care that a given % of the total value of the coin goes to paying for hashing power guaranteed.
05:13 < petertodd> maaku: I'm not seeing how that turns into game dynamics assuming reasonable decentralization
05:16 < maaku> petertodd: so in freicoin there are two knobs to tweak: (1) the demurrage rate, and (2) how much of that goes to the miners (vs other distribution mechanisms, such as the above-mentioned 'republicoin' proof-of-stake voting)
05:17 < petertodd> maaku: right, where I'm proposing a system with just knob #1
05:17 < maaku> i can see how a secure voting mechanism could lead to the latter (although I don't have such a protocol, yet), but not the former
05:17 < maaku> yeah i figured you don't care about the other aspect, but that's the context in which I'm working on this
05:17 < petertodd> no, I think it's the other way around, because the former have opposite incentives than the latter, guaranteed. (assuming no external attack threat)
05:18 < petertodd> after all, miners can always refuse to mine a transaction due to too-low fees - refusing to mine because of too-low % vote is not much different
05:18 < petertodd> and if anything, that's much less likely to be gamed in many senses
05:18 < maaku> i think that's what I meant - it's late here, i must have switched them in my mind
05:18 < petertodd> ah good
05:19 < petertodd> speaking of, I proof-of-stake vote all the demurrange to myself
05:20 < maaku> i expect you could construct a voting scheme for regulating the rate of income given to miners, I don't think a voting scheme would work to set demurrage rate at what is necessary to achieve 0% basic interest
05:20 < petertodd> "0% basic interest"?
05:21 < maaku> petertodd: do you have majority stakeholder vote?
05:21 < petertodd> maaku: not yet, but the moment I do it's a tipping point...
05:21 < maaku> we're anticipating that if we structure the elections properly, we will have competing factions that form governments, and the real-world outcome is that you won't get 51% votes to "pay ourselves"
05:22 < maaku> i'd like to formalize that argument before we deploy though
05:22 < petertodd> yeah, probably true enough
05:22 < maaku> hence the name "republicoin"
05:22 < petertodd> I'd sure as hell formalize it - just look at all the screwy things with incentives that have been found lately
05:22 < maaku> yeah
05:23 < maaku> basic interest == liquidity preemium, when we're talking about currency
05:23 < petertodd> rght
05:23 < petertodd> *right
05:27 < maaku> Gesell wrote several monographs showing how the parasitic behavior of the financial industry and government, and the ruinous effect that has on society is due to the liquidity preemium
05:27 < maaku> https://www.community-exchange.org/docs/Gesell/en/neo/
05:28 < maaku> so the experiment of freicoin is: set the liquidity preemium = 0%, and see if that helps create positive economic incentives, as predicted
05:29 < petertodd> ...and the experiment you actually have wound up running, is will cryptocoin people ever adopt anything with demurrange?
05:30 < maaku> haha, suprisingly the answer is a mild yes
05:30 < maaku> but no, we've been targetting groups outside of bitcoind
05:30 < petertodd> indeed, and I wasn't saying that in a negative way! I'm quite happy to see *that* experiment happen even if I don't give a damn about economic theory :)
05:31 < maaku> while most freicoin users may have heard of, downloaded, and maybe used bitcoin, most of them did not become active until they got involved with freicoin
05:31 < maaku> and we've mainly been reaching out to monetary reform groups, which suprisingly haven't heard of or done anything with bitcoin either
05:31 < petertodd> there were some occupy types adopting it or something similar IIRC?
05:32 < petertodd> and agreeing to use a decentralized demurrange cryptocurrency is wonderfully democratic
05:32 < maaku> we framed the original crowdfund campaign in the language of occupy, but suprisingly there was very little interest
05:32 < maaku> we've seen interest peak the most in the regional/community currency movement
05:32 < petertodd> huh, too abstract maybe
05:33 < maaku> possibly, or maybe even too concrete. the problem with occupy is that they all have agreement on the problems, but 100 protestors have 101 different solutions in mind
05:33 < maaku> this wasn't the solution any of the occupy people we talked to had in mind ;)
05:34 < petertodd> did they add it to their mental solutions list? because if so you added to the problem :P
05:35 < petertodd> you know, one of the annoying things about crypto-currencies is how the basic dynamics of proof-of-foo make experimentation hard - normally a small currency experiment might be worthless, but it is secure
05:36 < maaku> you'd think it'd be a perfect match though - occupy prime problem is the banks that contol directly or indirectly so much of our society. gesell's basic thesis is that ilquidity preemium is the root cause of that. problem identified, solution provided...
05:36 < petertodd> "wtf is liquidity preemium? sounds like something a banker would talk about"
05:36 < maaku> heh
05:37 < petertodd> I'm glad that you're self-aware enough to laugh at that!
05:40 < maaku> Well I (and Gesell) are not anti-banker - gasp! Gesell is totally a free-market capitalist, and so am I.
05:40 < maaku> What Gesell is against is the unfair advantage banks have, and how they naturally use that advantage to ill gain
05:41 < maaku> He then goes to considerable length in showing how that advantage is exactly equal to "basic interest" - that interest which remains after you subtract out the risk preemiums, time preference, etc.
05:41 < petertodd> yeah, of course, monetary issues aside, understanding credit risk is something where scales leads to bigger profits
05:41 < maaku> So neutralize that, and you've got a level playing field - banks want to loan to you just as much as you need them
05:42 < petertodd> rick preemiums aren't easy to measure after all
05:42 < petertodd> *risk
05:42 < maaku> yeah they're not
05:43 < maaku> but people who have money should be entitled to the reward of taking that risk
05:43 < maaku> they just shouldn't be entitled to that reward... + 5% for absolutely no  reason
05:44 < petertodd> right, otoh if the cost of figuring out that premium works out to be 5%, well, what's the diference exactly?
05:44 < petertodd> real world-will be somewhere in between, but it might not make such a big difference is my point
05:46 < maaku> well the historical analysis, repeated many times is that once you subtract out the risk, the costs, and any other identifiable factor, there's 4-6% left over
05:47 < maaku> it fluctuates a little bit based on global and local economic conditions, but has remained remarkably steady since they started tracking this
05:47 < petertodd> how was the cost of determining credit risk factored out? and for that matter, the way credit risk can often be amortized and so on
05:48 < maaku> unsatisfyingly, i'm going to have to go to bed soon (almost 3am here)
05:48 < maaku> but i believe in these studies they just use the banks own numbers
05:48 < maaku> credit risk is what the bank thought it was
05:48 < petertodd> right, but even the banks might be fooling themselves
05:49 < petertodd> heck, with the last crash, I'll say that's guaranteed in some sense
05:49 < maaku> right, but every banker in the world fooling themselves the same amount?
05:49 < petertodd> they're all human... I hope
05:49 < petertodd> or heck, it's all the same amount because of good competition :P
05:50 < maaku> well that is quite the point
05:50 < maaku> the banks compete and they end up at the same amount
05:50 < maaku> that is, charging extra by the same amount, the most they can get away with
05:51 < petertodd> yup, and they all think they're making out like bandits, and like most people they're discounting all kinds of risks, like black swan events, which leaves them at break-even
05:51 < maaku> competition doesn't drive it to zero, as you might think, because the bank would rather have money under the matress than a loan with expected 0% return
05:51 < petertodd> well... it drives it to zero in *some* sense
05:51 < maaku> opportunity cost and all that
05:52 < petertodd> hence why rather than "zero" you could wind up at that 5% and wonder why it's not zero - when a broader picture is that rate is 0%
05:53 < petertodd> an interesting analysis comes from civil aviation, where a lot of people have come to the conclusion that in the entire history of it, the industry has lost money
05:54 < petertodd> but equally, aviation is full of dreamers...
14:21 < jtimon> maaku petertodd I thought the demurrage rate would be fixed and PoS only votes on the % to the miners % to something else
14:22 < jtimon> "in the zerocoin application, the entire tree is recoverable from the spend history in the block chain, but nodes don't have to keep it resident in the UTXO set"
14:22 < jtimon> how do you do that?
14:46 < gmaxwell> what are you quoting?
14:46 < gmaxwell> In any case, look at the little MMR writeup I did:
14:47 < gmaxwell> https://bitcointalk.org/index.php?topic=314467.msg3371194#msg3371194
15:34 < maaku> he's quoting me
15:35 < maaku> updating the chaum double-spend database using proofs provided with the transaction
15:35 < maaku> like we talked about a week or so ago
15:36 < maaku> jtimon: this is just to keep a list of which chaum tokens have already been spent
15:36 < maaku> you put them in an ordered tree structure, and to perform a spend you have to provide an insertion-proof showing that the token is not already in the db
15:37 < maaku> the validating nodes only have to keep the root hash around
15:37 < maaku> since each spend references the previous hash, and they update the hash afterwards
15:37 < maaku> update the root hash
15:38 < maaku> you still have to use some sort of ZKP or centralized signing to create the chaum tokens and validate that the token provided is from the original issuance set
16:07 < maaku> i wonder if there is a subset of the SHA-3 and AES contendors which are particularly amenable to small circuits in ZK proofs
16:17 < gmaxwell> 22:36 < gmaxwell> It would be interesting to evaluate all the well studied cryptographic hashes and see which would result in the most efficient quadratic span program proofs.
16:18 < gmaxwell> but I suspect sha2 is not so bad. likewise with aes.
16:22 < maaku> yeah i was thinking rijndael is probably better than all the others
16:23 < maaku> but keccak is probably worse than sha2
16:41 < jtimon> maaku in the context of freimarkets, would there be a "chaumian tree" per asset?
16:44 < maaku> well there'd be a tree per mint series
16:44 < maaku> and a mint series would be presumably limited to a single asset
16:45 < jtimon> I see
16:46 < jtimon> did you read pertertodd's proposal for indexing the inputs set instead of the output set?
16:46 < jtimon> I'm not sure I undesrtand it but it looks very interesting
18:30 < jtimon> petertodd I'm re-reading this http://sourceforge.net/mailarchive/forum.php?thread_name=20131119110023.GA24068%40savin&forum_name=bitcoin-development
18:30 < jtimon> I have several questions
18:31 < jtimon> the first is how are tx fees paid?
18:31 < jtimon> maybe you have PoW per transaction to prevent spam DoS?
18:39 < jgarzik> jtimon, TX fees are paid by providing input bitcoins > output bitcoins
18:39 < jgarzik> jtimon, the difference is the fee
18:39 < jgarzik> jtimon, e.g. 2 BTC inputs, 1 BTC outputs == 1 BTC fee
18:40 < jtimon> that's how bitcoin works, but I'm not so sure that is how petertodd's proposal works
18:40 < jtimon> miners see no outputs if I understand correctly
18:47 < jgarzik> ah, apologies
18:47 < jtimon> jgarzik no problem
19:24 < maaku> petertodd: what are the advantages of keeping a spent-txin set instead of an unspent-txo set?
--- Log closed Sat Nov 30 00:00:20 2013