--- Log opened Thu Jan 23 00:00:53 2014
04:27 < _ingsoc> So, get a hold of this Ethereum!
04:27 < _ingsoc> Thoughts?
07:32 < gmaxwell> adam3us: schnorr multisignature seems to be naturally sidechannel busting.
07:32 < gmaxwell> adam3us: e.g. you do 2-of-2 with the hardware wallet signing first... and the final R,S could be anything.
07:33 < gmaxwell> and avoids the other complexities with the device knowing what its signing when the signature is blind.
07:33 < adam3us> gmaxwell: yes.  i mentioned two variants of the wallet observer thing on https://bitcointalk.org/index.php?topic=428494.new#new
07:34 < adam3us> gmaxwell: the basic one that brands talks about uses blind sig so the wallet has no subliminal channel
07:34 < adam3us> gmaxwell: but using brands ZKP issuing protocol, you can also prove to the wallet what it is blind signing, so it can show it on screen for approval with a hw wallet with screen like trezor, and STILL not have a subliminal channel
07:35 < adam3us> gmaxwell: i'm sure brands covered that somewhere in his thesis, the guy is exhaustively inventive.
07:36 < adam3us> gmaxwell: but yeah the subliminal channel freedom is  beautiful thing to have as a building block
07:37 < gmaxwell> adam3us: Right but I believe that a regular 2 of 2 threshold signature has the same sidechannel elimination effect without requring the ZKP proof of what its signing.
07:38 < adam3us> gmaxwell: ah gotcha.  yes that appears to be true also :) and nice and simple
07:52 < adam3us> gmaxwell: btw other than adding cc other authors, about the private key issue, another step could be to make an ID / RFC on EdDSA as a complement to the safe curve focused ID that Watson Ladd on IRTF CFRG is doing.  i thnk the lowest 3 bits=0 is just a optimization, I dont immediately see why that cant be removed and multiply by 8 somewhere in the verification relation, and the bit 254 I think is just defensiveness
07:53 < adam3us> gmaxwell: ie bit 254 is not necessary for security, just that the montgomery ladder start at bit 254 whether its 0 or 1 to avoid a timing side-channel.  thats all if anyone had time/energy for an RFC process but it would be a natural way to extract feedback from the algorithm authors
12:25 < jtimon> maaku,what if we start with the private chains? http://freicoin.freeforums.org/freimarkets-t717.html#p6913
12:25 < jtimon> not sure if wrong forum or not...I'll say the same on #freicoin just in case
14:12 < petertodd> lol twister: https://groups.google.com/d/msg/twister-dev/h2ukT1msggc/Jbh-UPYPGiIJ
14:12 < petertodd> "May someone suggest a good free captcha generator for text that is OCR
14:12 < petertodd> resistant?"
14:12 < petertodd> apparently they have a namesquatting problem...
14:13 < petertodd> they also have implemented ripple-style soft-consensus to prevent rewrite attacks
14:13 < gmaxwell> uh.. how does that work with anonymous participation?
14:14 < petertodd> good question!
14:14 < petertodd> that's the lead dev suggesting that!
14:15 < petertodd> they don't even use namecoin-style two-stage commit-reveal, so an attacker can watch the network for new name registrations and register all new names for themselves
14:15 < gmaxwell> lol
14:16 < Luke-Jr> facepalm
14:16 < petertodd> I almost want to fire up some ec2 instances and 51% the network with empty blocks just to see how they'll react - it's a social experiment at this point
14:17 < Luke-Jr> I think I like how with namecoin, if two people register the same name concurrently, both lose their coins ;)
14:17 < gmaxwell> I take it this isn't merged mined?
14:17 < petertodd> gmaxwell: nope
14:17 < gmaxwell> sha256 pow?
14:17 < petertodd> gmaxwell: and they changed the block header so standard scryptminers don't work, but with some effort you can still modify litecoin scrypt miners to mine it
14:18 < gmaxwell> ah. scrypt.
14:18 < petertodd> gmaxwell: they added CBlockHeader.nHeight
14:18 < gmaxwell> and just made the header a bit longer or?
14:18 < petertodd> but they left nVersion=2 and the supermajority code in for nVersion=2!
14:18 < petertodd> gmaxwell: yup
14:18 < gmaxwell> that probably actually won't break the gridseed asics, the work generator is apparently microcoded.
14:18 < petertodd> gmaxwell: I haven't looked into how hard it'd be to adapt a scrypt miner to that
14:19 < petertodd> gmaxwell: oh nice!
14:19 < gmaxwell> (they have an on chip work generator and increment logic which is apparently all microcoded)
14:20 < petertodd> gmaxwell: amir was trying to convince them to just use namecoin
14:21 < gmaxwell> namecoin codebase is nearly unmaintained. :(
14:21 < petertodd> twister codebase is worse than unmaintained
14:23 < gmaxwell> hopefully once scrypt mining asics exist in large enough quantities to have driven everyone off gpu mining people will go back to making merged mined things.
14:23 < petertodd> meh, merge-mining is no perfect solution either - just makes it easy to be attacked early on
14:24 < gmaxwell> petertodd: changes who can attack, for something which isn't compeating with bitcoin it's probably fine.
14:24 < petertodd> gmaxwell: you can be in trouble by competing with another merge-mined system you realize...
14:25 < gmaxwell> perhaps, but it's not clearcut. if 60% of your hashrate is really bitcoin miners who totally don't give a shit about any of these things attacking becomes hard.
14:25 < gavinandresen> gmaxwell: I think scrypt mining asics will just drive people to a wakier-proof-of-work-coin (Quark maybe).
14:26 < petertodd> gmaxwell: easy to start offering people >100% paying shares to quickly buy hashing power for an attack
14:26 < gmaxwell> gavinandresen: Thats a point!   "DDD coin's Proof Of Work involves ringing peoples doorbells and running."
14:27 < gavinandresen> gmaxwell: lol
14:33 < petertodd> gmaxwell: anyway, I think I've got my "tree-chains" concept in decent shape: blockchian is a sharded tree, each node in the tree has left and right leaves that are half the difficulty of the parent node/chain. have participants have consensus about the contents of the blocks in the parent chain, and the blockheaders for left and right. the rule for left and right child chains is that full-diff PoW solution "locks" the order of the chain, so ...
14:33 < petertodd> ... re-ordering takes 51% with respect to the parent work. However contents are subject to 25% majority. You solve the "lost-data" problem by allowing the mining of a challenge - a tx that you want to see mined - and that tx must either be proved to be not minable (e.g. succinct MMR TXO) or prove that the tx was mined. If nothing happens, eventually the child chain can be re-orged.
14:34 < petertodd> Security guarantees are resistant to 50% attack for re-ordering transactions, 25% for censorship - however you can pay higher fees/work to force a tx to get mined. Done recursively you *will* get to the point where the PoW effort is too low to be secure, but at least that's an adjustable parameter.
14:34 < petertodd> It looks like merge-mining in a sense, but the challenge rule improves the security guarantees.
14:35 < petertodd> Dunno yet how you'd spend coins from one multi-level deep child chain to a different one - easy to think of cases where you allow inflation attacks.
14:37 < petertodd> gmaxwell: Note how all this is easiest to think about with per-tx work - IE one block == one tx. Also easiest to think about it in practice as a token transafer system - how you'd use it with unrestricted values is an interesting question given the inflation issue.
17:17 < arbart> what is the state of the art of enabling microtransactions?
17:22 < sipa> bitcoin (at the protocol level) isn't designed for microtransactions
17:27 < phantomcircuit> arbart, trust a third party
17:27 < phantomcircuit> remember that the transactions are micro
17:30 < sipa> #bitcoin-dev please, btw
17:31 < arbart> sipa, cool, that is what i was wondering then i guess
17:31 < arbart> and alright, what is the purpose of this channel then, I thought it was similar?
17:33 < Luke-Jr> this channel is more like extreme advanced stuff that isn't really practical :p
17:33 < arbart> well that is what I like :)
17:33 < sipa> arbart: oh, i misread your line
17:34 < sipa> i thought you said "what is the state of enabling microtransactions", which would apply to bitcoin-as-it-exists today
17:34 < sipa> for state-of-the-art, there are some more interesting ideas
17:34 < sipa> like probabilistic transactions
17:34 < arbart> yes, now you are talking :) why i came here
17:36 < gmaxwell> probablistic transactions are more of a social/political challenge than a technical one. (I think the lottery protocols iddo/adam3us worked on can basically be applied directly to create a probablistic payment)
17:37 < arbart> ah interesting, i didn't find this before, now searching 'probabilistic transactions', i find much stuff! sipa, thank you already!
17:37 < sipa> arbart: gmaxwell certainly has more state about it than i do
17:39 < arbart> gmaxwell: what is the social/political challenge you see with it?
17:39 < Luke-Jr> …
17:39 < Luke-Jr> arbart: 'probabilistic transactions' essentially means 9 times out of 10, you get nothing, and the 1 other time you get a penny
17:40 < gmaxwell> arbart: Many people seem to not regard a probablistic payment as a payment.
17:41 < arbart> ok, i'm starting to see. reading https://bitcointalk.org/index.php?topic=62558 right now.
17:43 < sipa> gmaxwell: many seem to not regard playing lotto as paying tax either
17:46 < gmaxwell> sipa: People are implementing batch DSA verification in this thread: https://bitcointalk.org/index.php?topic=427025.0
17:46 < arbart> it is interesting so far :)
17:46 < arbart> i understand it now
17:47 < sipa> gmaxwell: how do they overcome not knowing R.y?
17:47 < arbart> i think i am in -wizards and not -dev is because stuff like that gmaxwell is good to have, but not enough a solution, something more extreme :) is needed
17:48 < gmaxwell> sipa: brute force.
17:49 < arbart> i suppose it is hard to tell though, that looks interesting, and combined with pruning and all, might be enable native nanotransactions
17:50 < petertodd> arbart: pruning doesn't make the bandwidth problem go away unfortunately
17:50 < gmaxwell> sipa: basically you guess the sign and test and apparently this still comes out ahead.
17:50 < gmaxwell> arbart: native nanotransactions
17:50 < gmaxwell> doesn't really sound sensible in a global consensus system.
17:50 < arbart> :)
17:50 < gmaxwell> Now, you can do things to perform them non-globally and that perhaps becomes more interesting.
17:50 < arbart> hmm :)
17:50 < petertodd> arbart: now, an interesting question is if you really need global consensus? I think there are blockchain structures that don't
17:51 < arbart> ahh, right
17:51 < gmaxwell> So there are a couple paths to relaxing that which have different tradeoffs.
17:51 < petertodd> arbart: right now just trusting a third-party is probably far more practical
17:51 < arbart> maybe global checkpointing, but only local is interested in the details usually, etc?
17:52 < petertodd> arbart: trusting third-parties and non-global-consensus blockchains have interesting convergence re: security I suspect
17:52 < gmaxwell> are you just stringing words togeather? :P
17:52 < arbart> i understand the third-party thing, another avenue im interested in
17:52 < petertodd> arbart: global *ordering* is a better term
17:52 < petertodd> arbart: heh, lets see if I can explain my pet idea to you re: tree-chains... so imagine you have a blockchain, and you merge mined two child chains with it, left and right.
17:52 < arbart> only out of the necessity you think is there
17:52 < petertodd> arbart: you know what merge-mine means?
17:53 < arbart> ok, i get that term
17:53 < arbart> petertodd: not yet
17:54 < petertodd> mining: I find a pow solution so that my block will be part of the consensus
17:54 < petertodd> merge-mining: the rules of the system let me re-use a pow solution from a different consensus system, letting me do one bit of work, yet get two blocks from two different systems
17:54 < arbart> ok, intuitive :)
17:55 < petertodd> merge-mining is implemented by just letting you prove the block solution for sytem #2 by showing a merkle path through some tree that terminates in the blockheader for system #1
17:55 < petertodd> (namecoin does this)
17:56 < arbart> ok, i was guessing that, so i think i got it :)
17:56 < petertodd> right, so we have the parent chain, and two child chians, left and right, got that? you can mine the parent chain, or the parent chain and the left chain, or parent and right chain (in our system)
17:57 < arbart> petertodd: was just about to prod you :)
17:57 < petertodd> basically it's *exclusive*, you can only mine the left *or* right child chain (or neither)
17:57 < arbart> oh ok, noted
17:58 < petertodd> this means the work done on these child chians will tend to be half that of the parent (assuming the reward is halved for instance)
17:58 < petertodd> however, this also means that a given miner only needs the data, and thus bandwidth, cost of the parent and one child. so the total # of transactions in both children can be higher and the system still works
17:59 < petertodd> the downside is that transactions in either child chain have less security, it only requires 25% of the hashing power to reorg that chain as the parent chain
17:59 < petertodd> got that?
17:59 < arbart> oh wow, yes, a load balancing mechanism :) thinking about the security aspect though
18:00 < petertodd> yeah, so we've figured out how to make it more scalable, now, what about the security? well, lets make a new rule! if a pow solution for a child chain *also* meets the difficulty of the parent, we say that block is fixed - it's only allowed to be reorganized if the parent chain itself gets reoganized
18:01 < petertodd> now it takes 50% of total hashing power to attack the child chain right? nope
18:01 < petertodd> can you guess why?
18:01 < arbart> i guess im missing the reorganized part
18:02 < petertodd> reorg just means work is done to extend a block other than the current best block, so when your node learns about the longer chain, suddenly the shorter one is made invalid by definition
18:02 < arbart> well at least because only half the network is working on each side of the chain?
18:02 < petertodd> remember, the problem bitcoin is trying to solve is consensus on what's the longest chain
18:02 < arbart> ah nice okay, was just missing that definition
18:02 < petertodd> arbart: sure, but an attacker can still get some hashing power somehow and reorg one of those child chians, and they only need 25% of the total hashing power to do that
18:02 < arbart> or word i mean
18:03 < petertodd> good
18:03 < arbart> ah right, half of half, got it now.
18:03 < petertodd> yup
18:04 < Luke-Jr> petertodd: you coming to Miami?
18:04 < petertodd> so here's the question: with this fancy "parent chain locks things" scheme, why can the child chain be still attacked with just 25% hashing power?
18:04 < petertodd> Luke-Jr: isn't that, like, right now?
18:04 < Luke-Jr> petertodd: tomorrow :p
18:04 < petertodd> Luke-Jr: heh, nah, tomorrow's my last day of work, couldn't make it
18:05 < petertodd> Luke-Jr: how long does it go? I guess I could strictly speaking... :P
18:05 < Luke-Jr> Saturday and Sunday is the main conference! :p
18:05 < petertodd> Luke-Jr: heh, nah, too tight
18:05 < arbart> hmm, that is a sucky result, a good question to analyze, in order to make sure it is right :)
18:05 < Luke-Jr> Friday is just the pre-conference thing
18:05 < petertodd> arbart: Well, lets think this through: what does attack mean anyway?
18:06 < petertodd> arbart: So, I could attack the chain by making only empty blocks and make it useless, I could also attack it by reorganizing it and double-spending transactions... but there's one other thing I can do.
18:06 < arbart> well the value of what they are attacking is also half i suppose. that counts for enough to throw the game theory?
18:06 < Luke-Jr> petertodd: the first case is debatable
18:06 < petertodd> arbart: maybe! but what if they're just assholes and want to burn the world?
18:07 < petertodd> arbart: we might as well know how much said assholes need to spend
18:07 < arbart> so the one you didn't list is to just not allow new txs to be added?
18:07 < petertodd> Luke-Jr: for sake of argument, we'll say empty blocks are an attack
18:07 < petertodd> arbart: yup
18:07 < gmaxwell> "making only empty blocks and make it useless"
18:07 < arbart> ok, heh, that is the main one i knew about
18:07 < petertodd> arbart: oh, sorry, no, there's one I didn't list that's more subtle
18:08 < arbart> petertodd: ok, i understand, and agree with that knowledge being valueable!
18:09 < petertodd> arbart: I'll give you a hint: this rule where a particularly good PoW "locks" in the chain, how would you actually implement that?
18:10 < arbart> oh my, so put in their own entire child chain?
18:10 < petertodd> well, here's the big thing: in this scheme I'm assuming that miners mining these child chains also have full consensus on the parent, and all associated data
18:10 < arbart> i wondered about the exact implementation of what you asked there, but did not forumlate or see how it is done yet.
18:11 < petertodd> yeah, implementation is critical
18:11 < arbart> ok,
18:11 < arbart> i was thinking it wouldn't be that easy for my fear there
18:11 < petertodd> see, I'm thinking that the fact that a child block was found would be known from examining *just* the parent blockchain, IE, put the child blockheaders in the parent blocks
18:12 < arbart> makes sense, it is a worked on (child) block with provable difficulty, some hash of it in the parent blockchain, something like that right?
18:13 < petertodd> yup, and importantly, by just examining the parent blockheaders+part of the blocks, you can come to consensus about the state of the child blockchain without knowing what the actual blocks are, just like SPV mode in bitcoin
18:14 < petertodd> and remember that miners who don't care about the particular child chain aren't checking the contents of the child chain's blocks, only that the child blockheaders are valid
18:15 < arbart> its like sharding but in bitcoin, i really like it
18:15 < petertodd> well, it sounds good... but there's a nasty problem with what I've described: What happens if a child-chain miner mines an invalid block, or mines a block and never gives anyone the actual block data?
18:16 < petertodd> Remember, we said the rule was that once the blockheader met the parent chain difficulty, it when in that chain and locked in that version of history so that we had 50% attack security rather than just 25%
18:17 < arbart> yes, i often wonder about that (the data block, where is it published? a concurrent distributed datastore?)
18:17 < petertodd> Excellent question! It's only "published" by giving it to other miners, there's no central place where a block goes.
18:18 < petertodd> So here we've accidentally created a system that grinds to a halt if a blockheader gets in the parent chain - with full difficulty - but the block itself never gets distributed. Ooops!
18:18 < arbart> i see, it is provable and thus accepted, but then missing
18:18 < petertodd> yup
18:18 < arbart> arg :/
18:19 < petertodd> However, we can fix this, with what I call a challenge: Mine another full-difficulty block that basically says "OK, I want this tx to be mined, and it spends these txouts. Prove that either the tx has been mined in the child chain, or that it's invalid. If you do neither, then we relax the rules and let the chld chain get reorganized anyway."
18:20 < petertodd> Or, equally the challenge could be "Where the !@#$ is block n? Stick it in this chain so we can all see it, and if you don't, we get to reorganize the chain."
18:21 < arbart> Oh, I get it now :)
18:21 < petertodd> With either version of the system (or both!) you still get the property that reorganizing the chain is hard *if* enough child-chain miners actually have the data - they can easily meet that challenge.
18:22 < petertodd> If the data gets lost somehow, or hidden maliciously, or whatever, then at least the system can recover and move on.
18:22 < petertodd> With the former version, where you can force a tx to be mined, you can always pay something like 2x the fees to get a tx mined even if some >25% attacker is trying to make the chian useless with empty block - not perfect, but better than nothing.
18:23 < petertodd> And of course, once you imagine a parent with two children... you can recurse this as deep as you want for as many tx's/second as you want.
18:24 < arbart> I was thinking recursive the whole time :)
18:24 < petertodd> hehe, good
18:25 < arbart> so who issues the challenge block? what basic condition triggers it?
18:25 < petertodd> Anyone can by mining a block meeting the parent PoW difficulty with the special challenge data in it.
18:26 < petertodd> Now, I'd expect that in a working implementation, you'd just make it possible for the 75% majority to see "Hey! Someone really wants a tx mined! Lets make it into a challenge."
18:32 < arbart> A challenge block would just have additional challenge code in it, so the miner is not forgoing tx fees and such?
18:33 < arbart> I do understand the tree-chain part itself and think it is a great idea.
18:33 < petertodd> Good question! I dunno exactly - challenges in themselves are probably possible to use in certain types of attacks. I mean, heck, you're forgetting the even bigger question of "How do I turn this crazy thing into a useful currency transaction system?"
18:35 < petertodd> For instance, can a tx on child left-left-left spend a txout from child right-right-right? Probably, with succinct merkle-path proofs. (like the (U)TXO stuff that people are working on) But what happens on a re-org? Didn't that just cause inflation?
18:35 < petertodd> (specifically double-spend inflation)
18:36 < arbart> This thing? are you referring to Bitcoin? I think it already is :) Tree-chains would augment it to enable killer apps beyond our imagination.
18:36 < petertodd> arbart: Or if not that, to enable killer headaches beyond our imagination. :P
18:37 < arbart> So tree chains might change the nature of Bitcoin as it is? I assumed txs would be rejected if they added inflation. But I think what you are raising then is things like that that would require checking the data? :)
18:38 < petertodd> Ah, but how does the miner on right-right-right know that spending a txout on left-left-left added inflation? Remember, they don't have the blockchain data, they just have a SPV-style proof that the txout existed and was spent.
18:39 < arbart> Yes, I'm seeing what you mean.
18:42 < petertodd> Heh, tough problem 'eh? I've got some ideas, but I'm not sure you can come up with a scheme that makes such systems have transactions as simple as bitcoin.
18:43 < petertodd> But anyway, given I seem to be able to explain it to some random passerby, it's an idea probably good enough to write up and publish. :) So thanks!
18:45 < arbart> It is indeed. If there was a clean recovery from missing blocks you mentioned, and an easy way for an arbitrary node to get any blocks inbetween two points (so alice on right-right-right, bob on left-left-left) in order to verify the merkle-path proofs and all :), that would solve inflation and make it no different than bitcoin as is (well, an evolution, so hard fork as in new version of client, but not incompatible)
18:45 < petertodd> arbart: Crazy thing is you can probably do this as a *soft-fork* even!
18:45 < arbart> If you have it as a pet idea, do you think it is possible? or just interested in mentally checking every so often? :)
18:46 < petertodd> Well remember, the problem isn't getting the blocks, the problem is prohibiting those blocks from getting reorganized, and the txouts getting respent elsewhere.
18:47 < petertodd> Fundementally the system just doesn't have full consensus, and without that it's hard to prevent double-spends.
18:47 < arbart> I was kinda thinking that as you described it. It could be phased in and if not affecting inflation or security, Etc, would be accepted as simply a new version that enhances tx scaling.
18:47 < arbart> I see, possible friction :)
18:49 < petertodd> Yup. Now one possible solution is to move coins around in steps: IE, make left-left-left miners also be forced to mine right-right-right blocks in some pattern, and then move value through that path... but that's inconvenient and takes a long time.
18:49 < arbart> I see, and what bitcoin does is solve the double-spend. I agree that is not something to compromise.
18:50 < petertodd> Yes, although at least we did figure out how to solve double-spending locally and hiarchically. For instance, I could have a transaction spending some 1/4-value token and some 1/2 value token in a parent chain, where the 1/4 value move can only happen if the 1/2 value one does. (but not the other way around)
18:51 < petertodd> Also interestingly, if you have a scheme of binary-sized tokens Adam Back pointed out awhile back that you can easily wind up with something pretty much as private as zerocoin.
18:51 < arbart> Oh that is interesting
18:51 < petertodd> Tokens are kinda inconvenient, but it's a possibility.
18:52 < petertodd> Also, keep in mind that the system as described has inflation as the failure mode, that's stil better than "your tx got reversed and your money vanishes"
18:54 < arbart> Oh I see, interesting. I suppose as long as it is not really possible to purposely cause it in meaningful amounts as an attack.
18:55 < petertodd> well, it's still an attack on the system, arguably, but not an attack on an individual, arguably
18:56 < arbart> Yes, it does seem to eliminate the individual attack.
19:04 < arbart> petertodd: So the current alternative you mentioned many times :) is the trusted third-party. That is something like a (logical/trust) network of web wallets?
19:06 < petertodd> arbart: off-chain tx's? it's a third-party, although the nature of the trust involved depends on how you do it
19:09 < arbart> Actually, I just realized, the third parties wouldn't have to trust each other... just trust the math of the bitcoin-nanopayment?
19:10 < petertodd> Sure, but getting acceptance for that is a social problem.
19:12 < arbart> Heh, totally. My thought was the probailistic payments might not be accepted by the average joe, but perhaps it could work for bitcoin banks to settle with each other without needing to exchange records to settle balances (without them all being separate bitcoin txs),
19:13 < gmaxwell> micropayment channels are better for that.
19:14 < arbart> But what are the existing ideas? https://npmjs.org/package/bitcoin-nanopayment is now the closest one I know thanks to visiting here just now :)
19:14 < petertodd> arbart: ah, yeah if you're talking banks u-payments work well. Or ripple actually.
19:15 < arbart> I think it needs to work with bitcoin. Inflation proof.
19:17 < arbart> petertodd: I meant bank as a concept, even if it were a computer algorithm running somewhere.
19:17 < petertodd> arbart: inflation proofing third-party balances is pretty easy actually - you can always have the bank prove your balance is backed by real bitcoins
19:22 < arbart> So is there anyone you've heard developing an open bitcoin bank API / system, meant so anyone (the world) can run an off-chain tx thingies to enable micro-transactions, and enabling a distributed nature of such (to allow people in different countries to implement them however works there), thus using something like probabilistic payments or something to settle bitcoin transfers across the 'banks' in a trustless manner? :) all 
19:23 < petertodd> arbart: None that I've heard of - doing all that is a tonne of work and tricky to monetize.
19:23 < petertodd> Small-value payments just aren't worth much... and improvements in blockchian tech, or just the community accepting less decentralization, could easily make all or effort in vain.
19:25 < arbart> Yes, well why i was wondering the state of the art, or I guess opinion on where it is at, in third party ideas, or native bitcoin protocol, or what :)
19:25 < petertodd> arbart: basically state of the art re: what we know can be done is way, way ahead of what people actually do
19:25 < arbart> oh, and they aren't worth much each, but together they are more useful/powerful
19:26 < petertodd> e.g. proving balances are backed by real bitcoins is pretty easy, yet no-one's bothered AFAIK even though there's all kinds of bitcoin funds popping up
19:26 < arbart> Well my mission is to discover all the boundries right now and then find which one I am best suited to help poke at :)
19:27 < arbart> oh interesting point
19:27 < petertodd> well, try writing one of these prove-a-balance schemes! it's reasonably easy, and would be a nice thing for us to be able to show as an example
19:29 < arbart> I can't argue any of that! That's an awesome idea then, thanks :)
19:31 < petertodd> np
19:32 < arbart> What were you thinking then, a whole system? As simple as an rpc call in bitcoind that is something like signs some proof message with the public key? (is that a good way to do it) Or what level of 'system' were you thinking?
19:34 < arbart> Oh, and thank you for the summary of the state of the art then :) Your tree-chain idea though is quite interesting and will plague my thoughts for some time to come I'm sure.
19:35 < petertodd> haha, mine too!
19:36 < petertodd> arbart: doesn't have to be fancy, just something that has some python or whatever functions that takes a list of balances, commits them to a txout, can spit out short proofs, and finally can verify those proofs is enough
19:36 < petertodd> that'd implement everything a cold-storage bitcoin investment fund would need
19:41 < arbart> I know C (enough ++ boost pain that I groked the original Satoshi client) and Java.
19:41 < arbart> Should I be learning python?
19:42 < petertodd> arbart: the python bitcoin libraries aren't great, python-bitcoinlib is one I've done some work on, a javascript implementation of this would probably be more useful to a wider audience
19:44 < arbart> In that case, scarily enough I might take a look at the javascript avenue then :)
19:44 < petertodd> arbart: heh!
20:02 < arbart> petertodd: In your list of requirements, I don't understand the 'commits them to a txout'. By that is it suggested the proof is a transaction that is output (just not published to network, but passed by hand / posted on /investors website)?
20:03 < petertodd> arbart: by "commit" I mean the txout is of some form that makes it impossible to make fraudulent proofs for a second merkle tree
20:05 < arbart> Oh I see, to actually transfer the bitcoins as part of the proof process?
20:05 < petertodd> exactly! otherwise it's just a merkle tree
20:10 < arbart> petertodd: Would you vomit, if I used supernode as a library to do this?
20:11 < petertodd> dunno what supernode is
20:12 < arbart> A BSD licensed java implementatation, not made by google.
20:12 < petertodd> ah, yeah, I dunno much about java anything
20:12 < BlueMatt> is anyone going to the financial crypto conf in march?
20:12 < petertodd> do what you want :)
20:12 < petertodd> BlueMatt: I am
20:12  * BlueMatt is pondering going...
20:12 < petertodd> BlueMatt: amiller is booked, and adam back said he was thinking of it
20:12 < BlueMatt> shit, now I have to go
20:13 < petertodd> BlueMatt: hehe
20:13 < jtimon> "commits them to a txout" sounds like "hash 'them' including a hashof a txout" I'm glad to hear I'm not the only one who gets confused when I hear that abstract data is "just simply" '"¿¡commited!?'" to other abstract data. I'm definitely not one of the math guys here, but I miss definitions quite often...
20:13  * BlueMatt ponders where to get funding from
20:13 < petertodd> BlueMatt: I'd offer to share a room except I already cheaped out on a single :P
20:13 < BlueMatt> damn
20:13 < BlueMatt> maybe adam3us would
20:13 < arbart> petertodd: Just wondering if that would limit the usefulness to the community much, not sure how people feel on that. I certainly don't like it due to oracle at least.
20:14 < petertodd> BlueMatt: what'd airfare be for you? you can get the student rates for the conf itself right?
20:14 < BlueMatt> yea, I could get student rates I'd think
20:14 < petertodd> arbart: like I said, a javacsript implementation is probably most useful because it can go on a website to show people
20:15 < petertodd> arbart: beyond that, python is probably best, although python btc libs suck
20:15 < arbart> what js lib would you recommend, when I searched it looked the only one wanted node. Are there any that will run in a browser and do what I need?
20:16 < petertodd> BlueMatt: well work out the total cost, decent chance someone could make it happen
20:16 < arbart> jtimon: thanks for that btw, helps me understand my lack of understanding :)
20:16 < petertodd> arbart: I assume whatever kyle drake is using for coinpunk would work?
20:17 < petertodd> jtimon: correct, we need a -wizards glossery
20:17 < jtimon> python libs https://github.com/monetizeio/python-bitcoin didn't got my hands into it yet, but it's maaku's forking from jgarzik, maybe too focused on commited utxo's
20:18 < BlueMatt> petertodd: now...where to get $2k
20:18 < jtimon> petertodd a glosary would be definitely a good thing
20:18 < petertodd> jtimon: I prefer my 'pythonize' branch at https://github.com/petertodd/python-bitcoinlib myself, but I am a little biased...
20:18 < petertodd> jtimon: yup, and spellcheck in my irc client...
20:18 < petertodd> BlueMatt: that's what it is for you?
20:19 < arbart> petertodd: Awesome, thanks for the pointer to coinpunk.
20:19 < BlueMatt> petertodd: well, incl the hotel +/- sharing a room...the flight is ~700
20:19 < petertodd> arbart: kyle seems pretty competent, so whatever he uses is probably good :P
20:19 < BlueMatt> oh, sorry, +500 for the conf...dur
20:19 < petertodd> BlueMatt: I managed my hotel for like ~$200, but I really cheaped out
20:20 < Luke-Jr> I wish I could cheap out in miami :/
20:20 < jtimon> well, when I don't understand you is more often because you use foreign terms like I live in your head than because you  misspell
20:20 < petertodd> BlueMatt: of course, if you get desperate, ask, and we can swap bookings :)
20:20 < Luke-Jr> I'll be lucky to get hotel alone for under $1000
20:20 < BlueMatt> petertodd: heh, well I suppose I could look harder at finding a real hotel instead of the conf one.....
20:20 < petertodd> BlueMatt: oh, the conf one is insane, IIRC mine was $40 a night
20:20 < BlueMatt> yea, thought so
20:21 < petertodd> single room, shared kitchen/bath - kinda a hostel
20:21 < petertodd> problem is they seem to be booking out :(
20:21 < BlueMatt> petertodd: yea, I had it on my calendar to figure it out by I forgot until today
20:21 < jgarzik> BlueMatt, RE fin crypto, trying to get core devs there
20:21 < jgarzik> Barbados, March 3-7, IIRC
20:21 < BlueMatt> yep
20:21 < arbart> While I'm a math guy, so I really should learn python, however, one idea I have I have would actually need javascript in browser able to generate transactions, so I guess coinpunk it is :)
20:22 < petertodd> jgarzik: you're gonna make this conf go from academia to bitcoin-central :P
20:22 < jgarzik> hey, I didn't start it
20:22 < petertodd> arbart: python is the one true language :) but yeah, in-browser is great for demos for people
20:23 < petertodd> jgarzik: of course, the actual bitcoin part is like one day out of seven
20:23 < BlueMatt> the foundation is a big sponsor...
20:23 < jgarzik> indeed
20:23  * jgarzik would probably only come in for the bitcoin part
20:23 < jgarzik> too many confs.  if you go to them all, there's no time for real work.
20:24 < petertodd> BlueMatt: dunno I'd say "big" - they're sponsoring a one-day workshop, dunno what that means in terms of the whole thing
20:24 < Luke-Jr> jgarzik: no kidding, it's getting to the point where it's almost once every week it seems
20:24 < BlueMatt> petertodd: well...they have the largest logo, so that means they have no sponsors, really
20:25 < petertodd> BlueMatt: oh yeah? lol, the location is a bit suspect
20:25 < jtimon> another foundation, small sponsor, but funds free software more than PR, get listed can't lose anything http://foundation.freicoin.org/#/donations, sorry for the spam...
20:25 < Luke-Jr> jtimon: huh?
20:27 < jtimon> Luke-Jr was continuing this "the foundation is a big sponsor..." but yeah, sorry for the offtopic (if you're developing complementary currency-related free software [I think you are] then you should definitely get listed there to get 10% matched donations)
20:29 < petertodd> BlueMatt: you should prove your worthyness by writing up a quick app to do a SIGHASH_ANYONECANPAY fund for you to go :)
20:30 < Luke-Jr> petertodd: that also requires the donors to be "worthy" :P
20:30 < shesek> arbart, look into bitcoinjs-lib, vbuterin's fork is the most maintained one
20:30 < petertodd> Luke-Jr: the better the app is, the less worthy the donors need to be!
20:30 < shesek> and it works well in the browser with browserify
20:30 < Luke-Jr> petertodd: oh app :D
20:31 < shesek> (browserify compiles code with nodejs module system to a single js file with all the dependencies)
20:34 < arbart> shesek: thank you very much!
20:34 < shesek> arbart, you welcome
20:35 < shesek> I've been using it quite heavily myself for bitrated, so feel free to ping me if you need any help
20:48 < arbart> shesek: thanks, its not unlikely I'll have to take you up on that offer :)
20:48 < shesek> cool, I'll be glad to help if I can :)
20:52 < shesek> you can also check the code at https://github.com/shesek/bitrated/ to see some examples of using it (its written in coffeescript, though) and how the browserify compilation step works (bin/build-static.sh, or server/assets.coffee for a nodejs server that compiles on-the-fly)
20:53 < jgarzik> shesek, RE bitcoinjs-lib, BitPay's fork of bitcoinjs-server (the node.js fork) is the most maintained
20:53 < jgarzik> in case you are on server, rather than client/browser
20:53 < jgarzik> https://github.com/bitpay/bitcore
20:54 < shesek> oh really? that's great to know, last time I looked at bitcoinjs-server it seemed completely unusable :\
20:54 < shesek> I ended up using bitcoind with a thin nodejs layer to serve the public api
20:54 < jgarzik> shesek, creaky and old.  both bitcoinjs-lib and bitcoinjs-server were 2 years old. no p2sh, no multisig, ...
20:55 < jgarzik> shesek, we need all that, so we picked up maint on the node.js stuff
20:55 < jgarzik> shesek, _most_ is compatible with the browser, but there are a few replacements still needed
20:56 < shesek> have you looked into vbutertin work on bitcoinjs-lib? he got it to a pretty stable state, added new features, and made it compatible as a nodejs modules
20:57 < jgarzik> yes
20:57 < jgarzik> it wasn't complete enough when we looked at it
20:57 < jgarzik> at the time, coinpunk was in bitpay's office, hacking out code to run in browser
20:59 < shesek> oh, cool, I didn't know coinpunk was related to you
20:59 < shesek> you just gave them some work space, or is coinpunk a bitpay project?
20:59 < jgarzik> he worked for us briefly
21:00 < arbart> What's the node.js stuff for? accessing the blockchain?
21:01 < shesek> that, and for handling keys/addresses/transactions/signatures server-side
21:02 < arbart> No current alternative if I want browswer js to parse the blockchain for what I'm doing?
21:03 < shesek> how would that work? you would load the entire blockchain client side?
21:03 < shesek> the client-side libraries allows you to create keys/addresses, construct/sign transactions and all that
21:04 < shesek> communicating with the Bitcoin network/blockchain requires running something on the server that's capable of doing that
21:04 < shesek> I ended up writing https://github.com/shesek/bitcoin-webapi that exposes some minimal APIs that I needed (loading unspent inputs and broadcasting transactions) on top of bitcoind with sipa's #2802
21:04 < shesek> (address index with searchrawtransaction, https://github.com/bitcoin/bitcoin/pull/2802)
21:10 < arbart> Ok, I understand then. Your coffee script stuff looks pretty cool actually.
21:11 < shesek> its a nifty little language that can give some people a serious productivity boost, but its not for everyone :)
21:12 < shesek> bitrated's source is still a bit messy, but its somewhat organized and commented, so it should give you a good start
--- Log closed Fri Jan 24 00:00:55 2014